139-ый выпуск Цинкового прода!

Поговорили с Димой Санниковым из All Cups про соревнования программистов.

видео: https://www.youtube.com/watch?v=CzM-bPS2Y2I
Аудио: https://soundcloud.com/znprod/139-govorim-pro-sportivnoe-programmirovanie-s-dmitriem-sannikovym

Дрю ДеВолт хочет убить npm, чтобы сделать его сильней.

Его достало, что практически в каждом проекте в дереве зависимостей есть тысячи npm-пакетов, написанные бог знает кем, и непонятно, как это выстрелит (вспомним печально известный leftpad). Многие пакеты состоят из одной-двух строк, и подключать их как зависимость просто нет смысла.

Поэтому он предложил интересную идею: Дрю будет ПЛАТИТЬ за то, чтобы владельцы пакетов сами уничтожали своё детище, причем чем меньше строк и чем больше популярность, тем сумма будет больше:

Вознаграждение($) = 100 * log10(количество загрузок в неделю / количество строк кода)

Например, для практически однострочного пакета isArray с 51 млн загрузок, это будет $710

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

Почему некоторые функции в PHP (strptime, nl2br, htmlspecialchars) так странно/неконсистентно называются, рассказал создатель языка Rasmus Lerdorf (источник):

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

Это было примерно в конце 1994 года, когда PHP был моим личным инструментом, и я не слишком беспокоился о том, что не смогу запомнить несколько названий функций..."

Кент Бек, создатель TDD:

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

А ведь в TDD утверждается, что код должен появляться только после написания "красного" теста, его проверяющего (после чего тест делать зеленым)

Никому верить нельзя

Компания Jetbrains анонсировала новую легковесную IDE под названием Fleet

По словам Hardi Hariri, Fleet стартует как легковесный редактор, но при этом имеет все функции IDE: код комплит, дебаг, рефакторинг, навигацию и т.д. (для этого надо переключить IDE в smart mode нажатием кнопки).

IDE написана с нуля на Kotlin и Rust, на совершенно новой архитектуре, и будет поддерживать сразу все языки (на данный момент это пока что Java, Kotlin, Rust, Python, Go, JS, Typenoscript).

С помощью виртуализированной файловой системы Fleet позволит работать с проектами как локально, так и удаленно. Вообще, у fleet довольно развесистая архитектура: он подойдет и для совместной удаленной работы, и локально, и в облаке и как угодно. Подробнее можно посмотреть здесь

Пока что скачать Fleet нельзя, но можно зарегистрироваться для Early Preview, и возможно придет приглашение. Я зарегался )

Предыдущие IDE (intellijIDEA, Goland и т.д.) никуда не денутся, и будут развиваться дальше

Давайте переформулируем вопрос в текстовом виде. Я соберу самые частые варианты из коментов и запущу опрос уже с чекбоксами.
Итак, как вы считаете, какой ЯП подойдет в качестве первого языка программирования?

Go 1.18 с поддержкой дженериков в бете!

Посмотреть детали/скачать можно тут: https://go.dev/blog/go1.18beta1

Итак, путем пересечения опросов (белого и черного списка) получился такой рейтинг языков в качестве первого языка программирования:

1) Python (39)
2) Pascal (16)
3) Go (13)
4) Java/Kotlin (12)
5) С (9)

а и всё, больше ни одного нет. Ни js, ни Rust, ни Haskell не втиснулись.

Свежая кровь

Некоторое время назад я писал пост про добавочную стоимость старожилов https://news.1rj.ru/str/general_it_talks/135
В этот раз хочется рассмотреть ситуацию почти обратную, и обсудить ценность новых сотрудников.

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

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

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

