Какой красавчик! Вообще все видосики изумительные.

Хорошая метрика командной производительности -- скорость, с которой выполняется code review. Типа, отправили вы свой код в локальный мастер, и ждёте пару дней, когда его ближайший свободный сеньор обозрит :)

Если в вашей команде вообще не ведутся никакие метрики, рекомендую начать именно с этой.

Если, конечно, процесс проведения инспекций кода у вас хоть как-то организован; если же нет, тогда с вами пока вообще не о чем говорить, это даже не детский сад, а ИТ-ясли :)

В web3 сегодня работает много 17-летних, 16-летних, 14-летних! Именно работающих - зарабатывающих деньги, и создающих потрясающие проекты (более подробно буду рассказывать об этом тут).

Когда моему сыну было 14, он в основном упарывался в HoMM и LoL и ходил в WoW на больших боссов.

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

Нравится вам это или нет, но рост JavaScript уже не остановить. Сейчас он захватил более 50% кода на GitHub. Он как сорняк заполнил фактически каждую нишу в экосистеме. Он слишком "подходит" для чего угодно.

Фронтенд? node.js
Бэкенд? node.js

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

P.S. Учите, короче, обязательно js и ноду, увы :)
А кто хочет стратегически развиваться, старайтесь по возможности вместо js применять TypeScript.

RISC-V -- вечная архитектура! В этом году только Intel инвестировала в неё миллиард долларов.

"SiFive X280 delivers 100x increase in computational capability with leading power efficiency, fault tolerance, and compute flexibility to propel next-generation planetary and surface missions"

А вот авторы "Стратегии развития программного обеспечения с открытым кодом в России" назвали гибельной "активно лоббируемую идею использовать для разработки отечественных процессоров «открытую» архитектуру RISC-V".

С примитивными мемами "Создавать и развивать своих разработчиков и свои платформы, везде, где только возможно в таких брешах. Тратить бюджеты и господдержку в первую очередь на своих." и не поспоришь: Майор Ясен Пень отмечает, что лучше быть богатым и здоровым чем бедным и больным, и лучше вкладывать в своих (Эльбрус кстати не RISC) а не в чужих, и что 2x2=4 и что солнышко светит в небе и что трава зелёная.

Однако на практике это выливается в недавнее "дайте 6 миллиардов рублей на отечественный игровой движок", и грядёт что-то типа "дайте 666 миллиардов рублей на отечественную RISC-архитектуру".

Как правильно: выделить 1 миллиард рублей на промышленный шпионаж, похитить всю проприетарную техническую документацию по RISC-V, и продолжить свои проекты уже на основе такого "форка", в который уже были вложены многие миллиарды долларов.

Кстати, вот Байкал это RISC ARM, но они не учли высокие риски международной обстановки :) и теперь их реально может спасти переход именно на RISC-V. Ну и вторая итерация в подобных мега-проектах это совершенно нормально.

Австралийский военный фрегат HMAS Ballarat стоимостью 500 млн. долл. в январе 2005-го сел на мель из-за предполагаемого сбоя в бортовом ПО. Навигационная система автоматического управления проложила маршрут так, что он пересёкся с маршрутом другого судна; капитан приказал вручную выполнять аварийный разворот в обход компьютерной системы, и дал команду включить два винта работать в противоположные стороны (совсем не в морской теме, извините :) но идея понятна, для разворота корабля). Однако это "сбило с толку" компьютер, который врубил оба двигателя на полный обратный ход, и судно въехало кормой в скалы. Ремонт обошёлся в 2 млн. долл.

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

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

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

🔥 Подписаться 🔥

В советское время все ребята до 27 лет кто не служил, парились темой бронь/отсрочка. Официально решалось это только работой в закрытых конторах (которых тогда было очень много), в почтовых ящиках. Я и сам работал программистом в таком (ГВЦ Министерства оборонной промышленности СССР), но засада была в том, что пресловутая бронь была на словах, а как пришла офицерская повестка, так сделать там ничего не смогли :) Писульку какую-то дали, которую военкомат просто проигнорил, и довольно прозрачно намекали на возможность решить проблему неформально :) Но я принципиально пошёл к адвокату, который потребовал законного учёта моих проблем со здоровьем -- и всё молниеносно решилось в мою пользу.

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

Требуйте безукоснительного соблюдения законодательства РФ.

Красивое: паззл нового поколения Dog-Bunny Puzzle. Кто не решит, у того заячий ум :)
Крайне простые правила, и удивительно высокая сложность. Я всю ночь провозился, но так и не смог решить; правда, и PhD многие не справляются.

