Примерно раз в 2–3 года мне удаётся увидеть ледоход на Волге. Это впечатляющее зрелище: льдины скрипят, поют, наезжают друг на друга, сталкиваются и отталкиваются на считаные секунды. Откровенно говоря, выглядит всё это не только величественно, но и небезопасно: кажется, что льдины готовы затереть всё живое и неживое на своём пути. Но дух захватывает.

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

А что вообще мы знаем об айсбергах, кроме истории с «Титаником»? 

Автор — чудесный Антон Гудим

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

RSS и Atom — простые и понятные форматы для публикации контента. Кто-то считает, что золотое время RSS осталось в прошлом, но это не так. На самом деле этап хайпа остался в прошлом, а сейчас синдикация вышла на плато продуктивного использования в своих нишах. Например, подкасты (MP3 по RSS) живут и процветают.

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

В прошлой части мы рассказали о том, как в США 50-х годов от экспериментов по созданию «сывороток правды» перешли к попыткам программировать человеческое сознание. Сия гениальная идея пришла в головы американским спецслужбам по причине внутриведомственной конспирологии: они верили, что у коммунистов уже были такие технологии, и очень боялись отстать. Во главе проектов ЦРУ в этой сфере стоял Сидни Готтлиб: живое воплощение образа безумного учёного, ставящего самые странные и пугающие эксперименты над людьми… просто потому, что может и ему это очень интересно.

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

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

Какое подмножество C++ или Kotlin вы используете? Что вы предпочтёте: project.toml или requirements.txt? Теперь у вашего языка есть возможность поэтапной типизации с помощью аннотаций типов. Хотите ей воспользоваться? Как вы реализуете конкурентность: с помощью многопоточности, Tokio или std::async?

Чем более экспрессивный язык, тем сложнее всё становится. И здесь на сцену выходит Go. И речь не только о gofmt, но и о его стандартной библиотеке и согласованности. В Kotlin вам приходится гадать, что лучше использовать для ошибок: исключения или объекты Result? В случае же Go вам всё ясно – ищем err. Да, это многословно, но зато предсказуемо.

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

В марте 2024 года регулятор FCC согласовал нормативно-правовую базу для сервиса прямого спутникового доступа (Direct-to-Device, D2D) в США. SpaceX, использующий на правах сублизинга частоты сотового оператора T-Mobile, будут иметь вторичный приоритет. Такое правило закреплено в п. 4.4 Регламента радиосвязи ITU (non-protected/non-interference basis) — не создавать помех приоритетным сервисам, которым частоты в диапазоне были выделены ранее. Однако США стали первой страной, применившей его для D2D. Вероятно, вскоре их примеру последуют и другие страны. Использование сотовых частот даёт возможность подключить обычные устройства. Сначала это будут сообщения/сигнал SOS с координатами, потом добавится голос, а затем и передача данных на скоростях 2-4 Мбит/с. Пока D2D воспринимается как премиальный сервис (Apple iPhone и флагманы Huawei). Но приоритетным для него будут наименее развитые страны Африки и Азии, где на «границе сети» живут оставшиеся полмиллиарда абонентов, нуждающиеся в базовых услугах. И на этом рынке уже тесно и без SpaceX.

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

В начале 50-х годов ЦРУ в рамках проекта «Артишок» активно занималось экспериментами в области того, что в шпионских романах и фильмах обычно называют «сыворотками правды»: как с помощью химических веществ заставить допрашиваемого или расспрашиваемого стать более откровенным, чем ему бы хотелось. Аппетит пришёл во время еды — и уже в начале 1952 года руководством американской разведки была поставлена куда более амбициозная задача: «получить контроль над человеком до такой степени, что он будет выполнять приказы вопреки своей воле и даже вопреки фундаментальным законам природы, таким как самосохранение». Из этой идеи вырос проект «MKUltra», подробности которого до сих пор остаются загадкой для историков спецслужб. Продолжим разбираться в его мрачных тайнах.

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

Во все века разведчики, шпионы и спецслужбы полагались в своей работе на разные вещества и психологические уловки. Тёмные рыцари плаща и кинжала травили врагов всевозможными ядами, усыпляли стражу, подсылали убийц-фанатиков с промытыми пропагандой и веществами мозгами — как легендарные ассасины времён Крестовых походов, чьё название происходит от неумеренного накачивания одноразовых киллеров гашишем. Развитие науки и техники в ХХ веке только подстегнуло энтузиазм шпионских ведомств. Если в СССР секретная токсикологическая лаборатория №12 при КГБ занималась в основном ядами для ликвидации врагов трудового народа, то в США к боевым токсинам из закрытого центра Форт-Детрик добавлялись безумные во всех смыслах эксперименты ЦРУ по взлому чужих (и даже своих!) мозгов посредством веществ и гипноза. Это привело к грандиозному скандалу в 70-е годы, породило немало теорий заговора, а также отсылок в массовой и не очень культуре. Впрочем — обо всём по порядку.

Компания Microsoft сегодня (или с 1 апреля) блокирует доступ к облачным сервисам для корпоративных клиентов из России. С этого дня хранилище OneDrive станет недоступно, как и 50 других сервисов Microsoft. Аналогичная ситуация может сложиться с сервисами Amazon и Google. Это вызовет некоторые проблемы у компаний, хранящих файлы в облаке.

