Хотели как лучше ("технологический суверенитет"), а получилось как всегда ("цифровой концлагерь").

"Вот вводят программу «Мой спорт». Слышали о такой? Детям даются куар-коды, а мы, тренеры, должны их считывать, когда они приходят на тренировку. После — выставлять оценки. Нам объясняют, что пора уже проводить цифровизацию и здесь. Ребята, у нас нет площадок, условий, инвентаря, а мы вкладываемся в цифровизацию! У нас скоро детей не останется в спорте. Вот для этой платформы нужны персональные данные как детей, так и родителей. Что сильно настораживает последних. Кто все-таки приходит — то телефоны забывает, то они разряжаются, у кого-то кнопочные. И вот вместо тренировок мы этой отчетностью занимаемся."
Спорт-Экспресс

Ну как там обстановка, с грядущей цифровизацией "Москвичей" и "Волг"? ))) Для начала предлагаю впендюрить голосовое управление стеклоподъёмником на ардуинке или малинке! Моделька, обученная 2-3 голосовым командам, вполне на них заработает.

В топовых моделях массовых иномарок на борту суммарно работает более 100 млн. строк кода (для сравнения, в Windows + Офис единичные десятки миллионов строк), и до уровня даже в сто раз меньше потребуются многие годы работы больших коллективов разработчиков. И как эти вложения окупать?

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

Мишустину: в срок до 01.09.22 организовать межведомственный центр компетенции по цифровизации автомобильного транспорта.
В нём надо объединить экспертов из действующих структур, занимающихся этой темой (КАМАЗ, яндексовские беспилотники, различные компании, занимающиеся GPS-трекингом, и т. п.)

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

Об исполнении доложить в СМИ.

100% признак плохого тимлида/ИТ-менеджера/CTO описан в книге Фила Найта "Продавец обуви. Как я создал Nike". Как Фил, едва закончив какие-то местные инфоцыганские бизнес-курсы, занял у папаши 50 долларов (!), и в итоге организовал на них многомиллиардную корпорацию.

Так вот, немного перефразирую его подход: допустим, вы CEO и нанимаете CTO. К вам приходит множество замечательных специалистов, с солидным опытом работы в ВОТВАСЯ, и каждому вы задаёте один и тот же простой вопрос: "Как вы обучаете своих сотрудников?".

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

CTO/тимлид не должен напрямую заниматься архитекторством или оперативкой; он должен прежде всего обучать других.

Очень хороший доклад по теме проектирования API в играх
который подробно разбираю и дополняю на неигровых примерах в СильныхИдеях. Одна из лучших цитат из этого доклада:

"Когда вы оцениваете некоторый готовый API для своих нужд, вы обычно полагаете, что лучшее, что тут можно сделать -- это прочитать документацию по технологии, которую вы потенциально оцениваете. Не делайте этого! Представьте, что у вас есть идеальный инструмент, который вам нужен. Представьте, что вы интегрируете его в игру, которая у вас уже есть, в течение не более 1-2 дней, посмотрите, что у вас получилось, и вот теперь подумайте: "Насколько близко этот API соответствует тому, что я собираюсь сделать в идеальном варианте?". Не думайте в терминах внешнего API! Сначала думайте в своих терминах, в "онтологии своего домена", а затем, когда оцениваете разные внешние API, определите, например: "Что из этого хорошо подходит для моих нужд?"."

Интересно, какой будет процент слива с такого?

Государство компенсирует ученикам 100% стоимости ИТ-обучения. Для участия школьникам нужно только подать заявку на понравившейся курс и описать свою мотивацию. Обучение будет длиться два года, программы рассчитаны на четыре модуля по 36 академических часов.

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

Получится ровно в духе того мема, когда подрядился на проект, и уже через несколько минут задумчиво смотришь вдаль: зачем??

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

P. S. Ok, сейчас конечно большая мода на "войти в айти", поэтому наверное кто-то будет успешно доучиваться. Хотя ребята кто этим реально интересуются пусть лучше всё же в университеты идут, а подобные курсы их только собьют с пути истинного. Кроме того, такая стрельба по площадям всегда была и будет крайне неэффективной, когда буквально провоцируется безответственность подобным: "нужно только подать заявку на понравившейся курс".
"Понравившийся", Карл! Для тех, кому "интересненького" захотелось под влиянием мимолетней эмоции, а что это будет прежде всего огромный труд, почему-то ни слова.

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

"Хотели как лучше получилось как всегда" выходит на мета-уровень (тыц тыц): даже "цифровой концлагерь" не могут без детсадовских багов запилить.

