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

Наиболее простой вариант, оптимальный с точки зрения обучения ребят без опыта в кодинге, сводится к применению функции Code Builder. В данной среде написание кода для работы с игровыми объектами требует использования блоков с командами на Python и JavaScript.

Следующая логичная ступень или шаг для ребят с минимальным опытом в программировании – разработка модов для Minecraft и их программирование посредством «Питона».

Научиться делать все это можно на онлайн-курсах Майнкрафта в 12 лет.

Содержание

• 10 содержательных онлайн-курсов кодинга в Minecraft для детей 12 лет

• Образовательная траектория «Инженер миров Minecraft»

• Разработка в Майнкрафте на «Питоне»

• Курс «Minecraft: программирование на языке Python»

• Кодинг в Minecraft для детей

• Minecraft-программирование для детей

• Основы программирования в Minecraft

• Уроки кодинга в игровой вселенной Minecraft

• Online-курс Майнкрафта для детей

• Курс написания кода в Minecraft

• Занятия по Python в Minecraft

• FAQ

• Что детям дадут курсы Minecraft в 12 лет?

• Почему создание модов в Майнкрафте в 12 лет считается вводным вариантом обучения?

• Как понять, что курс Майнкрафта для детей 12 лет является качественным?

• Уроки программирования в Minecraft онлайн хуже очных занятий?

10 содержательных онлайн-курсов кодинга в Minecraft для детей 12 лет

Отобрали десятку насыщенных онлайн-курсов Minecraft для детей 12 лет. Как и обычно, представили краткие аналитические сведения.

Образовательная траектория «Инженер миров Minecraft»

Узнать об образовательной траектории

Особенности: это комплексная образовательная траектория, которая базируется на блочном кодинге в Code Builder и на программировании на «Питоне». Основа представлена парой курсов, детализация опубликована в разделе с описанием содержания.

Цена: от 600 рублей за один час дистанционных занятий.

Скидка: 10 % для новых клиентов; чтобы получить выгоду, достаточно оплатить абонемент на 12+ занятий в день обращения.

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

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

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

Вот базовые направления, с которым предстоит познакомиться ребятам на образовательной траектории Майнкрафта в 12 лет:

• Блочный кодинг в Code Builder. Это функция Minecraft Education Edition, основанная на написании кода посредством блоков. Ранее отметили, что в них вписаны команды на Python и JavaScript, что по мере управления игровой вселенной через визуальное программирование поможет подготовиться к уверенному переходу к текстовым языкам;

• Кодинг на «Питоне» и создание модов для Minecraft. Особенность данного направления сводится к тому, что в результате его освоения учащиеся смогут отточить базовые навыки геймдева на примере разработки дополнений для Майнкрафта. Не обойдется без кодинга, для чего предстоит использовать Python.

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

Разработка в Майнкрафте на «Питоне»

Цена: от 790 рублей за урок.

Форматы: один на один с педагогом.

Темы: автоматизация процессов в игровой вселенной, создание дополнений, управление виртуальным миром путем написания скриптов на Python.

Курс «Minecraft: программирование на языке Python»

Цена: от 800 рублей за урок.

Форматы: только индивидуальные занятия для детей 12 лет в Майнкрафте.

Темы: переменные, строки, булевые значения, циклы, функции и т. д.

Кодинг в Minecraft для детей

Цена: от 1 125 рублей за занятие.

Форматы: группы, индивидуальное обучение.

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

Minecraft-программирование для детей

Цена: от 1 225 рублей за урок.

Форматы: данный курс доступен только в рамках группового обучения.

Темы: блочный кодинг, основы использования Code Builder, разработка дополнений и т. д.

Основы программирования в Minecraft

Цена: от 1 000 рублей за занятие.

Форматы: группы, один на один с учителем. Можно выбрать видеокурс.

Темы: управление игровыми объектами, базовые команды, автоматизация виртуального строительства и т. д.

Уроки кодинга в игровой вселенной Minecraft

Цена: от 790 рублей за урок.

Форматы: индивидуально-параллельный и полностью индивидуальный.

Темы: азы написания кода, основы 3Д-моделирования, создание игр внутри вселенной Minecraft и т. д.

Online-курс Майнкрафта для детей

Цена: около 1 200 рублей за урок минимум.

Форматы: параллельный и индивидуальный.

Темы: введение в игровую вселенную, знакомство с ее образовательным потенциалом, написание кода на «Питоне» для управления дополнениями и т. д.

Курс написания кода в Minecraft

Цена: около 900 рублей за урок минимум.

Форматы: организатор набирает группы.

Темы: основы программирования в Minecraft, создание анимации и мини-игр, разработка квестовых карт и т. д.

Занятия по Python в Minecraft

Цена: нет сведений.

Форматы: нет сведений.

Темы: программирование построек, создание небольших игр внутри Майнкрафта, кодинг на «Питоне» и т. д.

FAQ

Что детям дадут курсы Minecraft в 12 лет?

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

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

