От переводчика:
Начало года — отличное время, чтобы вдумчиво оценить прошедший год. Окинуть широким взглядом происходящее и понять, как сделать 2019 год лучше, спокойнее и продуктивнее. В этом деле нам показалась полезной статья How To Slow Down to Go Faster Than Ever in Software Development, которую написал Lemi Orhan Ergin. А ее перевод мы публикуем ниже.

Github это незаменимый инструмент, прочно вошедший в жизнь практически каждого разработчика.

Хотя многие из нас используют его постоянно, не все знают, что существует большое количество сторонних (и бесплатных) сервисов и инструментов, которые тесно интегрированы с github и расширяют его функциональность.

В данной статье мы уделим внимание, в основном, инструментам, работающим в инфраструктуре npm. Полный список сервисов, интегрирующихся с github, можно посмотреть на странице github integrations directory.

Сегодня в выпуске:

• Настраиваем continuous integration c travis ci
• Настраиваем отчеты о test coverage с coveralls
• Мониторим статус зависимостей с david
• Настраиваем автоматическое обновление зависимостей с greenkeeper
• Улучшаем сообщения коммитов с commitizen
• Генерируем changelog и release notes с conventional-changelog
• Управляем задачами с zube

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с использованием стороннего плагина под названием pglogical.

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



TL;DR

• Всё получилось (не без костылей, о них и статья).
• Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

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

О реализации многопоточности при разработки Android-приложений уже написано немало. В этой же статье хочется провести сравнение нескольких распространенных на сегодня способов скачать/прочитать/сохранить/посчитать, при этом не дав пользователю повода для раздражения. Постараться понять, когда то или иное решение будет уместным, а чего лучше не делать вовсе. Попытаемся показать, почему привычных вещей, таких как класс Thread и пакет java.util.concurrent оказывается недостаточно, когда речь заходит об Android-приложении.

Привет хабр!

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

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

Основной аргумент сторонников — медленно работают неправильные приложения, а вот правильные не должны содержать более 2000-3000 элементов. Если содержит больше значит что-то не так. См. например http://iantonov.me/page/angularjs-osnovy.

Аргумент в общем вполне здравый, но всегда есть ситуации, когда нужно написать «неправильное» web приложение потому, что такие требования. В этой статье мы решили рассказать как раз про такую задачу, и как мы ее решили. На наш взгляд статья будет полезна в большей степени профессиональным веб разработчикам. Итак, наша задача была сделать календарь для системы бронирования для одного спортивного клуба. Календарь отображает семь 12–часовых блоков, каждый день из которых разделен на 15 минутные интервалы. В блоке может быть от 2-х до 10 DOM элементов. Вроде ничего не предвещало беды, верхняя граница ~3000.

В рамках недавно прошедшей конференции DotNext 2018 состоялся BoF по Domain Driven Design. На нем был затронут вопрос работы с исключениями, который вызвал жаркий спор, но не получил развернутой дискуссии, поскольку не являлся основной темой.

Также, изучая множество ресурсов, начиная от вопросов на stackoverflow и заканчивая платными курсами по архитектуре, можно наблюдать, что в IT-сообществе сложилось неоднозначное отношение к исключениям и к тому, как их использовать.

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

Есть разные мнения о том, стоит ли создавать собственные типы исключений или использовать стандартные, поставляемые в .NET.

