1. UI widgets / DOM manipulation frameworks
2. class based type system frameworks

In this post I would like to focus on the latter. Every time is see a new framework of this type popping on the news I tend to ask myself the same question – why ? Why one does write all does frameworks, why people so much need classes in Javascript ?

After some thinking I’ve got to a conclusion, that people need them mainly because they are used to the concept of the „class” and to a typical type system like this found in Java, PHP or „name your favorite mainstream programming language here”. This is understandable, as naturally human beings are resistive to change.  Also, some people tend to „not get” what’s going on in the prototypical type system. We cannot also blame them here because it has  some quirks and well, no one teaches it in schools ( ;P ).

One may ask himself – do we have an other choices to write clean, readable and understandable code other than using JS frameworks ? I think the answer for this question would be affirmative.

But before we come up for a solution. We must think for a second and summarize what we are trying to achieve. I think that are needs wrap in:

1. new object instantiation
2. information hiding
3. code reuse
4. modularization

The thing that some one will miss would be inheritance. Should it be on the list ? I don’t think so. The reason for the lack of inheritance is simple – inheritance has two purposes:

1. vertical code reuse – the type lower in the hierarchy inherits behavior from the type higher in it
2. signature checking – in statically typed class based languages, polymorphism is achieved through inheritance

we could achieve code reuse by other means in Javascript and as JS has no type checking we don’t need inheritance at all.

For our „no framework JS framework” we will use mainly such features of JS as first class functions and JSON. So behold, some common patterns for our daily JS programming:

//persons module
persons = (function(){

    //private Person object constructor
    var Person = function(firstName, lastName, birthDate){    
        var foo = "bar";
    
        var name = function(){
            return firstName + " " + lastName;
        }
    
        var age = function(){
            var currentYear = (new Date()).getYear()
            var birthDayYear = birthDate.getYear()
            
            return currentYear - birthDayYear      
        }
    
        var saySomething = function(){
            return foo;
        }
        
        //the methods that will be public
        return {
            "name": name,
            "age": age,
            "saySomething": saySomething
        }
    }
    
    //private FitnessAddict object constructor
    var FitnessAddict = function(firstName, lastName, birthDate, weight, height){        
        var person = Person(firstName, lastName, birthDate);
        
        var bmi = function(){
            return weight / (height*height);
        }
        
        var isWeightNormal = function(){
            var currentBmi = bmi()
            if(currentBmi > 25){
                return false
            }
            if(currentBmi < 18.5){
                return false
            }
            return true
        }
        
        //we make isWeightNormal method public
        person.isWeightNormal = isWeightNormal;
        
        return person;   
    }

    //we make the fitnessAddict object constructor public
    return {
        "FitnessAddict": FitnessAddict
    }
})()

Usage of the example:

var fa = persons.FitnessAddict(
    "Bar",
    "Baz",
    new Date(1990,5,5),
    80,
    1.8)
    
fa.isWeightNormal() // true
fa.saySomething() // "bar"
fa.name() // "Bar Baz"    

The first example proves, that we can achieve all of our goals through simple Javascript, without the need for frameworks. The additional benefit is that, because all is private by default, we improve the „cleanliness” of our API.

Jeżeli bym miał podsumować jednym słowem tworzenie kodu w PHP, to tym słowem było by „var_dump”. Pisząc jakiś kod, jesteśmy przyzwyczajeni do tego, że możemy go w każdej chwili zmodyfikować a potem sprawdzić efekty jego działania przy pomocy przywołanej wcześniej metody. Oczywiście są osoby, które w tym celu używają debuggera, jednakże jak wszyscy wiemy, są problemy z jego integracją z różnorakimi IDE i generalnie „var_dump” wydaje się być dość uniwersalnym narzędziem.

Pisząc w Javie, var_dump jest pierwszym z naszych pehapowych przyzwyczajeń, które powinniśmy schować do szuflady. Po pierwsze dlatego, że nie ma odpowiednika takiej funkcji w Javie, a po drugie dlatego, że var_dump driven development nie ma tam żadnych sensownych racji bytu. Dzieje się tak ze względu na czas jaki zajmuje deployment kodu – każda zmiana, jaką wprowadzimy w kodzie Javowym wymaga rekompilacji zmienionych klas i restartu serwera, co może trwać dość długo (np. w moim projekcie taka operacja trwa mniej więcej około 5 minut). Powstały oczywiście pewne solucje by temu zaradzić, takie jak np. podmienianie klas w trakcie działania serwera (Hot Swap), jednakże nie działają one we wszystkich przypadkach (jak dodanie, bądź usunięcie metody jakieś klasy).

