Ожидание:
HoTT в Lean 4: 3/10 (почти готовая реализация)
HoTT в Python: 10/10

Реальность:
HoTT в Lean 4: 8/10
HoTT в Python: 5/10

Вот этот контринтуитивный момент стал для меня пожалуй самым важным пониманием - из реальной практики - и на него не жалко было потратить несколько сотен долларов. В принципе я как-то интуитивно предполагал:
"...4. MLTT++ на Python по-взрослому (термы/значения как типы данных)."

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

Ровно так и получилось: оказывается что чем сильнее система типов, тем будет не легче а тяжелее реализовывать на ней сложные абстрактные темки. Многие годы до вчерашнего дня я считал 💯 что чем она сильнее, тем в любом случае будет проще и быстрее , при надлежащем уровне понимания, что угодно на ней реализовывать -- но нет.

Теперь совершенно не исключаю что вот именно уровень C# или Python с аннотациями типов и есть как раз тот самый оптимальный баланс относительно реальных прикладных практических задачек которые можно реализовывать с какой-то формальной поддержкой со стороны HoTT.
Буду над этим отдельно много думать, и что с этим пониманием делать дальше.

Конечно моя реализация в некотором смысле игрушечная: type inference "на уровне компиляции" в ней отсутствует по сути более чем полностью, и насколько она потянет конструкции на сотни, а тем более тысячи, термов, вопрос пока открытый. Хотя конечно чисто технически, уверен, это вполне можно будет решить.
Пока всё уместилось в тысячу строк кода, и думаю что теперь уже не будет особых проблем автоматически конвертировать его на PHP или C++. Отдельно хочу попробовать "обратную" схему: из Python-реализации в Lean :)

Ну и буду дальше изучать/экспериментировать с тем что получилось. Ещё вчера я приунывал, что не получится прыгнуть выше MLTT, а сегодня уже думаю, как бы сделать киллер вообще всех систем топового уровня, наподобие lean, f*, agda, coq )))

Потому что у меня всё же цель не продакшен, а обучение этому всему.

Продолжаю работу с курсантами 😎

--- GameLogic здесь будут храниться игровые правила и логика управялет тем, КАКИЕ действия будут выполнены
Правильный коммент кстати, как раз сегодня на эту тему я сделал пост.


--- Если после перехода с MySQL на PostgreSQL вся логика хранения пользователей не изменилась — значит, "модель пользователя" была правильной абстракцией, а "таблица в БД" — нет.
---Скрипты, правда, запускаются ощутимо медленнее. Поскольку меня такое раздражает, маловероятно, что буду этим пользоваться.
---Первая серьёзная проблема, с которой столкнулся - установка библиотеки.
---Не начал вовремя, так как отвлекся на заказ секундомера
---Я реализовал СЛИШКОМ много ненужных методов
---поскольку Django Rest Framework в сериалайзерах игнорирует коды при вызове стандартного исключения ValidationError, подставляя всегда 400 статус, то, чтобы не вызывать каждый раз APIException проще сделать собственное исключение
---работаю в рамках одного каталога, хотя нужные мне файлы могут находится и в подкаталогах.
-- Сейчас восстановление возможно только вручную, но планируется автоматизация.
---справедливо будет сказать, что я забыл эти методы исключить после изучения эталонного решения для предыдущего задания

/bdd ...Релизим проект, работаем 24/7, как всегда подвела оценка задачи. Оценивали по форме без анализа внутреннего содержания. Надеюсь когда-нибудь научимся, а пока испытываем боль.
Первый шаг для решения этой классической проблемы -- пройти мой курс по BDD.

Выложил на бусти первый сериал из 14 материалов СильныхИдей
(уровень понимания крепкий джуниор, но наверняка этим темам вас никто не учил даже в универе :)
Так они доступны только моим курсантам, но тут расширенные версии, дополненные множеством примеров (преимущественно на Java).

Рассматриваем начальную БАЗУ программной инженерии
(правильная форма рассуждений и основы programming in small)
для джуниоров и всех интересующихся:
- три уровня мышления о программе,
- основные принципы снижения сложности кода и повышение его выразительности и понимаемости,
- инженерные подходы к отладке и тестированию.

Формат - html-гайд, в архиве 74 файла, 500 тыс. знаков чистого текста (объём средней книги).
Цена пока 1,999 рублей, через несколько дней повышу.