Кто-то делает валидацию на исключениях, а кто-то повсеместно использует монаду Result. Справедливо, что Result позволяет по сигнатуре метода понять, возможно ли не только успешное выполнение. Но не менее справедливо, что в императивных языках (к которым относится C#) повсеместное использование Result приводит к плохо читаемому коду, засыпанному конструкциями языка настолько, что с трудом можно разглядеть исходный сценарий.

В данной статье я расскажу о практиках, принятых в нашей команде (если кратко — мы используем все подходы и ни один из них не является догмой).

Речь пойдет об enterprise-приложении, построенном на базе ASP.NET MVC+WebAPI. Приложение построено по луковой архитектуре, общается с базой данных и брокером сообщений. Используется структурированное логирование в ELK-стек и настроен мониторинг при помощи Grafana.

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

В наших решениях мы используем интеграцию и с помощью Kafka, и с помощью gRPC, и с помощью RabbitMQ.

В этой статье мы поделимся нашим опытом кластеризации RabbitMQ, ноды которого размещены в Kubernetes.



До RabbitMQ версии 3.7 его кластеризация в K8S была не очень тривиальной задачей, со множеством хаков и не очень красивых решений. В версии 3.6 использовался autocluster плагин из RabbitMQ Community. А в 3.7 появился Kubernetes Peer Discovery Backend. Он встроен плагином в базовую поставку RabbitMQ и не требует отдельной сборки и установки.

Мы опишем итоговую конфигурацию целиком, попутно комментируя происходящее.

В статье мы расскажем о применении свёрточных нейронных сетей для решения практической бизнес-задачи восстановления реалограммы по фотографии полок с товарами. С помощью Tensorflow Object Detection API мы натренируем модель поиска/локализации. Улучшим качество поиска мелких товаров на фотографиях с большим разрешением с помощью плавающего окна и алгоритма подавления немаксимумов. На Keras реализуем классификатор товаров по брендам. Параллельно будем сравнивать подходы и результаты с решениями 4 летней давности. Все данные, использованные в статье, доступны для скачивания, а полностью рабочий код есть на GitHub и оформлен в виде tutorial.
 

Мы продолжаем рассказывать про миграцию мобильного сервиса в ASP.NET Core и Docker. В этой статье будет идти речь про модуль WCF-клиента, упомянутый в предыдущей статье, NTLM-авторизацию и другие проблемы при его миграции. Сейчас расскажем, почему нам пришлось немного изучить анатомию и пощупать .NET Core изнутри.

В этом топике мы хотим поделиться нашим опытом создания мобильных приложений на платформе для разработки кроссплатформенных приложений Titanium. Примерно с 2011 мы начали работы с кроссплатформенными фреймворками. Сначала это был PhoneGap, потом Titanium. Сделали десяток приложений, работающих и по сей день, как в России, так и в США. Мы сознательно хотим отойти от оценок — плохо это или хорошо разрабатывать кроссплатформенные приложения, а сосредоточиться на тех трудностях, с которыми предстоит столкнуться с точки зрения разработки и сопровождения этих приложений.

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

Итак, начнем со списка проблем, с которыми вам придётся столкнуться.

Проблемы:

1. Проблема дабл-кликов.
2. If’ный код.
3. Управление памятью на Android.
4. Недостаточная реализация отдельных функций, в том числе стандартных.
5. Javascript — отсутствие типизации замедляет процесс написания кода и усложняет сопровождение.
6. Отсутствие InterfaceBuilder — замедляет процесс написания приложения, весь UI пишется в коде.
7. Titanium SDK обновляется позже SDK операционных систем.
8. Каждая версия SDK содержит исправление старых ошибок и привносит новые ошибки.

Примеры, на которых мы столкнулись с этими проблемами.

Всем привет! Этим материалом мы открываем цикл из нескольких статей, посвященных длинной истории о том, как мы пришли с одной стороны к CD, а с другой — к high availability, основанной на избыточности.

Начнем по порядку. У нас есть API для мобильного приложения, которое находится в продуктовой среде, написанный на .NET.

И первым шагом мы переводим его на .NET Core и делимся с вами тонкостями, которые встретились нам на этом пути.

Привет, хабровчане! В EastBanc Technologies ведётся большое количество проектов, связанных с мобильной разработкой. В связи с чем необходим целый зоопарк устройств для тестирования на всех этапах. И, что характерно, каждый отдельный девайс постоянно оказывается нужен самым разным людям, а найти его даже в одном отделе мобильной разработки из нескольких десятков человек — это целая история. Не говоря уже о том, что есть тестировщики, дизайнеры, PM’ы, в конце концов!

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

Наш продукт разрабатывается на платформе .Net Core 2.2 с использованием WCF 4.5 для взаимодействия с SOAP сервисом клиента. В процессе работы сервиса разработчики шины данных заметили высокую нагрузку на сервер. Далее стали появляться проблемы с доступом к сервису. В результате выяснили, что причина кроется в количестве активных соединений.

Существует такая проблема как connection exhaustion. Она может возникать из-за нехватки доступных портов при установлении соединения или ограничения на количество соединений с внешним или внутренним сервисом. Есть два варианта решения:

• Увеличение доступных ресурсов,
• Уменьшение количества соединений.

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

Привет, Хабр.

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

Всем привет!

Сегодня расскажем об опыте одного из наших DevOps проектов. Мы решили реализовать новое приложение под Linux с использованием .Net Core на микросервисной архитектуре.

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

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

Поэтому использовали такие технологии:

• .Net Core для реализации микросервисов. В нашем проекте использовалась версия 2.0,
• Kubernetes для оркестрации микросервисов,
• Docker для создания образов микросервисов,
• шина интеграции Rabbit MQ и Mass Transit,
• Elasticsearch и Kibana для логирования,
• TFS для реализации конвейера CI/CD.

В этой статье поделимся подробностями нашего решения.



Это расшифровка нашего выступления на .NET-митапе, вот ссылка на видео выступления.

Мы разрабатываем рабочие инструменты для сотрудников и партнеров заказчика. Большинство созданных нами модулей содержит таблицы, реестры, карточки с детальной информацией.

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

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

Для дизайн-проектирования это ставит нам 2 задачи:

1. Превратить большое в маленькое – перевести объемные списки в мобильное представление.



2. Разработать подход к унификации – унифицировать мобильное представление для разных списков в рамках нашей экосистемы. Чтобы пользовательский опыт был единообразным, вне зависимости от модуля, с которым работает пользователь.

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

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



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

Привет, хабровчане!

Мы вернулись с конференции для .NET-разработчиков DotNext и честно делимся впечатлениями про самые запомнившиеся доклады. Надеемся, наш отзыв пригодится тем, кто будет смотреть видеозаписи выступлений.

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