http://ferrante.pl/frontend/javascript/w-dobie-html5-stan-spolecznosci-frontend-w-polsce/
Interesujący artykuł przekrojowy o polskim frontendzie
2011/07/08 – 10:24
JavaScript MVC
2011/06/08 – 14:55
Interesowałem się ostatnio podejściem do pisania aplikacji JavaScriptowych w oparciu o wzorzec projektowy MVC.
Znalazłem dość ciekawy artykuł na ten temat – polecam jako wstęp do zagadnienia, gdzie autor szkicuje aplikację w oparciu o ten wzorzec:
http://www.alexatnet.com/content/model-view-controller-mvc-javascript
Nie mamy tu do czynienia z żadnym pełnoprawnym frameworkiem, jednak jest to ciekawy przykład – w jaki sposób można podejść do tematu MVC w JavaScript.
Grzebiąc po sieci dalej, trafiłem na (doskonale wypozycjonowaną) stronę http://javascriptmvc.com/ – tutaj mamy już pełen framework. Interesujące rozwiązanie, jednak prawdopodobnie skupię się na sprawdzeniu Backbone: http://documentcloud.github.com/backbone/
Wydaje mi się, że już teraz mogę polecić Backbone z kilku względów:
1) Nie jest to pierwszy raz kiedy słyszę o tym frameworku – cieszy się on dobrą renomą
2) Wystarczy spojrzeć na listę przykładów, gdzie Backbone zostało wykorzystane – całkiem imponujące 
3) Dokumentacja – bardzo ładnie rozpisana. Lubię, kiedy dokumentacja jest czytelna.
4) Czytając dokumentację stwierdziłem, że to podejście mnie przekonuje. Podoba mi się:
a) fajny podział na modele, kontrolery, widoki
b) kolekcje modeli, wygodne rozwiązania do synchronizacji z backedem, ale także przeszukiwania, filtrowania, sortowania itd po stronie client-side ( wykorzystano tu Underscore.js )
c) elegancka obsługa zdarzeń (ważne przy MVC), aktualizacja modelu może automatycznie aktualizować widok
d) co bardzo fajne, kontrolery automatyzują obsługę routingu opartego o część URL-a znajdującego się po # (hashu)
Jeśli już mówimy o MVC, to myśląc o View – przychodzi mi do głowy jeszcze system szablonów.
Backbone nie narzuca tu jedynego słusznego rozwiązania. Możemy widoki realizować “z palca”, używając np. jQuery, możemy także skorzystać z bardziej rozbudowanego systemu. Jednym z polecanych przez twórców Backbone rozwiązań jest Mustache.js.
Mustashe realizuje wszystko to, co system szablonów realizować powinien: zmienne, iteracje, instrukcje warunkowe itd.
Node.js – jak rozpocząć – część I – instalacja
2011/05/16 – 21:41
1. Instalacja całego tego bajzlu.
Do nauki samego JavaScriptu nie potrzeba zbyt wielu narzędzi. Na początek wystarczy edytor tekstu i przeglądarka WWW, która pełni rolę środowiska uruchomieniowego.
W przypadku node.js sytuacja wygląda trochę gorzej, ponieważ to node.js jest środowiskiem uruchomieniowym w którym uruchamiać będziemy skrypty pisane w języku JavaScript. Środowisko to trzeba więc sobie zainstalować.
Jeśli chodzi o instalację, to tylko po krótce odeślę to źródeł:
Oficjalna instrukcja instalacji node’a (wszystkie dostępne systemy):
https://github.com/joyent/node/wiki/Installation
Instrukcja instalacji node.js pod Windows:
https://github.com/joyent/node/wiki/Building-node.js-on-Cygwin-%28Windows%29 – kompilacja ze źródeł / cygwin
http://node-js.prcn.co.cc/ – Skompilowane wersje nodejs bez konieczności ręcznego kompilowania.
Osobiście instalowałem node.js i na windowsie i na linuxie (ubuntu). O ile instalacja pod linuxem jest stosunkowo prosta, o tyle instalacja pod windowsem paradoksalnie (lub nie) jest trudniejsza i może sprawić trochę kłopotów. Przynajmniej tak było jeszcze w czasach node 0.2. Na szczęście od wersji 0.2 sporo wody upłynęło w serwerowej rzece i wydaje mi się, że powinno być z tym znacznie mniej kłopotów. Ostatecznie, w razie czego, zawsze można poprosić o pomoc wujka. Wujka Google. 
Oprócz samego node.js koniecznie należy zainstalować NPM – Node Package Manager. Jest to manager instalowania dodatków do node.js. Dwa takie “must have” dodatki to:
socket.io
express
Aby je zainstalować, należy wywołać NPM z następującymi parametrami:
$ npm install socket.io
$ npm install express
Jeśli wszystko poszło dobrze, to aby uruchomić nasz program należy odpalić w konsoli:
node /sciezka/do/naszego/skryptu.js
W następnym odcinku – nodo.jotesowe hello world.
Node.js – sieć czasu rzeczywistego
2011/04/09 – 19:44
Pisanie własnego serwera usług WWW to duże wyzwanie programistyczne. A co, jeśli moglibyśmy napisać taki serwer w… javascripcie?
Ale zaraz, zaraz – ktoś powie – przecież JavaScript to język programowania client-side.
Otóż drodzy Państwo – niekoniecznie. Weźmy np. taki NODE.JS.
Node.js to framework I/O – implementacja enginu V8 JavaScriptu po stronie serwera. Może służyć do zbudowania serwera WWW sterowanego zdarzeniami. Mamy tu do dyspozycji zestaw gotowych bibliotek, dzięki którym oprogramujemy najprostszy serwer już za pomocą kilku linijek kodu! Na dodatek w języku, który dobrze znamy.
No dobra – znowu ktoś zada pytanie za 100 punktów – ale po co właściwie pisać własny serwer?
Pytanie to faktycznie jest dobre. Już odpowiadam: ponieważ daje to niesamowite możliwości w tworzeniu nowoczesnych, dynamicznych aplikacji webowych.
NODE.JS wraz z pakietem SOCKET.IO pozwala na cross-browserową obsługę websocketów. Realizuje to poprzez: natywne websockety, flash-sockety, ajax long polling i inne. Dzięki tej technologii jesteśmy w stanie oprogramować aplikację, która będzie komunikować się z serwerem oraz w której… serwer będzie komunikował się bezpośrednio z użytkownikiem aplikacji. Mamy tu więc do czynienia z komunikacją dwustronną.
Chyba nie muszę pisać, jak bardzo znacząco komunikacja dwustronna oraz podejście zdarzeniowe – są w stanie wpłynąć na wydajność działania naszej aplikacji. Podam prosty przykład.
Dzięki boomowi na technologię AJAX, jak grzybów po deszczu namnożyło się w sieci czatów opartych o tę technologię. Jak przeważnie działa taki czat na AJAXie? Aplikacja po stronie klienta co określony okres czasu (np. 5 sekund) odpytuje serwer czy nie pojawiła się jakaś nowa wypowiedź. Jeśli się pojawiła, odbiera ją i wstawia do okienka. Rozwiązanie takie ma wiele ograniczeń:
- do ciężkiego serwera (przeważnie apache) leci ogromna ilość zapytań
- ilość zapytań zawsze jest taka sama, gdyż klient nigdy nie wie o tym, czy pojawiło się coś nowego czy nie
- następuje konflikt między częstotliwością odświeżania, a wydajnością całej struktury
Ograniczenia te powodują, że utrzymanie czata opartego o technologię AJAX jest po prostu drogie, gdyż mocno obciąża to serwer.
W przypadku NODE.JS mamy zupełnie inną sytuację:
- dwustronna komunikacja sprawia, że klient nie odpytuje serwera czy coś się zmieniło – w momencie zmiany – to serwer powiadamia o tym klientów (broadcasting)
- odwołania nie lecą do krowiastego apache, tylko do leciutkiego serwerka napisanego tylko w jednym celu: obsługi naszej aplikacji
- zarówno aplikacja jak i serwer napisane są w javascripcie – z programistycznego punktu widzenia następuje płynny przepływ informacji.
Zapraszam na demo czata napisanego z wykorzystaniem NODE.JS: http://chat.nodejs.org/
Oczywiście sam nodejs to nie tylko websokety. Przy jego pomocy można zrobić dużo, dużo więcej. Ale o tym kiedy indziej. Niedługo postaram się opisać jak zacząć przygodę z tym środowiskiem.
Odwołania Cross-Domain
2011/04/07 – 12:02
W dobie serwisów społecznościowych, całego web 2.0, usług sieciowych, itd – coraz częściej pojawia się potrzeba, aby strony internetowe / aplikacje webowe / widgety – mogły się ze sobą komunikować. Dużą przeszkodą jest tu wprowadzona polityka bezpieczeństwa w przeglądarkach, zabraniająca wielu cross-domainowych akcji (np. odwołań AJAX).
Nie będę się na ten temat rozpisywał, ponieważ zrobili to już inni:
http://frontend.pl/2010/04/jsonp-crossdomain-ajax-czyli-jak-oszukac-przegladarke/
http://frontend.pl/2010/06/cross-domain-post-czyli-jak-oszukac-przegladarke-cz-2/
http://blog.kamilbrenk.pl/cross-domain-javascript/
Hello world!
2011/04/06 – 18:31
Słowem wstępu.
Założyłem tę stronę celem opisania moich przygód z szeroko rozumianym front-endem.
Będę pisał o technologiach z jakimi pracuję, o problemach z jakimi miałem do czynienia oraz o front-endzie jako takim.
Siłą rzeczy będzie też troszkę o back-endzie, ponieważ w przypadku części zagadnień mamy do czynienia z czymś na pograniczu jednego i drugiego.
Zdaję sobie sprawę, że jest to kolejny dev-blodżek, ale:
- po pierwsze piszę go trochę dla siebie, aby usystematyzować wiedzę
- mam nadzieję, że mimo wszystko kogoś to zainteresuje