Однажды Миша Рубанов посмотрел интервью Wylsacom с Анатолием Попко «Как незрячий пользуется iPhone, MacBook и Apple Watch» и понял, что адаптировать приложения для незрячих это важно, и несложно. Начал разбираться как люди пользуются телефоном, как ведут себя отдельные контролы, как строить из этого сценарии, начал адаптировать экраны приложения Додо Пиццы, написал статью про доступность «Voice Control и VoiceOver: как адаптировать приложение для незрячих или неподвижных», потом ещё и ещё, провёл курс. В итоге накопилось столько материала, что его хватило бы на целую книгу.

В Domain-Driven Design выделяют стратегические и тактические паттерны. Например, первые — это Единый язык, а вторые — Агрегаты. Я много раз слышал от коллег, что со стратегией всё понятно, но когда дело доходит до перехода на тактический уровень (до кода) — всё в тумане. Это приводит к некорректным техническим решениям, которые не могут компенсировать даже правильный настрой и близость к бизнесу. Для успеха проекта крайне важно освоить тактические паттерны, особенно Агрегаты. Всё потому, что Агрегаты инкапсулируют в себя почти всю бизнес-логику, это основа вашего приложения. В этой статье я и расскажу про Агрегаты, как они могут помочь и почему важно их освоить. Но...

Раньше я считал, что написать книгу — это история длиной в жизнь. Год назад я бы рассмеялся, если бы кто-то сказал, что к стольки-то годам напишу книгу на 250 страниц. Но с фактом не поспоришь: вот книга «Про доступность на iOS».

Рассказываю, как случайности и хорошая подготовка нашли друг друга.

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

Мы тоже использовали Realm — 3 года подряд. Сначала он помогал, потом раздражал, пару раз выстрелил и в конце чуть не вогнал команду в депрессию. В итоге мы удалили Realm из проекта. Это сложный инструмент — простота интеграции обманчива, а за все удобства придётся расплачиваться.

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

В начале 2019 мы собрали аналитику по адресам в заказах и увидели, что бо́льшая часть клиентов заказывает доставку на одни и те же адреса и не устанавливают отложенное время. Они хотят получить заказ «туда же, куда и в прошлый раз и как можно быстрее». Но сделать это не так просто. Поэтому мы решили поменять флоу оплаты заказа и максимально его упростить именно для таких клиентов. Мы назвали этот проект Бриллиантовый чекаут™ и планировали сделать за 2 месяца. А закончили через 9.

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

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

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

В какой-то момент у нас стало много хотфиксов — стабильно больше половины деплоев на проде были хотфиксы или откаты. Мы решили анализировать каждый хотфикс, чтобы понять причины, найти системные закономерности и устранить их, не допуская два раза одних и тех же ошибок. Как говорил Джейсон Стейтем (Стэтхэм? Стэтэм?): «Не страшно ошибаться, страшно повторять одну ошибку 2 раза». Ну и мы решили не повторяться и внедрить постмортемы. В статье расскажу как мы анализируем хотфиксы и другие критичные проблемы, что у нас получается, а что нет, с какими сложностями столкнулись и как их решали.

8 июня 2009 года Фил Шиллер выступил на WWDC. Всего 36 секунд он неловко говорил о VoiceOver, Zoom, White on Black (с  iOS 6 называется Invert Colors) и Mono Audio. Это были первые реальные специальные функции на платформе iPhone OS, как её тогда называли. Однако, они не произвели большого впечатления — 36 секунд закончились, а потом не было никакой демонстрации или аплодисментов, и Шиллер просто перешел к описанию приложения Nike+.

Но в сообществе людей с проблемами зрения всё было иначе. Казалось, что время остановилось где-то после 1:51:54. Произошло нечто совершенно удивительное, и только несколько человек, казалось, понимали, что это значит.

Я Android-разработчик и хотел бы сам решать, какие задачи мне делать, а какие нет. У вас бывало такое желание? Можно ли так делать на работе? Мой краткий и возможно, интригующий ответ — можно. Ключ к этому — погружение в бизнес.

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

В 2011 году 2 разработчика начали создавать свою информационную систему, чтобы через неё принимать заказы в Додо Пицце. 2 года назад мы рассказывали про раннюю архитектуру Dodo IS здесь и здесь. За это время монолит нашей системы пережил немало изменений, самое значительное произошло в этом году — мы перевели его весь на .NET 6 и переехали в Kubernetes. Переход оказался непростой задачей и длился в общей сложности год.

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

Три года назад я стала продактом. Это приучило меня мыслить в таких понятиях как ЦА и пользовательские сегменты, JTBD, считать метрики и оценивать профит от всего. А ещё легализовало мои мысли о дизайне UX и о том, как можно выпрямлять пользовательские пути в разных сферах жизни человека.

Год назад я завела собаку. С тех пор я много гуляю и ещё больше думаю. Я даже захотела завести телеграм-канал, который назвала бы «Алёна гуляет с Лисёной» и писала бы туда свои мысли с прогулок. Но вместо этого снова ушла гулять, думать и вот до чего додумалась.