Я тоже за интегрированый подход. Стоишь на остановке можно растяжку какую нибудь делать, подниматься на ступнях например. Видел даже одного чувака он на железнодорожном перроне отжимался. Хорошо еще в трамвае никто не додумался подтягиваться на поручне :D Но балансировать на ходу в автобусе или трамвае, когда загруженность позволяет, я сам люблю. И весело и полезно.
Скажите, простому обывателю Блютуз наверное известен прежде всего тем, что попытки соединить два устройства, например телефон к машине, превращаются в целое приключение с неизвестным концом. Может соединится, а может и нет. Например android телевизор Bravia от Sony хоть и имеет bluetooth поддержку, но не распознает ни колонки ни наушники. Причем выборочно. Думаю подобная ситуация, возможно с другими комбинациями устройств, знакома всем не по наслышке. Так вот вопрос. Отчего в принципе происходят такие проблемы? Это неправильно запрограммирован протокол на одном из устройств? Это принципиальная проблема самого протокола?
Ну и всякие наушники, колонки, чайники. То, что никак не критично
Клавиатуры, мыши ...
Причем читал, что можно подменить тип устройств. Если адрес останется прежним, то материнское устройство никак на это не прореагирует. Например, были наушники, а стали клавиатура. И погнали скрипты по типу Rubber Ducky крутить.
Нельзя вводить технологию не объясняя принцип ее устройства. Иначе у нас получится не обучение а курсы по технологии.
Конечно это не уровень проф. разработчика
Эти навыки до сих пор востребованы на рынке (bootstrap, jQuery), значит это уровень проф. разработчика. Качество выполнения работы - скорее всего не будет дотягивать до рыночных стандартов, это да.
для показа ребенку — вполне
Ребенку важно не только показать, а объяснить. И это мы с 14-летним разбирали HTML, и то уже после получаса концентрированой работы мозга, "батарейка" села. А 9-летнему я вообще не представляю толком как это давать. Там человек только читать и писать научился. Хотя! Вот вспомнил, мы в прошлом году с младшим (8 лет) делали мини-проект на https://calliope.cc/ (обучающий одноплатинник, вроде micro:bit) и хоть ему было трудно все время следить за ходом создания проекта, сама идея сделать анимацию с музыкой его заинтересовала, и он подавал идеи. Но интерес возник тоже спонтанно и оказался непродолжительным. С другой стороны детективные загадки те же самые дети решают увлеченно и с удовольствием. Или играют в игры требующие логическокго упорядочивания действий.
И то, сейчас верстка уехала настолько вперед по сравнению с тем что было 10-20 лет назад. Ребенок мне сказал: "а я хочу расположить текст в колонки, как на википедии". И все, уже нужно рассказывать про методы верстки на div-контейнерах. Т.е. то с чем дети будут сравнивать свой результат сильно продвинулось, и дать им что-то "простенькое" будет для них неудовлетворительным. А давать всё - могут потерять нить. Путь который нужно осмыслить от начала до результата удлиннился существенно.
Я расположил входные сигналы на 1,5,6,10, 11 и программа решила, что это похоже на "4", хотя 11 в четверке не возможна.
пример
Но, надо сказать, что это наглядно демонстрирует насколько сложной может быть настройка коэффициентов и что тестирование нейросетей совсем не тривиальная задача, хотя, казалось бы, это всего лишь математическая функция, которая проецирует одно множество на другое.
Количество подмножеств одного множества вычисляется по формуля 2 в степени n. Получается нам для полного покрытия этой функции понадобится 8192 проверки.
Мне эта задача видится как требующая решения на уровне архитектуры приложения. Если это фактически самое самое важное место в программе, вокруг которого вращается все, то я бы выделил его в независимую единицу с четким интерфейсом, грубо говоря "движок приложения" (есть шаблоны архитектурные для таких типовых задач), и покрыл бы юнит тестами так, чтобы мышь не проскочила.
Если, конечно, писать "сверху вниз" безо всякой архитектуры, тогда логика расползется по всему коду, будет нечитаемая каша, страх изменений и постоянный регресс. (Страх кстати и есть одна из причин ругани в команде). Дальнейший рефекторинг станет сложным. Интервалы релизов будут увеличиватсья. Тестирование превратится в гонку на время. По причине этого введут автоматизацию тестирования, которая не решит это проблему. Это перекладывание отсутствующих тестов с уровня кода (юнит-тесты) на уровень пользовательского интерфейса. Где они сложнее, и менее надежны по своей природе.
Как клиент магазина бытовой техники, я хочу зарегистрироваться на сайте магазина, чтобы оформить он-лайн заказ.
Это то, какне надо писать юзер стори. Почти все в этой шаблонной формулировке сущее вранье. Пользователь не хочет регистрироваться на сайте магазина, чтобы оформить заказ. Пользователь хочет оформить заказ и, как правило, вынужден для этого проходить процесс регистрации. Не он хочет этого, этого хочет магазин. Для того чтобы выслать товар клиенту, владелец магазина хочет получить от клиента адресные данные и данные по оплате. (Для этого регистрация кстати не нужна). А регистрация нужна для того, чтобы хранить адресные данные и данные по оплате для последующих заказов. Либо же там есть какие-то удобные функции (типа истории заказов) которые привязаны к учетной записи. И эти случаи все нужно четко разграничить. Тогда у нас получатся разные истории: я новый клиент и хочу быстро оформить заказ, я постоянный клиент и при оформлении заказа не хочу каждый раз вводить одни и те же данные.
Юзер стори не содержит деталей реализации. Одна из функций юзер стори это, грубо говоря, прояснить в голове заказчика, а как же у него бизнес работает и как он взаимодействует с пользователем, зачем и почему, а также инициировать процесс осмысления и обсуждения.
Я понимаю, что это "всего лишь пример, и вообще не про это, а про именование", но из таких неверных примеров потом мы имеем тонны шаблонно написаных юзер стори от которых ни тепло ни холодно. Кстати и именование я бы сделал исходя из пользователя, а не функции. "новый клиент", "постоянный клиент". А для различения лучше написать отличительную особенность этой истории вместо цифр и аббревиатур, которые не несут в себе никакой полезной информации, кроме того что по цифрам можно сортировать в экселе. Для группировки по тематической области лучше потом уже к карточке "тег" прикрепить.
Интересно, конечно. С одной стороны у нас аджайл с его принципами
Люди и взаимодействие приоритетнее процессов и инструментов . Сотрудничество с заказчиком важнее согласования условий контракта Работающий продукт важнее исчерпывающей документации ...
С другой стороны мы вводим формализацию и инструменты для ее автоматизации.
P.S.: Кстати, если смотреть на контрактную разработку то корпоративным заказчикам по факту важнее именно ценности справа, а не слева, хоть они и требуют чтобы их команды работали по аджайлу. Единственный принцип корпоративного аджайла это "прикрытие своей задницы важнее всего остального".
Тестирование калькуляторов - совсем нетривиальная задача. Хотя сам продукт в применении довольно прост. Кнопок вроде не много а вот количество вводных и выходных данных огромно.
Я думаю фундаментальная проблема этих подходов, это то, что интерфейс, и соответственно возможности для параметризирования и управления, с каждой наложеной сверху абстракцией сужаются.
И в классическом программировании это нам на руку, мы так ограждаем код от неправильного использования. Но если что, мы можем поправить то, что под капотом.
А в этих безкодовых инструментах, абстракции есть, а подкапотная часть вся проприетарная. И ты ее просто так не поправишь. В то время как производитель может быть не заинтересован в решении твоих частных проблем а сфокусирован на маркетинге. И сиди со своей проблемой до скончания времен. Можешь даже за саппорт заплатить, ведь воспользоваться ты им не сможешь, потому что проект, например, нельзя показывать третьим лицам.
Это то о чем покупателям не рассказывают.
Мое личное мнение - за простоту ты платишь свободой и гибкостью. А учитывая, что современный мир разработки сошелся на догме что "нет ничего более постоянного чем изменения" (см. аджайл), то гибкость имеет приоритет.
генерированный код и специфический код инструмента (допустим это какой-то xml) нормально не ревьюится. В одном инструменте мне попалась специальная функция чтобы делать мерджи. Т.е. разработчикам этих инструментов проблема тоже ясна. И от нее никуда не деться.
Кстати для себя вывел один способ ненавязчивого ревью документации. Берешь свою доку, и по ее оглавлению начинаешь с непосвещенными проходить материал с демонстрацией кода. Если дока хорошо структурирована, и четко сформулирована, то этото процесс пройдет плавно и сам по себе. Если же ты почуствуешь, что приходится делать отступления чтобы пояснить какие-то моменты, то вот это и есть дыры в документации.
А видимо я не правильно истолковал суть вопроса. Не собираюсь никому читать это. Так просто мысли в голове, как можно раскрутить простой практический пример и пройтись по важным фундаментальным темам. Чтобы разработать урок нужно серьезно сесть и все продумать, порядок, обьем. И вероятнее всего это будет серия уроков. Тоже смотря кому давать. Думаю тридцатилетним дядькам игра про угадывание чисел будет не очень, тогда нужно будет подобрать другой пример. Кстати на hyperskill.org мне понравилось, что они предлагают выбрать какое приложение ты хочешь строить и тогда переставляют модули в другом порядке. Интересный и, как мне кажется, правильный подход. Ну а так обучение программированию я думаю можно начинать ровно тогда когда по математике начинают проходить функции. Тут прям хорошая когнитивная синергия. Про результат, не совсем понимаю, что имеется ввиду, тут скорее нужно говорить не о результатах, а о целях обучающегося. А результат, т.е. успех обучения проверять на заданиях. Причем проверяется этими заданиями в первую очередь не как принято считать, успех учащегося, а успех обучающей программы. У тестов и контрольных мониторинговая функция а не фильтрирующая. Проверочная работа дается для того, чтобы понять какие концепции были усвоены лучше а какие хуже. Поэтому ставить оценку тесту вообще нелепость. Это получается выразить дельту знаний одной цифрой. Не зря ведь есть поговорка, что если учитель ставит двойку, он ставит ее себе. Хотя ладно, это я уже похоже с темы съехал порядком.
это у вас план на один урок? Или курс «простая программа угадывания чисел»?
я просто думаю что "хеллоу ворлд" не тот объем на котором можно объяснять программирование. А вот программа угадывания чисел она как минимум интерактивна и можно на ее примере затронуть много аспектов. Но достаточно проста, чтобы понять ее логическое устройство. Ну и еще на генераторе псевдослучайных чисел построена уйма игровых механик, тут такой простор для развития идей.
Буквально недавно с сыном обсуждали этот вопрос, отчего так сложно ему изучить 3д моделирование, или разработку в Unreal Engine, или монтаж видео в Premiere. И одним из факторов, как мне кажется является, недостаток дидактически правильно оформленного учебного материала. Тот учебный материал который в изобилии имеется в открытом доступе, часто является туториалом. "Повторяй за мной и у тебя получится то что, получилось у меня". Но по туториалу ты научишься делать только то, что в туториале. А не работе с программой. Ты почувствуешь свою беспомощность как только захочешь реализовать собственную задачу, готового решения которой не обсуждалось в туториале.
Научиться, это значит приобрести навыки принятия контекстных решений и правильного использования возможностей инструмента для достижения поставленой задачи. Научиться, это значит правильно декомпозировать задачу, и понять к какому сегменту задачи нужно применить какой подход. Научиться это понять фундаментальное устройство инструмента.
Поэтому я например не умею делать электросхемы, я принципиально не понимаю как взаимодействуют друг с другом электронные компоненты. Я понимаю что полупроводник проводит ток только в одну сторону. Но как из транзисторов, конденсаторов и сопротивлений получается радио, а если расположить их же по-другому, получается что-то еще, я просто не могу взять в толк. Несмотря на это по туториалу я мог бы спаять радиоприемник, но не научился бы электротехнике ни грамма.
Так вот, что значит дидактически правильно оформленный материал? Это такой материал который объясняет суть вещей.
Предположим у нас простая программа угадывания чисел.
Если мы ее декомпозируем, то я бы начал с обьяснения что есть операционная система, и приложение работает в ней. Есть система ввода вывода. Какими способами программа получает внешние данные из операционной системы. Какие могут быть данные. Это не только текст, это и другие переферийные устройства. Что есть системные библиотеки и одна из них может выводить данные на консоль, что эти системные библиотеки в любом языке завязаны на операционную систему, поэтому для каждой операционной системы мы скачиваем свой дистрибутив языка. Передача параметров в программу. Хранение данных в переменных. Потом обработка данных. Использование еще одной библиотеки для создания случайных чисел. Уже знаем две библиотеки. Тут можно сказать, что встроенных библиотек огромное множество и если придется то вот так и так можно найти ту что нужна для решения конкретной задачи. Показать как для этого пользоваться документацией к языку и библиотекам. Показать что все языки имеют такую документацию. Потом идут контрольные структуры, логические выражения. Рассказать о том как завершается программа. Что есть коды выхода. Потом дать задачу чтобы игру можно было начать игру заново не перезапуская ее. На примере этой задачи обьяснить цикл игры. По ходу дела обьяснить как читать ошибки и от чего они могут возникать. Как с помощью мысленного трейсинга понять причину ошибки. Потом дать пару задач на создание других интерактивных игр или расширить пример собиранием статистики. Или добавить угадывание кода на время. Рассказать что для работы со временем есть еще одна библиотека. И так далее.
Т.е. мы берем простой пример, но достаточный, чтобы на нем можно было столкнуться с типовыми задачами, всякими разными "почему" и "а что если". И тогда у человека будет целостное представление. Так устроен мозг. Нужно очертить горизонт, показать куда мы пойдем, тогда человек уже мысленно будет готов к тому, что его ждет и сможет знания разложить по полочкам. Еще хороший практический момент подсмотрел на вебинарах, это в начале дать план урока, а потом, после каждого пройденного этапа возвращаться к плану и показывать, что вот это мы только что прошли. Потому что часто презентации даются одним галопом, и теряется нить.
Я тоже за интегрированый подход. Стоишь на остановке можно растяжку какую нибудь делать, подниматься на ступнях например. Видел даже одного чувака он на железнодорожном перроне отжимался. Хорошо еще в трамвае никто не додумался подтягиваться на поручне :D
Но балансировать на ходу в автобусе или трамвае, когда загруженность позволяет, я сам люблю. И весело и полезно.
Какой резон постить спойлеры, да еще и о том что еще доподлинно неизвестно?
Скажите, простому обывателю Блютуз наверное известен прежде всего тем, что попытки соединить два устройства, например телефон к машине, превращаются в целое приключение с неизвестным концом. Может соединится, а может и нет. Например android телевизор Bravia от Sony хоть и имеет bluetooth поддержку, но не распознает ни колонки ни наушники. Причем выборочно. Думаю подобная ситуация, возможно с другими комбинациями устройств, знакома всем не по наслышке.
Так вот вопрос.
Отчего в принципе происходят такие проблемы? Это неправильно запрограммирован протокол на одном из устройств? Это принципиальная проблема самого протокола?
Клавиатуры, мыши ...
Причем читал, что можно подменить тип устройств. Если адрес останется прежним, то материнское устройство никак на это не прореагирует. Например, были наушники, а стали клавиатура. И погнали скрипты по типу Rubber Ducky крутить.
Нельзя вводить технологию не объясняя принцип ее устройства. Иначе у нас получится не обучение а курсы по технологии.
Эти навыки до сих пор востребованы на рынке (bootstrap, jQuery), значит это уровень проф. разработчика. Качество выполнения работы - скорее всего не будет дотягивать до рыночных стандартов, это да.
Ребенку важно не только показать, а объяснить. И это мы с 14-летним разбирали HTML, и то уже после получаса концентрированой работы мозга, "батарейка" села. А 9-летнему я вообще не представляю толком как это давать. Там человек только читать и писать научился. Хотя! Вот вспомнил, мы в прошлом году с младшим (8 лет) делали мини-проект на https://calliope.cc/ (обучающий одноплатинник, вроде micro:bit) и хоть ему было трудно все время следить за ходом создания проекта, сама идея сделать анимацию с музыкой его заинтересовала, и он подавал идеи. Но интерес возник тоже спонтанно и оказался непродолжительным. С другой стороны детективные загадки те же самые дети решают увлеченно и с удовольствием. Или играют в игры требующие логическокго упорядочивания действий.
И то, сейчас верстка уехала настолько вперед по сравнению с тем что было 10-20 лет назад.
Ребенок мне сказал: "а я хочу расположить текст в колонки, как на википедии". И все, уже нужно рассказывать про методы верстки на div-контейнерах. Т.е. то с чем дети будут сравнивать свой результат сильно продвинулось, и дать им что-то "простенькое" будет для них неудовлетворительным. А давать всё - могут потерять нить. Путь который нужно осмыслить от начала до результата удлиннился существенно.
Я расположил входные сигналы на 1,5,6,10, 11 и программа решила, что это похоже на "4", хотя 11 в четверке не возможна.
пример
Но, надо сказать, что это наглядно демонстрирует насколько сложной может быть настройка коэффициентов и что тестирование нейросетей совсем не тривиальная задача, хотя, казалось бы, это всего лишь математическая функция, которая проецирует одно множество на другое.
Количество подмножеств одного множества вычисляется по формуля 2 в степени n. Получается нам для полного покрытия этой функции понадобится 8192 проверки.
Показалось, что вы спроецировали моменты из статьи на какой-то свой прошлый негативный опыт.
Я бы копал в сторону т.н. Business Rules Engine
Мне эта задача видится как требующая решения на уровне архитектуры приложения. Если это фактически самое самое важное место в программе, вокруг которого вращается все, то я бы выделил его в независимую единицу с четким интерфейсом, грубо говоря "движок приложения" (есть шаблоны архитектурные для таких типовых задач), и покрыл бы юнит тестами так, чтобы мышь не проскочила.
Если, конечно, писать "сверху вниз" безо всякой архитектуры, тогда логика расползется по всему коду, будет нечитаемая каша, страх изменений и постоянный регресс. (Страх кстати и есть одна из причин ругани в команде). Дальнейший рефекторинг станет сложным. Интервалы релизов будут увеличиватсья. Тестирование превратится в гонку на время. По причине этого введут автоматизацию тестирования, которая не решит это проблему. Это перекладывание отсутствующих тестов с уровня кода (юнит-тесты) на уровень пользовательского интерфейса. Где они сложнее, и менее надежны по своей природе.
Это то, как не надо писать юзер стори. Почти все в этой шаблонной формулировке сущее вранье. Пользователь не хочет регистрироваться на сайте магазина, чтобы оформить заказ.
Пользователь хочет оформить заказ и, как правило, вынужден для этого проходить процесс регистрации. Не он хочет этого, этого хочет магазин. Для того чтобы выслать товар клиенту, владелец магазина хочет получить от клиента адресные данные и данные по оплате. (Для этого регистрация кстати не нужна). А регистрация нужна для того, чтобы хранить адресные данные и данные по оплате для последующих заказов. Либо же там есть какие-то удобные функции (типа истории заказов) которые привязаны к учетной записи. И эти случаи все нужно четко разграничить. Тогда у нас получатся разные истории: я новый клиент и хочу быстро оформить заказ, я постоянный клиент и при оформлении заказа не хочу каждый раз вводить одни и те же данные.
Юзер стори не содержит деталей реализации. Одна из функций юзер стори это, грубо говоря, прояснить в голове заказчика, а как же у него бизнес работает и как он взаимодействует с пользователем, зачем и почему, а также инициировать процесс осмысления и обсуждения.
Я понимаю, что это "всего лишь пример, и вообще не про это, а про именование", но из таких неверных примеров потом мы имеем тонны шаблонно написаных юзер стори от которых ни тепло ни холодно. Кстати и именование я бы сделал исходя из пользователя, а не функции. "новый клиент", "постоянный клиент". А для различения лучше написать отличительную особенность этой истории вместо цифр и аббревиатур, которые не несут в себе никакой полезной информации, кроме того что по цифрам можно сортировать в экселе. Для группировки по тематической области лучше потом уже к карточке "тег" прикрепить.
Интересно, конечно. С одной стороны у нас аджайл с его принципами
С другой стороны мы вводим формализацию и инструменты для ее автоматизации.
P.S.: Кстати, если смотреть на контрактную разработку то корпоративным заказчикам по факту важнее именно ценности справа, а не слева, хоть они и требуют чтобы их команды работали по аджайлу. Единственный принцип корпоративного аджайла это "прикрытие своей задницы важнее всего остального".
Тестирование калькуляторов - совсем нетривиальная задача.
Хотя сам продукт в применении довольно прост. Кнопок вроде не много а вот количество вводных и выходных данных огромно.
Я думаю фундаментальная проблема этих подходов, это то, что интерфейс, и соответственно возможности для параметризирования и управления, с каждой наложеной сверху абстракцией сужаются.
И в классическом программировании это нам на руку, мы так ограждаем код от неправильного использования. Но если что, мы можем поправить то, что под капотом.
А в этих безкодовых инструментах, абстракции есть, а подкапотная часть вся проприетарная. И ты ее просто так не поправишь. В то время как производитель может быть не заинтересован в решении твоих частных проблем а сфокусирован на маркетинге. И сиди со своей проблемой до скончания времен. Можешь даже за саппорт заплатить, ведь воспользоваться ты им не сможешь, потому что проект, например, нельзя показывать третьим лицам.
Это то о чем покупателям не рассказывают.
Мое личное мнение - за простоту ты платишь свободой и гибкостью. А учитывая, что современный мир разработки сошелся на догме что "нет ничего более постоянного чем изменения" (см. аджайл), то гибкость имеет приоритет.
генерированный код и специфический код инструмента (допустим это какой-то xml) нормально не ревьюится. В одном инструменте мне попалась специальная функция чтобы делать мерджи. Т.е. разработчикам этих инструментов проблема тоже ясна. И от нее никуда не деться.
Кстати для себя вывел один способ ненавязчивого ревью документации. Берешь свою доку, и по ее оглавлению начинаешь с непосвещенными проходить материал с демонстрацией кода. Если дока хорошо структурирована, и четко сформулирована, то этото процесс пройдет плавно и сам по себе. Если же ты почуствуешь, что приходится делать отступления чтобы пояснить какие-то моменты, то вот это и есть дыры в документации.
Раньше барыжили кожанками, вьетнамками и лосинами. Теперь барыжат общедоступными знаниями :)
А видимо я не правильно истолковал суть вопроса. Не собираюсь никому читать это.
Так просто мысли в голове, как можно раскрутить простой практический пример и пройтись по важным фундаментальным темам. Чтобы разработать урок нужно серьезно сесть и все продумать, порядок, обьем. И вероятнее всего это будет серия уроков. Тоже смотря кому давать. Думаю тридцатилетним дядькам игра про угадывание чисел будет не очень, тогда нужно будет подобрать другой пример.
Кстати на hyperskill.org мне понравилось, что они предлагают выбрать какое приложение ты хочешь строить и тогда переставляют модули в другом порядке. Интересный и, как мне кажется, правильный подход.
Ну а так обучение программированию я думаю можно начинать ровно тогда когда по математике начинают проходить функции. Тут прям хорошая когнитивная синергия.
Про результат, не совсем понимаю, что имеется ввиду, тут скорее нужно говорить не о результатах, а о целях обучающегося. А результат, т.е. успех обучения проверять на заданиях. Причем проверяется этими заданиями в первую очередь не как принято считать, успех учащегося, а успех обучающей программы. У тестов и контрольных мониторинговая функция а не фильтрирующая. Проверочная работа дается для того, чтобы понять какие концепции были усвоены лучше а какие хуже. Поэтому ставить оценку тесту вообще нелепость. Это получается выразить дельту знаний одной цифрой. Не зря ведь есть поговорка, что если учитель ставит двойку, он ставит ее себе. Хотя ладно, это я уже похоже с темы съехал порядком.
я просто думаю что "хеллоу ворлд" не тот объем на котором можно объяснять программирование. А вот программа угадывания чисел она как минимум интерактивна и можно на ее примере затронуть много аспектов. Но достаточно проста, чтобы понять ее логическое устройство. Ну и еще на генераторе псевдослучайных чисел построена уйма игровых механик, тут такой простор для развития идей.
Буквально недавно с сыном обсуждали этот вопрос, отчего так сложно ему изучить 3д моделирование, или разработку в Unreal Engine, или монтаж видео в Premiere.
И одним из факторов, как мне кажется является, недостаток дидактически правильно оформленного учебного материала. Тот учебный материал который в изобилии имеется в открытом доступе, часто является туториалом. "Повторяй за мной и у тебя получится то что, получилось у меня". Но по туториалу ты научишься делать только то, что в туториале. А не работе с программой. Ты почувствуешь свою беспомощность как только захочешь реализовать собственную задачу, готового решения которой не обсуждалось в туториале.
Научиться, это значит приобрести навыки принятия контекстных решений и правильного использования возможностей инструмента для достижения поставленой задачи. Научиться, это значит правильно декомпозировать задачу, и понять к какому сегменту задачи нужно применить какой подход. Научиться это понять фундаментальное устройство инструмента.
Поэтому я например не умею делать электросхемы, я принципиально не понимаю как взаимодействуют друг с другом электронные компоненты. Я понимаю что полупроводник проводит ток только в одну сторону. Но как из транзисторов, конденсаторов и сопротивлений получается радио, а если расположить их же по-другому, получается что-то еще, я просто не могу взять в толк. Несмотря на это по туториалу я мог бы спаять радиоприемник, но не научился бы электротехнике ни грамма.
Так вот, что значит дидактически правильно оформленный материал? Это такой материал который объясняет суть вещей.
Предположим у нас простая программа угадывания чисел.
Если мы ее декомпозируем, то я бы начал с обьяснения что есть операционная система, и приложение работает в ней. Есть система ввода вывода. Какими способами программа получает внешние данные из операционной системы. Какие могут быть данные. Это не только текст, это и другие переферийные устройства. Что есть системные библиотеки и одна из них может выводить данные на консоль, что эти системные библиотеки в любом языке завязаны на операционную систему, поэтому для каждой операционной системы мы скачиваем свой дистрибутив языка. Передача параметров в программу. Хранение данных в переменных. Потом обработка данных. Использование еще одной библиотеки для создания случайных чисел. Уже знаем две библиотеки. Тут можно сказать, что встроенных библиотек огромное множество и если придется то вот так и так можно найти ту что нужна для решения конкретной задачи. Показать как для этого пользоваться документацией к языку и библиотекам. Показать что все языки имеют такую документацию. Потом идут контрольные структуры, логические выражения. Рассказать о том как завершается программа. Что есть коды выхода. Потом дать задачу чтобы игру можно было начать игру заново не перезапуская ее. На примере этой задачи обьяснить цикл игры. По ходу дела обьяснить как читать ошибки и от чего они могут возникать. Как с помощью мысленного трейсинга понять причину ошибки. Потом дать пару задач на создание других интерактивных игр или расширить пример собиранием статистики. Или добавить угадывание кода на время. Рассказать что для работы со временем есть еще одна библиотека. И так далее.
Т.е. мы берем простой пример, но достаточный, чтобы на нем можно было столкнуться с типовыми задачами, всякими разными "почему" и "а что если". И тогда у человека будет целостное представление. Так устроен мозг. Нужно очертить горизонт, показать куда мы пойдем, тогда человек уже мысленно будет готов к тому, что его ждет и сможет знания разложить по полочкам. Еще хороший практический момент подсмотрел на вебинарах, это в начале дать план урока, а потом, после каждого пройденного этапа возвращаться к плану и показывать, что вот это мы только что прошли. Потому что часто презентации даются одним галопом, и теряется нить.