Бедолагам разрешаю брать "вскладчину" или подождать когда "на торренты сольётся" :)

= Краткое содержание первого сезона =

1. Три уровня рассуждений о программной системе
Вы когда-нибудь задумывались о том, что значит "программа работает неправильно", "программа ошибочна"? Что-то вроде "ну, это когда она вылетает с ошибкой... но если она вроде работает, а может сломаться гипотетически, при определённых условиях... кхм, подождите...".
Давайте разберёмся с этим...

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

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

4. Снижение цикломатической сложности кода как метод проектирования (база)

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

6. О циклах по умному
Каждый раз, когда вы пишете цикл, вы делаете это с одной из нескольких целей. Понимание программы — это искусство восстановления замысла по коду, и тут соответственно будет очень полезен навык быстрого распознавания нескольких разновидностей циклов.

7. Правильное проектирование на микро-уровне
Небольшой, очень наглядный и поучительный пример подходов software design: огромное улучшение, которое мы можем делать даже в крошечных функциях.

8. Три важных принципа programming in small
...Эти три, казалось бы, тривиальных шага помогли и мне, и многим другим, продуктивно выдать много-много качественного кода. Я надеюсь, что они смогут сделать то же самое и для вас.

9. Три свойства качественного кода
Что такое качественный код? На этот вопрос не может быть короткого исчерпывающего ответа. Вопрос "что такое качественный код" сродни вопросу "что такое квантовая физика". Это тема целой области.

10. Группировка в функциях и файлах
Разбиваете ли вы большой метод на более мелкие? Если да, то вы правильно обозначили логические границы, но при этом добавили в код некоторую зависимость/косвенность/перенаправление.
Если же вы не разбиваете его, то всё будет наоборот: вы избавляетесь от множества методов и внутренней вложенности вызовов, однако явные границы между логикой теряются.

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

12. Как правильно писать тесты
Действительно, как вы можете добиться прогресса, если тесты всегда срабатывают успешно? Разве вы иногда не делаете ошибки? И что будет, если вы напишете кучу кода, и потом его просто придётся стереть, разве это не обидно, разве это не трата кучи усилий впустую?

13. Как правильно относиться к TDD
Мы учимся с самого начала думать над кодом в терминах спецификации, предметной области, домена: берём техническое задание и транслируем его в формальный вид в виде тестов, которые уже однозначно задают нужную логику поведения.

14. Отладка как наука
Существует ли теория отладки в целом? В основе теории отладки лежит универсальный метод: вы можете ускорить отладку, задавая вот какие вопросы...

Доступен для покупки на бусти.
Формат - html-гайд, в архиве 74 файла, 600 тыс. знаков чистого текста (объём средней книги).
Цена пока 1,999 рублей, через несколько дней повышу.

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

Мои курсанты перед тем, как я им порекомендую начинать искать работу и помогать по карьере, сперва должны сделать "дипломный" проект, около 40 заданий. В нём примерно в сравнении с картинкой раз в 10 больше технических темок, которые надо изучить хотя бы с минимальной практикой и продемонстрировать гитхабом, прежде чем рыпаться на поиски juniorской работы.

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

- Докер? Смотрим часовой видосик, и затем пару десятков часов экспериментируем с compose. Главное, суметь на интервью запустить демонстрационный имадж с красивыми окошками (делаем на проекте).

- K8s? Но тут, обратите внимание, требуется не "опыт", а "знание", потому что так-то это отдельная профессия )
Есть Play with Docker, есть Play with Kubernetes, где можно просто из браузера поиграться.

- Настройка CI/CD? Тоже однозначно важная вещь, я курсантам рекомендую, если у них такого на работе (скорее всего) нету, предложить и внедрить как крайне полезное рацпредложение. GitLab CI + Docker изучаются за полдня.
Я вообще всем рекомендую: выполняйте развёртывание как можно чаще (или вашего тимлида пора выгонять).

- Микросервисы? опять требуется не "опыт", а "знания" :)
Ну потому что, будем объективны, джуну вряд ли дадут что-то делать с микросервисами для прода. На второй части дипломного проекта впиливаем обязательно микросервисы с кафкой.

- Spring + Hibernate -- ну это просто по определению базовый фреймворк для Java + базовый ORM (для которого соответственно надо знать стандарт JPA).

- SQL + PostgreSQL - а это вообще фундамент для любой базы бэкенда :)

