przeczytalem ostatnio wypowiedz MajareQ na temat frameworkow i juz sam wstep zrobil na mnie piorunujace wrazenie:"Jeśli się pytasz: “Który framework powinienem wybrać?” to popełniasz błąd logiczny. Zakładasz, że w ogóle potrzebujesz jakikolwiek framework."moim zdaniem nie. bledem logicznym jest zakladanie, ze piszac w php nie potrzebuje frameworka :)1) startna dzien dzisiejszy osoba szukajaca frameworka, ktora nie zadala sobie juz wczesniej pytan zadanych przez MajareQ, to na 99% jest osoba, ktora nigdy nie pisala na prawde duzej strony i na 99% w najblizszym czasie jej bedzie robila. wiec nie szuka frameworka do pisania klonu Twittera, czyli bardzo, bardzo wysoka wydajnosc nie jest dla mniej priorytetem. i tu dochodzimy do punktu drugiego2) pomijanie calkowicie roli w ktorej frameworki sprawdzaja sie najlepiejrola polegajaca na szybszym, latwiejszym i przyjemniejszym pisaniu kolejnych aplikacji. frameworki pozwalaja zaoszczedzic duzo czasu, odwalaja za nas brudna robote zwiazana z autoryzacja, formularzami, walidacji itd. jesli 99% (ok, niech bedzie 90%) wykorzystania frameworkow to nie sa strony potrzebujace porad z High Scalability, to dlaczego mam nie uzywac frameworka, aby lepiej mi sie pracowalo? dlaczego mam pisac wlasne rozwiazania od podstaw i samemu dokonywac zmian na miare wlasnej wiedzy, skoro moge siegnac po cos co jest rozwijane przez osoby co najmniej, a zazwyczaj lepiej, orientujace sie w php? dlaczego nie mam skorzystac z faktu, iz bledy same sie poprawia, nowe funkcje same sie dodadza - wszystko niemal 'magicznie', calkowicie bez mojej ingerencji, po prostu 'pop' i mam kolejna wersje frameworka do sciagniecia. i tak dochodzimy do punktu trzeciego3) praca i zabawaczym innym jest praca, zarabianie z pisania w php, a czym innym bawienie sie w php, pisanie glownie dla przyjemnosci, bez terminow (ew. z odleglymi), rodziny itd. takie pisanie, kiedy po kilku godzinach siedzenia czlowiek ma duza satysfakcje, ze cos zrobil minimalnie lepiej niz bylo wczesniej, czesto po prostu cieszac sie faktem, ze cos sie zrobilo, dziala i jest tak samo funkcjonalne jak inne gotowe rozwiazania dostepne na sieci - ale to jest moje, moje i tylko ja to zrobilem, hoooray :) niestety, czesto pozniej zaczyna sie praca plus rodzina i albo skorzystam z gotowego, sprawdzonego, stabilnego, dzialajacego poprawnie rozwiazania i bede mial gotowa rzecz w 30 minut, albo poswiece najblizsze 4-5h na to aby zrobic to samemu, majac w perspektywie fakt, iz strona nad, ktora pracuje na 90% nie trafi na liste 'optimized by High Scalability'. w 90% przypadkow nie potrzebuje napisac czegos co bedzie musialo miec wydajnosc Twittera, wiec nie bedzie dla mnie roznicy w jakim frameworku to napisze (a roznice w wydajnosci moga byc miedzy nimi duze). i tu dochodzimy do punktu czwartego4) framework jaki jest kazdy widzina pewno przed wybraniem frameworka trzeba wiedziec czego potrzebujemy, to nie ulega watpliwosci. problem w tym, ze dla 90% wykorzystania frameworkow, wszystkie liczace sie spelniaja te wymagania. maja wsparcie, sa rozwijane, maja obsluge wielu baz, maja mechanizmy wspierajace rozne silniki do cache`owania itd. dlatego wlasciwym kryterium jest to, w ktorym frameworku najlepiej mi sie pracuje. ktory dla mnie i tylko dla mnie jest najfajniejszy. dodatkowo jest jeszcze kolejne kryterium o ktorym warto pomyslec zanim zdecydujemy sie na jakies bardzo niszowe rozwiazanie. i tu dochodzimy do punktu piatego.5) w kupie razniejwlasne rozwiazania sa fajnie, ale jak jestem klientem i mam swoj sklep online napisany na czyims wlasnym silniku, to mam przesrane. tak po prostu. jak mi webmaster odejdzie, to zanim nowy sie polapie, to troche czasu minie - chyba kazdy kiedys robil cos w cudzym kodzie i wie jaka to jest 'przyjemnosc'. a jak wyglada sytuacja jesli mam framework? z nowym webmasterem nie ma problemu, po prostu szukam kogos kto zna dany framewok i sporo problemow z glowy. podobnie jesli mam firme z 20 ITmenami na wlasnym rozwiazaniu. przyjdzie nowa osoba, ile czasu bedzie musiala sie uczyc ? ile czasu bedzie sie uczyl nowy pracownik, ktory zna dany framework? a czas to pieniadz. analogicznie jesli szukam pracy, to znajde ja szybciej znajac gotowe rozwiazania czesto stosowane w firmach.6) uwagi koncoweprzewaga frameworkow nad domowymi rozwiazaniami jest zazwyczaj bezpieczenstwo, optymalizacja, 'magiczne' naprawianie bledow i dodawanie nowych funkcjonalnosci, trzymanie sie ogolnie przyjetych standardow, mniejsze lub wieksze wymuszanie pisania zgodnie z MVC. jak dla mnie to wystarczajaca lista, aby zarzucic wlasne rozwiazanie i zajac sie czyms gotowym, czyms co w miare szybko dostosuje do wlasnych potrzeb i bede czul sie 'jak u siebie'. mozna samemu napisac framework, tyko nadal pozostaje jeden minus - samemu trzeba wprowadzac wszelkie poprawki, a majac gotowe rozwiazanie czas na to przeznaczony moge poswiecic na poza komputerowe hobby. nie sama praca czlowiek zyje.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Nadeszła pora na podsumowanie tematu systemów szablonów. Nie da się ukryć, że większość aktywnych programistów nie widzi już potrzeby korzystania z systemów szablonów. Świadczą o tym wpisy na blogach zagranicznych np. Paul M. Jones czy Hasin Hayder, który nawet napisał swego czasu...

W nawiązaniu do poprzedniej noty o CXFie, którą napisałem jakiś czas temu, gonię aby uzupełnić brak konfiguracji klienta. Sam proces jest bardzo zbliżony do tworzenia klienta w oparciu o XFire. Nie jest wymagana duża ilość kodu Javy, a w zasadzie tylko dwa pliki XML (client.xml, myservice.xml).

Pierwszy z nich odpowiada za wczytanie wymaganych rozszerzeń CXFa oraz definicję bazowej konfiguracji fabryki z interceptorami. W interceptorach możemy skonfigurować logowanie, obsługę załączników czy standardów WS-Security etc. Wszystkie te ustawienia będą dziedziczone, a fabryki docelowych usług będą dodawać tylko adres, do odpytywania. Na koniec bean klienta będzie miał określony autowire by nie przekazywać mu wszystkich własności.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Temat testów jednostkowych nie pojawiał się na tym blogu tak często jak PHP czy JAXB, jakkolwiek temat ten poruszałem w 2 notach - o testach oraz o singletonie.

Tych, którzy chcieliby dowiedzieć się więcej o testach na przykładzie JUnit i Javy zapraszam się do zapoznania z bardzo dobrą pozycją na temat testów jednostkowych, z którą miałem przyjemność się zetknąć.

JUnit. Pragmatyczne testy jednostkowe w Javie to tłumaczenie książki Pragmatic Unit Testing in Java z serii The Pragmatic Programmers. Nie wspominam tu o tej książce jak i całej serii przypadkowo, ponieważ pragmatyzm jest główną domeną tego bloga.

Tytuł ten traktuje o rzeczy bardzo ważnej, jaką są bez wątpienia testy jednostkowe. Nie jest to sucha referencja opisująca możliwości JUnit ale przewodnik i poradnik - czyli nie tylko o tym czym testować ale po co i w jaki sposób to robić. Sam język w którymś momencie schodzi na drugi plan a ważna staje się na prawdę idea i szczytny cel, jakim jest wykluczanie błędów przed wdrożeniem aplikacji, tak by nie musiał się o nich w ogóle dowiadywać klient.

W książce znajduje się wiele przykładów i rozważań, pisanych lekkim językiem, całość czyta się lekko i przyjemnie. Jest to bodajże najczęściej wypożyczana pozycja z mojej domowej biblioteczki. W każdej kolejnej pracy (a troszkę ich w międzyczasie było :)) staram się komuś polecić tą pozycję i odzew jest zawsze pozytywny, co dowodzi, że praca autora włożona w tytuł była bardzo przemyślana. Z najważniejszych elementów, które zostają w książce omówione należy wymienić definiowanie warunków brzegowych, wykorzystanie “obiektów imitacji” (ang. mock objects) z użyciem biblioteki Easy Mock oraz projektowanie kodu przyjaznego dla testów. Chyba wszyscy się ze mną zgodzą że są to elementy nieodzowne podczas tworzenia testów.

Na zakończenie przytoczę dwa akapity które najbardziej zapamiętałem z całej pozycji.

Gdyby architekci sprawdzali mosty w taki sam sposób jak większość programistów to na świeżo wybudowanym moście środkiem jezdni przejeżdżałby jeden malutki samochód w ciepły dzień, bez jakiegokolwiek wiatru i innych zakłóceń atmosferycznych. (o warunkach brzegowych)

Z testami jednostkowymi jest jak ze strzyżeniem trawnika. Jeśli jest on dobrze utrzymany to jego uporządkowanie nie jest zadaniem trudnym. Jeśli jednak nasz trawnik zarośnie (w projekcie nie będzie testów jednostkowych) i pojawią się chwasty (błędy) to jego uporządkowanie (wprowadzenie testów) będzie zadaniem bardzo czasochłonnym. (o filozofii testowania)

Koniec końców, siejąc pragmatyczną propagandę na rzecz testów :), zachęcam wszystkich do zapoznania się z opisywaną książką. Dla praktyków zawiera ona kilka trafnych spostrzeżeń a dla laików będzie znakomitym sposobem na wdrożenie się w temat testów.

Szkic tej noty czekał na publikację ponad rok, stąd może być on troszkę nieskładny.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Dziś wydana została nowa wersja Vframe oznaczona numerkiem 2.3.1. Większe zmiany:

• Możliwość tworzenia grup routingów za pomocą wyrażeń regularnych (grupowanie regułek, aby przyspieszyć działanie).
• Automatyczne wczytywanie konfiguracji Vframe_Router_Advenced::PatternsBuild().
• Wydzielenie głębi konfiguracyjnej dla kontrolerów (kontroler News_Admin_Vcontroller ma plik: /Configuration/Controllers/Admin/News.php).
• Zaimplementowanie Cache_Engine (wzorzec fabryki) oraz silników: File, Memcache, APC.
• Zaimplementowanie Image_Engine (wzorzec fabryki), silnik GD.
• Zaimplementowanie Db_Layer (wzorzec fabryki), silniki MySQL, SQLite.
• Zniesiona została stała V_APP oraz V_APP_REAL.
• Dodanie nowego komponentu Vframe_Mail_Inbox (pobieranie poczty) oraz silnika Vframe_Mail_Inbox_Engine_Imap.
• Zabezpieczenie unikalnego klucza sesji frameworka, dodanie V_APP_SESSION_HASH.
• Zmiana struktury Exceptions oraz Interfaces - teraz klasy znajdują się w głównym pliku komponentu, nie posiadają wydzielonych plików.
• Dodanie pluginu Vframe_Controller_Front_Plugin_Gzip.

Konieczne zmiany w aplikacji:

• Pliki konfiguracyjne modelu Db_MySQL na Db_Layer_MySQL, analogicznie dla innych baz.

Zalecane zmiany:

• Wszelkie define() zamienić na Vframe::_() (argumenty analogiczne) oraz załadować główny plik konfiguracyjny po frameworku (aby uzyskać funkcję statyczną _() ).
• Usunąć V_APP_REAL.
• Aby użyć pluginu Gzip: $oFrontController->Plugin(new Vframe_Controller_Front_Plugin_Gzip(6)); gdzie 6 to stopień kompresji, jeżeli null, wówczas domyślnie 6.

Linki:

• Pobierz Vframe 2.3.1. (wszystkie wersje).
• Źródła online.
• Dokumentacja.
• Pełne repozytorium.

Ostatnio zdenerwowałem się pisząc walidację formularza i nakładanie filtrów na pola formularzy w jednym z panelu administracyjnych. Co chwilę coś nie działało. Framework jest po to, aby unikać takich sytuacji. Aby uniknąć takich sytuacji w przyszłości postanowiłem napisać dość przydatną klasę Vframe_Form integrując ją z Vframe_Validator i Vframe_Input (pluginem POST). Zanim się napisze klasę, wypadałoby napisać mały prototyp.

Tak oto powstała klasa obsługi formularzy oraz jego elementów. Użycie jest bardzo wygodne, po zainicjowaniu $oForm->init() nasz komponent wykonuje filtracje, a następnie walidacje danych wejściowych. Ewentualne błędy można wychwycić poprzez wywołanie metody $oForm->error(’nazwa_pola’); - zwrócony zostanie string w przypadku wystąpienia błędu, null jeżeli go nie ma. Aby sprawdzić, czy wystąpiły jakieś błędy przy walidacji - nie podajemy parametry metody error: $oForm->error(); Zostanie zwrócona liczba błędów (jeden dla każdego pola), jeżeli 0 - możemy wykonać akcję.

Image by Deiru.

Dzisiaj rano światło dzienne ukazało się Agavi 0.11 RC5, oprócz poprawek błędów z wersji RC4 doszło parę nowości: - Pełne wsparcie dla generowania WSDL, automatyczne mapowanie akcji a nawet wsparcie dla obsługi nagłówków SOAP. - Wsparcie dla transformacji plików konfiguracyjnych poprzez zamieszczanie instrukcji < ?xml-stylesheet?> - Wsparcie dla przestrzeni nazw w plikach konfiguracyjnych - Automatyczna obsługa magic_quotes dla zmiennych superglobalnych

Pojawiły się drobne zmiany w API do obsługi configów oraz nowy sposób ich odczytu, który wejdzie do użytku w wersji 1.0. Póki co jest tylko testowy a jedynym handlerem, który został zaimplementowany "na nowo" jest ten obsługujący WSDL.

Dodam, że Agavi to pierwszy framework PHP, który rozwiązuje kwestie dostępu do akcji w tak elastyczny sposób. Niezależnie od tego jakim sposobem zostało przysłane żądanie akcja wygląda tak samo. Jest to krok w stronę dojrzałych rozwiązań tj Spring Framework. Pytanie tylko - czy developerom uda się zachować pierwotną prostotę i ile pracy trzeba będzie włożyć w użycie danego rozwiązania? Odpowiedź na nie pozostaje póki co zagadką a pełnej oceny będziemy mogli dokonać po ukazaniu się wersji 1.0 wraz z dokumentacją.

Zainteresowanych naturalnie Agavi zapraszam do traca i przeglądania źródeł wersji 0.11 RC5. :)