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

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

В первую очередь расскажем немного о том, что же такое 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.

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

В этой статье мы хотели поговорить о моделировании волн в открытом море и представить алгоритм, который позволил достичь достаточно интересные результаты при приемлемых 25-30Fps на среднем китайфоне.

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

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