#!/bin/nwkr devblog

Malcom na swoim blogu podzielił się swoimi przemyśleniami na temat obiektowości w webdevelopingu, choć nie tylko. Jako że nie zgadzam się za bardzo, z tym, co napisał – odpisałem mu w komentarzu. Tak się tam rozpisałem, że zyskałem i materiał na wpis na moim blogu :)

Strukturalnie czy obiektowo?

Jakie podejście jest lepsze – strukturalne czy obiektowe? Tym pytaniem chciałbym wywołać dyskusję, w jakich przypadkach lepiej jest stosować jedno, bądź drugie rozwiązanie. Nie można bowiem powiedzieć, że tylko jedno jedyne podejście jest słuszne, a inne całkowicie odpada.

Moim zdaniem, w webdevelopingu rządzi obiektowość. Wymagania co do moich projektów poszerzają się bardzo szybko. Bez obiektowości konserwacja aplikacji jest bardzo ciężka. Przykładem jest tutaj portal geograficzny GeoZone.pl – 3 lata dopisywania kolejnego strukturalnego kodu doprowadziło do kresu możliwości dalszego rozwoju. By dokonać jedną zmianę trzeba odwiedzić kilkanaście różnych miejsc w kodzie. A potem i tak nie działa to do końca tak, jak chcę.

Do realizacji algorytmów oczywiście obiektowość i wzorce projektowe nie bardzo się nam przydadzą. Tutaj rządzi C/C++ ze wględów wydajnościowych. (Oczywiście do organizacji struktur danych wykorzystujemy struktury, czy klasy – jak zwał, tak zwał – jednak nie stosujemy tu dziedziczenia, polimorfizmu, wzorców, itd.) Kto rozwiązywał zadania na SPOJ-u, ten wie o co chodzi ;) A kto nie, temu tłumaczę, iż liczy się każda sekunda wykonywania programu.

Cytaty z MalDevBlog, komentarz Nowakerowy

Oczywiście przewagą ActiveRecorda jest miedzy innymi to, że wystarczy zmienić implementację sterownika bazy i można generować zapytania do dowolnej bazy, bez poprawiania kodu. Ale czy znów tak często zmieniamy bazę danych, szczególnie w nieco mniejszych aplikacjach?

Często może i nie, co nie oznacza, że nie warto stosować warstwy abstrakcji na bazę danych. Za pół roku możesz np. zdecydować, że przenosisz swoje wszystkie projekty ze względów wydajnościowych z MySQL na PostgreSQL – i co wtedy zrobisz? Albo mozolnie zmienisz wszędzie mysql_ na odpowiedniki pg_ albo… olejesz sprawę, bo będzie z tym zbyt dużo roboty.

Inna sprawa, to porozrzucanie po 40 klasach 4 funkcji, i tworzenie 10 obiektów tylko po to, aby zmienić jakąś regule w routingu czy funkcjonalność w innym module. I później przedzierać się przez tony dokumentacji i kodu, aby w efekcie otrzymać zamierzony cel działania ;)

Wg mnie nie masz tutaj racji, ponieważ dokumentację bedziesz musiał tylko raz przejrzeć, aby zrozumieć, o co chodzi. Później już nie będziesz tego odczuwał. Gdy zaś przyjdzie czas na jakąś przeróbkę w routingu, pójdzie ona gładko, podczas gdy w strukturalnym projekcie nie obeszło by się bez skakania po plikach i zmieniania wszystkiego po kolei w wielu miejscach.

Jednorazowe napisanie projektu obiektowo wymaga więcej pracy, aniżeli strukturalnie. Gdy zaś przychodzi czas na przeróbki, zyskujemy dużo czasu w stosunku do podejścia strukturalnego.

Tak myślę, że chyba jednak dokończę tego własnego frameworka. Ileż to różnych projektów wstrzymałem, zawiesiłem, czy porzuciłem na różnych stopniach zaawansowania prac. Głównie z braku czasu i zmian w zapotrzebowaniu i użytkowaniu danego produktu (projektu).

Według mnie to upadło w wyniku strukturalnego projektowania. Zmieniło się zapotrzebowanie i okazało się, że napisany strukturalnie system nie jest już w ogóle przydatny. Przemyślany obiektowy system daje się łatwo wykorzystywać dalej oraz modyfikować, a więc i szansa powodzenia projektu jest większa.

Na koniec zapraszam na blog Malcoma.

