В статье про комплексную эффективность разработки есть забавные цифры про концентрацию программиста:

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

Инженеры в больших корпорациях по статистике имеют лишь 16.9 часов в неделю, когда они могут нормально сосредоточиться (против 22.5 в более маленьких компаниях).

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

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

Что можно сделать навскидку: регулярные встречи двигать в самое начало (конец) дня или вплотную к обеду; выделять в календаре блоки времени "я работаю", чтобы никто не вставил туда встречу; на скучных митингах выключать звук - это хорошее время спокойно поработать 🙂

Если серьёзно, то очень хорошо, что эту тему начали поднимать. Пройдет лет 5, и учет непрерывности времени разработки может быть будет стандартом. Хотя, хрен там, наверно 10

P.S. Когда падает прод, чайка-менеджмент из серии "ну че, скоро там почините?" тоже не добавляет концентрации

Петя в канале "Пятиминутка PHP" (советую подписаться!) скинул восхитительную новость. Так вот для чего были все эти вопросы на собеседованиях про сортировку :)))) 👇

Замена алгоритма сортировки в sysinit позволила ускорить загрузку FreeBSD
Во FreeBSD принято изменение, меняющее в коде инициализации ядра (sysinit) алгоритм сортировки массивов. Вместо ранее применявшегося алгоритма пузырьковой сортировки в sysinit задействован более эффективный алгоритм сортировки слиянием, что позволило на 2 мс сократить время загрузки ядра в виртуальных машинах Firecracker.

Ого, в Microsoft Excel добавили поддержку Python. Для анализа данных, очистки, визуализации (matplotlib и др), machine learning и так далее. Запускаться это будет в облаке Microsoft Cloud. Достаточно лишь написать "=PY", больше ничего якобы настраивать будет не надо.

https://techcommunity.microsoft.com/t5/excel-blog/announcing-python-in-excel-combining-the-power-of-python-and-the/ba-p/3893439

Оказывается, в Гитлабе можно настроить MR так, чтобы сразу подсвечивалось полосками, какие строки покрыты тестами, а какие - нет. Для этого надо ваш файл покрытия сконвертировать в xml нужного формата (cobertura) и положить это в артифакт:

  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage.xml

(подробная инструкция здесь)

Далее, после того как весь пайплайн полностью пройдет, появится подсветка, как на картинке выше.

Для языка Go покрытие конвертируется в xml с помощью утилиты gocover-cobertura, для других языков тоже есть аналоги.

Пример:

go test -coverprofile  cover.out ./...

go install github.com/boumenot/gocover-cobertura@latest

gocover-cobertura < cover.out > coverage.xml

P.S. Гоша, спасибо за наводку :)

git - мерзавец, мудак
github - хаб мудаков
gitlab - лаборатория мудаков
trunk - ствол
log - бревно
logger - дровосек
bash - погром
shell - оболочка
yarn - пряжа, нить
node - узел
RESTful - спокойный
docker - портовый грузчик
MySQL часто произносят как my sequel, т.е. "моё продолжение"
Oracle - предсказатель, оракул
daemon - демон
stack - стог
heap - куча
noscript - сценарий

Java, Kotlin - остров Ява, остров Котлин
Rust - ржавый
Swift - стриж, быстрый

Angular - угловой
scrum - схватка, баталия

Чего только не бывает на свете.

https://smolsite.zip/ - позволяет разместить содержимое сайта прямо в урле. Т.е. можно взять папку, в которую положить index.html, картинки и т.д., зазиповать, перегнать в base64 и добавить в урл после слеша: https://smolsite.zip/[тут ваш base64]

Вот пример

В итоге, ваш сайт отобразится по этому урлу.

Непонятно только зачем, а главное - науя

Очень интересное приложение нашел. Общаешься голосом с роботом (на основе chatgpt) и тренируешь английский. Задания там всякие и всё такое. Для английского я его и поставил. Удобнее, чем italki и skyeng, потому что не надо назначать время, подгадывать, а просто учишь, когда хочешь, хоть 24/7. И на порядки дешевле.

Но самое интересное, что его можно использовать как тренировку собесов по-английски.

Ставишь параметры: собес на техлида, роль робота - interviewer. И он тебя гоняет по всяким вопросам типа "какие технологии знаешь", "как бы ты поступил в такой-то конфликтной ситуации" и т.д.

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

Просто 11/10

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

проще показать на примере:

```go

 funcs := []func(){}

 for i := 0; i < 5; i++ {
  funcs = append(funcs, func() {
   fmt.Println(i)
  })
 }

 funcs[0]()

```

Последняя строка примера напечатает 5 в go 1.21, но в go 1.22 будет уже интуитивно понятный 0.

С одной стороны, это вроде бы нарушение обратной совместимости, но зато не надо писать пугающее новичков i := i для починки скоупа.

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

Говорят, такой же трюк проделывали с C# в 2012 году, и все довольны

UPD. Написал статью на Хабр

#golang

Мотивация и сложность

Часто в вакансиях я вижу зазывания из серии «У нас сложные задачи!», «У нас высоконагруженная система с замудреной архитектурой!» и так далее.
И это вроде как должно привлекать инженеров устраиваться именно туда. Ну типа они ищут вызовы и готовы броситься в омут сложных задач с головой.

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

Так как же стыковать эти нестоковочки? Я предложу несколько своих вариантов, а вы предложите в комментариях свои. Уверен, у многих найдутся какие-то интересные лайфхаки на этот счет.

Йеркс-Додсон
Сначала хотел написать вам про закон Йеркса-Додсона, который говорит, что сложные задачи даются хорошо при слабом уровне мотивации, легкие – при высоком, а средние – при среднем. Но если почитать, что же за эксперименты эти господа проводили, то окажется, что «мотивацией» они называют удары током. Вернее мотивация – это то, что вас током били, а теперь перестанут, если задание сделали.
Я подумал, что это к нашим реалиям не очень применимо, тем не менее знайте, что если кто-то вам рассказывает про Закон Йеркса-Додсона и мотивацию, то там «есть нюанс».
Хотя, может, мы чему-то и можем научиться и здесь, например, что желательно людей не бить током, если хотим, чтобы они что-то сложное нам сделали.

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

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

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

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

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

Бонусный контент
Пост на эту тему мы решили написать с моей весьма опытной в сфере управления коллегой Мариной Востриковой. Мы знакомы недавно, но, читая её канал, я понял, что у нас на некоторые вещи довольно схожие взгляды. Сейчас мы и узнаем, насколько 🙂 Её пост тут.
А ещё Марина – одна из немногих моих знакомых, кто написал книгу. Всегда такое дело во мне пробуждает большое уважение.

Ключ к эффективности разработки: делать то, что нужно, но лишнего не делать.

Кучу времени можно сэкономить если:

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

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

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

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

Выделять слои бизнес-логики в сложных программах
Не городить 10 слоёв абстракций и супергибкий код в небольшой эффективной программе, которая не будет особо меняться в будущем

Проверять на код ревью важные вещи
Не докапываться до стилистических мелочей и вкусовщины, а некоторые очевидные MR(PR) вообще не проводить через код ревью

Тщательно запланировать работы перед важным дедлайном
Не тратить (много) времени на планирование, если нет дедлайна или нет взаимодействия с другими командами

К сожалению, люди часто упарываются во что-то одно, или перфекционизм, или вселенский пофигизм. Или 100% тестирование в пет-проекте или катим работу с деньгами без тестирования прямо в прод. Это какое-то когнитивное искажение, человеку проще выбрать один шаблон, и всё делать по нему, унифицируя всё и вся, все проекты и задачи.

Я призываю всегда думать и взвешивать вероятности. Быть осознанным. Ключевой вопрос "А что будет, если не делать?". Это точно окупится.

Короче, нормально делай - нормально будет, и подписывайся на Cross Join

Написал статью, про то, как найти мёртвый код в Go-программе, а также заодно пересчитать тестовое покрытие относительно живого кода

https://habr.com/ru/companies/karuna/articles/764326/

В последние дни несколько раз натыкался на обсуждения ниши языка Go

Вот краткое резюме:

Go нужен для написания небольших приложений с высокой производительностью при условии относительной легкости написания кода.

C++ производительнее, но очень сложный и надо внимательно следить за памятью

Си тоже производительнее, но тоже надо следить за памятью и тд, хотя синтаксически он беден и прост.

Rust суперсложный.

Java, PHP, Ruby и т.д. - они не такие дубовые синтаксически, как Go, но производительность в большинстве случаев на практике получается намного хуже. И научиться языкам с нуля сложнее.

Go - где-то по середине. Это идеологически как C (такой же бедный), но только туда вкорячено еще чуть-чуть ООП (без наследования), горутины и управление памятью.

Т.е. если нужно писать большой монолит со 100 слоями абстракций - Go подойдет наверно не очень, лучше брать Java.