- gradle/maven - "умные" сборщики пакетов java (на самом деле боль и страдание:), тоже база, без них никуда.

- JUnit - фреймворк тестирования, тут и обсуждать нечего.

- git (из командной строки) - тоже абсолютная база для любого программиста.

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

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

Why the fuck do we let people that have no computer science backgrounds write code? Unacceptable!

В пояснение вчерашнего опроса ↑ ↑ ↑

Почему именно ФП -- подмножество ООП?
(берём чисто прикладной уровень понимания)

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

2. Алгебраические типы данных из ФП можно реализовать в ООП как "запечатанные" (sealed) классы.

3. Product тип (произведение типов) -- это просто обычный класс.
Sum тип (сумма типов) -- это абстрактный класс, каждый из наследников которого -- один из вариантов sum типа.
Таким образом мы можем комбинировать sum и product типы, создавая иерархии классов, где каждый производный класс представляет конкретный вариант sum типа, а поля класса представляют product типы. А чтобы такая иерархия оставалась "алгебраической", производные классы мы просто запечатываем.

=

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

На мой взгляд, стратегически правильный подход -- правильно сбалансированная комбинация этих двух подходов. засада только в том ,что такой баланс не определить без знания cs :)

Сегодня упал хостинг, где я размещаю свои новые курсы (TDD, BDD, лямбда-исчисление... а также курсы для начинающих с нуля).
Собственно единственная причина, по которой я не использую свою собственную прекрасную и неуязвимую обучающую платформу (которую делал сам на 100%), что до сих пор в России нету НИ ОДНОГО автономного сервиса для автоматизации приёма платежей.
Всяческие а- б- в- т- ю- я- кассы, с настройкой которых куча головняка и под которые приходится пилить поверх едва ли не полноценный собственный биллинг, чтобы сделать вообще элементарнейшее: чел оплатил заданную сумму через стандартный интернет-эквайринг, и ему тут же + на почту сбросился ключик доступа или логин пароль, и всё. Я бы за такое и 15% отдавал, но нет. Вот и приходится выкручиваться через всяческие внешние сервисы хостинга курсов, бусти-шмусти, самопальные платёжные боты-фиготы и прочую муть...

Я так понимаю что Selectel -- это же почтовый сервис? Почему тогда весь хостинг курсов упал, ну ладно бы только почта заморозилась. Детский сад штаны на лямках... Сплошные имиджевые потери, не говоря уже о материальных, но PO как правило так и остаются непробиваемыми, сколько им не тверди о важности software design.
Впрочем, совершенно не удивлён, и дальше, по мере роста объёмов кода, безумно ускоряемого "с помощью" AI, будет только хуже.

=

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

"Ключевой вопрос любой зависимости независимо от её типа, очевидно, такой: "Зависит ли А от B?".
Любая зависимость характеризуется как минимум тремя параметрами:
1) семантика или конкретная вычислительная модель,
2) ключевые свойства,
3) пространство допустимых изменений.

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

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

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

Хотя я бы начинал с аттестации не рядовых бедолаг, а эйчаровской мафии:
надо прежде всего компании обязать размещать вакансии в единой строгой форме.
Набор стандартных скилов с грейдами и всё, ни возраста, ни пола, и ничего другого проверяться не должно. А если уж кого-то пригласили на живое интервью, лайв-кодинг, дали тестовое задание -- и потом отказывают, то должны заполнить детальный чек-лист с с парой сотен пунктов, поясняя кандидату, почему он не подходит.

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

=

Но пока с нетерпением ожидают завтрашнего утра потенциальные кандидаты на распил тендер очередных миллиардов на госпроект со слабо понятной эффективностью (будет ли такой сертификат давать хотя бы +2% к резюме? очень большие сомнения, если для компаний не будет кнута) ,

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

Сейчас там два набора тестов, постепенно буду добавлять:
Знаете ли вы нововведения C# 9 ?
Знаете ли вы нововведения Spring Framework 6 ?

❤️❤️❤️❤️❤️

Это хорошо известная сеть платных клиник, обслуживание топчик, врачи супер, к кандидату наук по-любому профилю легко записаться на консультацию за пару дней, а сам приём стоит $30 + доп. процедуры 50-70 долларов, анализы немного подороже конечно. 5 лет к ним хожу регулярно и жутко доволен, в своей реанимации они меня спасли однажды от смерти 🙏😇

