(пост про 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: на данный момент проблема устранена

System Design. The Big Archive

Большая памятка от ByteByteGo для подготовки к собеседованиям или расширения кругозора.

Некоторые вопросы из книги:

— Deployment strategies
— Tradeoff between latency and consistency
— AWS Lambda behind the scenes
— Why is Redis so Fast?
— Why is Kafka fast?
— How does Twitter work?
— Stock exchange design

Антон Морев показал как он работает на 7 мониторах - я был впечатлён 🤯

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

2 видеокарты, 96 Гб оперативки, 5,5 Тб SSD, чтобы не разбирать хлам файлов просто докупает новые SSD по терабайту - моё почтение!

https://youtu.be/z8pnoBh9o9s?si=RA5g--7htjT1oNQt

Время от времени обновляется индекс популярности TIOBE для языков программирования. И постоянно его публикуют различные сми, каналы, обсуждают в подкастах. Но блин, этот индекс строится на анализе статистики поисковых запросов.

Т.е. по сути это не самые распространенные языки, а языки, которые вызывают много вопросов! (литералли)

Например, если кто-то спросит в гугле "ну почему python такое говно", то это прибавит в индексе TIOBE питону лишний балл.

Вот текущий топ, как обычно немного всратый:

1 Python
2 C
3 C++
4 Java
5 C#
6 JavaScript
7 PHP
8 Visual Basic
9 SQL
10 Scratch
11 Go
12 Fortran
13 Delphi/Object Pascal
14 MATLAB
15 Assembly language
16 Swift
17 Kotlin
18 Ruby
19 Rust
20 COBOL

Почему я сделал этот опрос ☝️. Дело в том, что формальное требование в 80% покрытия тестами для языка Go на мой взгляд трудновыполнимо. Например, добавился такой новый код (псевдокод):

err :=  zaprosSelectVBazu(....)
if err != nil {
return fmt.Errorf("zapros error: %w", err)
}

err = drugoyZaprosSelectVBazu(...)
if err != nil {
return fmt.Errorf("drugoy zapros error: %w", err)
}

и т.д.

Т.е. значимых тут строк две, которые стоит покрыть тестами, но есть еще две - это обработка ошибок, которые фиг знает, зачем покрывать.
Т.е. покрытие тут будет 50%. Это если логов нет прямо тут, иначе будет еще хуже. И что вы делаете, если у вас пайплайн жестко настроен на то, чтобы новый код был покрыт не меньше 80%?

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

В других языках был бы try ... catch, который бы для таких случаев ловил сразу всё один раз и выдавал а-ля http 500, но это же го.

При этом 40 человек ответили, что у них обязательное покрытие 80%. Я чего-то не понимаю, как вы это делаете, ребят?

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

Ужасно, конечно, что можно себе подпортить карьеру навсегда. Или СБ найдет какой-то проступок молодости или внезапно ваши тройки в университете (20 лет назад) будут на что-то влиять. Видел вакансии с требованием "An exceptional academic track record from both high school and university"

Появилось исследование на предмет влияния требования возвращения в офисы (RTO) на различные показатели. Анализировались компании из S&P500. В результате выяснилось, что финансовые показатели при возвращении в офисы никак не улучшаются, а удовлетворённость сотрудников падает.

https://deliverypdf.ssrn.com/delivery.php?ID=689110098112003004031017067005075075039006014007064066093070077069026023112003095081038035000043106003046064017116085080085127027053082084022064075127083127101076120084047038089073118002076021087115026025117093107092121112078110084069086073066081017112&EXT=pdf&INDEX=TRUE