До этого они балуются в автоматическом тренажере - решают крохотные задачки на создание отдельных функций или даже кусков кода.
Так что "да" - это их первый реальный код. Им почти бесконечно сложно все сразу: и Питон, и ООП, и Гитхаб, и IDE - а еще и над логикой и дизайном игры нужно думать.
Это будет уже не "оверхед", а чистый "кыш отсюда" для большей части студентов. Ведь многие приходят совсем зеленые (вот как Марина в статье).
Курс рассчитан на постепенное погружение в настоящую разработку - после года обучения они уже все перечисленное: requirements.txt, ридми, линтеры и даже больше - понимают и применяют.
А в первом проекте это не нужно. Лучше не пугать, а мотивировать на обучение.
Если бы мне доверили - я точно бы заставлял делать Пентамино. Сам на разных языках писал - очень помогает понимать где в языке засада по нагрузочным вычислениям.
Есть примитивное дерево из классов для фигур, которые можно показывать: общий базовый, наследник Яблоко, наследник Змея. Метод для отрисовки фигуры лежит в базовом, а реализован в каждом из наследников.
ложная идея, что CudaText это Sublime, только лучше
Я каждый день пользуюсь CudaText и вижу, что для меня он лучше Sublime. Несколько раз пробовал пересесть и ни разу не получилось улучшить рабочую среду. И, что важно, я не пытаюсь утверждать, что Sublime и vim не нужны.
В статье нет посыла "CudaText лучше Sublime". Лишь перечислены идеи для улучшения Sublime. Да, идеи опробованы внутри CudaText, это лишь придает им больше веса и рекламирует CudaText на фоне Sublime.
Полностью согласен. Но нигде не вижу, чтобы в комментариях это кто-то оспаривал. Вы пытаетесь жестко доказать, что идеи из статьи вам не подходят. А никто их вам и не пытается навязать. Речь была, про то, что «скорее всего, найдется много пользователей, кому это будет удобно».
Про «мышь только мешает». Вы не угадали. Такого предположения мы с Алексеем не делали.
Про «инструмент для юникод-символов». Спасибо за ссылку, поизучаем.
Про «в этом вашем». Постарайтесь избегать подобного тона.
Про «vim». В Cuda нет такого, и много еще чего нет. Это не мешает его пользователям.
Да, замечательная вещь — доп.потоки у файлов. Давно на них облизываюсь. Например, удобно хранить в них всю историю изменений файла, то есть данные для undo/redo. Но теги — нет, так как к ним имхо нужен ручной простой независимый доступ.
(Учтите, что я тут про теги пишу как диванный аналитик. Это не у меня, а у ovsale есть программа для работы с тегами)
Мягкие и жесткие ссылки в Файловой Системе дают для некоторых файлов альтернативные пути хранения. Дерево превращается в Сеть. Но, насколько я знаю, у пользователя нет простого способа увидеть и использовать все эти альтернативы, если он видит конкретный файл. Если в пути к файлу одна из промежуточных папок (в том числе и последняя) станет результатом новой ссылки, описание файла никак не изменится.
То есть ссылки — это исключительно про папки.
А теги — это про свойства файлов.
Обычная иерархия файлов — это один из способов для их структурирования.
Поскольку файлов часто очень много (например, у меня на С-диске 640К/83К файлов/папок), полезной будет почти любая дополнительная система доступа. Предлагаемые ovsale теги — это как раз про это. То что его теги образуют дерево, особенность реализации. Это полезно для манипуляций, но имеет обычные проблемы всех "каталогов": единственность родителя входит в противоречие с интуитивными связями между тегами.
В идеале, хотелось бы иметь СУБД, в которой у файлов кроме атрибутов "имя", "тип", "папка" были наборы произвольных свойств и поиск по ним. Теги стали бы одним из таких свойств.
До этого они балуются в автоматическом тренажере - решают крохотные задачки на создание отдельных функций или даже кусков кода.
Так что "да" - это их первый реальный код. Им почти бесконечно сложно все сразу: и Питон, и ООП, и Гитхаб, и IDE - а еще и над логикой и дизайном игры нужно думать.
Это будет уже не "оверхед", а чистый "кыш отсюда" для большей части студентов. Ведь многие приходят совсем зеленые (вот как Марина в статье).
Курс рассчитан на постепенное погружение в настоящую разработку - после года обучения они уже все перечисленное: requirements.txt, ридми, линтеры и даже больше - понимают и применяют.
А в первом проекте это не нужно. Лучше не пугать, а мотивировать на обучение.
Если бы мне доверили - я точно бы заставлял делать Пентамино.
Сам на разных языках писал - очень помогает понимать где в языке засада по нагрузочным вычислениям.
И еще алгоритмические скилы прокачивает.
Ага. Так и происходит
Ох! Десятки их!
Чего только не выдумывают. Хорошо известно, что новички выдумывают такое, что опытным никогда в голову не придет.
Но если змея бегает и ест яблоки, то все это считается правильным.
Есть примитивное дерево из классов для фигур, которые можно показывать: общий базовый, наследник Яблоко, наследник Змея. Метод для отрисовки фигуры лежит в базовом, а реализован в каждом из наследников.
На Win-ноуте не видит штатную клавиатуру после скачивания портабельной версии. Это нормально?
Полностью согласен. Но нигде не вижу, чтобы в комментариях это кто-то оспаривал. Вы пытаетесь жестко доказать, что идеи из статьи вам не подходят. А никто их вам и не пытается навязать. Речь была, про то, что «скорее всего, найдется много пользователей, кому это будет удобно».
Это многое проясняет — вы не попадаете в целевую группу. У тех, кто не может пользоваться vim, отношения с Cuda/Sublime складываются удачнее.
Про «инструмент для юникод-символов». Спасибо за ссылку, поизучаем.
Про «в этом вашем». Постарайтесь избегать подобного тона.
Про «vim». В Cuda нет такого, и много еще чего нет. Это не мешает его пользователям.
Да, можно завести свои спецподстановки в регулярки. Теперь голова начнет переваривать эту идею.
Но ваш пример мне не понятен. Что можно упростить, в какой регулярке?
Нигде в основном тексте явно не было указано — имейте ввиду, что мой плагин ищет только внутри отдельных строк.
Да, замечательная вещь — доп.потоки у файлов. Давно на них облизываюсь. Например, удобно хранить в них всю историю изменений файла, то есть данные для undo/redo. Но теги — нет, так как к ним имхо нужен ручной простой независимый доступ.
(Учтите, что я тут про теги пишу как диванный аналитик. Это не у меня, а у ovsale есть программа для работы с тегами)
Мягкие и жесткие ссылки в Файловой Системе дают для некоторых файлов альтернативные пути хранения. Дерево превращается в Сеть. Но, насколько я знаю, у пользователя нет простого способа увидеть и использовать все эти альтернативы, если он видит конкретный файл. Если в пути к файлу одна из промежуточных папок (в том числе и последняя) станет результатом новой ссылки, описание файла никак не изменится.
То есть ссылки — это исключительно про папки.
А теги — это про свойства файлов.
ovsale Правильно я понял, что у вас теги имеют не более одного родителя? (смотрите мой пост "Обычная иерархия файлов — это...")
Обычная иерархия файлов — это один из способов для их структурирования.
Поскольку файлов часто очень много (например, у меня на С-диске 640К/83К файлов/папок), полезной будет почти любая дополнительная система доступа. Предлагаемые ovsale теги — это как раз про это. То что его теги образуют дерево, особенность реализации. Это полезно для манипуляций, но имеет обычные проблемы всех "каталогов": единственность родителя входит в противоречие с интуитивными связями между тегами.
В идеале, хотелось бы иметь СУБД, в которой у файлов кроме атрибутов "имя", "тип", "папка" были наборы произвольных свойств и поиск по ним. Теги стали бы одним из таких свойств.
Можете описать подробнее "и т.п."?
Все средства хороши. Я тоже не упускаю возможности искать в ТС и/или из командной строки.
Подумаю над этим. Потребуется более глубокое взаимодействие с лексером. Интересная тема.