Рассматривайте вид как шаблонизатор. В нём не объявляется новых переменных и он может работать только с уже переданными данными.
Модель хранит всю информацию о данных. Включая, например, правила валидации и SQL.
Но вся логика и операции происходят в контроллерах. Например, сама валидация данных в соответствии с моделью.
Контроллер будет ядром системы и не будет захламлён, например, SQL-запросами.
Что лично я встречал чаще всего — это то, что программисты внезапно переходят от MVC к привычному им подходу. Без предупреждения, просто начинают клепать какие-то уберклассы, которые объявлены как модели, но вместе с тем работают как контроллеры и ещё умудряются управлять представлением данных. Вот это — реально проблема. А различные трактовки MVC всегда можно согласовать.
По поводу Windows и Apache+PHP+MySQL, что бы Вы предложили?
Я бы предложил не пихать в курс по Kohana инструкции по настройке PHP, MySQL и вебсервера. Это — отдельная тема, которую можно (если стоит) описать отдельно.
В-третьих, считаю, что писать код по мере записи видеоуроков в образовательном плане очень правильно. Будет виден и процесс отладки, и допускаемые ошибки, что, в свою очередь, очень важно.
В-четвертых, Вы действительно невнимательно смотрели видеоуроки, потому что, на сколько я понимаю, Вам и так все это известно. Поэтому в видеокурсе для Вас остались только минусы и ничего полезного. А вот если бы Вы внимательно отнеслись к продукту, прежде чем его критиковать, то нашли бы и код, выложенный на моем блоге и поняли, что я разрабатываю образовательную систему для публикации учебных материалов (я об этом в первом видео рассказывал).
Я невнимательно смотрел эти многочасовые уроки, потому что мне было скучно. Не только потому что я знаю, как это можно написать, даже лучше. Это просто скучно. Несколько часов внимания зрителя тратятся на показ, как автор пишет код, а потом исправляет свои ошибки. Что должен делать зритель? Писать ошибочный код вслед за учителем, а затем так же, следя по кадрам, исправлять в нём баги или просто смотреть видео, вникая в долгий процесс Зен-отладки и постигая, как же именно ощущает себя великий программист? Смотреть видео намного тяжелее, чем читать
Вы читали книги по программированию? Там даётся сразу рабочий код, а потом он комментируется. Чуть ли не по буквам. Если и даётся нарочно ошибочный код, ошибка одна и кусок кода не такой большой. Чтобы у ученика оставался хотя бы шанс найти эту ошибку и чтобы не загружать ему голову. Здесь вы тащите его за собой через горы буреломов, заставляя следить за каждым шагом. Попутно, кстати, обучая самому тупому из подходов к программированию: эволюционному. Это именно подход проб и ошибок, когда даже самому автору неясно, что будет в итоге — он просто делает новые фичи, не задумываясь раньше момента, когда придётся.
Насчёт кода, выложенного на вашем блоге. Я говорил не о кусочках кода, а о полном дампе. То есть, полностью весь сайт, который получился на данном этапе (это такой архивчик со всеми файлами, все папки application, system и modules) и дамп базы (SQL код, при помощи которого можно получить копию). Чтобы ученик мог во-первых, проверить себя, во-вторых, взять готовый сайт с исправленными ошибками и просмотреть все видео, в-третьих, взять готовый сайт с исправленными ошибками и посмотреть не все видео (а только те которые интересуют)… Можно придумать много сценариев, в которых полный код пригодился бы, но главное — одно: он нужен. Он нужен даже профессионалам, которые начинают программировать на Kohana и хотят посмотреть на пример рабочего приложения.
Я просто предлагаю вам немного продумать ваши видео. Составить план разработки — что именно вы делаете и что вам там потребуется. Давать заранее приготовленный рабочий код — не обязательно уже написанный, но очищенный от багов. Идти не от чистого листа, а от уже готового сайта, показывая, как он строился. Не распыляться на смежные темы, вроде настройки веб-сервера или вёрстки в HTML и CSS. Не говорить лишних слов, правильно произносить и использовать термины (ну нет такой вещи, как почти человекопонятное URL), тратить заранее время на придумывание названий методов… Иначе вам придётся сделать намного больше работы, записав ещё несколько видео, в которых вы будете разбирать свои же ошибки, допущенные ранее. И ещё несколько видео, в которых вы будете разбирать ошибки предыдущих. И так далее, пока вам не надоест.
Мораль: даже курсы для начинающих не должны делаться на коленке. Более того: они должны быть максимально корректными и безошибочными, потому что ваши зрители не могут исправить за вас ваши же ошибки. Не стоит пренебрежительно относиться к вашей аудитории.
Почему не подумают о тех кто приобрел MS Windows официально (по собственному желанию или принудительно в придачу при покупке нового компьютера)?
Потому что:
Установить Windows с уже вшитыми в неё нужными программами и сохранить лицензию не получится
На любой GIMP найдётся Photoshop, который школьники принесут из дома
Покупка винды в школе заставит купить винду всем школьникам. Это миллионы денег, которые просто утекут из страны. Линукс во-первых, бесплатен, а во-вторых, к загранице можно и не обращаться.
Я, конечно, извиняюсь, но такие уроки никому бы не посоветовал.
Во-первых, видео не так важно, как КОД. Текст и примеры кода. Смотреть на то, как вы его набираете, совершенно необязательно, тем более что на видео не так много можно прочитать. К тому же, не у всех стоит Windows, не все пользуются именно такими редакторами, не все будут морочиться с Apache+PHP+MySQL (XAMPP вполне позволяет понять, что такое хостинг)… Люди, которые интересуются Kohana, вряд ли не знают, что такое PHP и как на нём писать, текста им достаточно. Они могут понять, как настроить веб-сервер и создать файл в нужном каталоге.
Во-вторых, потому что в видео очень много лишнего. Особенно в голосе. Слайды у вас полупустые, а голос только бубнит про то, что хочет спать и что он копирует одни строчки в другие строчки. При этом видно, что код пишется по мере записи видео, море времени уходит на отладку, ещё и произношение неправильное (Views читается как вьюс, а лучше вообще их называть видами). Для того, чтобы просмотреть все уроки, придётся потратить несколько часов. Для сравнения, несколько статей с кусками нужного кода читаются минут за 15.
В-третьих, потому что просто ТАК программировать на Kohana нельзя. Вспоминать про HMVC в пятнадцатом видео не просто поздновато, а уже пора всё выкидывать и переписывать с нуля. Например, из-за этого вы совершенно оставили без внимания Request и вместо этого наплодили видов (в смысле View). Совершенно неудобный подход — каждый раз, когда надо что-то добавить, лезть в вид И контроллер, чтобы передать в вид новую переменную с новым видом. Для того, чтобы переписать красиво и понятно всё то, что советовалось за все 15 уроков, понадобится ещё 15 уроков.
В-четвёртых, а что вы вообще пишете в этих уроках? Код на сайте (полный код полученного сайта, а не кусочки из видео) вы не выкладываете, о цели не говорите. Что должно получиться? Я не очень внимательно смотрел видюшки, но из текстовых описаний совершенно ничего не понятно. Там должна быть админка, разграничение прав и восстановление пароля. Ага. Ещё отправка почты. Угу. Значит, там должно быть много разных пользователей с разными правами, и они будут заниматься… чем? Неизвестно. Направление разработки выбирается случайным образом или всё-таки в голове есть идея, ради чего пишется этот код?
Верите, нет — не пользовался. На всех компах, которые я встречал, стоит в лучшем случае office 2007. А обычно так вообще 2003, и владельцы шипят при упоминании DOCX.
У самого стоит openOffice.
У меня нет Mac OS X. А между «можно сделать» и «включено по умолчанию» разница велика. В Word тоже можно делать красивые документы, только вот надо на это потратить уйму времени. Он даже переносы не проставит, пока не заставишь!
Экспорт в PDF из Word & Powerpoint делать сложно.
Для внедрения TeX'овских формул в PowerPoint вам понадобится сам PowerPoint (который, я напомню, стоит денег) и TeX.
Если вы делаете слайды сразу в TeX'е, то вам нужен только он (бесплатный) и ничего более.
К тому же, делать слайды на основе каких-нибудь научных работ, написанных в TeX, намного проще в том же TeX'е, потому что можно копипастить, а не набирать всё заново.
Если вы делаете презентации в OpenOffice или Microsoft Office, вам придётся думать над совместимостью. Как открыть PPTX, ODP и PPT на чужом компьютере? LaTeX генерирует PDF, проблем с этим форматом не возникает никогда.
А уж о том, как выглядит текст в различных офисах… В общем, что-то вроде этого ни один пакет для презентаций не сможет сделать:
Вы опять про MMORPG, я говорю о простом мультиплеере когда в одной игре может играть 2-8 человек.
Я для примера. На самом деле, любые игры штамповать нельзя. А простой мультиплеер тоже потребует писать бэкенд.
Фактически в тот же INSTEAD можно добавить поддержку сетевых игр, когда к изменению в игровом мире приводят действия не только одного человек но группы лиц.
Во-первых, это надо такую игру сначала сделать. Потому что играть в однопользовательские игры толпой пробовали и на ClubFloyd, и на Sarien. Либо все управляют одним персонажем и воюют за действия, либо начинается дурдом. Впрочем, дурдом всё равно неизбежен, если автор игры не предполагал 8 человек вместо одного.
Во-вторых, «поддержка сетевых игр» — это совершенно размытое понятие. Возможность связываться с Интернетом? В INSTEAD есть с момента основания. Берёте модуль Lua::Net и используете как заблагорассудится. Только игроку тоже надо поставить будет, и всё.
> Я представить себе не могу кнопку Like в игре, которая бы не ломала атмосферы.
Не в игре, а в списке игр или в карточке игры, но не в процессе игры.
Тогда какое отношение эта кнопочка имеет к игре? Никакого. Игра может быть и оффлайновой. Кнопочки же в ней в любом случае нету. Мы же сейчас говорим о самой игре, а не о том, как её презентовать.
По моему правка опечаток/оборотов в тексте/картинок вообще процесс вечный и бесконечный, но если авто обновления есть то вопрос снимается.
Правка опечаток должна, по-хорошему, производиться перед релизом простым нажатием F7. Остальное правится за неделю-две после бета-теста или релиза: благодарные игроки легко согласятся помочь. Но всё когда-нибудь кончается. Через месяц вы вряд ли вернётесь к этой игре, она уже уйдёт в архив — если, конечно, будет доделана. Вывод игры в онлайн не спасёт вас от проблемы недоделывания игр до конца, он позволит вам не обращать внимания на неё.
Мультиплеерная игра это не обязательно MMO
В любом случае, ей нужен самописный frontend и совершенно точно — уникальный backend. Просто потому что рисовать онлайн-игры пачками и потом ещё как-то брать ими рынок могут только корейцы. Исключение составляют текстовые MUD'ы: там действительно есть готовые движки для этих MMORPG, которые можно брать и допиливать в любом направлении (или так ставить).
К счастью за последние несколько лет ситуация с версткой изменилась в лучшую сторону и грубых персонифицированных косяков становится все меньше. К тому же есть Flash.
Flash не каждый пользователь держит и тем более — обновляет. К тому же, он довольно медлителен. От Flash постепенно уходят в сторону HTML 5 и Javascript. А там без костылей ничто серьёзное не взлетит.
Ну и кроме того веб интереснее мейнстримом. На оффлайновое приложение не поставишь кнопки лайк соц., сетей. В оффлайн приложении не сделаешь рейтингов пользователей прошедших игру (по разным срезам) и их комментарии и ощущения от этого. Точнее все это есть но оно размазано по уйме форумов, блогов и персональных сайтов.
Я представить себе не могу кнопку Like в игре, которая бы не ломала атмосферы. Или вот такой сюжет. Я — Великий Варвар Конунг, пришёл и убил Вождя Орков, беру его корону… и тут же мне показывают список великих варваров Конунгов, которые сделали это быстрее и изощрённее… Выглядит как издевательство. Оно действительно нужно именно в самой игре? Не на сайте игры?
Опять веб это более низкой порог входа — одно дело что то качать другое дело кликнуть и начать, а еще лучше в виде игры к соц., сети.
С этим согласен на все сто. Не зря QSP вышел в Контакт. Это — действительно плюс онлайн-игр.
Вообще, на самом деле загадка про лошадей в игре вообще как таковая не существует. Вопрос и варианты ответов генерируются случайно, надо только понять закономерность.
Видите ли, если бы люди могли понимать мыслеобразы лошадей, то конная упряжь была бы изобретена позднее, и григорианский календарь (а по вариантам ответа можно понять, что имеется в виду именно он) начинал бы отсчёт с шестого года н.э.
Это всё объясняется в игре, посмотрите. :-)
Модель хранит всю информацию о данных. Включая, например, правила валидации и SQL.
Но вся логика и операции происходят в контроллерах. Например, сама валидация данных в соответствии с моделью.
Контроллер будет ядром системы и не будет захламлён, например, SQL-запросами.
Что лично я встречал чаще всего — это то, что программисты внезапно переходят от MVC к привычному им подходу. Без предупреждения, просто начинают клепать какие-то уберклассы, которые объявлены как модели, но вместе с тем работают как контроллеры и ещё умудряются управлять представлением данных. Вот это — реально проблема. А различные трактовки MVC всегда можно согласовать.
Я бы предложил не пихать в курс по Kohana инструкции по настройке PHP, MySQL и вебсервера. Это — отдельная тема, которую можно (если стоит) описать отдельно.
Я невнимательно смотрел эти многочасовые уроки, потому что мне было скучно. Не только потому что я знаю, как это можно написать, даже лучше. Это просто скучно. Несколько часов внимания зрителя тратятся на показ, как автор пишет код, а потом исправляет свои ошибки. Что должен делать зритель? Писать ошибочный код вслед за учителем, а затем так же, следя по кадрам, исправлять в нём баги или просто смотреть видео, вникая в долгий процесс Зен-отладки и постигая, как же именно ощущает себя великий программист? Смотреть видео намного тяжелее, чем читать
Вы читали книги по программированию? Там даётся сразу рабочий код, а потом он комментируется. Чуть ли не по буквам. Если и даётся нарочно ошибочный код, ошибка одна и кусок кода не такой большой. Чтобы у ученика оставался хотя бы шанс найти эту ошибку и чтобы не загружать ему голову. Здесь вы тащите его за собой через горы буреломов, заставляя следить за каждым шагом. Попутно, кстати, обучая самому тупому из подходов к программированию: эволюционному. Это именно подход проб и ошибок, когда даже самому автору неясно, что будет в итоге — он просто делает новые фичи, не задумываясь раньше момента, когда придётся.
Насчёт кода, выложенного на вашем блоге. Я говорил не о кусочках кода, а о полном дампе. То есть, полностью весь сайт, который получился на данном этапе (это такой архивчик со всеми файлами, все папки application, system и modules) и дамп базы (SQL код, при помощи которого можно получить копию). Чтобы ученик мог во-первых, проверить себя, во-вторых, взять готовый сайт с исправленными ошибками и просмотреть все видео, в-третьих, взять готовый сайт с исправленными ошибками и посмотреть не все видео (а только те которые интересуют)… Можно придумать много сценариев, в которых полный код пригодился бы, но главное — одно: он нужен. Он нужен даже профессионалам, которые начинают программировать на Kohana и хотят посмотреть на пример рабочего приложения.
Я просто предлагаю вам немного продумать ваши видео. Составить план разработки — что именно вы делаете и что вам там потребуется. Давать заранее приготовленный рабочий код — не обязательно уже написанный, но очищенный от багов. Идти не от чистого листа, а от уже готового сайта, показывая, как он строился. Не распыляться на смежные темы, вроде настройки веб-сервера или вёрстки в HTML и CSS. Не говорить лишних слов, правильно произносить и использовать термины (ну нет такой вещи, как почти человекопонятное URL), тратить заранее время на придумывание названий методов… Иначе вам придётся сделать намного больше работы, записав ещё несколько видео, в которых вы будете разбирать свои же ошибки, допущенные ранее. И ещё несколько видео, в которых вы будете разбирать ошибки предыдущих. И так далее, пока вам не надоест.
Мораль: даже курсы для начинающих не должны делаться на коленке. Более того: они должны быть максимально корректными и безошибочными, потому что ваши зрители не могут исправить за вас ваши же ошибки. Не стоит пренебрежительно относиться к вашей аудитории.
Потому что:
Во-первых, видео не так важно, как КОД. Текст и примеры кода. Смотреть на то, как вы его набираете, совершенно необязательно, тем более что на видео не так много можно прочитать. К тому же, не у всех стоит Windows, не все пользуются именно такими редакторами, не все будут морочиться с Apache+PHP+MySQL (XAMPP вполне позволяет понять, что такое хостинг)… Люди, которые интересуются Kohana, вряд ли не знают, что такое PHP и как на нём писать, текста им достаточно. Они могут понять, как настроить веб-сервер и создать файл в нужном каталоге.
Во-вторых, потому что в видео очень много лишнего. Особенно в голосе. Слайды у вас полупустые, а голос только бубнит про то, что хочет спать и что он копирует одни строчки в другие строчки. При этом видно, что код пишется по мере записи видео, море времени уходит на отладку, ещё и произношение неправильное (Views читается как вьюс, а лучше вообще их называть видами). Для того, чтобы просмотреть все уроки, придётся потратить несколько часов. Для сравнения, несколько статей с кусками нужного кода читаются минут за 15.
В-третьих, потому что просто ТАК программировать на Kohana нельзя. Вспоминать про HMVC в пятнадцатом видео не просто поздновато, а уже пора всё выкидывать и переписывать с нуля. Например, из-за этого вы совершенно оставили без внимания Request и вместо этого наплодили видов (в смысле View). Совершенно неудобный подход — каждый раз, когда надо что-то добавить, лезть в вид И контроллер, чтобы передать в вид новую переменную с новым видом. Для того, чтобы переписать красиво и понятно всё то, что советовалось за все 15 уроков, понадобится ещё 15 уроков.
В-четвёртых, а что вы вообще пишете в этих уроках? Код на сайте (полный код полученного сайта, а не кусочки из видео) вы не выкладываете, о цели не говорите. Что должно получиться? Я не очень внимательно смотрел видюшки, но из текстовых описаний совершенно ничего не понятно. Там должна быть админка, разграничение прав и восстановление пароля. Ага. Ещё отправка почты. Угу. Значит, там должно быть много разных пользователей с разными правами, и они будут заниматься… чем? Неизвестно. Направление разработки выбирается случайным образом или всё-таки в голове есть идея, ради чего пишется этот код?
У самого стоит openOffice.
Экспорт в PDF из Word & Powerpoint делать сложно.
Если вы делаете слайды сразу в TeX'е, то вам нужен только он (бесплатный) и ничего более.
К тому же, делать слайды на основе каких-нибудь научных работ, написанных в TeX, намного проще в том же TeX'е, потому что можно копипастить, а не набирать всё заново.
Если вы делаете презентации в OpenOffice или Microsoft Office, вам придётся думать над совместимостью. Как открыть PPTX, ODP и PPT на чужом компьютере? LaTeX генерирует PDF, проблем с этим форматом не возникает никогда.
А уж о том, как выглядит текст в различных офисах… В общем, что-то вроде этого ни один пакет для презентаций не сможет сделать:
Я для примера. На самом деле, любые игры штамповать нельзя. А простой мультиплеер тоже потребует писать бэкенд.
Во-первых, это надо такую игру сначала сделать. Потому что играть в однопользовательские игры толпой пробовали и на ClubFloyd, и на Sarien. Либо все управляют одним персонажем и воюют за действия, либо начинается дурдом. Впрочем, дурдом всё равно неизбежен, если автор игры не предполагал 8 человек вместо одного.
Во-вторых, «поддержка сетевых игр» — это совершенно размытое понятие. Возможность связываться с Интернетом? В INSTEAD есть с момента основания. Берёте модуль Lua::Net и используете как заблагорассудится. Только игроку тоже надо поставить будет, и всё.
Тогда какое отношение эта кнопочка имеет к игре? Никакого. Игра может быть и оффлайновой. Кнопочки же в ней в любом случае нету. Мы же сейчас говорим о самой игре, а не о том, как её презентовать.
Правка опечаток должна, по-хорошему, производиться перед релизом простым нажатием F7. Остальное правится за неделю-две после бета-теста или релиза: благодарные игроки легко согласятся помочь. Но всё когда-нибудь кончается. Через месяц вы вряд ли вернётесь к этой игре, она уже уйдёт в архив — если, конечно, будет доделана. Вывод игры в онлайн не спасёт вас от проблемы недоделывания игр до конца, он позволит вам не обращать внимания на неё.
В любом случае, ей нужен самописный frontend и совершенно точно — уникальный backend. Просто потому что рисовать онлайн-игры пачками и потом ещё как-то брать ими рынок могут только корейцы. Исключение составляют текстовые MUD'ы: там действительно есть готовые движки для этих MMORPG, которые можно брать и допиливать в любом направлении (или так ставить).
Flash не каждый пользователь держит и тем более — обновляет. К тому же, он довольно медлителен. От Flash постепенно уходят в сторону HTML 5 и Javascript. А там без костылей ничто серьёзное не взлетит.
Я представить себе не могу кнопку Like в игре, которая бы не ломала атмосферы. Или вот такой сюжет. Я — Великий Варвар Конунг, пришёл и убил Вождя Орков, беру его корону… и тут же мне показывают список великих варваров Конунгов, которые сделали это быстрее и изощрённее… Выглядит как издевательство. Оно действительно нужно именно в самой игре? Не на сайте игры?
С этим согласен на все сто. Не зря QSP вышел в Контакт. Это — действительно плюс онлайн-игр.
Это всё объясняется в игре, посмотрите. :-)