Я не особо люблю освещать «текущие события», но правительство США на днях заявило о введении реально шокирующего запрета на импорт роутеров потребительского сегмента. Это идиотский запрет по целому ряду причин, но если он действительно вступит в силу, то навык сборки «самопального» роутера может оказаться весьма кстати.

К счастью, вы можете собрать его из практически всего, что можно хоть в какой-то степени назвать компьютером.

Любители вайбкодинга и агентного программирования говорят, что работают в 2, 10, а то и в 100 раз продуктивнее! Один даже разработал с нуля целый браузер. Невероятно!

И скептики задают правомерный вопрос: «А где же все эти приложения?» Если пользователи ИИ становятся пусть хотя бы вдвое продуктивнее, то где искать этот двухкратный прирост созданных программ? Все подобные вопросы исходят из предположения, что миру нужно больше ПО, и если оно станет дешевле в производстве, то и создавать его будут больше. Так что, если вы с этим предположением согласны, то где же все эти дополнительные программы, которые можно было бы отнести к «эффекту ИИ»?

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

Эта статья, по сути, родилась как развёрнутая версия комичной зарисовки, которую вы видите выше.

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

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

Когда я впервые заглянул во FreeBSD Handbook в 2002 году, то не мог поверить своим глазам. За шесть лет работы с различными дистрибутивами Linux, о чём у меня уже была статья, я научился выискивать документацию по кусочкам — часто неполную или устаревшую, причём иногда спустя всего год. Здесь же операционная система сопровождалась полноценным, точным и достаточно свежим подробным руководством. В то время я уже был убеждённым сторонником Open Source, но рассуждал очень практично. Если разработчики этой ОС вкладывают так много усилий даже в её документацию, то представьте, насколько проработанной должна быть сама система. Короче, я решил её попробовать. Тогда у меня был Sony Vaio, где не было места для второй операционки. В итоге я скопировал все данные на настольный ПК, собрался с духом и принял решение установить на этот ноут FreeBSD, а по завершению эксперимента снова вернуть на него Linux.

Спойлер: FreeBSD осталась на том ноутбуке навсегда.

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

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

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

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

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

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

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

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