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

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

Простота — это великое благо, но для её достижения необходим усердный труд, а для понимания — хорошее образование. Чего не скажешь про сложность, которая продаётся намного легче». — Эдсгер Дейкстра

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

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

Мне нравится экспериментировать с кастомными аллокаторами памяти, используя собственные реализации. И хотя модульные тесты помогают убедиться в их корректности, настоящей проверкой становится работа аллокатора в реальных программах.

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

Это история о том, как я превратила свою бывалую Kindle Touch в инструмент мониторинга времени прибытия автобусов с ежеминутным обновлением экрана и возможностью выйти из режима дашборда через кнопку меню. По сути, у меня получился TRMNL, только без ценника в $140.

В 2013 году на Randomwire была опубликована интересная статья. В ней автор указал на интересные особенности японского дизайна. Японцы известны своим минимализмом, но в случае сайтов у них, почему-то, всё наоборот. Страницы пестрят всевозможными цветами, что уже нарушает 3 принципа дизайна, плюс на них используются мелкие иконки и мно-о-о-о-го текста.  Да вы и сами видите пример этого буйства фантазии на скриншоте выше, сделанном в ноябре 2022 года.

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

И вот мне стало интересно, как обстоят дела сейчас, и можно ли как-то количественно оценить дизайн японских сайтов? Собственно, этим я и занялся.

«Примерно в то же время, когда Никита Хрущёв заявил о поддержке строительства Зеленограда, из Пенсильвании после года обучения вернулся один советский студент, Борис Малин. Борис привёз с собой небольшое устройство — SN-51 от Texas Instruments. Это была одна из первых интегральных схем, которые начали продаваться в США. С виду худощавый мужчина с тёмными волосами и глубоко посаженными глазами, Малин являлся одним из ведущих экспертов СССР в области разработки полупроводниковых устройств. Он видел себя как учёного, а не шпиона. В то же время Александр Шокин, занимавший пост председателя Госкомитета СССР по электронной технике (ГКЭТ), считал, что Советский Союз должен любыми средствами заполучить SN-51. Шокин пригласил Малина и группу других инженеров в свой кабинет, положил микросхему под микроскоп и начал разглядывать. «Скопируйте её, — скомандовал он. — Один в один, без каких-либо отличий. Даю три месяца».

— Отрывок из главы 8 книги Криса Миллера «Война чипов: борьба за самую важную технологию в мире».

Мне несказанно повезло, что я успел получить высшее образование до наступления бума ChatGPT.

Я закончил Университет Карнеги-Меллона по направлению "программная инженерия" в 2021 году. LinkedIn уже тогда был завален корпоративным слопом для вовлечения пользователей. Но этот слоп, хотя бы, писался людьми, а не LLM.

Эх, были же времена.

Когда я начал изучать рынок труда, оценка навыков джуниора, по сути, сводилась к одному бинарному вопросу: «Умеешь ли ты писать код?»

В то время, если я хотел запустить с нуля приложение, на это требовался минимум месяц усилий. И даже если ты знал, какие и как использовать библиотеки, как настроить аутентификацию, на что обратить особое внимание, как докеризировать своё приложение и как настроить автодеплой в пайплайне CI/CD, ты всё равно был обречён мучительно и монотонно набирать код, рискуя наплодить ошибок.

Сегодня же вся эта рутина полностью исчезла. Масштабируемые, обслуживаемые и красивые веб-приложения можно деплоить с Macbook Pro на собственном домене, меньше чем за 6 часов. Я знаю это, потому что сам так делал. Неоднократно. Самые ценные навыки молодого разработчика испарились, и мы по этому поводу даже не чешемся.

Мне страшно за будущее джуниор-разработчиков, и в этой статье я расскажу, почему.

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

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

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

Когда заходит разговор про WebAssembly, где-нибудь в начале дискуссии обычно появляется комментарий в духе «А что, собственно, произошло?»

Этот язык преподносили как нечто поворотное. Неужели это просто был яркий маркетинг? А может, очередной случай с обречённым на провал апплетом JVM?

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

Подмести весь супермаркет Albert Heijn? Звучит несложно. Собственно, так и должно быть.

Но я студент-информатик и у меня есть одна проблема — склонность оптимизировать процессы, которые, быть может, оптимизации не требуют.

