Projekt defaultowy

Czyli prosta aplikacja webowa utworzona z wykorzystaniem biblioteki Ruby on Rails. Będziemy chcieli zarządzać jakimś zasobem np. książkami, samochodami, landmarkami, notatkami, swoimi ocenami ze studiów, ciekawymi linkami itp. Weźmy np. książki: zadaniem jest zbudowanie aplikacji www z wykorzystaniem bazy danych dzięki której będziemy mogli np. dodawać/usuwać/edytować/listować książki ze swojej biblioteki, sortować je po kategorii, dodawać status wypożyczonej (i jeśli tak to komu i do kiedy). Funkcjonalności należy wymyśleć tak, aby w bazie danych znajdowało się ok. 8 tabel z kilkoma nietrywialnymi relacjami (1-do-wielu, wiele-do-wielu). Należy także dodać możliwość rejestracji/logowania wraz z dwoma poziomami dostępu: admin i user np. admin może usunąć książkę, a zwykły user już nie. Należy użyć styli CSS-owych, aby aplikacja nie wyglądała jak z początku lat '90.

Poniżej przedstawiam tematy projektów, przy których prace będę osobiście nadzorował i ew. sam poprawiał błędy, tworzył taski itp. Mam zamiar z nich w przyszłości korzystać, w związku z tym tylko jedna osoba (zespół) może tworzyć jeden z poniższych:

Zapisy Crawler

Przy okazji ostatniej edycji zapisów, uruchomiłem skrypt, który co godzinę ściągał i zapisywał do bazy danych stan liczebności wszystkich grup. Wszystkie dane są dostępne tutaj: link. Chciałbym, aby ktoś stworzył aplikację w Ruby on Rails (a tak naprawdę rozszerzył tą, którą ja zrobiłem), która weźmie te dane i przy pomocy jakiejś biblioteki JS-owej ładnie je zobrazuje w postaci różnych wykresów i tabel. Nie mam jeszcze pomysłu, jak dokładnie ma to wyglądać, dlatego chciałbym w ochotnikiem (ochotnikami) tę kwestię jeszcze przedyskutować. Rzeczy, które mi przychodzą do głowy, to:

• dla danego przedmiotu (i/lub konkretnej grupy) i przedziału czasowego: wykres zmiany liczebności osób zapisanych/limitu/osób w kolejce
• ranking popularności prowadzących/przedmiotów jako kryterium przyjmując np. czas zapełnienia się danej grupy
• wykres liczebności grup w trakcie i po zapisach
• wykres aktywności w systemie zapisów z podziałem na godziny

Zapisy Crawler 2

Usprawnienie systemu opisanego powyżej, aby można było zbierać dokładniejsze dane. Obecnie system zbiera tylko dane, które są dostępne publicznie (dla osoby niezalogowanej). Zadaniem jest dobranie się także do listy osób zapisanych w poszczególnych grupach/kolejkach.

RubyCourse Manager

Czyli system (apka w Ruby on Rails) wspomagający prowadzącego w zdalnym sprawdzaniu zadań w mojej grupie laboratoryjnej. Główną częścią jest stworzenie tabeli student/zadania, w której będę mógł sprawdzić stan danego zadania (zrobione, w trakcie, nie zaczęte) wraz linkiem do taska. Stan tej tabeli ma być przechowywany w bazie danych i aktualizowany specjalnym przyciskiem na stronie. Ta aplikacja może jednocześnie służyć jako tabela z punktacją, tak żeby odwiedzający student mógł zobaczyć jej stan, ale żeby nie mógł jej aktualizować. To znacza, że wymagany będzie jakiś system logowania (proponuję logowanie przez Githuba, przez co łatwiej będzie wszystko zintegrować z obecnym kodem). Nie mam jeszcze pomysłu, jak dokładnie ma to wyglądać, dlatego chciałbym w ochotnikiem (ochotnikami) tę kwestię jeszcze przedyskutować.

RubyCourse Manager 2

Usprawnienie systemu wysyłania list zadań przez Githuba. Udostępnię kod jednej osobie i dam jej wytyczne, co ma usprawnić, a raczej uszczelnić, bo aplikacja, którą napisałem nie jest odporna na przerwanie procesu wrzucania zadań w związku w np. brakiem internetu. Wspólnie z ochotnikiem przeglądniemy obecny kod i ustalimy w jaki sposób się za to zabrać.

RubyCourse Manager 3

Rozszerzenie do projektu RubyCourse Manager (1). Oprócz modułu "tabelki" przyda się jeszcze system zarządzania studentami (imię, nazwisko i login na githubie), abym nie musiał wszystkiego konfigurować ręcznie. Przez stronę chciałbym móc dodać/usunąć/edytować studenta (po byciu zalogowanym jako admin). Jako że to byłoby za mało roboty jak na projekt, to jeszcze można dodać zarządzanie listami/zadaniami. W szczególności tworzenie nowego zadania potrzebuje mieć edytorek tekstu z podglądem on-line (zadania są pisane w formacie Markdown).

