Понятие «долг» существует уже несколько тысяч лет. Вы берете у кого-то деньги. Тот, кто дал деньги, начисляет процент, пока вы их не вернете. Всё просто. Не так давно в сообществе разработчиков ввели термин, который описывает другой тип долга – технический. Технический долг подразумевает, что за ситуацию, когда разработчик срезает углы (или последовательно вносит в код много изменений), приходится расплачиваться в будущем.

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

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

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

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

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

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

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

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

Термин «догфудинг» (буквально: «поедание своего собственного собачьего корма») обозначает практику, когда компания использует в работе свои собственные продукты. Есть и более аппетитные выражения, например, «пьем собственное шаманское», «едим то, что сами приготовили». В некоторых компаниях такую практику описывают как принятие роли «нулевого клиента». Вне зависимости от названия, цель регулярного использования самодельных продуктов состоит в том, чтобы стать их первым и самым ценным пользователем, активнее собирать обратную связь от аудитории и быстрее вводить инновации.

Идея применения созданных продуктов внутри компании не нова. Всем хорошо известна история о том, как в начале 2000-х Джефф Безос разослал по всей компании распоряжение, согласно которому все команды Amazon обязаны были «представлять свои данные и функциональность через интерфейсы сервиса» и взаимодействовать друг с другом также при помощи этих интерфейсов. Он добавил, что прямой доступ к базам данных и любые другие способы получения данных напрямую из источника теперь под запретом. Это знаменитое распоряжение заканчивалось словами: «Все нарушители будут уволены. Спасибо и хорошего дня».

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

Наш новый дайджест за прошедшую неделю с обсуждением уязвимости в iOS, тенями в Android и множеством других материалов.

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

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

На мой взгляд, Google Play – лучшая платформа для распространения приложений. Но вместе с тем, ее руководство плохо справляется с очень важной проблемой – пользовательской поддержкой для разработчиков.

Существуют и другие сервисы Google – например, Admob или Google Ads. И когда у меня возникают трудности со, скажем, Google Ads, я могу быстро связаться с администрацией и получить помощь. Чтобы улучшить что-то в рекламной кампании, не нужно даже к ним обращаться, они сами присылают письма, где напоминают, что сотрудники поддержки к моим услугам. Был случай, когда мне даже довелось пообщаться с очень приятной женщиной по Google Meet.

Если же с проблемами сталкивается разработчик с аккаунтом на Google Play, всё происходит совсем иначе. Приходится довольствоваться текстовым полем, а в ответ неизменно получаешь письма, составленные по шаблону – обсудить свою проблему с человеком практически нереально.

В новом выпуске ускоряем прохождение UI-тестов и заведуем стейт-машинами, внедряем платежи и готовим открытый API для UWB, разбираем кроссплатформу, перепридумываем иллюстрации, делимся виджетами и многое другое!

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

Разработчики день-деньской смотрят на код. Разве не стоит попытаться усовершенствовать этот опыт, чтобы продуктивность возрастала? Существует большое количество шрифтов, которые служат именно этой цели. К самым популярным относятся Fira Code, Source Code Pro, Jetbrains Mono и Ubuntu Mono, но это только несколько примеров – есть еще множество других.

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

• Проще замечать баги
• Быстро находятся переменные и функции
• Легко опознаются специфичные для программирования символы
• Снижается нагрузка на глаза

Ну и смотрятся они здорово, а это разве плохо?

В нашем новом дайджесте приключения белорусских разработчиков в App Store, один iOS-техрадар и несколько трендов Android-разработки 2022, игра мечты, автоматическая модерация сообщений и многое другое!

В декабре я взял Tesla 3 напрокат у друга. Примерно через пять минут после начала поездки у машины стало запотевать лобовое стекло. На большом экране с панелью управления, которыми так славятся автомобили Tesla, мне не удалось найти опцию «обогрев стекла». В отчаянии я стал нажимать на иконку CAR, но меня перекинуло на экран настроек, с которого никуда больше нельзя было перейти. Перебирая все подряд кнопки на руле, я случайно перешел на голосовое управление, и тогда наконец сумел включить обогрев стекла. Опыт был такой необычный, что я написал о нем в Твиттере:



