В своём предыдущем посте о потоках я привёл импровизированное сравнение¹:

Потоки² — это просто состояния сохранения³ эмулятора⁴, связанные с условием, при котором продолжается их выполнение.

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

Поэтому я добавил многопоточность в Super Mario Bros. для NES.

«Зачем вообще писать программу, меняющую код в процессе выполнения? Это же ужасная идея!»

Да, всё так и есть. Но это и хороший опыт. Такое делают только тогда, когда хотят что-то исследовать, или из любопытства.

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

Предупреждение: в этом посте активно используется язык ассемблера x86_64, в котором я ни в коем случае не являюсь специалистом. Для написания статьи мне пришлось изучать приличный объём материалов, и, возможно (почти наверняка), в ней есть ошибки.

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

Например, система CasaOS изначально создавалась для одноплатника ZimaBoard (на фото), который позиционируется как мини-NAS. Главная ценность — отшлифованный UI с системными гаджетами для домашнего сервера, отобранный список приложений в каталоге, полезных именно для личного облака, и установка всех программ в докер-контейнерах в один клик. Плюс минимальные системные требования, поддержка старых ПК и одноплатников, включая Intel NUC и Raspberry Pi.

Как и у многих, у меня накопилось слишком много подписок: некоторые у Apple (iCloud, Apple Music), другие потерялись на разных платформах (например, на Netflix — я и забыл, что всё ещё плачу за него). На самом деле, я регулярно пользовался Apple Music (а ранее Spotify), но потоковая музыка оказалась больше удобством, чем необходимостью. При наличии тщательно подобранной локальной библиотеки я ничего особо не потерял.

Поначалу я думал, что просто продолжу использовать iCloud Music Library для синхронизации музыки между устройствами, но после отмены подписки на Apple Music синхронизация перестала работать. Оказалось, за эту функцию нужно платить. Строго говоря, её можно вернуть при помощи iTunes Match (24,99 $ в год). Match просто хранит AAC-копии с битрейтом 256 кбит/с; ваши исходные файлы остаются на месте, если вы не захотите удалить их. На современных Mac всё это делается в приложении Music. При отсутствии подписок синхронизация с облаком отключается и остаётся лишь синхронизация по кабелю/Wi-Fi.

Раздосадованный ограниченностью возможностей, я решил взяться за разработку. Если уж я купил вычислительное устройство (в данном случае iPhone), то что мешает мне просто создать необходимое мне при помощи кода? В этой статье я расскажу о своих разочарованиях по пути к реализации базовой функциональности музыкального плеера: загрузки аудиофайлов, их упорядочивания и воспроизведения. Но больше всего мне хотелось напомнить себе, что это просто компьютер, и у меня должна быть возможность заставить его выполнять нужные мне задачи.

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

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

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

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

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

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

Нас всегда спрашивают, каким вокодером мы пользуемся, но каждый раз в наших вокальных дорожках используется разный эффект вокодера. У нас есть старый Roland [SVC-350], Auto-Tune и DigiTech Vocalist.

В этой цитате содержатся важные подсказки, но она неполная, потому что охватывает только первые два альбома. В ней ничего не говорится о Talk Box, хотя в Around The World он почти наверняка использовался. Судя по цитате, можно решить, что DigiTech Vocalist — это вокодер, хотя на самом деле это не так. Да и какую конкретно модель DigiTech Vocalist они использовали? В серии DigiTech Vocalist есть примерно тридцать устройств, и многие из них были выпущены до релиза альбома Discovery в 2001 году.

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

У кинематографической индустрии есть собственные стандарты для защищённого создания и распространения фильмов. Всё необходимое, от форматов файлов и шифрования до проекционных систем, определяется в спецификации DCI (Digital Cinema Initiatives).

Сама спецификация доступна публично, но связана с различными стандартами IEEE (Institute of Electrical and Electronics Engineers) и SMPTE (Society of Motion Picture and Television Engineers), которые необходимо приобретать за деньги.

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

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

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

Если загуглить лучшие 10 продвинутых хитростей Python, то вы найдёте кучу постов или статей на LinkedIn с обзором тривиальных (но всё же полезных) вещей типа генераторов или кортежей.

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

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

Пожалуйста, будьте ответственными и изучите законодательство вашей страны, прежде чем пытаться делать нечто похожее. Передача радиосигналов может очень быстро вызвать юридические проблемы, а полосу, которую я использовал в посте (868 МГц) занимать в США без лицензии незаконно. Не хочу, чтобы в ваш дом из-за меня постучались люди в штатском. Я вас предупредил!

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

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

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

