• Информация за проектите
• Още Git

• Web с Ruby, Sinatra
• Ruby core и stdlib. Външни зависимости. Полезни библиотеки
• Бира

• Другата сряда (21. декември 2016г.), 19:00ч.
• Мястото ще обявим скоро
• Запишете се във Facebook събитието

• Задължителен, за да завършите курса
• Носи 60 точки - по 20 за функционалност, стил и тестове
• Защитавате го през сесията
• Изпращате ни кода по имейл преди защитата
• За последното ще обявим крайна дата и час като наближи - ден-два преди самата защита

• Крайният срок да си изберете тема е 24.12.2016 г., 23:59:59
• Важно е да прекарате време с Ruby и екосистемата около него и да напишете нещо по-голямо
• Имаме ръководство за проектите
• Най-важното нещо за проектите - ще ви трябва време и трябва да започнете работа по тях възможно най-рано

• Подготвили сме ви няколко примерни проекта, от които също можете да избирате
• Ограничение - до 5 човека избрали една тема. Проектите са индивидуални
• Повече информация - в ръководството
• Трябва да пишете в темата за това във форума

• Можете да изберете собствена тема
• Най-важното е темата да ви е интересна
• Пишете ни по имейл, ако искате да работите по нещо извън примерните теми

• Пак - темата е почти без значение
• Имаме нужда да придобием представа единствено дали проектът ви ще е достатъчно (и не прекалено) голям и сложен
• Ако не получите никакъв отговор от нас в рамките на 4-5 дни, пишете ни пак или пробвайте друг комуникационен канал

• "Идеята ми за проект е система за управление на магазин"
• Какви технологии?
• Уеб, command-line, GUI?
• Бази данни ще има ли?
• Какви интерфейси?
• Роли? Автентикация, авторизация?
• Груби спецификации за това какви данни ще се пазят и какви операции ще могат да се извършват?

• "Избрах си тема за проект - играта Battleships"
• Двама играча ще се редуват на един компютър, или ще се играе срещу компютъра?
• Ще се играе ли по мрежа, или само локално, на една машина?
• Кои ще са двата интерфейса? Command-line? Gosu? Друго?
• Горното е твърде просто - има нужда от "усложнения"; например - save/restore на текущата игра

• Представете си, че клиент дойде при вас и ви каже само това едно изречение и след това попита "Колко ще струва?"
• Не е нужно да сте безкрайно подробни, но се постарайте да засегнете темите и технологиите, които ще използвате
• Важно е да се получи ориентир за сложността и да се съгласим за базова функционалност-минимум

• Ruby е general-purpose език, но не е удачно решение за някои проблеми, като:
• Тежки, алгоритмични и изчислителни проблеми, които са CPU-bound, изискват CPU-паралелизация и/или garbage collection-ът ще им пречи
• Десктоп приложения с бутончета, менюта и прочее
• Тежки и големи игри
• Мобилни приложения (но пък има RubyMotion)
• Embedded системи (но за това пък има mruby)
• Приложения, чиято основна работа е да имплементират дадено API - окей е за Ruby, но е неподходящо като тема
• Rails проектите са забранени - използвайте Sinatra или друг микрофреймуърк

• Ако не сте студент във ФМИ, или оценката и точките не ви интересуват, може да пробвате и Rails
• На защитата ще ви дадем обратна връзка за това
• Може да пишете и десктоп приложения, като ползвате Shoes (новата версия) или Tkinter (Tk) - не е особено практично, но е окей за курсов проект
• В случая на десктоп приложение, ще искаме да имате и някакъв алтернативен интерфейс към функционалността (например, command-line)
• По-прости, 2D-игри, с помощта на Gosu - пак искаме втори интерфейс (например, command-line)

• Това е едно от изискванията ни към повечето теми
• Целта е да усетите нуждата от разделение между интерфейс и логика
• Описано е в ръководството за проектите

• Ако изберете от примерните теми - пишете в специалната за това тема във форума
• Ако искате да работите по друга тема - пишете ни по имейл

Ще продължим с още малко слайдове за Git.

git checkout Gemfile
git checkout .

• Работи само ако файлът е в състояние Modified
• Премахва не-stage-натите промени върху файловете
• Внимавайте - ако сбъркате ще трябва да ги пишете пак

• Начин на комуникация с колегите
• Казват ви какво се е случило, докато ви е нямало
• Разкриват причини за бъгове
• Показват мотивацията за промяната

• Първи ред - tl;dr версия. Възможно най-кратко и описателно - до 70 символа
• Останалите редове - допълнително описание
• Как сте разрешили определен бъг
• Каква е мотивацията да направите дадена промяна
• Какво е точното съобщение за грешка, което оправяте с този commit и прочее
• Сегашно време - все едно commit-ите говорят за себе си
• Първият ред трябва да довършва изречението: "If applied, this commit will..."

