Динамический высокоуровневый язык программирования
Что же мне перевести следующим?
Вижу вам зашел перевод книг особенно Black Hat Rust в посте я обещал сделать опрос если вам понравится перевод ну чтож ссылка на опрос в конце поста.
В общем, как я и обещал вот опрос https://docs.google.com/forms/d/e/1FAIpQLSdZnLR_qH0_Yiutv_F4KNBEH4GWYlgLzo-yWOjObn_2UdScjg/viewform?usp=header
Перевел на русский Black Hat Rust и Black Hat Ruby!
В общем, как все было: решил я подучить Rust но столкнулся с очень внезапной и странной проблемой книга есть только на английском. Английский я хоть и знаю, но сидеть и вручную переводить каждое непонятное техническое слово это боль для настолько ленивого человека как я, особенно когда там около 300 страниц технического английского текста.
Также мне по чистой случайность помимо раста попалась и книга по руби её я тоже взял и перевел, код я под новые версии языка хоть и не адаптировал, да и текст на картинках не переводил но вроде бы получилось довольно неплохо надеюсь многим понравится ну или хотябы там нескольким может)
Сразу скажу перевод неофициальный, если кто то против, пост могу и удалить (надеюсь не придется).
Сейчас уже готовы сразу две книги это Black Hat Rust и Black Hat Ruby еще в планах переводить еще книги тоже технические например какую-небудь книгу по C++ или что то подобное, честно пока идей нет скоро если вам пост зайдет сделаем опрос что в итоге то переводить следующим. Если вдруг хотите поддержать мой перевод то в репо есть криптокошелек там все указано (Ну это если прям сильно захочется, а так комменты и например звезды на репо на гитхабе это тоже поддержка которой я буду очень благодарен)
ну а вот и ссылка на репо https://github.com/smokeplay250-png/black-hat-ru
Выложил в открытый доступ небольшой инструмент, который сделал для своей работы: расширение для SketchUp, импортирующее сборки STEP.
Ruby API SketchUp не умеет читать STEP напрямую, поэтому расширение запускает FreeCAD в фоне и собирает модель в SketchUp:
- иерархия сборки сохраняется в виде групп
- повторяющиеся детали (винты, гайки) становятся компонентами
- тяжёлые узлы, например плата с компонентами, склеиваются в один меш: ~1200 деталей импортируются за секунды
- собственное окно прогресса, результат сохраняется в .skp
По пути наткнулся на несколько подводных камней производительности Ruby API SketchUp (add_faces_from_mesh против fill_from_mesh, молчаливая склейка точек) и описал их в README для других разработчиков расширений.
Windows, SketchUp 2021+, лицензия MIT. Это ранний релиз: цвета пока не импортируются. Буду рад отзывам и issues.
Мысли про DHH, Rails и AI в Ruby
Посмотрел выступление DHH с Rails World 2026. Ниже просто мои мысли по поводу того, что он говорил.
Никто не спорит что DHH гениальный маркетолог. Помню еще по истории когда он пересел с Mac на Linux и начал активно про него рассказывать, потом появились Omakub и Omarchy. В какой-то момент это местами звучало почти как проповедь.
С рельсой у меня сейчас похожее ощущение. DHH рассказывает, что Rails чуть ли не идеально подходит для эпохи AI: convention over configuration, мало кода, агенту проще разобраться в проекте, меньше токенов тратится, в этом есть логика. Но Надо помнить что Ruby является динамическим типизированным языком. Сам DHH статическую типизацию исторически не особо любит и, насколько я знаю, Sorbet или RBS активно не использует. Для человека отсутствие типов вполне может быть плюсом: быстрее пишешь код, не надо делать перегонять данные из одного типа в другой. Но для AI типы — это дополнительная информация. Поэтому мне не очень понятно, почему динамичность Ruby должна быть большим преимуществом именно в эпоху AI.
Но самое интересное не это. В том же выступлении DHH рассказывает, что в 37signals теперь фактически pencils down — код руками стараются почти не писать. И одновременно рассказывает, что HEY переписывают с использованием Rust. Причём, по его словам, получили огромную экономию CPU и памяти.
Сам DHH ещё говорит:
If I look at the past 21 years, over half of my work was Ruby code. This year, about 3%.
что раньше больше половины его кода было на Ruby, а в этом году что-то около 3%.
Получается довольно интересная ситуация, которая вызывает вопросики. Одно из главных преимуществ Ruby всегда было в том, что на нём очень приятно писать человеку. Синтаксис простой, код выразительный, Rails позволяет очень быстро собрать рабочий продукт. Но если код теперь в основном пишет агент, то насколько вообще важно, приятно ли человеку этот код писать?
DHH сам говорит примерно об этом же на примере Rust: смотреть на него ему не нравится, зато результат, который делает AI, нравится. И получается, что AI в каком-то смысле убирает одно из главных преимуществ Ruby. Раньше можно было сказать: да, Rust или Go быстрее, но Ruby позволяет разработчику быстрее получить результат, а теперь агент может довольно быстро написать и Rust, и Go.
При этом у тебя остаются статическая типизация, нормальная работа с многопоточностью и более предсказуемое потребление ресурсов. С Ruby всё сложнее. В MRI всё ещё есть GIL. Для обычного веба это далеко не всегда проблема, но если нужна CPU-параллельность, приходится уже думать про воркеры, дополнительные инстансы и так далее. А инфраструктура тоже стоит денег.
С Hotwire у меня похожее ощущение. Сама идея нормальная и для определённого класса приложений действительно удобная. Но DHH иногда очень хорошо умеет взять подход, который отлично работает в 37signals, и продать его так, будто именно так теперь должен писать весь интернет.
Поэтому DHH я всегда воспринимаю сразу в двух ролях. С одной стороны, это очень сильный инженер, который сделал один из самых крутых фреймворков. С другой, один из лучших маркетологов среди разработчиков. Он умеет взять своё мнение о разработке, превратить его в философию, дать ей красивую обёртку и заставить всех нас потом это обсуждать. Но после этого выступления я так и не понял, почему именно Ruby должен идеально ложиться на эпоху AI. Да, у Rails есть сильные conventions, мало шаблонного кода и агенту действительно может быть проще ориентироваться в проекте. Но при этом часть преимуществ Ruby была важна именно человеку, который этот код пишет. А если код всё чаще пишет агент, то эти преимущества уже не выглядят настолько очевидными.
После Ruby/Elixir в Go, часть 1
Когда я начал писать на Go после опыта с Ruby и Elixir, одной из самых непривычных вещей стало отсутствие консоли, в которой можно напрямую вызывать код приложения.
Для рубиста такая консоль почти универсальный пульт управления приложением(но пульт довольно опасный). Если нужно посмотреть, что происходит с конкретным пользователем, можно просто открыть консоль, найти его, вызвать нужный метод и понять, почему, например, не работает какая-то функция.
Набираешь:
bundle exec rails c
И через несколько секунд уже находишься внутри приложения и можешь работать с его кодом и данными. Только вместо кнопок у разработчика код. Надо помнить: «С большой силой приходит большая ответственность». © Дядя Бен.
Например, приходит вопрос:
Почему у этого пользователя не появился доступ к фиче?
В Rails можно открыть консоль, вызвать нужный код и довольно быстро проверить несколько гипотез. Когда я пришёл в Go, первое время постоянно хотелось сделать то же самое. Конечно, проверить код всё равно можно. Можно написать тест или небольшую программу, подключиться к базе, сделать отдельную CLI-команду под конкретный кейс, но это уже не то ощущение: «открыл приложение и начал быстро проверять гипотезы».
Ruby здесь не единственный пример. В Elixir есть интерактивная консоль IEx. Можно запустить прямо внутри неё:
iex -S mix
Благодаря возможностям Erlang VM можно даже подключаться консолью к другому запущенному узлу. И вот после Ruby и Elixir Go ощущается особенно необычно. В Ruby удобную консоль обычно даёт фреймворк. В Elixir сама платформа хорошо приспособлена к интерактивной работе с запущенной системой.
В Go это ощущается так:
Если хочешь что-то вызвать, сделай для этого нормальную точку входа.
Поначалу это раздражает. Кажется, что раньше на проверку гипотезы уходило 5–10 минут, а теперь приходится что-то дополнительно писать, но со временем я увидел в этом и другую сторону. Удобная консоль очень легко позволяет разработчику стать частью бизнес-процесса. Про эту боль я подробнее писал в статье. Также можно легко сломать продакшен.
Нет нужной кнопки в админке?
Попросим разработчика выполнить команду.
Нужно поправить состояние пользователя?
Разработчик сделает через консоль.
Для небольшого бизнеса это действительно может быть удобно. Но потом внезапно оказывается, что важная операция в продукте существует только потому, что рядом есть разработчик, который знает правильную команду. Я такой подход называю Developer as an admin panel.
В Go отсутствие такого универсального пульта начинает раздражать раньше. Если одна и та же операция повторяется, довольно быстро хочется сделать для неё CLI, скрипт, админку или нормальный API. Бизнес раньше начинает видеть ценность такого инструмента.
Я всё ещё считаю консоли в Ruby/Elixir невероятно удобными инструментами. Но теперь, когда хочется в очередной раз сделать что-то вручную, полезно задать себе вопрос:
Мне действительно не хватает консоли или не хватает нормального инструмента?
WebTransport: будущее потокового вещания и коммуникаций.
В сети появились интересное, как по мне, видео с конференции rubyconf2024. В нем рассказывается об эволюции веб-протоколов передачи данных, от веб-сокетов до веб-транспорта, а также грядущую спецификацию HTTP 3. Из видео можно узнать о двунаправленной потоковой передаче, дейтаграммах и потенциале веб-кодеков для потоковой передачи видео.
Всем кому любопытно, то рекомендую к просмотру: https://youtu.be/WqYExpMWIUU?si=p4gSGHXkhHAS4LK_
Для питонистов и тем кому интересно хочу перекомендовать к прочтению статью о webtransport и библиотеке на python aioquic [habr].
Что такое веб-транспорт?
Web Transport — это новый веб-протокол, разработанный для улучшения существующих решений, таких как WebSockets и события, отправляемые сервером (SSE). Хотя Web Transport часто называют «WebSocket 2.0» из-за его расширенных возможностей, он предлагает более тонкие функции, такие как однонаправленная и двунаправленная потоковая передача, дейтаграммы и улучшенная обработка частичной надёжности. В настоящее время этот протокол поддерживается в виде черновика основными браузерами, такими как Firefox и Chrome, а вскоре его поддержка появится и в Safari.
Ключевые особенности
Двунаправленная и однонаправленная потоковая передача: веб-транспорт поддерживает оба типа потоковой передачи, что делает его универсальным для различных задач.
Дейтаграммы: в отличие от более ресурсоёмких веб-сокетов, дейтаграммы требуют меньше ресурсов и допускают потерю пакетов, что может быть преимуществом в сценариях, где надёжность не является критически важной.
Приоритетная обработка: особенно полезна для таких приложений, как потоковое видео, где определённые критические кадры могут иметь приоритет над другими для обеспечения более плавной работы пользователя.
Уж сколько раз убеждался, что ФИПС при регистрации по факту ничего не проверяет и не правит в данных от заявителя... но чтобы настолько можно было нагло проталкивать чужое ПО как свое, пользуясь ленностью ФИПСа...
Федоров Максим Владимирович - если ты это читаешь - покайся! :)
Если Jean-Philippe Lang не просматривает реестры ФИПС - это не значит, что можно так безоглядно использовать его интеллектуальную собственность.
P.S.: очень хочется узнать, как удалось уместить программу в 10КБ :))
26 апреля 2024 года состоялся релиз эффективной многопоточной среды обработки Kafka на Ruby и Rail проекта Karafka 2.4.
Исходный код этого инструментария опубликован на GitHub под лицензией LGPLv3.
В новой версии проекта исправлены ранее обнаруженные ошибки, а также внесены улучшения и изменения. В Karafka 2.4 прекращена поддержка Ruby 2.7 и используется инструментарий WaterDrop 2.7.
Перестал работать RubyGems. Пакеты теряются на магистрали Мегафона. Как до них достучаться? Какие есть рычаги воздействия?
Если начнут блокировать еще и аутлайн, то вся работа компании встанет банально из-за невозможности запустить бандл.
