Mobile Pet

2021-02-25 16:23:30 ​​Архитектура Flutter-приложения.
Часть 1. Введение и Vanilla.

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

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

Flutter, как UI-фреймворк, сам по себе диктует некоторые архитектурные правила. Например, он разделяет виджеты с состоянием и виджеты без состояния (мой пост на эту тему). Для виджетов с состоянием должен быть создан отдельный класс - State, который хранит данные представления и может служить для работы с внешними источниками данных. Это означает, что в простых приложениях с небольшим количеством логики Flutter можно юзать "как есть", без архитектурных дополнений. Такой подход получил название Vanilla, он же является самой простой архитектурой для Flutter.

У Vanilla есть один большой плюс - низкий порог входа. Она хорошо подойдет для небольших проектов, а для начинающих Flutter-разработчиков поможет понять тонкости фреймворка. Если для проекта важна гибкость кода и простота масштабирования, Vanilla может не подойти, так как нарушает сразу несколько принципов SOLID. По этой причине я решил не использовать ее и перешел к изучению других возможных вариантов. О них поговорим в следующих постах, не переключайтесь
#development #tortiki_app Открыть/Комментировать

2021-02-16 16:09:18 Я - фанатик

Stack Overflow - популярный сайт для программистов, на котором можно задавать вопросы и отвечать на вопросы других пользователей. За 13 лет существования на сайте накопилась огромная база знаний. Она ежедневно помогает тысячам разработчиков решать проблемы и «спасает» их рабочее время. Помимо системы вопросов-ответов на сайте присутствуют рейтинги, награды и репутация. Если у вас хороший профиль на Stack Overflow, это может помочь при трудоустройстве.

Сегодня я получил свой первый золотой бейдж «Fanatic» на Stack Overflow. Для этого требовалось заходить на сайт каждый день в течение 100 дней. Я пытался несколько раз получить это достижение, но в выходные забывал заходить, после чего прогресс сбрасывался. Потом вспомнил, что есть cron. И вот, сегодня сотый день. По факту не нужно проявлять никаких знаний и усидчивости, которые требуются для получения большинства других наград, всего лишь написать скрипт, который отправляет запрос на сайт и запланировать его запуск через crontab.
#development Открыть/Комментировать

2021-02-12 15:23:40 База знаний

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

Для ведения базы знаний хорошо подходят языки разметки, такие как wiki, markdown. Можно по старинке хранить базу знаний в пошаренных файлах, но гораздо удобнее использовать специализированные web-сервисы, предоставляющие совместный доступ к данным через сайт или приложение. Вот несколько таких сервисов: Atlassian Confluence, Evernote, Notion, XWiki, Slite.

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

При ведении pet-проектов в одиночку также важно хранить некоторые данные в одном месте, иначе можно их попросту потерять или забыть. Я для этой цели использую wiki-странички в GitHub, Bitbucket или в другом хостинге git-репозиториев.
#management Открыть/Комментировать

2021-02-10 14:48:33 Стикеры

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

Лично мне эта затея когда-то казалась детской и бессмысленной. Ну вот серьезно, ты делаешь свою работу - кодишь, тестишь, проектируешь, рисуешь, планируешь, и стикеры на крышке ноута никак не помогут выполнить ее лучше. С этим не поспоришь, но с другой стороны, хочется как-то разукрасить повседневную рутину. Средний возраст сотрудника IT-компаний - 27 лет. По большей части это молодые и творческие люди. Вот и объяснение такому желанию.

А теперь предлагаю собрать небольшую внутреннюю статистику по каналу. Как вы относитесь к стикерам? Крышка вашего рабочего ноута еще девственна или уже давно безнадежно покрыта наклейками?

- нет стикеров
- есть немного
- залепил все крышку

#development #design Открыть/Комментировать

2021-02-04 18:18:19 Конференции

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

К сожалению, из-за пандемии вот уже почти год организаторы не проводят крупные оффлайн-конференции. На смену оффлайну пришел онлайн. И прямо сейчас (4 февраля с 18:00) идет одна очень крутая конференция о Flutter, организаторами которой являются ведущие Flutter-разработчики в России - компания Surf Studio. Тема конференции - «Почему компании всё чаще выбирают Flutter и что это значит для разработчиков». Это значит, что она не только для разработчиков, но и для остальных людей, заинтересованных технологиями кроссплатформенной разработки и их внедрением.

Кидаю ссылку на бесплатную регистрацию. Делаю это это НЕ на правах рекламы, это моя личная инициатива рассказать об этом событии вам. Подключайтесь! Кто прочитает сообщение после окончания, не переживайте, запись будет доступна на youtube.
#development #management Открыть/Комментировать

