Среди Android-разработчиков Артём Зиннатуллин пользуется таким уважением, что про него можно сочинять аналог «фактов о Чаке Норрисе» — что-нибудь такое:

• Артём так суров, что при его виде гитхаб сам зеленеет (кто из нас может похвастаться таким графиком contributions?)
• Артём так суров, что для него git — это мессенджер.
• Артём так суров, что в его приложениях context — это подкаст.

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

Как жить с проектом на миллион строк кода? В чём недостаток корутин Kotlin? А в чём неправ Google? Чем разработка в Сан-Франциско отличается от российской? Чему был посвящён доклад на Mobius? Под катом — обо всём этом.

Итак, с презентацией Google первой стабильной версии Flutter, которая случилась 4 декабря 2018 г. начался процесс изменения ландшафта на полях мобильного программирования. Появился новый игрок, способный изменить правила самой игры. Теперь из одной базы кода можно создавать сразу два нативных (т.е. «родных» для среды выполнения) приложения — для iOS и Android. В отличие от т.н. гибридных приложений, которые под капотом используют JavaScript, приложения созданные на Flutter работают быстро и плавно, поскольку код написанный на языке программирования Dart (для тех кто знаком с Java или C# с этим языком будет комфортно) затем компилируется (AoT, т.е. предварительно) в машинный код: отдельно для Android, и отдельно для iOS.

Поэтому, если вы изучите Dart и Flutter, вы сможете писать нативные приложения для двух самых популярных мобильных операционных систем, т.е. быть одновременно Android и iOS разработчиком. И это, вероятно, ещё не предел, поскольку было объявлено, что Google ведёт работу по расширению Flutter на предмет возможности создания с его помощью приложений для Windows, Mac и Web (проект Flutter для Web носит название Hummingbird — Колибри). В итоге может получиться так, что зная Dart и Flutter вы сможете писать всё очень многое. Поэтому многие IT эксперты назвали 2018 год — годом Flutter.

Представляем вашему вниманию перевод статьи Scott Domes, которая была опубликована на blog.bitsrc.io. Узнайте под катом, почему компоненты должны быть как можно меньше и как принцип единственной ответственности влияет на качество приложений.


Фото Austin Kirk с Unsplash

В 2017-2019 годах можно было наблюдать серьёзный рост TypeScript. Происходило это по вполне понятным причинам. В этом языке есть много хорошего. Почти половина респондентов исследования State of JavaScript 2018 года уже пробовали TypeScript и собираются писать на нём в будущем. TypeScript весьма популярен, но стоит ли использовать его в крупномасштабных программных проектах?



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

Долгожданные записи докладов с последнего питерского DevFest 2018. Внутри много про Android, много про Web и кое-что ещё.

Колодой, если верить писателям, раньше называлась «команда», которую набирал себе вор. У каждого человека в команде была своя «масть» — специализация и назначение. Вот что пишет об этом Борис Акунин в книге «Любовник смерти»:

«Пацаны рассказывали, что у настоящих деловых, кто по законам живет, шайка „колодой“ называется, и в каждой колоде свой кумплект. Кумплект — это восемь фартовых, каждый при своем положении. Главный — »король"; при нем маруха, по-деловому «дама»; потом «валет» — вроде как главный помощник; ну и прочие бойцы, от десятки до шестерки. А больше восьми человек в шайке не держат, так уж исстари заведено."

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



Как ни странно, тот же Джефф Сазерленд, один из авторов скрама, называл похожие цифры — от 5 до 9 человек. Хотя и не уточнял специализацию.

Ну да ладно. А мы продолжаем тему построения команд по ролям, на основе тестов Белбина.

Совсем недавно я открыл для себя Flutter – новый фреймворк от Google для разработки кроссплатформенных мобильных приложений – и даже имел возможность показать основы Flutter человеку, который никогда не программировал до этого. Сам Flutter написан на Dart – языке, родившимся в браузере Chrome и сбежавшим в мир консоли –  и это навело меня на мысль "хм, а ведь Flutter мог вполне бы быть написан на Go!".

Ведь почему нет? И Go и Dart созданы Google, оба типизированные компилируемые языки – повернись некоторые события чуть иначе, Go был бы отличным кандидатом для реализации такого масштабного проекта, как Flutter. Кто-то скажет – в Go нет классов, дженериков и исключений, поэтому он не подходит.

Так давайте представим, что Flutter уже написан на Go. Как будет выглядеть код и вообще, получится ли это?

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

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

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

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

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

Чтобы это объяснить, придется рассказать небольшую часть своей биографии.

Кто из нас не косячит? Я регулярно встречаюсь с ошибками в асинхронном коде и делаю их сам. Чтобы прекратить это колесо Сансары делюсь с вами самыми типичными косяками из тех, которые иногда довольно сложно отловить и починить.

Привет, Хабр! Представляем вашему вниманию перевод статьи «Using SQLite in Flutter».



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

В этой статье я продемонстрирую как сделать это, используя SQLite, в Flutter-e

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

Привет, Хабр! Представляю перевод статьи, Let me help you to understand and choose a state management solution for your app, которая попалась мне и заинтересовала в процессе изучения азов управления состоянием во Flutter. Буду рад услышать любую критику касательно данного перевода. В обратных кавычках (``) будут написаны мои личные мысли и пояснения.

Решил написать о некоторых вещах, которых, по моему мнению, стоит и не стоит избегать при использовании корутин Kotlin.

Привет, Хабр! Представляю вашему вниманию перевод с англ. статьи Pitching Flutter to your company or client (автор Wm Leler)

С момента публикации статьи What’s Revolutionary about Flutter прошло больше года (и этот материал всё ещё актуален). Когда я писал ту статью, лишь немногие мобильные разработчики слышали о Flutter, но с тех пор многое изменилось. Сейчас я не успеваю следить за потоком новых статей и видео, которые появляются в этом активном и постоянно развивающемся сообществе. Разработчики открыли для себя Flutter, и они от него без ума. Вот пример приложения от Reflectly, созданного с помощью Flutter:


Умное приложение-дневник Reflectly

Разработчик — в среднем человек увлеченный, спорить с этим смысла мало. Объективно, из-за того, что обучение программированию с самой юности отнимает много времени и сил, многие разработчики становятся чуть-чуть похожими на медведей. И сейчас объясню почему.

Медведь — вообще уникальное животное. Одна только система зимней спячки вызывает уважение. Добавить к этому размеры, всеядность и ареал обитания и мы получаем высшего хищника, у которого нет естественных врагов. Любой зоолог скажет вам, что медведь — зверь-одиночка. И как раз в образе жизни в качестве одиночек и кроется основная проблема взаимодействия с медведем: у него практически нет мимической сигнальной системы. Вред медведю в природе может причинить только другой медведь, но они просто расходятся в разные стороны предпочитая тактическое отступление кровавой схватке. То есть уровень эмоциональности этого зверя можно сравнить с эмоциональностью Чака Норриса, посмотрите сами:



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

Под катом — цикл из 3-х видео и текстовых версий к ним.

Главное — стресс вызван не внешними событиями. Причина внутри нас.

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

За последние два года Android-разработчики в Badoo прошли длинный тернистый путь от MVP к совершенно иному подходу к архитектуре приложений. Мы с ANublo хотим поделиться переводом статьи нашего коллеги Zsolt Kocsi, описывающую проблемы, с которыми мы столкнулись, и их решение.

Это первая из нескольких статей, посвящённых разработке современной MVI-архитектуры на Kotlin.

Раньше я очень любил C#

Это был мой основной язык программирования, и каждый раз, когда я сравнивал его с другими, я радовался тому, что в свое время случайно выбрал именно его. Python и Javascript сразу проигрывают динамической типизацией (если к джаваскрипту понятие типизации вообще имеет смысл применять), Java уступает дженериками, отстутствием ивентов, value-типов, вытекающей из этого карусели с разделением примитивов и объектов на два лагеря и зеркальными классами-обертками вроде Integer, отсутствием пропертей и так далее. Одним словом — C# клевый.

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

А потом я из любопытства попробовал F#.

В августе 2018 года Flutter стал самой запрашиваемой кроссплатформенной технологией на Stack Overflow.

В нашем блоге Артем Зайцев и Евгений Сатуров из студии Surf, сертифицированного агентства Google, расскажут, почему и как так получилось:

Кроссплатформенные решения давно привлекают желающих быстро и незатратно запустить MVP-продукт одновременно под несколько платформ. Причина проста — единая кодовая база. Ее легче поддерживать: артефакты централизованы, нет дублирования логики и правок одних и тех же багов под каждую из платформ. Да и людей для ее поддержки и создания требуется меньше — нет необходимости содержать двух нативных разработчиков.

На AppsConf 2018, которая прошла 8-9 октября, я выступил с докладом про создание андроид-приложений целиком в одном Activity. Хотя тема известная, существует много предубеждений относительно такого выбора — переполненный зал и количество вопросов после выступления тому подтверждение. Чтобы не ждать видеозаписи, я решил сделать статью с расшифровкой выступления.

О чем я расскажу

1. Почему и зачем надо переходить на Single-Activity
2. Универсальный подход для решения задач, которые вы привыкли решать на нескольких Activity
3. Примеры стандартных бизнес задач
4. Узкие места, где обычно подпирают код, а не делают все честно