Jak więc sobie radzić w takich warunkach ? Po pierwsze, musimy się zaprzyjaźnić z debuggerem. Wkrótce stanie się on naszym najlepszym przyjacielem, na którym będziemy polegać w każdej sytuacji. Debugger jest standardowo wbudowany w każde Javowe IDE, więc nie będziemy mieli żadnych problemów w korzystaniu z niego. Możliwości debuggera są naprawdę potężne i zaczynają się od przechodzenia kodu krok po kroku i podglądania wartości zmiennych, aż po zmianę ich wartości w locie oraz „cofanie się wstecz” w wykonaniu kodu.

Debuggera oczywiście najczęściej będziemy używać przy okazji poprawiania błędów. Jak natomiast sprawa się ma przy tworzeniu nowego kodu ? Tutaj z pomocą przychodzi nam dobrze znana, również z świata PHP technika Test Driven Development. Stosując TDD w kombinacji z debuggerem możemy dość skutecznie i szybko rozwijać nasz kod. Przy czym generalnie obowiązuje zasada, by raczej napisać jak najwięcej kodu przed jego testowaniem – nawet kompilacja testu, mimo, że jest to bardzo mała ilość kodu w porównaniu do całej aplikacji, którą depoloyujemy na serwerze nie jest natychmiastowa i chwilkę trwa. Jeżeli w tej chwili wyobraziliście sobie, że kompilujecie test tylko po to, żeby okazało się, że z jakiś głupich powodów nie działa, to mam dla Was dobrą informacje – dzięki statycznej naturze Javy, wszystkie „głupie” błędy zwykle podkreśli Wam na czerwono Wasz edytor, albo ostatecznie kompilator w momencie kompilacji.

Na koniec jeszcze taka mała uwaga odnośnie plików Javascriptowych. Zwykle bywa tak, że pliki źródłowe JS są częścią naszego Javowego projektu, w konsekwencji one również deployowane są na serwer wraz ze skompilowanymi klasamy Javy. W rezultacie, każda zmiana plików JS wymaga ponownego deployu projektu oraz restartu serwera co jak już wiemy – trwa dość długo. Na szczęście jak zwykle są na to sposoby . Po pierwsze, jeżeli tylko chcemy zmienić coś w JS do celów testowych, to wieść gminna niesie, że narzędzia deweloperskie Chrome’a  pozwalają zmieniać Javascript „w locie”. Po drugie, w przypadku InteliJ Idea, istnieje opcja „update resources”, która podmienia tylko obrazki, js i inne tego typu pliki dość szybko, bez potrzeby restartu serwera.

Tym radosnym akcentem kończę ten artykuł i ogłaszam, że jest to już ostatni wpis z serii „Kierunek Babilon”, oczywiście dalej zamierzam pisać o PHP i Javie, ale już w trochę innym kontekście.

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:

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. łatwego sposóbu na tworzenie immutable data types, chociażby a’la Scala:

    case class User(firstName: String, lastName: String, birthday: Date) 

2. Anonimowe klasy
3. Wsparcie dla przetwarzania równoległego / wielowątkowego – jest w postaci aktorów (podziękowania dla wookieba)
4. Przestrzeni nazw / modułów
5. „Odwróconych” interfejsów a’la GO, czyli coś w rodzaju:

   class Test {
       Integer foo(){
           return 1;
       }
   }
   
   interface Foo {
        Integer foo();
   }
   
   Foo someFoo = new Test(); /* ok! - nie ma błędu -
   klasa Test nie deklaruje, że implementuje interfejs Foo,
   ale sygnatura jej metod jest zgodna z nim */
   

   Więcej na stronie 8tlight

Jestem ciekaw jaka jest Wasza opinia ?

Poprzedni tytuł „La Galere / Propaganda Kapitana Pazura”, już jakiś czas przestał pasować do treści strony, z prostej przyczyny jaką było przeniesienie prywatnych przemyśleń na mój drugi site. Ten blog stał się stricte zawodowo – programistyczny, postanowiłem więc ujednolicić tytuł z podpisem na goldenline – „programista eksplorator”. Dzięki takiemu ujednoliceniu chce podkreślić takie cechy mojej osoby, jak kreatywność, skłonność do patrzenia na problemy z różnych perspektyw oraz szeroki zakres wiedzy zawodowej jaki mam nadzieje posiadam ( ;p ).

