Наша группа по оптимизации производительности нашла маленькое изменение, которое оказало большое влияние на скорость сборки по всем конвейерам. Мы обнаружили, что установка параметра refspec во время git fetch ускоряет шаг клонирования в 100 раз.

Группа Engineering Productivity отвечает за поддержку инженеров, которые создают и развёртывают программное обеспечение в Pinterest. Наша команда поддерживает ряд инфраструктурных сервисов и часто работает над крупными проектами — перенос всего программного обеспечения на Bazel, создание платформы непрерывной доставки под названием Hermez. Они же поддерживают монорепозитории, куда ежедневно присылают по несколько сотен коммитов, и это ещё не все их задачи.

За карьеру мне приходилось сисадминить в нескольких больших компаниях. Речь о миллионе Linux-серверов и больше. Когда под вашей опекой столько котиков, иногда нужно произвести действия с большой группой. Время от времени — со всеми сразу.

По моему опыту, компании с таким огромным серверным флотом стремятся создавать инструменты для массового управления. У этих инструментов разные названия, но суть примерно одинаковая: заходишь по ssh как рут, запускаешь команду и, возможно, получаешь какой-то код выхода и/или результат.

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

Компания Google «переосмыслила» G Suite как Google Workspace и выродила удивительное семейство разноцветных логотипов вместо всем привычных, узнаваемых, а в случае Gmail — даже культовых — иконок. На их месте появились маленькие радужные капли, которые мы теперь будем изо всех сил пытаться отличить друг от друга на вкладках браузера. Компании любят громко и много разглагольствовать о фирменном дизайне, поэтому в качестве противоядия попробую просто на пальцах объяснить, почему эти иконки такие плохие и почему они не продержатся долго.

Во-первых, я понимаю намерение Google. Они пытаются унифицировать визуальный язык различных приложений в своём наборе. Это может быть важно, особенно для такой компании, которая отказывается от приложений, сервисов, языков проектирования и других вещей, словно сбрасывая балласт с падающего воздушного шара (удивительно удачное сравнение, на самом деле).

В прошлые годы, даже в последние год-два мне иногда попадались новости, что кому-то пришёл счёт или чек на смешную сумму 2 020 202 доллара… и 02 цента.

Если вы такое увидите, то (почти наверняка) это ошибка программирования на COBOL. Большинство программистов COBOL совершают эту глупую ошибку, и я не исключение.

Проблема вызвана тем, как именно мы обычно инициализируем запись. Возьмём такую маленькую программу:

Текстовая строка — один из самых распространённых «типов данных» в программировании. Когда программисты думают о строке, то представляют список или массив символов. Это «достаточно хорошее» приближение, но реальность сложнее.

Символы должны быть каким-то образом закодированы в биты. Большинство строк в интернете, включая этот пост на Хабре, закодированы в UTF-8. Формат UTF-8 представляет «символы» в одном, двух, трёх или четырёх байтах. Это обобщение для стандарта ASCII, использующего только один байт на символ. То есть строка ASCII также является строкой UTF-8.

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

LDM — или load multiple — моя любимая инструкция в ассемблере для ARM. Вот почему.

Во-первых, что она делает. Вот пример:

ldm r4, {r0, r1, r2, r3}

Здесь она принимает базовый регистр (в данном случае r4) и набор регистров (в данном случае {r0, r1, r2, r3}). Загружает последовательные слова из адреса в базовом регистре в регистры из набора. Действие инструкции можно продемонстрировать с помощью такого C-подобного псевдокода:

r0 = r4[0];
r1 = r4[1];
r2 = r4[2];
r3 = r4[3];

История голодного студента с пытливым умом

Не знаю, как вы, а я обожаю пиццу. Особенно если это особые чесночные пицца-палочки Papa John’s. Поэтому я был в восторге, когда после заказа еды навынос получил от них следующее письмо:


Papa John’s (с) Заголовок письма с опросом

Бесплатная еда! Мне определённо нужно было пройти этот опрос…

Как разработчику научного ПО мне приходится много программировать. И большинство людей из других научных областей склонны думать, что программирование — это «просто» набросать код и запустить его. У меня хорошие рабочие отношения со многими коллегами, в том числе из других стран… Физика, климатология, биология и т. д. Но когда дело доходит до разработки ПО, то складывается отчётливое впечатление, что они думают: «Эй, что тут может быть сложного?! Мы просто записываем несколько инструкций о том, что должен сделать компьютер, нажимаем кнопку „Выполнить” и готово — получаем ответ!»

Проблема в том, что невероятно легко написать инструкции, которые означают не то, что вы думаете. Например, программа может совершенно не поддаваться интерпретации компьютером. Кроме того, нет буквально никакого способа определить, завершится ли программа вообще, не выполнив её. И есть много, очень много способов сильно замедлить выполнение программы. В смысле… реально замедлить. Так замедлить, что выполнение займёт всю вашу жизнь или больше. Это чаще всего происходит с программами, которые написаны людьми без компьютерного образования, то есть учёными из других областей. Моя работа — исправлять такие программы.

Люди не понимают, что информатика учит вас теории вычислений, сложности алгоритмов, вычислимости (то есть можем ли мы действительно что-то вычислить? Слишком часто мы считаем само собой разумеющимся, что можем!) Информатика даёт знания, логику и методы анализа, помогающие написать код, который выполнится за минимальное количество времени или с минимальным использованием ресурсов.

Недавно я провёл 600-е собеседование на interviewing.io (IIO). Хотелось бы поделиться опытом, рассказать, как я подхожу к интервью, и пролить свет на типичные проблемы у кандидатов. Каждый интервьюер на IIO индивидуален, поэтому ваши результаты могут отличаться. У нас на платформе сформировалось замечательное сообщество, где каждый работает над улучшением своих знаний, навыков и результатов интервью.

