Ostatnio dużo słyszymy o Symfony2. Dzisiaj postanowiłem się zachować jak prawdziwy oldschoolowiec i napisać posta o symfony 1.x . PHPCS (PHP_CodeSniffer) jest narzędziem które pozwala nam wykrywać naruszenia naszego standardu kodowania. Pokaże tutaj jak skonfigurowałem sobie PHPCS do projektów opartych o symfony 1.x. Jednak uważam że można spojrzeć na ten post również z perspektywy innych [...]

W dniu 12 października miałem przyjemność wygłosić krótki wykład i poprowadzić sesję livecodingu w ramach inicjatywy meetjs. Poniżej załączam linka do prezentacji na SlideShare, w formie PDFa oraz do repozytorium z kodem powstałym podczas livecodingu.

meet.js – QooXDoo View more presentations from singlespl

PDF do pobrania: meet.js QooXDoo – prezentacja Kod: GitHub

Jednym z najbardziej znanych komponentów ZendFramework’a jest Zend_Form. Na temat tego komponentu powiedziano wiele dobrego i złego, a opanowanie go nie należy do rzeczy stosunkowo łatwych. Dekoratory, filtry, validatory – sporo rzeczy do nauki. Dzisiaj chciałbym jednak skupić się na problemie dość często spotykanym i jego rozwiązaniu. Mianowicie chodzi o sprawdzenie, czy dana wartość jest większa od zadanej, ale w momencie, kiedy nie jest ona liczbą całkowitą.

Przykład

Przypuścmy, ze mamy formularz, w którym musimy zdefiniować cenę przedmiotu, ale nie może ona być niższa niż 0,90zł. Kod realizujący to zadanie z wykorzystaniem Zend_Form mógłby wyglądać następująco:

$form = new Zend_Form();
$element = new Zend_Form_Element_Text('val');
$element->addValidator(new Zend_Validate_GreaterThan(array('min' => 0.90)));
$form->addElement($element);
 
//input values
$data = array('val' => "0,93");
 
var_dump($form->isValid($data)); // false

Dlaczego dane nie zostały uznane za prawidłowe? Z prostego powodu – w Polsce cześć ułamkową zapisujemy po przecinku, a nie po kropce. Podczas porównania PHP zamienia ciąg tekstowy na liczbę, co w wyniku prowadzi do porównania 0 z 0,90.

echo (float)'0,'93'; //gives 0

Rozwiązanie

Rozwiązaniem tego problemu, jest zmiana wartości zlokalizowanej na znormalizowaną. Dokonać tego możemy automatycznie za pomocą mechanizmu filtrów, gdyż są one stosowane przed walidacją. Musimy dopilnować, żeby przed walidacją wartość 0,90 wyglądała tak: 0.90. Rozwiązaniem będzie zastosowanie filtra przeznaczonego specjalnie dla tego celu, mianowicie: Zend_Filter_LocalizedToNormalized (patrz dokumentacja). Automatycznie rozpoznaje on używane locale i zwraca znormalizowaną wartość. Poprzedni przykład, tym razem działający:

$form = new Zend_Form();
$element = new Zend_Form_Element_Text('val');
$element->addValidator(new Zend_Validate_GreaterThan(array('min' => 0.90)));
$element->addFilter(new Zend_Filter_LocalizedToNormalized()); // !
$form->addElement($element);
 
//input values
$data = array('val' => "0,92");
 
var_dump($form->isValid($data)); //true

Uwagi

Warto rozważyć także używanie filtra odwrotnego Zend_Filter_NormalizedToLocalized w momencie wyświetlania danych w formularzu. Warto zwrócić uwagę na fakt, że filtrów i walidatorów używać można także bez formularza – ww. filtr przydać może się przy zapisywaniu danych w DB.

Nie tak dawno temu pojawiła się informacja jakoby Google pracował nad nowym językiem programowania, dedykowanym dla www. Jedyne co było znane, to nazwa – Dart. Wczoraj rano na jednym z blogów Google’a można było przeczytać, iż Dart został wypuszczony na świat jako wersja preview, celem zdobycia informacji zwrotnych od programistów.

Czym jest Dart? Jest to język bazujący na klasach, z możliwością statycznego typowania. Według informacji zawartej na blogu, dowiadujemy się że Dart:

• umożliwia strukturalne tworzenie aplikacji
• jest prosty do nauki
• jest szybki i wydajny

Ponadto Dart ma działać zarówno w przeglądarce (kompilowany przez silnik przeglądarki do postaci JavaScript) jak również na natywnej maszynie wirtualnej. Tyle obietnice, a jak to wygląda od środka?

Klasy