2021-01-30 11:55:11 ​​Code coverage

Программистов можно мерить. Любой грамотный менеджер задумывается об этом и задается вопросом: какие метрики являются показателем хорошей работы программиста?

Несколько лет назад я работал в аутсорс-команде. В штате на тот момент было примерно 15 программистов. Однажды у нас в офисе над кухонным столом появился экран, на котором выводилась веб-страничка с цифрами, графиками и именами. Эти данные отражали простую статистику коммитов от каждого сотрудника за сутки. Таким образом наш директор открыто мерил программистов по количеству написанных им строк кода. Метрика очень базовая и не всегда информативная, но она уже что-то могла сказать о работе конкретного человека, а её открытость добавляла мотивации.

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

Если над проектом работает несколько человек, то можно смотреть на дельту code coverage после слияния очередной ветки от конкретного человека. Если, например, до слияния code covegare был равен 75%, а после - 65%, очевидно программист добавил много непокрытого тестами кода или удалил существующие тесты. Чтобы избежать подобных слияний, можно добавить ограничение на минимально допустимый code coverage в рамках CI.

------------------

Вчера я настроил подсчет и ограничение на code covegare в своем pet-проекте Tortiki. Если тестами будет покрыто менее 50% кода, то мой github action не позволит слить pull request в master. Также теперь всегда можно увидеть текущий code coverage в readme .

#management #qa #devops #development #tortiki_app Открыть/Комментировать

2021-01-27 16:16:14 GitLab CI и macOS

GitLab - популярное комплексное решение для управления проектами. Включает хранилище git-репозиториев, таск трекер, инструменты для CI/CD, wiki и другие полезные функции. При всем своем удобстве и самодостаточности, GitLab может доставить сложности при настройке CI-пайплайна для мобильного приложения.

Полноценная настройка CI для обеих мобильных платформ (iOS и Android) подразумевает использование macOS для выполнения работ в рамках пайплайна. Но GitLab изначально дает запускать CI-скрипты только на Linux, объясняя это тем, что macOS - проприетарная система, доступная только по платной лицензии, а Linux - свободно используемая. Это не значит, что мы совсем не можем запустить пайплайн на macOS. Все же можем, для этого нам нужно использовать свой mac и специальную утилитку - gitlab-runner. Runner в терминах GitLab - это машина, на которой запускается CI-пайплайн. Утилита gitlab-runner позволит добавить наш mac в список runner-ов проекта и использовать его для нашего пайплайна. Сам mac при этом может стоять у вас в кабинете или можно арендовать удаленный, что будет стоить примерно от 60$ в месяц.

Другая опция - использовать CI-сервис типа Bitrise, CodeMagic и пр. Для небольших проектов это будет стоить меньше аренды мака, но добавит ряд ограничений на время сборки и тестов, а также децентрализует сам процесс. Придется настраивать не только GitLab CI, но и другой CI-сервис и налаживать их взаимодействие. Тут уже решать вам.

В заключение скажу, что для своих мобильных pet-проектов я использую GitHub, потому что он бесплатно выделяет mac для CI. Но часто бывает так, что на крупных проектах разработчикам действительно удобнее юзать GitLab, так как свою основную задачу сбора всего необходимого для разработки в одном месте он выполняет хорошо. Сегодняшний пост как раз был для такого случая.
#devops Открыть/Комментировать

2021-01-20 15:33:00 Собесы

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

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

Возможно ты уже много лет работаешь на теплом месте и думаешь, зачем мне вообще эти собесы? И, ВОЗМОЖНО, проработаешь еще столько же без забот. Но дело в том, что ты никогда не знаешь, что будет завтра. Рынок переменчив, куча разных факторов может затянуть ИТ-компанию на дно, урезать ей бюджет или просто закрыть твой отдел. Опыт собеседований придаст уверенности в завтрашнем дне. Компании частенько идут на дно, а вот хорошие ИТ-специалисты будут нужны еще очень долго.
#development #management Открыть/Комментировать

2021-01-15 16:03:41 Статусы сервисов Apple

Вчера в течение суток многие iOS разработчики столкнулись с отказом работы сервисов App Store Connect и TestFlight. Ошибки возникали в основном при загрузке новой iOS-сборки на тест. Отчеты о них были крайне не информативными:

ITMS-90000: This bundle is invalid - $message.

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

Эта ссылочка может сильно сэкономить время. Если пройдя по ней вы видите, что нужный вам сервис недоступен, то проблема не в вашем коде и не в конфигурации CI, а на стороне Apple. Остается только ждать, когда сервис снова заработает. Можно заняться другой задачей Или выпить кофе
#development #devops Открыть/Комментировать