Современная разработка построена таким образом, что каждый участник команды, будь то разработчик, UI-специалист или product manager, отвечает только за те этапы работы, на которые распространяется его область знаний. Однако, для создания наилучшего продукта специалист должен понимать в достаточной степени все шаги производственного процесса. Если команда стремится к кросс-функциональности, когда разделение по зонам ответственности условно, то качество продукта и достижение поставленной цели становятся зоной ответственности не только отдельных специалистов, но и всей команды.

Пример из практики

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

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

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

Алгоритмы рекомендаций, предсказания событий либо оценки рисков – трендовое решение в банках, страховых компаниях и многих других отраслях бизнеса. Например, эти программы помогают на основе анализа данных предположить, когда клиент вернет банковский кредит, какой будет спрос в ритейле, какова вероятность наступления страхового случая или оттока клиентов в телекоме и т.д. Для бизнеса это ценная возможность оптимизировать свои расходы, повысить скорость работы и в целом улучшить сервис.

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

В первую очередь расскажем немного о том, что же такое Flutter. Это фреймворк для создания мобильных приложений от компании Google. Он является кроссплатформенным и позволяет компилировать созданный проект под 3 операционные системы:

• Android
• iOS
• Fuchsia

Причем для последней ОС – Fuchsia – это пока единственный способ создать приложение.
Flutter на протяжении долгого времени, с 2015 года, был представлен только в альфа и бета версиях. Релиз первой стабильной версии состоялся 4 декабря 2018 года.

Flutter активно продвигается Google, постепенно набирает популярность и, скорее всего, в дальнейшем будет теснить другие, используемые сейчас средства кроссплатформенной разработки (React Native, Xamarin), особенно при условии широкого распространения Fuchsia. С учетом того, что Google позиционирует данную операционную систему как замену Android, рано или поздно Flutter вытеснит нативную разработку под Android. Поэтому перспективность и активное развитие – основные плюсы Flutter.

Так или иначе, все сталкивались с ситуациями, когда в банальной обстановке вдруг происходило что-то необычное. Примерно такой случай произошел с нами при тестировании нового приложения на проверенном сто раз окружении. Сюрпризом для нас стало использование некоторых возможностей HTML5 в работе front-end’а, а точнее невозможность стандартными средствами Selenium WebDriver автоматизировать тестирование drag&drop операций. Об этом опыте мы хотим рассказать.

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

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

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

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

Достаточно часто компании с собственным программным продуктом, будь то мобильное приложение, внутренние, CRM — системы и т.д., сталкиваются с необходимостью дальнейшего развития решения. Причины могут быть разные: существующее ПО не соответствует бизнес-требованиям, процессам, показатели растут не так быстро, как хотелось бы, завалена техническая поддержка, от пользователей мало положительных отзывов. В таких случаях выявить слабые места и точки роста позволит аудит качества продукта.

Один из наших заказчиков обратился к нам с проблемой выпуска корпоративного приложения для управления дочерними филиалами. Клиент – страховая компания, в сферу работы которой входит рисковое и накопительное страхование, прочие услуги. Для координации, управления и учета деятельности головного офиса и дочерних филиалов существует специальное программное обеспечение. Основной функционал которого – большое количество журналов учета, планирования и аналитики. Кроме автономных журналов, предназначенных для конкретного подразделения и исключительно для локальных целей, есть журналы совместного пользования. По ним информация собирается в головной офис и в обратном направлении также спускаются планы и показатели.

Введение

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

На практике мы часто сталкиваемся с тем, что руководитель проекта хочет ускорить процесс разработки — его не устраивает скорость поставки нового функционала. Как правило такие клиенты нуждаются в сложных продуктах вроде системы управления госпиталем, системы торговли на бирже, банковских системах, ДБО.

В таких случаях можно подключить новую команду специалистов, наладить процессы в уже существующей или объединить и то, и другое. Рассмотрим, какие плюсы и минусы есть у каждого подхода. Сразу оговоримся, что в статье рассматривается разработка крупных и сложных проектов (больше 10 000 часов).

