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

Был сегодня на конференции 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

смотрите-ка, кто-то прочитал мои мысли. В одном посте я предлагал внедрять нейролинк и записывать всё, что есть в мозгу, чтобы обучать человекоподобных роботов. А тут люди сделали попроще - тупо навесили на ребёнка камеру и обучают по ней ИИ говорить (https://hightech.plus/2024/02/02/rebenok-s-kameroi-na-golove-pomog-ii-nauchitsya-govorit).

Вышел jQuery 4.0.0 (beta) 🙂

https://blog.jquery.com/2024/02/06/jquery-4-0-0-beta/

Как вы наверно уже знаете, вышел Go 1.22, об этом все уже написали. В том числе, в Go добавили (пока что в экспериментальном режиме, под флагом) итераторы. Т.е. оператор yield и прочие штуки, которые есть уже наверно во всех языках. Теперь затащили и в Go. Ну ок.

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

Имхо, если уж добавлять сахар, то в самом главном месте. По всем опросам среди раздражающих факторов языка обработка ошибок по-прежнему лидер №1 с большим-пребольшим отрывом. И разработчки Go не могут этого не видеть.

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

Бесит всё 🙂

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

"Корпоративный Agile пытается отдать приоритет адаптации И предсказуемости, не осознавая, что нужно выбрать что-то одно"

Автор предлагает или перейти к настоящему basic-аджайлу или честно называть происходящее водопадом.

https://bits.danielrothmann.com/corporate-agile