Списъци от символи с %i( foo bar baz )

Програмиране с Ruby

Курс във Факултета по Математика и Информатика към СУ

Проект за завършване на курса

  1. Трябва да ни изпратите имейл на fmi@ruby.bg с описание на идеята си за курсов проект, която сте си избрали, до 24.12.2014, 23:59:59. Ние няма да ви дадем списък от проекти, от които да си избирате. Харесайте си нещо, което ви се прави, или което ви е интересно и го започнете. Запознайте се с указанията за проекти.

    Най-важно за нас е да прекарате време с Ruby и написвайки нещо по-голямо, да пробвате нови неща и да научите нещо ново. Хубаво е да изберете нещо, което ви е интересно, което ви се пише, или което ви се струва предизвикателно и от което смятате, че ще научите много. Въпреки това, по-важно е да имате каквато и да е тема, одобрена от нас, за да може да започнете писането на код максимално рано.

    Идеалният имейл с тема за проект е сбит преразказ на спецификацията, която сте си поставили за цел. Допустимо е и да питате нещо, ако се колебаете много какво да изберете и имате нужда от насока. Важното е да ни пратите имейл по темата с нещото/нещата, които сте избрали в разумно време преди крайния срок, за да имаме време да ви дадем отговор и да нанесете корекции в изискванията си, ако има нужда от такива.

    Ако не сме получили имейл от вас до тази дата и час и ако искате кредити и оценка, ще трябва да дойдете с проект през септември. Вложете всичко от себе си, за да не стане така, че да изпратите този имейл вечерта на 24-ти.

    Може да задавате въпроси по проектите и в тази тема, ако смятате, че и на други колеги ще им е полезно да чуят отговора на вашия въпрос.

  3. Специафикацията на проекта какво трябва да включва? Изброяване на използваните технолоогии или описание на функционалности ? Може ли да направим някой неща да са опционални, тоест ако ни остане време да си ги донаправим. В описанието на проекта липсва шаблон, какво и как ще се оценява, давам пример с курса по Python:

    Оценяване (max 60 точки)

Проверката на функционалността на проектите няма да се прави автоматизирано, което означава че ви се дава свобода да изясните по-дребните детайли.

50% (max 30 точки) от точките, за вeрен и отговарящ на условието код. Трябва като минимум да покриете условието на проекта (по ваш избор можете да го разширите, но не и да променяте/пропускате части от него)
30%( max 18 точки) за стил, другояче казано: за четим код, добър дизайн, лесни възможности за разширяване на програмата ви, достатъчна документация.
20% ( max 12 точки) отиват при добрите unit тестове.

    Примерно описание на проект:

    Тема: Уеб приложение, за резервация в хотел

    Технологии:

    framework: Sinatra

    ORM: sinatra-activerecord (gem)

    База данни: SQLite

    Поддържани функционалности: регистрация на потребител, запазване на стая, разглеждане на свободни стаи.

    Опционални функционалности: Повече от един хотел, търсене на хотели по град.

    План на разработка:

    mileston 1 (insert_date) (Setting up all Sinatra bells and whistles)
milestone 2(insert_date) (implement registration/ login, setting up database and objects,  redirections, handling forms,handling  validation of user input )
Release: (insert_date) Using [Bootstrap](http://getbootstrap.com/) to beautify the interface and adding the test functionality Rack::Test (https://rubygems.org/gems/rack-test).

  5. Още не съм отговорил на никого. Извинявам се за забавянето. Очаквайте включване в близките ден-два.

    @Петя – може, смяна е принципно допустима, но е желателно да се избягва, ако е възможно. Важно е да ви ориентираме дали това, което сте избрали, е окей като обхват.

    @Йончо, в лекцията от понеделник има малко повече подробности и насоки за това какво ни трябва на нас в описанието на проекта.

    Твоето примерно описание е добро. Бих поискал малко повече подробности за поддържаните функционалности. Например, какви роли би имало освен нерегистрирани потребители и регистрирани потребители? Струва ми се, че трябва да има поне още една - служители в хотела/администратори. Хора правят резервации и по телефона, а и понякога някои стаи не са налични поради причини, различни от резервация. Виждам смисъл от такава роля.

    Ще има ли цени? Как ще се пазят цените? Кой ще ги въвежда? Аз мисля, че трябва да има. Ако има цени, трябва да могат да имат начална и крайна дата. Една резервация може да обхваща периоди с различни цени на вечер. Сметката трябва да е точна.

    Каква информация ще има за една стая? Ще може ли да има снимки? Мисля, че трябва да има. Ако има снимки, смятам, че за усленение на администраторите на системата, снимките трявба да са за категорията стая, а не за всяка индивидуална стая.

    И т.н. Очаквам малко по-подробни функционални спецификации.

    Отново - мислете, че при вас идва клиент с това задание и ви пита "Колко ще струва?" Какво бихте го попитали? Каква информация ще ви трябва още?

  6. @Митко описание на Business Use Cases, Use Cases, Class Diagrams е напълно излишно главно защото винаги подлежи на промяна, особено когато правиш нова идея, защото не знаеш какви проблеми ще срещнеш. Напълно съм съгласен, че човек трябва да седне и да помисли какво ще пише предварително, но "човек предполага, а Господ разполага" ("Албена", Йордан Йовков). Един mind map ще ми е доста по-полезен,това устройва ли те ?

    Така и не си отговорил на моят истински въпрос: Горната схема за процентите на оценяване ще важат ли за проекта, така например ако може накрая да реша да си подобря дизайна на кода вместо да дооправя тестовете си, ако не ми достига време или да се съсредоточа върху това да си довърша описаните функционалности.

    П.П. За уебаджийте, които ще пишат на Sinatra.

  7. @Йончо, оценката на проектите е описана в презентациите и сме я казвали на лекции - 1/3 функционалност, 1/3 стил, 1/3 тестове. Различна е от тази на курса по Python. Това ли питаш?

    Относно изискванията - вярно е, че в реалността често се налага да се променят. Допустими са и някои вариации в тях за проектите, но е необходимо да се опишат точно остновните use cases и да си "стиснем ръцете" за тях, за да се уверим, че проектът ще е достатъчно, но не и прекалено сложен. Без описанието на тези use cases, няма как да сме сигурни.

    Клас диаграми и твърдо формални описания не ни трябват. Mind map не знам дали ще ми върши работа, трябва да го видя.

    Предпочитам да видя списък от неща, които ще има приложението ти, които са определящи за неговата сложност. Без да се прекалява с детайлите. Ако има нужда от уточняващи въпроси, ще ги задам.

  12. Здравейте. Искам да попитам дали сте получили мейл от мен относно проекта, защото нямам отговор, а пък четох някъде из слайдовете, че ако не получа до 4-5 дена да пробваме друг начин за комуникация. Благодаря предварително и весели празници :)

Трябва да сте влезли в системата, за да може да отговаряте на теми.