В технической поддержке "Госуслуг" говорят, что возникла техническая ошибка:
- Уже работаем над устранением этой проблемы.
Но – пока система не готова. И тут пошло поехало. Главный тренер клуба ФНЛ Вадим Евсеев не может сделать Fan ID, чтобы попасть к себе на работу.

Да что вы говорите, Майор Ясен Пень, "возникла техническая ошибка"; странно только, что на американских хакеров и рептилоидов свою безалаберность не свалили.

Тестирование, CI/CD? Нет, не слышали.

детский сад штаны на лямках

P. S. Напоминаю, что, работая над подобными проектами, станете пожизненно нерукопожатыми в ИТ.

По следам наших недавних выступлений :)

Мэр Москвы Сергей Собянин и генеральный директор ПАО "КАМАЗ" Сергей Когогин подписали соглашение о сотрудничестве в рамках программы по развитию легкового транспорта и производству российских электрических автомобилей... Планируется создать ряд производств ключевых автокомпонентов: электрических двигателей, аккумуляторов, систем управления и безопасности и многого другого...

"Акцент мы делаем на электрический автомобиль"
(с) Максим Ликсутов

=

Ok, следующее распоряжение будет по поводу вот этого безобразия:

"Минцифры с IT-компаниями обсуждает перспективы разработки отечественного игрового движка с помощью госфинансирования"

Типа, "акцент мы делаем на доморощенный движок".

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

Проблема, как уже говорил, совсем не в движке. В играх решает не технология, решает прежде всего качественный контент. Поэтому, рекомендую Минцифры (пока по хорошему :) никаких денег ни в коем случае на эту задачу с третичным приоритетом не давать (Мишустину: проследить, чтобы не разбазарили — планируют ведь миллиарды рублей в эту фигню вложить). Пацаны обойдутся прекрасно пока и без такого "сермяжного движка": вон, разработчики "экшен-RPG Смута" на днях получили от государства 260 млн. рублей на её создание, а общий бюджет оценивается в полмиллиарда; пилят же его на Unity (кстати, они никуда не сбежали, не верьте фейкам; трудятся).

Подумать Минцифры тут надо в направлении поддержки российских разработчиков по продажам игр за валюту (и не только за доллары/евро, но и в Индию, Южную Азию...); очевидно, что в сложившейся ситуации нам нужно в срочном порядке это всё организовать. Тупейшие игры вроде Project Makeover (да, жанр match-3 вечен:) ежемесячно по 10 миллионов долларов зарабатывают например. А создать игру такого уровня в тысячу раз дешевле Смуты и в десятки тысяч раз дешевле "отечественного движка". Ну как бы приоритеты в инвестировании очевидны любому диванному эксперту, разве нет?

Шадаеву — подготовить действующий механизм скорейшей реализации поддержки разработчиков по платформе зарубежных продаж до 19.08.22.

Похоже, что ЛеКун (VP & Chief AI Scientist в FAIR) реально становится тем единственным человеком (или всё же он засланец из космоса?), который с помощью своего интеллекта поставит окончательную точку в нашей цивилизации :) Пока основной причиной, почему не получалось создать "AI, который захватит мир", считалось бабло. Не хватало его прозаически для масштабных прорывных исследований. И вот наконец ЛеКуну дали таки мультимиллиардные бюджеты: вписали FAIR в подразделение Метавселенных, куда ресурсов под модную темку выделено просто немеряно.

На радостях гуру опубликовал мощный материал
"A Path Towards Autonomous Machine Intelligence Version 0.9.2, 2022-06-27"

Дескать, сопротивление бесполезно.

Увы, но в данном случае действительно ничего серьёзного, что можно было бы FAIR противопоставить, нигде в мире больше и близко не видно.

В своей знаменитой книге "Как стать хакером" Эрик Рэйнмонд (один из основателей Open Source Initiative) заявил: "ни одна проблема не должна решаться дважды". Обычно мы следуем этому принципу, создавая библиотеки, выдумывая искусственные приляпки вроде принципа DRY, и т. п. То есть, имея два схожих компонента и достаточно денег, почти всегда можно сделать систему "лучше", представив их одним "многократно используемым" компонентом с настройками.

Однако чтобы лозунг Раймонда стал буквальной правдой, единственный путь вперед тут только такой: автоматическая генерация программ (Program Synthesis) + AI.

Да, Copilot пока выглядит ужасающе :) Но, это ведь только начало.

"Изучите это письмо внимательно" (с)