Lista student/temat

• Rafał Florczak: LogManager
• Michał Rapacz: RubyCourse Manager
• Mateusz Kołaczek: Krzywe Beziera
• Karol Wieczorek: Imgur
• Michał Łowicki: Projekt defaultowy
• Paweł Zykowski: Projekt defaultowy
• Juliusz Zarzycki: Subtitles Converter

Typowe błędy, które popełniacie

Znane metody

Pamiętajcie, żeby nie wynajdować koła na nowo. Każdy programista Ruby musi znać podstawowe metody do manipulacji stringów, tablic i hashy np.: map, max, min, inject, select, keep_if, delete_if, include?, push (<<), capitalize i wiele innych. Dokumentacja to Twój przyjaciel.

Pętle

Zamiast for-ów używajcie each-ów.

Dążenie do piękna

Musicie wyrobić w sobie pewne poczucie estetyki. Gdy już napiszecie metodę i sprawdzicie, że działa poprawnie, to postarajcie się ją "przeczytać". Następnie wypowiedzcie słownie co wg założeń dana metoda ma robić. Jeśli obie recytacje znacznie się różnią, to zrobiliście coś nie tak. Pamiętajcie:

• dobry kod Rubiowy mówi sam za siebie
• dobry kod Rubiowy nie wymaga komentarzy
• dobry kod Rubiowy czyta się jak książkę

Nazwy zmiennych

To jest trochę związane z poprzednim punktem. Starajcie się dawać nazwy zmiennych, które mówią coś na temat obiektu, który się za tą zmienną kryje. Nazwy jednoliterowe nie są mile widziane. Wyjątkiem mogą być zmienne, które kryją za sobą liczby naturalne/całkowite np. n, m.

Skracanie kodu

Zamiast:

          @var1 = var1
	  @var2 = var2
	  @var3 = var3
	  @num1 = 0
	  @num2 = 0
        

Lepiej jest napisać:

	  @var1, @var2, @var3 = var1, var2, var3
	  @num1 = @num2 = 0
	

Generalnie o stylu

Zaleca się przeczytanie tego: https://github.com/bbatsov/ruby-style-guide.

Wybieranie pierwszego elementu z listy

Zamiast @articles[0] lepiej pisać @articles.first (patrz punkt o dążeniu do piękna).

Śmieci w kodzie

Kod do ręcznego testowania metod (np. pod definicją klasy) nie może znajdować się w repozytorium. Do testowania najlepiej zrobić sobie osobny plik i nie dodawać go do repo. Jeśli boicie się, że przypadkowo go wrzucicie poprzez git add . to zawsze możecie popatrzeć na mechanizm .gitignore.

Spacje vs tabulacje

Wcięcia muszą być wykonywane poprzez wstawienie dwóch spacji. Nie wolno używać samych tabulacji ani mieszać tabulacji ze spacjami. W większości współczesnych edytorów tekstu można ustawić, aby wciśnięcie klawisza TAB wstawiało 2 spacje.

Przypadki brzegowe, wyjątki

Zakładamy, że dane, które otrzymuje metoda zawsze są poprawne np. jeśli metoda przyjmuje liczbę naturalną, to nie trzeba sprawdzać czy obiekt, który otrzymuje jest liczbą i/lub czy jest większy od zera.

Nazwy commitów

Nie nazywajcie każdego commita w tasku np. tak: "[#3] Article class". Każdy commit powinien w nazwie mieć skrót zmian, które się w obrębie danego commita dokonało np. "[#3] Added methods x,y,z", "[#3] refactoring method x", "[#3] added accessor for variable x" itp.

Git tips & tricks

Ładny output i aliasy

W folderze domowym utwórz plik .gitconfig z zawartością:

       	  [user]
            name = Imie Nazwisko
            email = jakis.email@gdzies.com
       	  [alias]
            st = status -s -b
            lg = log --oneline --decorate --graph
            ci = commit
            br = branch
            co = checkout
            df = diff --word-diff
       	  [color]
            status = auto
            diff = auto
            branch = auto
            interactive = auto
            blame = auto
            ui = true
       	

Zamiast np. git status teraz wystarczy napisać git st. Dodatkowo output jest jest bardziej zwięzły i kolorowy.

Zapomniałem dodać [#x] do nazwy ostatniego commmita

Nie wysłałem go jeszcze na githuba: git commit --amend -m "[#x] ..."

Wysłałem na githuba: sprawdź pierwsze 7 liter sumy kontrolnej ostatniego commita np. sprawdzając git log. Powiedzmy, że będzie to f9ab4cf. Tworzymy nowego pustego commita i linkujemy do starego commita w następujący sposób: git commit --allow-empty -m "[#x] f9ab4cf". Następnie wysyłamy ten pusty commit na githuba.