Несмотря на то, что книга «Чистый код» привнесла в наш лексикон прекрасный термин, она также снискала и дурную славу. Это руководство от 2008 года представляет собой сборник принципов и исследований, которые «дядя Боб» (Uncle Bob, то есть Роберт Мартин) выработал за годы программирования.

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

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

Можно подумать...

Недавно я закончил реализацию своего хобби-проекта по воссозданию ПК IBM XT из 80-х на основе оригинальных деталей с использованием современных технологий. У меня была чёткая цель: возможность играть на этом ПК в EGA-версию Monkey Island 1 со всеми примочками. То есть мне нужна была поддержка мыши, жёсткий диск с возможностью записи для сохранения игры и версия озвучки через карту Adlib, которая мне нравилась больше всего.

Эта задумка у меня возникла, когда я узнал о существовании маломощного варианта Intel 8088, который использовался в XT. Низкое энергопотребление значительно упрощает подключение процессора к ПЛИС, ввод-вывод которой обычно работает на 3,3 В. Всё это вкупе с маломощной микросхемой SRAM на 1 МБ (CY62158EV30), призванной обеспечить XT его 640 КБ памяти, уже составляло основу для всей будущей системы.

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

Интернет — невероятное изобретение. Людей от него за уши не оттащишь. Вот только есть у этого изобретения проблемы с надёжностью — пакеты теряются, каналы перегружаются, биты путаются, а данные повреждаются. Ох, какой же опасный мир! (Буду писать в духе Крамера).

Хорошо, почему же тогда наши приложения вот так просто работают? Если вы выводили своё приложение в сеть, то процесс вам знаком: socket()/bind() здесь, accept() там, возможно, connect() вон там и, вуаля — данные надёжно текут в обе стороны упорядоченным и целостным потоком.

Сайты (HTTP), сервисы e-mail (SMTP) или удалённый доступ (SSH) — всё это построено на основе TCP и просто работает.

Есть три вида писем, которые могут испортить блаженную субботу: уведомление безопасности, предупреждение об отключении электричества и, очевидно, повторное напоминание о том, что вы задолжали облачному провайдеру один цент — да, именно $0,01. Услугами DigitalOcean я пользуюсь с 2013 года, хотя для личных задач я этот сервис использую редко, просто авторизуюсь несколько раз в неделю для обеспечения поддержки моих клиентов на этой платформе.

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

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

Утечка оперативной памяти в Apple Calculator достигает 32 ГБ.

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

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

Мы урегулировали программные катастрофы такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.

Если вы уже давно знакомы с Backblaze (особенно, если следите за обзорами Drive Stats), то наверняка читали наши обсуждения кривой отказов. В статье «Drive Failure Over Time: The Bathtub Curve Is Leaking» мы писали о том, как проверяли истинность старого инженерного принципа, гласящего, что сбои в работе привода, представленные в виде временного графика, демонстрируют предсказуемую U-образную кривую, иначе называемую кривая «ванны».

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

И «ванна» в этом случае не просто «потекла» (отсылка к leak в названии вышеупомянутой статьи, — прим. пер.), её форма больше напоминает бордюр при входе в душевую кабину. Складная история о том, что вначале идут сбои, а потом спокойный средний период с плавным повышением отказов, больше не вписываются в реалии жизни наших приводов. Они становятся лучше. Говоря точнее, датасет Drive Stats указывает на повышение их качественных показателей конкретно в дата-центрах.

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

Если коротко, то жёсткие диски становятся лучше.

(Перевод моего выступления на  P.I.W.O в июне, слегка подчищенный и приближенный к формату блога).

…звучит как-то не очень. Я сделала все эти слайды в Inkscape с ПК под управлением KDE Linux, плюс я регулярно пользуюсь Firefox. Но это всего лишь я. А что насчёт вас? Вы используете свободное ПО? Поднимите руки! [в аудитории поднимаются руки] Конечно же! Что за чепуха, «Свободное ПО не победило». Кто-то подменил мои слайды… Эй, ведущий конференции!

