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

Я делаю это не для того, чтобы навлечь позор на людей, которые написали что-то не так. Я просто хочу приложить руку к решению проблемы. За время своей работы в AppSec я очень устал от бесконечных однообразных споров. Я делаю всё, что в моих силах, чтобы люди могли без особых сложностей реализовать всё правильно, в частности, указываю на код, который можно использовать смело – например, из репозитория Secure Compatible Encryption Examples от Люка Парка. И, тем не менее, попадаются команды, которые продолжают упорствовать, даже если код еще не ушел в продакшн – а ведь это самое лучшее время для исправления ошибок. Это усложняет всем жизнь: я теряю время на объяснения, что с кодом не всё в порядке, а команде потом приходится делать значительно больше работы, потому что после того как код уходит в продакшн, для исправления криптографии приходится сначала составлять план миграции.

В этой подборке 0-day уязвимости в iOS и скорость сборки для нее же, StoreKit 2 и Swift 5.5, тестовая ферма и правильная валидация для Android, битва снифферов, игры со шрифтами, подготовка к FAANG, релизные циклы и многое другое!

А вы знали, что выражение «выгореть» использовал еще Шекспир в 17 веке? Гораздо позже, в 2019 году ВОЗ дала выгоранию следующее определение: «синдром, который осмысляется как результат хронического стресса в процессе работы, который не прорабатывается должным образом».

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

Менее клиническое определение можно найти в эссе Лэнса Морроу, опубликованном в 1981 году, где он описывает выгорание так: «Болезнь тех, кому преграждают путь… досада настолько глубокая, что от нее истощается тело и дух. На поздних стадиях выгорание вызывает утомление, которое, пока его проживаешь, может казаться близким к смерти».

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

В новом дайжесте новые устройства Apple и автоматизация повышения качества кода, ускорение сборки и Jetpack для Wear OS, 16 советов по UX и UI дизайну, количество приложений на Flutter и React Native, ATT-согласие и многое другое!

В этом выпуске многопоточность Kotlin в iOS и игра в слова, судьба APK и MVVM для Android, первая игра на Unity, траты россиян на социальные сети, умные очки Facebook, худший вопрос разработчику и многое другое!

Нанимать разработчиков – дело непростое: это долгосрочное вложение, их полгода приходится вводить в курс дела и полную отдачу от них получаешь, только если сумеешь удержать на несколько лет. Сегодня на рынке труда идет повальная охота на самых талантливых разработчиков, так что, если хотите быть уверенными, что Facebook, Amazon, Apple, Netflix или Google не начнут обивать пороги ваших сотрудников, нужно остерегаться нанимать слишком способных. Чтобы вам с этим помочь, мы предлагаем несколько советов касательно того, как отсеять лучших из лучших в своем деле и набрать таких, кому больше некуда податься.

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

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

В новом дайджесте подготовка к собеседованию и целая энциклопедия интеропа, новые правила Apple и геолокация без GPS, Bluetooth в качестве сервиса, пероеход в продакт-менеджеры, красота кривых и многое, многое другое!

В этой подборке причины не делать приложение под iOS, послабления от Apple и локализация оценок в Google Play, чистая архитектура на Flutter, тестирование Codex от OpenAI, персональные сказки для детей и многое другое!

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

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

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

В новом дайджесте снова встроенные покупки, будущее Android UI и мобильное вещание, тренировки по алгоритмам и выравнивание текста, 46 приложений в месяц, маркетинг влияния и многое другое!

Google удалил наше приложение Language Transfer с Play Store.

Начнем с короткой предыстории. Когда мы впервые отправили приложение на маркет, его отклонили из-за того, что в интерфейсе была ссылка на страницу Language Transfer на Patreon.



Нижняя кнопка: «Поддержите Language Transfer»

Так как подобный способ привлекать финансирование (для бесплатного продукта с открытым кодом, вообще-то) не позволял Google получать 15% комиссионных, нам не разрешили им воспользоваться. Расклад был для нас паршивый – Language Transfer всегда держался только и исключительно донатами (Михаил на них оплачивает аренду), так сложилось еще до того, как мобильное приложение появилось на свет. Мобильная версия была наилучшим способом распространить наши языковые курсы среди широкой публики, и вот, оказалось, что на ней нельзя разместить ссылку на платформу для сбора средств. Мы не предоставляем никаких дополнительных возможностей тем, кто оставляет пожертвования, это просто способ помочь и поддержать проект. Для некоммерческих организаций, деятельность которых не облагается налогами, Google делает исключение, но Language Transfer – маленький проект, который ведет один человек. Так что если мы хотим донатов, то Google хочет 15% прибыли.

Чтобы задобрить Google, мы поставили вместо ссылок на Patreon ссылки на вебсайт Language Tranfer, чтобы пользователи могли сами ближе познакомиться с проектом. Мы убрали из приложения все фразы о поддержке и пожертвованиях. Эту версию Google пропустил на Play Store, и сейчас, примерно год спустя, продукт собрал около 50 000 установок.

В один прекрасный день Google удалил приложение из Play Store (в своем стиле, без всяких предварительных предупреждений) и приложил к отказу следующие скриншоты:

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

В новой подборке знакомимся с async/await и запускаем первые тесты, делаем первый аккорд в Jetpack Compose и сравниваем его со SwiftUI, участвуем в чемпионатах и решаем проблемы склада с помощью приложения. Все это и многое другое в нашем новом дайджесте!

В этом дайджесте читайте про фоновые задачи в Android 12 и однократные замыкания в Swift, про первый стабильный релиз Jetpack Compose и ускорение я сборок, музыку для инди, различия в покупках на iOS и Android, форменный UX и многое другое!

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

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



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

Если нас в первую очередь интересует качество, можно организовать сеансы парного программирования, что позволит усовершенствовать код. Тогда объем кода не возрастет в той же мере, но мы всё-таки получим выгоду от пополнения в команде в виде более качественного итогового продукта.

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

Firebase от Google – отличное бессерверное решение для разработчиков и компаний. Вообще говоря, мой первый опыт в облаках связан именно с ней. Я тогда писал на Android и только что запустил свой стартап. У меня не было денег на то, чтобы нанять себе в помощь разработчиков, которые занимались бы бэкендом. По этой причине я (и двое моих друзей) искали максимально простое решение для бэкенда. Так я узнал про Firebase.

Firebase представлялся одним из наилучших вариантов в нише «бэкенд как сервис». Освоить ее было очень легко – мне хватило пары дней, чтобы разобраться и начать применять ее в проекте. Изначально мы ставили цель подготовить прототип, посмотреть, как его примут на рынке и собрать побольше отзывов от пользователей.

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

В этой подборке SwiftLint и VSO, панические кнопки и властелины модулей, шутеры без даунтаймов и масштабируемые команды, ускорение билдов, открытый Lumberyard, миллиарды Pokémon GO и многое другое!