Я автоматизирую устройства в своей квартире с помощью Home Assistant, и хотел поступить так же с бойлером. Очевидно, для этого есть множество готовых решений, но они бы потребовали участия арендодателя и, вероятно, прихода электрика. А мне этого не хотелось!

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

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

За это время я пообщался со многими людьми из этой сферы: с членами некоммерческих организаций, сражающихся за права на конфиденциальность данных в разных странах до сотрудников компаний, занимающихся рекламными технологиями. Они подтвердили или опровергли мои слова (в основном подтвердили). Меня даже пригласили в подкаст «Lock and Code» для обсуждения геолокационных данных и конфиденциальности.

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

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

* Деятельность Meta — соцсети Facebook и Instagram — запрещена в России как экстремистская.

▍ TL;DR

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

Описание выложено в репозиторий GitHub.

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

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

Нет, на самом деле, мне не давал покоя такой вопрос:

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

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

Если на компьютере под Linux нужно быстренько запустить Windows или MacOS, самый простой и быстрый способ сделать это — ввести команду для скачивания и загрузки докер-контейнера с этой ОС.

В маркетплейсе RuVDS много готовых образов с установленными операционными системами. Там разные дистрибутивы Linux, Windows Server и CentOS. Но нет контейнеров с операционными системами.

Операционная система в докер-контейнере (в QEMU) не требует ручной инсталляции ОС. Всего одна команда в консоли — и контейнер Windows скачивается и запускается.

Двадцать лет назад, 7 апреля 2005 года, Линус Торвальдс создал самый первый коммит в «информационном менеджере из ада» Git.

За эти двадцать лет Git превратился из простого маленького личного проекта в самую масштабную и популярную систему управления версиями.

Лично для меня это было захватывающее приключение в мире ПО, со своими взлётами и падениями.

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

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

Некоторые из них хорошо известны, другие — достаточно нишевые. Но все они очень полезны разработчикам и менеджерам. Любопытно, какие из них вам известны:

1. Закон Паркинсона.
2. Закон Хофштадтера.
3. Закон Брукса.
4. Закон Конвея (и обратный закон Конвея).
5. Закон Каннингема.
6. Закон Старджона.
7. Закон Завински.
8. Закон Хайрама.
9. Закон Прайса.
10. Эффект Рингельмана.
11. Закон Гудхарта.
12. Закон Гилба.
13. Закон Мёрфи.

Поехали.

Когда я запустила первую симуляцию червя, ветра Санта-Аны дули уже сильно. Я не хакер, но это было просто: открываешь оболочку терминала, вставляешь команды из GitHub и наблюдаешь за бегущим по экрану каскадом символов. Совсем как в фильмах. Пока я искала в пролетающем перед глазами коде узнаваемые слова — neuron, synapse — ко мне подошёл друг, чтобы пойти со мной на ужин. «Секунду. Я тут прогоняю на компьютере червя», — крикнула я ему из офиса.

В корейском ресторане царил хаос: ветер клонил пальмы и гонял магазинные тележки по парковке. Атмосфера казалась сюрреалистичной, похожей на подкаст, проигрываемый с удвоенной скоростью. «Чем ты там занимаешься? Киберпреступлениями?», — спросил друг. Я попробовала ему объяснить: «Нет, не червя типа Stuxnet. Настоящего живого червя».

Когда я добралась домой, было уже темно, а в Альтадене уже загорались первые искорки пожаров. На моём ноутбуке меня ждал червь в объёмной пиксельной коробке. Заострённый с обоих концов, он висел в тумане из частиц, странно прямой и неподвижный. Разумеется, он никогда не был живым. Но мне он казался мертвее мёртвого. «Браво», — сказал мне Стивен Ларсон, когда я написала ему тем же вечером, — «вы добились состояния «hello world» в симуляции».

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

Для нормального управления закладками нужно специализированное решение. Тут много вариантов, а одно из лучших — это опенсорсное приложение Hoarder («Копилка информации»). Оно устанавливается на сервер и выступает единой БД для доступа из любых клиентов: Android, iOS, Chrome, Firefox и т. д.

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

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

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

В эти выходные мне пришлось купить новую посудомоечную машину, потому что моя старая GE умерла.

Я купил машину Bosch серии 500, потому что её рекомендовали в журнале Consumer Reports и, что более важно, она нашлась в магазине.

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