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

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

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

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

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

В языке 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.

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

В Go был принят proposal, добавляющий в стандартную библиотеку языка улучшенный http-роутер, чем-то похожий на gorilla/mux. Потому что тот, что уже сейчас есть в Go, дает только самые базовые возможности и в реальной жизни не особо применим.

В статье говорится, что его можно ждать уже в 1.22.

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

Рефакторинг старого кода (со звуком)
----
Cross Join - канал о разработке, подпишись

Из книги про Ruby, это ппц :)) Кстати, одна из причин, почему люди идут из разных языков в Go - там мозг вообще не надо подключать

(картинка взята из канала программистика)

Удивительно!

Не прошло и 100500 лет, как вышел pgbouncer 1.21, который научился обрабатывать prepared statements.

Пусть немного странновато реализовано и на синей изоленте, но всё же это прям биг дил

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

Послушал фоном доклад, в котором анализируется, почему в языке Go (да, я опять про го :)) никто не юзает ORM.

Мой вывод такой, что в Go так просто сложилось (где-то треть народу даже никогда не пробовали ORM в Go, тупо делают как все). При этом запихать данные из селекта в струкутуру можно с помощью, например, jmoiron/sqlx:

people := []Person{}
    db.Select(&people, "SELECT * FROM person ORDER BY first_name ASC")

, а сбилдить запрос из частей по условиям (например, это может быть нужно при обработки формы фильтрации данных), но не юзать небезопасную конкатенацию, можно через squrrel


u

sers := sq.Select("*").From("users").Join("emails USING (email_id)")
active := users.Where(sq.Eq{"deleted_at": nil})
sql, args, err := active.ToSql()

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

Интересно, конечно, что в разных языках по-разному, в Руби, как я понимаю, работают с ORM чуть ли не 100%

Наброс в порядке бреда. Философский вопрос.

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

Вообще, принципиально для этого почти всё есть, чуть улучшить нейролинк, чуть увеличить количество параметров нейросети, и вперёд.

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

"80% руководителей в США сожалеют о решении вернуть сотрудников в офисы"

Т.е. сожалели что выгнали из офисов, теперь сожалеют что загнали в офисы. Когда уже от%#%бутся от людей и будут оценивать индивидуальный результат, а не среднее количество жопочасов на единицу площади.

Еще про ORM

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

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

В итоге при использовании ORM обычно получается что-то вроде проектирования своей бд прямо в коде (сущности и их взаимосвязи), и борьба с проблемами производительности никуда не денется всё равно, как ни абстрагируй. Язык запросов в виде цепочки объектов и методов читается хуже, чем SQL, по сути это особый язык, который надо учить. За себя скажу, что когда писал на PHP (Laravel), длинные запросы на Eloquent меня иногда изумляли своей сложностью чтения.

В итоге, кстати, некоторые производители ORM даже пытаются прикрутить свой собственный абстрактный недоSQL на объектах бизнес логики, например как в DOCTRINE:

```

php

$query = $em->createQuery('SELECT u FROM Doctrine\Tests\Models\Company\CompanyPerson u 

WHERE u INSTANCE OF Doctrine\Tests\Models\Company\CompanyEmployee');

```

или Hibernate:

 java

IQuery q = s.CreateQuery("from foo in class Foo where foo.Name=:Name and foo.Size=:Size");

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

Есть еще такое мнение, что ORM - это как слой, абстрагирующий от способа хранения. Типа, сегодня ты пишешь на MySQL, завтра на Postgres, после завтра вообще в файлах хранишь - и тебе пофиг, код остаётся тем же. Чистая архитектура.

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

Про чистоту архитектуры тоже можно вставить 5 копеек, чтобы два раза не вставать. Очень часто слои пересекаются. Ты как ни крути, но делать абсолютно 100% независимый слой бизнес-логики (юзкейсы, сервисы) - это иногда бывает очень дорого. Например, если тебе надо построить хитрый отчет, ты будешь использовать SQL с группировками, оконными функциями, фильтрами и джойнами, выжимая из базы данных всё, что можно, включая хаки. Там будет не до абстракций. Да просто сделать group by и посчитать количество тех, у кого count больше одного - это ведь уже бизнес-логика в SQL.

НО

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

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

https://www.youtube.com/watch?v=rCJvW2xgnk0 - REST API сервис на Go
https://www.youtube.com/watch?v=EURjTg5fw-E - gRPC сервис на Go

