Хардкорное кодирование -- это когда допускается открыть в браузере только одну вкладку.

Дам пацанам бесплатные советы :)

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

Почитать эту статью, обратиться к автору,
ну и действительно, попробовать самим написать на плюсах Clickhouse UDF/UDAF.

Можно также поэкспериментировать с Presto или Spark, они тоже с регэкспами работают. Druid, Kylin...

Да, но даже 3rps не тянет :) Когда архитектурная ошибка была сделана исходно стратегически, поздняк метаться :)

P.S.1. Как тут не вспомнить разработку IBM IMS/DB в 1970-х, когда программисты говорили: "Мы ненавидим сложность, она почти всегда ненужная. Мы можем легко и просто хранить данные в плоских файлах, организованных в иерархию. Просто скажите нам ваши запросы, прежде чем мы начнём работать над дизайном схемы БД".

P.S.2. Ну и вообще-то любая аналитическая БД по дефолту подразумевает быстрое чтение и тормоза на запись. Тут уж либо OLAP, либо OLTP :)

Однажды я проработал ~12 часов, причём за это время я:

1. Не написал ни одной строчки кода.
2. Не набрал (и не написал) ни одного символа, связанного с работой.
3. Не читал и не слушал ничего связанного с работой.
4. Ни с кем не разговаривал ни о чём, связанном с работой.

Тем не менее я упорно трудился и добился немалых успехов.

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

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

Написал сегодня пост в вк, насколько (абсолютно!) важно качество кода/дизайна/архитектуры, и почему компании-разработчики софта не несут (пока) никакой юридической ответственности за забагованный софт? ИТ -- единственная в мире инженерная отрасль, где считается чуть ли не нормой продавать бракованные продукты.

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

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

Поэтому, предлагаю посоздавать побольше прецедентных случаев.

Сегодня в Москве несколько часов не работал мтс-овский петушеринг:
"У нас прилег сервис, мы видим проблему и стараемся решить её как можно быстрее."
(раз используете "ё", так уж будьте последовательны, ставьте везде)

Причин три:
1) либо условный "джун" задеплоил что-то не то: виноват сеньор, не сделавший code review;
2) либо накосячили dev/sys - админы: что-то не то сконфигурировали, что-то "само" апдейтнулось криво, сервак сгорел, забыли хостинг оплатить... -- виноват тимлид, не настроивший рабочие процессы;
3) либо хакеры -- виноват безопасник (а если такого нету, то CTO).

"Совершенно не удивлён, и дальше, по мере роста объёмов кода, будет только хуже."

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

Важнейший навык в разработке качественного программного обеспечения -- глубокое понимание домена (предметной области). Если вы плохо понимаете задачу, ваша система, скорее всего, будет представлять собой хаотичный набор всяческих use cases, связанных условными операторами, выполненный в архитектуре "говнокод".

Иногда я бываю в сильной растерянности... С одной стороны, для СильныхИдей хотелось бы готовить материалы примерно такого уровня:
"Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire"
We develop a calculus for lazy functional programming based on recursion operators associated with data type denitions. For these operators we derive various algebraic laws that are useful in deriving and manipulating programs.

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

Вот вчера курсант рассказал:
Готовлю аргументацию по внедрению подхода описания тестов через аннотацию DisplayName. Не ожидал, что простое и понятное предложение использовать достаточно простую аннотацию для повышения ясности теста встретит сопротивление, поэтому приходится готовить защиту для этого.

Совершенно не удивлён, и дальше, по мере роста объёмов кода, будет только хуже.

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

Ну и как бы выглядит довольно фантастически.

За 500т? Если ты действительно на такое способен, так в США это на удалёнке 2-3 сотни тысяч долларов (на руки) в год минимум.

Ставь китика, если реально имеешь

-- опыт управления командой разработчиков
-- опыт разработки архитектуры приложений с учетом масштабируемости, производительности и совместимости с различными устройствами
-- опыт разработки мобильных клиентов на Kotlin и Swift и в серверах Node.js и Unreal

Ну, с Днём Науки! (в СССР он был третьим воскресеньем апреля)

Гипотеза лингвистической относительности Сепира-Уорфа однозначно верна для многих людей и в программировании: языковая структура формирует мышление человека и способ познания им реальности мира.

