Начиная с Chrome 135 появилась возможность кастомизировать <SELECT> элементы. Туда можно пихать иконки, применять различные стили и т.д.

https://developer.chrome.com/blog/a-customizable-select


🫥 Cross Join
⠀

Go планирует улучшить производительность в контейнерах (proposal)

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

В Go 1.25 разработчики предлагают встроить умный GOMAXPROCS, который будет учитывать ограничения контейнера (cgroup).

Сейчас Go автоматически устанавливает GOMAXPROCS равным всем логическим ядрам на машине, что создаёт проблемы в контейнерах, где доступно меньше ресурсов. Это приводит к неэффективной работе, проблемам с производительностью и троттлингу приложения.

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

Сейчас разработчики решают эту проблему ручной настройкой через переменные окружения или используя библиотеку от убера. Новое предложение добавляет в сам Go автоматическое определение ограничений CPU из cgroups и динамическое обновление GOMAXPROCS при изменении этих ограничений.

🫥 Cross Join
⠀
#golang #performance #kubernetes #docker

Самое большое зло на свете - это неявное приведение типов.

Вот мои любимые приколы:

$str1 = "240610708";
$str2 = "QNKCDZO";

echo md5($str1) . "\n"; // 0e462097431906509019562988736854
echo md5($str2) . "\n"; // 0e830400451993494058024219903391

if (md5($str1) == md5($str2)) {
    echo "MD5 хеши равны!\n";
} 

md5 хэши равны, потому что php думает, что 0e... - это экспоненциальная нотация числа.

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

$x = "0abc";
$x = $x+1;
echo $x; // получится 1

$x = "0abc";
$x++;
echo $x; // получится строка 0abd

Не только в php проблемы, конечно.

На картинке выше, если кто не понял, Excel приводит 1/2 к 1 февраля.

Ну и классика js

name = 2;
console.log(name+2); // 22

потому что window.name хоть и получило число, но это заголовок окна, т.е. костылём прибито, что это строка.


Или такое

[1, 2, 3] + [4, 5, 6]  // -> '1,2,34,5,6'

Because fuck you, that's why.

Короче, не говорите мне, что неявная типизация - это удобно. Это говно

🫥 Cross Join
⠀
P.S. В коментах пишут про ===, strict types. Но ребят, это как раз попытка языков уйти от неявного приведения типов, потому что это говно.

Ох уж этот вайб кодинг. Https или api 🤦

🫥 Cross Join
⠀

encoding/json/v2 будет внедрен в go1.25 под экспериментальным флагом: https://github.com/golang/go/issues/71845

Анмаршалинг будет работать намного быстрее, кроме того, в новый json добавили 100500 фичей. nil-слайсы будут маршалиться как [], можно задать формат для времени, указать case-sensitive или нет и много других штук.

Соответственно, v1 и v2 несовместимы, очевидно не получится просто добавить везде v2 и катить в прод. Старый json обещают поддерживать вечно

🫥 Cross Join
⠀

Кирилл написал пост, что ИИ не заменит программистов.

Да, блин, точно заменит. Не нынешними технологиями, а чуть позже.

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

Машина не сразу, но победила, перебором ходов и заучиванием дебютов.

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

Не сразу, но машина победила, и стала намного быстрее и точнее, чем живые существа.

Потом говорили, что в игру Го машина не может победить, потому что там подсчет ходов вообще не имеет смысла, только на интуиции. А человек - гений интуиции.

Результат немного предсказуем, в Го машина тоже побеждает. И алгоритм приспособили под любую вообще подобную игру.

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

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

Машина начала программировать, рисовать, писать тексты и стихи. Да, местами фигово, но, как говорится, "мы находимся здесь"

Самое интересное, что GPT задумывался как T9 на максималках, и никто не ожидал, что она сможет программировать и переводить с французского на китайский, учитывая контекст.

Кстати, раньше смеялись над автоматическими переводами ("охлади траханье, углепластик"). Сейчас запускаются международные стартапы вообще без присутствия человеческого переводчика, всё переводится чатом гпт. Ну, максимум, кто-то вычитывает в особо важных ситуациях. Переводчиков заменили на 99%.