Уже доказали, судя по всему, что это NP-полная задачка.

Её математическое описание.

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

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

Где-то год назад я начал понемногу делать idle-игру в жанре "Русские хакеры против NATO", в редкие свободные минуты ) UI минималистичный, просто чистый медитативный геймплей. Однако никому не говорил, потому что, во-первых, мой опыт сотен сайд-проектов показывает, что до конца доходит в лучшем случае 1-2% задумок, и крайне важно добраться до некоторой критической точки перелома, после которой проект уже будет развиваться безусильно и неотвратимо )

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

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

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

Будем взламывать модуль Data Distribution System информационного комплекса Cooperative Engagement Capability морской пехоты США, который сейчас спешно развёртывается на военных кораблях,

делать закладки в архитектуру интегрированной системы боевого управления ПВО/ПРО Integrated Battle Command System, которая должна оперативно заменить семь ныне действующих легаси-систем,

перехватывать в реальном времени управление системой контроля давления в кабине стратегического лайнера-транспортника Boeing KC-46, сотни которых сегодня начали приходить на смену KC-135 1960-х годов,

создавать иллюзорные изображения в скрытно модифицированной системе ночного видения и целеуказания для пилотов TADS/PNVS, которая в этом сентябре начала обновляться на вертолётах Apache,
и т. д. и т. п.

P.S. Примерно 30% (!) ребят кто у меня занимается, мобилизовались, и частый вопрос "как потом вернуться?", потому что наборы у меня проводятся очень редко. Дорогие, не парьтесь, просто возвращаетесь и спокойно продолжаете с момента заморозки.
Главное напутствие: старайтесь по максимуму носить каску и броник, и не ни в коем случае не вытаскивайте из него пластины "чтобы было полегче". Берегите себя.

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

Однако на эту вроде бы очевидную вещь, формализованную ещё десятки лет назад в университете Карнеги-Меллона (Capability Maturity Model; американские военные и господрядчики не могут получать крупные ИТ-подряды, если не сертифицированы по её верхним уровням) сегодня практически нигде в ИТ не обращают внимания под предлогом "нету времени".

Когда вы говорите "реализуем эту фичу в следующей версии", ваш проект начал стремительно катиться на дно :)

Основной компромисс в проектировании систем любой сложности сводится к балансу между экономией на возможности работать с компонентом в изоляции, и затратами на отсутствие возможности работать с компонентом в изоляции.

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

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

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

Я сперва предполагал противоположное: типа, академические курсы давно устарёли, а самый топ -- это современные онлайн-школы... ничего подобного. Да даже классическая книжка "Black Hat Python" для младшего школьного возраста куда лучше и полезнее будет, чем вот это всё.

P.S. Неожиданно заспрашивали "а что это за поисковики?"
Ребята, ну вы чего? Дальше гугла не заходите? :)
Вот правильная подборочка например.

Книги по программированию надо писать так, как "Land of Lisp".

Две важные и неявно связанные проблемные точки в проектировании, характерные для 98% "проектировщиков" -- это скрытая связность/coupling (когда поверхностный выбор конкретного дизайна тонко влияет на множество вещей в проекте), и расползание по коду ваших предположений "как это всё должно работать", которые никак формально не обоснованы (потому что вы не умеете думать на третьем логическом уровне).

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

Если ваш код стал тяжёлым для понимания, в 9 случаях из 10 проблема заключается в кривой модели данных (не домена!).
И это полностью ваша вина :) Либо плохо учились проектированию, либо вообще не хотели учиться, полагаясь на свой "гениальный от природы" ум.

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

Однако они находят всё с первой попытки.

Женский кошелёк -- это чёрная дыра (которая внутри ещё больше), и это интересный объект исследования разве что для физика. Но для неё этот хаос имеет тайный смысл. "Это просто! - говорит она, - мужчины просто не могут ничего найти".

То же самое верно и для кода. То, что кажется очевидным для вас, может вообще не иметь никакого смысла для других.

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

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

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

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

Ещё в 80-х годах SmallTalk пытался дать нам свободу думать о коде в абстрактных терминах. Больше никаких файлов, только зависимости. Перемещайте что угодно куда угодно, а компилятор сам разберётся.
На то время такой чрезмерно прогрессивный подход не прижился потому, что компьютеры были слишком слабыми. Но вот почему он не возродился сегодня, большой вопрос к "трендсеттерам" ИТ.

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