Наша история начинается с твита Томаша Лакомы, в котором он предлагает представить, что такой вопрос встретился вам на собеседовании.



Мне кажется, что реакция на такой вопрос на собеседовании зависит от того, в чём конкретно он заключается. Если вопрос действительно в том, каково значение tree, то код можно просто вставить в консоль и получить результат.

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

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

Удивляясь красоте какой-нибудь микросхемы, невольно думаешь: как же это сделано? Давайте посмотрим на каждый шаг в производственном процессе.

RAD Studio состоит из Delphi и C++Builder. Компилятор Object Pascal в Delphi является однопроходным компилятором, и сам компилятор не является параллельным, однако при компиляции нескольких проектов параллельно он оказался способен скомпилировать 1 миллиард строк кода Object Pascal за 5 минут на машине с 16-ядерным AMD Ryzen 9 5950x. Я хотел выяснить, возможно ли сделать что-то подобное для C++. Этот пост является частью серии статей, в которой мы исследуем значительный прирост производительности, которого можно достичь на самых быстрых на начало 2021 года процессорах. Сколько это — 1 миллиард строк кода? Взгляните сюда.

Популярная шутка утверждает, что наши дети воспримут 3,5-дюймовую дискету как распечатанный на 3D-принтере значок сохранения. Действительно, растёт поколение, не знающее объекта, с которого срисовали эту пиктограмму.

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

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

Больше десятка лет я работал на одну из крупнейших в мире компаний по разработке ПО. Выполняя множество задач, я видел многие аспекты бизнеса: от быстрого «ковбойского» кодинга до серьёзных покупок конкурентов и стартапов.

1. Планёрки

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

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

Однако митинги и сосредоточенность — настоящие враги. Я уже сбился со счёту, сколько раз мой планировщик отвлекал меня, сообщая, что через 15 минут мне нужно явиться на планёрку, пока я пытался разобраться в сложной концепции, которую недавно придумал. Разумеется, я заранее знал, что будет планёрка. Когда я смотрел своё расписание в понедельник, чтобы оценить время, которое у меня будет на написание кода на этой неделе, у меня не было никаких сомнений: мои рабочие дни заполнены совещаниями.

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

И знаете что? Эти знания в основном передаются на совещаниях. Поймите меня правильно, само по себе это хорошо.

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

Настала пора ещё одного совещания.

Примечание: полный исходный код проекта можно найти здесь.

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

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

Любитель головоломок

Джеральд Селби всегда любил загадки: там, где другие видели лишь шум, он стремился найти порядок и гармонию. Работая на фабрике Kellogg's по производству овсяных хлопьев, он занимался анализом материалов для увеличения срока годности продукции. Однажды, изучая хлопья других компаний, Джерри наткнулся на странную последовательность символов на обороте коробки General Mills. Вместо даты и фабрики-производителя там был отпечатан загадочный код. Джерри решил расшифровать его: взяв несколько коробок завтраков Kellogg's и General Mills, он начал сравнивать их влажность, сообразив, что хлопья с примерно одинаковой влажностью должны иметь близкие даты производства. Делая записи на бумаге, он выявил некоторые закономерности. Вскоре ему удалось расшифровать всё, что позволило определить место, дату и время изготовления. В более агрессивной сфере бизнеса «взлом» секретов конкурентов мог бы обернуться огромной выгодой, но не в производстве овсяных хлопьев, поэтому руководство восприняло его открытие без энтузиазма.

В мире, где роутеры всё больше напоминают перевёрнутых пауков, чем предметы, которые бы хотелось видеть в своей гостиной, есть только несколько устройств, которые можно было бы назвать «знаменитыми». Примерами подобного могут быть AirPort Стива Джобса и mesh-роутеры Eero. Но лавры победителя в этой категории получает модель роутера Linksys, которой уже исполнилось почти 20 лет, и всё благодаря изначально незадокументированной особенности, ставшей чрезвычайно популярной у определённой пользовательской базы. Сегодня мы поговорим о сине-чёрном образце маршрутизатора беспроводного доступа — Linksys WRT54G. Именно этот роутер показал миру, на что должны быть способны беспроводные маршрутизаторы.

1988 год

Linksys был основан двумя иммигрантами из Тайваня Джени и Виктором Цао в 1988 году. По информации в профиле 2004 года на Inc., компания задумывалась как посредник между изобретателями и производителями на рынке Тайваня, но в 1990-х сама занялась производством оборудования, со временем придя к рынку домашних сетей и начав доминировать на нём в начале 2000-х.

Слева — старое приложение, справа — декабрьская версия от южнокорейцев. Источник: «Смерть MAPS.ME?»

В ноябре 2020 года Mail.Ru Group продала MAPS.ME южнокорейской компании Daegu Limited (входит в состав платёжной системы Parity.com), и уже 20 декабря 2020 года новые владельцы выпустили обновление, которое практически убило приложение.

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

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

