Некоторые относятся к спору о выборе первого языка программирования примерно так:



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

Виталий Брагилевский решил поставить точку и на Saint AppsConf представил окончательное решение. После прочтения статьи (или просмотра доклада) вы будете знать, как правильно отвечать родственникам или знакомым, которые узнали, сколько зарабатывают в IT и что удалёнка тут не помеха, и теперь интересуются, с чего же начать.

Я уверен, где-то существует книга «Как подсидеть тимлида». Она передается из рук в руки, из команды в команду и содержит советы типа: «Тимлид никогда не уволится по своей воле, потому что это не работа, а сказка! Его нужно сломать», или «Если ваш тимлид уехал в отпуск, напишите ему, что вам нужно поговорить, когда он вернется. Пусть вместо серфинга думает, что в его отсутствие команда разбежалась», а еще «Саботируйте попытки тимлида внедрить новые полезные рабочие процессы фразой из Agile-манифеста о том, что люди и взаимодействие важнее процессов и инструментов». Иначе просто невозможно объяснить, почему все тимлиды сталкиваются с одними и теми же проблемами и страхами.

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

Android Q — это десятая версия Android с 29-м уровнем API. Одна из главных идей новой версии это концепция edge-to-edge, когда приложения занимают весь экран, от нижней рамки до верхней. Это значит, что Status Bar и Navigation Bar должны быть прозрачными. Но, если они прозрачны, то системный UI нет — он перекрывает интерактивные компоненты приложения. Эта проблема решается с помощью insets.

Мобильные разработчики избегают insets, они вызывают у них страх. Но в Android Q обойти insets не удастся — придется их изучить и применять. На самом деле, в insets нет ничего сложного: они показывают, какие элементы экрана пересекаются с системным интерфейсом, и подсказывают, как переместить элемент, чтобы он не конфликтовал с системным UI. О том, как работают insets и чем они полезны, расскажет Константин Цховребов.

Пятница – самый подходящий день для того, чтобы наконец-то свергнуть власть своего тимлида. Он никогда не решит уволиться по своей воле, потому что это не работа, а сказка. Его нужно сломать и не оставить ему другого выхода. Давайте разберемся, как сделать так, чтобы он пришел к этой мысли самостоятельно!

Взаимодействуя с приложением, мы в определенный момент активируем системную клавиатуру для набора сообщения или заполнения необходимых полей. Сталкивались ли вы с ситуациями, когда клавиатура отображается, а вот поля для ввода сообщения нет или наоборот — клавиатура есть, куда вводить текст, не видно? Баги могут быть связаны как с проблемами внутри конкретного приложения, так и с общими недостатками системной клавиатуры.

Константин Мордань, iOS-разработчик из Mail.ru в своей работе повидал всякое: проанализировав способы управления клавиатурой в iOS, он решил поделиться основными найденными багами и подходами, которые применял для их обнаружения и исправления.



Осторожно: под кат мы поместили много гифок, чтобы наглядно демонстрировать баги. А еще больше примеров вы найдете в видео доклада Константина на AppsConf.

Кажется, что IT-инженерам легко живется. Они хорошо зарабатывают и свободно перемещаются между работодателями и странами. Но это все не просто так. «Типичный айтишник» красноглазит за компьютером со школы, а потом еще в университете, магистратуре, аспирантуре… Дальше работа, работа, работа, годы продакшн, и только тогда переезд. А потом опять работа.

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



Переезд в другой город, страну, континент или планету не так уж прост. Иной менталитет, культура, правила, законы, цены, медицина, а еще надо найти куда переезжать, оффер, жилье, сделать визу… тысячи нюансов. Как не получить нервный тик, а только максимальную выгоду и удовольствие от процесса, расскажет Денис Неклюдов (nekdenis).

По каким причинам люди уезжают, что их ждет там и как выбирать, куда переехать? Как сориентироваться на рынке труда, найти работу, подготовиться к интервью и выбрать самый выгодный оффер. На примере переездов Дениса на Пхукет, в Сингапур, Сан-Франциско и опыта множества других экспатов подготовимся к новым приключениям. Рассказ Дениса — это дорожная карта или чек-лист, который будет полезен всем, кто задумывается о переезде.

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