За последние годы их стоимость растёт ежегодно примерно на миллиард рублей...
да вот только они экономят лишнюю тыщу долларов на качественном фронтендере )))
Так-то это чисто джуниорский баг: наверняка вместо "name" по невнимательности указали другое поле, какой-нибудь "kind".
Отдел QA? А зачем он нам, и так сойдёт.
фигак фигак и в прод, классика 😬

Курсантам в СИ поясняю контринтуитивную вещь, как автоматизировать тестирование визуальных аспектов (когда в UI что-то пошло не так). Сегодня кстати с помощью AI это значительно проще делать.

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

Готовимся к вечеру пятницы: компьютерная версия русской рулетки =>

в баре усаживайтесь всем дримтимом за стол, каждый со своим ноутом, перезапускаете ОС и из чистого списка убиваете случайный процесс (например просто по случайному номеру в списке смотрите pid) ☠️
Выигрывает тот, чей комп ещё будет продолжать работать 🤘
Ставки на победу придумываете сами 🏆

Винда:
taskkill
taskkill /PID 42 /F

Линукс/Мак:
ps -ef
kill -9 42

На неделе для курсантов добавлены...

...в раздел "Элитный программист" -
59) Почему вам не стоит беспокоиться о составлении идеального плана
Микрозадачи и предварительное планирование нужны только для одного: чтобы свести к минимуму трения в работе. Да, но как это сделать правильно??

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

=

Если вы вдумчиво изучаете и регулярно применяете все без исключения рекомендации моих треков КК, ЭП, БПЗ и СИ+hardwork, без сомнения достигнете 10 программистских совершенств, а также обретёте 37 начал просветления computer science, в числе которых 4 состояния сверхвнимания, 4 сверхспособности и 5 сверхсил.

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

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

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

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

Я для начала предлагаю совсем атомарные вещи: например, давайте попробуем просто выполнять деплой почаще, и посмотрим, поможет ли это.

Но мой принцип: никогда ничего не предлагать в лоб. Типа вот я порекомендовал деплой, они так стали делать, и у них что-то улучшилось. Да нифига.

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

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

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

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

Собираюсь на весну-лето подзаработать курьером, на вело.рф смотрю аренду байков яндекса, но при попытке "Узнать адреса" меня посылают куда-то совсем непонятно куда )))

taximeter:// - что это за протокол такой лол

...Понятно, что в каком-то манифесте указано
<data android:scheme="taximeter" />
чтобы прога аренды на мобилке стартовала.

Ну добавьте для браузеров несколько строчек кода, YandexGPT в помощь:

const isMobile = /Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent);
if (!isMobile) console.log("Not a mobile device");

=

Кстати, html-код лендинга вело.рф, где считанные десятки фраз и одна картинка, занимает 490 Кб, Карл. Первокурсник делал в каком-то визуальном редакторе? )))
Любой жпт нарисует такое за одну минуту и раз в сто компактнее.

А начинается этот код так:

<!DOCTYPE html>
<html class="ua_service_turbo-lpc" lang="ru">

Рекомендация в варианте яндекс-жпт

const isNotMobile = !(/Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent));

как-то смутило, а что тут собственно делает ежевичка (ведь давно уже rip)? Я кстати где-то в 2013-м пилил для неё какую-то гиперказуальную игрушку, даже велись переговоры о предустановке её на всех ежевиках в России, но... грянул 2014-й :) и под санкциями они ушли, а потом и по всему миру сдохли. Последствия (с) :)
Но игра несколько сотен долларов успела заработать в конечном итоге. А больше всего на том проекте заработал я: программисты-исполнители всегда в плюсе )))

=

Я проверил жпт, дипсик, алибабу, яндекс, клод, perplexity, и даже хвалёный свежий грок! выставлял вроде везде на "подумать поглубже", смотрел все последние версии, самые дорогие. И это весёлая компания везде выдаёт практически идентичный код - с BlackBerry - с точностью до наименования переменной.
Собственно легко гуглится, что украден он был конкретно отсюда:
https://stackoverflow.com/questions/3514784/how-to-detect-a-mobile-device-using-jquery
Вот как ежевичка влезла: оригинальному посту 14 лет.

=

Гемини, квен и жпт4o затупили, возможно "сами написали" :)
выдали только одну проверку под андроид, даже ифон не добавили.

=