Расскажем о том, как мы принимали решение о применении blockchain-сети для нового проекта.

Эта история случилась в конце весны 2018 года. Мы отказались от блокчейна (AplaNet), предложенного стейкхолдером проекта и выбрали иное решение для продукта (Emercoin).

NOTE: в данный момент команда AplaNet решила большинство проблем, которые мы описали ниже. Так что все моменты, на которые мы обратили внимание, имели место быть в конце весны.

Мы работали над проектом, для решения бизнес-задач которого нужен блокчейн (реально нужен, а не как обычно). На его примере будем говорить о критериях выбора блокчейн-сети.
К сожалению, подробнее рассказать бизнес-кейс проекта мы, на данный момент, не можем. Поэтому статья не об этом.

Unity3D известнейшая платформа для разработки 3D и 2D игр, завоевавшая популярность во всем мире. В то же время ее возможности не ограничены разработкой только игровых приложений, а подходят для применения в любых других областях, требующих создания кроссплатформенных приложений для работы с графикой. В этой статье мы расскажем об опыте использования Unity3D для разработки системы расчета освещения открытых пространств.

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

Когда требования на проекте меняются “на лету” и у вас нет под рукой средства контроля за реализацией каждого отдельного требования по фиче или модулю, перед вами встает вопрос: как проводить анализ покрытия? Одним из таких инструментов, который использует наша команда QA на подобных проектах — матрица трассируемости (traceability matrix).

На данный момент мы используем матрицы более 2,5 лет. За это время мы смогли оценить преимущества этого инструмента, а также адаптировать его под наш проект.

В С++ направлении мы разработали приложение для подсчета количества посетителей на основе анализа видеопотока с видеокамеры. Его отличительной особенностью было в то, что приложение разрабатывалось как отдельный автономный модуль для запуске на плате Up Board. Это позволяет клиентам купить необходимое количество устройств и самим установить в требуемых местах. Также было разработано отдельное приложение-сервер, которое позволяло настраивать эти устройства удаленно, получать статистику с них, видеопоток и представлять данные о посетителях в удобном виде.

Каждому разработчику знакома ситуация, когда реализация новой возможности в системе занимает большое количество времени, но релиз уже близко, а тимлид или менеджер проекта пятый раз за день задают уже надоевший вопрос: “Ну когда будет готово?”. И тогда встает непростой выбор — сделать все правильно и не уложиться в сроки релиза или реализовать минимально работающий, но не идеальный с точки зрения технического решения, функционал. Очевидно, что в большинстве случаев будет выбран второй вариант, так как релиз и предоставление результата клиентам здесь и сейчас важнее чистоты кода и архитектуры системы. Но проходит несколько месяцев, и вот уже старое не идеальное техническое решение мешает реализации другого функционала. И дальше такие решения будут накапливаться в огромный ком. Разбираясь с этой проблемой, очень важно сделать правильные выводы и выбрать нужное решение. От этого решения будет зависеть дальнейшая судьба всего проекта. В данной статье мы постараемся разобраться с природой технического долга и посоветовать пути его устранения.

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

Теме чистого кода на одном только habrahabr посвящено тысячи статей. Никогда бы не подумал, что захочу написать свою. Но после проведения компанией курсов для желающих связать карьеру с разработкой ПО, в частности разрабатывать под Android, мое мнение поменялось.

За основу статьи взяты советы из классики “Роберт К. Мартин: Чистый код”. Отобрал из них те, которые наиболее часто встречались в виде проблем у студентов. Приведенные советы написаны с учетом моего опыта разработки коммерческих Android приложений. Поэтому не ко всем Android-проектам приведенные ниже советы подойдут, я уже не говорю про другие системы.

Советы в основном приводил с примерами кода как НЕ НУЖНО делать. Как ни странно, у большинства студентов были одни и те же ошибки. Все примеры кода были придуманы, любые совпадения с реально существующим кодом случайны.

Перейдем к самому интересному — подборке самых полезных и интересных, на наш взгляд, трюков и скрытых возможностей Chrome DevTools.