Почему создание модов в Майнкрафте в 12 лет считается вводным вариантом обучения?

Мы не считаем, что вариант вводный, но точка зрения уместна. Частично это обусловлено тем, что после тематических курсов ребенок сможет обрести лишь базовые знания и навыки программирования. То есть овладеть тем же «Питоном» в полной мере не удастся: потребуется учиться дальше.

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

Как понять, что курс Майнкрафта для детей 12 лет является качественным? 

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

Желательно, чтобы у организатора курсов имелась лицензия на ведение образовательной деятельности. Это станет гарантией соответствия реализуемых программ требованиям государства, а также основанием для предоставления клиентам ряда преимуществ. Оплата занятий маткапиталом, оформление вычета – примеры.

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

Уроки программирования в Minecraft онлайн хуже очных занятий?

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

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

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

Продолжение по теме
Распределение значений бенчмарка

Вопрос : При условии постоянной нагрузки и неизменного тестового запроса , какое распределение значений бенчмарка производительности СУБД для СУБД PostgreSQL будет встречаться чаще ?

Ответ DeepSeek:

При постоянной нагрузке и неизменных тестовых запросах распределение значений бенчмарка производительности PostgreSQL чаще всего будет приближаться к **нормальному распределению** (Гауссову распределению). Это объясняется следующими причинами:

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

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

3. **Минимизация выбросов**:
В идеальных условиях (оптимизированные индексы, достаточные ресурсы) редкие аномалии (например, внезапные задержки из-за сборки мусора) подавляются, и распределение становится более «гладким».

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

Постановка эксперимента.
▫️Постоянная нагрузка (количество одновременных запросов) на СУБД
▫️Одинаковый запрос
▫️Длительный период наблюдения
Вопрос математикам :
▫️Какое распределение значений бенчмарка будет наблюдаться ?

Есть два ответа на данный вопрос:
1️⃣В идеальном случае , при минимальном влиянии инфраструктуры будет нормальное распределение , характеристики которого (отклонение, дисперсия, медиана ) и будут результатом эксперимента .
2️⃣Распределение может быть любым , даже мультимодальным и характеристики распределения будут результатами экспериментов .

Вопрос - какой ответ корректнее с математической точки зрения ?

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

Встретил на Хабре интересную статью , да иногда бывает
Индексы в убывающем порядке (DESC) и NULLS FIRST в PostgreSQL

Насторожил один момент - а сколько измерений было проведено в ходе экспериментов?

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

Я пока, точно не рискну делать выводы о влиянии порядка индекса на эффективность выполнения запроса.

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

А , как известно , из ложной посылки - любой вывод должен.

Вот так, игнорирование стандартных математических основ может привести к глубоко ошибочным выводам и ложному пути .

Взято с основного технического канала Postgres DBA

В качестве дополнения к статье Первый пост

Важное пояснение

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

Историческое предисловие

Как известно, основная задача DBA - обеспечить наиболее эффективную и производительную работу вверенной ему в сопровождение СУБД. Для выполнения задачи одно из основных требований - умение определить насколько производительно/эффективно СУБД справляется с получаемой нагрузкой и выдает требуемый результат. Для этого необходимо определить такое понятие как производительность СУБД. Потому, что очень важно, для начала, хотя бы обеспечить мониторинг и иметь возможность сразу сказать - в каком состоянии СУБД - минимальная загрузка, оптимальная, перегруз, авария. Однако, как выясняется, общего понятия "производительность СУБД" до недавнего времени не существовало. Каждый DBA понимал под производительностью, то , что лично ему нравится - количество запросов в секунду, количество зафиксированных транзакций, среднее время отклика СУБД и даже процент утилизации CPU+RAM или вывести на экран десяток другой графиков мониторинга и каким то мистическим образом определить хорошо работает СУБД или плохо.

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

Для начала надо определиться с определением и ответить на главный вопрос - что есть производительность СУБД ?

Вспоминая физику , можно использовать базовое понятие:

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

Методы расчета метрики производительности

Самый первый вариант расчета метрики

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

А может быть производительность СУБД это вектор: (N1, N2, N3),где:N1 - количество активных сессийN2 - количество транзакцийN3 - количество запросов к СУБД в секунду.

В принципе, метрика вполне себе работала и показывала ожидаемые результаты - основная часть изменений не оказывали вообще никакого влияния на работоспособность СУБД . В результате было сохранено очень много рабочего времени , потому , что не нужно стало объяснять и доказывать неэффективности предлагаемых изменений. Все видно на графиках и в таблицах.

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

Аномалия учета ожиданий

Возможна ситуация - особенно при продуктивной нагрузке - работоспособность СУБД падает, а метрика растет.

Причина- количество активных сессий учитывает не только сессии выполняющие запросы , но и находящиеся в состоянии ожидания.

Порядок расчёта метрики производительности СУБД был изменен.

Второй вариант расчета метрики