Когда ввязываешься в Early Access Program, никогда заранее не знаешь, что получится в итоге. Конечно, надеешься, что технология взлетит, а твое приложение опередит рынок и получит порцию пиара на Google I/O. И это неплохая мотивация, чтобы на начальном этапе вместо документации читать исходники, которые к тому же надо качать из секретного архива.

На AppsConf Евгений Сатуров показал, во что может вылиться участие в Early Access на примере разработки приложения с мгновенным запуском, по дороге поясняя все особенности Google Play Instant. В расшифровке его доклада разберёмся, откуда пошли Android App Bundles, при чём тут вообще Dynamic Delivery, познакомимся с новыми Gradle-плагинами, и узнаем, как быть с неожиданностями, которые приготовили для нас разработчики SDK.

Управление продуктом — состоявшаяся дисциплина. На продакт-менеджеров большой спрос, а практических знаний хватает не у всех, поэтому 9 декабря мы проведем профессиональную продуктовую конференцию Product Fest. К её организации и программе мы применяем правило: «Сделать такую конференцию, на которую сами хотели бы сходить».



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

Со стороны пользователя почтовый клиент — приложение нехитрое. Разработчики Яндекс.Почты даже шутят, что в приложении всего три экрана: список писем; отправка письма; экран about.

Но очень много интересного происходит под капотом. Как многие мобильные приложения, Почта использует push-уведомления, чтобы взаимодействовать с пользователями. Как многие iOS-приложения, Почта теряет часть уведомлений в силу особенностей работы Apple Push Notification Service.

Руководитель iOS-группы Яндекс.Почты Ася Свириденко докажет, что даже с учетом ограничений системы, с потерями push-уведомлений можно и нужно бороться, если они критичны для вашего приложения. Для Почты это так, потому что push-уведомления о новых письмах — это то, ради чего пользователь устанавливает приложение. Если же для вашего приложения доставка push-уведомлений не так критична, узнать, какие велосипеды нагородила мобильная Яндекс.Почта, все равно интересно.


Речь пойдет о remote notification, то есть уведомлениях, которые приходят с сервера через APNs (Apple Push Notification Service). Локальные уведомления затрагивать не будем и поговорим о том:

• Как выглядит API для работы с push-уведомлениями. Рассмотрим схему доставки push-уведомлений и то, где в этой схеме могут возникать потери. 
• Как решили бороться с потерями в Яндекс.Почте — об очереди push-уведомлений.
• Как логировать и какие еще сложности могут встретиться.

Адепты функционального программирования любят завлекать новичков обещаниями идеальной выразительности кода, 100% корректностью, лёгкостью поддержки и простотой рефакторинга, а иногда даже пророчат высочайшую производительность. Однако, опытные разработчики знают, что такого не бывает. Программирование — это тяжёлый труд, а «волшебных таблеток» не существует. 

С другой стороны, элементы функционального стиля программирования уже проникли в промышленные языки программирования, такие как Swift и Kotlin. Разработчики этих языков прекрасно знакомы с функциональным программированием, поэтому смогли применить его «в малом», предусмотрев многие, хотя и не все, необходимые компоненты. Чем дальше — тем больше части ФП внедряются в промышленные ЯП, и тем качественнее и полнее реализуется поддержка.

Уметь программировать в функциональном стиле полезно, чтобы упрощать себе работу, и сейчас мы посмотрим, как этим воспользоваться!


Виталий Брагилевский — преподаватель ФП, теории алгоритмов и вычислений, автор книги «Haskell in Depth» и участник комитетов Haskell 2020 и наблюдательного комитета компилятора GHC.

Друзья, это официальное заявление Программного комитета!

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

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

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

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

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

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

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

General-трек, чтобы сделать следующий шаг по карьерной лестнице.

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

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

Добавьте к этому оборудованные дискуссионные зоны, чтобы задать множество важных вопросов спикерам. А ещё мы услышали ваш фидбек и увеличили интервалы между докладами. Таким будет следующий AppsConf, если совсем коротко. А подробно, что, как, зачем, сейчас расскажу. Но сначала когда — 21–22 октября в Санкт-Петербурге.

Всем привет! Меня зовут Егор Толстой, я руковожу кластером App Platform в Авито. Мои команды в основном занимаются разработкой внутренних продуктов, инструментов и процессов — тем, что принято называть платформенной разработкой.