Пробное интервью на interviewing.io

Мы оцениваем людей по трём четырёхбалльным шкалам. Оценка «один» означает плохой результат, а «четыре» — очень хороший. Я обычно вначале даю кандидату три балла, а затем прибавляю/отнимаю очки по мере интервью.

Каждый интервьюер отдаёт предпочтение какому-то одному аспекту. Лично я проявляю некоторую предвзятость в сторону скиллов «общение» («коммуникация») и «решение проблем», которые мы обсудим ниже.

Ключевые моменты

• Вот уже несколько лет нам обещают, что бессерверные вычисления (serverless) откроют новую эпоху без конкретной ОС для выполнения приложений. Нам говорили, что такая структура решит множество проблем масштабируемости. На самом деле всё иначе.
  
• Хотя многие рассматривают бессерверную технологию как новую идею, её корни можно проследить вплоть до 2006 года, когда появились Zimki PaaS и Google App Engine — в обоих случаях используется бессерверная архитектура.
  
• Есть четыре причины, по которым бессерверная революция зашла в тупик: от ограниченной поддержки языков программирования до проблем с производительностью.
  
• Бессерверные вычисления не так уж бесполезны. Отнюдь нет. Однако их не следует рассматривать как прямую замену серверов. Для некоторых приложений они могут быть удобным инструментом.

Выбор будет не между Windows и Linux, а что сначала загружается: Hyper-V или KVM, а уже стеки Windows и Ubuntu будут хорошо совместимы друг с другом.



В последнее время развернулась некоторая дискуссия о том, что Microsoft может в будущем перенести свою операционную систему Windows на ядро Linux.

Я как никто другой знаю о проектах Linux в Microsoft, поскольку работаю в подразделении настольных компьютерных систем в Canonical и помогаю выпустить Ubuntu на WSL (Windows Subsystem for Linux). По работе приходится регулярно общаться со многими сотрудниками Microsoft, которые занимаются Linux и различными проектами с открытым исходным кодом. Мне приходят сводки по продуктам Microsoft и стратегии. Обращаю внимание, что в этой статье только мои личные мысли, я не разглашаю никакой секретной информации.

Поведение планировщика Windows значительно изменилось в Windows 10 2004 без каких-либо предупреждений и изменения документации. Вероятно, это поломает несколько приложений. Такое происходит не первый раз, но эта перемена посерьёзнее.

Если вкратце, то вызовы timeBeginPeriod из одного процесса теперь влияют на другие процессы меньше, чем раньше, хотя эффект ещё присутствует.

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

Эх, fork(). Одни процессы порождают другие. Кажется, у меня есть история об этом.

Форк может потерпеть неудачу. Понимаете? В самом деле, понимаете? Это очень серьёзно. Форк может завершиться с ошибкой. Так же, как и malloc. Нечасто, но когда такое происходит, нельзя просто взять и игнорировать это. Вы должны что-то предпринять в таком случае.

Похоже, всем известно, что fork возвращает дочернему процессу 0, а родителю некоторое положительное число — pid ребенка. Он выдаёт этот номер, который используется позже.

Угадайте, что происходит, когда вы не проверяете ответ на ошибку? Да, вы обработаете "-1" (ошибка форка) в качестве валидного pid.

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

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

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

Итак, попробую привести аргументы против Rust.

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

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

Статья не поможет найти хорошие градиенты или оттенки. Она предназначена для подбора красивых, чётких цветов для различных категорий информации (например, континентов, отраслей промышленности, видов птиц) в линейных, круговых, полосковых диаграммах и так далее.

Работа инженера — сплошное разочарование. Возможно, потому что у нас нет власти, а менеджеры сбрасывают на инженеров все проблемы и ожидают, что они будут решены к вчерашнему дню.

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

Вот общий сценарий, который разыгрывается между инженером и его боссом, инженером-менеджером. Менеджер спрашивает, сколько времени займёт выполнение новой задачи. Бывает, что инженер не делал эту задачу раньше, поэтому честно отвечает, что понятия не имеет. Менеджер не принимает такой ответ — и снова спрашивает. Тогда инженер даёт оценку практически наугад, а босс отвечает: «Это слишком долго». Даже если инженер знает, сколько времени займёт выполнение задачи и даёт реалистичную оценку, менеджер часто отвечает: «Это слишком долго. У тебя есть время до пятницы». Когда инженер спрашивает, как давно стало известно об этой задаче, босс отвечает, что месяц назад. Когда инженер спрашивает, почему он не сказал ему об этом месяц назад, тот просто смотрит на инженера, как будто не понимает вопроса.

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

Для слепых и слабовидящих людей, таких как я, доступность — это не просто слово, это реальный выбор: или мы можем работать с сайтом, или не можем.

Как работают скринридеры

Скринридеры позволяют слепым и слабовидящим людям самостоятельно пользоваться компьютерами, телефонами и планшетами. В большинстве скринридеров работает движок Text To Speech (TTS), который преобразует текст с экрана в речь.

Чёрт возьми, Google, я не хотел снова писать в блог. У меня так много дел. Ведение блога требует времени, энергии и креатива, которые я мог бы использовать с пользой: мои книги, музыка, моя игра и так далее. Но ты меня достаточно разозлил, и придётся это написать.

Так что давай покончим с этим.

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

Полнотекстовый поиск — один из тех инструментов, которые мы используем практически каждый день, когда ищем какую-то информацию в интернете. Full-Text Search (FTS) — это метод поиска текста в коллекции документов. Документ может ссылаться на веб-страницу, газетную статью, сообщение электронной почты или любой структурированный текст.

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

Примечание: самым известным движком полнотекстового поиска является Lucene (а также Elasticsearch и Solr, построенные на его основе).