Dzisiejszy wpis poświęcony jest integracji frameworka KohanaPHP z serwerem LightTPD w taki sposób, aby ukryć adres index.php. Tzw. ładne linki, czy nice urls są bardzo ważne pod względem optymalizacji strony internetowej pod wyszukiwarki.

Plik lighttpd.conf: $HTTP["host"] =~ "^(www.|)nowaker.net$" { simple-vhost.server-root = "/home/www/nowaker.net/html" accesslog.filename = "/home/www/nowaker.net/logs/access.log" url.rewrite-once = ("^/(.*)$" => "index.php/$1") } Plik application/config/config.php: [...] $config['index_page'] = ''; [...] Prawda, że proste? ;)

Miałem dzisiaj coś do porobienia z poziomu konsoli DOS-owej. Aby wejść do katalogu E:\Programowanie\Java\Książki\Materiały\Java Core 1\v1ch9 musiałem się nieźle ponaciskać tych Tabów, albo naklikać (bo „mądra” konsola DOS’owa nie wie, co to CTRL+V). Wtem przypomniało mi się, że miałem kiedyś w menu kontekstowym pozycję „DOS Prompt Here„, która otwierała mi konsolę na wskazanym katalogu…

… więc i znów ją mam. ;)

Dla zainteresowanych:

• DOS Prompt Here – plik REG

Niektórzy pewnie zauważyli, iż wraz ze zmianą wyglądu bloga pojawił się z prawym menu dodatkowy dział pt. „Rekomendacje”. Owy link to mój pierwszy, jaki udało mi się sprzedać tutaj na moim blogu za pośrednictwem firmy LinkLift.

Jeśli chodzi o zarobki, to są całkiem niezłe. LinkLift wycenia naszego linka i pośredniczy w transakcjach, biorąc dla siebie 30% z ceny linku. Wg mnie to bardzo dobre rozwiązanie, ponieważ nie musimy się zbytnio wysilać wystawianiem linków na Allegro, obsługą nowych klientów, pobieraniem płatności – w przypadku LinkLift instalujemy tylko odpowiedni skrypt PHP i dalej już nas nic nie interesuje.

Odnośnie wyceny, jaką przeprowadza LinkLift, to jest ona uzależniona od wielu różnych czynników. Głównym czynnikiem jest PageRank, a drugim ważnym czynnikiem jest położenie linka na stronie. Wartość własnej strony można oszacować sobie tutaj.

Aby nie być gołosłownym, mówiąc „niezłe zarobki” przedstawiam kwoty, na jakie wyceniono linki na moich stronach. Podana kwota to cena za jeden link na okres jednego miesiąca.

• Portal geograficzny GeoZone – 45 zł / miesiąc
• Forum geograficzne GeoForum – 17 zł / miesiąc
• #!/bin/nwkr devblog – 7 zł / miesiąc

LinkLift oferuje również program partnerski – oferują wynagrodzenie w wysokości 25 zł za klienta, który po rejestracji sprzeda swoje linki, bądź zakupi jakieś za co najmniej 120 zł. Ja również uczestniczę w tym programie partnerskim :)

Są dwa sposoby, aby zintegrować system szablonów OPT z frameworkiem Kohana. Pierwszy, łatwiejszy i zarazem bardziej elegancki, nie wymaga żadnych modyfikacji w OPT – należy ściągnąć OPT i umieścić go w katalogu system/vendor/opt. Tworzymy również katalog application/templates, a w nim katalogi _compile oraz _cache.

Poniżej prezentuję zaś kod, który zmusi nasz OPT do działania:

define ('OPT_DIR', SYSPATH .'vendor/opt/'); require (SYSPATH .'vendor/opt/opt.class.php'); $this->opt = new OptClass; $this->opt->root = APPPATH .'templates/'; $this->opt->compile = APPPATH .'templates/_compile/'; $this->opt->cache = APPPATH .'templates/_cache/'; $this->opt->plugins = OPT_DIR .'plugins/';

I od tegoż momentu możemy już korzystać z naszego $this->opt.

Drugi sposób na uruchomienie Open Power Template z KohanaPHP to taka modyfikacja OPT, aby był częścią frameworka (dokładniej: biblioteką). Zaletą takiego rozwiązania jest to, że nie trzeba niczego „require’ować” (wystarczy tylko $this->opt = new Opt;). Utrudnieniem są jednak aktualizacje OPT – trzeba na nowo modyfikować pliki. Poniżej przedstawiam rozwiązanie krok po kroku:

