"Единственное, что растет быстрее, чем производительность компьютеров -- это человеческая глупость"
приписывается Бьярну Страуструпу (автор С++)

Есть такой малоизвестный класс алгоритмов задержки (backoff algorithms), которые используются во многих распределённых системах, когда несколько сущностей/устройств конкурируют за общий ресурс. Часто задачки по этой теме формулируются как "шары в корзины" (и оказывается, что важным критерием становится количество синглтонов - корзин с одним шаром); однако существующие схемы анализа алгоритмов применяют сложные вероятностные инструменты.
Вот например полезная вводная заметка "Exponential Backoff или как "не завалить сервер", рекомендую всем, кто изучает фундамент highload:
"Совет: используйте экспоненциальное откладывание при любом повторе запроса — в клиенте при обращении к серверу или в сервере при обращении к базе данных или другому сервису."

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

Мартовский свежачок, где пацаны из университета Миссисипи показали, что можно эти задачи решать гораздо проще и точнее с помощью так называемых стандартных границ Чернова (простое оценивание вероятностного распределения); в тему неплохая лекция "Границы Чернова, маршрутизация пакетов по коммуникационной сети".

Сам Герман Чернов кстати, профессор MIT, родился в семье эмигрантов из России в 1923-м и прекрасно себя чувствует :)

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

С одной стороны, пять лет программистом в оборонном ящике после института, конечно многовато (даже в СССР было три года отработки :).

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

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

Платить, думаю, будут достаточно нормально и стабильно; конечно не как в крипто-стартапах :) но если явно мало, так и кодить люди будут совсем еле-еле. Тут как раз выгоднее не экономить, потому что платя в 2 раза меньше, продукт получишь в 22 раза позже; лучше платить хорошо, близко к "среднерыночной", чтобы был нормальный результат в разумные строки.

Есть такая card-based cryptography, придуманная в 1989-м, когда для качественного шифрования сообщений используется обычная колода игральных карт. Заметочка с хабра "Крипто-шифр "пасьянс".

Так как эта форма криптографии "аналоговая", она и компрометируется в принципе достаточно легко (кто-то колоду перетасовал).

card-based cryptography однако была проработана достаточно глубоко некоторое время назад, и под неё подведено серьёзное научное обоснование: "Foundations for Actively Secure Card-based Cryptography".

В тему полезно также почитать про "ментальный покер".

В мае Пентагон начинает полевые испытания гарнитуры виртуальной реальности Integrated Visual Augmentation System (в частности, как системы кругового обзора для бронетехники), которая на самом деле -- коммерческие VR-очки HoloLens с доработкой под сложные условия эксплуатации, и которые закупаются у Microsoft на 22 миллиарда долларов (столько Газпромнефть стоит например).

А я говорил ещё три года назад (словами профессора Карла Хьюитта :), что

"Масштабируемые интеллектуальные системы SIS -- это самый эпичный программный проект, равных которому по сложности в истории человечества пока не было. В 2018 г за эту тему взялись США, Евросоюз, Китай, Канада, Англия, Тайвань и Япония. России в этом списке увы нету. Предполагается, что SIS вызовут громаднейшие изменения в мире, причём уже к 2025-му году."

Принципиально важно, что клиентские устройства SIS -- это прежде всего VR-очки.

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

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

Напомнило сериал "Космические войска" :)

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

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

Так вот, typestate позволяет добавлять в систему типов протоколы. Примерно 10-20% объектов в типовом проекте протоколы "поддерживают" (были научные исследования по их выявлению), только некорректно, а то и потенциально ошибочно. Речь о том, что методы класса в рамках протокола должны вызываться в определённом порядке. Скажем, вы должны сперва открыть файл до того, как будете его читать. Обычный компилятор корректность протокола open => read конечно не проверяет, вы просто получите ошибку рантайма при попытке считать из закрытого файла.

Typestate же позволяет вытащить протокол на уровень синтаксиса: у вас фактически будут отдельные типы файлов -- для открытого файла и для закрытого, у которого нет метода чтения. Это чуть-чуть похоже на микро-протокол Go, когда вам надо явно инициализировать переменную с помощью := перед дальнейшим её изменением, иначе компилятор выдаст ошибку, если выявит попытку присваивания = переменной, которая не была инициализирована явно особой синтаксической конструкцией.

Это всё, что нужно знать о функциональном программировании на JavaScript:

['1', '7', '11'].map(parseInt) == [1, NaN, 3]

...Однако, четыре фундаментальных языка (в разных парадигмах), на которых всё ИТ стоит и стоять будет, и которые полезно изучать максимально глубоко (включая понимание, как для них пишутся компиляторы и интерпретаторы) -- это Си, Лисп, SQL и JavaScript.

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

Иногда спрашивают, а что сегодня самый топчик в computer science, но при этом имеет прямое прикладное значение? Ну например DSL для реализации тайп-чекера. Единственной программой на таком языке будет декларативное описание конкретной системы типов в некотором прикладном языке программирования, исполняемая формальная спецификация (вычисляемая математика по Алану Кэю), если хотите. Это уровень ведущих разработчиков MMANGA, и имея подобный проект на гитхабе, вполне можно претендовать на отличный оффер в обход бесконечных типовых собеседований по решению литкодовских задачек. Напишите тайп-чекер для конкретного языка, для Apple Swift например, ну и просто это будет большой пожизненный +1 в вашей карьере.

