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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2 Трейты

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

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

Итак: Почему 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-агенты увеличивают производительность программистов, и гораздо меньше говорим о том, как они меняют само удовольствие от разработки.

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

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

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

Сразу скажу перевод неофициальный, если кто то против, пост могу и удалить (надеюсь не придется).

Сейчас уже готовы сразу две книги это Black Hat Rust и Black Hat Ruby еще в планах переводить еще книги тоже технические например какую-небудь книгу по C++ или что то подобное, честно пока идей нет скоро если вам пост зайдет сделаем опрос что в итоге то переводить следующим. Если вдруг хотите поддержать мой перевод то в репо есть криптокошелек там все указано (Ну это если прям сильно захочется, а так комменты и например звезды на репо на гитхабе это тоже поддержка которой я буду очень благодарен)

ну а вот и ссылка на репо https://github.com/smokeplay250-png/black-hat-ru

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

Посмотрел выступление 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%.

Когда я начал писать на 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 вообще не мой.

Я занимаюсь изучением синтаксиса языков программирования и пытаюсь отделить фундаментальные закономерности от исторических случайностей. Одна из таких случайностей - почти повсеместное использование терминов выражение (expression) и инструкция (statement) при описании и классификации синтаксиса языков программирования.

Интуитивно кажется, что 2 + 2 и if (x) { foo(); } - это совершенно разные сущности, но при более глубоком анализе оказывается, что подобное разделение искусственное и возникло из-за архитектурных особенностей вычислительных машин почти полвека назад и с тех пор просто «переходит» из языка в язык.

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

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

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

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

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

Привет, Хабр!

Давайте сразу начистоту: я не профессиональный программист. Я системный администратор и DevOps-инженер. Мой день состоит из автоматизации процессов, настройки серверов, написания скриптов и бесконечной рутины. И, конечно же, работы с тикет-системами, главная из которых — Jira.

Если есть необходимость взаимодействовать с Jira из Ruby-кода, то обычно выбирают гем jira-ruby — заслуженный стандарт индустрии.

Однако, попробовав использовать его для простых скриптов автоматизации в админской экосистеме, я понял: этот инструмент слишком избыточен и тяжел для сисадминских нужд. Мне хотелось чего-то простого, легкого и понятного. Так родилась rujira — моя собственная легковесная библиотека для работы с Jira REST API.

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

Решили мы добавить Rate Limit заголовки к ошибкам SubscriptionRequiredError, чтобы фронт понимал, какие лимиты превышены. Но внезапно при обработке ошибки пропал request. А значит — нет ни headers, ни current_user. Куда он делся и как это починить?

В любой компании, рано или поздно встает вопрос контроля сроков реакции и выполнения тех или иных задач. В статье речь пойдет о желании внедрить SLA (Service Level Agreement) в Redmine, о том как попытка найти и установить готовое решение, обернулось мини исследованием.

У меня было Falcon-приложение на Async, и в нём накопились задачи, которые надо было выполнять где-то рядом: cron-задачи, интервалы, отложенные джобы. Классический ответ — Sidekiq + Redis. Но ради трёх задач в минуту тащить в проект Redis с отдельным контейнером, отдельным процессом и отдельной точкой отказа казалось перебором. А альтернативы либо тянули за собой Postgres (который в большинстве проектов уже занят бизнес-логикой и плохо реагирует, когда на него вешают ещё и очередь задач), либо не дружили с Async event loop.

Так родился async-background — лёгкий планировщик, у которого нет внешних зависимостей кроме SQLite, который живёт в том же event loop что и Falcon, и в котором я смог реализовать ещё одну важную для меня штуку — управляемую утилизацию воркеров: можно явно сказать «эти два воркера только cron, эти два только очередь», или прибить конкретную задачу к конкретному процессу, без переписывания кода.

В статье — история создания гема: какие альтернативы я смотрел и почему они не подошли, какие принципы я зафиксировал на берегу, какие технические находки получились по ходу (min-heap вместо тиков, две шкалы времени, CRC32-шардинг для multi-process safety, UNIX-сокеты для мгновенного wake-up очереди), и какие гочи я нашёл лбом — включая историю про то, как Docker overlay2 ел мою SQLite базу под нагрузкой на staging.

Это адаптация моей англоязычной статьи на Medium

Всем известный Ruby on Rails, как самый яркий пример использования DSL, позволяет разработчикам абстрагироваться от низкоуровневых деталей реализации и сосредоточиться на бизнес-логике. Написание кода выглядит очень лаконично и выразительно, но как это работает? Давайте разберемся на простом примере.