⁃ Взбадривает болото. Порой с низкой ротацией в коллективе или несколько вязкими процессами со временем складывается более-менее равновесная ситуация, где всем норм, и никто никаких активных действий совершать не хочет. И вот свежий человек способен сгенерировать какие-то новые идеи, взяться за их реализацию.
Я сам не из тех, кто постоянно кричит про выход из зоны комфорта. Я люблю что-то комфортное и стабильное, однако очень радуюсь, если приходит человек с разумным, осознанным энтузиазмом и приносит новые идеи. Готов всегда идти навстречу, обсуждать, пробовать.
Конечно, я не имею в виду случаи, когда приходит новый разработчик и с порога говорит: «Тут всё фигня и надо переписать на svelte». Или новый менеджер, который говорит: «Вы что, без скрама и сторипоинтов вообще жизнь – не жизнь! Жду вас завтра на ретро!»
⁃ У него нет выученной беспомощности. Про это я тоже писал пост https://news.1rj.ru/str/general_it_talks/66
Т.е. человек еще не обескровлен скрипучими процессами и инертностью коллектива. Он не живет в позиции «Ой, да тут никому ничего не надо, не стоит даже пытаться».
⁃ Приносит новый опыт, которого у вас в команде нет. Вы же берете человека откуда-то. Он там работал, чего-то видал, чего-то делал. Интеграция чужого опыта тоже может быть очень полезна. Особенно если к найму подойти осознанно и не набирать людей глупее себя, чтобы они тебя не подсидели (да, такое бывает регулярно), а целенаправленно подумать, какой экспертизы не хватает команде и попытаться нанять человека, который бы её принес.

Итог
Желаю вам в новом году хороших, бодрых, профессиональных коллег.
Всех поздравляю с наступающим праздником🥳 Успехов вам!💪

Иногда я задаюсь вопросом: почему мы продолжаем писать бизнес-приложения на PHP с бексконечными CRUD/REST. Почему бы не взять Low-code/No-code систему типа Airtable или Fibery? Вот почему (картинка):

Говорят, что Bolt перешел на четырехдневную рабочую неделю. После трехмесячного эксперимента провели опрос среди сотрудников, и выяснилось, что у абсолютного большинства людей выросла продуктивность и, понятное дело, улучшился work-life баланс. Интересно, есть ли там вакансии Go-шников? ))

https://www.businessinsider.com/ecommerce-unicorn-bolt-adopts-4-day-week-after-productivity-improved-2022-1

На Хабре появилась очередная статья о том, как php пытаются натянуть на хайлоад, используя для этого костыли swoole.

Статья потрясающая, ведь в ней перечислены все минусы этого подхода по сравнению с Go, Node и т.д., а выводы сделаны противоположные здравому смыслу.

В статье api, которое пишет в базу, нагрузка всего 300rps.

1) Приложение жрет 2 гига памяти и 8 ядер cpu. Ну хз, Go сожрало бы в несколько раз меньше. У меня микросервисы обычно потребляют в разы меньше при гораздо большей нагрузке. Хотя, конечно, зависит от конкретики приложения.

2) раздел "простота инфраструктуры", цитирую:

"...внутри контейнера будет всего 11 процессов: 1 tini (supervisor)+entrypoint, 1 master процесс, 1 manager процесс и 8 worker процессов."

Вы чо, ребят? Какая тут простота? Особенно учитывая, что они зачем-то перезапускают процессы воркеров раз в час.

Image весит всего 120 мегабайт. Ну неплохо, но если это так важно, то в Go можно оставить вообще один бинарник (FROM scratch), и образ будет весить по сути вообще около нуля.

3) чтобы добиться постоянного соединения к бд и редису, пришлось написать несколько оберток к библиотекам и драйвер к doctrine.

4) 4ms уходит на обработку запроса без логики (пустой запрос или даже 404). Сорян, но это очень много.

5) в течение месяца после выкатки они вылавливали странные ситуации. Что-то там текло при коннекте к посгресу и тд.

Итог) Вывод делают такой: php закапывать рано, все норм.

Блин. Если бы в статье был упор на удобство написания кода, то я бы это купил и пошарил бы везде. Синтаксис php во многом удобнее. Но статья про хайлоад и производительность, блин.

Отдельно хочу заметить, что описанное в статье могла намутить только команда прокачанных php-синьоров, которые готовы ловить и фиксить необычные проблемы. А на Go с задачей "highload api, которое лезет в базу" справился бы начинающий по стандартному мануалу. И у него не возникло бы ни одной серьёзной проблемы.

Ребята из Data Egret попросили разместить их вакансию. Что ж, они меня часто выручали в сложных ситуациях с Postgres, так что теперь моя очередь. Data Egret ищет DBA

https://dataegret.ru/#_vacancy2

Непонятно, нафига такое вообще сделали

https://twitter.com/Randomazer/status/1495131345328222208?t=V6rm4UhemxFgdd-ndFkioQ&s=19

Наисал статью тут на выходных
https://habr.com/ru/company/karuna/blog/663906/