Dart jest “językiem klamrowo-średnikowym”, co na pewno wielu ucieszy. Składnia przypomina JavaScript/ActionScript z domieszką PHP/C#. Innymi słowy jest podobny do większości popularnych języków, co z pewnością przełoży się na szybkość uczenia. Mimo iż jak mantrę powtarza się structured web programming, Dart klasami stoi. To przy ich pomocy tworzy się API, to one służą do tworzenia kodu wielokrotnego użytku. Podobnie jak w większości języków, klasa może dziedziczyć tylko po jednej klasie (wyjątkiem jest tutaj klasa Object, która nie dziedziczy po żadnej klasie). Klasa składa się z konstruktora oraz składników instancji i składników statycznych (raczej nie trzeba wyjaśniać czym to się różni). W obu przypadkach składnikami klasy są metody, gettery, settery oraz zmienne. Jeśli dodamy do tego klasy abstrakcyjne oraz interfejsy, poczujemy się jak w domu (zwłaszcza programiści PHP).

Kolejną wyróżniającą cechą języka są konstruktory. Obok dobrze znanego z PHP 4 (lub C#) konstruktora, pojawiły się dwa kolejne – fabryka oraz konstruktor nazwany. Fabryka nie wymaga specjalnych wyjaśnień – jest to natywna implementacja wzorca o tej samej nazwie. Znacznie ciekawszy jest konstruktor nazwany, pozwalający przeciążyć konstruktor, dając tym samym możliwość utworzenia obiektu na kilka sposobów.

Operatory

Czymś niespotykanym w PHP i JavaScript jest przeciążanie operatorów, które podobnie jak np. w C# są metodami. Dlaczego jest to interesujące? Ponieważ pozwala nadpisać większość operatorów i dopasować je do naszych potrzeb. Oznacza to, że możemy od nowa zdefiniować operator sumowania i sprawić, by np. “dodawał” do siebie dwa obiekty.

Warty wspomnienia jest operator porównania, występujący w dwóch postaciach. Tak samo jak w JavaScript i PHP możemy porównywać dwie wartości przy pomocy == (!=) oraz === (!==). Zasadniczą różnicą jest to, że pierwsza postać działa tak jak powinna, czyli nie dokonuje konwersji typu. Drugi rodzaj służy do sprawdzenia tożsamości. Mówiąc wprost, sprawdza on czy obiekt a i obiekt b to ten sam obiekt w pamięci.

Typowanie statyczne i typy generyczne

Wspomniałem na początku, że Dart jest językiem umożliwiającym statyczne typowanie. Sprowadza się to do wskazania typu zmiennej, argumentu funkcji lub zwracanej przez nią wartości. Jeśli zależy nam na elastyczności możemy z tego zrezygnować i skorzystać z dynamicznego typowania. Poza “typowym typowaniem”, Dart został uzbrojony w coś, czego nie ma ani w PHP, ani w JavaScript – typy generyczne. W skrócie, typy generyczne pozwalają na tworzenie aplikacji bez wcześniejszej znajomości typów danych, którymi aplikacja będzie operować. W przypadku C# typy generyczne znacząco podnoszą wydajność kodu operującego na kolekcjach oraz uodporniają kod na błędy wykonywania (runtime errors).

Inne smaczki

Wymienione wyżej elementy języka są tylko niewielkim fragmentem Darta. Obok nich w języku znajdziemy między innymi bloki, które mimo podobieństwa w nazwie mają niewiele wspólnego z blokami znanymi z Ruby. Jeśli miałbym je do czegoś porównać, to byłyby to tuple z Pythona. W Dart, wykonanie bloku oznacza wykonanie każdego elementu kolekcji znajdującego się w bloku.

Na pewno interesująco prezentuje się współbieżność, zbudowana w oparciu o isolates (nie znam polskiego odpowiednika tego słowa). Ponieważ Dart jest językiem jednowątkowym, aby móc skorzystać z przetwarzania współbieżnego, musimy użyć wspomnianych isolates, gdzie każdy isolate to osobny wątek (istnieje możliwość utworzenia isolate w tym samym wątku). Isolates nie współdzielą między sobą żadnych danych, a jedyny sposób komunikacji między nimi, to przesyłanie wiadomości (message passing), działające podobnie jak przesyłanie wiadomości między skryptami w rozszerzeniach Google.

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

Zwiń
Czytaj na blogu autora...

Dzisiaj Google zaprezentował na blogu chromium pierwsze informacje na temat swojego nowego języka „Dart”. Dart prezentowany jest przez firmę z Mountain View jako język do „strukturalnego programowanie webowego”, mający docelowo zastąpić Javascript w roli głównego narzędzia do pisania aplikacji webowych po stronie przeglądarki. Postanowiłem przyjrzeć się szybko jak język ten wygląda i podzielić się pierwszymi wrażeniami jakie mi przyszły do głowy. W dalszej części artykułu, będę się opierał na jednym z artykułów, który jest mini tutorialem do Darta i przedstawia dość obszernie kod, który zwykle jest używany przez programistów jak i różne Dartowe smaczki.

Na pierwszy rzut oka Dart wygląda na kolejny klon Javy / C# z większym podobieństwem do C#. Jak każdy w miarę nowoczesny język posiada funkcje anonimowe i domknięcia. Jest oparty na klasach więc większość osób łatwo się w nim odnajdzie. Jest to główna i fundamentalna różnica pomiędzy Dartem a Javascriptem, oprócz oczywiście składni. Poza tą różnicą Dart wspiera DSL (domain specific languages), dzięki temu, że podobnie jak w Scali, operatory są tak naprawdę zwykłymi metodami, czyli mamy możliwość wywoływania metod bez użycia kropki. Dart wspiera też opcjonalne typowanie – możemy zadeklarować typ zmiennej i będzie on sprawdzony w czasie kompilacji.

Jeżeli porównamy Darta do PHP, to oprócz wcześniej wymienionych ficzerów jedyną w zasadzie różnicą będzie obsługa funkcji akcesorowych znanych z C# (metod prefiksowanych przez get/set).

Dart posiada jeszcze kilka mniej znaczących smaczków, które są głównie lukrem składniowym i mogą być z łatwością odtworzone przy użyciu innych konstrukcji językowych. Pierwszym z takich smaczków są nazwane konstruktory – czyli googlowy sposób na przeciążanie konstruktora w języku dynamicznie typowanym nieobsługującym przeciążania metod. Drugi sposób to metody fabryczne, czyli metody klasy poprzedzone słowem kluczowym „factory”, ich zastosowanie jest dla mnie generalnie mało zrozumiałe. Ostatnim „ficzerem” jaki zauważyłem są „krótkie konstruktory, które oszczędzają nam trochę pisania – zamiast pisać:

class Point {
    num x, y;
    Point(num x, num y) {
        this.x = x;
        this.y = y;
    }
}

Można napisać tak:

class Point {
   num x, y;
   Point(this.x, this.y);
}

Podsumowując – szału nie ma. Co jak co, ale po Google spodziewałem się więcej. Czego mi brakuje ?

1. Większego nacisku na programowanie funkcyjne – np. łatwy sposób na tworzenie nie mutowalnych typów danych
2. Anonimowe klasy
3. Wsparcie dla przetwarzania równoległego / wielowątkowego
4. Przestrzeni nazw / modułów

Jestem ciekaw jaka jest Wasza opinia ?

Ponad rok temu opisywałem na blogu różne techniki Cross-Domain JavaScript, czyli obejścia Same origin policy dla żądań XHR w języku JavaScript. Czas powrócić do tematu i rozszerzyć zawartą tam wiedzę, bowiem konsorcjum W3C wyprowadziło nową specyfikację dla Cross-Origin Resource Sharing, a wszystkie nowoczesne przeglądarki zdążyły już ją zaimplementować, stąd mamy prostsze rozwiązanie problemu :) Cross-Origin [...]