А несомненными победителями нашего рейтинга становятся три брата-близнеца:
жпт 4o мини , лама и гигасбер (который в 20 раз дороже ламы) 😂

if (window.innerWidth > 768) { /* код для десктопа */ }

Продолжаю работу с курсантами 🤓

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

...Хотел сделать как следует, но если честно чуть не запутался. И оставил основное. Конечно тут много в целом дорабатывать и добавлять.
Интересно, сложность в улавливании всех взаимосвязей программы это неопытность или отсутствие каких-то фишек восприятия и мышления?
Я: Проблема улавливании всех взаимосвязей в программе такая, что мозг не может удерживать более семи элементов одновременно, и как делать свёртку сложных многомерных понятий так чтобы они были уму понятны, подробно разбираем на второй части курсов и в СИ+HW.

...Думал, что сделаю всё гораздо быстрее и в первые дни не вкладывался особо сильно, но "внезапно" очень много нюансов стало возникать.
Зато наконец-то добрался до вашего телеграмм канала.
И конечно первый мой вопрос который меня озадачивает - это нормально, что больше половины того о чём вы пишете я не понимаю?

...Действительно войти в айти за 3 месяца за 200 тысяч (средняя цена сегодняшних курсов по программированию) уже звучит как издёвка.

...Сколько сил потрачено на поиск проблемы, а она была даже не в коде.
(в таймзонах - классика :) и кодировки - вечные боли)

...Да, в работе уже натыкался на такие вещи, было страшно видеть десятки таблиц и полное отсутствие консистентости...

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

...У меня неприятность(. Не разобрался с гитом и не пушил изменения, в итоге пара последних заданий не сохранилась, делаю заново.

=

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

Ну а для тех с кем мы развитием карьеры занимаемся, правила я постоянно уточняю, дополняю и формализую, иначе курсанты бесконечно вязнут в бесконечном изучении технических темок с карьерным КПД 2%.

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

Что-то планировать и тем более бояться, что будет после того как AI научится программировать как сеньор, ну просто несерьёзно.

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

Может быть рептилоиды захватят мир, может быть сразу его уничтожат, но более вероятно, что в первые часы/дни AI, рекурсивно себя улучшая, захватит почту телефон телеграф интернет, энергосети, производство,

затем (месяцы/годы) решит основные экзистенциальные проблемы человечества, связанные с экономикой, медициной, экологией -- будет например введён гарантированный базовый доход. Вместе с этим безработица приблизится к 100%, начнутся политические кризисы (военных конфликтов AI вряд ли допустит), местечковые бунты, кибервойны партизанского сопротивления за контроль над AI,

затем (годы/десятилетия) осуществится полный симбиоз AI и белковых (вживление чипов младенцам), колонизация космоса с помощью самовоспроизводящихся роботов, цифровое бессмертие и в итоге псевдокоммунистический кибергулаг.

Но самые критические изменения, которые перестроят вообще всё, произойдут в первые часы, максимум дни. Поэтому волноваться, не отнимет ли AI работу, смысла нету. Если он сможет её отнять у сеньоров, тогда у всех человеков сразу возникнут проблемы качественно иного рода.

Главный вопрос Software Design: кто контролирует ситуацию -- вы или код, который вы написали?
Если вы не кантрол-фрик, дела ваши плохи: вам предстоит проделать массу работы, чтобы разобраться в этом, и чем дальше, тем ситуация будет становиться всё хуже и хуже. Особенно если вы пишете код "с помощью" AI.

Какое главное различие между "Джуном" и "Сеньором" (независимо от того, на каких официальных должностях они работают) ?

"Джун" получает простые требования и выдаёт сложный код.
"Сеньор" получает сложные требования и выдаёт простой код.

"Умный человек решает проблему. Мудрый человек избегает её"
— Альберт Эйнштейн

Продолжаю работу над новым треком Ясные Системы, где систематизирую различные эвристики программной инженерии и computer science. Так, скоро будет большое дополнение для курса TDD.

Ещё немного в дополнение моей любимой темы про частые деплои -- из неё естественно следует эвристика частых комитов.
-- Работаю над чем-то одним за раз (c учётом 109-го материала СИ "Жёсткий хейт SOLID | SRP");
-- Выполняю рефакторинг с прицелом на потенциально возможные изменения функциональности (генерализация, дефункционализация...);
-- Делаю код максимально несвязанным.
Рекомендую в частности не очень распространённый, но крайне полезный git bisect