Из документации Google's Engineering Practices

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

• Стандарт код-ревью
  
• Что проверять в коде
  
• Навигация по списку изменений (CL)
  
• Скорость код-ревью
  
• Как писать комментарии
  
• Как преодолевать сопротивление

См. также Руководство автора CL, в котором даются подробные советы разработчикам, чьи коммиты проходят ревью.

По-прежнему в ходу RC4/3DES/TLS 1.0 и сертификаты на сотни лет. Анализ сотен миллионов SSL-рукопожатий

Если посмотреть на набор данных с 350 млн SSL-соединений, сразу возникает несколько вопросов:

• кто выдал эти сертификаты
  
• какая там криптография
  
• каково их время жизни

Когда я говорю об AWS, то стараюсь быть объективным. Если они сделали что-то хорошее, я рассказываю об этом — и люди мне верят, потому что я обязательно дам знать, когда они сотворят какую-то фигню.

Сегодня такой случай.

26 июля 2019 года Amazon подала в суд на бывшего менеджера AWS за нарушение пункта о неконкуренции в трудовом соглашении. Вот этот судебный иск (pdf).

Поскольку большинство из нас не любят читать юридические документы, позвольте резюмировать: «Филипп Мойер (простой менеджер по продажам) работал в AWS, продавал облачные сервисы. Он уволился и перешёл в Google, чтобы продавать облачные сервисы уже там. Amazon взбесилась и подала иск в Верховный суд округа Кинг, требуя запрета на конкуренцию минимум 18 месяцев, а также выплаты компенсации».

Это советы по улучшению UX ваших проектов БЕЗ многочасовых сессий по изучению пользовательского поведения, бумажного прототипирования или любых других модных словечек.

(Серьёзно, поищите «дизайн-мышление». 100500 результатов!)

Для кого эта статья?

• Разработчики. Вы создали собственное приложение, но каждый пользователь мучается с ним. И вы знаете: если они говорят вам это в лицо, то дело действительно плохо.
  
• Графические дизайнеры. Изучать UX по статьям в интернете — это какой-то… очень болезненный способ умереть.
  
• Менеджеры проектов. Вы уже на четверть UX-дизайнер. Было бы неплохо освоить остальные навыки.
  
• И остальные проходимцы. Все, кто корпит над своими проектами по вечерам и выходным. Вам тоже пригодится.

В этой статье перечислены некоторые трюки, которые применяли участники моего маленького конкурса программирования Commodore 64. Правила конкурса были просты: создать исполняемый файл C64 (PRG), который рисует две линии, чтобы сформировать изображение ниже. Побеждал тот, чей файл меньше по размеру.


Конкурсные работы публиковались в открытых твитах и личными сообщениями, которые содержали только байты PRG-файла и хэш MD5.

До недавнего времени у Dropbox была техническая стратегия использовать общий код C++ для мобильных приложений iOS и Android. Идея понятна: написать код один раз на C++ вместо его дублирования отдельно на Java и Objective C. Мы приняли эту стратегию ещё в 2013 году, когда группа инженеров мобильной разработки была относительно небольшой и приходилось быстро развивать продукт. Такое решение позволило выдавать большой объём кода как на Android, так и на iOS силами маленькой команды.

Теперь мы полностью отказались от этой стратегии в пользу родных языков каждой платформы (в первую очередь Swift и Kotlin, которые не существовали, когда мы начинали). Решение связано с (не очень) скрытыми издержками на совместное использование кода.

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

Протокол Message Queuing Telemetry Transport (MQTT) используется в течение многих лет, но сейчас он особенно актуален благодаря взрывному росту IoT: и потребительские, и промышленные устройства внедряют распределённые сети и граничные вычисления (edge computing), а устройства с постоянной трансляцией данных становятся частью повседневной жизни.

Это означает, что лёгкие, открытые и доступные протоколы со временем станут ещё важнее. В этой статье приводится концептуальное погружение в MQTT: как он работает, как используется сейчас и как будет использоваться в будущем.

Как разработчик, вы услышите много сумасшедших, невероятных теорий о значении «строк кода». Не верьте ни одной. Строки кода — нелепая метрика. В очень редких случаях она что-то говорит, обычно — ничего. Использование строк кода для принятия решений похоже на оценку качества книги по количеству страниц.

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

• Код должен быть последовательным
  
• Код должен быть информативным
  
• Код должен быть хорошо документирован
  
• Код должен использовать стабильные современные функции
  
• Код не должен быть излишне сложным
  
• Код не должен быть неэффективным (не пишите намеренно медленный код)

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

Современная фронтенд-разработка оставляет полярные впечатления: одни её любят, другие презирают.

Я большая поклонница современной веб-разработки, хотя она мне напоминает некую «магию», со своими плюсами и минусами:

• Когда вы поймёте, как использовать волшебные инструменты (babel! бандлеры! вотчеры! и так далее!), ваш рабочий процесс становится быстрым, мощным и восхитительным
  
• Если вы не понимаете волшебные инструменты, всё ужасно запутанно
  
• …и попытки освоить магию слишком часто неудачны, если вам кто-нибудь не поможет продраться через джунгли жаргона, преувеличений и устаревшей информации в интернете

Wine — программа для запуска приложений Windows на компьютерах под Unix.

Запуск Wine на Windows был мечтой фанатов, которые следуют зову сердца «Мы делаем то, что должны, потому что не обязаны это делать», по крайней мере, с 2004 года, когда кто-то попытался скомпилировать Wine в Cygwin и сломал реестр хост-системы.