Недавно благодаря предсказательной мощи машинного обучения (machine learning, ML) мы обеспечили экономию 1,7 миллионов долларов в год на инфраструктурных тратах, оптимизировав процесс генерации и кэширования превью документов Dropbox. Машинное обучение и раньше применялось в Dropbox для таких хорошо известных функций, как поиск, рекомендации файлов и папок, а также OCR при сканировании документов. Хоть и не все сферы применения ML непосредственно видны пользователю, они всё равно изнутри влияют на развитие бизнеса.

Что такое превью?

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

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

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

Рассматриваемый в статье способ — просто один из многих.

Сама по себе конструкция if-else не так уж плоха. Мы просто попали в ситуацию «когда в руках молоток, всё вокруг кажется гвоздями». В основах программирования мы изучаем условные операторы и многим разработчикам не удаётся перерасти их использование.

Однако if-else и switch зачастую неидеальны. Программисты обычно пренебрегают более качественными решениями, например, полиморфическим исполнением и словарями.

Федеративная система Matrix поддерживает связь с другими сетями через мосты. Это пример инфраструктуры, к которой нужно стремиться Signal

4 января 2021 года WhatsApp внёс изменения в пользовательское соглашение. Теперь каждый пользователь обязан согласиться на отправку личных данных в материнскую компанию Facebook, иначе его аккаунт WhatsApp просто заблокируют. Эффект от изменений был вполне предсказуем — миллионы человек массово ушли из WhatsApp. Прежде всего, в Telegram и Signal.

Павел Дуров назвал это «крупнейшей цифровой миграцией в истории»: всего за трое суток у Telegram появилось 25 млн новых пользователей, абсолютный рекорд. Илон Маск в твиттере прокомментировал события просто: «Используйте Signal», — написал он. То же самое советует Эдвард Сноуден. Мессенджер Signal для многих стал настоящим открытием.

Mac всегда отличался от своего близкого родственника iOS, особенно в отношении того, что пользователю можно и нельзя запускать в своей системе. Даже после появления Apple Silicon компания Apple чётко дала понять, что Mac остаётся Mac, и его по-прежнему можно хакать, даже при запуске на новой архитектуре.

Для программистов это значит, что при разработке для платформы Mac у нас есть выбор: мы можем распространять приложения независимо, за пределами Mac App Store, только через Mac App Store или сочетать оба варианта.

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

App Store и прямое распространение: плюсы и минусы

Все эти варианты имеют свои достоинства и недостатки. Начнём с того, что некоторые приложения для Mac просто невозможно будет распространять через Mac App Store. Примером этого может послужить моё приложение AirBuddy, которому для обеспечения глубокой интеграции с беспроводными устройствами Apple необходимо запускать системный агент и использовать приватные API, что в App Store запрещено. То же самое относится и ко многим другим видам приложений, которые просто не смогут работать в условиях ограничений «песочницы» Mac.

Для тех же, у кого выбор есть, я составил список плюсов и минусов выпуска в Mac App Store или независимого распространения.

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

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

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

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

Хоть и непривычно ожидать решения с XOR на собеседованиях, довольно забавно разбираться, как они работают. Оказывается, все они основаны на одном фундаментальном трюке, который я постепенно раскрою в этом посте. Далее мы рассмотрим множество способов применения этого трюка с XOR, например, при решении популярной задачи с собеседований:

Дан массив из n — 1 целых чисел, находящихся в интервале от 1 до n. Все числа встречаются только один раз, за исключением одного числа, которого нет. Найдите отсутствующее число.

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

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

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

Если я скажу, что тот или иной член команды халтурит, и даже объясню всё вежливо и с техническими подробностями, менеджеры воспримут это как «ссору» и сосредоточат всё своё внимание на сплочённости коллектива, подразумевая, что проблемы создаю именно я.

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

10 декабря 2020 года состоялся релиз долгожданной игры Cyberpunk 2077, а за день до этого вышла новая версия Proton 5.13-4 с поддержкой Cyberpunk 2077. То есть пользователи Linux смогли играть в Cyberpunk 2077 с первого же дня. Это наглядный пример, насколько великолепная ситуация сейчас с поддержкой игр на Linux-десктопах.

Если вам говорят, что Linux — отличная платформа для игр, то это уже не преувеличение! За такое положение вещей мы должны благодарить Proton.

Статистический подход к объяснению ошибочных дедлайнов в инженерных проектах

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

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

В 2019 году была написана потрясающая статья Parse, don’t validate. Я крайне рекомендую изучить её всем программистам (а также недавнее дополнение к ней Names are not type safety). Её основная идея заключается в том, что существует два способа проверки валидности входящих данных функции:

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

Главное утверждение, сделанное в этой статье — что парсеры предпочтительнее, чем валидаторы. Её основной посыл — нужно сделать недопустимые состояния непредставимыми (unrepresentable). В статье это реализовано с помощью использования системы типов. Я полностью согласен с такой философией, но хотел бы выделить и более подробно обсудить один из ироничных аспектов аргументации:

Инструмент контроля типов является хрестоматийным примером валидатора!

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

Какой же может быть альтернатива инструменту контроля типов в виде парсера для языка программирования?