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

Однако есть простое, хоть и неочевидное решение, если подумать, чему изоморфно подмножество допустимых плейлистов (и при чём тут биективный гомоморфизм моноидов :). Курсантам в СильныхИдеях скоро поясню эту тему примерами кода.

"Need to take moment to completely rewrite the software stack’"
-- Elon Musk

Раньше: программная инженерия, capability maturity model, классические итеративные подходы, аджайл-методики...

Сейчас: Маск-стайл в разработке программных продуктов, основанный на прихотях и самодурстве.

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

Понятие Cohesion (сцепление) по Кенту Беку:

-- Вещи, которые должны изменяться вместе, находятся вместе в проекте ("физически" в условной проектной папке).

-- Вещи, которые не должны изменяться вместе, находятся в разных местах. Где? Это вам и надо определить, товарищ проектировщик. Но, скорее всего, вместе с теми вещами, которые должны меняться одновременно с ними.

Бертран Мейер в своей методике ООАП рекомендует вроде бы другой подход: группируем в проекте классы в кластеры по их логической общности (например, все классы оружия или все классы ролей пользователей), но если подумать, этот подход будет почти изоморфен Беку. С какой стати вдруг потребовалось одновременно изменять классы, по смыслу не связанные? Хотя правильно спроектированное ООП подразумевает смысловую правку ровно одного класса, если SRP хорошо выдержан.

Тут главная фишка, что думаем об этом всём именно в контексте cohesion, не скатываясь в coupling.

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

Вот хороший разбор темки для тех, кто владеет хаскелем:
what-does-isomorphic-mean-in-haskell
а я курсантам в СильныхИдеях дам более простой разбор на питоне.

Смешное: "Why aren’t regular expressions a lingua franca?" 2019

15% регэкспов в разных языках будут работать по разному, т.е. они фактически непереносимы на уровне реализации. В то же время 90% программистов тупо копипастят подходящие регэкспы из интернета, не заморачиваясь контекстом, в котором они обсуждаются.

Всегда помните, что regex, скопипащенный из программы на PHP, скорее всего будет вести себя несколько иначе в JavaScript.

Миллиарды, вложенные венчурными инвесторами в стартапы -- против маленького веб3-агрегатора децентрализованных финансов, DefiLlama со смешной ламой, движок полностью доступен на гитхабе. Как думаете, кто победит? :)

Мировое рептилоидное правительство проводит глобальную операцию прикрытия: всем либеральным СМИ велено трактовать происходящее исключительно как "лопается криптопузырь" и "крипта это мошенничество и криминал", а властям США и главам зависимых центробанков приказано начать жёсткое регулирование криптопроектов.

Это не крипто-пузыри, а классические банковские пузыри. Кредитование не тех субъектов, неверные оценки залога, высокомерные нефтяные шейхи, и затем бегство вкладчиков. В FTX/Alameda инвесторы вкладывали безумные деньги, сотни миллионов долларов за считанные месяцы. Тут достаточно просто почитать про хедж-фонд Long Term Capital, едва не обрушивший мировую финансовую систему, суб-прайм ипотеку, кредитно-сберегательный кризис Savings & Loan...

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

Рептилоиды чётко работают против светлого децентрализованного будущего :)

Но ничего, они жёсткие и умные, но мы жёстче и умнее :)

DeFi -- не проблема, DeFi -- решение.

P.S. Стабильнее всего зарабатывают на этом всём конечно программисты )))

Баги в реализациях regex найдены например в движке V8, а также в Python, Rust, Ruby, однако имеются они и в самих регэкспах :) Почти половина из них связана с неправильным поведением регулярных выражений, а около 10% -- с неправильным использованием API regex. В работе "An Empirical Study on Regular Expression Bugs" 2020 приведена подробная иерархия причин ошибок и даны 10 паттернов, которые исправляют многие распространенные баги regex.

Илон Маск не перестаёт радовать :)