У меня только что состоялась первая поездка на Tesla (отстаю, да). У центральной панели на удивление плохой UX-дизайн. Никак не мог найти антизапотеватель. В итоге пришлось перейти на голосовое управление, только тогда появилась иконка климат-контроля. Это очень опасно.

Я и не знал, что машины Tesla перешли на новый интерфейс буквально за несколько дней до этого происшествия. Обновление вызвало немало споров: UX-дизайнер зашел в бар Tesla и наступил прямиком в осиное гнездо.

В новом дайджесте трудности перевода приложений и импакт-анализ, Force Update и тренды Android-разработки, шрифты в играх и история игрового композитора, экраны загрузки, использование приложений, GitHub Actions и многое другое!

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

Неопределенность может порождаться тем, что нам не всё известно о технологии, о бизнесе, о пользователе, объеме данных в системе, продолжительности жизни кода, а также другими неизвестностями, о которых мы даже не подозреваем (за расширенным списком примеров обратитесь к 2020 году).

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

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

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

Для начала представлюсь тем, с кем мы незнакомы: я системный администратор на Linux и также много работаю с кодом, в основном для собственного удовольствия. Среди моих личных проектов есть и приложения на Android, самое популярное из них называется Catima. Catima доступна только на Google Play и F-Droid и, вероятно, в обозримом будущем останется экслюзивом для этих платформ.

Вы спросите: «Но почему твое приложение не продается в других магазинах, например, Samsung Galaxy Store, Amazon AppStore или Huawei App Gallery? Что тебя в них не устраивает?». Мой ответ, возможно, вас удивит: я не размещаю свое приложение в других магазинах не из-за проблем с ними, а из-за проблем с Google Play. Публикация на этом маркете отнимала у меня столько сил и времени, что на другие уже не оставалось. Сейчас страсти немного улеглись, и я, наверное, обдумаю вопрос о привлечении дополнительных площадок. Только сначала удостоверюсь, что не на всех творится то же самое, что и на Huawei App Gallery.

В новом дайджесте годовой определяющий отчет State of Mobile 2022 от App Annie о рынке мобильных приложений, советы по разработке игр от Сида Мейера, тренды разработки и UI/UX, борьба Apple с клонами (да) и мошенниками (нет) и многое другое!

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



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

Очень, очень сжатая история pull request-ов

Pull request-ы появились в мире открытого кода и были необходимой мерой. Нужен был какой-то способ контролировать вклад от участников проектов со всего мира. В GitHub создали соответствующее решение для тех, кто работает с открытым кодом, а вскоре Git получил широкое распространение в корпоративном мире, несмотря на то, что большая часть его пользователей работала в офисе. Впрочем, сейчас круг замкнулся, и мы стали массово уходить на удаленку. Получается, pull request-ы стали актуальны, как никогда прежде? Возможно.

Однако рост популярности pull request-ов означает, что возникает новое препятствие между нашим кодом и слиянием/релизом. Раньше сотрудники просматривали код друг друга непосредственно в кабинете – в процессе парного программирования или синхронизированной проверки. Закончили – внесли код в проект. Сейчас pull request-ы по большей части проходят процедуру одобрения асинхронно, с многократной пересылкой файлов туда-сюда. По этой причине в процессе возникают периоды простоя, которых не было раньше.

Первый наш дайджест про мобильную разработку в новом году — частично с новостями и статьями из прошлого. Поздравляем вас с новым годом и рассказываем про async/await, Qt, Fleet, бесплатные ресурсы и многое другое!

Если вкратце: я открыл бизнес, чтобы дать людям возможность создавать сайты на бумаге. По ходу дела я завирусился на Твиттере, заработал тысячу долларов за два дня и просадил 720 долларов на сотню блокнотов с Alibaba.

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

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

Так можно ли делать сайты на листе бумаги? Я решил, что, по крайней мере, стоит попробовать.

В последнем нашем дайджесте в этом году использование языков в приложениях iOS 15, парковка магнитолы по гайдлайнам Гугла и укрощение батчинга, исходники Telegram, отказ от модульного тестирования и многое другое! С наступающим Новым Годом!