Mobile Pet

2021-07-30 11:19:15 Разные размеры экранов на Flutter

Размеры экранов современных гаджетов начинаются от 4″ и заканчиваются в районе 13″ (хотя бывает и больше). Если писать один и тот же код декларативного интерфейса под все модели, то вы неизбежно столкнетесь с проблемами верстки, вытекающими в плохой UX. Сегодня рассмотрим возможные решения этих проблем и узнаем, как адаптировать наш интерфейс на Flutter под разные устройства.

Смотреть на ширину экрана. Расположение и размеры UI-элементов можно завязать на ширину экрана и в зависимости её значения верстать разные варианты. Flutter легко позволяет узнать размеры экрана из текущего context через MediaQuery. В коде это выглядит вот так:

static bool isMobile(BuildContext context) => MediaQuery.of(context).size.width < 600;

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

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

Смотреть на размеры родителя. Flutter-виджеты вкладываются друг в друга, образуя дерево. Мы также можем установить правила для отображения посмотрев на родительский виджет в дереве и на его размеры. Делается это с помощью LayoutBuilder.

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

Перечисленные правила также актуальны для поддержки браузеров через Flutter Web. Так что если решите писать один код для всего UI на свете, Flutter отлично поможет вам в этом.
#development Открыть/Комментировать

2021-07-15 11:00:13 Источники знаний

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

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

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

Конференции. Помимо просмотра выступлений здесь можно напрямую задать вопросы спикерам и пообщаться с комьюнити. За последние полтора года актуален онлайн-формат.

Подкасты. Дают возможность послушать крутых спикеров стоя в метро или в пробке.

Статьи. Хороший способ изучить интересующий вопрос, потратив на это небольшое количество времени.

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

Соцсети, тематические чаты, q&a системы. Эту категорию с натяжкой можно назвать способом образования, но быстрым способом обсуждения проблем и получения ответов – однозначно.

–––––––––––––
Какие источники знаний используете вы, что для вас заходит и что нет – пишите в комменты Открыть/Комментировать

2021-07-01 10:02:16 GitHub Copilot

Будущее наступило. На днях GitHub и Microsoft анонсировали новый продукт – нейросетевой помощник для разработчиков Copilot. Работает он как обычный автокомплит, только вместо одного слова предлагает закончить за вас сразу несколько строк кода.

Технология функционирует на базе Open AI, нейросеть обучена на огромном количестве строк публичного кода и подходит для большинства фреймворков и языков. Разработчик остается «главным пилотом» и в праве отклонить автозаполнение, выбрать между несколькими предложенными вариантами или отредактировать их для обучения нейросети под себя.

Сейчас продукт находится на стадии technical preview и доступен ограниченному количеству тестировщиков в виде плагина для VSCode. Заявку на тестирование можно оставить по ссылке.
#development Открыть/Комментировать

2021-06-24 15:04:41 Flutter "Widget of the Week"

Flutter на удивление прост в изучении. Этому отлично способствует сообщество и разработчики фреймворка. Кроме известных источников знаний, таких как документация, статьи и github, у Flutter есть официальный youtube-канал.

Если вы хотите быстро понять, как работает тот или иной вииджет, предлагаю вам заглянуть к ним на youtube и найти плейлист Widget of the Week. Он содержит короткие (до 2 минут) видео о работе конкретных виджетов с анимациями, пояснениями и кодом. Лично для меня визуальный контент воспринимается гораздо проще текстового, а главное быстрее. Это хороший способ сэкономить рабочее время.
#development #flutter Открыть/Комментировать

2021-06-16 16:36:44 Комментарии в коде

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

Комментарии делятся на 2 типа – документирующие и поясняющие. Документирующие в основном пишутся при разработке библиотек и фреймворков. Их наличие позволяет программистам, использующим код, понять назначение программных сущностей – классов, переменных, функций и их параметров. Поясняющие пишутся для тех, кто будет поддерживать код в дальнейшем. Их цель – помочь разобраться в коде, алгоритмах и уменьшить значение «WTF в минуту».

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

В итоге по комментариям или по их отсутствию все-таки можно судить о чистоте кода. Эта информация не будет значимой характеристикой навыков разработчика, но на неё однозначно можно обратить внимание.
#development #management Открыть/Комментировать

2021-06-09 15:50:28 Future, async, await

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

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

