Раньше я использовала для рисования диаграмм плагин в Confluence drawio или Microsoft Visio, который позволяет в графическом виде нарисовать диаграммы. Основная боль (для меня) у этих инструментов заключалась в том, чтобы поправить множество диаграмм надо открывать каждую, двигать элементы, стрелочки. А это время.

Изучив возможные решения я пришла к plantuml. Это инструмент, который позволяет с помощью текста рисовать диаграммы. Его можно использовать через макрос в Confluence или плагин в Idea, что позволяет за раз править много диаграмм, так как это текст. Не верите? Давайте попробуем на примере.

Представьте, что в рецепте для приготовления еды была бы вводная часть о том, откуда привезли продукты, как их упаковывали и доставляли.

Вы бы стали читать рецепт из 10 страниц, чтобы приготовить салат? Что-то я сомневаюсь. Схожая ситуация бывает в документации, когда она пишется без шаблона по принципу "чем больше, тем лучше".

Если ваши  документы не читают, не понимают, или вы не знаете с чего начать описывать интеграцию,  то эта статья для вас.

Я тех.лид системных аналитиков и прошла долгий путь к шаблонам документации в разных компаниях.

Введение

«Нужно бежать со всех ног, чтобы только оставаться на месте,
а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!»
(с) Алиса в стране чудес

Некоторое время назад меня попросили прочитать лекцию аналитикам нашей компании на тему проектирования моделей данных, ведь сидя долгое время на проектах (порою по нескольку лет) мы упускаем из виду происходящее вокруг в мире ИТ-технологий. В нашей компании (уж так получилось) на многих проектах не используются NoSQL-базы данных (по крайней мере пока), поэтому в своей лекции я отдельно уделил им некоторое внимание на примере HBase и постарался ориентировать изложение материала на тех, кто с ними никогда не работал. В частности, я иллюстрировал некоторые особенности проектирования модели данных на примере, который несколько лет назад прочитал в статье «Introduction to HB ase Schema Design» by Amandeep Khurana. Разбирая примеры, я сравнивал между собой несколько вариантов решения одной и той же задачи, чтобы лучше донести до слушателей основные идеи.

Недавно, «от нечего делать», я задался вопросом (длинные майские выходные в режиме карантина к этому особенно располагают), насколько теоретические выкладки будут соответствовать практике? Собственно, так и родилась идея этой статьи. Разработчик, который не первый день работает с NoSQL, возможно и не почерпнет из нее что-то новое (и поэтому может сразу промотать полстатьи). Но для аналитиков, которые еще не работали плотно с NoSQL, полагаю, она будет полезна для получения базовых представлений об особенностях проектирования моделей данных для HBase.

Архитектура: искусство делать излишнее необходимым.

Фредерик Кислер

Вместо введения

Для кого я решил написать? Данная статья, написана для моих коллег аналитиков или для тех, кто желал бы им стать. Если вы теперь захотели стать аналитиком, то подумайте хорошенько. 

Микросервисы. С хайпом вокруг них, лучше быть разработчиком, архитектором, тестировщиком, проджект-менеджером, дизайнером. Хорошо быть кем угодно в микросервсиах, но только не аналитиком. Аналитик ведь всегда во всем виноват. Ни разу не слышал, чтобы в “факапе” и срыве сроков обвинили архитектора, ну или там разработку. Нет, господа, вина всегда лежала и будет лежать на плохой документации и нечетко поставленных задачах. Вот вся команда собралась и тычет в тебя пальцами. Дескать, это все он! Опытный архитектор спроектировал, хороший разработчик сделал, внимательный тестировщик протестировал, мотивированный проджект-менеджер обеспечил… а невнимательный аналитик все завалил. А меж тем, материалов по аналитике и как её вести на русском языке очень мало. И как “анализировать” эти самые микросервисы не совсем понятно. Более того, никто вам не скажет, чем “системный аналитик” теперь отличается от “солюшн архитектора”. Вот во всем этом я и захотел разобраться и поделиться. Поэтому, если вы не аналитик - не читайте. Вам не будет интересно. Ведь, нет в вас экзистенциального кризиса и вопросов “Кто я? и зачем я им нужен на проекте”.

