DSC_5812

Red Bull Air Race – Gdynia

Mimo ciężkiego światła i dość krótkiego obiektywu (Nikkor 55-200 F/4,0-5,6) jestem zadowolony z ujęć.

Co do samych zawodów mam podobne podejście jak do Formuły 1 -niby fajnie, ale na dłuższą metę trochę wieje nudą. W sumie taka jest już natura sportów motorowych :) Co innego jeśli chodzi o pokaz Breitling Jet Team – po raz pierwszy oglądałem tego typu wydarzenie i na pewno w przyszłości podobnej okazji nie odpuszczę.

Zrzut ekranu 2014-01-25 o 17.55.56

Composer – manager pakietów dla PHP

Zawsze mając jakiś projekt używamy jakiś bibliotek, których chcemy użyć, aby ułatwić sobie pracę. Zaczynając od jakiś maleństw np. od helperów do obsługi obrazków, do kobył jakimi są frameworki MVC. Do tej pory albo ten problem ignorowałem i na sztywno wrzucałem kod do repo albo stosowałem moduły zależne w gicie.

Pierwsze rozwiązanie jest najprostsze  - nie wymaga specjalnej wiedzy, wrzucamy kod do katalogu, wrzucamy do repo i działa. Tylko co jeśli chcemy użyć biblioteki w kilku projektach? A co jak wyjdzie nowsza wersja? Odpowiedź: kopiujemy :) Tym sposobem trzymamy tę samą bibliotekę w każdym projekcie i musimy ją ręcznie aktualizować jak wyjdzie nowa wersja. Aby temu zapobiec wynaleziono wcześniej wspomniane moduły zależne (git submodules).

Działają one następująco: w tym katalogu naszego repozytorium jest inne repozytorium. Rozwiązanie w swojej prostocie genialne, wpisujemy polecenie do konsoli:

Tylko,  co jeśli chcemy nie dopuścić do zainstalowania wersji 3.0, bo psuja ona naszą funkcjonalność? Tutaj jest pies pogrzebany, git pozwoli zrobić wszystko :) A co jak wersjonujemy się w svnie?

Tu z pomocą przychodzi tytułowy composer. Jest to zewnętrzny manager pakietów,  niezależny od naszego repozytorium Dodatkowo pozwala korzystać z potężnego repozytorium pakietów oraz definiować własne.

Sama idea użycia sprowadza się do stworzenia w katalogu głównym naszego projektu pliku composer.json. Tam trzymamy “namiary” na zewnętrzne biblioteki. Przykładowy plik konfiguracyjny, który zassie nam  CakePHP z gałęzi 2.4 do katalogu Vendor wygląda następująco:

Instalacja wymaganych zależności odbywa się przez polecenie composer instal l wykonane w katalogu naszego projektu. Jedyne o czym musimy pamiętać, to dodanie katalogu Vendors do pliku gitignore. Aktualizacja jest równie banalna – wykonujemy composer update . Po więcej odsyłam na główna stronę projektu. 

orig_iStock_000002282120Large (1)

Trochę o nazewnictwie zmiennych.

Chyba nie ma nic gorszego w pracy programisty niż przeszukiwanie tysiąca linijek kodu w poszukiwaniu tego jednego, magicznego miejsca gdzie w przypadku jakiegoś dziwnego warunku brzegowego nasza zmienna jest ustawiana na null. Wiadomo, niestety od przewalania gnoju widłami nie uciekniemy – bug trzeba zafixować w takich warunkach jak jest nam dane klnąc przy tym niemiłosiernie na nieszczęśnika który to pisał. Oczywiście, wszystko byłoby dużo prostsze, gdyby ten kod był trochę bardziej przejrzysty…

Niezwykle istotne w dbaniu o czystość kodu jest odpowiednie nazewnictwo zmiennych. W dzisiejszym (pierwszym po “restarcie” bloga :)) trochę o tym poopowiadam.

Po co mi angielski

Na początku swojej kariery (głównie na uczelni) ludzie piszą takie kwiatki:

W sumie wiadomo o co chodzi. Program działa, wszyscy są zadowoleni. No i teraz wyobraźcie sobie, że pracujecie z Chińczykiem i on napisał coś takiego.