Разослал сотрудникам письмо "Twitter 2.0", где заявил, что новая версия твиттера "need to be extremely hardcore" -- должна работать под критической нагрузкой многие часы. Кто не подтверждает участие в этой движухе в течение 24 часов, получает трехмесячное выходное пособие и пендаль.

А через сколько секунд развалится твоя система на первой тысяче rps, бро? :)

P.S. По взрослому, конечно, это совершенно не про то, как создаются долговечные и надёжные highload-проекты, и не имеет ничего общего с лучшими практиками программной инженерии.

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

Запасаемся попкорном: крайне увлекательный сериал, и наверняка станет очень поучительным. И тамада хороший.

P.P.S. Пожалуй, за компанию обновлю и мою Школу до 2.0 :)

Спрашивали по вчерашнему, а как это "по-взрослому" такие проекты делать?

Ну вот эталонный современный уровень System Design на примере рекомендательной подсистемы тиктока:
"Monolith: Real Time Recommendation System With Collisionless Embedding Table"

Крайне показательно также, насколько сегодня важно хорошо знать АСД, если вы хотите стать элитным программистом.

Зарегился наконец в Mastodon, скорее всего и сервачок подниму. Давно хотел, и вот вчерашняя заметка подстегнула:
"Как зарегистрироваться в Mastodon. Твиттерские переселяются в соцсеть после ультиматума Илона Маска"

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

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

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

Отчасти сила Mastodon заключается в её децентрализованной природе. Это истинный веб3 и это плюс, когда мы говорим о технологиях и инновациях. Это минус, когда мы волнуемся о централизованной синхронизации и возможности злоупотреблений. Электронная почта так и не смогла оправиться от своего открытого духа, что позволило спамерам и мошенникам делать то, что им нравилось, а несовершенные фильтры помогали слабо.

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

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

Смешное: AI-ассистанты, помогающие писать код (вроде микрософтовского copilot), "помогают" так, что число уязвимостей в проекте только растёт, причём вдобавок вылазит когнитивный баг: программисты полагают, что их код с помощью AI наоборот стал более защищённым. Ну, понятно, так удобно перекладывать ответственность за свой код на других.

Исследование Стэнфорда: "Do Users Write More Insecure Code with AI Assistants?"

Вообще-то это не code review, а системная архитектура. А где use cases, которые её определяют? И куда они спрятали ту самую 1,000 RPC? :)
Квадратики и стрелочки, фактически одна view model, и всё. Какой-то детский сад на уровне собеседования во второсортную контору :)

"ISO/IEC/IEEE 42020:2019. Software, systems and enterprise — Architecture processes" ? Нет, не слышали.

P.S. С другой стороны, 80% айтишников уволено, а твиттер всё ещё работает, так что прежняя архитектура не такая и плохая.
P.P.S. 28:1 :)

Даже в новой архитектуре, которую оставшиеся в твиттере пацаны предъявили Илону Маску, потребуется примерно миллион довольно мощных серверов для поддержки графовой базы с порядка миллиардом узлов. Причём поддерживать это всё хозяйство им придётся самим: даже с максимальными скидками 50% на aws за хостинг такого проэкта придётся отстёгивать почти полмиллиарда долларов ежемесячно.

Для сравнения, Neo4j держит триллион узлов по цене $250 тыс. долл. за месячный облачный хостинг. Да и проблема асинхронного логирования без забивания диска тоже нормально решается известно как (мои курсы по highload-системам в помощь :).

Алгоритм SHA-3 был стандартизован в 2015-м, и лишь спустя 7 (!) лет в его реализациях на Python и PHP нашли дефекты: "SHA-3 Buffer Overflow".

Что делать с этим вечным багом? Теоретическая computer science игнорирует проблемы крупной промышленной разработки программного обеспечения, потому что их слишком трудно формализовать. А кибербез в основном занимается поверхностной, для галочки, борьбой с цифровой преступностью с помощью готовых инструментов на уровне скрипт-кидди, или тактическими выпусками патчей, потому что реальная защита слишком трудна.