Поэтому вместо того, чтобы просто делать свою работу, ну то есть… подметать… я поступил так, как поступил бы любой здравомыслящий человек: превратил план этажа супермаркета в решётчатый граф, создал визуальный редактор и написал на C++ оптимизатор пути, используя алгоритм имитации отжига (simulated annealing).

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

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

Работая в Bell Labs, Джеймс Д. Джонстон 26 лет посвятил созданию технологии, которую мы сегодня знаем как MP3. Затем его имя растворилось в истории...

Вступление от «Rogues’ Gallery»

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

И наше шоу (имеется в виду подкаст «The Rogues’ Gallery», — прим. пер.), как и многие другие, существует, благодаря той самой технологии. Ничто из этого не оказалось бы возможным, если бы не инженеры, которые научились втискивать час музыки в файл, достаточно небольшой для скачивания через коммутируемое соединение.

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

Одним из таких людей является Джеймс Д. Джонстон. В IEEE его зовут «отцом перцептуального аудиокодирования». Этот человек зарегистрировал более, чем 100 патентов. Кен Томпсон, который разработал Unix, лично переписывал код для созданного им кодека, сказав, что тот значительно превосходит MP3. Федеральный апелляционный суд США подтвердил, что он изобрёл формат MP3 параллельно с Карлхайнцем Бранденбургом. Но всё же в рассказах об истории развития цифрового аудио его имя всплывает крайне редко.

Джеймс является такой же рок-звездой, каких мы приглашаем на наше шоу. Просто он играет на другом инструменте.

И это история о нём.

Дублирование, использование неразличимых деталей, рассогласованность символов, путаница и куча других недоразумений...

Впереди подробный разбор перлов дизайнерских решений в macOS Tahoe с оглядкой на старое-доброе руководство Macintosh Human Interface Design из далёкого 1992 года. — прим. пер.

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

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

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

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

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

Но мы сегодня, естественно, поступим наоборот и заглянем в глубины элемента <plaintext>, чтобы узнать, какие занятные вещи с его помощью можно делать.

Бьюсь об заклад, что ПК в вашем офисе вряд ли потянут большие языковые модели (LLM).

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

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

Недавно моё утро началось с такого вот прекрасного e-mail от Hetzner:

Уважаемый, м-р Джей Сандерс,

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

Также просим вас прислать краткое пояснение с описанием того, как такое могло произойти, и что вы собираетесь в этом отношении предпринять. Если последующие шаги не будут успешно выполнены, ваш сервер может быть заблокирован в любой момент после 2025-12-17 12:46:15 +0100.

К письму прилагалось подтверждение того, что с моего сервера было выполнено сканирование некоего IP-диапазона в Таиланде. Отлично. Никакого вам «Здравствуйте», а лишь заявление о злоупотреблении и угроза отключить всю инфраструктуру через 4 часа.

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

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

Некоторым людям нравятся собеседования с написанием кода. Я к их числу не отношусь.

Недавно мне на LinkedIn попался пост такого содержания:

"Мы задаём каждому соискателю тривиальную задачу на программирование. Что-нибудь вроде: «Дан список чисел, нужно вернуть сумму чётных из них». И такая задача не предполагается как сложная или заумная, и её цель не в том, чтобы кого-то отсеять, теоретически.

Это лишь базовая проверка. Разработчик или SRE с опытом от 6 до 10 лет должен решать такие во сне, согласитесь?

Оказывается, нет.

Где-то 75% кандидатов не справляются. И не только джуниоры. Я говорю о людях с приставкой «Senior» в их квалификации. О людях, которые заявляют, что учат новичков. О тех, кто говорит, что имеет за плечами годы опыта в продакшене.

Для меня это загадка".

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

Долгие годы я воспринимал систему HDMI-CEC как домового: иногда полезная, часто непредсказуемая и всегда загадочная. У меня в гостиной собран несложный мультимедиа-центр — ТВ Samsung с поддержкой ARC (не eARC, которая заслуживает отдельного поста), Denon AVR-X1700H, спрятанный в кладовке, Apple TV, несколько подключённых к Denon игровых приставок и Raspberry Pi 4, управляющий системой Homebridge. Что касается CEC, то в Apple TV эта фича работает прекрасно, но вот приставки ведут себя так, будто едва с ней знакомы. Они будят ТВ, переключают источник, но оставляют Denon в режим ожидания, вынуждая меня переключать вывод аудио вручную.