Итак, принципы программирования по заветам Марксизма-Ленинизма от Владимира Ильича: LENIND

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

E - Economic Efficiency Principle (Принцип экономической эффективности): Максимизируйте использование ресурсов. Оптимизируйте ваш код для достижения максимальной производительности с минимальными затратами. Всякий излишек должен быть устранен.

N - Necessity Principle (Принцип необходимости): Каждый элемент кода должен быть необходимым и иметь цель. Избегайте бесцельного кода. Если часть кода не способствует общей цели программы, она должна быть исключена.

I - International Solidarity Principle (Принцип международной солидарности): Код должен быть написан таким образом, чтобы его можно было легко использовать, модифицировать и понимать в любой точке мира. Это включает в себя учет локализации и интернационализации, использование ясных комментариев и документации, а также придерживание стандартов кодирования.

N - No Exploitation Principle (Принцип нон-эксплуатации): Код не должен злоупотреблять своими ресурсами или зависимостями. Избегайте ситуаций, когда одна часть кода "эксплуатирует" другую, используя больше ресурсов, чем необходимо, или принуждая ее выполнять задачи за себя.


D - Dictatorship of the Proletariat Principle (Принцип диктатуры пролетариата): Код должен служить интересам большинства пользователей. Конечные пользователи - это "пролетариат" вашего кода, и его нужно разрабатывать с учетом их потребностей и интересов. Вы должны активно слушать отзывы и требования пользователей и стремиться их удовлетворить.

Пара мыслей про поиск мёртвого кода в Go, в порядке бреда

В Go 1.20 сделали возможность сбилдить приложение с флагом cover

go build -cover

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

Это, конечно, было сделано для хитрых интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но возможно это можно попробовать использовать и по-другому:

запустить прям на проде, подержать какое-то время и посмотреть, какие участки кода в реальности никогда не запускаются.

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

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

Просто как мысль на подумать

Пара деталей:

Запускать надо с переменной окружения GOCOVERDIR

GOCOVERDIR=somedata ./myapp 

После завершения приложения в этой папке появятся бинарники, которые можно сконвертировать в нормальный вид

go tool covdata textfmt -i=somedata -o coverage.txt

и посмотреть, что там, стандартными средствами, например так:

go tool cover -html=coverage.txt

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

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

Счастливой отладки :)

Написал на Хабр статью про Go 1.21

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

Мало кто знает, что Кирилл Мокевнин завёл свой канал Организованное программирование. С интересом читаю и рекомендую подписаться, опыт виден в каждой строчке

Вот его мнение по поводу замены програмистов ИИ 👇

Серебряной пули нет
Такую статью написал Фредерик Брукс, аж в 1986 году, где он утверждает, что, даже в отдаленном будущем, никакая технология, техника менеджмента или способ разработки не улучшат производительность, надежность и простоту разработки ПО. Подробнее об этом можно почитать на вики https://en.wikipedia.org/wiki/No_Silver_Bullet но так как этого все равно никто не сделает, я поделюсь его ключевыми мыслями, так как это очень совпадает с моими представлениями о том, как оно работает.

Если кратко, Брукс определяет два вида сложности: случайная и необходимая.

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

С необходимой сложностью все не так просто. Необходимая сложность определяется бизнес задачами. Если наша программа должна делать 30 разных штук, то мы будем должны эти 30 штук написать. И у нас не будет возможность этого избежать, так как само оно делаться не начнет. Нужно считать зарплату? Придется писать код. Нужно строить отчет? Мы будем писать код, который готовит этот отчет.

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

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

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

В очередной раз проверил, как работает усталость на способность программировать. Вчера поздно вечером, можно сказать ночью, уставший, решил порешать задачи на литкоде. Простые и средние задачи шли норм, но вот дошел до задачки hard, где надо было чуток подумать, и началось интересное.

Я сумел придумать алгоритм, и он даже сработал на некоторых тестах, но в одном тесте был какой-то затык: я пытался дебажить и так, и сяк, убил точно больше получаса на поиск проблемы, сдался и лёг спать. Интеллект 0%

Утром встал, из любопытства глянул - и СРАЗУ понял, в чем проблема. Сразу блин, за ноль минут.

Просто перепутал && и || 😂

Так тупо, капец

В общем, алгоритм от капитана:
1) устал - отдохни (кофе - не отдых, если чо)
2) отдохнул - работай
3) при необходимости повторить

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

Пятничный наброс

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

В первом случае ты выдаешь проработанную аналитиками задачу, обкладываешь сотрудников регламентами, правилами, обязательным % покрытия тестами, обеспечиваешь автоматический и ручной контроль каждой строчки, 2 апрува обязательно, навязываешь истинно правильный подход к разработке, объясняешь как именно надо работать с базой данных (с ORM там или без), апрувить новые либы могут только избранные, выкатывать на прод только Вася и только в определенное время и еще 100500 инструкций.

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


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

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

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

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

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

Нашел забавную вводную статью (я бы даже сказал вводную миникнигу), объясняющую происходящее с программой на низком уровне: как работает процессор, как запускается приложение, как несколько процессов работают одновременно, что такое syscall, зачем нужен libc, как идет взаимодействие с памятью и т.д.

Причем всё, можно сказать, практически на пальцах, насколько это возможно. Для тех, у кого нет общего понимания здесь - must read:

https://cpu.land/

Подпишись на канал о разработке Cross Join

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

Разработчик не робот, ему в среднем нужно 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

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

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

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

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

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

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

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

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

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

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

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