Если честно, я тоже сейчас реально/серьёзно думаю в этом направлении...
Может быть даже, сделаю что-то типа реалити-шоу.

Как ни крути, но сейчас мой доход на 90% зависит от моей загруженности. Обучение, консультации, и всё фактически в почасовом режиме. А если месяц сделаю паузу, то и заработаю ноль. Мне это всё невероятно нравится но...

Буду следовать своим же рекомендациям по созданию микро-стартапов: к 1 декабря сделаю (или не сделаю:) рабочий прототип игры для программистов.

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

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

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

Хотя конечно нередко бывает и такое: "Leaving Rust gamedev after 3 years"

"На момент написания этой статьи я программирую уже около 20 лет, начав с C++ и перейдя через всевозможные языки, PHP, Java, Ruby, JavaScript, Haskell, Python, Go, C#, и выпустив игру в Steam на Unity , Unreal Engine 4 и Godot."

Наверное, самый знаменитый фейл на сегодня -- Concord. Точнее, фейл для заказчика, программисты как раз очень успешны ))) Пацаны из Firewalk за 8 лет освоили 200 млн. долл. на создание "геройского шутера", а как он вышел этим летом, купили всего 25 тыс. копий (стим + плейстейшен), в онлайне редко когда несколько сотен игроков сидели. Ну её и прикрыли через две недели.

То есть, идя в геймдев за деньгами, продуктивнее всего иметь богатенького покровителя (например, государство), которому можно годами вешать лапшу.

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

btw Когда теперь в следующий раз буду снова набирать учеников не знаю наверное ближе к весне (а может быть и никогда).

Документация -- это глупость. В ней точно указано, что нужно делать.

Развитие AI будет идти экспоненциально, говорили они. Действительно, ллм-ки сперва показали неплохой рост в плане кодинга. Но если посмотреть на результаты текущего года, то этот рост даже не то что линейный, он уже логарифмический. AI превращается просто в умный поисковик/автозаполнитель с очень медленным дальнейшим развитием. Типа автоматизация расширенного поиска по SO и гитхабу.

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

Происходит это не непосредственно на уровне кода, а именно на уровне логики проекта -- когда надо всё же понимать взаимосвязи между множеством частей, понимать смыслы. Это чистый software design, но этому вообще практически нигде не учат, и на гитхабе ничего подобного ни фига не найти.

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

/update третью скалу устанавливал вчера 4 часа.

"I am raising $100M at $2B pre money valuation for a startup that will get people together to sit down and talk to each other in person."
Bojan Tunguz (Machine Learning ex Nvidia. Kaggle Quadruple Grandmaster.)

98% сеньоров-питонистов срезаются на этом вопросе на собесе!!1

В чём разница между [0]*3 и [0,0,0] ?

/rtfm разница между мутабельными и иммутабельными объектами

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

Вот сермяга (отсюда):
"Из тысячи доступных архитектурных практик ты, скорее всего, используешь три: микросервисы, REST и вечные попытки убедить команду обновить версии библиотек."

/defer swift всё? как его в эппле убивают в погоне за прибылью.

Первое правило геймдева: как можно быстрее сделать самый первый уровень.

Иначе вы быстро запутаетесь в куче технических нюансов и потеряете мотивацию.

Разбираю структуру игры "7 billion humans" (рассказывал тут , насколько она полезна для программистов). И нашёл в ней баг (или фичу , которая всё же на 51% баг).

Первое задание - надо сделать простую программу из трёх команд.
И тут сразу появляется нетривиальное: как отследить успешное прохождение уровня? Просто проверять конечную позицию тупо на совпадение с шаблоном неверно по многим причинам, и "7 billion" такого конечно не допускает. Однако , похоже , игра прозаически смотрит длину программы. Вот пример , когда я сделал достаточно длинную программу , которая приводит к нужному результату - но долгим путём. И "7 billion" её уже не засчитывает!
Или даже , не исключено , выполняется просто сравнение "кода" решения с эталонным.

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

/dev мощно обновились mini apps 2.0 для тележки.

Из свежих отчётов курсантов (с формата hard work)

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

...Изучил материал, грустно конечно. В смысле, материал великолепен, просто грустно что никто это не изучает и не понимает. С другой стороны откуда им это вообще изучать, если в РУ Сегменте вы один, а в EU... Ну это надо быть явно заинтересованным чтобы святых (computer science) читать.
(это по заданию "создать функциональный интерфейс с помощью F-ограниченного полиморфизма":)

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

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

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

...Это занятие заставила меня хорошо подумать и переосмыслить свои подходы в разработке. Кажется, в свой список подходов и методологии разработки - aka советы, я добавлю несколько подходов из материала. Одно из занятий, что сильно поменяли мою картину мира разработки. Хочу, чтобы дальнешие занятия были увлекальнее и полезнее. Подобные материалы я искал бессонными ночами, наконец я их нашел. Все рядышком друг к другу.

/win в js появился новый оператор безопасного присваивания
?=
срочно забираем. (впн)

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

5% адекватных просто говорят: "X лучше потому, что Y". Это реальный аргумент, с которым можно работать и, соответственно, найти лучшее решение для данного проекта.

В частности, правила SOLID (или методики ОО-проектирования, и т.д. и т.п.) безусловно хороши, однако строгое следование им редко приводит к хорошему коду. Потому что на практике вы разбираетесь прежде всего с тем, как что-то делать с учётом соответствующих рекомендаций, на что уходит 80% возни. И лишь 20% вашего времени уходит на то, что именно вы хотите с их помощью делать. В результате ваше понимание только усложняется , а не упрощается.