Ведущий: В другом каталоге.

[Перехожу в каталог с названием другой каталог и открываю файл твои слайды тупица.pdf]

Вот они мои слайды.

Всех приветствую, меня зовут Дорота, и сегодня я буду говорить о том, как …

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

Ещё в 2009 году Тим Бернерс-Ли написал веб-спецификацию под названием «Socially Aware Cloud Storage», ориентированную на защиту общественных интересов при реализации облачных хранилищ:

«Есть такая архитектура, в которой несколько сетевых или веб-протоколов собираются воедино для создания всемирной системы, где приложения (десктопные или веб) способны работать поверх уровня стандартного хранилища, предоставляющего возможность чтения/записи.

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

Несколько таких идей активно обсуждались в цифровой среде в конце 2000-х, вскоре после взрывного развития монолитных платформ эпохи Web 2.0 вроде Facebook*.

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

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

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

Это история о том, как я превратил свой старый iPhone 8 в OCR-сервер на солнечных батареях, используя фреймворк Apple и зарядную станцию EcoFlow River 2 Pro. Он месяцами напролёт работает в режиме 24/7, обрабатывая тысячи изображений на полностью автономном питании.

За год с лишним мой сервер обработал 83 418 запросов на распознавание текста (OCR) и 48 ГБ изображений, используя только фреймворк Apple Vision и возобновляемую энергию. Большинство людей после апгрейда закидывают свои старые iPhone в ящик. Но не я. Я превратил свой телефон в сервер, который экономит мои деньги, работая полностью автономно.

Мог ли я просто запустить этот сервер на своём маке, как нормальный человек? Конечно же. Но разве это весело?

Занимаясь проектированием систем ПО, идите самым простым путём из возможных.

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

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

Когда я впервые узнал о кодировке UTF-8, то был поражён её продуманностью и структурой. Тем, как изящно её авторам удалось выразить миллионы символов разных языков и письменностей, параллельно сохранив обратную совместимость с ASCII.

В UTF-8 используется 32 бита, а в старой доброй ASCII — 7 бит. Но UTF-8 выстроена так, чтобы:

- Любой файл в кодировке ASCII являлся валидным файлом UTF-8.

- Любой файл в кодировке UTF-8, имеющий только символы ASCII, также являлся валидным файлом ASCII.

Спроектировать систему, способную масштабироваться на миллионы символов и сохранить совместимость со старыми стандартами, использующими всего 128 символов — это гениально.

В этой статье я расскажу о том, что происходит внутри ядра Linux, когда процесс вызывает execve(), как ядро подготавливает стек и как затем передаёт управление пользовательскому процессу для выполнения.

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

В качестве одного из своих увлечений я помогаю людям восстанавливать данные со старых ленточных кассет, например QIC-80, которые в 90-е годы часто применялись для резервного копирования. Ими пользовались отдельные люди, компании, операторы досок объявлений и не только. К ленточным кассетам я испытываю очень тёплые чувства. Есть нечто особое в том тактильном ощущении, которое возникает, когда держишь эту кассету в руках. Нечто такое, что делает сам процесс её использования приятным несмотря на все огрехи дизайна, которыми славилась технология QIC. Причём, если вникнуть в процесс и воссоздать все необходимые условия, то данные на этих лентах, даже спустя столько времени, вполне можно восстановить.

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

Предыстория

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

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

Ссылка на ролик на YouTube

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

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

Я уже больше десяти лет критикую Go, о чём высказывался в своих предыдущих статьях «Why Go is not my favourite language» и «Go programs are not portable».

Описанные в них проблемы языка бесят меня всё больше, и в основном потому, что их явно можно было избежать. Мир знавал решения и получше, но Go почему-то состряпали именно таким.

Те, кто читал мои прежние статьи, встретят здесь частичные повторы, так что заранее прошу меня за них простить.