wstęp

Na potrzeby wszystkich wpisów z tej serii zdecydowałem się, w miarę możliwości, skupić je wokół jednego przykładu. Oczywiście nie będę przeprowadzał żadnej analizy wymagań, ani specjalnie rozwodził się nad całą strukturą i pełną funkcjonalnością, będę poruszał jedynie te aspekty aplikacji, które będą bezpośrednio powiązane z danym wpisem. Dzięki takiemu praktycznemu przykładowi mam nadzieję, że uda mi się przedstawić myślenie, które kryje się za większością decyzji projektowych oraz pozbędę się zbędnego teoretyzowania i przykładów, które nijak nie pokrywają się z rzeczywistością.Dzisiaj chciałbym skupić się na atrybutach klasy, więc na początek trochę teorii.

let's start

Atrybuty klasy są czymś, co odróżnia od siebie jej konkretne instancje, umożliwiają one identyfikację obiektów.Można podzielić je na dwa rodzaje:

• typów podstawowych: boolean, string, integer, float
• obiekty, które realizowane są jako agregacja, częściowa lub całkowita (kompozycja)

Atrybuty typów podstawowych są to dane bezpośrednio dotyczące instancji obiektu, natomiast agregacje są to swego rodzaju jego części składowe np. atrybutem budynku jest jego wysokość (typ podstawowy), budynek jednak zawiera też pewną ilość mieszkań (obiekty).Agregację dodatkowo można podzielić na:

• częściowa - oznacza to mniej więcej tyle, że zawieranie nie jest konieczne dla istnienia obiektu głównego i zawieranego np. jabłko zawiera robaka (i jabłko i robak mogą sobie spokojnie istnieć bez siebie:)
• kompozycja - oznacza to, że obiekty składowe nie mogą istnieć bez obiektu głównego ani nie mogą być współdzielone z innymi obiektami. Zostają one usunięta wraz z obiektem głównym np. blok z mieszkaniami.

a gdzie array?

Może niektórzy z Was zwrócili uwagę, że wypisując dwa rodzaje atrybutów, nie uwzględniłem tam typu array. Dlaczego? Ponieważ tablica jest po prostu zbiorem innych typów. Jeżeli tworzymy klasę powinniśmy zadbać o to, aby atrybut, który jest tablicą składał się z elementów tylko jednego typu. Rozumiem, że w dokumentacji PHP często można się spotkać z 'typem' mixed, ale u Was nie powinno być dla niego miejsca. Co jeżeli jednak tablica okazuje się zawierać różne typy i nijak nie da się tego inaczej zrobić? Może to oznaczać dwie rzeczy:

• należy utworzyć klasę, a elementy tablicy powinny być jej atrybutami. Oczywiście to rozwiązanie można zastosować tylko wtedy, gdy taka klasa będzie posiadała logiczny sens
• należy usiąść do projektu jeszcze raz i zastanowić się, gdzie jest błąd:)

widoczność atrybutów

Ogólnie jestem zdania, że każdy atrybut klasy powinnien być prywatny. W końcu jednym z głównych paradygmatów progamowania obiektowego jest hermetyzacja, co wyraźnie mówi, że nie powinno się udostępniać swoich wnętrzości światu. Stosowanie atrybutów chronionych, jeżeli wiemy, że klasa będzie rozszerzana? Takie coś również do mnie nie przemawia, wolę stworzyć chroniony getter i/lub setter, a atrybut i tak zostawić prywatny, nawet jeżeli jest to klasa abstrakcyjna. Ale to już moje osobiste zdanie i niejedną dyskusję na ten temat toczyłem i wiem, że w takich przypadkach wielu programistów stosuje jednak atrybut protected.A co z atrybutami publicznymi? Coś takiego byłbym w stanie zrozumieć, jeżeli miałbym klasę z x liczbą atrybutów, która wymagałaby setterów i getterów dla każdego z nich. W takim wypadku rzeczywiście rozsądniej byłoby uczynić je publicznymi. Jednak w czasie swojej kariery programisty nigdy nie spotkałem się z sytuacją, aby obiekt wymagał osobnego gettera i settera dla każdego atrybutu i ciężko mi wyobrazić sobie, aby taka funkcjonalność mogła mieć jakieś logiczne uzasadnienie.

nie mieszaj typów

Zdaję sobię sprawę, że PHP umożliwia przypisywanie do jednej zmiennej wartości różnych typów, ale jest to coś, czego nie powinno się robić, a już z pewnością nie w odniesieniu do atrybutów klas. Jeżeli mam jakiś atrybut typu string, to powinnien on być tego typu, nie integer, float, czy object, a tylko i wyłącznie string. Wiem, że dla wielu to oczywiste, ale mimo wszystko...

odrobina praktyki

Załóżmy, że naszym zadaniem jest stworzenie systemu dla firmy transportowej. Jednym z głównych części składowych ma być baza kontrahentów. Przy dodawaniu kontrahenta użytkownik musi określić jego NIP oraz unikalną nazwę. Musi istnieć możliwość wystawiania i przesyłania drogą mailową faktur za usługi firmy oraz musi być możliwość wykonania przelewu na konto kontrahenta, z którego usług korzystała firma. Firma jest międzynarodowa, więć musi istnieć możliwość obsługi różnych walut. Niektórzy kontrahenci mają kilka osób, do których chcą aby były wysyłane faktury na maila. Dodatkowo powinna istnieć możliwość określenia adresu siedziby kontraheta.Na podstawie powyższego spróbujmy określić atrybuty dla klasy kontrahent.Pierwszą rzeczą, którą wiemy jest to, że kotrahent musi posiadać NIP i nazwę:

<?phpclass Contractor {  private $_nip; //string  private $_name; //string}

Kontrahent może posiadać wiele kont przypisanych do przelewów w różnych walutach. Ponieważ numer konta i waluta są ściśle ze sobą powiązane decydujemy się na utworzenie kolejnej klasy reprezentującej konto bankowe:

<?phpclass BankAccount{  private $_number; //string  private $_currency; //string}class Contractor {  private $_nip; //string  private $_name; //string  private $_bankAccounts; //BankAccount[]}
        
                    

            

                Czytaj dalej tutaj (rozwija treść wpisu)

                Czytaj dalej na blogu autora...            
            

            

                Zwiń

                Czytaj na blogu autora...