Мастерство -- это когда данная пропорция становится 20/80.

/eureka Такую физику мы одобряем: расчёт траекторий движения котиков.

Из отчёта курсанта:

Почти 2 недели не возвращатся к проекту по ETL процессам, т.к. были срочные рабочие задачи. Всегда сложно после перерыва вникать обратно в проект, даже если бОльшую его часть написал ты сам. Это больше моя психологическая проблема. Решение наверное уделять проекту постоянно хотя бы 15 минут в день, чтобы контекст не пропадал.

Да, у многих так; вы придерживаетесь рекомендаций по скоростному ведению заметок с трека "Элитный программист"? Я там третий материал добавил недавно в подборку "Технологии поддержки мгновенной перефокусировки".

Ну и документировать проект конечно очень желательно , на третьем логическом уровне, где что зачем. За 15 минут , просто что-то ковыряя в коде , вы скорее всего ещё больше запутаетесь. Лучше за эти 15 минут пишите документацию и комментарии (мышление письмом).

Обновлённый список наших блогеров.

В этом месяце безусловные победители: Новиков и Доронин! 💥🤘🚀

Конечно, 80% со временем сливаются, ну штош...

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

Такое мы забираем:
Marten (.NET Transactional Document DB and Event Store on PostgreSQL)
Use proven PostgreSQL database engine, its fantastic JSON support and ACID compliance as the underlying data store.

Пост ВКонтакте:
Почему подходы мейнстрима, где кодовые базы — сплошные big balls of mud, почему весь этот "детский сад штаны на лямках", так популярны, и какую алгебру (с учётом тотального детского сада) вам надо изучать прежде всего.

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

...В одном нагрузочном (как предполагается:) проекте посоветовал пацанам выбрать эрланг 🙈

Почему Erlang? Ну потому что с учётом всех его технических плюсов, оказывается также очень удобно интегрировать семантику бизнес-процессов и его семантику. Почему удобно? :) Потому что он прозрачно маппится в алгебру процессов (π--calculus), но это уже совсем другая темка...

/rtfm Обычно люди, которые покупают книги по программированию, никогда их не читают. Между прочим, /rtfm читается также, как read the fine manual

В честь дня математики написал пост в вк.

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

Я не забросил кстати игру для обучения программированию (которую обещал к 1 декабря :). На самом деле 80% времени ушло на UI. Я перебрал с десяток самых разных 2D-движков - ни одного и близко нету , чтобы отвечал моим достаточно простым требованиям. Поэтому как обычно пришлось всё делать самому :) графика , анимация, переопределение кучи стандартных контролов UI...
Возможно к 1 января сделаю какой-то альфа-прототип с начальными уровнями, если снова не возникнет засад с UI (не забывая, что всем абсолютно пофиг:) .

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

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

После чего достаточно естественно мы приходим к языкам наподобие Erlang, где модель акторов прекрасно формализуется с помощью activity semigroups (фундаментальная часть математической семантики эрланга), ну и т.д.
Загадывать ничего не буду конечно, ведь надо ещё и что-то кушать...

=

"Не учишь матан -- превратишься в метан." (с)
(матан на самом деле наименее востребован в cs, а что надо - в закрепе основного паблика)

В продолжение вчерашнего ↑↑↑
Чем раньше начинающий начнёт въезжать в эти темки, тем лучше, потому что если человек, претендуя на звание Программиста, по жизни потенциально годится лишь клепать CRUD и рисовать формочки мышкой, то его надо поскорее отправить в биореактор на курсы "как быстро войти в ит с гарантией трудоустройства".

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

"Ну и что полезненького мне даст вся эта ваша математика??"

Например, вот как писать код по-взрослому:
Dependently-typed HTTP headers in Idris
(моделирование HTTP-заголовков строго по RFC )

Дана сермяга с достаточно подробным разбором: завтипы, correctness by construction, making illegal state unpresentable etc.

Для повседневных задач получается конечно накладно, но такой (абсолютный) уровень качества обычно и не требуется. А вот для критически важных систем критически важно.

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

Вдогонку-2. На самом деле практически в любом функциональном языке вы можете легко и просто реализовать парадигму MISU (marking illegal states unrepresentable)! Потому что по большому счёту ФП именно MISU и подразумевает автоматически.

Вам остаётся лишь make representable states valid. Для этого вам прежде всего понадобятся sum types: если вы с их помощью определите набор допустимых состояний, то все эти состояния должны быть корректными и иметь определённую семантику. Другими словами, если ваш тип описывает все возможные состояния, то каждое из этих состояний должно иметь осмысленное значение в контексте вашей программы. Нельзя оставлять "дырки" в определении типа (когда некоторые состояния не имеют смысла).

Далее вам надо задействовать exhaustive pattern matching, чтобы не забывать обрабатывать все возможные состояния в функциях, использующих соответствующий тип. Если вы упустите какое-либо валидное состояние, компилятор выдаст ошибку.

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

AI изобрёл ветряк, который в 7 раз эффективнее традиционной версии, настраивается на турбулентность окружающих зданий, эффективно работает при скорости ветра 3,6 м/с (номинал большинства турбин -- 10 м/с) и т.п.
(отсюда)

Белковый инженер до таких конструкций (справа вверху) скорее всего не додумался бы в принципе :)

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

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

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