Если у пользователей нет резервных копий, им придётся в экстренном порядке переносить их на другой сервер, спасая с «тонущего корабля». К счастью, на этот случай есть удобные инструменты вроде Rclone, который одной командой копирует файлы с популярных облачных хостингов на свой сервер.

Иллюстрация из книги «Справочник киберсантехника»

Протокол SSH — очень мощный инструмент, который используется для удалённой консоли или передачи файлов (scp, sftp). Есть менее известная функция перенаправления портов. Такие SSH-туннели используются для пробития файрволов и хорошо скрываются от обнаружения стандартными средствами мониторинга типа Trisul, Zeek (ранее был известен как Bro), Suricata и Snort. Поэтому для их обнаружения в корпоративной сети используются другие методы.

Советские игровые автоматы стали порождением сближения СССР и Запада в начале 70-х годов, при брежневско-никсоновской разрядке. Советский Минкульт выкупил большую часть игровых автоматов, которые появились в Москве на международной выставке «Аттракцион-71», и уже в 1974 году в серию пошёл самый знаменитый советский игровой автомат «Морской бой». О том, как он появился на свет, и какую роль в этом сыграли японские и американские разработки, мы поговорили в прошлой части. А теперь вспомним другие игровые автоматы СССР — менее культовые, но также дарившие множество ярких впечатлений до появления в нашей стране массовых компьютерных игр.

Пару месяцев назад я запустила сервис y.gy, навороченный сокращатель URL. Вызвано это было личной нуждой: в другом моём проекте, getwaitlist.com, используется множество реферальных ссылок, а доступные сервисы сокращения url не внушали мне доверия. В итоге я решила создать собственный инструмент, который наверняка окажется полезен не только мне.

Я разработала лучший в своём роде сокращатель со всеми возможными примочками, начиная с обширной кастомизации и заканчивая хорошей аналитикой трафика. Это всё, что мне было нужно. По аналогии со многими аналогичными инструментами я разместила интерфейс «Shorten Link» по центру домашней страницы. Регистрация для использования сервиса не требуется. Я сделала доступ бесплатным и неограниченным, опираясь на принцип: «бесплатность – лучшая маркетинговая стратегия». Закончив с настройкой, я без громких заявлений сделала релиз и начала потихоньку продвигать свой проект.

С выходом Persona 3 Reload, ремейка игры, которая коренным образом изменила облик серии и сделала её одной из самых важных японских RPG-франшиз в истории, шумиха вокруг пятой части поутихла. Появившись на западе в 2017 году, следом за родной Японией, игра захватила умы геймеров по всему миру, имея нестандартные для жанра сеттинг, темы и художественное оформление.

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

В первой части этого небольшого цикла статей мы говорили о том, что механизм устойчивого выполнения (durable execution) сохраняет состояние программы в журнале, а также о связанных с этим сложностях в случае обновлений служебного кода, ведущих к утрате журналом актуальности. Мы увидели, что ограничение времени выполнения обработчика существенно облегчает эту проблему. Но… не ведёт ли это к потере одного из наиболее интересных свойств устойчивого выполнения — возможности создавать бизнес-процессы, работающие с длительными паузами? В Restate мы считаем, что при использовании правильных примитивов можно ничего не потерять.

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

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

Бывает и так, что энтузиазм не угасает, но после многочисленных безрезультатных попыток и серьёзных материальных вложений становится предельно ясно, что целей D.I.Y.-проекта достичь невозможно. Результатами такого проекта становятся все пять стадий принятия неизбежного, и радостно от этого никому не бывает.

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

За последние годы мы наблюдаем всплеск разработки инструментов и платформ, обеспечивающих Durable Execution (устойчивое выполнение). Немного поясню его принцип.

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

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

Недавно в сердцах я написал на Mastodon такой пост:

«Мы считаем, что сфера опенсорса должна быть жизнеспособной, а труд мейнтейнеров должен оплачиваться!»

Мейнтейнер: *вносит коммерческие возможности*
Мы: «Не таким образом».

Мейнтейнер: *работает на крупную технологическую корпорацию*
Мы: «Не таким образом».

Мейнтейнер: *привлекает инвестирование*
Мы: «Не таким образом».

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

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

Haskell — это язык программирования, изобретённый в 20-м веке шотландскими логиками в качестве пранка (вероятно). Примерно пятнадцать лет назад я начал изучать Haskell по причинам, которые уже и не упомню. Сегодня я наконец написал полезную программу на Haskell и уверен, что смогу сделать это снова, если мне когда-нибудь понадобится ещё одна компьютерная программа.

Я не знаю, как изучал функциональное программирование в целом и Haskell в частности. В 2006-м я следил за проектами why the lucky stiff и читал передовой тамблелог Леа Нойкирхен Anarchaia, и какой-то из этих источников познакомил меня с миром за пределами ООП. В декабре 2006 года Леа опубликовала на Anarchaia ссылку на Pandoc, и тогда я впервые узнал о своём любимом ПО и языке, на котором оно было написано.