Mam nadzieje, że będziecie tak często (albo nawet częściej) odwiedzać moją stronę jak dotąd .

public class Produkt {
    private Integer cena = 0;
    private Integer ilosc = 0;
    private String nazwa = "";

   public Produkty(Integer cena, Integer ilosc, String nazwa);

    /** tu gettery i settery dla wszystkich parametrow parametrow **/

}

public class Koszyk {

    private List<Produkt> produkty;

    public List<Produkty> getProdukty();
    public void setProdukty(List<Produkty> produkty);

}

public class KoszykUtil {

    public static Integer podliczKoszyk(Koszyk koszyk){
        List<Produkty> produkty = koszyk.getProdukty();
        Integer suma = 0;        

        for(Produkt produkt: produkty){
            suma+= produkt.getCena() * produkt.getIlosc();
        }
        return suma;
    }
}

Produkt p1 = new Produkt(12, 1, "baton z ropą");
Produkt p2 = new Produkt(13, 1, "baton z benzyną");
List<Produkty> produkty = new ArrayList<Produkty>();
produkty.add(p1);
produkty.add(p2);

Koszyk k = new Koszyk();
k.setProdukty(produkty);

Integer suma = KoszykUtil.podliczKoszyk(k);
System.out.println(suma);

Obiektowo:

public class Produkt {

    private final String nazwa;
    private final Integer cena;
    private Integer ilosc;

    public Produkt(String nazwa, Integer cena, Integer ilosc);
    public Integer suma(){
        return cena*ilosc;
   }

}

public class Koszyk {

    private List<Produkt> produkty;
    private Integer wartosc = 0;    

    public dodajProdukt(Produkt produkt){
        produkty.add(produkt);
        wartosc += produkt.suma();
    }

    public Integer wartosc(){
        return wartosc;
    }
}

Koszyk k1 = new Koszyk();
Produkt p1 = new Produkt("baton z benzyna" , 10, 1);
Produkt p2 = new Produkt("baton z ropą", 10, 1);
k1.dodajProdukt(p1);
k1.dodajProdukt(p2);

Integer suma = k1.wartosc();
System.out.println(suma);

Funkcyjne:

public interface Sumator<D> {

     public Integer sumuj(Integer suma, D element);
}

public class ListUtil {

    public static <T> Integer sumuj(Sumator s, List<T> dane) {
        Integer suma = 0;
        for (T element : dane) {
            suma = s.sumuj(suma, element);
        }
        return suma;

    }
}

public final class Produkt {
    public final Integer cena;
    public final String nazwa;

    public Produkt(String nazwa, Integer cena){
        this.nazwa = nazwa;
        this.cena = cena;
    }
}

Produkt p1 = new Produkt("baton z ropą", 10);
Produkt p2 = new Produkt("baton z benzyna", 10);

List<Produkt> produkty = new ArrayList<Produkt>();
produkty.add(p1);
produkty.add(p2);

produkty = java.util.Collections.unmodifiableList(produkty);
Integer suma = ListUtil.sumuj(new Sumator<Produkt>() {

            @Override
            public Integer sumuj(Integer suma, Produkt element) {
                return suma + element.cena;
            }
        }, produkty);

System.out.println(suma);

Czego można dowiedzieć się z tych prostych przykładów ? Otóż można zauważyć w każdym z nich cechy charakterystyczne danego stylu programowania i tego na co kładzie nacisk.

1. Proceduralny – stawia na swobodny przepływ danych.
2. Obiektowy – abstrakcja, enkapsulacja, odwzorowanie modelu domeny
3. Funkcyjny – niezmienność (immutability), generyczność i funkcja jako pełnoprawny element języka (tutaj emulowana przez anonimową klasę)

Mam nadzieje, że powyższe przykłady były pouczające.Jestem bardzo ciekawy, które z powyższych rozwiązań przypadło Wam do gustu i dlaczego, oraz jaki styl preferujecie.

Dla przypomnienia, powody, dla których postanowiłem zmienić środowisko z PHP na Javę:

1. Rodzaj projektów – miałem dość projektów typu „strona – wizytówka”, portali, cms-ów etc
2. Organizacja pracy – brak sformalizowanego procesu wytwarzania oprogramowania, brak specyfikacji, metodologii etc
3. Zarobki

Czy wobec perspektywy tych trzech powodów, zmiana miała sens ? Jak najbardziej ! Po półtora tygodnia pracy mogę powiedzieć że:

1. Uczestniczę w projekcie a raczej w rozwoju produktu ze skomplikowaną logiką biznesową
2. Proces wytwarzania kodu jest ściśle sformalizowany
3. Oprócz zdecydowanej podwyżki, w stosunku do „PHP-owego okresu mojej kariery”, mam do dyspozycji wiele bonusów (tzw. socjału oraz szkoleń)

Największą różnicą między tym co dotychczas robiłem a tym co teraz robię jest przede wszystkim rozmach. Realizując projekty PHP-owe dotychczas pracowałem zwykle sam, lub maksymalnie w około 5-cio osobowym zespole, który pracował zwykle w jednym pokoju biurko w biurko.

W obecnej pracy, jestem członkiem działu (nie mylić z oddziałem), który tylko w Polsce liczy ponad 100 osób (w firmie, która tylko w Polsce zatrudnia około 1200 osób), jestem członkiem jednego z 4ech zespołów pracujących nad jednym produktem i bezpośrednio współpracuje z około 20-toma osobami. To dość duża zmiana mentalna.

Jeszcze większą mentalną zmianą jest to, że często się zdarza, że nad jednym „user story” (odpowiednik pojedynczego „ficzera”) pracuje nierzadko z kilkoma osobami. Zmienia to zupełnie sposób pracy i wymaga ciągłej komunikacji, zrozumienia i trzymania się ściśle ustalonych standardów.

Kolejnym faktem, który wiele zmienia, są Unit Testy. Pierwszy raz, rozwijam aplikację, której część biznesowa jest prawie w całości pokryta testami jednostkowymi (bo w przypadku frameworków to jest norma).

Generalnie wiele rzeczy prowadzonych jest „książkowo”, jak np. praca w metodyce Scrum. Codzienne „standupy”, iteracje i ich planowanie – uczestniczę w nich i widzę, że ma to sens.

Wracając do rzeczy czysto programistycznych mogę powiedzieć tyle, że łyknąłem już dość dużo Javy, przede wszystkim wszelakich adnotacji i typów generycznych, sposobu obchodzenia się z projektami – Maven, integracja z IDE, debbugger, Tomcat oraz frameworki JUnit oraz Mockito.

Cały czas tutaj wymieniam plusy i zalety, natomiast nie wspomniałem o kilku rzeczach, które można by nazwać wadami tej roboty. Pierwsze co od razu rzuciło mi się w oczy to dość duża biurokracja – na wstępie musiałem wypełnić 11-stronnicowy formularz. Druga kwestia to niestety nieproporcjonalność wyposażenia mojego laptopa do ogromu projektu (poranny update potrafi trwać nawet 15 minut !) – niestety nawet 4gb ramu i najnowszy Core i5 nie zapewniają w jego przypadku komfortowej pracy.

Tak więc pokrótce wyglądają moje wrażenia z pierwszego tygodnia pracy. Jeżeli ktoś chciałby również spróbować pracy w „corpo” z Javą, dajcie znać, chętnie Was polecę

Zastosowań jest całe multum, natomiast chyba najbardziej przydatna jest ta funkcja dla twórców wszelakiej maści frameworków i bibliotek (szczególnie ORM). Dzięki niej, nie trzeba już będzie korzystać ze sztuczek z serialize/deserialize, by stworzyć obiekt z pominięciem konstruktora.

Nic z tych rzeczy. Ci, którzy mnie znają bliżej, wiedzą, że często mówiłem o Javie i jej ekosystemie jako o „Babilonie”. Skojarzenie z tym historycznym państwem jest jak najbardziej na miejscu – państwo Babilońskie miało bardzo złożoną strukturę i było bardzo zbiurokratyzowane (prawie jak dzisiejsza Unia Europejska ;P ). Taka jest też Java – masa bibliotek, frameworków i mało ekspresywny język, w którym za każdym razem trzeba napisać masę „boilerplate code” – czyli powtarzalnego kodu, który musi być wklepany, żeby wszystko działało.

O co więc chodzi z kierunkiem ? Żeby się dużo nie rozwodzić to powiem tyle, że zmieniam pracodawcę. Dzisiaj podpisałem umowę z firmą Sabre Holdings, która jak może wiecie albo i nie, jest jak się to mówi „Java shopem”. Większość oprogramowania tworzy się tam w Javie z dodatkiem Javascriptu i HTML dla webowego frontendu. Taka też będzie moja praca na stanowisku Java/Web developer i głównie będę używał wspomnianych trzech języków.