В Dart и во многих других языках существует удобное средство представления результата асинхронной функции - Future. Этот объект содержит в себе сам результат или ошибку выполнения. С помощью ключевого слова async можно определить функцию, как асинхронную, а слово await останавливает выполнение в ожидании результата асинхронного вызова.

Эти три простых инструмента в совокупности дают возможность писать легко читабельный асинхронный код без использования коллбеков.
#development Открыть/Комментировать

2021-05-26 16:35:08 На языке заказчика

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

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

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

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

-(Заказчик)

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

-(Заказчик)

Умение разговаривать на языке заказчика иногда более важно, чем умение писать гениальный код. Поставьте себя на его место и подумайте, с кем бы вы больше хотели иметь дело – с технически сильным синьором, которого страшно что-либо спросить, или с мидлом, который вас понимает и которого понимаете вы. Думаю, ответ очевиден.
#development #management Открыть/Комментировать

2021-05-19 16:02:46 Нужны ли нам алгоритмы?

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

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

Для сравнения разных алгоритмов используется вычислительная сложность (О-большое). Это величина показывает как быстро растет время выполнения алгоритма в зависимости от размера входных данных. Например, алгоритм пузырьковой сортировки имеет сложность O(n^2), а быстрой – O(n*log(n)). Это означает, что для больших объемов данных лучше использовать быструю сортировку. Я ставлю под сомнение необходимость знания всех алгоритмов сортировки, но они являются очень показательным примером и отлично подходят для осознания темы.

Иногда слышу такое мнение: «мобильная разработка больше про UI, алгоритмы здесь не важны». Отчасти так и есть. Если сравнить её с бэкенд-разработкой, слой логики действительно меньше. Но это не значит, что ее там совсем нет. Она присутствует всегда – преобразование данных, сортировка списков, фильтрация и т.д., и если нанять программиста, который плохо разбирается в алгоритмах, вы рискуете теми самыми быстродействием и стабильностью. Вот почему технические собеседования начинают с этой темы. И именно поэтому разработчикам стоит разбираться в ней.
#development #management Открыть/Комментировать

2021-05-12 16:06:36 ​​Риалтайм и WebSocket

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

Самое распространенное решение – протокол WebSocket (WS). В отличие от HTTP, построенному по модели «запрос-ответ», WS работает полностью асинхронно. Клиент и сервер отправляют сообщения друг другу через созданное соединение, не дожидаясь ответа. Входящие сообщения обрабатываются с помощью подписки на созданное WS-соединение.

Схема работы WS со стороны клиента выглядит так:

создаем соединение:
final channel = IOWebSocketChannel.connect('ws://echo.websocket.org');

для получения сообщений в реальном времени подписываемся на созданное соединение и обрабатываем входящие данные как нам необходимо:
channel.stream.listen((message) => print(‘WS Message: $message’));

для отправки сообщений серверу добавляем данные в этот канал:
channel.sink.add(‘Check Mobile pet!');

для завершения соединения закрываем его:
channel.sink.close();

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

2021-05-05 15:34:56 Junior, Middle, Senior

У программистов и некоторых других IT-специалистов существует общепринятая градация junior-middle-senior. От конкретного уровня, как правило, зависит зарплата и степень ответственности. Некоторые компании вводят больше уровней, некоторые вообще их не делают. По факту их наличие добавляет осознанности как в рабочий процесс, так и в карьеру отдельного специалиста без контекста конкретного рабочего места. Ведь в конечном счете в большинстве вакансий указано, кого хотят нанять – junior, middle или senior-специалиста. Сегодня поговорим о том, что объективно требует каждый из этих уровней.

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

Middle – специалист с багажом опыта в 2-5 лет, способный самостоятельно декомпозировать и выполнить ощутимую задачу, например, написать с нуля сайт или приложение по предоставленным требованиям и дизайну. Может менторить джунов, проверять PR-ы, формулировать для них задачи.

Senior – старший специалист, 6+ лет опыта. По сравнению с мидлом обладает более широкими знаниями в своей области, может реализовать задачи бизнеса разными способами, а главное знает, какой будет оптимальным. При должном уровне soft-скиллов такой специалист может руководить командой разработки.

Приведенные цифры опыта в годах условны, но на деле люди развиваются и так и получается.

А теперь предлагаю каждому из вас оценить свой уровень в соответствии с требованиями выше. Вместе узнаем, какие специалисты подписаны на канал. Если вы не разработчик, попробуйте также оценить себя, переложив требования на свою специальность Голосуйте Открыть/Комментировать