Оправдание: «А как же старые приложения, которые не работают должным образом в последних Windows?». Но мы-то понимаем, что истинная причина — «Я долго страдал за своё искусство, теперь ваша очередь».

19 июля 2019 года банк Capital One получил сообщение, которого боится каждая современная компания — произошла утечка данных. Она затронула более 106 миллионов человек. 140 000 номеров социального страхования США, один миллион номеров социального страхования Канады. 80 000 банковских счетов. Неприятно, согласитесь?

К сожалению, взлом произошёл совсем не 19 июля. Как выяснилось, Пейдж Томпсон, она же Erratic, совершила его между 22 марта и 23 марта 2019 года. То есть почти четыре месяца назад. На самом деле, только с помощью внешних консультантов Capital One сумела узнать, что нечто произошло.

При слове «криптография» некоторые вспоминают свой пароль WiFi, зелёный замочек рядом с адресом любимого сайта и то, как трудно залезть в чужую почту. Другие вспоминают череду уязвимостей последних лет с говорящими аббревиатурами (DROWN, FREAK, POODLE...), стильными логотипами и предупреждением срочно обновить браузер.

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

За последние годы коллекция криптографических атак превратилась в зоопарк кричащих логотипов, набитых формулами научных статей и породила общее мрачное ощущение, что всё сломано. Но на самом деле многие из атак основаны на нескольких общих принципах, а бесконечные страницы формул часто сводятся к простым для понимания идеям.

Изначально я написала этот документ несколько лет назад, будучи инженером по проверке ядра исполнения команд (execution core verification engineer) в ARM. Конечно, на моё мнение повлияла углублённая работа с исполнительными ядрами разных процессоров. Так что делайте на это скидку, пожалуйста: может, я слишком категорична.

Однако я по-прежнему считаю, что создатели RISC-V могли справиться гораздо лучше. С другой стороны, если бы я сегодня проектировала 32-или 64-разрядный процессор, то, вероятно, реализовала бы именно такую архитектуру, чтобы воспользоваться существующим инструментарием.

Статья изначально описывала набор команд RISC-V 2.0. Для версии 2.2 в ней сделаны некоторые обновления.

Это мой маленький твиттер-тред о видеоадаптерах Lightning, также известных как Haywire, которые на самом деле являются компьютерами с Apple Secure Boot и ядром Darwin.

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

В первой части настроим FreeType и напишем простой рендерер символов в консоли.



Вот что мы будем писать. А вот и код.

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

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

Я постоянно делаю коммиты в проекты open source (Red Hat и др.). И заметил, что больше всего времени отнимают негативные код-ревью, субъективные по сути. Чаще всего такое происходит с коммитами, где мейнтейнеру по какой-то причине не нравится ваше изменение. В лучшем случае такая стратегия код-ревью приводит к потере времени в бессмысленных спорах; в худшем случае он активно препятствует коммиту, создавая враждебную и элитарную среду.

Код-ревью должен быть объективным, кратким и, по возможности, содержать только определённые факты. Это не политический или эмоциональный спор, а технический. Его цель — продвижение вперёд, развитие проекта и всех участников. Любой коммит должен оцениваться только по существу, а не по субъективному мнению.

Давным-давно, когда компьютеры были большими, а бизнес скучным, произошло нечто неожиданное. Молодые хакеры нашли способ собрать персональные компьютеры на дешёвых микропроцессорах от телетайпов и светофоров. Одним из них был Стив Возняк. Эти ребята восприняли ограничения своих компьютеров как вызов, сели и заставили эти крошечные чипы делать удивительные вещи. Вот что публиковал Dr Dobb's Journal в августе 1976 года:



Это набор арифметических процедур на действительных числах. Микропроцессор (6502, такой же, как в Apple I и II) мог работать только с байтами, то есть целыми числами между 0 и 255. Хуже того, он мог только складывать и вычитать их. Но с помощью этой библиотеки вы можете вычислить $$, или даже взять квадратный корень из пи. Удивительно, но автор программы по имени Стив Возняк уместил основные функции (сложение, вычитание, умножение и деление) в 239 байт, используя всего 127 инструкций.

Представьте, что вам нужно сгенерировать равномерно распределённое случайное число от 1 до 10. То есть целое число от 1 до 10 включительно, с равной вероятностью (10%) появления каждого. Но, скажем, без доступа к монетам, компьютерам, радиоактивному материалу или другим подобным источникам (псевдо) случайных чисел. У вас есть только комната с людьми.

Предположим, что в этой комнате чуть более 8500 студентов.

Самое простое — попросить кого-нибудь: «Эй, выбери случайное число от одного до десяти!». Человек отвечает: «Семь!». Отлично! Теперь у вас есть число. Однако вы начинаете задаваться вопросом, является ли оно равномерно распределённым?

Что нынче с HTML во фронтенде? В последнее время я разговаривал со многими разработчиками. Похоже, что некоторые даже не разбираются в HTML. В смысле, кое-что они понимают. Они понимают, что такое div и что такое span, и когда всё выглядит хорошо и работает по щелчку, им этого хватает. До такой степени, что многие на вопрос о HTML отвечают: «О, да я сейчас всё делаю в React или Vue». Но на самом деле не имеет значения, что вы пишете только Javascript. Если вы разрабатываете веб-сайты, то HTML — это самое главное для вас. Это и есть веб.

Речь о том, что потребляется пользователем. Это UI и UX. Вот весь пакет. В порядке убывания важности: HTML, CSS и поведение (которое может быть обеспечено Javascript — а может и нет).

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