Еще там что-то говорили про то, что мозг человека содержит 100 млрд нейронов. Но современный комп, например, Macbook M4 содержит 30 млрд транзисторов. Конечно, сложно сравнивать нейроны и транзисторы, но блин.

И рост продолжается, становится больше ядер, компьютеры объединяются в облака и т.д.

Тупо оценивать будущее, опираясь на сегодняшние возможности. Copilot 1.5-2 года назад был скорее анекдотом, сейчас для большинства разработчиков - это незаменимый инструмент. Да, надо перепроверять, да он не может поговорить с коллегами и уточнить задачу, но блин.

И каждый раз одно и то же, "компьютер никогда не сможет...".

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

🫥 Cross Join
⠀

Мне что-то сегодня не остановиться.

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

Еще слышал такой аргумент, что, мол, программист ставит компьютеру задачу очень конкретно, а потом еще и проверяет решение. А когда ставишь задачу через chatGPT, то это какой-то черный ящик: что он там понял, не понял, а не глюканул ли в ответе.

А вы задумывались о том, как владелец бизнеса, который не шарит в техничке, ставит задачу программистам? Абсолютно ли чётко? Всегда ли правильно программисты его понимают и выдают четкую программу без багов? Люди вообще, часто говорят или делают хоть что-то абсолютно точно? Не бывает ли так что они бредят и несут чушь?

На самом деле всё происходит примерно так: туповатый менеджер как-то ставит задачу, она как-то делается туповатыми программистами, а потом работа проверяется туповатыми тестировщиками или туповатыми пользователями на проде. (под туповатыми я понимаю "не абсолютно чётко выполняющими задачи"). Ничего чёткого тут и в помине нет, это хаотический процесс между хаотическими агентами. Даже если есть выделенный бизнес-аналитик (чаще его нет).

В итоге получается, что система, состоящая из нечётких глючных вещей, как-то функционирует. Да, с проблемами и т.д., ну и что. Ну упадёт прод, туповатый SRE это заметит и сообщит кому-надо, там починят костылём (сделав еще пару других багов). А ведь это делал венец творения - человек!

🫥 Cross Join
⠀

В работе лида очень важно слушать свою интуицию.

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

Например:

- чувствуешь раздражение от того, что срочный таск нужно затащить на прод, а на код ревью кто-то придирается или вообще не смотрит - это поинт задуматься над процессами;
- пайплайн идет слишком долго на ci, бесит блять - это повод его пересмотреть;
- какой-нибудь скрам-митинг вызывает раздражение своей бессмысленностью. А нужен ли он тогда, этот митинг, и вообще скрам;
- вынужден следовать странным процессам, навязанным извне, это напрягает - нельзя ли что-то с этим сделать;
- в этом куске кода стало сложно ориентироваться, какие-то бесячие баги лезут - нельзя ли выделить время на рефач.

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

То же самое и с положительными эмоциями:

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

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

🫥 Cross Join
⠀

Чем горутины отличаются от async/await функций в других языках?

Логически это примерно то же самое, но:

1. В Go не надо помечать асинхронные функции специальным ключевым словом async, они все там такие. Т.е. асинхронный код выглядит как синхронный, по сигнатуре не отличишь, только по тому что они делают (есть ли блокировки, сисколы и тд).

2. Стек: в горутинах при блокировке (саспенде) просто сохраняется указатель на стек, сам стек остаётся как был (в куче). Когда функция должна заработать снова, в регистр SP записывается указатель на стек

При async/await стекфрейм не сохраняется, а конкретные переменные сохраняются в специальном месте. Когда нужно продолжить работу функции, стек создаётся заново на основе сохраненных значений, что намного дольше. Тут конечно от реализации зависит, но в целом так

🫥 Cross Join
⠀

Про предварительную оптимизацию.

Слышал, что в VictoriaMetrics абсолютное большинство кода никак не оптимизировано, а задрочено под скорость только пара процентов кода (короче, узкие места). И вроде всё верно.

Однако наткнулся на такой коммент на реддите (там не про victoriametrics, но всё же), вот примерный перевод:

"Вы [...] утверждаете, что ЛЮБУЮ оптимизацию следует откладывать, пока она не станет проблемой. В реальности ваша архитектура буквально может сделать оптимизацию невозможной, если вы её даже не учитывали. Эти архитектурные решения НЕЛЬЗЯ просто переработать позже, если только вы не готовы остановить постоянную разработку новых функций и вложиться в ускорение вашего продукта. В реальности никто не хочет этого делать. Так что вы застреваете с программным обеспечением, которое работает как патока, и молитесь богу, чтобы не появился конкурент, который может делать то же, что и вы, но не раздражая пользователя (что буквально сделала Apple с iPhone и захватила целую индустрию). И вы можете избежать загона себя в угол, просто потратив несколько часов на обдумывание требований к производительности, выявление вероятных узких мест и написание эффективного кода с самого начала."

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

А учитывая, что медленный код тратит энергию (а это выбросы в атмосферу углекислого газа), думаю, всё же надо оптимизировать любой вообще код хотя бы чуть-чуть :)

🫥 Cross Join
⠀

Почему микроменеджмент - это всегда плохо.

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

Короче, не оптимизируй частности, оптимизируй только результат.

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

- % покрытия кодом,
- 2 апрува на ревью,
- строгое абсолютное следование таким-то принципам ( SOLID/шмолид или любым другим),

то система будет стремиться ВНЕЗАПНО к:
- % покрытия кодом,
- апрувам на ревью
- и таким-то принципам.

Но вот будет ли при этом бизнес-результат - это вопрос случайности. Означает ли покрытие тестами X%, что код работает без ошибок? Или что покрыт осмысленный процент кода, а не тот, который легче покрывать? Означает ли апрув на ревью и следование принципам, что бинес-задача сделана правильно и потрачено оптимальное количество времени?

Спойлер: да хой там плавал.

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

тогда разработчик (команда) сделает ВНЕЗАПНО так, что

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

Ну, люди в целом делают примерно то, что просят )

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

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

Т.е. в итоге, без микроменеджмента: лишнего не сделано, нужного сделано больше.

Квинтессенцией микроменеджмента является, конечно, скрам. Когда тебе жестко навязывают 100500 обязательных приседаний ("процессов"), которые игнорируют контекст, да и вообще сомнительны. Пример: могли бы сегодня доделать что-то важное, но нет же, у нас сёдня по расписанию дейли, ретро в игровой форме и покерное планирование-онанирование. Не до работы, короче.

В общем, микроменеджмент противоречит теории систем.

Вот такой вот воскресный наброс на канале 🫥 Cross Join
⠀

Ментальные ловушки софтваре девелопера
в статье прям всю мою жизнь описали.

TLDR:

1. Планирование и оценки:

Ошибка планирования — недооценка времени на задачи, даже имея опыт подобных проектов

Эвристика доступности — принятие решений на основе недавних событий, а не реальной статистики

Эффект якоря — слишком сильная привязка к первой полученной оценке


2. Выбор инструментов:

Закон инструмента — использование знакомых технологий для всех задач подряд

Синдром "не изобретено здесь" — отказ от готовых решений в пользу разработки с нуля

Эффект присоединения к большинству — выбор трендовых технологий без учета реальных потребностей


3 .Работа в команде:

XY-проблема — попытка решить неправильно сформулированную задачу

Ошибка атрибуции — обвинение людей вместо анализа системных причин

Конформизм — молчание при несогласии с групповым решением

Предвзятость авторитета — слепое следование мнению старших коллег


4. Самооценка:

Синдром самозванца — недооценка собственных навыков

Эффект Даннинга-Крюгера — переоценка способностей новичками и недооценка экспертами

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


5. Принятие решений:

Эффект IKEA — переоценка собственного кода и сопротивление рефакторингу

Велосипедный сарай — фокус на мелочах вместо важных проблем

Искажение выжившего — изучение только успешных кейсов без анализа провалов

Предвзятость подтверждения — поиск фактов, подтверждающих существующие убеждения


Вот такие когнитивные искажения на канале 🫥 Cross Join
⠀