Dla typowego Anglika te 2 fragmenty (działające!) są w sumie tożsame – robią to samo. I są tak samo czytelne. Jako, że prędzej czy później będziesz pracować zarobkowo w międzynarodowym zespole polecam szybko sobie wdrożyć nawyk pisania po angielsku.

Kiedyś kumpel mówił że poprawiał po kimś algorytm odpowiedzialny za symulacje układu słonecznego. I metody nazywały się tam w stylu getPozycjaWzgledemSlonca(). Wszystkie popularne biblioteki, języki programowania są pisane w języku angielskim. Jeśli wciśniemy tam troszkę polskiego to wychodzą właśnie takie kwiatki językowe. Naprawdę warto otworzyć słownik językowy (albo google translate) i przetłumaczyć wcześniej nam nieznane słówko. Bo jeśli tego nie zrobimy, to zostajemy z getPozycjaWzgledemSlonca które będzie coraz trudniej wyrzucić.

Magiczne literki

Wiadomo czasem człowiek śpieszy, chce zrobić coś szybko i zostawia taki kwiatek:

Co to jest to m? Nie ma siły, musimy znaleźć definicje i domyślić się co programista miał na myśli… I wszystko jest fajnie, jak to nie jest jakaś przekazana referencja nie wiadomo skąd. Czy nie o wiele lepiej by to wyglądało, gdyby to m pojawiło się tu jako messegeService? Swoją drogą ten fragment kodu aż się prosi o refaktoryzację, ale to innym razem :)

Oczywiście nie należy tych m i t unikać jak ognia. Jeśli mamy jakiś znany i lubiany wzór matematyczny (np. transformatę Fouriera), to nie ma sensu silić się, żeby to t czy omega nazwać inaczej. W szczególności jeśli w artykule z którego korzystamy też tak są te zmienne oznaczone – warto wtedy też wskazać nasze “źródła” do niego w komentarzu.

Skrótowce

W dzisiejszych czasach, kiedy praktycznie każde IDE – zaczynając na Visual Studio i kończąc na Vimie ma podpowiadanie składni naprawdę nie warto używać skrótów. Trzy pierwsze literki, strzałka w dół i mamy co chcemy :) Naprawdę obecnie nie zyskujemy nic a możemy stracić bardzo dużo.

Dobrym przykładem jest coś co bym nazwała RegisteredUser. I jak to można skrócić?

  • RgstrUsr
  • RegstrUser
  • RegistrUsr
  • RgstdUser

Jak widać trochę tych możliwości jest. I teraz hm. Chcemy tej zmiennej użyć i jak ona się nazywała? No ciężko to zapamiętać, szczególnie jak w innych klasach/metodach użyty jest inny skrót. I wtedy człowiek klnie, bo po wpisaniu trzech liter Reg nie podpowiada mu nic. A zmienna nazywa się RgstrUsr

Zbędne prefiksy

Mamy tool, nazwijmy go Fancy Database. W skrócie FDB. I go rozwijamy. Co możemy zrobić? Nazywać klasy z tym przedrostkiem. FDBInteger, FDBRow, FDBConnectionManager. Co nam daje to FDB? Ok, od razu widzimy, że jest to nasza funkcjonalność. Ale poza tym? Nic. No ale w sumie po najechaniu na nazwę od razu pojawia się w jakiej przestrzeni nazw dana klasa siedzi. Właśnie – przestrzenie nazw są po to, by nie tworzyć takich potworków.

Dodatkowa sprawa, że czasem taki prefiks może zaciemnić sens użycia danej klasy. Rozważmy taki fragment kodu w Javie.

No po co to? Jeśli ktoś nie wie po co takie konstrukcje się robi, to nie wie, dlaczego. Może autor chciał dodać jakaś funkcjonalność typową dla FancyDatabase? No naprawdę nie widzę tu sensu.

Ale jak się dowiedziałem, że aby w Javie przekazać typ prosty jako referencje musimy go opakować go w o to obiekt to od razu wszystko mi się wyjaśniło. Przecież to chciał osiągnąć twórca tej klasy! Dużo lepiej by było, jakby nazwał ją IntegerWrapper (bo to ta klasa robi) i umieścił w odpowiednim packagu (np. com.fancycorp.FancyDatabase.common).

Na tym w sumie zakończę na dziś, W następnym wpisie opiszę dokładniej nazewnictwo klas i metod.