Jako, że gotowanie mnie relaksuje, postanowiłem dziś coś upichcić. A jako, że dawno tu nic nie pisałem o jedzeniu, to postanowiłem mój przepis tu umieścić.
W mojej lodówce, od dobrych dwóch miesięcy, zalegał tuńczyk w puszcze. Postanowiłem go w końcu wykorzystać.
Poszedłem na początku drogą dość klasyczną. Jajka na twardo, chudy jogurt, odsączony tuńczyk w sosie własnym z puszki, trochę soli, więcej pieprzu, majeranek, tymianek. Ale, przy wyciąganiu przypraw, spostrzegłem pudełko orzechów włoskich i zacząłem je podjadać. W końcu smaki się spotkały – słodkawy orzech, słony tuńczyk.. i stwierdziłem, że smak jest świetny.
Wrzuciłem zatem dwie garści orzechów włoskich do moździerza i wygniotłem – dzięki czemu cześć z orzechów była w większych kawałkach, cześć sproszkowana. Jajka podziabałem widelcem – więc też były tam większe i mniejsze kawałki. Zamieszałem, spróbowałem, ale jeszcze czegoś mi brakowało – dodałem ostrej i słodkiej papryki, szczypiorku i pietruszki.
Może moje kubki smakowe są dziwne, może po prostu miałem smaka na te składniki, a może to po prostu jest świetne połączenie – mi smakuje wprost nieziemsko. Wrzucone na ciemną bagietkę po prostu miażdży moje podniebienie, a kubki smakowe reagują orgazmicznie.
Fotki będą później (chyba, że domownicy wpałaszują ;-) ).
A teraz składniki: dwie puszki tuńczyka w sosie własnym, jeden (150g) chudy jogurt, trzy jajka – na twardo, dwie garści orzechów włoskich, szczypiorek, pietruszka, czerwona papryka, tymianek, majeranek, pieprz, odrobina soli.
Jestem graczem. Gdy miałem niecałe dwa lata, w 1986 roku, w moim domu pojawił się IBM PC AT na którym, już wtedy, były preinstalowane gry. Pamiętam do tej pory uczucia które wzbudzało we mnie granie. Uczucie rywalizacji przy graniu w PC-POOL czy Spacewar!, chęć bycia coraz lepszym w wyścigach, czy wyzwanie i chęć odkrycia historii przy Space Quest. Potem było już tylko lepiej. Pojawiła się Amiga, Pegasus, gry takie jak Contra, Mario, Settlers, Settlers 2, pierwsze Playstation, Intel Pentium 75MHz, coraz lepsza grafika, ciekawe historie i coraz bardziej złożone mechaniki. Potem granie online: Quake, Half-Life, Counter Strike, Unreal Tournament, Day of Defeat, Battlefield 1942, Ultima Online, MUDy. Gry “singlowe” których wszystkich na pewno nie pamiętam, ale wspomnieć muszę o serii Fallout ( łącznie z ostatnim New Vegas ), Baldur’s Gate, Planescape Torment, serii Vampire, grach FPP od Wolfensteina po Half-Life 2, Bioshock, System Shock.. sporo ich było. Nie wiem ile czasu spędziłem na graniu “w młodości”, ale z pewnością znaczącą ilość czasu. Co ciekawe, w dzisiejszych czasach, w USA, od piątej klasy podstawówki ( coś jak koniec podstawówki u nas ) do ukończenia liceum, uczeń siedzi przed ekranem komputera, grając w gry, średnio 10000 godzin. Przy stu procentowej obecności na zajęciach, czas nauki w szkole w USA we wspomnianym czasie to 10080 godzin. Oznacza to, że uczeń poświęca mniej więcej tyle samo czasu na naukę grania w gry komputerowe co na naukę wszystkiego innego. Jest to przerażające, ale jednocześnie można o tym pomyśleć jako o niesamowitym zasobie osobogodzin do wykorzystania do czegoś dobrego, kreatywnego, budującego. I właśnie o tym będzie ta seria wpisów.
Ja sam nie mam teraz czasu grać. Za gracza uważa się osobę, która średnio gra godzinę dziennie codziennie, ja na pewno nie spędzam tyle czasu przemierzając wirtualne światy. Możliwe, że w pierwszym zdaniu powinienem napisać “byłem graczem”, ale mentalnie dalej się za gracza uważam.
Ale jestem też znudzony. Oprócz braku czasu, coraz rzadziej zdarza mi się napotkać grę która wzbudza we mnie jakieś emocje, czy jest wyzwaniem. W którą tak po prostu chciałbym pograć. Która stymuluje mnie na tyle intensywne żeby przyciągnąć mnie do siebie na długie godziny. Tak jak książka czy film przyciągają nas interesującą fabułą.
Znalazłem trzy prezentacje, trwające łącznie około godziny. Zazębiają się one w wielu kwestiach. Trzy prezentacje z których każda pokazuje, że z graniem się nie wygra ;-) ale też, że można przekuć je na coś dobrego.
Pierwsza z nich jest najstarsza (luty 2006) i pokazuje spojrzenie na przyszłość.. czyli na to co teraz i to co będzie za kilka lat. Jest też trochę smutnym, przerażającym i melancholijnym spojrzeniem wstępem do całego tematu.
W prezentacji zawarte są dwa ciekawe filmy. Jeden pokazuje ewolucje gier od zarania dziejów po rok 2006 (6:29). Drugi to swoisty manifest studenta uzależnionego od gier, zrealizowany w bardzo fajny, profesjonalny sposób (9:30). Dodatkowym smaczkiem niech będzie to, że prelegentem jest David Perry, człowiek odpowiedzialny za Earthworm Jim, MDK, Messiah, czy adaptacje takich filmów jak Alladin, Matrix czy Terminator na coś w co możemy pograć. Dostępne są polskie napisy.
Według mnie najciekawszą częścią tej prelekcji jest film studenta zaczynający się w 9min30s. Padają w nim mocne stwierdzenia, których słuszność potwierdzą prelekcje które pokaże w kolejnych wpisach.
Zresztą, myślę, że sporą ich część mogą potwierdzić wasze własne doświadczenia.
Granie wiąże się z silnymi emocjami. Gry są tak zaprojektowane, po to byśmy chcieli w nie grać. Bo co uzależnia mocniej od emocji właśnie? Każdy gracz czuł wzruszenie, podniecenie, dumę czy strach. Niezliczoną ilość razy przebiegały nam ciarki po plecach. W końcu czujemy, że to nasze działania i decyzje mają wpływ na świat w którym się poruszamy. Czujemy odpowiedzialność za naszych żołnierzy nawet mimo tego, że 95 procent ich działań jest zaprogramowanie. Przez to intensywność naszych emocji jest stosunkowo duża. Czujemy to przy wszystkich tych “whoa” momentach – gdy zbieramy szczękę z ziemi, gdy udało się nam dokonać coś, czego teoretycznie dokonać nie mogliśmy – coś epickiego. Wynik 80:4 k:d w CSa, trwająca minutę i wygrana walka na karabiny snajperskie, pokonanie kolejnego bossa, odkrycie dalszej telenowelowej historii w Metal Gear Solid – wszystko to, chcąc nie chcąc, budzi w nas – graczach – emocje.
Pisałem wcześniej, że jestem znudzony i po tej prelekcji myślę, że wynika to ze zbyt dużych oczekiwań. Oczekiwań które zostały rozbudzone przez granie w przeszłości. Zostałem przyzwyczajony do zupełnie innego poziomu oddziaływania niż jest oferowany dziś. Bo mnie nie rusza specjalnie nowa świetna grafika, tylko fabuła – która teraz ma tendencje do bycia coraz płytszą, albo coraz bardziej zbliżoną do Mody na sukces w kosmosie albo w świecie fantasy. Kręci mnie też interakcja i skomplikowanie, które są często zarzucane na rzecz liniowości i cutscenek. Wystarczy porównać budowę poziomów z Quake 2 z tymi z Crisis.
W grach nasze wysiłki są od razu nagradzane, gra od razu powiadamia nas o naszych postępach. Co poziom dowiadujemy się jak nam poszło, co chwilę odblokowujemy jakiś “achievement” czy zdobywamy trofeum. Cała gra składa się z wielu wielu małych i dużych celów, a dzięki ich zdobywaniu wciąż czujemy, że posuwamy się do przodu.
Jesteśmy przyzwyczajani przez gry do tego, że mamy szybki i bezpośredni wpływ na życie. To co robimy zmienia świat, mamy też natychmiastowy feedback. Nie musimy czekać miesiąca żeby dowiedzieć się, czy nasza akcja się powiodła. W realnym świecie nie mamy takiego poziomu interakcji, a przez to czujemy, że nie mamy wpływu na własne życie.
Przez to niektóre uniwersytety zrezygnowały z wystawiania ocen, a w ich miejsce stworzyły “paski postępu” – zupełnie takie same jak przy zdobywaniu doświadczenia w grach. Dzięki temu każda ocena coraz bardziej posuwa nas do przodu – i widać to dokładnie. Taki pasek pokazuje drogę która pokonaliśmy, łatwiej też jest porównać go do czyjegoś paska i utworzyć ranking, a przez to stworzyć zdrowe współzawodnictwo.
Patrzymy na świat i rozumiemy świat poprzez pryzmat naszych doświadczeń, tego co przeżyliśmy i co widzieliśmy wcześniej. Od mojego pokolenia, a pewnie i w tym trochę wcześniejszym też, dużo z życiowych doświadczeń stworzyły telewizja i gry. Gdy jesteśmy nastolatkami nasz mózg nie do końca kapuje, że to co oglądamy nie jest rzeczywiste, szczególnie gdy stanowi to tak dużą część świadomego życia. Najzupełniej w świecie nie ma porównania do rzeczywistości. To co widzimy w TV czy ekranie staje się naszą rzeczywistością.
Czy po pięciu godzinach grania w Gran Turismo czy Need for Speed nie macie poczucia, że staliście się mistrzami kierownicy?
Albo po graniu w Tony Hawka nie macie ochoty wskoczyć na deskę i “kręcić” tricki, mimo, że wasza jedyna dotychczasowa styczność z deską była krótka i szybko po niej nastąpiła styczność z asfaltem? Ja wiem, że tak mam.
A ile razy ktoś z czytających chciał “zasejwować” życie, tak na wszelki wypadek?
Przez to, że nasze życie i świat nie dają nam takiej interakcji i poczucia, że można coś zmienić w łatwy sposób, problemy takie jak ubóstwo, wojna, choroby czy ludobójstwo tracą swoją powagę, stają się płytkie, nie dotyczące nas. W końcu w grach głównym pomysłem na fabułę jest “od zera do bohatera”. Ile razy ratowaliście już świat? Bo ja z kilkadziesiąt. W życiu, teoretycznie, nie mamy szans stać się takimi bohaterami. A skoro nie mamy jak rozwiązać tych problemów, to nie przejmujemy się nimi.
Spędzamy tonę czasu grając, w grach czujemy się bohaterami, dokonujemy epickich czynów, przeżywamy intensywne emocje, dostajemy szybki feedback – czujemy się panami swojego losu. Z tego wynika ten zły wpływ gier i możliwość uzależnienia się od nich. Z jednej strony jest to przerażające, ale z drugiej – nic tego nie zmieni. Rynek gier komputerowych stale rośnie, gry będą powstawać dalej. Będą coraz bardziej realistyczne i będą nas coraz bardziej wciągać i odcinać od rzeczywistości. Niedawno był boom na HD, teraz zaczyna się boom na 3D. Fizyka w grach jest coraz lepsza. Nie ma przed tym ucieczki.
Jedna z istniejących teorii sukcesu, sformułowana przez Malcolma Gladwella, mówi, że spędzając nad czymś 10000 godzin zanim osiągniemy wiek 21 lat, stajemy się wirtuozami tego czegoś. Oznacza to, że cała masa nastolatków jest wirtuozami grania w gry komputerowe. Ale co to oznacza i jak można przekuć to w coś dobrego?
Na końcu filmu Michaela, studenta z opublikowanej tu prelekcji, padają słowa, że “Może to pranie mózgu [ przez gry komputerowe ] nie jest takie złe. Wyobraźcie sobie gry uczące nas wzajemnego poszanowania, czy pomagające nam zrozumieć problemy otaczającego nas świata. Gry mają potencjał do robienia dobrych rzeczy. ”
I właśnie o takim podejściu do sprawy będzie część druga.
Niedawno odbyłem ciekawe dyskusje o grach. O kilku typach gier, ale ich wspólnym mianownikiem był fakt, że są to gry Role Playing Games.
Tak, rozwinąłem ten skrót. Głównie dlatego, żeby pokazać co on znaczy – gry w których odgrywamy rolę, postać.
Czyli nie, naszym celem nie powinno, według nazwy, być “levelowanie” postaci, tylko jej odgrywanie. Czy ktokolwiek jeszcze zastanawia się czemu postać którą tworzy jest elfem lub krasnoludem? Czemu wojownikiem a nie magiem?
Postać powinniśmy tworzyć tak, żeby dobrze się nam nią grało, a nie dlatego, że jej “statsy” dają najwięcej szans na wygraną. I świat gry powinien na to pozwalać – czyli wyjść poza schemat, że liczba obrażeń którą nasza postać może zadać decyduje o jej powodzeniu w świecie. Ja, na ten przykład, dobrze odgrywam silnych wojowników którym nie brakuje pod czaszką – moja klasa to wojownik/paladyn. Często jako rasę wybieram krasnoluda lub jego odpowiednik. Co nie zmienia faktu, że często staje się handlarzem, bo widzę co można kupić stosunkowo tanio i sprzedać drogo. Wiem jak wykorzystać umiejętności moich znajomych, aby przetworzyć tanio kupione materiały na warte wiele więcej przedmioty i sprzedać je z zyskiem.
Ale czy w ogóle da się grać postacią?
To, że idziemy bić smoki, zbierać ciasta czy ubijać orków nie sprawia, że (ode)gramy naszą postać. W dzisiejszych grach nie ma mechaniki pozwalającej na bycie sobą. Jasne, można tańczyć, można wyrzucać z siebie emotki czy robić inne rzeczy, ale nie jest to odgrywanie postaci które by cokolwiek nam dawało ( jeżeli w ogóle można mówić o odgrywaniu postaci dzięki tym mechanizmom). W klasycznych grach RPG osoba mistrza gry ocenia nasze granie postaci i na podstawie tego przydziela nam punkty doświadczenia. Oczywistym jest to, że nie da się tego ( jeszcze ) zalgorytmizować i na podstawie tego wyznaczać wartości punktów doświadczenia dla graczy, ale może można wyznaczyć inne trendy, w oderwaniu od czystego “levelowania”.
Aktualnie granie oznacza odkrywanie nowych lokacji, zabijanie coraz to większych potworów, zdobywanie coraz to lepszych przedmiotów. Naszego avatara w grze definiuje to co ma na sobie, jego poziom doświadczenia, jakiego rumaka dosiada itp. a nie to jaki jest – jaką ma osobowość ( swoją drogą.. czy widzicie tu jakieś podobieństwa do realnego świata? ). Trudno by było ubrać w tabelkę rankingu to jak odgrywamy naszą postać. Jest to idealnie takie same jak tworzenie wskaźników działania naszego biznesu – nie da się zmierzyć wartości których nie da się ubrać w matematykę, a często są to o wiele ważniejsze wartości niż to co daje się prosto zmierzyć.
Ale! Jeżeli mamy gadkę pozwalająca nam na sukcesywny handel, to już same ceny kupna i sprzedaży da się zapisać i wykorzystać.
W dawnych czasach grałem w Ultima OnLine, na serwerze Clairs Lair. Nieoficjalnym ( ;-) ) polskim shardzie ( serwerze ). Nie pamiętam już z jakiej okazji się dołączyłem do tej gry, ale faktem jest, że zajęła sporą część mojego młodzieńczego grania online. Wspominam o tym dlatego, że była to gra w której odgrywanie postaci mogło dać wiele więcej niż proste statystyki postaci. Każda umiejętność wyrażona była w procentach, 100% znajomości danej umiejętności oznaczało bycie Grand Masterem. Łącznie można było mieć 700% ( a później 800% ) znajomości umiejętności. Aby “wbić” GMa w jakiejś umiejętności trzeba się było naprawdę napracować. Jeżeli chodzi o walkę to było to wiele tygodni, jeżeli nie miesięcy, bicia stworów. Jeżeli chodzi o tworzenie przedmiotów ( crafting ) było to wiele miesięcy ich tworzenia. Walka zużywała nam oręż. A gdy zginęliśmy trzeba było owy odzyskać zabijając stwory które często go “zjadały”. Oznaczało to zebranie drużyny która była w stanie zabić stwora który zabił nas. Tworzenie przedmiotów zużywało nasze składniki. Trzeba było mieć drewno, skóry zwierząt, sztaby metali i wiele wiele innych. Sklepikarze w miastach mieli jedynie podstawowe przedmioty, większość z bardziej wartościowych składników znajdowała się w niebezpiecznych miejscach.
Oznaczało to, że połączenie między ludźmi walczącymi a ludźmi tworzącymi przedmioty ( gospodarką ) było olbrzymie.
Dany gracz mógł nigdy nie walczyć z nikim, a i tak był poważany za to, że tworzył wyjątkowej jakości zbroje. Do wielu osób były wielotygodniowe kolejki, zamówienia składało się o wiele wcześniej, bo renoma danego rzemieślnika była znacząca. Aby kupić materiały trzeba było mieć dobre stosunki z ludźmi. Tak naprawdę trudno było zbadać postęp naszej postaci i miejsce w rankingu względem innych, ale nikt się tym nie przejmował, dlatego, że ważne było to kim jesteśmy i co reprezentujemy w grze.
Gra nie była idealna, miała bugi, które łatwo było odkryć. Kiedyś odkryłem ze znajomym fakt, ze golibroda, stojący w stolicy świata gry, ale jednocześnie w budynku wyglądającym na magazyn, kupuje za krocie magiczne przedmioty, które, poza jego kramem, nie miały żadnej rzeczywistej wartości. Zaczęliśmy skupować te przedmioty, tworząc znaczący popyt i sprzedawać golibrodzie z zyskiem. Ceny magicznych przedmiotów, które i sami pozyskiwaliśmy z zakopanych skrzyń, których lokalizacje znaliśmy dzięki wyłowionym mapom skarbów, zupełnie się zmieniły.. w końcu o wiele bardziej opłacało się nam sprzedawać je na aukcjach niż golibrodzie. Czyli zaczęliśmy wykorzystywać popyt stworzony przez nas samych do zarabiania na przedmiotach które tak naprawdę nie miały żadnej wartości, oprócz tego, że ich nazwy były fajne.
Jak widać gracze mieli znaczący wpływ na ekonomię i gospodarkę całego świata. To był akurat w dużej mierze “problem” skali – gdyż na serwerze przebywało w danym momencie kilkuset graczy, czyli łatwo jednostce było wpłynąć na gospodarkę całego świata. Ale gdyby świat był większy, to wpływ na gospodarkę byłby raczej lokalny niż globalny. Oczywiście nie trzeba było też wykorzystywać do tego bugów w grze. Wystarczyło zobaczyć odpowiednią możliwość, zmianę w modzie i wykorzystać dla siebie. I znów.. czy ktoś widzi tu podobieństwo do rzeczywistego świata?
Co więcej czegoś takiego jak “quest” praktycznie nie było. Gra sama w sobie nie posiadała żadnych misji. Jedyne wyjątki to misje tworzone przez administratorów serwerów. Przypominały one zakrojone na dużą skalę sesje RPG.
Granie w taka grę dawało o wiele więcej satysfakcji niż, stosunkowo proste, nabijanie leveli ubijając stwory w kolejnej nowo odkrytej lokacji. Dzisiejsze współdziałanie z innymi graczami sprowadza się do tworzenia drużyn aby zabić jakiegoś “bossa” i zdobyć przedmioty. Jedynym wyznacznikiem bycia lepszym jest posiadanie lepszych statów – czy to poprzez nabijanie poziomów czy przez posiadane przedmioty. Cała struktura gier została mocno spłaszczona.
A można by stworzyć o wiele bogatszy system
Moim marzeniem jest gra, w której gracze mają rzeczywisty wpływ na świat. Lokalnie, nie globalnie. Gdzie questy są wynikiem rzeczywistej gospodarki i ekonomii a nie pre-definiowanego świata. Jeżeli kowal nie ma z czego kuć przedmiotów które mu najlepiej “schodzą” i wykaże się odpowiednią inteligencją, to zamówi u gracza dostawę sztab odpowiedniego stopu. Może to być kowal-gracz, może to być kowal-non-player-character. Myślę, że przy dzisiejszym poziomie techniki, spokojnie da się zaimplementować logikę rozmytą na tyle mocno, aby dany kowal wiedział czy jego praca w danym mieście mu się opłaca i jakich materiałów potrzebuje. To samo tyczy się karczmarza czy innego rzemieślnika.
Gra musiała by dać możliwość pogrania w ciągu “10 minut” – bo nie każdy ma czas grać po osiem godzin dziennie, codziennie – i coś uzyskać. Jednocześnie nie zabijając rozrywki ludziom którzy czas na granie mają.
Sam świat może być właściwie dowolny – czy to fantasy czy rzeczywisty czy post apokaliptyczny – ważne żeby mógł się zmieniać pod wpływem działań graczy ( nie gracza – graczy ).
Nie każdy przedmiot musiałby mieć sens – byłby rynek na mody. Cała masa przedmiotów była by prawie bezużyteczna, ale mogła by być eksponowana.
Postacie uczyły by się przez doświadczenie, a nie zdobywanie doświadczenia. Aby lepiej władać mieczem trzeba by nim władać.
Materiały dla rzemieślników dostarczane by były przez wojowników – aby obie główne frakcje nawzajem się nakręcały.
Według mnie taka gra dawała by o wiele większą satysfakcję niż to, że ktoś ma najwięcej dmg na serwerze, czy że ma najwięcej nabitego doświadczenia postaci.
Respekt wyrażony wśród społeczności werbalnie, a nie poprzez czyste cyferki, byłby o wiele więcej warty niż czyste statystyki.
Możliwość walki bardziej angażującej niż 7 8 3 5 2 2 4 5 9 7 1 6 3 2 8.
No i oczywiście, żeby dało się na grze zarobić i nie upadła jak APB, współzawodnictwo między graczami na podstawie wszechobecnych rankingów. W końcu FarmVille pokazuje wszystkim, że właśnie na tej, sztucznie stworzonej rywalizacji, robi się kasę.
Zostawienie paru niedopracowań, aby gracze mieli gdzie wykazać się kreatywnością – jak Dragon Kill points, czy My Two Pecs tym samym umacniając społeczność.
Dokładnie 23 miesiące temu, w święta 2008, pisałem o i wrzucałem linki do shortów “Rare Exports”, opowiadających o tym skąd bierze się święty Mikołaj. Nie będę pisał całej fabuły, co by nie popsuć. Każdy może obejrzeć sobie sam. Link do notki z działającymi filmami na końcu tego wpisu.
Shorty te zdobyły na tyle dużą popularność, że ich twórcy postanowili nakręcić film pełnometrażowy, który trafia do światowych kin trzeciego grudnia 2010. Niestety nie wiem jeszcze czy zobaczymy go w Polsce, ale jak tylko się dowiem, to dam znać. Całkiem możliwe, że nie jesteśmy jeszcze wystarczająco światowi, ale ja na pewno go nie przegapię.
A poniżej trailer, ku podkręceniu atmosfery. Prawda, że fajnie się zapowiada?
Właśnie uruchomiliśmy nową stronę Zeno.pl . Jest to już siódma odsłona jeżeli chodzi o grafikę.
W związku z ostatnimi rotacjami i rosnącym doświadczeniem zmieniło się nam portfolio usług i projektów.
Największą zmianą jest dodanie oferty projektowania, wyceniania kosztowego i czasowego oraz prowadzenia projektów internetowych.
Brzmi skomplikowanie, a sprowadza się do rozmów mających na celu jak najlepsze określenie danego projektu tak, aby firma która go realizuje wiedziała co zrobić, klient wiedział co chce otrzymać i co otrzyma, ile za to zapłaci i kiedy to będzie. Możemy również zrobić mały headhunterski wypad i poszukać agencji, firmy która w najlepszy sposób zrealizuje dany projekt. Dzięki temu zdejmujemy klientom trochę pracy z barków, jednocześnie obniżając koszty i zmniejszając czas potrzebny na realizację. A w prowadzeniu projektów mamy już osiem lat doświadczenia.
Udało się nam też nawiązać współpracę z Przemkiem Melnarowiczem, którego pierwsze wypociny graficzne osiem lat temu miałem okazję obserwować i komentować. Teraz często podnoszę szczękę z podłogi na widok jego prac. Zresztą jest on autorem nowej grafiki Zeno.pl .
Oferujemy też hosting dla naszych klientów. Możemy dzięki temu dostosować całe środowisko dla danej aplikacji i dać to czego ktoś potrzebuje, o wiele taniej niż udaje się to uzyskać na popularnych hostingach.
Zaczynamy też pisać aplikacje na Androida. Póki co budujemy jego portfolio i zdobywamy doświadczenie, ale pewnie w przeciągu kilku miesięcy będziecie mogli kupić jakąś aplikacje autorstwa Zeno.pl w Android Market.
A tak jako wisienkę na torcie i abyście mogli na świeżo śledzić co się dzieje założyliśmy profil na Facebooku .
Próbując uruchomić Diasporę doznałem kilku olśnień. Głównym z nich było odkrycie MongoDB. Istnieje cała masa baz danych które powstały dzięki rozwojowi aplikacji WWW jak choćby “key->value store” używane przez Facebooka, a teraz prowadzone przez Apache pod nazwa Apache Cassandra Project. Mówiąc z perspektywy programisty WWW – bazy relacyjne nie wpasowują się w potrzeby moich aplikacji. Klientom dostarczam dokumenty, liczy się szybkość ich generowania. Rządzi XML. W końcu XHTML to jest XML. Dane są hierarchiczne i często ich struktury naturalnie są dynamiczne. Fajnie by więc było gdyby mogły w łatwy sposób być tak przechowywane. Tworzenie kilku tabel dla pięciu rekordów w bazie danych, gdy klient podał trzy numery telefonów zamiast jednego, jest olbrzymim (stosunkowo) narzutem pracy, logiki i skomplikowania. Ile razy widzieliście pola VARCHAR/TEXT w których dane były przechowywane po przecinku? No właśnie. Za dużo.
Dlatego wiele lat temu zakochałem się w PureXML serwowanym przez IBM DB2 od wersji 9.0 . A teraz porzucam moją starą miłość dla zupełnie nowej. Nie oszukujmy się, zmuszenie DB2 do działania według tego jak się chce, a nie jak baza chce, to jest katorga dla osoby która nie spędziła przynajmniej kilku miesięcy na kursach. Narzędzia do obsługi bazy są toporne i bolesne w użyciu. A narzut wiedzy który był mi potrzebny do wykonywania na niej operacji liczył około trzech tysięcy stron A4 (od instalacji, przez używanie do administracji). Nie chce nawet szacować ile czasu zajęło mi instalowanie tej bazy na serwerach i maszynie developerskiej za pierwszym razem.. drugim i kolejnymi trzema. Uczenie się DB2 przyniosło mi sporo wiedzy ogólnej, która przydaje mi się teraz od czasu do czasu, ale to nie jest godna rekompensata zużytego czasu.
Ale dość wstępu. W tym wpisie chcę się skupić na MongoDB, jako, że po kilku ładnych tygodniach testów różnych baz doszedłem do wniosku, że właśnie ten produkt najlepiej spełnia oczekiwania które mamy w Zeno.pl i te które można mieć przy pisaniu mocno obciążonych aplikacji. Z pewnością zbiorę się do napisania wniosków ogólnych dotyczących innych moich odkryć wyniesionych z Diaspory along the way. Ale póki co Mongo i jego NoSQL, Schema-free podejście do życia.
MongoDB
Baza oparta jest o JavaScript i JSON/BSON. Do wykonywania zapytań używa się składni JS i JSON, dane przechowywane są przy użyciu JSONa i BSONa (do danych binarnych). Próg wejścia jest więc znikomy dla każdego kto pisał jakąkolwiek interaktywna aplikację WWW. Jest to ogromny plus. Od instalacji do pierwszych zapytań minęło u mnie kilkanaście minut. Na stronie jest ciekawie zrobiony interaktywny tutorial, dokumentacja jest tworzona na bieżąco i można o niej powiedzieć, że jest kompletna.
Sama instalacja bazy jest prościutka – wystarczy swoim managerem paczek zassać i zainstalować bazę i klienta. Standardowa konfiguracja wystarcza do zabawy i testów. Sterowniki do PHP dostępne są z poziomu PECLa
Ma to swoje plusy i minusy. Bazy danych i kolekcje (odpowiedniki tabel) tworzone są dynamicznie – oznacza to, że baza nie krzyczy na nas za literówki. Jeżeli raz napiszemy
db.users.insert({"name": "Zenobius" });
(komenda wstawiająca dokument – odpowiednik rekordu – do kolekcji user z polem – kolumną - name która ma wartość “Zenobius”) to Mongo sprawdzi czy w używanej przez nas bazie jest już kolekcja users, jeżeli nie to ją utworzy. Gdy za drugim razem wpiszemy
db.usrs.find();
(komenda listująca wszystkie dokumenty z kolekcji usrs ) to Mongo nie nakrzyczy na nas, tylko wyświetli pusty zbiór wyników. Gdy wpiszemy
db.usrs.insert( {"name": "Zenobius" } );
to Mongo stworzy kolekcję usrs, wstawi do niej dokument z polem name o wartości Zenobius i będzie się cieszyć z dobrze wykonanego zadania.
Co ciekawe każdy dokument przy insercie dostaje generowany przez bazę identyfikator. Dotyczy to też sterowników do PHP – po wywołaniu inserta obiekt który dodawaliśmy dostaje automatycznie pole _id .
Kolekcje tworzone są dynamicznie.Jestem w stanie wyobrazić sobie godziny spędzone na szukaniu buga polegającego na zjedzeniu literki. Z drugiej strony nazwy kolekcji i baz danych powinny być trzymane w modelu lub pliku konfiguracyjnym i nie zmieniane – więc da się z tym żyć.
Aby stworzyć bazę danych wystarczy użyć polecenia
use <nazwa bazy>
i baza jest gotowa do użycia. Domyślnie przy użyciu wiersza poleceń ( mongo ) używana jest baza test .
Baza jest skalowalna horyzontalnie. Jest to niesamowicie proste do skonfigurowania – wystarczy kilka poleceń na poziomie roota i admina bazy.
Replikacja danych, podobnie jak skalowanie, jest bardzo łatwa do skonfigurowania. Bazę można z łatwością dostosować do swoich potrzeb. Można wymusić zapis na kilku serwerach. Z łatwością w trybie produkcyjnym można przełączać status master i slave, aby zrobić np. backup danych.
Używa UTF8 – tak jak powinien to robić każdy z nas.
Support i interakcja twórców ze społecznością i developerami jest świetna. Przykładem może być współpraca twórców MongoDB po wpadce foursquare opisana na łamach high scalability. Oczywiście twórcy bazy nie mogli sobie pozwolić na zły PR, ale poziom szczegółowości, otwartość i szybkość reakcji sprawiają, że jestem pod wrażeniem.
MongoDB Admin UI
Do MySQLa mamy phpMyAdmina, do Postgresa mamy pgAdmina, do DB2 jest DB2 Developer Workbench. Dla Mongo też jest kilka interfejsów. Ich opis, po angielsku, dostępny jest na blogu Tima, oraz na stronie MongoDB.
Osobiście używałem póki co tylko ob PHPowych, z których o wiele lepszy jest Opricot. Ale jeżeli ktoś z was ma ochotę pobawić się Pythonem lub Ruby i dać znać czy warto – to czekam na komentarze.
Aplikacje Webowe muszą być dynamiczne. Musimy mieć też możliwość szybkiego wprowadzania w nich zmian aby wyprzedzać konkurencję. Próg wejścia dla Mongo jest niski – wystarczy kilka dni nauki i poruszamy się w jego środowisku swobodnie. Natomiast zyski z użycia Mongo wydają się być spore, jeżeli nie ogromne. Łatwość użycia, szybkość działania, łatwość konfiguracji replikacji i skalowania, prosta składnia – to wszystko rozwiązuje wiele problemów czy pytań które pojawiają się gdy używamy MySQLa czy Postgresa. Dynamiczna struktura dokumentów pozwala z łatwością zapisać w tej bazie wszystko. Fakt, że opiera się na JSON pozwala na bardzo łatwą manipulację danymi z poziomu PHP. Minusem jest mała dostępność bazy na hostingach i potrzeba migracji danych ze starej bazy i przepisanie całego modelu aplikacji. Natomiast jeżeli zaczynamy pisać coś zupełnie nowego to radzę poważnie zastanowić się nad MongoDB.
Niestety w tym roku nie udało mi się zrealizować moich wyprawowych planów. Niektórzy myśleli, że jestem cham i prostak nie pożegnawszy się na okres mojego wyjazdu – a smutna prawda niestety jest taka, że nie pisałem przez natłok pracy i życia. Patrząc jak pogoda za oknem robi się coraz mniej przyjazna a szanse na bezpieczną samotną pieszą wycieczkę po górach znikają.
Wyprawa się nie udała, ale plan pozostał – do realizacji w przyszłym roku. Została też ciekawa historia o tym jak ów powstał. Czyli właśnie krótka historia o tym, jak programista planuje podróż.
Plan wyprawy jest prosty: pojechać w Bieszczady i przejść głównie ich słowacką częścią w tatry i zakończyć w Zakopanem. Po drodze zaliczyć weekend w gorących źródłach w celu chwilowego lenienia się i regeneracji sił.
W Bieszczady jeździłem kiedyś sporo, w Tatrach byłem kilka razy. Nigdy nie byłem w górach Słowacji. Zacząłem zatem przeczesywać Internet w poszukiwaniu mapy szlaków turystycznych, a idealnie jakiegoś narzędzia do wytyczania trasy. Niestety nie udało mi się czegoś takiego znaleźć. Zapisałem się więc na forum poświęcone Bieszczadom. Przywitałem się grzecznie i zadałem nurtujące mnie pytania: którędy najatrakcyjniej przejść i co zobaczyć gdzie można? Niestety okazało się, że mój pomysł jest raczej z tych mało popularnych. Dostałem garść porad, ale nikt nie szedł w ten sposób wcześniej, więc nie miałem z kim takiej trasy przygotować.
Udałem się do Traffica. Właściwie lepszym stwierdzeniem było by “wstąpiłem do Traffica przy okazji” – nie był to plan, raczej fakt, że przechodziłem obok, a lubię to miejsce. Znalazłem się szybko w dziale z przewodnikami i przez niecałą godzinę szukałem mapy i/lub przewodnika po górach Słowacji. W końcu, gdy oczy miały mi wyjść z orbit, a szyja bolała mnie od ciągłego przechylania głowy to w lewą to w prawą stronę…
Mała dygresja. Czy książki nigdy nie mogą być ustawione tak, żeby tytuły na ich grzbietach dało się czytać bez ciągłej zmiany pozycji głowy? Czy może jest to jakiś specjalny sposób na rozruszanie moli książkowych? I jeżeli prawidłowa jest ta druga opcja – to serio – wystarczy próba czytania książki w autobusie. Ustawiajcie książki tak, żeby były zgodne grzbietami!
.. znalazłem to, czego szukałem. “Góry Słowacji”. Przewodnik napisany przez Barbarę Zygmańską. Nie piszę “Panią Barbarę Zygmańską” gdyż.. gdy tylko napisałem o tym na forum bieszczadzkim, okazało się, że Barbara jest jednym z jego użytkowników. A jako, że niepisana ( a czasem też pisana ) zasada forów mówi, że z użytkownikami owych jest się per “Ty” to właśnie z tego korzystam. Zresztą, na szlaku wszyscy jesteśmy znajomymi, prawda?
Ale jeszcze zanim okazało się, że autorka jest na forum, udało mi się przewertować wszystkie potrzebne mi rozdziały przewodnika i zacząć planować trasę. Użyłem do tego Google Earth, Google Maps oraz cudownego spreadsheeta z wszelkimi cenami, przelicznikami walut, liczbą kilometrów, planem wydatków i innymi.
Na Google Earth nałożyłem trasy z przewodnika i z tego co udało mi się znaleźć w necie. Niestety gotowe już warstwy programu nie miały tras które by mnie interesowały. Musiałem więc robić to sam. Obliczyłem również dzięki temu odległości oraz znalazłem część noclegów i stron ośrodków wypoczynkowych. Warstwa zdjęć natomiast pomogła mi ocenić które miejsca warte są obejrzenia a które nie. Zaplanowałem nawet o której porze dnia najlepiej iść, żeby słońce ładnie oświetlało zbocza gór. Dzięki temu powstała mapa, lista punktów ważnych ( łącznie z koordynatami do GPSa, którego planowałem kupić, a którego znalazłem oczywiście na allegro, korzystając też z testów znalezionych w necie ), lista odległości do przebycia, a nawet wykresy mówiące o różnicach wysokości i nachyleniu terenu – dzięki czemu łatwo było mi oszacować ile czasu zajmie mi przejście danego odcinka.
Gdy autorka przewodnika znalazła mój wątek dorzuciła mi jeszcze masę zdjęć, wskazówek oraz interaktywną mapę tras górskich na Słowacji. Dzięki temu mogłem doprecyzować wszystko czego potrzebowałem w bardzo zgrabny sposób.
Lubię planować od A do Z ale nie lubię trzymać się tego planu sztywno. Lubię móc improwizować, dostosowywać się do bieżących wydarzeń. Dlatego lubię też mieć możliwość zorientowania się w wielu pobocznych wątkach, ciekawostkach i faktach dotyczących różnych rzeczy. Taka wiedza ogólna pozwala na bezpieczne improwizowanie – czyli stwierdzenie “ok, jest burza, nie dojdę na tamten szczyt, ale przenocuję w tej chatce – wiem, że tam jest, bo widziałem ją na fotkach użytkownika google earth”, lub stwierdzenie “ok, w październiku ta kwatera okazała się być nieczynna, ale wiem, że 8km stąd jest większa miejscowość, tam pewnie się coś znajdzie”, zamiast stwierdzać “ok, idę tam, bo nie wiem gdzie mam iść”. Lubię też być przygotowany na wiele okazji. Dlatego kupiłem pneumatyczną syrenę alarmową (znaną dobrze z meczy piłkarskich ) i race spadochronowe – gdyby się coś stało, mógłbym z tego zrobić pożytek. Odświeżyłem też informacje o pierwszej pomocy i zaznajomiłem się, ponownie, z wszystkimi zasadami obowiązującymi na szlaku oraz w kontakcie z ratownikami.
Odruch szukania i planowania swoich wakacji używając Internetu nie wydaje się niczym dziwnym – wiele osób tak robi, bo jest to praktyczne. Gdybym zdał się tylko na wyniki wyszukiwania to nie miałbym za dużo informacji i pewnie przegapiłbym wiele ciekawych miejsc i możliwości. Dzięki temu, że użyłem Google Earth i Google Maps cała moja wyprawa osadzona jest w czasie i przestrzeni. A ja dokładnie wiem co jest w okół mnie. I jakie są opcje planu “B”, który mogę stworzyć na poczekaniu.
Dzięki temu, że napisałem na forum Bieszczadzkim wiedziałem, od najbardziej świadomych polaków w necie, co zobaczyć i gdzie się przespać gdy już będę na Słowacji.
Gdybym planował tą podróż kilka lat temu. I to niedużo, dosłownie pięć czy sześć lat wstecz, musiałbym zdać się na mapy papierowe. Nie miałbym też możliwości zakupienia, za stosunkowo nieduże pieniądze, urządzenia w którym mógłbym zapamiętać najważniejsze lokacje i w łatwy sposób wyznaczyć sobie odległość od nich. Jasne, kompas, mapa i orientacja w terenie to umożliwiają, ale bezpieczniej użyć GPSa (szczególnie, że nigdy nie wiadomo w jakich okolicznościach ta wiedza będzie potrzebna). Z pewnością ominąłbym dużo ciekawych miejsc, gdyż informacje byłyby niepełne.
Dziś, używając komputera i kilku darmowych programów, można zdobyć tonę informacji pobocznych, pomoc doświadczonych osób, zaplanować swoją podróż w wielu szczegółach i dopuszczając wiele możliwości. To piękne jak technologia ułatwia nam życie. Nie mówiąc już o tym, że gotowe notatki i mapki musiałbym laminować, żeby móc korzystać z nich nawet w deszczu.
Trasę i relację z wyprawy, które miałem plan opublikować właśnie jakoś teraz, opublikuję gdy już ją przejdę i będę miał co relacjonować. Póki co zostanie to moją słodką tajemnicą.
A może i Wy macie jakieś ciekawe miejsca które trzeba zobaczyć na Słowacji, idąc z Łupkowa do Zakopanego, w ciągu dwóch tygodni? Piszcie o tym w komentarzach.
Wczoraj pojawiła się pierwsza odsłona Diaspory. Nie jest to wersja dla użytkowników końcowych, lecz dla developerów. Aby zainstalować ją na swoim komputerze trzeba się trochę namęczyć. Ale może najpierw odpowiedź na pytanie
Co to jest Diaspora?
Projekt powstał na uniwersytecie w Nowym Yorku. Idea jest właściwie identyczna do tej z Appleseed. Lepszy jest marketing. Łatwiejsza ma być instalacja.
Diaspora, w zamyśle twórców, jest rozproszoną siecią społeczną, pozwalającą na kompletną kontrolę nad danymi w niej udostępnianymi. Dostarczana na zasadach Open Source ( aczkolwiek widać, że autorzy chcą mieć kasę z innych źródeł – czemu się nie dziwię, bo jednak cos ze swojej pracy mieć muszą ), rozbudowywalna przez API i napisana w Ruby. Rozproszona – oznacza działająca na zasadach peer-to-peer. Chroniona jest przez protokół SSL oraz enkrypcje PGP – żadna wiadomość nie może przemieszczać się między instancjami “otwartym tekstem”.
Każdy użytkownik Diaspory ma mieć swoją kopię/instancję aplikacji uruchomioną na swoim serwerze (komputerze) i wystawioną na świat.
Dla nie posiadających własnego miejsca hostingowego twórcy oferować mają konta na zasadach podobnych do WordPress.com – gdzie dany węzeł ( w terminologii Diaspory “seed” – yep, p2p ) będzie dostępny pod daną subdomeną ( i przechowywany na serwerach twórców projektu – co, tak z deczka tyci tyci, kłóci się z kontrolą użytkownika nad danymi, nie? ).
No, ale generalnie każdy użytkownik musi mieć jak wystawić na świat swoją instancję Diaspory – a do tego potrzebny jest hosting z Ruby 1.8.7 na pokładzie. Co jest oczywiste, żeby seed był widoczny dla innych, i aby mógł odbierać dane od znajomych, musi być stale włączony. Dla większości ludzi domowy PC odpada. A już szczególnie biorąc pod uwagę, że łącza w domach mogą do tego nie wystarczyć.
Jak wymieniać się danymi?
Gdy już mamy naszą Diasporę – czyli taki nasz profil, wypełniony danymi i wystawiony w sieć na “naszym” serwerze – musimy mieć możliwość udostępniania tego w internecie ( oczywiście decydując czy zdjęcia ze srogiej imprezy na której dużo się działo a nawet więcej się lało mają widzieć wszyscy, czy może tylko osoby które w niej uczestniczyły? ).
Dane oczywiście mogą być publiczne, ale mogą być też dostępne tylko dla jednej konkretnej osoby. Czyli gdy wiemy, że Łysy i Młody z którymi się na imprezie bawiliśmy mają swoje seedy w necie pod adresami http://mlody.joindiaspora.com i http://lysy.joindiaspora.com to możemy wpisać te adresy w “dodaj znajomego”, wysłać zaproszenie, i zdecydować co który ma widzieć. Gdy już węzły Młodego i Łysego zapoznały się z naszym węzłem, to gdy tylko napiszemy jakiś nowy status, to i oni go zobaczą. A gdy któryś z nich postanowi go skomentować, to ten komentarz wysłany zostanie do wszystkich trzech osób ( tak, to jest Facebook ).
Idea jest piękna, prosta i.. powiedzmy, że zrealizowana ( choć dalej nie udało mi się odpalić Diaspory na moim komputerze – trzy godziny męczenia się starczą póki co – to widziałem kilkoro uradowanych ludzików wysyłających sobie nawzajem wiadomości o tym jak to fajnie mieć coś, czego prawie nikt oprócz nich nie ma ;-) ).
Tak, bo póki co to ta aplikacja nie ma w ogóle dokumentacji. Tutoriale “jak zainstalować” powstają na blogach różnych niezrzeszonych w projekcie ludzi. Diaspora oparta jest o Ruby, z którego ja nie miałem okazji dużo korzystać, więc trudno mi samemu debugować błędy. Natomiast jeszcze żaden poradnik nie przeprowadził mnie przez proces instalacji aplikacji tak, żeby wszystko działało ( na mojej developerskiej Fedorze, bo nie chce zaśmiecać sobie Windowsa). No i niestety nie wszędzie dostępne są paczki z odpowiednią wersją Ruby. Udało mi się natomiast dowiedzieć, niejako przy okazji, o ciekawej bazie danych MongoDB – zorientowanej w okół zapisu dokumentu, a nie w modelu relacyjnym czy hierarchicznym. Ale to temat na osobny wpis.
Ja, mimo wszystko, wróżę projektowi ciekawą przyszłość. Ale mogącą się zdarzyć tylko przy spełnieniu kilku warunków. Musi powstać dokumentacja – zarówno dla developerów jak i prostych szaraczków – która wyjaśni dokładnie proces instalacji i jak to wszystko działa. Muszą powstać miejsca hostingowe dla Diaspory na których ludzie będą mogli odpalać swoje seedy ( i powierzać tym firmom swoje dane ;-) ). Twórcy aplikacji nie mogą być łasi na kasę – a niestety takie zapędy można u nich zaobserwować ( a może się mylę? ). Jedyny powód dla którego to może się przyjąć to skala – czyli odpowiednia liczba ludzi korzystająca z tego rozwiązania, aby i inni chcieli z niego korzystać. No i.. musi być to lepsze niż Facebook do którego wszyscy zdołali już przywyknąć ;-)
Po wpisie o tym jak zostałem programistą kilka osób zapytało się mnie o więcej konkretów – jako, że konkretami są książki to poniżej krótka lista tych które stanowią zupełne podstawy PHP, SQL, Linuxa i Apache’a ( tzw. LAMP ). Po ich przeczytaniu powinniście znać słownictwo i programowanie w PHP na tyle, żeby móc umieć: napisać aplikacje rozwiązujące konkretne problemy, umieć przeczytać czyjś kod ( ze zrozumieniem! ), móc użyć gotowych frameworków i zrozumieć jak działają, no i mieć podstawy pozwalające na dalsze dokształcanie się w internecie.
Ja sam przerabiałem różne książki, z różnych serii wydawniczych i pisane przez wiele różnych osób. Do samego PHP4 miałem około trzech książek podstawowych i dwie lub trzy dotyczące bardziej zaawansowanych zagadnień. Potem nadszedł PHP5, ale wtedy już wiedziałem które książki kupować.
Najfajniej mi się czytało książki z serii Wrox, wydawane w Polsce przez Heliona.
Co programista powinien wiedzieć?
Według mnie samo PHP nie wystarczy. I mimo, że PHP uważane jest przez wielu za prosty i prostacki język ( głównie dlatego, ze “próg wejścia” jest niski – czyli wystarczy trochę wiedzy, by mój pisać skrypty PHP, które są wątpliwej jakości ), to jednak pozwala on na wiele konstrukcji używanych w językach bardziej zaawansowanych, takich jak C++, Java czy C# . Ale wojny językowe to osobny temat. Skupmy się na tym co programista wiedzieć powinien, aby umieć pisać kod dojrzały i profesjonalny. Tak, co by “zaawansowani programiści” mieli mniej powodów do naśmiewania się z developerów PHP ;-) Oto lista zagadnień:
Podstawy programowania ogólnie ( czyli znajomość mechanizmów, które każdy język programowania musi mieć, aby móc się nazywać językiem programowania ). Z definicji językiem programowania nazywa się taki, w którym można zapisać każdy algorytm. Matematycznie rzecz ujmując musi on być kompletny w sensie Turinga – czyli zgodny z modelem maszyny Turinga. Ale znów, ja nie o tym tu miałem.
W bardzo dużym uproszczeniu znaczy to, że trzeba znać instrukcje warunkowe, rekurencyjność i zapis/zmianę danych w pamięci. HTML, XML, CSS to nie są języki programowania, gdyż nie mają takich mechanizmów. Podstawy programowania opisują książki takie jak PHP5, Apache i MySQL. Od podstaw ( to specyficznie dla PHP – ale bardzo dobrze napisane ) oraz Programowanie. Od podstaw – trochę bardziej ogólna i oderwana od PHP, ale daje sporo jeżeli chodzi o wejście w “całe to programowanie”. Zajmuje się środowiskiem pracy, tym jakie problemy można napotkać po drodze i czemu jest to normalne ;-)
Często dużym problemem jest instalacja Apache’a i PHP tak, żeby wszystko działało jak należy – książki o podstawach PHP zawierają taką wiedzę. Aczkolwiek planuję na łamach tego bloga napisać poradnik o instalacji PHP i Apache’a pod Windowsem, jak również używając Linuxa lub jakiejś maszyny wirtualnej.
Algorytmy i struktury danych. Każdy program to algorytm – czyli zestaw działań które trzeba wykonać, aby stało się coś konkretnego i zdefiniowanego – czyli żeby otrzymać określony wynik. Tu również miałem kilka książek, ale i w tym przypadku Wrox wygrał Algorytmy. Od podstaw .
Podstawy PHP. Ten temat obejmuje książka o której wspomniałem wyżej – PHP5, Apache i MySQL. Od podstaw . W tym temacie znajduje się opis składni PHP, łączenia go z HTMLem, wywoływania przez Apache’a ( lub inny serwer WWW ). Poznanie podstawowych funkcji, pętli (for, foreach, while ) i instrukcji kontrolnych ( if, switch ). Komunikacji z użytkownikiem, pobierania od niego danych, itp. itd.
Programowanie obiektowe. Aby znać obiektowość w pełni radzę wziąć w ręce książkę o zaawansowanym programowaniu w Java lub C++, natomiast aby opanować podstawy zawarte w PHP5, polecam PHP5. Zaawansowane programowanie . Aktualnie pisanie kodu strukturalnie, to strzelanie sobie w stopę. I chociaż każdy od tego zaczyna, to lepiej, po opanowaniu podstaw, przejść do programowania obiektowego. Tutaj dowiedzieć się można co to są klasy, interfejsy, klasy abstrakcyjne, metody, hermetyzacja, dziedziczenie, implementacja i cała masa innych ciekawych słów, których definicję i sposób użycia znać trzeba.
xHTML i CSS. W idealnej sytuacji programista zajmuje się programowaniem, grafik tworzeniem grafiki, a webmaster/webdeveloper czy jak to się teraz nazywa, zajmuje się przygotowaniem grafiki dla programisty – czyli “pocięciem” jej i stworzeniem szablonu HTML, kawałków grafiki i plików CSS, a czasem nawet dołączeniem do tego AJAXa. Natomiast na początku, i aby własna twórczość nas nie odrzucała, przydaje się znać HTML i CSS ( zresztą podstawy CSS i HTMLa nikomu nie zaszkodzą ). Aby się tego nauczyć polecam tutoriale na w3schools lub CSS. Projektowanie profesjonalnych stron WWW .
Head First to też ciekawa seria, chociaż dość specyficzna – nie wiem czy do wszystkich głów trafi jej forma przekazu. Co nie zmienia faktu, że są kompletne i, przynajmniej mi, dobrze się je czyta.
Oczywiście nie trzeba kupować wszystkich tych książek na raz. Dobrą zasadą jest wypróbować nowo nabytą wiedzę w trakcie czytania, a potem popisać trochę kodu używając nowo nabytych technik.
Miłego czytania, mam nadzieję, że ta lista pomoże komuś w zostaniu programistą aplikacji internetowych.
Powyższe linki mają w sobie mój kod z programu partnerskiego Heliona. Gdy kupicie książkę na ich stronie, to na moje konto zostanie zaliczona prowizja. Jeżeli komuś to nie odpowiada, niech przed zakupem skasuje ciasteczka w przeglądarce.
Ostatnimi czasy zabraliśmy się w Zeno.pl za refactoring kodu którego używamy do pisania naszych aplikacji – ZenoFuel i ZenoApp.
Staramy się to robić raz na kilka projektów, bo nic tak nie pokazuje ewentualnych pól do poprawy jak używanie kodu w praktyce. Tym razem postanowiliśmy jednak zrobić kilka sporych zmian – co oznacza również przegląd kodu od początku do końca.
W skrócie: nasz framework oparty jest luźno na Zend Framework ( podobny jest podział na pliki, wykorzystujemy kilka z jego modułów – np. do wysyłki poczty czy łączenia się z bazą danych ), napisany jest zgodnie z duchem MVC, wykorzystuje OPT do generowania HTMLa.
Składa się z kilku modułów: zestawu kilku Routerów ( do wyboru do koloru ), które decydują o tym jakie tworzyć Kontrolery, które to mają hooki pozwalające np. przed wykonaniem akcji na sprawdzenie uprawnień użytkownika. Zestawu klas do tworzenia Formularzy opisanych za pomocą XMLa. Abstrakcyjnych Modeli pozwalających na łatwy i uniwersalny dostęp do bazy. Prosty Cache oparty na APC ( który ma być wbudowany w PHP od wersji 6.0 ). Obsługę Sesji w bazie danych i plikach. No i całej masy klas pomocniczych do różnych zadań specjalnych.
Część tego kodu nie zmieniała się od kilku lat. Stał się on swoistym ‘blackboxem’ który po prostu działa. A skoro działa, to nie ma co w nim grzebać. Zmiany natomiast wprowadzamy gdy w jakiś sposób kod nas ogranicza lub widać miejsce które mogło działać by szybciej, lepiej, zgrabniej. Na bieżąco staramy się też dodawać komentarze lub uwagi na przyszłość.
Tyle słowem wstępu a propos materiału na którym oparte są te przemyślenia.
Czym jest refactoring ( tudzież refaktoring tak z polskiego ;-) )?
Refaktoryzacja to zmiania kodu programu, nie zmieniając jednocześnie zbytnio jego funkcjonalności. Oznacza to, że nie wprowadza się przy tym nowych featuresów, tylko dba się o to, aby nazwy metod, parametrów, funkcji itp. itd. były odpowiednie. Dodaje się komentarze tam, gdzie jest to wymagane. Rozbija się kod na mniejsze porcje – dzieląc na nowe metody i funkcje. W niektórych przypadkach można nawet w ogóle wydzielić część funkcjonalności do osobnej klasy.
Co oznacza “odpowiednie”?
Samo opisujące się. Idea jest taka, żeby przeczytanie nazwy metody dało nam już pełen ogląd na to, co owa robi i co zwraca. W praktyce trudno się operuje potem metodami które złożone są z siedmiu słów, nawet mimo podpowiadaczy we współczesnych edytorach.
Czyli tak naprawdę sprowadza się to do połączenia ze sobą komentowania i odpowiednich nazw – szczególnie, że taki Eclipse potrafi pokazać co metoda robi poprzez pokazanie nam,oprócz nazwy, również jej dokumentacji w auto-uzupełniaczu.
Umiejętność odpowiedniego wypoziomowania tych dwóch podejść przychodzi z praktyką.
Refaktoryzacja jest fajna i przydatna z kilku względów. I można robić ją na wielu poziomach.
Po pierwsze ułatwia zrozumienie kodu po dłuższej rozłące. Nie oszukujmy się, gdy wracamy do kodu po dwóch trzech miesiącach trochę czasu zajmuje nam połapanie się o co w nim w ogóle chodzi i czemu robi to co robi i jakim prawem to w ogóle działa?! :O Dobry podział plików, nazwy klas, metod, funkcji, odpowiednie zależności klas od siebie, hermetyzacja i odpowiednie komentarze/dokumentacja pozwalają skrócić czas ponownego zrozumienia.
Po drugie dobrze podzielonym kodem łatwiej zarządzać. Jeżeli w kodzie panuje chaos, to nie wiemy czy zmiana działania danej metody sprawi, że w innym miejscu nie pojawią się błędy. Porządek pozwala utrzymać panowanie.. nad kodem i nas swoimi nerwami ;-)
Po trzecie zmiana kodu na lepszy często wiąże się ze wzrostem wydajności. I tak, mimo, że komputery są coraz potężniejsze – oszczędzanie wydajności bardzo się przydaje. Podobna zasada tyczy się generacji HTMLa i CSSów – należy oszczędzać transfer.
Po czwarte jest to niezły ubaw. Z dwóch względów – widzimy jak się rozwinęliśmy, gdy coś co kiedyś potrzebowało kilku ifów i dziwnych funkcji teraz potrafimy zrobić połową ilości poprzedniego kodu. Niektóre nasze stare komentarze dla potomnych również potrafią rozbawić do łez ;-)
Jak pisać kod by potem dużo nie refaktorować?
To jest pytanie na zupełnie osobny wpis, ale odpowiedź może być prosta: pisać dużo kodu. Wracać do starego kodu, myśleć co by się w nim zmieniło i robić to :-)
Ja, gdy mam pomysł na rozwiązanie jakiegoś problemu, to najpierw sprawdzam go w praktyce, później dopiero, ale chwilę po sprawdzeniu czy działa, porządkuje go. Jeżeli może okazać się, że pomysł jest zły, to nie ma sensu poświęcać czasu na napisanie go od razu poprawnie. Jeżeli kod rzeczywiście działa, to trzeba sprawdzić, czy nasza pisanina nie ma zbyt rozciągłych czy zduplikowanych zmiennych, za dużo pętli i czy coś do poprawy nie rzuca się od razu w oczy. Nie ma co szukać na siłę, jeżeli wszystko wydaje się ok i spełnia swoją rolę, to nich tak zostanie.
Lepiej wrócić do takiego kodu za jakiś czas, gdy już osiądzie w swoim kontekście i będzie kilka razy wykorzystany – wtedy łatwiej zobaczyć co mógłby robić lepiej lub inaczej. Czy nie lepiej go podzielić, wydelegować niektóre czynności na zewnątrz. Czy część z tego co robi nie mogła by być wykorzystana w innym miejscu – czyli czy nie lepiej jej wydzielić obok. A może należy coś dopisać?
Może tablica z czynnościami do wykonania na porcji danych powinna zostać wydzielona do osobnej kolekcji, może trzeba dodać dodatkową parametryzacje, zrobić kod bardziej ogólny? W niektórych przypadkach kod jest na tyle samodzielny, że powinien stać się osobną klasą.
Co zmieniliśmy?
W Zeno, po przejrzeniu kodu ZenoFuel, liczącego sobie około 600 plików i 400 klas, interfejsów i abstrakcji, do zmiany poszło około 40% ( licząc również drobne poprawki kosmetyczne, w stylu ładniejsze ułożenie kodu, wywalenie nadmiarowych białych linii itp. itd. ).
Zmieniło się nazewnictwo kilkudziesięciu klas, niektóre zostały wyodrębnione w osobne miejsca – np. filtry danych z klas do formularzy uzyskały samodzielność, można je teraz bez obaw wykorzystywać zupełnie obok. Oznacza to również, że poszły z drzewa katalogów Formularzy do swojego własnego osobnego ( wyprowadziły się z domu ). Kontrolery straciły pewną część nadmiarowych metod i składowych ( pól ) – z kilku rozwiązań tych samych problemów wybraliśmy najlepsze. Niektóre klasy trzymają w sobie więcej danych aby zmniejszyć obciążenie bazy danych dodatkowymi zapytaniami – okazało się, że i te dane są często wykorzystywane w praktyce w naszych aplikacjach. Zmieniły się też odpowiedzialności klas, np. teraz to Kontrolery zajmują się przetwarzaniem parametrów które dostały od Routera – wcześniej to on nimi zarządzał. Niektóre metody skróciły się o dobre 70%, w kilku miejscach doszła rekurencja – jako jednak lepszy wybór.
Po tym etapie wszystko działa dokładnie tak samo jak działało wcześniej, jednak w ten nowy fajniejszy i lepszy sposób niż kiedyś – i to jest właśnie refaktoryzacja.
Klasy zostały też uporządkowane tak, aby móc przyjąć na siebie nowe funkcjonalności które dla nich planujemy, np. eventy ( zależności ) w Formularzach, bardziej rozbudowany Cache, elastyczniejszą Konfigurację, generowanie HTMLa Formularzy zdefiniowanych w XMLu, itp. itd. A wszystko w duchu wzajemnej nauki.
Oczywiście i te nowe featuresy dostąpią zaszczytu refaktoringu za kilka miesięcy, gdy w praktyce okaże się, czy spełniają dokładnie swoją rolę ;-)