Какое-либо практическое кодирование dojo/kata идеи?

Возможно, вы сможете взглянуть на Ruby Quiz материал для вдохновения.

Большинство примеров программирования в моем блоге, по сути, являются упражнениями по кодированию додзё. В частности, серия матриц , а также головоломки и 99 пиво . Теперь не стоит пренебрегать матричными рядами как "математическими", так как проблемы, к которым я отношусь, связаны с построением классов в Scala, а не с выполнением фантастических алгоритмов. На самом деле, я практически пропускаю сами математические алгоритмы.

Сейчас 99 Проблемы Скалы и практически все из Project Euler являются хорошими упражнениями для функциональной части Скалы, но я понимаю это не для того, чтобы быть вашим акцентом. Я рекомендую retronym's answer. Код Розетты , не будучи функционально ориентированным, может иметь более общие примеры. С примерами Scala, конечно, много, хотя, возможно, вы захотите рассмотреть и другие задачи, для идей.

Есть много интересных вещей, которые можно узнать о Scala, но нужно быть осторожным на начальном уровне. Например, я бы не стал говорить об инъекции зависимостей (самотипы и паттерн пирога) или о классах типов (паттерн, который имитирует их с имплицитами).

Посмотрите также материал на сайте Scala Lang, в частности на документ Scala by Example.

EDIT

Я сейчас просмотрел несколько додзёй Scala, так что вот кое-что, чему я научился тогда:

• Проблемы: они должны быть веселыми, не-квит-легкими, не-трудными, и это должно быть мнение каждого .

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

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

• Знание скалы: оказывается, не так уж важно заранее ввести ключевые понятия языка скалы, особенно если некоторые из участников имеют базовые знания.

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

• Преподавание скалы: если вы решили преподавать скалу, держите уроки короткими и следуйте додзё. В этом случае, держите набор проблем додзё, адекватных уроку, и, в зависимости от того, сколько уроков вы хотите за один день, короткими.

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

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

На данный момент мы используем формат Randori Kata, но без фиксированного времени и перерыва, и с ретроспективой в конце додзё, а не в начале следующего. Это, однако, это просто то, на чем мы сейчас находимся - мы экспериментировали со многими вариациями, и мы все еще эволюционируем.