Всякий раз, когда я пишу какие-то заметки по императивщине или ООП (скоро в вк будет подробный разбор, какие неприятные семантические запутанности неявно вносятся в код при использовании null, и что с этим делать), курсанты нередко пытаются мне это "объяснить". Типа, я просто не понял какую-то фичу.

Да знаю я отлично, как это работает. Это просто то, на что я жалуюсь. Я говорю, что это запутанно и неинтуитивно, и подход ФП всегда лучше.

Но мне в ответ дают ещё больше объяснений, как это работает "правильно" )))

Да... Я знаю. И я говорю снова и снова, что то, как это работает в ООП, плохо и тупо. Мне уже не кажется -- я знаю точно, что люди изучают всё программирование на том языке, на котором они его изучают. Понимаете, о чём я? И в итоге они воспринимают подход этого языка как единственно возможный. Я пытаюсь пофиксить этот когнитивный баг с помощью треков по вычислительным моделям и ФП.

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

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

=

Программирование -- это мышление + синтаксис. Может быть, 90% мышления и 10% синтаксиса. Если синтаксис можно автоматизировать, то научить правильному мышлению можно только того, кто умеет думать.

Llama 3 теперь бесплатно доступна оффлайн, в удобной оболочке =>
LM Studio
+ много разных моделек на выбор.
5 гиг памяти, и на среднем компе почти в реальном времени пишет код. Потестировал её на Python, TypeScript, C# и F#, ну получше чем ChatGPT и даже Cloude.
Можно через API локально сервер поднять, дообучать модель под свои нужды, и всё такое. Очень доволен.

Я думал, это фейк, проверил, оказалось правда =>
netflix.com/helloworld

Самое смешное, посмотрите, что творится в исходниках этой странички 🙈 140 kB !

Надо было ещё в wasm-контейнер запихнуть.

Я всё более скептически отношусь к "бессерверным" вычислениям. Функции без состояния + контейнеры похожи на алгоритмы без структур данных :)

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

Но к счастью, появляются очень хорошие альтернативы: "stateful serverless" :)
И алгоритмы, и структуры данных в одном флаконе. В вк рассказывал подробнее,
напомню, например опенсорсный GolemCloud: вам не нужен сервер, и в тоже время вы не найдёте такой serverful-архитектуры, которую нельзя было бы реализовать с помощью этого инструмента! 🚀🚀🚀

Написал сегодня в вк программный пост, про стратегический рост в айтишке :)

Если вы будете прокачивать не хард- , а софт-скиллы с целью "заработать побольше денежек", то лет через 5 останетесь вообще без штанов. Вас обойдут реально умные ребята, с хорошим образованием, знающие и умеющие в computer science...

В один прекрасный (и уже не такой и далёкий) день внезапно выйдет какая-нибудь Llama 7 от гениальных математиков, и с джуниорским (а потом и миддловским уровнем) будет покончено. И что вы будете делать?..

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

Вот увидите, через 1-2 года все инфоцыганские популярные онлайн-курсы по программированию начнут учить computer science, качественному software design и профильной математике (если конечно найдут хороших преподов, в чём большие сомнения). Без этого немыслимо будет продуктивно использовать AI...

Меня это вообще не волнует, потому что, хм....

Нифига себе:

Narya -- new proof assistant that implements a type theory that is a common generalisation of dTT and HOTT!

Да ещё и написано это чудо на F# OCaml!

(только HOTT это не HoTT :)
This type theory seeks to combine the advantages of "Book HoTT" and cubical HoTT, and avoid some perceived disadvantages of either

Про кубики я пояснял 5 лет назад: "Кубическая теория типов для малышей"

=

"Towards Large Language Models as Copilots for Theorem Proving in Lean"
Our latest experiments show that our co-pilot can automate >80% of the proof steps (2.3 times better than the previous rule-based baseline aesop).

P.S. Тем временем: "Яндекс разрабатывает Календарь+ с ИИ" 😁

Грядёт Java 23 !!1
Поддержка векторных вычислений, паттерн матчинг сделали почётче,
добавили Class-File API (a standard API for parsing, generating, and transforming Java class files), а также Stream Gatherers:
This will allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations.

Только не знаю, "transform data" имеется в виду наверное "pulling data" ?

Вот если "pushing data", было бы реально круто, но скорее всего нет.