Cross Join - канал о разработке

Бюро статистики труда США прогнозирует рост вакансий software developers и QA на 15% до 2034 года. И это несмотря на все ИИ, массовые сокращения и прочие экономические закидоны.

Любопытно

Про синдром самозванца.

"Ой, мой опыт N лет, но замучил синдром самозванца, ничего не знаю ни в чем, хаха"

Не смешно, потому что ты самозванец и есть. Всё меняется каждые несколько лет, текущие знания не стоят ничего.

Перед Go я писал много лет на php, куда мне засунуть эти знания? Надо ли их вычитать теперь из годов? А еще я наблюдал, как в том же пыхе всё меняется. Как писали на php4 и как пишут, допустим, сейчас - да там ничего общего нет. Вообще. Совсем.

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

Знания - это sliding window.

Да, есть вечные темы, типа дизайна распределенных систем или баз данных, но и там инструменты меняются постоянно.

Хуже только в javascript, там просто пиздец. Моргнул - и устарели два фреймворка и сборщик.

Куда, опять же, мне засунуть опыт с jQuery?

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

Только Go радует своей консервативной деревянностью, но вокруг него всё в броуновском движении.

Синдром самозванца - это, короче, не синдром самозванца.

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

Сейчас на досуге пытался понять почему в swc два runtime для wasm — wasmtime и wasmer. Быстро нашел ADR, в котором было указано, что wasmer был выбран как основной runtime для wasm-плагинов. Но если хочется узнать как он запускает wasm-плагины, как встраивается в компилятор — иди читай исходники.

Здесь мне помог проект deepwiki.com, который в ситуации подобной моей делает прекрасный onboarding: отвечает на вопросы, знакомит с основными частями кодовой базы и тем, как они связаны, рисует графики зависимостей, сопровождает свои ответы участками исходного кода. Более того он собирает лендинг с документацией на основе исходников, например, https://deepwiki.com/swc-project/swc

В общем, рекомендую приглядеться к deepwiki.com

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

Но это, конечно, не так. За свою 20-летнюю карьеру видел пяток увольнений самых-пресамых незаменимых.

Во-первых, незаменимость часто преувеличивается (особенно с учетом ИИ, который и разберется, и нарисует, и расскажет всё, что важно знать). На практике обычно через 3-4 месяца уже никто и не вспоминает о Васе, который где-то там всё знал. А чаще скорее просто ругают его за странные решения, переписывая запутанные куски с нуля.

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

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

Короче, будьте бдительны. Нужно всегда быть готовым менять работу. Незаменимых не бывает.

🫥 Cross Join - канал о разработке
⠀

Наткнулся на обсуждение "как это классно, когда ввели вторники без митингов, можно хоть день поработать нормально".

Когда в большой организации вводят правило "вторники без митингов", я смотрю на это со скепсисом.

С вероятностью 99% это означает лечение поноса затыканием жопы. Вместо того, чтобы искать корень проблемы, почему же все, собственно, задолбаны митами.

Обычно перегрузка митами происходит, когда:

1. слишком много контроля (микроменеджмент), приходится постоянно отчитываться о том, как именно ты что-то делаешь

2. слишком много согласований с другими отделами, нет независимости команды в принятии решений ( как Tight coupling в программировании). Или например, фронтенд одна команда, а бекенд другая, со своими планами и приоритетами.

3. есть какие-то наслоения сбоку типа структур "Engineering excellence", "отдел корпоративного обучения" и прочие активности, оторванные от реальных дел бизнеса, и находящиееся в абстрактном вакууме. Поймите меня правильно, можно много всего классного полезного придумать и сделать, но запрос должен идти от команды, а не насильно в команду.

4. обязательное на всю организацию внедрение скрама и прочих штук, которые нужны так-то далеко не всем. Я, например, как-то работал в команде из 2(!) разработчиков, куда насильно навязали скрам. А скрам - это много странных приседаний (планирование, демо, ретро, хуетро и т.д.)

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

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

🫥 Cross Join - канал о разработке
⠀

Этот канал, кстати, ведёт Дима Пацура, вы можете его помнить по подкасту Underjs, да и в "Цинковом проде" он был миллион раз.

Природа настолько очистилась, что Дима возвращается!

Сегодня в Twitter заметил тред, где Jarred Sumner (автор Bun), подсвечивает проблему что в VSCode медленно работает copy/paste в терминал со скриншотом кода.

