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

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

Меня зовут Евгений Домнин, я QA и постараюсь поделиться видением, что делает баг репорт хорошим. Прошу простить за долгое вступление, давайте начнем.

Размер приложения часто играет важную роль в восприятии его пользователями и принятии ими решения о скачивании. Исследования показывают, что чем меньше размер APK, тем выше вероятность его установки и тем реже оно оказывается в списке на удаление. Конечно же, это важно для команды Яндекс Go, так как наше приложение непрерывно развивается.

Для внедрения одной из SDK, основанной на Flutter, мы прибегли к механизму Dynamic Feature Delivery (DFD). Но оказалось, что в русскоязычном сегменте информации о DFD крайне мало, поэтому я решил поделиться нашим опытом работы с этим механизмом на Android с Google Play Feature Delivery Library.

Сегодня мы подробно разберём, как интегрировать механизм DFD в современную архитектуру Android‑приложения с использованием корутинов, а также протестируем загрузку и установку динамического модуля, использующего Flutter.

Привет, Хабр! Меня зовут Станислав Чернышев, я автор книги «Основы Dart», телеграм-канала MADTeacher и доцент кафедры прикладной информатики в Санкт-Петербургском государственном университете аэрокосмического приборостроения.

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

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

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

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

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

А потом высокоскоростной Интернет нас избаловал — мы перестали скачивать файлы и формировать свои собственные локальные библиотеки знаний и контента. Теперь всё лежит на сайтах и в облаках. Зачем что-то скачивать, если всё это моментально доступно по одному клику?

Но, похоже, настало время вернуться к истокам. Всё чаще оказывается, что нужный контент становится недоступным или меняется до неузнаваемости...

Недавно мы опубликовали в блоге перевод статьи о том, как GitHub заменил SourceForge в роли доминирующей платформы для хостинга кода. Но, как справедливо отметил автор оригинала, его мнение основано на открытых источниках и интервью с коллегами. А потом своим ви́дением поделился один из сооснователей GitHub, Скотт Чакон, который «действительно был там». Под катом — перевод его ответной статьи о реальных причинах победы GitHub. 

Привет всем! Это не обычная статья, это целый курс про UX-редактуру от Ozon. Мы с вами разберем, что такое UX-редактура, какие бывают форматы интерфейсных текстов и как их писать качественно, быстро и просто.

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

Этот курс подойдёт тем, кто только погружается в мир UX-редактуры и хочет стать продуктовым редактором. А также тем, кто вынужден писать тексты для приложений, но не умеет (или думает, что не умеет).

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

Всем привет! На связи «Инферит Клаудмастер». Я Милена, технический писатель, и пару месяцев назад уже делилась в статье, как в две руки актуализирую портал документации, чтобы вся информация в нём была актуальная и полезная.

На этот раз хочу рассказать:

- о том, почему ченджлог и роадмап — пользовательская документация,

- о ключевых преимуществах ведения обоих видов документации,

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

В этой заключительной статье мы подробно рассмотрим процесс настройки почтового сервера с использованием Docker и Exim4, Dovecot, PostfixAdmin и RainLoop. Наша цель — создать полностью функциональный и масштабируемый почтовый сервер, который легко управляется благодаря контейнеризации.

Линус Торвальдс как-то написал в своей книге, что создавал Linux для развлечения, но в итоге это привело к революции. Git, его второе творение, также оказалось «случайной революцией» — и сегодня это стандартный инструмент для людей в ИТ. Однако процесс его создания был уже не таким «весёлым» — по крайней мере, для самого Линуса. 

Прошло уже более года с тех пор как я написал статью - Анонимная сеть в 200 строк кода на Go. Пересмотрев её однажды осенним вечером я понял насколько всё в ней было ужасно - начиная с самого поведения логики кода и заканчивая его избыточностью. Сев за ноутбук и потратив от силы 20 минут у меня получилось написать сеть всего в 100 строк кода, используя лишь и только стандартную библиотеку языка.

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

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

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

Я работаю тимлидом направления системного анализа в X5Tech и за все время развития карьеры сталкивалась с большим количеством кейсов проектирования Web систем. IT продукты в большинстве очень динамичны: постоянно изменяются требования, появляются новые, итеративно улучшается пользовательский опыт (по принципу 20% усилий на 80% результата, а остальное доделаем потом).

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

В этой статье предлагаю спроектировать контракт по шагам, и на каждом из них я расскажу про общие рекомендации из копилочки “Полезное”, а также про личные правила и практики, полученные долгим опытом работы над постоянно меняющимися ИТ-продуктами, которые помогут для “дальновидного” проектирования GET REST API.

Всем привет!

Я написал свой сервис знакомств на основе общих лайков. Это альфа версия и альфа анонс.

Ссылка - @RubikLoveRuBot

▍ Предисловие. Флейта хулуси

▍ Дисклеймер

Всем привет! Меня зовут Вадим, я старший разработчик по направлению Flutter в компании STM Labs. В этой статье я хочу поделиться нашим опытом внедрения единой биометрической системы в приложение, написанное на Flutter.