Ваша мотивация — полностью ваша проблема 😎

Немного из отчётов ребят:

Но я все больше начинаю понимать,что меня интересует software design в программировании и как вы говорите «эти ваши веб фреймворки» да и в целом “programming in small” не так интересно. Может быть,это конечно неправильно, не знаю)) Но меня как то прям «прёт» от того,когда получается,пока естественно по кривому,не идеально,но все же разбить какую-бы то ни было программу на более менее независимые классы,спроектировав их общение мало мальски с интерфейсами.

Мы тут делали на distributed systems клиент и сервер по обмену сообщениями на сокетах на С++ и я вот прям день сидел и потел над дизайном,какие «абстракции» добавить. Пусть даже и пока не такие,чтобы вау,но так не хотелось как весь класс писать 300 строчек в мейн…

Как оказалось,после такого дневного обдумывания с UML и sequence diagram код писался намного легче. Всё таки,как вы и писали в одном из последних постов - навык по software design будет очень востребован со всеми LLM. Потому что в целом после уверенного понимания архитектуры и как что с чем общается, написать код - рутина. ...и пришлось что то менять,когда код писал,но уже лучше чем менять его после каждого «прозрения»,что надо было сделать по другому…

Даже сейчас читая про ASP NET мне как то больше интересно про его архитектуру,а не за какие API его дергать,чтобы достать сервис из DI контейнера...

И спасибо вам за ваши мотивационные посты в тг,у меня хоть потихоньку как то глаза открываются на карьеру и путь в IT. В FAANG уже не хочется,хочется как тот парень на 3ех проектах)) Ну и уже нет установки просто «поднять скилы» с вами - хочется научиться и зарабатывать деньги. Хорошие…

В общем изменения в себе я вижу с момента того,как к вам присоединился,а это самое главное! Так как до вас я 1,5 года какой то ерундой занимался,прогресса как то не было. Так что ваши посты работают!!! Они такое медленное действие оказывают,сея зерно сомнений в своих установках,которые чаще всего как то криво пока сформированы…

Компетентность проявляется в глубине знаний, а не в их широте.

Бесчисленное множество программистов могут писать говнокод на Java, но на порядки меньше понимают и учитывают достаточно сложные детали, такие как JVM, сборка мусора, сериализация, многопоточность... И ещё на порядок меньше тех, кто может свободно писать на Java в функциональном стиле.

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

Для начала, будь то популярный язык программирования, REST-фреймворк или оптимизация SQL запросов в PostrgeSQL, станьте специалистом по чему-либо одному. Со временем это существенно изменит вашу карьеру!

P.S.1. Между прочим, если у вас один сервер и нету потока ежесекундных запросов, зачем вам постгресс? Используйте шуструю и компактную sqlite 🚀

P.S.2. Ну ладно, или бессерверный Postgres :)

Я решил, что функциональное программирование -- это поверхностная мода, и собираюсь вернуться к вечным математическим принципам императивного и объектно-ориентированного программирования.

Java/C#/C++ программистам очень полезно периодически кодить на Python, чтобы никогда не забывать, какая это боль, если не используешь хорошую static type system.

А чего так на "Смуту" набросились? Рассматривают под микроскопом, придираются к каждой детали.

"Текстурки разъехались... Сценка не проработана... Графика на максималках всё равно не топ..."

Ну игра и игра. Мне не нравится только, что бегать надо многовато по локациям (наверное, коня дадут?), а так норм.

Не знаю, это анрил наверное просит установить Visual C++ 2015 Redistributable? :)

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

Завтра выложу в вк пост, почему будущее -- за монолитами :)

В частности, потому, что микросервисы -- это вот нечто подобное ↑

Выложил на курс карьеры 82-й материал "Стоит ли работать в МОСЯ/FAANG?".

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

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

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

Прекрасное от создателя кложа, очень рекомендую =>
"Hammock Driven Development"

Как говорил Алан Кэй,

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP."

Как они так мыслят? Точнее, как они доходят до такого мышления? изучаю, разбираюсь в этом постоянно, понемногу взламываю и моделирую ) мой формат hard work в помощь.

