Dzień pierwszy

Raz na zawsze (mam nadzieję), rozstrzygnęliśmy co jest językiem szablonów, a co czystym HTML-em. Wszystko dlatego, że otworzyłem nasz szablon w edytorze, który nie wiedział co to jest szablon Django, więc nie pokolorował tych fragmentów jak Komodo Edit. Dziecinnie proste więc stało się wytłumaczenie tego, że nasze szablony Django mają tylko dlatego rozszerzenie ".html", aby możliwa była praca na szablonie w edytorze, który może nie znać szablonów Django w ogóle. Jednym słowem, nasze szablony mają rozszerzenie ".html" i w zasadzie wszystko co zaczyna się od {{, a kończy się na }} (analogicznie z {% i %}) jest językiem szablonów Django, a reszta to czysty HTML (następnego dnia do listy dodałem jeszcze {# i `#}). Znowu też musiałem świecić oczami, kiedy zamiast aplikacji pojawiły się błedy, ale to dobrze, uczy rekruta tego, że niestety, nie wszystko zawsze będzie działać i że Depreciated oznacza, że cos może niedługo zniknąć (przestać działać). Na koniec menu z przykładu Bootstrapa, zamienilismy za pomocą tagu {% url %} na takie z działającymi odnośnikami.

Dzień drugi

Zaczęliśmy od |naturaltime, czyli od filtra pokazującego, w przyjemny dla człowiek sposób, czas od/do daty na której filtr operuje. Filtr należy do biblioteki Humanize (django.contrib.humanize). Po chwili na stronie dokumentacji, stało się jasne, że aby skorzystaż z tego filtra musimy najpierw dodać django.contrib.humanize do settings.INSTALLED_APPS, a na górze szablonu umieścić {% load humanize %}. Okazało się też, że filtr działa równie dobrze z językiem polskim, wystarczy aby jezyk aplikacji miał ustawiony nasz język w pliku settings.py LANGUAGE_CODE = 'pl'. Następnie zaczęliśmy poznawać HTML-ową tabelę(<table>), w czym pomocne było live demo, a także Inspektor w Google Chrome. Następnie zaczęślimy naszą listę liczników uporządkowywać w formę tabeli. Mimo dość prostego przekazu, że <ul> = <table>, a <li> = <tr>, chwilę zajęło nam umiejscowienie tagów <tr> i <td> względem przeniesionej z listy pętli {% for item in counters %}. Do znacznika tabeli <table> dodaliśmy, znalezione wspólnie w dokumentacji Bootstrapa, klasy <table class="table table-striped"> i nasza tabela nabrała w końcu sensownego wyglądu.

Dzień trzeci

Po jednym dniu laby, kontynuowaliśmy poznawanie kolejnych tagów HTML i usystematyzowaliśmy też sposoby komentowania kodu:

• w szablonach Django:

  {# my_inline_commment #}

  {% comment %}
      my_multiline_commment
  {% encomment %}

• w HTML-u i za pomocą:

  <!-- my_comment -->

• w Pythonie:

  # my_inline_commment 

  """ 
  my_multiline_commment 
  """ 

W 50 minut, wiele więcej się nie dało zrobić.

Dzień czwarty

To już weekend, więc można było poświęcić więcej czasu na naukę. Rozpoczęliśmy od tematu wszechobecnego ID w programowaniu. Wyjaśniłem, że PESEL jest jednym z najlepszych przykładów ID i że ID to coś dzięki czemu możemy jednoznacznie zidentyfikować dany element. W HTMLu to będzie <div id="something">, a w bazie danych aplikacji Django będzie to kolumna id. Następnie zaczęliśmy ekspresowy wstęp do baz danych. Wyszukaliśmy stronę MySql-a w wikipedii, wyjaśniłem mojej rekrutce definicję, opisałem po krótce działanie bazy dancych i wytłumaczyłem przykładowe zapytanie SELECT * FROM pracownicy WHERE pensja > 2000 ORDER BY staz DESC. Opowiedziałem też o tym, w jaki sposób wysyła się kod (FTP, git) i uzyskuje dostęp do baz danych na serwerach produkcyjnych. Pokazałem też, w jaki sposób można zmieniać style po najechaniu :hover, gdyż rekrutkę zainteresowały paski zmiany języka i wersji w dokumentacji Django, które wysuwały sie po najechaniu na odpowieni przycisk. Czasu starczyło jeszcze tylko na to by opowiedzieć o modelach. Poznaliśmy definicję modelowania ze słownika Pwn. Porównałem model do modeli do sklejania, gdzie możemy oddać modelowaną rzeczywistość w sposób ograniczony, a potem możemy dzięki temu testować np. areodynamikę samochodu w skali np. 1:100. Odwiedziliśmy stronę dokumentacji dla Modeli Django, gdzie zapoznaliśmy się z definicją modelu, dowiedzieliśmy się, że każdy model dziedziczy z django.db.models.Model i reprezentuje jedną tabelę w bazie danych. Z kolejnej strony w dokumentacji dowiedzieliśmy się, że każde pole modelu jest obiektem odpowiedniej klasy *Field. Na stronie Model field reference pokazałem wszystkie typy pól dostępnych w modelach, a także opisałem EmailField i w jaki sposób ułatwia życie posiadania "nadmiarowych" typów pól, dzięki którym, choćby, mamy mniej roboty z walidacją. Na koniec stworzyliśmy nasz pierwszy model o nazwie Cabaret, próbowaliśmy zrobić migrację, ale framework nie widział zmian, pewnie dlatego, że nie dodaliśmy naszej aplikacji do INSTALLED_APPS.

Dzień piąty

Zaczęślimy od szybkiej powtórki z prawdziwych podstaw baz danych. Następnię trochę pomęczyłem się aby Django uznało nasz model przy budowaniu migracji. Ostatecznie udało mi się dojść do tego, że to wszystko nie działa tylko z mojej winy, bo zamiast X w INSTALLED_APPS dodałem Y. No na każdej lekcji choć raz muszę ostatnio popełnić jakiś Fakap. Zgroza! Ale co to są te migracje(ang. migrations)? Jako, że już rekrutka jest zaznajomiona z git-em, to dość sensownym pomysłem było porównanie: commit migration, gdyż można powiedzieć, że migracja to zmiana na bazie danych, zupełnie tak samo jak commit to zmiany na/w plikach (oczywiście migracje to pliki, więc koniec końców wylądują w commicie). Wpisaliśmy w konsoli python managy.py makemigrations i już mieliśmy migrację naszego pierwszego modelu. Wpisalismy python manage.py migrate i już mieliśmy w naszej bazie danych... tabelę. Efekty naszych działań podziwialiśmy w phpMyAdmin (wiki), a przy okazji padło pytanie o bezpieczeństwo naszych danych, a także pytanie, jak je zabezpieczać. Mam już więc naszą pierwszą tabelę, czas więc pokazać rekrutce, że Django przygotowało dla nas niespodziankę. W pełni funkjonalny panel administracyjny, kryjący się pod adresem /admin. Żeby się do niego dostać potrzebujemy jakiegoś loginu i hasła, więc wyszukujemy jak go dodać wpisując w konsoli python manage.py. Znaleziony createsuperuser, wydaje się być tym, czego szukamy. Wpisujemy python manage.py createsuperuser, tworzymy konto, a potem logujemy się do niego. Teraz już możemy dodawać nowe Kaberety do naszej bazy danych.

Dzień szósty

Dwudniowe krążenie wokoły bazy danych, modeli i migracji sprawiło, że wiedza zamiast wyparować, utrwaliła się! Nasza baza danych jest relacyjna, więc zaczynam od ogarnięcia relacji. Poznajemy django.db.models.ForeignKey i relację many-to-one, a many-to-many i one-to-one wymieniamy tylko z nazwy (na początek to wystarczy). Jako że przyład na stronie mówi o samochodach, dwoję się i troję, aby rekrutka zrozumiała jak bardzo relacje między modelami/tabelami ułatwiają życie, ograniczają redundancję (nadmiarowość danych) i ogólnie mają wiele różnych zalet. W trakcie padło też pytanie, a jednocześnie moje zadanie domowe, czyli: Co jeśli w bazie danych mamy producenta np. Renault i on chce zmienić nazwę np. na Fsm, ale tak, żeby starsze modele jako producenta miały Renault, a nowe już miały Fsm, co wtedy? Następnie wróciliśmy do maszego models.py i utworzyliśmy drugi, obok modelu Cabaret, model City i połączyliśmy za pomocą city = models.ForeignKey(City, on_delete=models.SET_NULL, blank=True, null=True) (wcześniej pole city było CharField). Tak więc tworzymy sobie kolejną migrację. Niestety Django nie jest aż taki mądry, zupełnie zapomniałem. Trochę rzeźbimy, trochę zmieniamy, trocę usuwamy, a na końcu zmieniamy city na home_city, migrujemy i tabela jest! Dodajemy miasta, a potem na ślepo dodajemy te miasta do Kabaretów. Na ślepo, bo domyślnie w panelu jedynie wyświeltają nam się 'City object (1)' i 'Cabaret object (1)'. Więc musimy zdefiniowa metody __str__, czyli:

def __str__(self):
    return self.name

def __str__(self):
    return "{} ({})".format(self.name, self.home_city)

i na tym w zasadzie kończymy kolejny tydzień owocnej nauki.

Podsumowanie

Jak często się to już zdarzało, tak samo w tym tygodniu, planowane tematy, często były przerywane innymi tematami albo wstawkami uzupełniającymi. Dość często padały sensowne pytania, które zmieniały tory nauki. Doszedłem też do wniosku, że mimo wszystko za dużo jest prowadzenia za rączkę. Może by wymyśleć jakiś zestaw zadań. Najlepiej takie od początku do końca, od stworzenia widoku do gotowej podstrony. Dość mocno czekałem na ten moment, kiedy już dojdziemy do tworzenia Modeli, migracji i edycji tego z poziomu panelu administracyjnego. Teraz przechodzimy do tworzenia naszej prawdziwej/rzeczywistej aplikacji, a nic tak nie cieszy jak aplikacja, która ma swój cel i rzeczywiste dane. Po trzech tygodniach jestem zadowolony, z optymizmem i nawet lekkim podekscytowaniem czekam co przyniesie nam kolejny tydzień obozu przetrwania :D :D :D.