Лучшие инвестиции в моей жизни пришлись на последние пару лет. Во-первых, я прошёл мощный семинар по проектированию у PhD-пацанов из MIT (тысяча долларов), и во-вторых, на днях заплатил 1,100 долларов за онлайн крутейший воркшоп "Simple by Design: Declutter Your Architecture, Code and Test" (это где банили за упоминание SOLID, Clean Architecture, TDD и прочую антиматематическую ересь-мартинфаулерщину :), и теперь у меня есть десятки часов ценнейшего видео, только для вас, дорогие (курсанты). Выжимки будут как обычно в СильныхИдеях.

• rethink classes and methods
• rethink data and code
• rethink readability
• rethink unit testing and mocking
• rethink dependency injection and composition
• rethink layering in architecture
• rethink integration testing

В моей Школе распродажа!!!

Скидки до 98,7% на консалтинг по конструктивной математике и коучинг по гомотопической теории типов!

Комбинаторы Шейнфинкеля по цене комбинаторов Карри, а солверы гиперболических уравнений в частных производных по цене эллиптических!

Ковариантные функторы по самым низким ценам!

Купите полиморфное лямбда-исчисление, и я добавлю поддержку зависимых типов бесплатно!

В качестве бонуса -- множество с дробным количеством элементов.

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

Спрашивали, не дорого ли $1,100 за двухдневный семинар?

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

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

Но даже крепкий миддл -- это где-то 0,1% от мирового топа, сеньор -- 1-2% максимум, а дальше каждый процент даётся уже существенно труднее, дольше, дороже. И прыгнуть с 1% до 10% сразу не получится, потому что в учебных материалах для каждого уровня имеется ряд подразумеваемых абстракций, без практики в которых подобные воркшопы будут восприниматься как магия.

Но если я тут прыгаю например с 25% до 33%, то это такой выигрыш в ресурсах, который вообще ни с чем не сравним.
Поэтому и дальше буду спокойно развиваться в этой маленькой нише programming in large для тех самых 2%, у которых ещё горят глаза.

Чтобы всю жизнь наслаждаться спокойной интересной работой, когда, едва вы прочитали первую страничку техзадания любой сложности, за доли секунды, на быстром мышлении S1, качественно обученной нейросеткой ума, рождается готовая схема, готовая архитектура. Остаётся только это неспешно и без суеты перевести в аккуратный код, занимаясь этим, как я сейчас -- в приятном уюте и комфортном тепле, попивая вкуснейший мятный капучино на безлактозном соевом молоке с бергамотовым тирамису :)

P.S. Уточняли, не релоцировался ли я. Нет, и не собираюсь, десятки лет живу в прекрасном московском микрорайоне Ховрино (лучше только в Крылатском :).

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

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

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

Почему это не так?

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

В первую волну дот-комов, в начале 2000-х, в стартапах той поры почти невозможно было найти эффективных менеджеров по управлению с дипломом MBA. Но зато почти все были теми самыми 10x-разработчиками, знающими и умеющими тучу всего самого разного, и быстро решающими полезные задачи с помощью реальных технологий, которые не были слишком разрекламированы. Enterprise JavaBeans, Delphi, CORBA, XML... Сегодняшнему мэйнстриму было бы неплохо вернуться в те дни.

...чтобы в редакторе везде автоматически вводился префикс javaBeansEnterprise :)

Смешной тренд: когда сеньоры массово укатили, на их место стали лихорадочно ставить миддлов. Кто-то вытянул, но 80% конечно нет. Однако возвращаться обратно в миддлы пацаны уже не хотят :)

И так как в резюме у них теперь есть официальная запись "сеньор", спокойно увольняются на более вкусные печеньки. А в компании получается на одна дыра, а две: ни сеньора, ни миддла.

Я полностью на стороне этих ребят, и рекомендую, если на интервью будут вникать в такой опыт более подробно, напоминать, что дескать неудачный опыт лучше удачного, и астронавтов на Луну в США отбирали именно по опыту фейлов, а не побед.