Реальная цель всех русских айти- компаний/департаментов/стартапов/... на 2025-й -- выжить. Идеально, если получится просто выйти в ноль.
План-стандарт -- не закрыться. План-минимум -- закрыться так, чтобы не отправили в кутузку. Поэтому и происходят сейчас массовые сокращения увольнения ....
Вдобавок давит и ai-дебилизация рынка программистов... точнее, хайп на темке жпт, которому всерьёз верят тотально неграмотные айти-менеджеры. Ну, как бы когда по 1-му всерьёз рассказывают про советские корни дипсика... Поэтому, думаю, вторую волну ai-дебилизации следует ждать этой весной.
Что делать нам с вами? Двигаться в инди-хакерство 💯
Переходите на удалёнку, прокачивайте скиллы software design чтобы делать рабочие задачки на день во много раз быстрее, а высвободившееся время вкладывать в инди- , и делайте ставку в плане денег только на самих себя. Не *****. Верьте в себя!
Я подправил карьерные цели для курсантов в этом контексте, и на бусти для всех папищеков скоро выложу БАЗУ, с чего начать, какой сделать первый шажок в ситуации, когда вы абсолютно не представляете, куда и как.
План-стандарт -- не закрыться. План-минимум -- закрыться так, чтобы не отправили в кутузку. Поэтому и происходят сейчас массовые сокращения увольнения ....
Вдобавок давит и ai-дебилизация рынка программистов... точнее, хайп на темке жпт, которому всерьёз верят тотально неграмотные айти-менеджеры. Ну, как бы когда по 1-му всерьёз рассказывают про советские корни дипсика... Поэтому, думаю, вторую волну ai-дебилизации следует ждать этой весной.
Что делать нам с вами? Двигаться в инди-хакерство 💯
Переходите на удалёнку, прокачивайте скиллы software design чтобы делать рабочие задачки на день во много раз быстрее, а высвободившееся время вкладывать в инди- , и делайте ставку в плане денег только на самих себя. Не *****. Верьте в себя!
Я подправил карьерные цели для курсантов в этом контексте, и на бусти для всех папищеков скоро выложу БАЗУ, с чего начать, какой сделать первый шажок в ситуации, когда вы абсолютно не представляете, куда и как.
7⚡48✍24❤8👍5🔥1
Простой лайфхак, как вам гарантированно проходить любой собес:
Вас как специалиста не должно смущать вообще ничто и никак.
И рабовладельцу ничего не остаётся, кроме как взять вас на работу под его горящие проэкты за хорошие деньги на ваших условиях.
/dev в вк выложил пост, как объективно и автоматизированно, и при этом легко и просто оценить, насколько качественно спроектирована ваша система.
...Когда вы создали первые 5 классов, спроектировали первые 5 таблиц в базе, вроде всё норм. Но когда вам надо 256-й класс "впендюрить" в забетонированную систему с высокой связанностью (coupling), начинаются сплошные боль и страдание.
А если вы вдобавок используете протекающие абстракции (например, применяя классические паттерны проектирования "интуитивно", "на глазок"... или не применяя их совсем, и выдумывая собственные костыли и приляпки), то они просто убивают смысл всех ваших интерфейсов в проекте.
Вас как специалиста не должно смущать вообще ничто и никак.
И рабовладельцу ничего не остаётся, кроме как взять вас на работу под его горящие проэкты за хорошие деньги на ваших условиях.
/dev в вк выложил пост, как объективно и автоматизированно, и при этом легко и просто оценить, насколько качественно спроектирована ваша система.
...Когда вы создали первые 5 классов, спроектировали первые 5 таблиц в базе, вроде всё норм. Но когда вам надо 256-й класс "впендюрить" в забетонированную систему с высокой связанностью (coupling), начинаются сплошные боль и страдание.
А если вы вдобавок используете протекающие абстракции (например, применяя классические паттерны проектирования "интуитивно", "на глазок"... или не применяя их совсем, и выдумывая собственные костыли и приляпки), то они просто убивают смысл всех ваших интерфейсов в проекте.
1👍51❤10
Какой порт использует PostgreSQL (на собесах реально спрашивают) ?
Anonymous Quiz
4%
80
1%
123
1%
139
1%
445
3%
1521
5%
3306
3%
3389
67%
5432
2%
6789
13%
8080
🤓34✍15😁12🐳3👍2
pip, grade, maven, npm-check-updates, snyk, bundler, dependabot...-- что объединяет все эти пакеты?
Один и тот же алгоритм разрешения зависимостей между артефактами (что кстати NP-полная задача).
Какой?
Один и тот же алгоритм разрешения зависимостей между артефактами (что кстати NP-полная задача).
Какой?
Anonymous Quiz
7%
алгоритм Беллмана-Форда
17%
алгоритм Дейкстры
2%
алгоритм Clique
2%
алгоритм Косарайю
3%
алгоритм Краскала
2%
алгоритм Тарьяна
14%
алгоритм топологической сортировки
6%
алгоритм Флойда-Уоршелла
48%
алгоритм "я хз"
✍53🤔13❤2
Вдогонку к опросу: один из более чем дюжины приёмов сражения с dependency hell (в СИ курсантам скоро поясню их все) -- это семантическое версионирование для управления версиями пакетов и определения совместимости между зависимыми компонентами.
Кстати, свежий тренд — обозначать версии как "год + номер", например 25.0, 25.1, 25.2... Его назвали миксом стандартного семвера и убунта-стайл.
Кстати, свежий тренд — обозначать версии как "год + номер", например 25.0, 25.1, 25.2... Его назвали миксом стандартного семвера и убунта-стайл.
✍45👍13❤🔥1
Хорошая подборочка: идеи AI-стартапов, на которые YC готов давать денежки (много) в этом году. Интересно про "вертикальные AI-агенты" -- по сути обёртки вокруг жпт, которые однако будут тщательно настроены для автоматизации какой-то реальной, важной работы.
"Трудно заставить такие системы работать правильно, но как только вы это сделаете, рост может быть феноменальным."
Обещают чуть ли не 100грустных уточек новых единорогов в этой нише.
Я отдельно повёлся на "Будущее разработки программного обеспечения": сырого контента у меня на эту темку полно, ну думаю, "сейчас наконец буду делать курс".
Ага, всё оказалось очень прозаично:
"Убьют ли агенты работу программиста? Нет! В будущем нам понадобится больше инженеров-программистов, потому что программное обеспечение будет запускать практически все.
Эти люди не будут писать много кода напрямую. Вместо этого они будут управлять командами агентов, которые создают для них программное обеспечение. Помимо написания кода, агенты будут выполнять большинство других специализированных задач, необходимых для создания программного обеспечения: контроль качества, развертывание, аудит безопасности и соответствия требованиям, переводы, операции и т. д.
Мы хотели бы финансировать стартапы, которые позволяют небольшим группам разработчиков программного обеспечения широкого профиля управлять большими командами агентов, работающих вместе над созданием и поставкой большого количества софта".
Эх, а я-то думал, что инвесторы хочут например такое будущее разработки, как компиляция кода в абстрактный формат декартово замкнутых категорий, откуда мы сможем получать машинный код вообще для любых аппаратных архитектур, от классических до квантовых... Или проектирование базового языка с зависимыми типами для быстрого создания eDSL-ей, через денотационный дизайн, с мощной системой типов, исключающей 99,999% ошибок...
Но нет.
"Трудно заставить такие системы работать правильно, но как только вы это сделаете, рост может быть феноменальным."
Обещают чуть ли не 100
Я отдельно повёлся на "Будущее разработки программного обеспечения": сырого контента у меня на эту темку полно, ну думаю, "сейчас наконец буду делать курс".
Ага, всё оказалось очень прозаично:
"Убьют ли агенты работу программиста? Нет! В будущем нам понадобится больше инженеров-программистов, потому что программное обеспечение будет запускать практически все.
Эти люди не будут писать много кода напрямую. Вместо этого они будут управлять командами агентов, которые создают для них программное обеспечение. Помимо написания кода, агенты будут выполнять большинство других специализированных задач, необходимых для создания программного обеспечения: контроль качества, развертывание, аудит безопасности и соответствия требованиям, переводы, операции и т. д.
Мы хотели бы финансировать стартапы, которые позволяют небольшим группам разработчиков программного обеспечения широкого профиля управлять большими командами агентов, работающих вместе над созданием и поставкой большого количества софта".
Эх, а я-то думал, что инвесторы хочут например такое будущее разработки, как компиляция кода в абстрактный формат декартово замкнутых категорий, откуда мы сможем получать машинный код вообще для любых аппаратных архитектур, от классических до квантовых... Или проектирование базового языка с зависимыми типами для быстрого создания eDSL-ей, через денотационный дизайн, с мощной системой типов, исключающей 99,999% ошибок...
Но нет.
2🤔53😁16👍6👌4❤3
Цена дипсика в 5,6 млн.долл. -- это хайп и фейк. Оказалось, что это "всего лишь стоимость GPU для предварительной подготовки", а фактическая общая стоимость исчисляется миллиардами, как и ожидалось.
Подробный срыв покровов тут.
...А может и правда, что к созданию современного AI имеют прямое отношение наработки советских математиков? см картинку.
Invented principles of meta-learning (1987), GANs (1990), Transformers (1991), very deep learning (1991), etc.
Подробный срыв покровов тут.
...А может и правда, что к созданию современного AI имеют прямое отношение наработки советских математиков? см картинку.
Invented principles of meta-learning (1987), GANs (1990), Transformers (1991), very deep learning (1991), etc.
1😁50🐳11✍9👍5💯1
Планировал завершить мою специальную научную операцию (гомотопическая теория типов на PHP :) ко Дню Науки...
Кстати с праздником, дорогие! 🚀
(не, я поспешил, он же завтра — в один день с Лыжнёй России :)
Вы же знаете, что финансирование всей фундаментальной математики в СССР было существенно меньше стоимости одного танка? (а как сейчас, вообще военная тайна, я её знаю, но вам не скажу :)
Но не получилось прозаически: мне не хватило ресурсов. Дешёвые модельки не тянут, а клод 3.5 или жпт о1-мини слишком дороги: при интенсивной работе где-то 10 долларов в час получается, десятки часов ушли, но жпт пока лишь вязнут в багах. Можно конечно и вручную, ну это тогда совсем долго получится.
Но с другой стороны, искусство и наука требуют жертв, и никакой окупаемости не может быть в принципе...
Король был удивлен: этому человеку казалось, по крайней мере, сто двадцать лет. Неужели он сумасшедший, или... Он не мог ожидать, чтобы эти деревья начали цвести, тем более давать плоды - зачем же ему все это было нужно? Он трудился в старости так напряженно, целый день на жаре. Это была пустынная земля.
Старик засмеялся и ответил: «Нет, я не смогу видеть цветы на этих растениях. Но видишь ли ты прямо за моей хижиной эти огромные деревья, которым тысячи лет? Это те же самые деревья. Они дают мне плоды, дают мне цветы».
Король сказал: «Я могу видеть их, но не могу понять. При чем здесь эти деревья?»
Старик ответил: «Если бы мои предки не посадили их, если бы они также думали, что не смогут видеть плодов своего труда, цветов и плодов деревьев, этих деревьев бы не было. Я не думаю о себе. Я думаю о своих предках и потомках. Я должен оставить им какое-то наследство!»
Но зато я попутно разобрался, как программно реализовывать вообще любую формальную систему, ну и в процессе столько наделал весьма сложных тестов, что теперь могу достаточно свободно "кодить" на хотт.
Самое приятное конечно в том, что HoTT как язык программирования -- ну это буквально уровень физмат школы. Обучить этому мне как нефиг делать, но... нужна полноценная реализация именно учебного модуля.
(продолжаю размышления письмом .... сегодня для этого святой день)
кстати, мем в плане темок-топчиков верен на 100% )
Кстати с праздником, дорогие! 🚀
(не, я поспешил, он же завтра — в один день с Лыжнёй России :)
Вы же знаете, что финансирование всей фундаментальной математики в СССР было существенно меньше стоимости одного танка? (а как сейчас, вообще военная тайна, я её знаю, но вам не скажу :)
Но не получилось прозаически: мне не хватило ресурсов. Дешёвые модельки не тянут, а клод 3.5 или жпт о1-мини слишком дороги: при интенсивной работе где-то 10 долларов в час получается, десятки часов ушли, но жпт пока лишь вязнут в багах. Можно конечно и вручную, ну это тогда совсем долго получится.
Но с другой стороны, искусство и наука требуют жертв, и никакой окупаемости не может быть в принципе...
Король был удивлен: этому человеку казалось, по крайней мере, сто двадцать лет. Неужели он сумасшедший, или... Он не мог ожидать, чтобы эти деревья начали цвести, тем более давать плоды - зачем же ему все это было нужно? Он трудился в старости так напряженно, целый день на жаре. Это была пустынная земля.
Старик засмеялся и ответил: «Нет, я не смогу видеть цветы на этих растениях. Но видишь ли ты прямо за моей хижиной эти огромные деревья, которым тысячи лет? Это те же самые деревья. Они дают мне плоды, дают мне цветы».
Король сказал: «Я могу видеть их, но не могу понять. При чем здесь эти деревья?»
Старик ответил: «Если бы мои предки не посадили их, если бы они также думали, что не смогут видеть плодов своего труда, цветов и плодов деревьев, этих деревьев бы не было. Я не думаю о себе. Я думаю о своих предках и потомках. Я должен оставить им какое-то наследство!»
Но зато я попутно разобрался, как программно реализовывать вообще любую формальную систему, ну и в процессе столько наделал весьма сложных тестов, что теперь могу достаточно свободно "кодить" на хотт.
Самое приятное конечно в том, что HoTT как язык программирования -- ну это буквально уровень физмат школы. Обучить этому мне как нефиг делать, но... нужна полноценная реализация именно учебного модуля.
(продолжаю размышления письмом .... сегодня для этого святой день)
кстати, мем в плане темок-топчиков верен на 100% )
50🔥44👍14❤🔥10🤔3⚡2
...В принципе можно конечно сделать вообще на Лине 4, самое смешное, что поддержка хотт была в третьей версии, но потом её оттуда выпилили, потому что поддержка унивалентности в ядре Lean оказалась пацанам не под силу 😬 Надо переопределять базовые понятия равенства, конфликты с классическими представлениями о тождестве, нарушается UIP и AC, бесконечные иерархии преобразований, запутанные проверки эквивалентности...
Вроде бы тривиально?
def idEquiv {A : Type} : A ≃ A
Да но мы-то хотим такое с унивалентностью в ядре доказательств 🫢
Классическая теория, что с лицом?
Это как попытка встроить квантовую механику в классическую физику: принципиально новый уровень абстракции.
Поэтому с одного края: то что я делал на PHP, просто закодировать непосредственно на лине как языке программирования (без каких-то плагинов для ядра), это вообще легко и просто. Но тут засада, что я ведь хочу сделать многопользовательский (веб)клиент. Хотя в лине имеется нативная поддержка concurrency, асинки...
1.1. Посмотреть, можно ли на коленке склепать рестик на лине 4.
1.2. Запилить некую минималистичную поддержку хотт.
=
Другой вариант: использовать F* -- микрософт его прям энергично развивает вовсю. И вроде бы это .NET -- но нет )
Сетевой поддержки у него нету, придётся делать обвязки на ocaml, да и сам он позиционируется прежде всего в направлении верификации кода, Lean конечно посильнее в математическом плане.
Поэтому от F* отказываемся, и следующий шаг -- это наш любимый F#. Вот тут в техническом плане сразу всё становится элементарно, но зато мы резко проседаем по системе типов (прежде всего теряем завтипчики) и уже прилично скатываемся на другой конец, ближе к пыхапы 🙈
Навскидку:
HoTT в F#: 7/10 (практически с нуля)
HoTT в Lean 4: 3/10 (почти готовая реализация)
2.1. Если по п.1.1 возникнут явные трудности, когда немного поэкспериментировать с F#.
(размышления продолжаю...)
Вроде бы тривиально?
def idEquiv {A : Type} : A ≃ A
Да но мы-то хотим такое с унивалентностью в ядре доказательств 🫢
Классическая теория, что с лицом?
Это как попытка встроить квантовую механику в классическую физику: принципиально новый уровень абстракции.
Поэтому с одного края: то что я делал на PHP, просто закодировать непосредственно на лине как языке программирования (без каких-то плагинов для ядра), это вообще легко и просто. Но тут засада, что я ведь хочу сделать многопользовательский (веб)клиент. Хотя в лине имеется нативная поддержка concurrency, асинки...
1.1. Посмотреть, можно ли на коленке склепать рестик на лине 4.
1.2. Запилить некую минималистичную поддержку хотт.
=
Другой вариант: использовать F* -- микрософт его прям энергично развивает вовсю. И вроде бы это .NET -- но нет )
Сетевой поддержки у него нету, придётся делать обвязки на ocaml, да и сам он позиционируется прежде всего в направлении верификации кода, Lean конечно посильнее в математическом плане.
Поэтому от F* отказываемся, и следующий шаг -- это наш любимый F#. Вот тут в техническом плане сразу всё становится элементарно, но зато мы резко проседаем по системе типов (прежде всего теряем завтипчики) и уже прилично скатываемся на другой конец, ближе к пыхапы 🙈
Навскидку:
HoTT в F#: 7/10 (практически с нуля)
HoTT в Lean 4: 3/10 (почти готовая реализация)
2.1. Если по п.1.1 возникнут явные трудности, когда немного поэкспериментировать с F#.
(размышления продолжаю...)
51🤔42👍11✍2❤🔥2🏆1
...Ну и наконец приближаемся ко дну и пробиваем его 😁
Последний минимальный приемлемый язык -- C#.
Теперь у нас уже нету паттерн матчинга "из коробки" и алгебраических типов данных, существенно проигрываем F# как математической нотации, но зато в девятке появились record types, source generators, а так же продвинутые дженерики:
bool IsConnected<U>(HomotopyType<U, IPath<U>> other) where U : IComparable<U>
и даже метапрограммирование:
bool IsHomotopic<T>(this T value, Func<T, bool> predicate)
3. C# хз, ну если только с F# по каким-то совсем конкретным нюансам не получится. В коре на F# эндпоинты вообще в пару строк задаются 😊
[<ApiController>]
[<Route("api/[controller]")>]
type ProofController() =
[<HttpPost>]
member _.ProcessProof([<FromBody>] req: ProofRequest) =
let response = {
Status = true
Result = sprintf "Processed: %s" req.Theorem
}
...
let app = WebApplication.Create()
app.MapGet("/dwarf", fun () -> dwarf)
app.MapPost("/dwarf", fun (dwarf: Dwarf) ->
... Results.Created("/dwarf", dwarf))
app.Run()
=
Посадка на дно начинается с "хотт на питончике" )))
Задаём термы (лямды, универсы, pi-) как датаклассы, а динамическая типизация позволяет вытворять разные штуки на уровне F#.
По большому счёту конечно всё это можно сделать интерпретацией чисто на символьном уровне, как я пытался на пыхе, но слишком уж велика трудоёмкость. В принципе, 50% MLTT (лямбда-исчисление, аппликация и зависимые типы) я упаковал где-то в 200 строк PHP-кода 👊
Но дальше, когда полезли в индуктивные типы, универсумы и особенно рекурсивные определения, без какой-то минимально адекватной типизации, с тайп инференсом в чисто символьных вычислениях начинается полный хардкор 🤘
4. MLTT++ на Python по-взрослому (термы/значения как типы данных).
Несомненный плюс питона технический: реализация получается полностью прозрачной и переносимой куда угодно, хоть в браузере запускай
(кстати, lean умеет компилироваться в wasm...).
5. Ну и в заключение пробиваем дно: пыхапы :)
Ничего не могу сказать, с него я начинал - им же и закончу?
Если получится что-то на питоне, то можно в принципе его код достаточно легко конвертнуть в php...
=
HoTT в Lean 4: 3/10 (почти готовая реализация)
HoTT в F#: 8/10 (практически с нуля, но система типов близка к математической нотации)
HoTT в C#: 9/10
HoTT в Python: 10/10
HoTT в PHP: 12/10
=
В общем, буду пробывать в таком порядке:
4. MLTT++ на Python по-взрослому
1. Lean 4 : REST + HoTT
2. F#
3. C#
4. PHP
Успех предрешён и неминуем.
Последний минимальный приемлемый язык -- C#.
Теперь у нас уже нету паттерн матчинга "из коробки" и алгебраических типов данных, существенно проигрываем F# как математической нотации, но зато в девятке появились record types, source generators, а так же продвинутые дженерики:
bool IsConnected<U>(HomotopyType<U, IPath<U>> other) where U : IComparable<U>
и даже метапрограммирование:
bool IsHomotopic<T>(this T value, Func<T, bool> predicate)
3. C# хз, ну если только с F# по каким-то совсем конкретным нюансам не получится. В коре на F# эндпоинты вообще в пару строк задаются 😊
[<ApiController>]
[<Route("api/[controller]")>]
type ProofController() =
[<HttpPost>]
member _.ProcessProof([<FromBody>] req: ProofRequest) =
let response = {
Status = true
Result = sprintf "Processed: %s" req.Theorem
}
...
let app = WebApplication.Create()
app.MapGet("/dwarf", fun () -> dwarf)
app.MapPost("/dwarf", fun (dwarf: Dwarf) ->
... Results.Created("/dwarf", dwarf))
app.Run()
=
Посадка на дно начинается с "хотт на питончике" )))
Задаём термы (лямды, универсы, pi-) как датаклассы, а динамическая типизация позволяет вытворять разные штуки на уровне F#.
По большому счёту конечно всё это можно сделать интерпретацией чисто на символьном уровне, как я пытался на пыхе, но слишком уж велика трудоёмкость. В принципе, 50% MLTT (лямбда-исчисление, аппликация и зависимые типы) я упаковал где-то в 200 строк PHP-кода 👊
Но дальше, когда полезли в индуктивные типы, универсумы и особенно рекурсивные определения, без какой-то минимально адекватной типизации, с тайп инференсом в чисто символьных вычислениях начинается полный хардкор 🤘
4. MLTT++ на Python по-взрослому (термы/значения как типы данных).
Несомненный плюс питона технический: реализация получается полностью прозрачной и переносимой куда угодно, хоть в браузере запускай
(кстати, lean умеет компилироваться в wasm...).
5. Ну и в заключение пробиваем дно: пыхапы :)
Ничего не могу сказать, с него я начинал - им же и закончу?
Если получится что-то на питоне, то можно в принципе его код достаточно легко конвертнуть в php...
=
HoTT в Lean 4: 3/10 (почти готовая реализация)
HoTT в F#: 8/10 (практически с нуля, но система типов близка к математической нотации)
HoTT в C#: 9/10
HoTT в Python: 10/10
HoTT в PHP: 12/10
=
В общем, буду пробывать в таком порядке:
4. MLTT++ на Python по-взрослому
1. Lean 4 : REST + HoTT
2. F#
3. C#
4. PHP
Успех предрешён и неминуем.
52❤38👍12🤯6👌6🫡3
Сам не ожидал, но я всё же завершил свою специальную научную операцию ровно в День Науки! 💥💥💥🚀💪🏻
Причём сознательно я вообще не верил что даже просто получится в принципе когда-нибудь, но... подсознательные калкулусы вчера работали просто идеально.
Это собственно подтверждает ту давно известную лемму, что надо от 50 часов интенсивной практики, чтобы в голове сформировалась минимально качественно работающая тематическая нейросетка (думательная машинка на быстром мышлении).
Где-то в 23:50 я успешно прогнал два заключительных базовых теста (унивалентности и "интеграционные":), и только сегодня утром осознал, что намедни уложился таки в святой день! 🤘🙏☺️
Я реализовал БАЗУ HoTT:
1. Базовые типы и зависимые типы
- Реализация Unit, Empty, Sum, Product
- Система Pi- и Sigma-типов
- Механизм зависимых функций
2. Пути и тождества (Path)
- Реализация путей как равенства
- Операции над путями (симметрия, транзитивность)
- Система доказательств для путей
3. Высшие индуктивные типы (HITs)
- Реализация Circle и Torus
- Механизм рекурсии для HITs
4. Унивалентность
- Система эквивалентностей типов
- Транспорт вдоль путей
- Преобразование путей в эквивалентности
5. Бесконечно-группоидная структура
- Реализация путей высших размерностей
- Операции композиции путей
- Механизм когерентности
6. Усечения типов
- Система n-усечений
- Пропозициональное усечение
- Усечение до множества
7. Иерархия универсумов
- Система уровней
- Кумулятивность универсумов
- Полиморфизм по уровням
8. Гомотопические группы
- Вычисление гомотопических групп
- Пространства петель
...
💝💝💝
(продолжение следует)
Причём сознательно я вообще не верил что даже просто получится в принципе когда-нибудь, но... подсознательные калкулусы вчера работали просто идеально.
Это собственно подтверждает ту давно известную лемму, что надо от 50 часов интенсивной практики, чтобы в голове сформировалась минимально качественно работающая тематическая нейросетка (думательная машинка на быстром мышлении).
Где-то в 23:50 я успешно прогнал два заключительных базовых теста (унивалентности и "интеграционные":), и только сегодня утром осознал, что намедни уложился таки в святой день! 🤘🙏☺️
Я реализовал БАЗУ HoTT:
1. Базовые типы и зависимые типы
- Реализация Unit, Empty, Sum, Product
- Система Pi- и Sigma-типов
- Механизм зависимых функций
2. Пути и тождества (Path)
- Реализация путей как равенства
- Операции над путями (симметрия, транзитивность)
- Система доказательств для путей
3. Высшие индуктивные типы (HITs)
- Реализация Circle и Torus
- Механизм рекурсии для HITs
4. Унивалентность
- Система эквивалентностей типов
- Транспорт вдоль путей
- Преобразование путей в эквивалентности
5. Бесконечно-группоидная структура
- Реализация путей высших размерностей
- Операции композиции путей
- Механизм когерентности
6. Усечения типов
- Система n-усечений
- Пропозициональное усечение
- Усечение до множества
7. Иерархия универсумов
- Система уровней
- Кумулятивность универсумов
- Полиморфизм по уровням
8. Гомотопические группы
- Вычисление гомотопических групп
- Пространства петель
...
💝💝💝
(продолжение следует)
104❤🔥64🫡13👍9🏆6🤝4
This media is not supported in your browser
VIEW IN TELEGRAM
...В мировой микро-тусовке по hott-"программированию" (считанные десятки человек) пишут что-то подобное в основном на хаскеле, ну а я сделал на питончике 🙈
Причём у них там будешь называться реально чётким пацаном, если
a) не просто такое реализуешь, а сделаешь "свой солвер"никому нафиг не нужный , и
б) обязательно добавить кубик (это вообще чисто понтовый топчик).
(пять лет назад я пояснял что это: "Кубическая теория типов для малышей") - только тогда будешь считаться cs-просветлённым 🙏
Впрочем, до этой тусовки мне нет абсолютно никакого дела. Буду продолжать эти темки исключительно на русском, и только в рунете (жаль сайт hott ру занят какой-то попсой :).
Хотя кубик будет обязательно.
так-то я больше склоняюсь к тому, чтобы сделать - по теории типов с нуля до хотт и далее - обучающую гача-игру в духе genshin impact 😬
плавно повышать свой уровень универсума, автоматически получая доступ ко всё более сложным конструкциям.
Хотя нет... В хотт 5+ уровень - это уже наверное на премию Филдса 😇
формализация (∞,1)-топосов, моделирование высших группоидов, бесконечно-категорные структуры...
А в генше вроде до сотого левела можно...
С другой стороны, каждый универсум легко бьётся минимум на десяток подуровней для изучения, и для первых двух-трёх универсумов темппрохождения изучения получается примерно как в GI 💎
(продолжение следует)
Причём у них там будешь называться реально чётким пацаном, если
a) не просто такое реализуешь, а сделаешь "свой солвер"
б) обязательно добавить кубик (это вообще чисто понтовый топчик).
(пять лет назад я пояснял что это: "Кубическая теория типов для малышей") - только тогда будешь считаться cs-просветлённым 🙏
Впрочем, до этой тусовки мне нет абсолютно никакого дела. Буду продолжать эти темки исключительно на русском, и только в рунете (жаль сайт hott ру занят какой-то попсой :).
Хотя кубик будет обязательно.
так-то я больше склоняюсь к тому, чтобы сделать - по теории типов с нуля до хотт и далее - обучающую гача-игру в духе genshin impact 😬
плавно повышать свой уровень универсума, автоматически получая доступ ко всё более сложным конструкциям.
Хотя нет... В хотт 5+ уровень - это уже наверное на премию Филдса 😇
формализация (∞,1)-топосов, моделирование высших группоидов, бесконечно-категорные структуры...
А в генше вроде до сотого левела можно...
С другой стороны, каждый универсум легко бьётся минимум на десяток подуровней для изучения, и для первых двух-трёх универсумов темп
(продолжение следует)
1❤37🔥19🫡10👍7🤯1
Ожидание:
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 )))
Потому что у меня всё же цель не продакшен, а обучение этому всему.
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 )))
Потому что у меня всё же цель не продакшен, а обучение этому всему.
1❤🔥26🤔22✍7👍7❤1
Продолжаю работу с курсантами 😎
--- GameLogic здесь будут храниться игровые правила и логика управялет тем, КАКИЕ действия будут выполнены
Правильный коммент кстати, как раз сегодня на эту тему я сделал пост.
--- Если после перехода с MySQL на PostgreSQL вся логика хранения пользователей не изменилась — значит, "модель пользователя" была правильной абстракцией, а "таблица в БД" — нет.
---Скрипты, правда, запускаются ощутимо медленнее. Поскольку меня такое раздражает, маловероятно, что буду этим пользоваться.
---Первая серьёзная проблема, с которой столкнулся - установка библиотеки.
---Не начал вовремя, так как отвлекся на заказ секундомера
---Я реализовал СЛИШКОМ много ненужных методов
---поскольку Django Rest Framework в сериалайзерах игнорирует коды при вызове стандартного исключения ValidationError, подставляя всегда 400 статус, то, чтобы не вызывать каждый раз APIException проще сделать собственное исключение
---работаю в рамках одного каталога, хотя нужные мне файлы могут находится и в подкаталогах.
-- Сейчас восстановление возможно только вручную, но планируется автоматизация.
---справедливо будет сказать, что я забыл эти методы исключить после изучения эталонного решения для предыдущего задания
/bdd ...Релизим проект, работаем 24/7, как всегда подвела оценка задачи. Оценивали по форме без анализа внутреннего содержания. Надеюсь когда-нибудь научимся, а пока испытываем боль.
Первый шаг для решения этой классической проблемы -- пройти мой курс по BDD.
--- GameLogic здесь будут храниться игровые правила и логика управялет тем, КАКИЕ действия будут выполнены
Правильный коммент кстати, как раз сегодня на эту тему я сделал пост.
--- Если после перехода с MySQL на PostgreSQL вся логика хранения пользователей не изменилась — значит, "модель пользователя" была правильной абстракцией, а "таблица в БД" — нет.
---Скрипты, правда, запускаются ощутимо медленнее. Поскольку меня такое раздражает, маловероятно, что буду этим пользоваться.
---Первая серьёзная проблема, с которой столкнулся - установка библиотеки.
---Не начал вовремя, так как отвлекся на заказ секундомера
---Я реализовал СЛИШКОМ много ненужных методов
---поскольку Django Rest Framework в сериалайзерах игнорирует коды при вызове стандартного исключения ValidationError, подставляя всегда 400 статус, то, чтобы не вызывать каждый раз APIException проще сделать собственное исключение
---работаю в рамках одного каталога, хотя нужные мне файлы могут находится и в подкаталогах.
-- Сейчас восстановление возможно только вручную, но планируется автоматизация.
---справедливо будет сказать, что я забыл эти методы исключить после изучения эталонного решения для предыдущего задания
/bdd ...Релизим проект, работаем 24/7, как всегда подвела оценка задачи. Оценивали по форме без анализа внутреннего содержания. Надеюсь когда-нибудь научимся, а пока испытываем боль.
Первый шаг для решения этой классической проблемы -- пройти мой курс по BDD.
✍35🫡9👍5❤3🤔2
Выложил на бусти первый сериал из 14 материалов СильныхИдей
(уровень понимания крепкий джуниор, но наверняка этим темам вас никто не учил даже в универе :)
Так они доступны только моим курсантам, но тут расширенные версии, дополненные множеством примеров (преимущественно на Java).
Рассматриваем начальную БАЗУ программной инженерии
(правильная форма рассуждений и основы programming in small)
для джуниоров и всех интересующихся:
- три уровня мышления о программе,
- основные принципы снижения сложности кода и повышение его выразительности и понимаемости,
- инженерные подходы к отладке и тестированию.
Формат - html-гайд, в архиве 74 файла, 500 тыс. знаков чистого текста (объём средней книги).
Цена пока 1,999 рублей, через несколько дней повышу.
Бедолагам разрешаю брать "вскладчину" или подождать когда "на торренты сольётся" :)
(уровень понимания крепкий джуниор, но наверняка этим темам вас никто не учил даже в универе :)
Так они доступны только моим курсантам, но тут расширенные версии, дополненные множеством примеров (преимущественно на Java).
Рассматриваем начальную БАЗУ программной инженерии
(правильная форма рассуждений и основы programming in small)
для джуниоров и всех интересующихся:
- три уровня мышления о программе,
- основные принципы снижения сложности кода и повышение его выразительности и понимаемости,
- инженерные подходы к отладке и тестированию.
Формат - html-гайд, в архиве 74 файла, 500 тыс. знаков чистого текста (объём средней книги).
Цена пока 1,999 рублей, через несколько дней повышу.
Бедолагам разрешаю брать "вскладчину" или подождать когда "на торренты сольётся" :)
😁43❤15🫡9👍2✍1
= Краткое содержание первого сезона =
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 рублей, через несколько дней повышу.
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 рублей, через несколько дней повышу.
👍45❤8🤔6⚡4✍1
Смотрю, эта вакансия стала мемом, у кого только уже её не видал. Но совершенно никакого возмущения по её поводу не понимаю, хотя недоволен конечно, что тёмный эгрегор эйчаров + хх + хабров + прочих вредителей, безвозвратно сломали русский рынок найма более чем полностью.
Мои курсанты перед тем, как я им порекомендую начинать искать работу и помогать по карьере, сперва должны сделать "дипломный" проект, около 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!
Мои курсанты перед тем, как я им порекомендую начинать искать работу и помогать по карьере, сперва должны сделать "дипломный" проект, около 40 заданий. В нём примерно в сравнении с картинкой раз в 10 больше технических темок, которые надо изучить хотя бы с минимальной практикой и продемонстрировать гитхабом, прежде чем рыпаться на поиски juniorской работы.
Тут по большому счёту просто какие-то разрозненные и по смыслу особо не связанные кусочки базы. Основной вопросик, насколько глубоко надо знать каждую из этих тем, а так конечно сегодня это всё фактически must have.
- Докер? Смотрим часовой видосик, и затем пару
- 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!
4❤44👍15✍4💯1🫡1