Уже на стадии проектирования мобильного приложения важно понимать, какой язык выгоднее использовать для конкретного проекта. Наряду с нативной разработкой (например, для iOS — Swift или Objective-C, для Android – Java или Kotlin), используются кроссплатформенные фреймворки, такие как React Native и Flutter. Мы в SimbirSoft предлагаем несколько критериев, которые помогут в выборе как бизнесу, так и мобильному разработчику.

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

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

Go получил славу одного из самых простых языков программирования, в числе его плюсов – простота написания и чтения кода, в большинстве случаев более простая поддержка кодовой базы. Рассказываем о нескольких преимуществах Go, благодаря которым мы в SimbirSoft использовали его в ряде высоконагруженных проектов с различными архитектурами, как веб-сервисными, так и микросервисными (SOA).

Успех IT-проекта во многом зависит от того, насколько грамотно организована система тестирования и обеспечения качества (Quality Assurance, QA) на всех этапах его жизненного цикла.

Для специалиста по QA один из самых надежных способов подтвердить свои профессиональные качества ─ наличие международного сертификата ISTQB. Сегодня поговорим о том, что дает такая сертификация сотруднику, работодателю и бизнесу, а также о том, как мы в SimbirSoft поддерживаем квалификацию QA инженеров.

IT-компания SimbirSoft в очередной раз организует двухнедельную образовательную программу для специалистов и студентов в сфере информационных технологий. Занятия пройдут в Ульяновске, Димитровграде и Казани.

Участники смогут на практике познакомиться с процессом разработки и тестирования программного продукта, поработать в команде в роли программиста, тестировщика, аналитика и руководителя проекта. Условия интенсива максимально приближены к реальным задачам IT-компании. Программа охватывает 7 направлений: Web Java, Android Java, Frontend (Java Script), SDET (Java), C# Desktop, QA и аналитика.

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

Проблема с отображением картинок возникла с момента появления адаптивности в интернете. Мы хотим, чтобы сайт хорошо смотрелся на любом планшете, телефоне, в портретной или ландшафтной ориентации экрана, а также на супербольших дисплеях 5K. Также на рынке появились Retina-дисплеи с высокой плотностью пикселей (DPI), где обычные картинки выглядят размытыми. Растет доля мобильного трафика, и крупные ресурсы нацелены на экономную загрузку изображений. Рассмотрим, как решают эти проблемы на сайтах Apple, Tilda и блог-платформе Medium.

Делимся опытом модернизации архитектуры веб-портала, позволившей сделать продукт удобным, стабильным и отказоустойчивым: посещаемость выросла с 350 тысяч до 7 миллионов пользователей! История будет полезна тем, кто планирует расширение своего продукта. Для начала разберемся, какие факторы могут помешать работе и развитию веб-портала:

Современная разработка построена таким образом, что каждый участник команды, будь то разработчик, 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 решила большинство проблем, которые мы описали ниже. Так что все моменты, на которые мы обратили внимание, имели место быть в конце весны.

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