1. Rozpakować wszystkie pliki oprócz opt.class.php do system/libraries/opt
2. Rozpakować plik opt.class.php w system/libraries i nadać mu nazwę Opt.php (z wielkiej litery)
3. Linie 69-72: { define('OPT_DIR', './'); } zamienić na: if(!defined('OPT_DIR')) { $docroot = pathinfo(str_replace('\\', '/', realpath(__FILE__))); define('OPT_DIR', $docroot['dirname']. '/opt/'); }
4. Linia 144: class optClass zamienić na class Opt_Core

Tak, jak w pierwszym rozwiązaniu, muszą oczywiście istnieć katalogi application/templates/_compile oraz _cache.

Takim sposobem posiadamy rozbudowany system szablonów OPT w frameworku Kohana.

1. Open Power Template – oficjalna strona
2. Open Power Template – Wikipedia
3. KohanaPHP framework

Dzisiaj, 5 kwietnia obchodzimy CSS Goły Dzień w Polsce (na świecie obchodzimy go 9 kwietnia). Pomyślałem, że warto się przyłączyć i zobaczyć, jak będzie wyglądała strona bez dołączania arkuszy CSS. Jak widać, szablon WordPressowy jest dobrze zrobiony, strona wygląda OK. Natomiast Portal geograficzny GeoZone.pl wręcz przeciwnie, mimo odłączenia pliku CSS, style i tak zostały częściowo zachowanie (dużo atrybutów „style”). Nie świadczy to dobrze o webmasterze (czyt. mnie), jednak na swoją obronę mogę powiedzieć, że projekt portalu geograficznego powstał trzy lata temu oraz, że na dysku powstaje powolutku nowe GeoZone zgodne z wzorcem projektowym MVC.

Wydanie frameworka Kohana PHP w wersji 2.1 stało się faktem! Oto lista najważniejszych funkcji, podana w roadmapie dla wersji 2.1:

• Image library
• Cache library
• ORM library
• Kodoc library
• Auth module
• Forge module
• Template_Controller, for simple auto-rendering templates
• PostgreSQL driver for Database
• MySQLi driver for Database

Nie jestem być może zbyt oryginalny, kopiując na żywca krótką listę funkcji prosto z oficjalnej strony Kohany; czuję się jednak zobligowany do poinformowania o tym wydarzeniu reszty świata ;)

Dzisiaj, w Środę Popielcową, weszliśmy – my katolicy – w pierwszy dzień Wielkiego Postu. Wielki Post to okres szczególny. W czasie tych 40 dni mamy czas, aby skierować się czynami w stronę Boga. Czy jednak wykorzystamy ten czas tak, jak się należy?

Po co nam Wielki Post?

Wielki Post ma nas nastawić duchowo do godnego przeżycia najważniejszego z katolickich świąt – święta Wielkanocy. Jest to czas, gdy wspominamy zmartwychwstanie Jezusa Chrystusa. Jego zmartwychwstanie daje nam gwarancję, że również i my powstaniemy z martwych i będziemy się mogli cieszyć życiem wiecznym w idealnym świecie.

XSLT, czyli Extensible Stylesheet Language Transformations, służy w skrócie do prezentacji danych zawartych w pliku XML w graficzny sposób. Idea szeroko pojętego rozdzielania treści od formy jest tutaj zachowana. XML przechowuje tylko surowe dane, podczas gdy XSLT pobiera stosowne informacje z XML’a i prezentuje je w sposób przystępny dla czytającego. XSLT stanowi alternatywę dla generowania stron po stronie serwera (np. za pomocą PHP), jako że całej transformacji dokonuje silnik przeglądarki.

I tutaj zaczynają się schody… Czy postawić na nowe technologie XML’owe i generowanie widoku przez przeglądarkę, czy lepiej jednak zajmować się generowaniem widoku po stronie serwera? A może połączyć obie technologie i generować widok z szablonów XSLT za pomocą PHP? Pytanie pozostawiam otwarte.

• Projekt I: plik xml, plik xsl, plik css
• Projekt II: plik xml, plik xsl, plik css

Minęły dwa miesiące od daty wydania frameworka Kohana w wersji 2.0, a już z niecierpliwością wyczekuję wersji 2.1. Magiczna liczby 100% na roadmapie Kohany 2.1 jest coraz bliżej i stawiałbym, że 2.1 wyjdzie około 5-10 lutego. Czyżby developerzy Kohany chcieli nam osłodzić niezdaną sesję? ;)