DevTools Radar
8 subscribers
7 photos
Download Telegram
Channel created
Channel photo updated
Первый пост — как маркер. Дальше будет регулярно
Первый пост — как маркер. Дальше будет регулярно
Запускаем. Внутри — кейсы, цифры, иногда мнение. Без воды
Канал об одном: инструменты. Без сторонних тем
Канал открыт. Здесь будут разборы и наблюдения по теме «инструменты»
**Июньский сбой обходных схем — не “сломали всё”, а поменяли правила игры.**
У многих одновременно просели связки на базе `xray + VLESS + REALITY`: не потому что протокол внезапно умер, а потому что фильтрация начала бить по _паттерну_ соединения, а не по конкретному хосту.

Что видно на практике:
- первые пакеты проходят, дальше соединение рвётся;
- часть конфигов с одинаковыми параметрами начинает палиться массово;
- чем «типичнее» выглядит трафик, тем быстрее его режут.

Схема стала ближе к **поведенческому детекту**: смотрят не только на IP/домен, но и на сигнатуры TLS, последовательность рукопожатия, схожесть конфигов между пользователями.
Итог простой: старый шаблон больше не даёт стабильности.

Для тех, кто автоматизирует инфраструктуру, вывод такой:
`1)` не держать один туннель на всё;
`2)` иметь запасной стек;
`3)` мониторить не только аптайм, но и качество handshake. ⚙️
**Linux не обязан быть проектом на вечер.**
Если у вас дистрибутив уже запускает браузер, IDE, Git и видеомонтаж — возможно, вы уже выиграли.

Ключевая мысль простая: **настройка ≠ работа**.
15 лет назад многие жили в режиме `dotfiles`, `i3`, `polybar`, 400 строк `~/.vimrc` и скриптов на bash для каждого монитора. Это круто, пока не начинаешь считать время: час на кастомизацию сегодня — минус час из работы завтра.

Что изменилось технически:
- GNOME и современные DE стали реально usable из коробки
- драйверы, масштабирование, цветовые профили и мультимониторность уже не требуют шаманства
- Fedora и другие свежие дистрибутивы дают нормальный baseline для dev-рабочей станции

Схема простая:
`ставим систему → проверяем 5 базовых сценариев → дописываем только то, что экономит время каждый день`

Хороший тулкит — это не максимальная кастомизация.
Это минимальный набор, который не мешает кодить, собирать, пушить и жить.
А всё лишнее — в архив 🧰
**NetFix** — GUI-обёртка для `Zapret` и `TgWsProxy`, которая убирает ручной админский зоопарк: батники, конфиги, консоль и вечные «а почему у меня опять не работает Telegram?» 🚀

Что делает автоматом:
- сама скачивает нужные бинарники
- сама подхватывает и применяет настройки
- сама следит за состоянием
- сама обновляется

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

Отдельный бонус — интерфейс не для галочки: в нём даже есть ритм\-игра. Значит, автор реально собирал инструмент не только «чтобы работало», но и чтобы им хотелось пользоваться.


Доп. контекст по dev saas — @devtools_brief
**Пауки, которых в вебе не хотелось бы видеть в живом виде** 🕷️

Короткий полевой гайд по тем, кого реально лучше не трогать в европейской части России: каракурт, тарантул, сольпуга и несколько менее медийных, но не менее неприятных соседей по фауне.

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

Мини-схема поведения:
`заметил -> не трогай -> отойди -> закрой доступ детям/животным -> при укусе к врачу`

Пара цифр без паники: для каракурта критичны не «размеры монстра», а **токсичность яда** и скорость развития симптомов. Если после укуса пошли нарастающая боль, слабость, потливость, спазмы — это уже не формат «перетерплю».

Практика простая: **не хватать руками, не прижимать обувью, не пытаться “проверить на ядовитость”**. В полевых условиях это тот самый баг, который дешевле предотвратить, чем дебажить.
ИИ в разработке сейчас продают как `ускоритель всего`: код пишет, тесты генерит, PR-ы разруливает, docs обновляет. На бумаге — магия. В реальности у многих команд получается другой пайплайн:
`prompt → сгенерил → открыл PR → человек всё равно перепроверяет → баги ловит QA → правки руками`