"Loom" означает "ткацкий станок" - так назывался проект по добавлению асинхронности в джаву. Тяжёлые системные потоки заменили легковесными виртуальными потоками. Потоки и нити в английском называются одинаково - thread - отсюда название.

Проект успешно внедрили пару лет назад, и я, к сожалению, это полностью пропустил. Основная причина, конечно - что я в принципе не ожидал от джавы никаких прорывов (и оказался на 100% неправ!) Ну и, как бэкенд-разработчик на питоне, я не очень-то слежу за развитием JVM-языков.

Но исправляюсь: Project Loom - это блестящая идея. Учитывая, что его внедрили совместимым образом, и почти не было ломающих изменений. Я считаю, это оптимальная реализация асинхронности для высокоуровневого серверного языка.

Уже почти все использующие JVM языки переехали на новую версию JVM, и, таким образом, на проект Loom: деваться им некуда. Так что, есть надежда, что это изменение откроет новую главу для некоторых из них. Есть также предположение, как оно может повлиять на скриптовые языки, такие как питон. Гипотеза только.

Также, вы узнаете, почему Гвидо ван Россум не ошибся, когда добавлял async/await в питон, а Мацумото — создатель Ruby — тоже угадал, когда, наоборот, отказался от async/await.

25 декабря 2025 года состоялся релиз языка программирования Ruby 4.0.0, отличающегося высокой эффективностью разработки программ и вобравшего в себя лучшие черты Perl, Java, Python, Smalltalk, Eiffel, Ada и Lisp. Исходный код проекта Ruby распространяется на GitHub под лицензиями BSD (2-clause BSDL) и Ruby, которая ссылается на последний вариант лицензии GPL и полностью совместима с GPLv3.

Привет! Меня зовут Фёдор Засечкин. С 2023 года я руковожу группой разработки операционной платформы в Купере. Наша команда отвечает за стабильность и развитие сервисов, которые обеспечивают сборку и доставку заказов, а также найм и выход партнёров в смены.

Последние два года наша ключевая задача — микросервисная трансформация. Мы постепенно распиливаем монолит, перераспределяя нагрузку по сервисам. На сегодня более 1 000 RPS HTTP-трафика уже ушло с монолита; до полного завершения осталось около 30 RPS и часть межсервисных интеграций.

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

Некоторые считают Java раздутым монстром, а Rust — чемпионом производительности. Но что, если взглянуть на современную Java с Vector API и многопоточностью? 

В новом переводе от команды Spring АйО посмотрим на запуск масштабной симуляции частиц и сравним результаты. Правда ли, что бывалая Java всё ещё умеет удивлять? 

Сравнение performance-а языков всегда было холиварной темой. Рекомендуем расценивать статью как приглашение к конструктивной дискуссиии, а не как призыв к конкретному действию.

Создатель языка Ruby Юкихиро Мацумото (Yukihiro Matsumoto) объявил о переводе под управление основной команды разработчиков языка Ruby (Ruby Core Team) GitHub‑репозитория, в котором развиваются инструментарии RubyGems и Bundler для работы с каталогом пакетов rubygems.org.

Пять бывших сопровождающих проекты RubyGems.org, RubyGems и Bundler, включая владельца торговой марки Bundler, представили альтернативный проект Gem Cooperative. Эта платформа подконтрольна сообществу и в ней используется открытая модель управления, по аналогии с проектом Homebrew.

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

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

На 23 июля 2025 года AWS удалил мой аккаунт, которому было 10 лет, и каждый байт данных, который я там хранил. Без предупреждения. Без льготного периода. Без возможности восстановления. Произошла полная цифровая аннигиляция.

Ниже я расскажу историю о катастрофической внутренней ошибке в AWS MENA, 20 днях кошмарного общения с поддержкой, в ходе которого я так и не получил прямого ответа на вопрос «Мои данные ещё существуют?», и о том, что всё это показывает в отношении доверия облачным провайдерам.

Я — да. И вместо того чтобы мириться с ручным копированием, гигантскими .gitignore и вечными конфликтами, написал dmp — инструмент, который:
 Отслеживает, откуда взялся каждый файл,
 Автоматически разрешает конфликты (или даёт контроль),
 Не ломает IDE (никаких симлинков!),
 Работает с любыми языками и фреймворками.

Для кого:
— Разработчики плагинов/модулей,
— Те, кто устал от git-submodules и rsync,
— Все, кто хочет чистый workflow без монрепозитория.