Если нужно писать сверхпроизводительные вещи, где важны каждый байт и каждый такт - Go подойдет плохо.

Если нужно написать производительный микросервис без лишних заморок или CLI-утилиту - Go будет идеальным выбором. Причем научиться языку очень просто. Как показывает практика, PHP-шника переучить на Go можно прям на ходу.

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

Хотя программирование там тоже есть )
Надеюсь, его зарождающийся бизнес выстрелит!

https://habr.com/ru/articles/766054/

Вопрос от анонима (мопед не мой), нужен совет, бест практис:

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

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

Тут надо отметить, что не все нотификации приводят к алерту (не отсылаются в on-call), а только те, что мы определили как Critical. Warning и Info просто насыпают в Slack.

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

Как побороть это говно? Как сделать мониторинг, в котором будут только реальные проблемы?"

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

Побороть это всё можно только если отказаться от вашего флоу, при котором неизвестные ошибки вдруг почему-то имеют такое же значение и валится туда же, куда валится отфильтрованное, важное, бережно отобранное. Так будет продолжаться всю жизнь: фильтров на все случаи жизни не понаделаешь. Что делать (1) выбрать бизнес-метрики и реагировать в первую очередь на них: не смогли зарегистрироваться, не смогли выполнить платеж, резко снизился поток регистраций/кликов/юзеров онлайн (2) по процедуре (просыпаться ночью и бежать тушить) реагировать только на отобранное (3) нефильрованное складывать отдельно, и следить, чтобы по возможности каждому типу ошибки соответствовал фильтр, не было неизвестных ошибок (это можно сделать метрикой - процент “неизвестного говна”) (4) если вы большие, то завести дежурных, которые могут по бизнес-метрикам и логам оперативно разрулить ситуацию и принять решение будить инженера или нет.

Кстати, Алексей недавно запустил курс devhands.io/ru, где обещает за 6 месяцев “обучить хайлоаду”, там осталось несколько мест в октябрьский набор. Я сам не очень понимаю, как это можно сделать за 6 месяцев, но там вроде с первого дня дают в управление инфру и сплошь практика, Алексей утверждает, что такой подход работает. Если вдруг кто из подписчиков ходит на эти курсы или интересовался - напишите в комментарии, интересно. Ещё у Алексея есть интересный канал @rybakalexey.

Микросервис на Java - забивать гвозди микроскопом.
Монолит на Go - использовать молоток для исследования бактерий.

Вот вообще не согласен. Любые отклонения как в ту, так и в другую сторону, ни к чему 👇

Пацифизм в работе

Исполнительный и не конфликтный, божий одуванчик, добряк и лапочка, он не задает вопросов, а свято верит в начальство и бежит туда, куда скажут быстрее всех, на благо компании, чисто «за идею». Мечта руководителя, но только слабого руководителя-куколда.

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

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

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

В языке Go есть слоган "Do not communicate by sharing memory; instead, share memory by communicating". Если по-простому, то это означает, что лучше использовать го-каналы, чем прямое изменение переменных (и защищать их мьютексами).

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

Цитата:

Shared memory vs. message passing. Our study found
that message passing does not necessarily make multithreaded programs less error-prone than shared memory.
In fact, message passing is the main cause of blocking bugs.
To make it worse, when combined with traditional synchronization primitives or with other new language features
and libraries, message passing can cause blocking bugs that
are very hard to detect.
...
We believe that message
passing offers a clean form of inter-thread communication
and can be useful in passing data and signals. But they are
only useful if used correctly, which requires programmers
to not only understand message passing mechanisms well
but also other synchronization mechanisms of Go.

Наткнулся на забавную статью "ну почему экосистема фронтенда настолько сложна?"

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

Краткий пересказ статьи:

Нет единой системы импортов. ESModules, CommonJS, Asynchronous Module Definition (AMD), Universal Module Definition (UMD)

Многочисленные шаги минификации, траспиляции, uglification (уродования)

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

Множество фронтенд-инструментов полагаются на определенную структуру файлов в проекте, поэтому, например, в корне проекта лежат всевозможные tailwind.config.js, postcss.config.js, eslint.config.js, next.config.js и т.д.

Configuration hell. Огромное количество инструментов, которые нужно как-то поженить между собой. И если на шаг отойти от create-react-app, то столкнешься с адом взаимодействия десятков штуковин.

Из-за множества слоёв преобразования затруднён hot reload.

Напишите в коментах, почему так, зашто и куда всё это движется