Логика там простая, весь контент вставки бьется на строчки по 50 символов и вставляет их последовательно с паузой в 5 ms. Естественно, это выглядит как нереальный говнокод.
Какая еще пауза при вставке? Набежала куча людей, естественно шуточки, приколы, все как мы любим. Но почему так сделано? Почему сразу не пишут все за раз?

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

> The only pattern I can see is that the text gets cropped after 1018 characters

Переписали плохо, но чтобы работало. Но почему так?
Я не хочу грузить сложностями в пятницу вечером, а просто приведу мой подробный комментарий как я считаю почему вызывался такой баг.
Баг крайне сложный, вызванный из-за того что Node.js использует везде NON Blocking IO для STDOUT/STDERR/TTY.

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

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

Помните, код который вы пишите, не определяет вас, а определяет вас реакция. Человек пошел и начал чинить. 1-2 дня и проблему исправят.

Хороших выходных!

Голландский Rust-ист - канал о веб разработке

В Go 1.26 появится еще немного сахара

Как известно, тип error - это просто интерфейс, под которым может скрываться любой тип, который этот интерфейс реализует.

И для проверки и распаковки ошибки в переменную нужного типа применяется errors.As, но этот метод неудобен: надо сначала создавать переменную, а потом туда загонять значение

var appErr AppError
if errors.As(err, &appErr) {
    fmt.Println("Got an AppError:", appErr)
}

Особенно это напрягает если есть цепочка if, else if ..., перед этой цепочкой надо создать все переменные.

Ну так вот, приняли proposal, который позволяет это сделать попроще. "type-safe, faster, and easier"

if appErr, ok := errors.AsType[AppError](err); ok {
    fmt.Println("Got an AppError:", appErr)
}

Наличие дженериков в Go снова помогло улучшить стандартную библиотеку.

🫥 Cross Join - канал о разработке
⠀

https://about.gitlab.com/blog/gitlab-discovers-widespread-npm-supply-chain-attack/

🚨 Масштабная атака на npm-экосистему

GitLab обнаружил крупную атаку на цепочки поставок через npm-пакеты. Вредоносная программа распространяется как червь, автоматически заражая новые пакеты через украденные токены разработчиков. Малварь крадёт credentials от GitHub, npm, AWS, GCP и Azure, а затем использует их для дальнейшего распространения через легитимные пакеты.

Самое опасное — встроенный механизм «мёртвой руки». Если малварь теряет доступ к своей инфраструктуре (например, при массовом удалении заражённых репозиториев), она начинает уничтожать данные пользователя. На Windows удаляет файлы и перезаписывает сектора диска, на Unix использует shred для безвозвратного уничтожения.

Что делать:

Проверьте node_modules на наличие файла bun_environment.js, папки ~/.truffler-cache/ и др (см статью)

Также в статье указаны подозрительные процессы, которые стоит поискать.

Просканируйте package.json на подозрительные preinstall скрипты

Ротируйте все токены GitHub, npm и облачных сервисов

Расследование продолжается, список заражённых пакетов уточняется.

🫥 Cross Join - канал о разработке
⠀

Говорят, на собеседованиях стали просить закрывать глаза при ответах на сложные вопросы, чтобы исключить подсказки chatGPT.

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

Думаю, что на алгоритмической секции прогерского собеса тоже можно так читить. Так что надо еще просить показать ж, чего уж мелочиться.

Вообще, если серьёзно, то собесы превращаются в какой-то цирк. Имхо если чел быстро и правильно отвечает, то какая разница, что он там использует фоном, хоть ии, хоть вибратор.

Такой хитрожопый (во всех смыслах) чел уж как-нибудь кнопку покрасит и json в базу пихнёт

🫥 Cross Join - канал о разработке
⠀

В новой версии git дефолтной веткой станет main (вместо master). Вообще, если отбросить политические аспекты, main ведь гораздо логичнее. Что еще нафиг за master (хозяин)? Хозяин веток? Лесовик что ли

Но еще круче было бы вернуть старый добрый trunk, как деды называли. Раз у нас есть ветки, то должен быть и ствол. Суперлогично, как мне кажется.

Тем более, что второе значение trunk - это сундук. Сундук, короче, со всяким ненужным хламом. Вообще было бы супер в тему

🫥 Cross Join - канал о разработке
⠀

"....Глава «Сбера» Герман Греф заявил, что до 1 января банк уволит до 20% сотрудников, которых признал неэффективными искусственный интеллект. ИИ также поможет банку закрыть неэффективные проекты, рассказал он на конференции AI Journey...."

жесть

В go 1.26 расширяют оператор new, теперь туда можно будет передать число, и получить ссылку. Как по мне, очень странное решение.

