Рубрика «Анализ и проектирование систем» - 38

В последнее время мы в группе распознавания компании ABBYY всё больше применяем нейронные сети в различных задачах. Очень хорошо они зарекомендовали себя в первую очередь для сложных видов письменности. В прошлых постах мы рассказывали о том, как мы используем нейронные сети для распознавания японской, китайской и корейской письменности.

image Пост про распознавания японских и китайских иероглифов
image Пост про распознавание корейских символов

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

Мотивация

А в чём вообще проблема? Зачем нужно работать на изображениях, которые не являются отдельными символами? Казалось бы, можно разделить фрагмент строки на символы, классифицировать их все и собрать из этого результат, как, например, на картинке ниже.

Отличаем символы от мусора: как построить устойчивые нейросетевые модели в задачах OCR - 3

Да, конкретно в данном случае так действительно можно сделать. Но, увы, реальный мир устроен куда более сложно, и на практике при распознавании приходится иметь дело с геометрическими искажениями, смазом, пятнами кофе и прочими трудностями.
Читать полностью »

Производительность фронтенда: разбираем важные метрики - 1

Обычно под производительностью понимают количество операций за определенный интервал времени и чем их больше, тем лучше. Но такое определение, да и подход в целом, мало применим к фронтенду, потому что у каждого пользователя будет свой «фронтенд». Именно об этом я и хочу поговорить, что же происходит «там», у пользователя, на другой стороне, в реальности, а не на вашем топовом MacBook.

Кроме это, я постараюсь вскользь рассмотреть общие правила оптимизации кода и некоторые ошибки на которые стоит обратить внимание. Ещё расскажу про инструмент, который помогает не только в профилировании, но и «из коробки» собирает кучу базовых метрик о производительности вашего приложения (и надеюсь, вы дочитаете этот пост до конца).
Читать полностью »

Введение

В рамках предыдущих статей мы описали: область применения, методологические основы, пример архитектуры и структуры. В данной статье, я хотел бы рассказать как описывать процессы, о принципах сбора требований, чем отличаются бизнес требования от функциональных, как перейти от требований — к коду. Рассказать о принципах применения Вариантов Использования (Use Case) и как они нам могут помочь. Разобрать на примерах варианты реализации шаблонов проектирования Interactor и Service Layer.

likeyourgrandmom

Примеры приведенные в статье даны с использованием нашего решения LunaPark, оно поможет вам с первыми шагами в описанных подходах.

Отделяем функциональные требования от бизнес требований.

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

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

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

Читать полностью »

С одной стороны, предмет действительно был квадратным. C другой стороны он был круглым. Но с третьей стороны, с которой должен быть треугольник, предмет вышел кривой и косой.

— Алешенька идет на совещанку? — в дверь просунулась Леночкина заинтересованная физиономия.
— Алешенька на совещанку не идет. Алешенька пишет статью.
— О кубиках?
— Каких еще кубиках? — я опустил глаза, в руках и правда был злосчастный кубик. То есть шарик. То есть ромбик.
— Не о кубиках! И не о шариках. О шаблонах.
— Я им так и скажу! Шаблон, ах. — Леночка уже бежала дальше по коридору.

"О шаблонах. Даже о трех разных шаблонах". Точнее, о трех причинах использовать шаблоны в серверном коде. И ни одна из этих причин не будет про HTML.

В примерах я использовал синтаксис Mustache, в силу лаконичного синтаксиса и наличия реализаций для всего, что движется. Mustache практически не позволяет себе вольностей в отличии от, например .Net Razor, который позволяет кодировать внутри шаблона, подавая тем самым плохой пример некрепким духом разработчикам.

Примеры кода будут на python. Реализация Mustache под пайтон называется pystache.

Итак, три причины впустить шаблоны в свою жизнь свой код.

Читать полностью »

Есть такая полезная задача — разработка систем мотивации. Я долго наблюдал за несчастными HR, которые создавали системы KPI, материальную и нематериальную мотивацию, силились поднять корпоративный дух. Мои наблюдения всегда показывали одно и то же — HR в этой работе чего-то не хватает. Вроде слова правильные говорят, и философия под их расчетами правильная лежит, но созданные ими системы мотивации не выдерживают никакой критики.

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

А если вспомнить о том, что бизнес далеко не всегда может нормально выразить словами, чего хочет от конкретной должности, то становится совсем грустно. И ладно, если именно выразить не может — иногда ведь и не понимает. Точнее, не понимает конкретный представитель этого бизнеса, заказывающий систему мотивации.

Итогом почти всегда является «какая-нибудь» система мотивации, которая хоть что-то считает и дает хоть какое-то представление об эффективности работы людей. Но главная беда — система мотивации не приносит пользы бизнесу, потому что оценивает людей по критериям, ему не выгодным.

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

В итоге я пришел к выводу, что разработка систем мотивации — больше инженерная задача, чем гуманитарная (да простят меня милые и добрые HR). Как ни крути, система мотивации — это система показателей. Показатели — это измерение, управление границами, согласованность целей и возможностей, четкая взаимосвязь с бизнес-процессом, правильная автоматизация. Все перечисленное — инженерные задачи.Читать полностью »

Сравниваем особенности микросервисной и монолитной архитектуры, их преимущества и недостатки. Статья подготовлена для Хабра по материалам нашего митапа Hot Backend, который прошел в Самаре 9 февраля 2019 года. Мы рассматриваем факторы выбора архитектуры в зависимости от конкретной задачи.Читать полностью »

Рекомендательные системы: идеи, подходы, задачи - 1

Многие привыкли ставить оценку фильму на КиноПоиске или imdb после просмотра, а разделы «С этим товаром также покупали» и «Популярные товары» есть в любом интернет- магазине. Но существуют и менее привычные виды рекомендаций. В этой статье я расскажу о том, какие задачи решают рекомендательные системы, куда бежать и что гуглить.
Читать полностью »

Всем привет!

Школа системного анализа Альфа-Банка - 1

Мы открываем набор в школу системного анализа Альфа-Банка. Если у вас есть желание освоить новую специальность (а в перспективе и получить работу в наших продуктовых командах), обратите внимание. Стартуем с 6 августа, обучение бесплатное, занятия очные в нашем офисе на Ольховской (ближайшие станции метро — Комсомольская и Бауманская) по вторникам и четвергам, курс длится 4 недели.

А теперь подробнее.
Читать полностью »

История выкатки, которая затрагивала всё - 1
Enemies of Reality by 12f-2

В конце апреля, пока белые ходоки осаждали Винтерфелл, у нас произошло кое-что поинтереснее, мы сделали не совсем обычную выкатку. В принципе мы постоянно катим новые фичи в прод (как и все). Но эта была не такая, как все. Масштаб её был таков, что любые потенциальные ошибки, которые мы могли допустить, поаффектили бы все наши сервисы и пользователей. В итоге мы всё выкатили по плану, в запланированный и анонсированный срок даунтайма, без последствий для прода. Статья — о том, как мы этого добились и как желающие могут это повторить в домашних условиях.
Читать полностью »

Предыстория

Я работаю фронтенд разработчиком уже на протяжение одного года. На моём первом проекте был «вражеский» бэкенд. Бывает так, что это не составляет больших проблем, когда налажена коммуникация.

Но в нашем случае было не так.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js