W związku ze zmianą pracy nie będę miał okazji na co dzień programować w PHP. Wielu może się dziwić takiej decyzji, Radek Benkel np. zapytał mnie skąd ta decyzja, bo język coraz bardziej się „ogarnia”. Śpieszę więc z wyjaśnieniem.

Pierwszą kwestią, która mnie skłania do zmiany języka jest rodzaj projektów jakie się w nim tworzy. Powiedzmy sobie szczerze, rynek jest nasycony agencjami interaktywnymi, które głównie specjalizują się w robieniu „stronek”, głównie w celach marketingowych oraz informacyjnych. Blogi, fora dyskusyjne, CMS-y, mailing, na tych kilku hasłach generalnie kończy się repertuar tej klasy firm. Oczywiście zdarzają się też inne rzeczy, czasami jakieś dedykowane aplikacje, ale jest to generalnie mniejszość. W pewnym momencie człowiek ma dość „klepania” tego samego i szuka odmiany.

Drugą kwestią jest organizacja pracy, w większości firm „PHP-owych” w których pracowałem nie było żadnego sformalizowanego procesu wytwarzania oprogramowania. Minimalne specyfikacje, opierające się na makietach, niejasne oczekiwania klienta, brak projektantów czy architektów. Mam wrażenie, że firmy używające Javy, będące w dużej części korporacjami, są pod tym względem lepiej zorganizowane.

Trzecią kwestią są oczywiście zarobki i popyt na programistów. Ofert pracy w Javie jest naprawdę wiele. Co więcej nie są to oferty typu „murarz, tynkarz, akrobata” gdzie firma szuka gościa, który zrobi grafikę w Photoshopie, potnie ją do HTML/CSS w sposób idealny, oprogramuje, postawi na serwerze i jeszcze weźmie za swoją robotę 50 zł. Konkretnych ofert jest na prawdę mało.

Co do zarobków to różnica jest dość istotna. Realnie zarobki Javowca zaczynają się tam gdzie kończą PHPowca.

Podsumowując zmieniam pracę i zmieniam technologię, żeby się rozwijać. Żeby zyskać inny punkt widzenia na pewne sprawy. Myślę, że w naszym zawodzie jest to bardzo ważne. Co więcej, jako, że w przyszłości chce założyć własną firmę, uważam, że głęboki przegląd przez różne technologie obecne na rynku może się wydatnie przełożyć na mój sukces.

Na koniec chciałbym również uspokoić wszystkich, który namiętnie czytają mojego bloga (:P). Dalej zamierzam pisać o PHP i myślę, że będzie to nawet ciekawsze pisanie, bo będę mógł przy okazji porównywać go z Javą i innymi technologiami obecnymi na JVM. Nie jest to więc pożegnanie, a zapowiedź nowego rozdziału, nowej jakości

Kiedy się to może przydać ? Prosty przykład, stosujemy wzorzec obserwator. Obserwowany obiekt zwany też podmiotem rejestruje subskrybentów, których będzie powiadamiał o zmianie swojego stanu. Takich subskrybentów może być bardzo wielu. Może się zdarzyć, że któryś subskrybent mógłby już zostać usunięty z pamięci przez GC, gdyby nie ta ostatnia referencja, którą trzyma podmiot. W efekcie przy wielu obiektach subskrybentów, tracimy niepotrzebnie pamięć. Rozwiązaniem jest zastosowanie słabej referencji. Dzięki niej, w momencie, gdy wszystkie inne zewnętrzne referencje do danego subskrybenta wygasną zostanie on od razu zebrany przez GC.

Implementacja zaproponowana w RFC postuluje stworzenie klasy SplWeakRef. Jej zastosowanie będzie wymagało tylko przekazania do jej konstruktora zmiennej do obiektu, który ma być słabą referencją.

class Foo {}

$foo = new Foo; //reference count 1
$bar = $foo; //reference count 2

$slabaReferencja = new SplWeakRef($foo); //reference count 2

Jestem ciekaw co sądzicie o tej propozycji ? Osobiście wydaje mi się dość ciekawa, natomiast chyba pole zastosowań jest naprawdę bardzo małe, a potencjalnie może być ten „ficzer” bardzo niebezpieczny w rękach początkujących programistów. Osobiście zamiast tego mechanizmu, wolałbym możliwość deklarowania klas tak, by ich obiekty były przekazywane przez kopię, tak jak typy proste. Moim zdaniem dużo bezpieczniejsze rozwiązanie a efekt podobny.

• usprawnione opisy błędów parsera
• wbudowany deweloperski mini serwer www

O innych nowościach i zmianach możecie przeczytać w logu.