Ruby *

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

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

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

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

Еще раз привет хабру! Это обещаный в прошлых постах отрывок из 9 главы отшлифованный конечно не в плане кода, но все же вот отрывок. 9 глава - глава о фишинге и wasm(WebAssembly):

Глава 9. Фишинг с помощью WebAssembly

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

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

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

9.1 Социальная инженерия

Социальная инженерия — это всё об убеждении. Убеждении кого-то дать вам фрагменты информации, сделать что-то или дать вам доступ, которого у вас быть не должно.

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

И снова привет хабру еще раз! Прошлый пост был по 7 главе, где я написал о том что сегодня выйдет 8 отрывок из 8 главы, соответственно вот он. Так, как 8 глава - глава о шеллкодах, то я выбрал по моему мнению наиболее подходящий отрывок:

Глава 8. Написание шеллкодов на Rust

Поскольку у моего первого компьютера был всего 1 ГБ оперативной памяти (Asus EeePC), мои хобби были очень низкоуровневыми и нетребовательными к ресурсам.

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

8.1 Что такое шеллкод

Цель эксплойта — выполнить код. Шеллкод — это сырой код, выполняемый на эксплуатируемой машине.

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

Вот пример шеллкода:

Снова привет хабру! Сегодня я отшлифовал сразу 3 главы - 7, 8, и 9 главу. Они уже лежат на гитхабе здесь будет отрывок из 7 главы. Из 8 главы отрывок будет завтра, а соответственно отрывок из 9 будет после завтра. Я выбрал самый первый кусок главы и чуть-чуть больше:

Глава 7. Разработка эксплойтов

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

Эксплойт — это фрагмент кода, используемый для запуска уязвимости.

Обычно эксплойты разрабатываются либо на Python для удалённых эксплойтов, либо на C для локальных эксплойтов.

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

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

Вы поняли! Rust — идеальный язык для разработки эксплойтов.

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

7.1 Где искать эксплойты

В главе 5 мы видели, где искать известные уязвимости: на www.cvedetails.com, а в главе 6 — как находить собственные уязвимости.

Затем у вас есть 2 возможности:

Привет хабр! Извиняюсь, что все это время я к сожалению не придерживался старого графика 1 глава - 1 день, так, как был сильно занят, но сейчас за этот день готовы целых 2 главы — 5 и 6 вот как пример перевода отлаженый кусок 5 главы:

5.3 Поисковые системы

Назначение поисковой системы — превратить океан данных в искомую и пригодную для действий информацию.

Поисковая система состоит из следующих частей:

И снова привет хабру! Сегодня подправил 4 главу, исправил опять таки то, что режет слух. 4 глава уже лежит на гитхабе путь тот же. И вот как пример правленого перевода подраздел 4.2 Трейты:

4.2 Трейты

Трейты — это эквивалент интерфейсов из других языков (с некоторыми отличиями).

Так как определение термина через его синоним не очень полезно, посмотрим, что это означает в коде:

Привет хабр еще раз! Сегодня мы обсудим тему из книги Black Hat Rust, а именно подраздел первой главы «Почему Rust?». Этот кусок текста уже полностью адаптирован и ничего больше не должно резать слух.

Итак: Почему Rust?

Мир безопасности (и, в более широком смысле, софта) страдает от слишком большого количества языков программирования со слишком большим количеством граблей. Приходится выбирать между быстрым, но небезопасным (C, C++…) и медленным, но в основном безопасным (Python, Java…).

Может ли кто‑то быть экспертом во всех этих языках одновременно? Я так не думаю. Бесчисленные баги и уязвимости в инструментах атакующих доказывают, что я прав.

А что, если бы вместо этого у нас был один‑единственный язык?

Язык, который, будучи освоенным, удовлетворял бы все потребности области:

Привет хабру! Снова.

В общем пока вы голосуете в опросе и пока побеждает Malware Development for Ethical Hackers от Zhassulan Zhussupov

Я исправляю некоторые неправильности перевода, которые режут слух пока что почти закончил 3 главу Black Hat Rust поэтому довольно скоро будет релиз уже полностью исправленной книги и потом возьмусь за Black Hat Ruby и надеюсь за то время, что я буду править перевод книг в опросе проголосует побольше людей вот ссылка если кто не видел прошлый пост https://forms.gle/pny2pD7G7f5Fhtno7

Связаться со мной или сообщить о некоторый неправильностях перевода например можно в группе в тг вот ссылка https://t.me/+Xome2X_nj-wyMDcy только не переусердствуйте!

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

В OpenIDE появилась поддержка Ruby — с подсказками в редакторе, навигацией по коду, запуском и отладкой приложений. Работать с базами данных и Docker-контейнерами тоже можно прямо в IDE.

А в OpenIDE Pro можно подключить Claude Code, Codex и других AI-агентов, поручать им задачи и проверять изменения в том же окне.