Проблема не в самом ИИ, а в том, что его часто внедряют **как замену процесса**, а не как инструмент в пайплайн. И вот где ломается экономика:

- скорость генерации высокая, а скорость проверки — человеческая;
- качество сильно гуляет от контекста и формулировки;
- агент умеет уверенно наделать лишнего кода и скрытых регрессий;
- итоговая стоимость — это не `0`, а часы ревью, отладки и отката.

Хороший сценарий для ИИ в dev-потоке простой:
`черновик → ограниченная задача → автопроверка → человек-валидатор`

То есть не “пиши за меня всё”, а “сократи рутину там, где уже есть чёткие границы”. Иначе получаем не ускорение, а новый слой шума поверх старого CI/CD.
Китай не делает «один Falcon 9-клон», а распараллеливает ставку на несколько многоразовых ракет сразу. Это выглядит не как хаос, а как R&D на максималках: разные команды тестируют разные связки — керосин/метан, разные двигатели, разные схемы возврата 1-й ступени и разные бюджеты на разработку 🚀

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

Параллельные программы позволяют:
— быстрее отстреливать гипотезы;
— сравнивать решения вживую;
— не зависеть от одного подрядчика;
— собрать внутреннюю конкуренцию за деньги и инженеров.

По сути, Китай строит не одну ракету, а конвейер компетенций. И именно это может дать самый быстрый путь к серийной многоразовости ⚙️
Самый суровый кодовый замок СССР — это почти железный CLI для двери: вводишь комбинацию, а дальше внутри щёлкает не софт, а чистая электромеханика.

Такие замки ставили не только в подъездах, но и там, где домофонов не было вообще: на служебных дверях, складах, техпомещениях. Логика простая, как у bash-скрипта: нажатие кнопок → дешифрация кода → срабатывание реле → открытие защёлки.

Почему «суровый»? Потому что в конструкции минимум электроники и максимум отказоустойчивости. Нечему зависать, нечему обновляться, нечего ломать удалённо. Часто это были контактные панели, механические узлы и релейная схема с очень приземлённой логикой работы. Для своего времени — железобетонный access control.

Интересный момент: такие замки обычно проектировали без привычного нам UX. Никаких подсказок, звуковой вежливости и защиты от тупых ошибок. Нажал не ту цифру — вводи заново. Зато для обслуживающего персонала это был понятный и ремонтопригодный девайс: прозвонка, реле, контакты, питание — и уже ясно, где баг. 🔧

Вот вам и советский security stack: меньше магии, больше физики.
Инструмент дня: личный центр управления VLESS для Android TV.

Автору надоело руками перекидывать конфиги на приставках, ТВ и телефонах близких — особенно там, где пульт и длинный `vless://...` это уже UX-преступление. В итоге он собрал Android‑приложение, которое делает из хаоса нормальный рабочий поток: выбираешь профиль, применяешь конфиг, проверяешь результат, переключаешься без ритуалов.

Что здесь интересно технарю: проблема решена не “магией”, а автоматизацией повторяемого процесса. Вместо ручного импорта — централизованное управление своими конфигами и устройствами. Для тех, кто держит дома зоопарк из ТВ-приставок, старых телефонов и роутерных костылей, это уже не игрушка, а маленький control plane 🛠️

Практический вывод простой: если действие повторяется чаще раза в неделю и бесит на Android TV — его почти всегда стоит вынести в отдельный тул. Меньше кликов, меньше ошибок, меньше объяснений близким.
Whoosh раскатывает кикшеринг в Мехико — и сразу с плотной сеткой до 5 000 электросамокатов. Для сервиса это уже второй город в Мексике: после Сан-Педро компания заходит в столицу, где трафик, плотность поездок и короткие last-mile-маршруты могут дать совсем другую экономику.

Что важно по-радарному: международное направление у Whoosh уже приносит около 20% выручки, так что это не “проверим гипотезу”, а нормальный ростовой контур. Мехико — большой рынок с высоким ежедневным спросом и понятной задачей для микромобильности: заменить часть такси и общественного транспорта на коротких дистанциях.

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

Для кикшеринга это не просто новый город, а тест масштаба: сможет ли модель держать utilization и маржу на плотном мегаполисе.