С ростом количества компонентов в программной системе, обычно растёт и количество людей принимающих участие в её разработке. Как следствие, для сохранения темпов разработки и простоты сопровождения, подходы к организации API должны стать предметом особого внимания.
Если хотите познакомиться поближе с тем как команда Wargaming Platform справляется со сложностью системы из более чем сотни взаимодействующих друг с другом web-сервисов, то добро пожаловать под кат.
Читать полностью »
Чем высоконагруженная информационная система похожа на огромный гипермаркет? Что делать, если 150 млн человек одновременно придут в гипермаркет за покупками? За что можно наказать руководителя гипермаркета, а за что нет? Почему время загрузки документа ночью намного меньше, чем днем? Почему время загрузки одного документа на самом деле ни о чем не говорит?
Высоконагруженные информационные системы имеют свои особенности, которые не очевидны для многих организаций-поставщиков. Мы расскажем, как устроена массовая загрузка документов (и других данных) и подробно рассмотрим этот непонятный для многих вопрос.
За последний год публикаций о микросервисах стало так много, что рассказывать что это и зачем нужно было бы пустой тратой времени, так что дальнейшее изложение будет сконцентрировано на вопросе — каким способом бы реализовали эту архитектуру и почему именно так и с какими проблемами столкнулись.
У нас в небольшом банке были большие проблемы: 3 python монолита связанных чудовищным количеством синхронных RPC взаимодействий с большим объемом legacy. Что бы хотя бы отчасти решить все возникающие при этом проблемы было принято решение перейти на микросервисную архитектуру. Но прежде чем решиться на такой шаг нужно ответить на 3 основных вопроса:
Собственно кратким ответам на эти вопросы и будет посвящена данная статья.
Процесс документирования эволюционно прорастает из скупых комментариев в коде по мере роста компании. Где-то в середине пути обычно появляются люди, которые говорят, что знают, как правильно, и что «в этой книжке написано, как надо делать документацию», и приносят в компанию какой-нибудь тяжелый процесс. Дальше идут обсуждения, споры, ссылки на разные источники с противоречивыми подходами и так далее. На самом деле всё это не случайно. Каждый раз, когда мы сталкиваемся с такими моментами, это значит, что есть культурные различия. Тренды меняются, и каждая эпоха дает свои учебники.
Под катом вместе с Максимом Цепковым будем разбираться, какие уроки можно вынести из разных подходов, как проектировать документы проекта, что занести в wiki, для чего подойдет Google Docs, а что обязательно должно все время находиться перед глазами. Да и вообще, зачем нужна это вся документация. Заодно и тему управления знаниями затронем.
Я учусь в CS центре в Новосибирске уже второй год. До поступления у меня уже была работа в IT — я работал аналитиком в Яндексе, но мне хотелось развиваться дальше, узнать что-то за пределами текущих задач и, по совету коллеги, я поступил в CS центр. В этой статье я хочу рассказать о практике, которую проходил во время учебы.
В начале первого семестра нам предложили несколько проектов. Мое внимание сразу зацепилось за проект под названием «Метод оценки цвета зерна по фотографии». Эту тему предложили специалисты из Института цитологии и генетики СО РАН, но сам проект был больше связан с анализом и обработкой изображений, чем с биологией. Я выбрал его, потому что интересовался машинным обучением и распознаванием образов и мне хотелось попрактиковаться в этих областях.
Читать полностью »
Давно я хотел написать эту статью. Все думал — с какой стороны зайти правильнее? Но, вдруг, недавно, на Хабре появилась подобная статья, которая вызвала бурю в стакане. Больше всего меня удивил тот простой факт, что статью начали вбивать в минуса, хотя она даже не декларировала что-то, а скорее просто поднимала вопрос об использовании кодов ответа web-сервера в REST. Дебаты разгорелись жаркие. А апофеозом стало то, что статья ушла в черновики… килобайты комментариев, мнений и т.д. просто исчезли. Многие стали кармо-жертвами, считай, ни за что :)
В общем, именно судьба той статьи побудила меня написать эту. И я очень надеюсь, что она будет полезна и прояснит многое.
Предупреждаю, все ниже написанное является реальным опытом, а не когнитивной эквилибристикой. И так, погнали.
Читать полностью »
ExonumTM — это наш открытый фреймворк для создания приватных блокчейнов. Сегодня мы расскажем, как работает его алгоритм консенсуса.
В первой части статьи мы написали небольшой веб-сервер, который является бэкендом для нашей информационной системы. Та часть не была особенно интересной, хотя и демонстрировала использование интерфейса и один из приёмов работы с горутинами. И то и другое может быть интересно начинающим разработчикам.
Вторая же часть намного интереснее и полезнее, потому что в ней мы напишем юнит-тесты как для самого сервера, так и для библиотечного пакета, реализующего хранилище данных. Приступим.
картинка отсюда
Читать полностью »
Давайте попробуем написать небольшую тренировочную, но вполне себе законченную информационную систему, состоящую из серверной части на Go и клиентского веб-приложения на Javascript + Vue JS.
Для начала пару слов о том, что это за приложение и для чего оно нужно. Некоторое время назад передо мной встал вопрос о том, как бы сохранить некоторую сумму денег, которая у меня образовалась. Даже мне, человеку далёкому от мира финансов, было очевидно, что держать деньги наличными плохо по, как минимум, двум причинам:
Было принято решение изучить вопрос и выбрать подходящий инструмент для инвестирования. Основными критериями были надёжность и защита сбережений от указанных выше рисков.
Вопрос я изучил и в результате пришёл к выводу, что единственным адекватным инвестиционным инструментом для жителя России являются акции биржевых фондов (ETF), причём именно те, что торгуются на Московской Бирже.
Таким образом, предлагаю написать учебное приложение, которое бы показывало доходность всех ETF, которые представлены на Московской Бирже.
Читать полностью »
В этой трехминутной статье я хочу затронуть наболевшую тему.
Речь пойдет о статус коде HTTP 200 и ошибках в ответе.
HTTP/1.1 200 OK
{
"error": {
code: 2019,
message: "Validation failed: field 'size' is invalid: the value is not a number"
}
}
Нормально ли возвращать такой код, если возникла ошибка?
Нет? Да? Ну-ка давайте разберемся.
Допустим отправляется один запрос. Запрос выполняется успешно. Возвращаем код 200. Ответ не содержит информации об ошибке. С этим случаем всё предельно просто и понятно. А что делать если требуется выполнить batch операцию?
Читать полностью »