Metaeducation

С самых простых вещей, язык не особо важно какой, но лучше сразу 2 параллельно учить, они сейчас все развитые, а вот важное: - как делать промежуточные переменные вместо сложных выражений - разделять сложное на части и объединять части в целое - давать всему семантически полезные имена, строить читаемые управляющие конструкции, избегать комментариев - избегать accidental complexity, из нескольких решений выбирать попроще - сначала думать о данных, как они представлены в памяти и связаны, а уже потом писать алгоритмы обработки - привыкать думать об ограничениях и контрактах, какие входные данные можно изменять, какие нет - больше думать не о вычислительной сложности, а о семантической сложности и как ее можно изолировать

Сегодня — Часть 2 вводного курса по применению структур данных, покажу и сами примеры внедрения и Skills для AI, чтобы писать код эффективнее 1. Встроенные структуры JavaScript: Object, Array, Map, Set, WeakMap, WeakSet, TypedArray 2. Кастомные структуры: Queue, Deque, Stack, List, UnrolledList, Circular Buffer, Heap, Trie, Graph, LRU, Pool, CRDT 3. Высокопроизводительные структуры metautil: Struct, ConsList, Trie, List, UnrolledList, Queue, Deque, Stack, Pool, Semaphore В субботу, 8 августа, в 17:00 смотрим, как подключать скилы и библиотеки и использовать их в реальном коде: https://gm.nexttick.it/go/data-structures-code-review

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

Что я понял по итогам работы над структурами данных для стандартной библиотеки Metarhia Это же классическая тема, но ее мало кто хорошо осваивает в наше время, тем более в мире JS/Web разработки и во времена, когда все пишет AI. И даже если учили и знают, как делать хотябы простейший список, то нет привычки его использовати и знания остаются аккадемической теорией, невосстребованными вообще, а в коде массивы и объекты, ну максимум Set/Map. Почему же так случается? - Обычно людей учат как устроены структуры данных внутри, а нужно учить, как их применять. Внутреннее устройство даже не всегда нужно знать. - Нет хороших примеров использовани и нет культуры написания кода на структурах, так что, просто так это не поменять, нужно менять трек обучения. - Еще вариант: добавить скилы для этого и заставить типовые случаи внедлять через AI, это наверно сейчас более актуально, людей быстро не переучить. Я за последний месяц собрал свои наработки за последние 15 лет и сделал и продакшен-версии кода и учебные примеры, записал много лекций и стримов по структурам данных. Буду делать примеры и скилы, а пока вот продакшен-реди реализация самых нужных структур тут https://github.com/metarhia/metautil

Fable наконец начал понимать конструкции с динамическим наименованием классов, раньше невозможно было пояснить и проще было написать руками такие вещи и то другие модели часто переписывали, если встречали такое на что-то привычное, например defineProperty или брендинг классов. Ладно там Fable, а вы такое умели? Через объект-контейнер и свойство с динамическим именем

const createClass = (name) => {
  const container = { [name]: class {} };
  const Entity = container[name];
  return Entity;
};

Более короткий способ

const createClass = (name) => ({
  [name]: class {},
})[name];

Или через деструктуризацию

const createClass = (name) => {
  const { [name]: Entity } = { [name]: class {} };
  return Entity;
};

В этот четверг на созвоне сообщества Метархия обсудим Стартап инкубатор Meta Qube Основные его идеи: - с AI стало возможно делать стартапы малыми силами и вложениями - ИТшники до уровня синьора не могут найти работу, решение - стартап - начинающим негде получить первый опыт, решение - стартап - синьоры и архитекторы сейчас часто предпочитают сделать свой продукт вместо того, чтоб работать на дядю - инвесторы хотели бы заработать на AI буме, но нет доверия, везде нейрослоп - 80% функций любого стартапа одинаковые и писать их каждый раз заново нет смысла: платежи, API, лендинг, рассылка, боты, и многое другое - универсальный модуль для переиспользования сделать всего на 20-30% сложнее, вынеся конфиги и метаданные, использую DSL и схемы - переиспользуемая модуль будет гораздо качественнее, чем навайбкоженный и проще обеспечить его поддержку и улучшение 🎙️ Metarhia community call Thursday, Jul 2  •  19:00 – 21:00 Google Meet joining info Video call link: ссылка опубликована для Patreon подписчиков https://www.patreon.com/c/tshemsedinov

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

🕳 AI: Event Horizon for IT Коллапс, образование, AI пузырь, работа 👤 Vlad Ten 👤 Timur Shemsedinov Fri, 22 May 2026, 19:00 https://www.youtube.com/live/17RqGlJjb50

Со скиллами самые простые и дешевые модели пишут как самые дорогие. Но это только задачи по этим скилам, а чтобы все писало лучше, их нужно десятки. Я уже выпустил 4 из 40+ драфтов и здесь видео о том, как их собираю и готовлю. Еще есть видео где я их отлаживаю и экспериментирую, но не знаю, будет ли оно интересно. https://youtu.be/wfjNneyifYw

Ревью кода и постановка ТЗ занимает много времени в программировании с AI и люди, естественно, пытаются переложить эту задачу тоже на AI. Пусть агенты друг-другу ТЗ пишут, друг-друга дрессируют и ревью делают. Так можно дойти и до кнопки "Сделай все хорошо", которая запускает бесконечный цикл. У вас не выйдет не тратить внимания на проект. AI про ваши потребности не занет и мысли не читает. Идеи, приоритеты, контекст, критерии качества и продуктовые компромиссы он сам не определит. AI хорошо пишет только то, что уже много раз кем-то писалось. Если убрать из процесса человеческое внимание, вы не ускорите проект - вы просто зациклите галюцинирование. На проект все равно придется тратить внимание. Вопрос не в том, как убрать человека из контура, а в том, куда именно направить внимание и в какой форме его вписать в жизненный цикл разработки, чтобы получить максимальную отдачу. Например, в виде DSL-языков, в форме md-файлов или json-файлов, блок-схем, в виде ревью или архитектурных документов. - Не заменять ревью, а удешевлять его через стандарты, скилы, субагентов, экономию контекста - Не строить зацикленные цепочки агентов, а ограничивать зоны их ответственности - Не пытаться автоматизировать мышление целиком, а освобождать внимание человека от рутины - Не держать требования в текстовой форме, а выносить логику в строгие синтаксисы и контракты - Не надеяться на память чата, а собирать контекст в версионируемые артефакты, схемы и спецификации