Я проходил технические собеседования на системного аналитика в самых разных компаниях и каждый раз записывал все вопросы. У меня накопилось 120 вопросов. Список вопросов выкладываю в этой статье. Даю гарантию, что, подготовившись по этим вопросам, вы будете успешно проходить технические собеседования в большинстве, если не во всех, it-компаниях. Почему? Потому что большинство вопросов повторяются от собеседования к собеседованию. Очень высока вероятность того, что вопросы, которые вам будут задавать, будут из этого списка.

Так получилось, что я провожу довольно много собеседований на должность веб-программиста. Один из обязательных вопросов, который я задаю — это чем отличается INNER JOIN от LEFT JOIN.

Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.

Я так устал от этих ответов с пересечениями множеств и кругов, что даже перестал поправлять людей.

Дело в том, что этот ответ в общем случае неверен. Ну или, как минимум, не точен.

Расскажу про системы с микросервисной архитектурой (MSA). Как они устроены, как я их анализировала, какие увидела проблемы и преимущества.

Статья не раскрывает лучшие практики использования микросервисов и не разоблачает их излишнюю популярность. Основная цель - описать технологию и процесс работы с ней с точки зрения системного аналитика.

Содержание

• Что это и как работает
  
  • Зачем нужен клиент
  • Зачем нужен сервер
  • Зачем нужна база
• Плюсы архитектуры
• Минусы архитектуры
• Что тестировать
• Итого

В этой статье я расскажу об особенностях работы data-аналитиков и поделюсь, как взяла за основу scrum и оставила только каркас, идеологию. Адаптировала в Кошельке процессы, которые успешно прошли тест-драйв длиною в год. 

Представьте, что вам предстоит собеседование на позицию системного аналитика (СА). Что нужно знать для успешного прохождения интервью и какие вопросы могут задать? Эта статья может стать roadmap при подготовке к собеседованию.

Все больше и больше аналитиков, проджектов и продактов приходят в айти из маркетинга, консалтинга, продаж и других нетехнических индустрий, да и вообще без опыта работы. И я тут не стал исключением. Существует проблема, что в первые годы на тебя падает немерено технических терминов и концепций, ты пытаешься в них разобраться, но не понимаешь до какого уровня деталей тебе надо опускаться в каждой из них. Надо ли разбираться, что значит обнаруженный тобой термин WSDL и какие бывают виды асинхронного выполнения запроса, или достаточно знать, что у веб-сервиса просто есть запрос и ответ? Статья нужна, чтобы решить эту проблему для одной из самых частых фичей – научиться работать с веб-сервисом для обмена данными, выполнения целевых действий в других системах и прочих интеграций.

Что касается нынешнего ИТ-рынка, среда DevOps — один из лучших вариантов для ИТ-специалистов с точки зрения заработной платы и карьерного роста. И мне довольно часто задают вопрос: «Как стать инженером DevOps?»

В этом блоге я попытаюсь ответить на него на примере своего собственного опыта работы DevOps в различных организациях.

Я бы хотел получить такое письмо три года назад, когда только начинал изучать Data Science (DS). Чтобы там были необходимые ссылки на полезные материалы. Статья не претендует на полноту охвата необъятной области DS. Однако для начинающего специалиста будет полезна.

В индустрии существует целый ряд кейсов, требующих распознавания номера по фотографии
(scene number recognition). Часто требуемым условием для алгоритма распознавания является низкое значение ошибки второго рода, а именно случаи, когда распознается неверный номер. В качестве примера таких задач можно привести:

1. Распознавание номера на скидочных, банковских картах, рисунок 1.
2. Распознавание номера автомобиля, рисунок 2.

Рисунок 1 – Карта лояльности
Рисунок 2 – Изображение, содержащее регистрационный номер в низком качестве

Среди проблем, связанных с распознаванием номера, можно выделить:

• Большое разнообразие шрифтов;
• Отсутствие зависимости между предыдущими и последующими символами номера (в отличие от задачи распознавания текста);
• Высокий уровень шумов по причине того, что съемка ведется в различных условиях освещенности, с разного оборудования и т.д.

Задача

Разработать алгоритм распознавания номера на изображении (scene number recognition) при обязательном условии: ошибка второго рода должна быть не больше 0.03.

import numpy as np

1. Flask

2. Keras

Лирика