age := new(42)

Для начала, для чего вообще это нужно?

Это нужно,чтобы передать конкретное значение в поле, которое принимает ссылочный тип. Например, необязательное поле в json-структуре в Go обычно делают как ссылку на значение, которая может быть nil.

type User struct {
    name string
    age *int
}

А надо передать в него 42. И вот сделали для этого new(42).

user := User{
    name: "vasya",
    age: new(42),
}

Но зачем, блин, для этого использовать new?

Оператор new и в предыдущих версиях максимально странный. Всё что он может - это делать ссылку на zero value типа, который в него передали. Если написать

 go
a := new(int)

это всё равно, что

var x int = 0
a = &x

Для структур тоже самое. Но довольно редко кому то нужна ссылка на 0. А на пустую структуру все обычно делают ссылку явно &User{} (для единообразия), а не new(User). Есть некоторые очень редкие кейсы с дженериками, где нужен именно new, но это прям надо постараться.

И вот они взяли и разрешили делать new(42), чтобы получить ссылку на 42.

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

Лучше бы просто в стандартной библиотеке сделали какую-нибудь функцию ptr(). Она пишется за минуту, и есть в каждом, наверно, проекте:

func Ptr[T any](v T) *T {
 return &v
}

А еще лучше бы не занимались такими мелочами, а улучшили бы синтаксис обработки ошибок 🙂

🫥 Cross Join - канал о разработке
⠀

Услышал тут несколько советов, как эффективнее кодить с помощью агента.

1. Разбивать код на модули. В идеале микросервисы. Чтобы при рефакторинге нужно было меньше контекста, меньше вероятность повреждения чего-то лишнего. Лапша-код в гигантском монолите роботам понятен намного хуже.

2. Код должен быть как можно стандартнее, без трюков и вывертов. Нейросети грубо говоря обучены на чём-то среднем, поэтому и писать надо как все, тогда агентам будет легче. В идеале, чтобы весь код с самого начала в основном был написан ими же. В идеале, на самом распространенном языке / фреймворке и т.д.

3. Модули должны быть задокументированы. README модулей, ADR, примеры кода - это всё поможет.

4. Код должен быть покрыт тестами - чтобы агент мог отдебажить свой высер и поправить.

5. Явные интерфейсы и контракты. Утрируя, js-код без явных типов рефакторится хуже, чем typescript. Если тебе в функцию прилетел объект context, то ни человек, ни робот ничего не поймут, если у контекста не задан нормально тип (придется долго рыться в коде)

ВНЕЗАПНО, для людского кодинга действуют точно такие же правила - легче рефачить, если ты понимаешь весь контекст, и есть тесты и доки.

🫥 Cross Join - канал о разработке
⠀

Мне кажется, что развитие LLM как-то замедлилось немного. Ну, т.е. да, появляются новые инструменты, новые версии, но прям такого вау как при переходе с GPT 3.5 на 4 уже (субъективно) не наблюдаю. Да, всё это полезно, но иногда бесполезно. И год назад также было, в общем-то.

Как год назад нельзя было доверить сложный рефакторинг, так и сейчас нельзя. Заколебёшься объяснять и следить, проще самому сделать.

Курсор стал гораздо удобнее, но не прям, чтобы в 100 раз повысил продуктивность (при работе со сложным софтом) по сравнению с прошлым годом.

Чё думаете? Или это у меня только так?

Bloom filter

Если нужно быстро и с малым количеством памяти проверить, есть ли элемент в каком-то списке (например, емейл в блеклисте), можно использовать Bloom filter. Этот алгоритм умеет выдавать два ответа: "этого элемента точно нет" и "этот элемент возможно есть".

Как он работает:

Выделяется массив бит длиной m (чем больше m, тем меньше ложноположительных срабатываний).

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

Короче, для каждой хеш функции выставляем в итоге бит в 1.

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

Проверка на вхождение элемента в список

точно также, вычисляем теми же хеш фунциями позиции битов и смотрим, что там, в этих позициях.

Если хотя бы один бит равен 0, то этот элемент точно отсутствует в списке. Если все 1, то возможно присутствует.

Элементарно и эффективно.

Хеш-функций нужно несколько, чтобы уменьшить вероятность ложноположительных ситуаций.

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

Особенности фильтра:

Вы сами задаёте количество памяти исходя из требуемого качества.

Работает за константное время O(1)

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

Можно разные фильтры объединять в один простым побитовым ИЛИ

🫥 Cross Join - канал о разработке