Это ведь не просто фраза, сгенерированная нейросеткой мозга, а мета-скилл, умение создавать в такой парадигме качественные проекты на миллионы строк кода.

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

Чем больше у вас в проекте полиморфизма (который не надо путать с генериками), тем больше у вас будет glue code (это тёмная материя программного обеспечения, которая в значительной степени невидима, и мы знаем о ней очень мало :).

Вообще, сила системы типов абсолютна: порядок всегда бьёт класс.

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

Итак, идите и пишите правильный код, и да пребудет с вами Сила Куба Барендрехта! :)

P.S. Лет шесть назад кстати я писал об этом, вот думаю, не вернуться ли к тем планам? Все остальные курсы для Школы, которые хотел, уже сделаны.

...Вы сможете предлагать уникальный сервис, где вообще нету конкурентов -- разработку мощных языков программирования (верифицированных!) под конкретные ниши ML, с доказательством корректности кода. ...Совсем прозаическое -- что-то хотя бы на уровне System F для 1C :)
...Вы встанете вровень с Джеймсом Гослингом и Ван Россумом, Аланом Кэем и Андерсом Хейлсбергом, Юкихиро Мацумото и Грейдоном Хоаром. Это проект саморазвития даже не на одну жизнь, а на многие жизни вперёд.
...Ну и в любом случае, вы научитесь мыслить в программировании так, как никто больше практически, ну может несколько сотен человек во всём мире. Это объективно самый программистский топ.

"В правоохранительных органах ТАСС сообщили, что сбой в базах ГИБДД произошел по стране в связи с переходом на новое программное обеспечение..."

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

Азы программной инженерии? PMBoK? SMBoK?
Хотя бы CI/CD на студенческом уровне?
Нет, не слышали.

Я не зря сделал это девизом Школы :)
"Why the fuck do we let people that have no computer science backgrounds write code? Unacceptable!"

В США нельзя получить достаточно серьёзный гос- или оборонный ИТ-заказ, если подрядчик не сертифицирован хотя бы по 3-му (из 5) уровню модели зрелости программных процессов CMM Карнеги-Меллона, много об этом писал.

В конце 90-х одна московская контора (сотни программистов работали по оффшорным подрядам) прошла эту сертификацию на 4 (из Америки к ним приезжал CMM-гуру), я тогда большой материал об этом писал. Ну и ISO 9001 где-то рядом. Они действительно серьёзно работали над рабочими процессами, покупали например аналитические отчёты Cutter -- 2-3 странички стоили 300-400 долларов, мне их босс по дружески сканировал, и я потом классные статьи писал по эксклюзивной инфе 😎

=

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

Эта мания с тёмным режимом в вашей IDE и ваших редакторах должна наконец прекратиться! :)

Скажу больше, это выглядит просто ужасно, так что я склонен быть классиком и минималистом в этой теме. Когда вы в последний раз писали что-то на чёрной бумаге? Вы просто не делали этого никогда, так что я предпочитаю светлый режим с очень минимальной подсветкой синтаксиса. Это в основном чёрный текст на белом фоне, малиновый для ключевых слов, серый для комментариев, и тёмно-синий для значений, вот и всё, что вам нужно. И если вы попробуете так хотя бы 1-2 недели, вы наверняка скажете, что вашим глазам стало лучше, и это действительно приятно.

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

Я давно ещё писал, почему подсветка синтаксиса -- вообще зло.

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

Лучшие книги и курсы для программистов -- это не те, которые вы читаете/проходите в начале своей карьеры. Это те, которые вы начинаете ценить лет через пять.

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

Однако потребуется время, чтобы понять и оценить более глубокие идеи. Вам нужно сперва как следует поработать над реальными проектами-вызовами. И вам нужно продержаться в них достаточно долго для того, чтобы почувствовать последствия своих действий и понять и оценить, насколько важны фундаментальные академические знания computer science.

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

Как правильно? Объяснять фундаментальные принципы, универсальные базовые строительные блоки, и позволить вам самостоятельно разбираться в деталях.

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

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

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

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

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

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

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

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

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

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

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

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

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