Было принято решение изменить методику расчета, используя вектор:(N1, N2, N3, N4, N5), где:N1 - количество страниц shared_buffer , прочитанных в секундуN2 - количество страниц shared_buffer, записанных в секундуN3 - количество страниц shared_buffer, измененных в секундуN4 - количество завершенных запросов в секундуN5 - количество зафиксированных транзакций в секунду

Этот вариант проработал дольше . И обеспечил хорошую базу для работ по статистическому анализу производительности СУБД.

Аномалия изменения плана выполнения запроса.

Для того, что бы обнаружить аномалию достаточно было провести очень простой эксперимент:

1. Создаем большие таблицы: родитель-потомок.

2. В таблицах не создаем индексы.

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

4. Выполняем несколько итераций, фиксируем время выполнения запроса и показатель производительности СУБД.

5. Создаем индексы для таблиц.

6. Выполняем итерации того же самого запроса.

7. Фиксируем время выполнения запроса и показатель производительности СУБД.

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

Причина: При выполнении индексного доступа к данным количество обработанных страниц shared_buffer существенно уменьшается. А при использовании метода доступа Index Only Scan вообще будет нулевым. В результате значение метрики производительности уменьшается.

Третий вариант расчета метрики

Для решения проблемы аномалии изменения плана выполнения запроса, расчет метрики был изменен. Необходимо было ввести новые определения .

Операционная(результативная) скорость

Полезными операциями(результатами) работы СУБД являются:

1. Количество строк выданных пользователю.

2. Количество запросов выполненных пользователем.

3. Количество зафиксированных пользователем транзакций.

Разделив количество на количество секунд (DB Time), которые потребовались на выполнения операций СУБД в изменяемый промежуток получаем - вектор , определяющий операционную(результативную) скорость:

• QPS: Количество запросов в секунду.

• TPS: Количество транзакций в секунду.

• RPS: Количество строк в секунду.

Для того, что бы иметь одну цифру используется модуль вектора ( QPS , TPS , RPS ).

Полученное значение и будет считаться операционной скоростью.

Объемная скорость

Работа СУБД заключается в обработке блоков информации:

1. Прочитанные разделяемые блоки

2. "Загрязнённые" разделяемые блоки

3. Записанные разделяемые блоки

4. Прочитанные локальные блоки

5. "Загрязнённые" локальные блоки

6. Записанные локальные блоки

7. Прочитанные временные блоки

8. Записанные временные блоки

Таким образом, применив тот же подход , что и для расчета операционной скорости получим- вектор, определяющий объёмную скорость :

1. RSBS : Прочитанные разделяемые блоки в секунду.

2. DSBS : "Загрязнённые" разделяемые блоки в секунду.

3. WSBS : Записанные разделяемые блоки в секунду.

4. RLBS : Прочитанные локальные блоки в секунду.

5. DLBS : "Загрязнённые" локальные блоки в секунду.

6. WLBS : Записанные локальные блоки в секунду.

7. RTBS : Прочитанные временные блоки в секунду.

8. WSBS: Записанные временные блоки в секунду.

Аналогично, для получения значения используем модуль вектора ( RSBS , DSBS , WSBS , RLBS , DLBS , WLBS , RTBS , WSBS ).

Полученное значение и будет объемной скоростью.

Расчет метрики "производительность СУБД"

Отношение операционной скорости к объемной скорости и будет принято как производительность СУБД.

Как видно, производительность СУБД в течение заданного промежутка времени прямо пропорционально объёму полученного результата и обратно пропорциональна объёму обработанной для получения результата информации.

Другими словами - данная метрика показывает - насколько эффективно СУБД выдаёт результат, обрабатывая объем информации .

Т.е. если план запроса изменился так, что запрос стал выполняться быстрее и читать меньше блоков (стоимость запроса снизилась) , то в этом случае значение метрики - увеличится .

Для удобства , обозначим производительность СУБД как CPI. Тогда производительность СУБД в момент времени t , есть значение дискретной функции CPI(t).

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

Дополнение: очень вероятно , что корреляция между операционной и объёмной скоростью - очень интересная тема для более подробного анализа . Нужно протестировать в самое ближайшее время .

Временной/исторический анализ производительности

Задача анализа производительности СУБД сводится к анализу временного ряда, сформированного из значений функции CPI(t) , для значений t от начала до окончания анализируемого периода .

Например: Использование корреляции для мониторинга производительности СУБД

Параметрическая оптимизация производительности

Задача по оптимизации производительности СУБД сводится к задаче оптимизации функции CPI(t) при изменении набора конфигурационных параметров СУБД .

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

Примечание

В настоящее время в стадии сбора данных несколько экспериментов по параметрической оптимизации. Результаты будут опубликованы после окончания и анализа.

В комментариях к предыдущей статье было предложено использовать не Евклидову, а Манхеттенскую метрику для расчета модуля векторов операционной и объёмной скорости . Поскольку , в общем случае, размерности векторов нельзя считать независимыми . В настоящий момент , тема в проработке. Возможно смена метрики позволит избежать каких то еще аномалий , которые пока не проявились.