В новом дайджесте гарнитуры смешанной реальности и разработка для встроенных систем на Swift, реакции ВКонтакте и вымышленные языки, Яндекс Go для незрячих, мобильная безопасность, роботы клинической поддержки и многое другое!

В новом дайджесте навигация в iOS и suspend под капотом, фантастические формулы и сон разработчика, новое пришествие Angry Birds, WWDC 22, старые приложения в Google Play и многое другое.

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

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

Я убежден в двух вещах:

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

В нашем новом еженедельном дайджесте внешние аккаунты для iOS-приложений и опыт KMM в QIWI, конец Dagger 2 и соответствующий выбор оффера, теория разбитых окон в разработке, вакансии, рост доходов приложений и многое другое!

В новом дайджесте визуализация графа билда и OAuth в мобильных приложениях, стартап соло- разработчика и безопасность мобильных приложений, стереотипы тестирования, новый Performance Index, естественный язык и многое другое!

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

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

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

В этой еженедельном дайджесте гибкая навигация и лучшие практики, новый 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.