tgindex

Будни разработчика

описание

Блог Lead JS-разработчика Автор: @bekharsky По рекламе: https://telepost.pro/ch/id2415 или https://t.me/it_adv Чат: https://t.me/htmlshitchat №5001017849, https://www.gosuslugi.ru/snet/679b74f8dad2d930d2eaa978

← к каналу@htmlshit
14 635
подписчиков
Охват к подписчикам
9,1%
ERR
Реакции к просмотрам
0,61%
446 на 50 постов
Пересылки к просмотрам
1,08%
785
Постов в день
1,4
всего 439

Где отзываются чаще

доля реакций к просмотрам
  • 10 авг.#тред дня Забытое воровство из X! Лонгрид от Димы Рожкова: «Собес — не место для советов». Сразу ссылку, ну и копия. Спасти компанию за 5 минут Ваши вопросы к представителям компании на собеседовании - очень важный этап. Он же может стать решающим. Я как то на собеседовании в Мету на менеджера спросил могу ли я уволить всю команду в один день и нанять новую. В те далекие долэйофные годы следующего этапа не последовало. Это был один из вопросов Бугаенко "на менедждера", в Лондон я переезжать не планировал поэтому ради прикола решил спросить. Один раз живем. Так вот. По следам треда @beshkenadze решил написать, что стоит спрашивать, а какие вопросы стоит задавать когда уже пройдете испытательный срок. Во-первых: совершенно точно нужно задавать вопросы! Особенно если вы идете на сеньорную позицию. Если у вас нет вопросов - это очень плохой сигнал: • Вы читали про компанию и ее бизнес? • Вам совсем не важно как с кем и с чем вы будете работать? • Ничего не хотите добавить к своим ответам? Что точно не стоит спрашивать Давать непрошеные советы и критиковать выбор людей. Даже если мягко. Во-первых у тебя околонулевой контекст. Даже если ты изначально спросил какая у них платформа (хороший вопрос), а потом начинаешь критивовать и сокрушаться, что они все выбрали не правильно. Тебе скорее всего ответили прямым ответом: У нас технология Х. У тебя нет необходимых данных, метрик и причин почему у них так. И за одну минуту ответа ты не сможешь открыть тупым глаза на их ошибки и заработать авторитет. Но ты можешь показать, что ты с порога несогласен. Начинаешь давать советы неразобравшись. Зачем тебя брать если ты уже недоволен с чем тебе придется работать? На собеседовании ты продаёшь не только экспертизу, но и предсказуемость. Компания (особенно если это уже работающий бизнес, а не совсем зелёный стартап) хочет понять: • Ты сможешь встроиться в существующую систему? • Ты будешь решать их проблемы или создавать новые? • Ты уважаешь чужой контекст или сразу начинаешь мерить всё своей меркой? Критиковать само собеседовение тоже не стоит. Особенно в лицо людям, которые к дизайну собеседования не имеют отношения. Как например спрашивать, пишут ли программисты алгоритмы каждый день на работе? Кому что кроме своей раздражительности ты этим вопросом хочешь показать? Особенно если ты НЕ МОЖЕШЬ решить задачу. Что стоит спрашивать На собесе ты исследователь и дипломат. Молчать совершенно точно нельзя, а задавать качественные вопросы, которые показывают сеньорность. Если ты молчишь и только киваешь, ты выглядишь как исполнитель, а не как человек, который будет влиять на архитектуру. Хороший баланс — задавать вопросы, которые раскрывают ситуацию, а не оценивают её. 1. Про нагрузку и масштаб «Какая сейчас нагрузка? Какие планы по росту на год-два?» 2. Про текущие боли «Какие самые болезненные проблемы прямо сейчас в инфре/деплое/костах?» 3. Про структуру команды «Как устроена команда? Кто принимает архитектурные решения? Как выглядит процесс изменений?» 4. Про бизнес-контекст «Какие требования бизнеса сейчас важнее всего: скорость фич, косты, надёжность?» 5. Про квалификацию и процессы «Какой уровень экспертизы в команде по платформе/куберу/терраформу?» 6. Про историю развития «Это первая версия системы? Как бы выглядела идеальная система для этой задачи? Какие риски в текущей архитектуре вы видите?» 7. Можно урвать эти 5 минут и наоборот уточнить свой ответ, если вы осознали, что что-то недосказали. Этой возможностью вообще довольно редко пользуются. Самый сильный сигнал сеньорности — это когда ты: задаёшь точные вопросы; демонстрируешь, что понимаешь компромиссы; оставляешь пространство для того, что у них могут быть на все веские причины о которых тебе не рассказали. На собеседовании твоя главная задача — собрать максимум информации и показать, как ты думаешь, а не «спасти» компанию от страшной ошибки за 5 минут. А уже после офера (или испытательного срока), когда ты внутри и у тебя есть полный контекст и выстроены отношения блядь, — можно и нужно спорить, отстаивать свою точку зрения. #cv #interview #собеседование #x1,96%
  • 15 авг.Проект от подписчика! Напоминаю, что я выкачу любую статью или проект от вас, не стесняйтесь писать. Презентация? Выступили на митапе? Хотите поделиться интересной статьёй — добро пожаловать! Всем привет! Меня зовут Василий, я разработчик из Хельсинки. В свободное время занимаюсь проектами на стыке веба, C++ и криптографии. Один из них это AmethystXMR: https://amethystxmr.github.io/ Это браузерный Monero-кошелёк: нативный C++ код Monero собран в WebAssembly, а вокруг него сделан интерфейс на React. Ключи остаются у пользователя в браузере, там же приложение сканирует блокчейн и формирует транзакции. На скриншоте кошелёк называется [object Promise] - это не баг, а мое чувство юмора: люблю вписывать в формы значения вроде undefined, null, NaN, Invalid Date, ReferenceError, TypeError, [object Object], Cannot read properties of undefined. Смешно же. AmethystXMR полностью рабочий: можно создать или восстановить кошелёк, отправлять и получать XMR, подключаться к своей ноде, использовать QR-коды. Можно запускать и в Tor Browser, в том числе с onion-нодами. Еще есть поддержка multisig. В Monero он устроен довольно интересно и не совсем так как в Bitcoin. Я рассказывал об этом на MoneroKon, а по мотивам доклада вышел подробный пост со схемами: https://coin.space/how-does-monero-xmr-multisig-work Недавно еще разбирался с неприятным багом: платеж отображался как потерянный, хотя в итоге оказалось, что деньги никуда не пропали. Всю историю расследования и того, как удалось найти проблему, описал здесь: https://www.reddit.com/r/MoneroMeansMoney/comments/1v5dsx2/the_story_of_a_lost_and_found_payment/ Еще с MoneroKon есть запись моего второго доклада - про Lightning Network: https://www.youtube.com/watch?v=obFwB_KA7pk Исходники проекта: https://github.com/amethystxmr/amethystxmr.github.io Если появятся какие-то вопросы по проекту, WebAssembly, Monero или докладам - спрашивайте, отвечу.1,43%
  • 9 авг.#инструмент дня Вы, наверное, уже наслышаны от обладателей айфонов про AirDrop и дикпики. Кроме шуток, передать файлы по локальной сети между двумя своими устройствами должно быть максимально просто же! Без ковыряний в Network Discovery, настроек Samba и так далее. И такое решение есть, даже с открытым кодом: LocalSend. Сайт: https://localsend.org/ Написано на Dart и Flutter, работает на всех разумно доступных платформах: Windows, Linux, MacOS, Android, iOS. Не опирается на один протокол, а перебирает все доступные и даже может запустить свой собственный сервер по необходимости. В крайнем случае, можно донастроить. Никаких облаков, всё по локальной сети. Поддержка нескольких получателей, поддержка буфера обмена. В общем, если у вас дома зоопарк устройств и пока не хватило времени настроить что-то иное, или лучше Samba вы ничего в жизни не видели — вот это самое то. #flutter #localsend #airdrop #network #бородач1,23%
  • 7 июл.#инструмент дня Появился Nub — новый «всё-в-одном» тулкит для JavaScript. Название, конечно, опасное: любой пост про него автоматически звучит как обращение к аудитории. GitHub: https://github.com/nubjs/nub Site: https://nubjs.com/ Кто уже догадался, откуда у названия ноги растут? Да, оттуда. Но есть нюанс: Nub не пытается заменить Node.js. Смысл такой: дать разработчику всё приятное, что люди обычно хвалят в Bun — быстрый запуск, TypeScript из коробки, меньше зоопарка CLI, — но оставить выполнение кода на старом добром Node.js. Nub — это один Rust-бинарник поверх обычного Node.js. Он умеет: — запускать TypeScript/TSX/JSX без отдельного build step — автоматически подхватывать tsconfig paths — грузить .env — импортировать YAML/TOML/JSONC/JSON5 — работать как быстрый runner для package.json scripts — заменять npx/pnpm exec — ставить зависимости — управлять версиями Node — делать watch mode То есть вместо набора из tsx, ts-node, dotenv, tsconfig-paths, nvm, pnpm run, npx и пары заклинаний из README вашего монорепо — один nub. Главный selling point не «мы быстрее всех, потому что переписали мир на Zig, потом по-ковбойски переписали его на Rust с помощью ИИ, а теперь давайте все сделаем вид, что это нормальный жизненный цикл инфраструктурного рантайма». Код в итоге выполняет обычный Node.js. Nub просто добавляет слой удобства: транспиляцию через oxc, хуки резолвинга, полифиллы и быстрые команды вокруг проекта. На сайте, конечно, бенчмарки красивые: nub run — сильно быстрее npm run / pnpm run nubx — сильно быстрее npx nub install — быстрее pnpm и, по их тестам, даже чуть быстрее bun install nub index.ts — примерно как обычный node по старту и быстрее tsx Плюс отдельно упирают в supply-chain безопасность: build scripts по умолчанию не запускаются, свежие подозрительные релизы можно придерживать, вредоносные пакеты проверяются через OSV. Выглядит как очень понятная реакция на последние годы JS tooling: всем понравилось, что Bun быстрый и удобный, но не всем хочется тащить в прод ещё один почти-Node, который иногда внезапно оказывается «почти», а потом ещё и внезапно оказывается почти переписанным. Nub говорит: а давайте оставим Node, но перестанем страдать от того, что вокруг него исторически вырос целый огород одноразовых CLI. Пока штука свежая, я бы не тащил её сразу в критичный CI без проверки, но для внутренних тулов, dev-скриптов и монореп — очень интересно. #node #bun #typescript #oxc #rust1,17%
  • 3 авг.#статья дня В CSS предлагают добавить роутинг Сейчас без JS кастомные анимации перехода по страницам практически невозможны: ловить переход, смотреть исходный и конечный URL, определять, по какой ссылке кликнули, и уже после этого выбирать нужный View Transition. В черновике CSS Route and Navigation Matching предлагают описывать эту логику прямо в CSS. Всё можно описать декларативно, если ты достаточно смел. Ну вы поняли. Например, сначала объявить маршруты: @route --home { pathname: url-pattern("/"); } @route --article { pathname: url-pattern("/articles/:id"); } А потом задать отдельную анимацию для перехода с главной на статью: @navigation (from: --home) and (to: --article) { @view-transition { navigation: auto; types: slide-left; } } Для перехода назад можно использовать другой тип анимации. Кроме @route и @navigation, в черновике есть :nav-source — селектор элемента, с которого начался переход, и :link-to() — селектор ссылок, ведущих на определённый маршрут. Самый понятный пример — список карточек. Пользователь нажимает на изображение, открывается отдельная страница, а именно эта картинка плавно превращается в большое изображение статьи. Сейчас для такого обычно нужен JavaScript, который найдёт нажатый элемент и назначит ему view-transition-name. Здесь это хотят сделать без ручной обвязки. Роутер это, конечно, не заменяет. CSS не будет загружать страницы или управлять историей браузера. Он просто сможет выбирать стили и анимации с учётом того, между какими адресами происходит переход. Пока это ранний Editor’s Draft, поэтому синтаксис ещё вполне может измениться. Попробовать можно в Chrome Canary с включённым Experimental Web Platform Features. Подробный разбор — у Ван Дамма нашего Брамуса, сам черновик — на сайте CSSWG. #route #css #view #transition1,01%
  • 2 июл.без подписи0,98%
  • 13 июл.без подписи0,96%
  • 19 июл.без подписи0,89%
  • 5 авг.#заметка дня В npm нашли ChainDrop — червя, который успел выпустить 2212 заражённых версий в 444 пакетах. Стартовой точкой стал keyv@6.0.0. После установки пакет искал npm-токены и, если находил, публиковал заражённые версии других пакетов, к которым у владельца токена был доступ. Так заражение пошло дальше по экосистеме и затронуло, среди прочих, flat-cache, file-entry-cache и cache-manager. Код запускался через preinstall. Пакет скачивал Bun с GitHub и выполнял обфусцированный скрипт, который собирал токены GitHub, npm, PyPI, AWS, GCP, Azure, Docker, Kubernetes, Vault и других сервисов. В GitHub Actions он ещё и пытался достать секреты из памяти runner-процесса. Заодно менялись конфиги Claude Code и VS Code. Поэтому заражённый репозиторий мог сработать не только при npm install, но и просто при открытии проекта или запуске агента. С keyv есть отдельный нюанс. Вредоносная версия была опубликована через официальный GitHub Actions workflow, с npm Trusted Publishing и валидной SLSA provenance. То есть provenance не была подделана. Она честно подтверждала, что пакет собран официальным workflow из конкретного коммита. Просто сам коммит уже содержал вредоносный код, потому что аккаунт мейнтейнера был скомпрометирован. Поэтому наличие attestation здесь ничего не гарантировало. Она подтверждает происхождение сборки, но не авторизованность изменений в репозитории. Если одна из заражённых версий попала в CI или локальное окружение, откатить пакет недостаточно. Токены и секреты, доступные этому окружению, придётся перевыпустить. StepSecurity #npm #attack0,88%
  • 28 июл.Проект от подписчика! Напоминаю, что я выкачу любую статью или проект от вас, не стесняйтесь писать. Презентация? Выступили на митапе? Хотите поделиться интересной статьёй — добро пожаловать! Всем привет! Меня зовут Ильдар. Я легаси-подписчик этого канала – уже около 6 лет, всегда с интересом наблюдал посты про личные проекты и хочу сегодня поделиться своим. Я пришёл в команду как Frontend Lead и получил несколько проектов, которые до этого в основном развивали джуны. Кодовая база и процессы были довольно хаотичными, а качество оставляло желать лучшего. Я привык использовать системы трекинга ошибок вроде Sentry и Bugsnag. Но здесь возникло сразу несколько проблем. Проекты были на старом стеке, версии Node для сборки варьировались от 9 до 16, а сам продукт физически находился в России. Использование сторонних сервисов было рискованным и в любой момент можно было потерять к ним доступ. В итоге production-баги отлавливались вручную: через поддержку, тестировщиков и самих клиентов. Позже, когда из-за кризиса рынка команда сократилась, стало понятно, что такой подход больше не работает. Нужно было автоматизировать сбор ошибок, но я не хотел просто получать бесконечный поток событий. Хотелось видеть уже готовые проблемы, сгруппированные по смыслу, а ещё добавить AI-объяснение, чтобы происходящее могли быстро понять не только разработчики, но и менеджеры. Так появилась идея сделать собственный сервис. Так родился RetraceKit. За несколько месяцев вечерний pet-проект вырос в полноценную платформу: собственный zero-dependency SDK, backend на Kotlin, dashboard на SolidJS, интеграции с Telegram, AI summaries, релизы, breadcrumbs. Самым неожиданным оказалось не написать код. Самым сложным было постоянно отвечать себе на вопрос: «А эта функция действительно нужна сейчас?» Именно поэтому я сознательно отказался от десятков идей и старался оставить только то, что действительно помогает быстрее понять production-проблему. Сегодня проект дошёл до состояния, когда им уже можно пользоваться. Теперь начинается, пожалуй, самый сложный этап - это понять, нужен ли RetraceKit другим разработчикам так же, как оказался нужен мне. Ссылка на проект: https://retracekit.cloud Приветствую поддержку и фидбэк на ProductHunt: https://www.producthunt.com/products/retracekit-error-tracking-platform0,84%
  • 24 июл.#баг дня или история одного апокалипсиса Знаете, что происходит, если в Firefox ввести в <input type="number"> что-то вроде lol? Он позволяет. Да, вы видите эти lol, будто это валидное число. Только вот значение value в DOM превращается в пустую строку. Ну типа «я тебе это показал, но делать с этим ничего не буду». Гениально. Баг #1398528 в Bugzilla живёт с 2017 года. Проблему признают: Firefox нарушает спецификацию WHATWG, согласно которой input type=number должен принимать только корректные числовые строки. А на деле — буквы, кириллица, эмоджи — всё идёт в бой. Только вот под капотом — пусто. Т.е. ты видишь, что ввёл, но значение не считается валидным. UX? Ну, такое себе. Почему не фиксят? Ответ классический: «а что, если у нас локаль с деванагари и арабскими цифрами, и вообще — как различать запятую и точку?». Ну и правда, лучше пусть вводится вся клавиатура, чем разбираться в сепараторах. А теперь немного цирка из Chrome: В Chrome <input type="number"> иногда разрешает ввод e, ведь вдруг ты хочешь ввести 1e10 (научную запись). Но если ты просто набрал e, поле становится… валидным. Бинго! Ещё веселее: 1e- — тоже "нормально", но 1ee — уже нет. Картинку с барабаном вставите сами. А если ты вводишь 1,5 в локали, где десятичный — это точка, Chrome может забраковать это, а может и нет — зависит от версии, луны и количества кофе у разработчика. В итоге: у Firefox можно ввести хоть «привет», и он такой: «ну окей, но это не число». Chrome вроде бы фильтрует, но делает это через лунную призму. Что же мы делаем? Пишем код, блять! Мораль: в 2026 году проще создать свою валидацию под конкретный случай, чем надеяться, что браузеры когда-нибудь договорятся. А баг тем временем отмечает 8 лет жизни, всё ещё «NEW», и, судя по комментариям, будет жить Баг-репорт: https://bugzilla.mozilla.org/show_bug.cgi?id=1398528 Подпишитесь и следите, если вы, как и мы, верите (нет) в чудеса стандартизации. P. S. тем временем Firefox пробивает дно за дном. В англоязычном интерфейсе выдаёт мне ошибки валидации на финском языке. P. P. S. я молчу уже о том, что <input type="number"> вообще нахер не нужен и даже вреден: https://t.me/htmlshit/2663 #firefox #bug #input #number #бородач0,82%
  • 21 июл.без подписи0,82%