Многие знают, что было довольно много попыток оценивать эффективность работы программиста. Пытались считать строки кода, жопочасы, количество выполненных задач и т.д.

Ничего, естественно, не работает.

Однако с появлением ИИ это может заиграть новыми красками. Допустим (чисто теоретически!) скидываешь в ИИху весь код, который наваял чел за месяц, все описания задач, все расшифровки митов и т.д. А ИИ потом выдаёт оценку, типа value, которое принёс разраб от 1 до 100.

Это была бы бомба.

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

Если же будет "сколько value принёс, столько и заработал", то по настоящему эффективные ребята бы разбогатели, а те, кто научился только отмазываться и на митах делать умное лицо, ели бы доширак. А некоторые бы вообще в минус ушли.

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

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

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

Bloom filter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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 - канал о разработке
⠀

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

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

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

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

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

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

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

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

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

🫥 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 - канал о разработке
⠀

В 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 - канал о разработке
⠀