Максимально подробно и практично.

(пост про IT, если чо:))

Штраф за безбилетный проезд 1000 крон, примерная вероятность проверки контролёром - допустим, примерно один раз на 100 проеханных остановок.

Давайте умножим штраф на вероятность.

Т.е. ожидаемый расход при безбилетном проезде одной остановки будет 1000 * (1/100) = 10 крон. А билет стоит 30 крон. Т.е. если ехать одну остановку, то платить в среднем бессмысленно. Да, ты можешь случайно попасть на штраф, даже пару раз подряд, если невезучий, но если всегда и везде придерживаться такой тактики (платить, если едешь больше двух остановок), то будешь в плюсе.

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

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

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

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

Сорян, все примеры какие-то всратые 🙂

Какие-то энтузиасты сделали SQL-обёртку над гитом. Можно сделать SELECT по коммитам или, например, веткам, отфильтровав по автору и сгруппировав еще по чему-нибудь.

SELECT DISTINCT noscript AS tt message FROM commits
SELECT name, COUNT(name) AS commit_num FROM commits GROUP BY name ORDER BY commit_num DESC LIMIT 10
SELECT commit_count FROM branches WHERE commit_count BETWEEN 0 .. 10

SELECT * FROM refs WHERE type = "branch"
SELECT * FROM refs ORDER BY type

SELECT * FROM commits
SELECT name, email FROM commits
SELECT name, email FROM commits ORDER BY name DESC, email ASC
SELECT name, email FROM commits WHERE name LIKE "%gmail%" ORDER BY name
SELECT * FROM commits WHERE LOWER(name) = "amrdeveloper"
SELECT name FROM commits GROUP By name
SELECT name FROM commits GROUP By name having name = "AmrDeveloper"

SELECT * FROM branches
SELECT * FROM branches WHERE is_head = true
SELECT name, LEN(name) FROM branches

SELECT * FROM tags
SELECT * FROM tags OFFSET 1 LIMIT 1

Опубликовал статью про ORM на хабре, плюсаните плиз, у кого есть плюсовалка.
https://habr.com/ru/companies/karuna/articles/774478/comments/

В коментах спрашивают, не наброс ли это.

Сейчас будет каминаут. Честно говоря, я очень часто слегка набрасываю в постах/статьях. Дело в том, что душнину со скрурпулёзным перечислением всех плюсов и минусов и неизменным выводом "it depends" никто читать вообще не будет. А так - я выражаю мнение, в котором сомневаюсь (я вообще во всём сомневаюсь) так, как будто я уверен на 100%. Добавляю резковатые формулировки типа "птичий язык" или безапеляционное "ну, это ерунда, конечно". Цепляющий заголовок. В итоге людей это триггерит, и они со всей душой объясняют в коментах, как я неправ, и почему именно. И эти коменты очень полезны для саморазвития. Бывает, из них узнаешь больше разнообразной информации, чем за годы опыта. Не раз я менял точку зрения на противоположную.

Главное не переборщить с набросом, важно всё же выражать своё мнение, а не просто против аудитории.

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

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

Был сегодня на конференции PgConf EU в Праге.

Simon Riggs в своём докладе сказал, что Postgres в этом году вышел на первое место в мире по популярности среди баз. И что самое интересное, у них есть амбициозные планы в следующие 20 лет поглотить более менее ВЕСЬ рынок БД. Так же как Линукс вытеснил постепенно FreeBSD

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

И вот этого я не понял. Кому это надо? Если это просто опенсорс-комьюнити, то нафига ему вытеснять весь рынок. Обычно сообществу достаточно решать насущные проблемы, и это всё. А не жечь огнём и мечом конкурентов.

Если это инициатива EDB (в которой работает Riggs), то опять же, непонятно, поддерживает ли комьюнити такую активность. В общем, я не понял.

И немного оффтопика: если вы боитесь эйджизма, идите в DBA: на конфе добрые 50% - это седые бородатые мужики. Даже призы на стендах в основном расчитаны на их детей (внуков?): всякие раскраски и плюшевые слоники

Узнал интересную вещь. Как известно, VK пилит свой монолит на KPHP, это подмножество PHP, которое компилируется в C++, а потом уже в бинарь.

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

А уже при выкатке на прод запускается машинерия по компиляции (это долго).

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

Понятно, что навряд ли кто-то начнёт пилить в 2023 году монолит на KPHP, но подход к разработке интересный.