Update Gemfile.lock

Update skeptic and libv8

The skeptic update showed errors in edge cases with the "spaces around
operators" restriction.

The libv8 update was because of compile problems I had with the older
version on OS X Yosemite.

• Независими разклонения на историята
• Например два фийчъра в процес на разработка
• В Git - файл, съдържащ хеш на commit
• Този commit се счита за последен в branch-a
• Нарича се връх на branch-а (branch tip)
• Първи елемент на свързан списък от commit-и

• Branch по подразбиране - master
• HEAD всъщност е референция към текущия branch (файл, съдържащ името му)
• Локалните и отдалечените са различни - master vs origin/master
• Всъщност origin/master е локален branch, съответстващ на отдалечения.
• Ако го променим - отново трябва да push-нем
• .git/refs/heads/<branch name>

git branch

• Нов файл в .git/refs/heads/

git pull
git pull origin
git pull origin master

• Изтегля промените и ги слива с текущия branch

git push
git push origin killer-feature
git push origin local-branch-name:killer-feature # Ако са с различни имена

• origin е име на отдалечено хранилище - това, от което сме клонирали
• На мястото на origin може да стои името на което и да е отдалечено хранилище

git merge killer-feature
git merge --squash killer-feature

• Слива промени от (най-често) 2 клона
• Често създава нов commit

Различни стратегии на сливане. Основните са:

• Fast-Forward
• Recursive

Слива 2 разделили се клона с обща история.

Жълтото e merge commit-a. Той съдържа промените и от двата клона.

git pull
git fetch && git merge origin/master

• Горните две команди са еквивалентни, ако текущия ви branch е master
• Изтегля промените и ги слива с текущия бранч

git branch -d killer-feature
git push origin --delete killer-feature # Ако сте го push-нали
git push origin :killer-feature         # Еквивалентно на горното

• Премахва само файла на branch-a, commit-ите се пазят
• Дори ако е останал commit, който е извън историята, пак може да се възстанови
• За възстановяване - след малко

Ще продължим с по-advanced неща.

git revert <commit>

• Премахва промените, направени от commit
• Всъщност създава нов commit, който прави същото като commit, но наобратно
• Разбирайте, където има + в diff-a, става на - и обратно
• Ако все пак решите, че искате тези промени, можете да revert-нете revert commit-a

git reflog

• Показва ви последните операции, които сте правили, заедно с ID-та на разни обекти
• Можете да намерите ID-тата на изгубени commit-и и да ги възстановите
• Понякога се чисти

• Често има файлове, които не искаме git да следи
• Например компилирани двоични файлове, временни файлове, конфигурационен файл с API ключове и т.н.
• Всеки ред в .gitignore е шаблон за файлове/директории, които трябва да бъдат игнорирани
• Това означава, че няма да се виждат в git status и няма да се commit-ват

/bin            # Файлът/директорията bin в главната директория на проекта
bin             # Всички файлове и директории с име bin
bin/            # Всички директории с име bin
compiled/*.html # Всички файлове с разширение html в директория compiled
lib/**/*.txt    # Всички текстови файлове в lib или нейна поддиректория
*.exe           # Всички изпълними файлове за Windows 

git checkout killer-feature
git rebase master
git rebase -i
git rebase -i master
git rebase -i HEAD~4
git pull --rebase

• Пресъздава промените от текущия branch, все едно са направени върху сегашното състояние на master
• С -i ви позволява да си премахнете, промените или слеете (squash-нете) commit-и от историята
• Трябва да направите git push --force, ако вече сте push-нали branch-a, който променяте
• Отново - избягвайте да го правите, ако промените вече са публикувани

• git add, git commit
• git push, git pull
• git checkout
• git merge, git rebase -i
• git reflog

• Елегантно решение на сложен проблем
• Научавайки как работи на по-ниско ниво, ще ви помогне да се ориентирате
• Конзолният интерфейс е сложен, но ще разбирате какво става "под капака"

• Няма да минете без Git
• Започвайте да го използвате
• Препоръчително - с терминала
• Ще се ориентирате бързо

• git help <command>
• git <command> --help
• man git
• man git-<command>

• Добър туториал за начинаещи с терминалния интерфейс - Try git
• Безплатна книга с много подробни обяснения - Pro Git
• Инструкции за създаване на pull request в GitHub - Guide
• Интерактивна визуализация на команди - Explain Git (забележка: някои неща не са 1:1 с реален Git)

• http://fmi.ruby.bg/
• @rbfmi