В този документ ще събираме някои указания, които да ви насочат в избора на тема и в писането на вашите проекти към курса "Програмиране с Ruby".
Тъй като за добро или лошо това е една от най-предпочитаните теми, трябва да обърнем внимание, че Ruby и екосистемата около него не са най-подходящите инструменти за разработване на игри. Това личи най-малко по факта, че няма изобилие от графични и 3D-библиотеки, които да са активно разработвани. Може би най-близо до целта попада gosu. Писането на игра, която е GUI-intensive не е добра идея. Писането на по-простички игри, които могат да имат и command-line интерфейс е приемливо. Причината за тази препоръка, освен споменатата по-рано, е и че не искаме проектът ви да се върти около интерфейса, а по-скоро обратното – интерфейсът да е дребна притурка към логиката на играта.
Когато сте избрали да пишете неща, наподобяващи игри — или каквито и да е други проекти, изискващи сериозно GUI — е много важно да "откачите" основния си код максимално много от рисуването/графиката/GUI-то. Целта ви е да имате много ясно разделение и абстракция между "ядрото" на вашия проект и графичния му интерфейс. Добре би било основната логика на проекта ви да се намира изцяло в "ядрото", под формата на класове, модули и прочее, като това ядро предоставя на своите позлватели някакво API. Тоест, стремете се да пишете въпросното ядро все едно пишете библиотека, която ще се преизползва в друг(и) софтуер(и). От там нататък, GUI-то се прави като wrapper на тази библиотека, ползва публичното й API и е един вид pluggable компонент към нея.
Поради гореизброените причини, за всички игри е задължително да имплементирате повече от един UI – например един конзолен и един графичен. Единствено тогава ще разберете истинската стойност на необходимостта от разделение между логика и интерфейс и единствено тогава ще може да проверите дали сте се справили с тази задача. Допускат се само индивидуални изключения, ако изрично сме се разбрали с вас за това предварително.
В някои случаи, можете да минете и само с кода от основното ядро, който имплементира функционалност без GUI, ако сте писали обилно тестове. Този проект е подходящ шанс за вас да пробвате подхода TDD. Допълнително, това ще ви помогне да покриете едно от изискванията, а именно да имате пълно покритие с unit тестове.
Разбира се, ако държите да дълбаете в посока графичен интерфейс, било то двуизмерно или триизмерно чертане, няма да ви спрем – все пак е важно и да се забавлява човек от време на време :) Просто имайте предивд, че това няма да придаде тежест на проекта ви.
Базирайки се на трагичния опит с ваши Rails проекти от минали години, сме принудени за ваше добро да ви забраним да правите такива проекти.
Причината за това е, че Rails сам по себе си е много сложен и за правилната му, канонична употреба, се изисква да положите усилия, които се равняват на още един едносеместриален курс. Ако не сте се занимавали с уеб програмиране преди това, нещата се усложняват допълнително. Rails е още една голяма и сложна абстракция, която трябва да научите прилично, за да става проектът ви за нещо, а това усложнява нещата неимоверно много.
Разбира се, имали сме няколко случая на сносни Rails проекти. Студентите, които са ги направили, са:
- имали предварителен опит с и силен интерес в областта на уеб програмирането
- се справяли добре с курса по Ruby и са овладели предварително достатъчно добре самия език
- прекарали в продължение на месеци множество часове – безсънни нощи и уикенди – в борба с Rails
Всичко останало е обречено на провал.
Ето ви един конкретен пример за възможна грешка (каквито изобилстваха в почти всички Rails проекти), произтичаща от сложността на Rails – ако сте ползвали <form>-тагове, за да направите форма, която не е пряко свързана с Rails модел, вместо да ползвате form_tag view helper-а (понеже вероятно не сте знаели, че има такова нещо). В Rails има много неща (както и в Ruby, между другото), така че се налага да проверявате за почти всичко, преди да тръгнете да си го пишете сами, какви готови решения се предлагат вече от фреймуърка и да прецените дали това решение е окей или не ви върши работа. Да, не е проблем да ползвате таг <form>, ако сте видели, че има form_tag, но, поради някаква причина, той не ви върши работа.
За тези от вас, които са фенове на уеб програмирането и искат да направят такъв проект за курса си по Ruby, ви даваме алтернатива – може да ползвате нещо като Sinatra, или друг минималистичен уеб фреймуърк. Пак ще се налага да опознаете из основи това, на което стъпвате (например, Rack и Sinatra), но това е задача, която е в пъти по-малка и обозрима, от това да научите добре Rails.
Да си направите собствена Руби библиотека е безплатно и не особено трудно. Като начало, запознайте се с няколко кратки ръководства, намиращи се на guides.rubygems.org:
Описанието на gemspec-формата може също да ви е полезно, докато правите gem. Ще ви трябва безплатен акаунт на rubygems.org.
Ограниченията са причина хората да проявяват изобретателност.
Поставете си следното ограничение - представете си, че правите проекта си в Ruby gem. Представете си, че го правите така, че клиентът му ще бъде друг Ruby код и че не трябва да мислите за потребителски интерфейс, графичен интерфейс, уеб интерфейс... Помислете как може да моделирате вашата бизнес логика и да разделите кода си на модули и файлове по начин, подходящ за вашата предметна област, без да се съобразявате със структура, наложена от Rails, Sinatra, Ruby Tk или каквото и да е друго. Не се притеснявайте да правите повечко файлове и папки, стига това да се вписва добре в модела ви.
Накрая може да ползвате вашия gem в Rails, или Sinatra, или Ruby Tk, или нещо друго, написвайки малко код и малко интеграционни тестове, за да проверите, че интеграцията ви със съответния GUI фреймуърк работи. И трябва въпросното GUI да е тънък слой върху вашата библиотека, а не вашата библиотека да е тънък слой върху Rails, да кажем.
Ако дойдете при нас само с Ruby gem и добри unit тестове, може да получите пълен брой точки. Ценим unit тестовете най-много за тези проекти и може да минете и без интеграционни такива, ако нямате интеграция с външи компоненти.
Гледайте това видео от презентация на "чичо Боб Мартин" по повод архитектурата на приложения и Rails. То се отнася и до проекти, които не са уеб или Rails. По-конкретен пример за това как бихте могли да реализирате на практика идеите, за които Боб Мартин говори в презентацията си, може да намерите в статията на Виктор Савкин "Building Rich Domain Models In Rais. Separating Persistance." Архитектурата, предложена и реализирана по-горе, е до известна степен крайна и доколко е подходяща за даден проект е обект на дискусия. От друга страна, тя е много изчистена и за целите на курсовия проект е много добро упражнение.
Изискването да се ползва система за контрол на версиите не сме го споменавали изрично, но смятаме, че се подразбира и че всички сте наясно. Задължително е. Силно препоръчваме да ползвате Git и GitHub. Няма проблем кодът на проекта да ви е публичен. Ако все пак държите да ползвате друга version control система, пак ще приемем това изискване за покрито. Важното е да има някакъв version control.
Ако една задача в курса ви носи 6 точки, едно предизвикателство една точка, а един проект — 60, може да направите грубата сметка колко сложен трябва да е проектът. Осланяме се на вашата честност и ви оставяме сами да прецените това.
Като цяло, проектът не трябва да е нещо, което да може да се напише за едно или две денонощия. Може да се наложи да си измислите и да вкарате още функционалност, за да покриете това изискване за сложност. Преценката за това какво е "достатъчна сложност" засега остава във вашето поле. Изисквания за функционалност могат да се измислят винаги, така че може да се приеме, че сложността на дадена идея никога не е ограничена отгоре. Тоест, каквато и да е идеята ви, може да добавяте и да добавяте функционалност, докато не се получи нещо с "достатъчна сложност".
В крайна сметка, ако не се опитвате просто да напишете нещо, което да ви "прекара" през курса, а пишете проекта с цел да пробвате и научите нови неща и подходите сериозно, няма да имате проблем.
Започнете навреме.