Вообще, это рекурсивный процесс )))

"Google" programmers. How one idiot hired a couple more idiots.

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

Простой пример, что даже в SQL делаются явные ошибочные различия между базовыми таблицами и представлениями на уровне синтаксиса: CREATE TABLE и CREATE VIEW. Естественно, что человек, не обученный теоретически мыслить в реляционной вычислительной модели, и дальше начинает их "различать" в своей практике, хотя по сути это одно и то же.

По мелочи, в CREATE VIEW сразу указывать список столбцов плохой стиль, не надо так: всегда делайте AS.
И WITH CHECK OPTION для апдейтов добавлять полезно.

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

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

По следам наших выступлений :)

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

Ну, да, процент по ипотеке ещё снизили, проще стало попасть в ИТ-реестр (но халявщиков вроде банков и маркетплейсов наоборот собираются исключить, и поделом) и т. п.

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

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

Сейчас ключевая проблема, что в цепочке "обучение - работа" имеется огромный разрыв интеграции.

Даже явно способным джуниорам с хорошей подготовкой сегодня весьма трудно найти первую работу. Процесс может затягиваться на многие месяцы.

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

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

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

По мере погружения в computer science и ФП я одно время горячо верил в активное повторное использование небольших функций. Очевидно, полная глупость, когда огромное количество самых разных приложений в моём компьютере имеют каждый свою собственную проверку орфографии и систему логина; и сколько мозгов было потрачено на создание практически идентичной функциональности? Однако со временем я всё чаще наблюдал, как команды с энтузиазмом подключали готовые компоненты, но затем быстро задумывались об их замене, как только понимали, что могут получить на 10% меньший размер программы, создав собственную версию с меньшим количеством функций.

Потом я однажды прочитал знаменитое эссе Дуга Макилроя (легендарный американский математик и программист, автор пайпланов в Unix и многих утилит, принимавший участие в проектировании PL/I, Снобол, C++...) "Компоненты программного обеспечения массового производства" ("Mass-Produced Software Components", "a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968") в котором вместо универсальных библиотек предлагались "семейства библиотек", "генерирующие" варианты библиотек, подходящие для конкретного приложения.

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

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

В СильныхИдеях выложил по этой теме материал
"4 универсальных принципа проектирования API".

По следам наших выступлений :)

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

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

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

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

1. Ясный код.

2. Вычислительное мышление.

Это пока были хипстерские шаги, а вот далее начинается секретная кроличья нора :)

3. Чистое функциональное программирование.

4. Транспиляция (эквивалентные преобразования исходных текстов программ на разных языках) -- запилить свой транспайлер.

5. Гомоиконичность (изоморфность синтаксиса и AST, код как сущность первого класса) -- попрактиковаться в Лиспе на сотне задачек с акцентом на "code as data".

6. Ссылочная прозрачность.

7. "Well typed programs cannot go wrong" Robin Milner 1978

8. Изоморфизм Карри-Ховарда.

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

Технически, в каждом дне 900 тханг чит, в году их 328500.
В великой кальпе 4,32 миллиарда лет, да на тысячу,
получаем 1 419 120 000 000 000 000 тханг чит.
Берём это как дни, да на три неисчислимые кальпы, да на, допустим, 9 миллиардов раз,
и получаем округлённо в годах
100 000 000 000 000 000 000 000 000

100 септиллионов лет! Вот на что я готов ради вас, дорогие! )))

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

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

Хотя конечно, когда проект исходно был спроектирован криво, он весь целиком одна сплошная опасность :) И надо всё переделывать с нуля.

Очень надеюсь, что в ближайшие годы проекты наподобие
Bun (a fast all-in-one JavaScript runtime)
или Deno (a modern runtime for JavaScript and TypeScript)
сбросят таки node.js с пьедестала.

Мы все часто слышим, что написанию хорошего кода (и качественной разработке в целом) можно научиться только опытным путём, методом проб и ошибок, через реальные проекты; или даже, возможно, хорошими программистами рождаются, а не становятся. И при этом мы постоянно читаем о принципах, которые лежат в основе хорошего кода: инкапсуляция, модульность, связность... Многие из них контринтуитивны, то есть были изобретены/открыты в академических кругах, мировыми специалистами в computer science.

Нету ли тут некоего противоречия? :)

Diagram as Code: рисуем красивые диаграммки питон-кодом.

Diagrams lets you draw the cloud system architecture in Python code. It was born for prototyping a new system architecture design without any design tools. You can also describe or visualize the existing system architecture as well.