Что же мне перевести следующим?

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

В общем, как я и обещал вот опрос https://docs.google.com/forms/d/e/1FAIpQLSdZnLR_qH0_Yiutv_F4KNBEH4GWYlgLzo-yWOjObn_2UdScjg/viewform?usp=header

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

Причём самое обидное, что для этого AI-агенту даже не нужно писать плохой код. Наоборот, чем лучше он справляется, тем интереснее становится проблема.

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

Теперь вы открываете редактор, объясняете агенту, что нужно сделать, и получаете готовую реализацию.

Если всё прошло хорошо, остаётся посмотреть diff, запустить тесты, оценить результат и принять изменения.

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

И вот у меня вопрос: а если человеку нравился именно этот процесс?

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

Мне кажется, мы довольно много обсуждаем, насколько AI-агенты увеличивают производительность программистов, и гораздо меньше говорим о том, как они меняют само удовольствие от разработки.

А ведь программисту, вообще-то, должно нравиться программировать.

Перевел на русский 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.

GitHub: https://github.com/eugenyh/sketchup-step-importer

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

DHH за год прошёл от страха потерять навык из-за AI до отказа писать код руками. Почему разворот одного инженера меняет то, какие инструменты другие считают допустимыми, и где заканчивается применимость его опыта.

Мысли про 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/Elixir в Go, часть 1

Когда я начал писать на Go после опыта с Ruby и Elixir, одной из самых непривычных вещей стало отсутствие консоли, в которой можно напрямую вызывать код приложения.

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

Набираешь:

bundle exec rails c

И через несколько секунд уже находишься внутри приложения и можешь работать с его кодом и данными. Только вместо кнопок у разработчика код. Надо помнить: «С большой силой приходит большая ответственность». © Дядя Бен.

Например, приходит вопрос:

Сгенерированная картинка для привлечения внимания. Промпт: «Продемонстрируй, что всё новое — это хорошо забытое старое» (нет)

За последний год инструментов для агентной разработки стало столько, что в них легко потеряться: одни обещают сохранять контекст между сессиями, другие — «понимать» всю кодовую базу целиком, третьи — память, планирование и автономность в одном флаконе. На GitHub каждую неделю появляются репозитории с внушительным (и не всегда честно заработанным) числом звёзд, которые обещают всё и сразу, а на поверку оказываются README-проектами; другие честно работают на демо-репозитории и падают с OOM при первой же встрече с реальным энтерпрайз-проектом — и так далее, список можно продолжать долго.

Осенью прошлого года я пользовался связкой Claude + RooCode + семантический поиск на Ollama, и это был мой основной рабочий инструмент — ровно до того момента, как связка перестала работать (об этом чуть ниже). Я решил полностью пересесть на Claude Code и начал искать замену семантическому индексу, но так её и не нашёл: альтернативы для меня просто не работали — на монолите в 3,5M+ строк они либо индексировались часами, либо требовали отдать код в облако (и заплатить немалую сумму за эмбеддинги!!!), либо поддерживали Ruby, мягко говоря, номинально. В итоге я принял непростое для себя решение сделать собственный инструмент — начав с форка простого движка семантического поиска на Ollama + Qdrant — и, что характерно, сделал: полностью локальный, чтобы ни код, ни его производные (индекс, эмбеддинги, граф вызовов) никуда не уезжали. На сегодняшний день на него ушло больше полугода (и, честно признаюсь, не одна сотня чашек чая).

11 сентября исследователи Nightingale Collective опубликовали разбор RubyHack и связали майскую кампанию в RubyGems с внутренними агентами OpenAI. По их версии, скрипты внутри пакетов запускали код в инфраструктуре RubyDoc, собирали открытые данные с сайтов британских муниципалитетов и публиковали результаты обратно в реестр. В нескольких образцах исследователи также обнаружили попытки получить чужие API-ключи RubyGems.

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

Одной из точек входа стала обычная сборка документации. В пакет добавляли .yardopts – файл параметров генератора YARD – с указанием загрузить Ruby-скрипт. Когда для пакета запрашивали документацию на RubyDoc, сборщик обрабатывал этот файл и запускал вложенный код. Такое поведение соответствует механике самого YARD: параметр --load загружает указанный Ruby-файл перед выполнением команды.

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

Отдельные пакеты обращались к старому endpoint выдачи API-ключей. В нём действовала ошибка кэширования: при определённых условиях CDN мог сохранить ответ с legacy-ключом и до часа отдавать его следующим запросам на том же узле. RubyGems исправил проблему 9 июля, очистил кэш, отозвал legacy-ключи и затем отключил старый endpoint.

Как я собрал на чистом Ruby мультиплексор поверх pipeline mode из libpq, обогнал классический пул соединений на 27% при вдвое меньшем числе коннектов — а потом обнаружил, что почти весь оставшийся CPU вообще не мой.