Метапрограммирование, аланкэевщина -- это в значительной степени про DSL (domain specific language) -- прикладные языки предметных областей. Отличие метапрограммирования от lowcode в том, что мы не берём одно готовое "универсальное", а сами делаем подходящие DSL чётко под нашу проектную семантику. Про DSL относительно мало материалов (это очень продуктивный подход, но и весьма сложный), хотя некоторые относительно популярные языки (например Ruby) парадигму DSL поддерживают.

Но есть в этом контексте другой топчик, ещё более аутентичный -- TSL (type specific language). Идея, что в коде есть функция, которая принимает например регулярное выражение, и когда компилятор это видит, он автоматически переключается на парсер регэкспов, и таким образом можно смешивать много разных языков, много разных синтаксисов в одном файле -- гораздо более концептуальным и элегантным способом, чем другие решения. В некотором смысле например C# можно считать TSL, когда мы нативно используем в коде LINQ.
Полноценный пример TSL -- это язык Wyvern разработка которого была профинансирована Агентством национальной безопасности США, потому что подходы DSL/TSL позволяют существенно повысить надёжность и выразительность кода.

Определений абстракции в программировании существует множество, и возможно вы встречались с одним из них, если изучали учебник "Структура и интерпретация компьютерных программ" (SICP), который считается одной из двух самых великих классик в информатике -- наряду с "Concepts, Techniques, and Models of Computer Programming" (CTM), которая на русский не переводилась (кроме моих курсов :). Так вот, уже первая глава SICP называется "Построение абстракций с помощью процедур", но насколько она адекватно отражает концепцию абстракции?

Gerry Sussman (один из авторов SICP) продолжает успешно профессорствовать в MIT, и наши с вами PhD-друзья из Массачусетса этой весной 2022-го года специально обратились к мэтру, чтобы он окончательно пояснил за его версии абстракций :) По мнению Sussman, абстракция -- это "чемоданный термин", который означает слишком много разных вещей, хотя он видит ровно два её подходящих определения, прямо относящихся к разработке программного обеспечения.

Первое определение: давать имена сущностям, созданным в соответствии со вторым определением. :)

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

В СильныхИдеях в мае разберу эту тему более подробно, на пальцах, доступно любому программисту-нематематику :) Ну и, надеюсь, разберём со временем, как доказать первую теорему о гомоморфизме в HoTT на питончике, в каком-нибудь теорем-прувере.

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

Думаю, это явился в мир киллер JavaScript )))
pynoscript.net

Поддержка добавляется просто двумя строчками в html-страничке.

Ддосят большого и богатого клиента (не скажу какого - ***.info), а мой скромный учебный сервис оказался с ним у хостера на одном серваке и немного попал под раздачу -- подтормаживает 2-3 секунды :)
Админы пообещали перебросить в более спокойную зону.

Не понимаю, почему NashStore сегодня преподносится как какое-то эпичнейшее достижение российского ит )))
Ну да, полезная альтернатива гуглмаркету для страховки, поставил себе, но не более.
"более 1000 приложений" (с) )))

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

P.S. Так то это уровень дипломного проекта наших универов.
P.P.S. На фрилансерских сайтах можно за сотку долларов найти исполнителя, который прототип такого стора запилит за недельку-другую :)

Что очень важно понимать по Go, который активно пропагандирую , в контексте своей карьеры (важный нюанс, не говорю тут про технический аспект)?

Ну, вот на Java (8 :) и Python (2.7 :) написаны наверное терабайты кода, и всё это легаси работает вокруг нас в огромном количестве, и на его сопровождение и сейчас полно очень вкусных вакансий, и будет становиться только больше.

А на Go-программистов такого ажиотажного спроса нету просто потому, что пока не нафигачены все эти тонны говнокода, которые надо суппортить и хоть как-то развивать :) Лет через 10, ну возможно.

Нытьё на РИФе, просто поразительно.

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

Зачем?? Очень надеюсь, что им не дадут ни копейки.

Как надо:

- тем, кто даёт деньги - организовывать побольше конкурсов для разработчиков игр, с нормальными бюджетами, чтобы побольше участников что-то получали, + помогать им в продвижении;

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

P.S. Вышедшая на днях Songs of Conquest — изумительный клон Heroes of Might and Magic, сделана как раз в олдскульных технологиях :)

Возможно, вы уже читали: на днях гугловский Deep Mind устами профессора Nando de Freitas заявил, что близок к созданию AI человеческого уровня (AGI), причём весьма бескомпромиссно: "the game is over", и теперь достаточно лишь смасштабировать Gato, чтобы получить полноценные результаты.

Вообще, подобные анонсы ожидались только лет через 10-15, и пока это заявление раскритиковали авторитетные конкуренты (например, LeCun).

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

Сильно недолюбливаю этот подход (тупо токенизируем данные и тупо запускаем градиентный поиск...), однако факт, что на этом пути удаётся получать совершенно неожиданные и совершенно непредсказуемые результаты. А что будет способна делать Gato, когда вырастет до размеров GPT-3? В каких областях внезапно покажет способности уровня людей-экспертов и выше? Уже сегодня нейросетки проектируют специализированные чипы и управляют истребителями лучше людей например.

Короче говоря, прогноз, что с мая 2022-го роль сильного AI во многих (всех?) областях деятельности будет возрастать экспоненциально. Самоубийственно сегодня вкладывать миллиарды в создание заводов по производству чипов 20-летней давности, и не вкладывать миллиарды в создание сильного AI.

Просили пояснить по парадигме TSL (type specific language) -- в чём отличие от DSL, в частности?

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

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

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

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

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