Год назад я рассказывал в этом блоге, как мы внедрили и используем performance review. Тогда я упоминал, что мы смотрим на него как на индикатор пользы, которую приносит компании каждый отдельный человек. Понимать это важно и полезно. Это помогает ответить на вопрос «насколько Вася молодец по сравнению с Петей?» и определить, какую премию кому выплатить. Но когда мы переходим на уровень команд, всё становится сильно интереснее. Здесь важно оценить конкретный результат команды и его влияние на успех компании. Высокое среднее значение перфоманса всех членов команды совсем необязательно значит, что команда достигла крутых результатов. Какая-то корреляция точно присутствует, но для оценки фактического вклада команды в успех компании этот инструмент использовать нельзя.

Для решения этой и ряда других проблем мы в Авито используем метод OKR — Objectives and Key Results. Он позволяет установить дерево понятных и легко измеримых целей во всей компании, связать результаты различных команд друг с другом и добиться достижения желаемых результатов.

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

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

Во всяком случае, так говорит руководитель мобильной разработки Prisma Андрей Володин. А еще о том, как идеи перетекают в мобильную разработку из GameDev, чем отличаются парадигмы, почему в Android нет нативного размытия — да много еще чего, продуктивный вышел выпуск AppsCast. Под катом поговорим про доклад Андрея на AppsConf без спойлеров.

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



Написав код, вы должны убедиться, что он:

1. Работает.
2. Ничего не ломает, в том числе код, который написали ваши коллеги.

Если оба условия выполняются, то вы на пути к успеху. Чтобы легко проверять эти условия и не сворачивать с выгодного пути, придумали Continuous Integration.

CI — это рабочий процесс, при котором вы как можно чаще интегрируете свой код в общий код продукта. И не просто интегрируете, а еще и постоянно проверяете, что все работает. Так как проверять нужно много и часто, стоит задуматься об автоматизации. Можно все проверять на ручной тяге, но не стоит, и вот почему.

В рамках проекта АйтиХайп мы записали видеоинтервью с Андреем Станкевичем, легендарным тренером команды университета ИТМО по спортивному программированию, которая стабильно из года в год побеждает всех подряд на международных соревнованиях.

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

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



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

Latency Numbers Every Programmer Should Know — таблица «задержек, которые должен знать каждый программист». Там собраны средние значения времени для выполнения базовых операций компьютера в 2012-м году. Для этой таблицы есть несколько альтернативных представлений и вот одно из них.


Ссылка на источник схемы

Но какая польза мобильным разработчикам от этой информации в 2019? Кажется, что никакой, но Дмитрий Куркин (SClown) из команды Яндекс.Навигатора задумался: «А как бы таблица выглядела для современного iPhone?». Что из этого получилось, в переработанной текстовой версии доклада Дмитрия на AppsConf.

Для чего это нужно?

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

Привет мобильным разработчикам Хабра. Завтра мы заканчиваем прием заявок на AppsConf 2019 и, кажется, самое время рассказать, кто те люди, которые приготовят для вас мегапрограмму самой полезной конференции по мобильной разработке.

Программный комитет у нас большой, потому что нужна целая команда экспертов по iOS и Android, и потому что больше суммарного бэкграунда и разных точек зрения — лучше, меньше субъективного хайпа и тем, широко известных только в очень узких кругах. Я уже рассказывал про то, как мы работаем с заявками, и знакомил вас с некоторыми членами ПК. Сегодня представлю вам еще четверых. Место работы, должность и базворды ключевых интересов, говорят только то, что они все разработчики с приличным опытом, а вот короткое несерьезное (на само деле с важными вопросами) интервью, мне кажется, лучше подскажет, какую конференцию сделают эти люди.



Итак, вопросы для всех одинаковые: iOS vs Android, мобилки vs веб; инстурменты мобильного разработчика; мысленные эксперименты путешествия во времени; технологические лидеры и источники новостей в индустрии. А ответы разные, кроме того, что совсем никто не хотел бы вернуться в прошлое и отговорить себя от мобильной разработки — но это нам же лучше.

Спойлер: самый популярный инструмент, без которого не обойтись мобильному разработчику — терпение.

А за остальным — прошу под кат.