Из книги про 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, но подход к разработке интересный.

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

IT-ёлочка

Вопрос из зала, от анонимуса:

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

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

Советую озаботиться антифрод-системами, особенно в Новый Год.

Моя дочка (6 лет) в прошлом году попросила у дедушки Мороза куклу, в этом - велосипед. А сегодня поняла, что уязвимость можно эксплуатировать, и в следующем году будет просить сундук с золотом, серебром и кристаллами(!).

По-секрету мне рассказала.

Скрам на пальцах

29 декабря в реестре NPM был опубликован пакет под названием «все» (everything), содержащий в качестве зависимостей вообще все пакеты npm. А по правилам реестра, зависимый пакет не может быть удалён (unpublish).

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

Разработчики «всего» заявили, что не ожидали таких последствий, и обратились к NPM и GitHub, чтобы решить проблему. По иронии судьбы, команда не смогла самостоятельно отменить публикацию «всего» из-за циклической зависимости, по сути, пакет был зависимым от самого себя.

«Мы просто подумали, что это будет забавно», — написал Эван Боэс, участник «всего», в ответ на вопрос другого пользователя GitHub о цели проекта. «Мы не знали, что все это произойдет»

К пакету «все» прилагался файл «README», в котором говорилось: «Пожалуйста, не устанавливайте это…». Несмотря на предупреждение не устанавливать пакет, сайт реестра NPM указывает, что по состоянию на 3 января «все» было загружено 224 раза.

Update: на данный момент проблема устранена