1. Moja prezentacja o Node.JS z Meet.JS i GTUG Wrocław
2. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings
3. Zapraszam na darmowe szkolenie DevMeeting – middle-end w oparciu o NodeJS

DevMeetings – hot topics

Na początku lata ekipa z DevMeetings zorganizowała trzydniowy DevCamp, na którym wykrystalizowały się trzy ciekawe backendowe tematy. Teraz nadszedł czas, aby przyjrzeć im się dokładniej. I tak odbędą się po kolei:

• Wydajność Node.JS kontra reszta świata (3 września, Poznań) – kontrowersyjny temat – ile prawdy jest we wszystkich stwierdzeniach o super wydajności Node’a? Trochę na ten temat dowiedzieliśmy się już na DevCampie (polecam zajrzeć do materiałów z naszych badań), jednak wiele osób krytykowało zastosowane podejście jako zbyt oderwane od rzeczywistości. Dlatego tym razem postaramy przygotować się prawdziwą aplikację i na tej podstawie wyciągnąć wnioski. Rozpoczęła się już dyskusja, o tym jak podejść do tematu. Ja oczywiście będę, a Ty wciąż możesz się zarejestrować.
• Bazy noSQL-owe – naturalny storage aplikacji JSON-owych (10 września, Warszawa) – drugi temat na czasie, czyli bazy noSQL-owe (np. CouchDB, MongoDB, Redis). Meeting powinien być interesujący dla zwolenników, jak i przeciwników tego typu rozwiązań, w końcu nie ma nic lepszego niż potężny flame :). Jedni i drudzy dodatkowo dowiedzą się jak radzić sobie w nowym środowisku, które wymaga nowego podejścia (żegnaj SELECT, witaj map-reduce). Tym razem mnie nie będzie, bo do Warszawy mi zbyt daleko, ale i tak polecam :). Również można się jeszcze zarejestrować.
• Middle-end w oparciu o serverside JavaScript (24 września, Kraków) – to temat, na który czekam z niecierpliwością. Z jednej strony bowiem wiem co to middle-end, o którym nawet pisałem, a na DevCampie bawiliśmy się w jego implementacje, z drugiej, faktyczna architektura całego przekroju zastosowań (nie tylko DOM po stronie serwera, ale też np. walidatory) jest dla mnie pewną zagadką. Polecam ten temat wszystkim, którzy zastanawiali się kiedyś tym, czy da się współdzielić kod pomiędzy serwerem i przeglądarką i jak do tego podejść. Ja oczywiście będę i zachęcam do rejestrowania się.

onGameStart – first HTML5 conference

Konferencja organizowana przez Michała Budzyńskiego odbędzie się 22-23 września w Warszawie. Michałowi udało się ściągnąć wielu ciekawych prelegentów, więc na pewno warto posłuchać co mają do powiedzenia. W szczególności, że temat gier budowanych przy użyciu pakietu HTML5+CSS3+JS, jest ostatnimi czasy bardzo na topie i dużo w tej kwestii się dzieje. Mnie niestety nie będzie, mimo że wygrałem bilet, ale polecam zainteresowanym. Bilety po 79 i 89 euro są jeszcze do kupienia. Można też spróbować wygrać bilet u Lidii Wilczyńskiej.

Front Row Conference

Konferencja poświęcona frontendowi, która odbędzie się 20-21 października w Krakowie. Póki co nie ogłoszono zbyt wielu prelegentów, ale dwóch może być Wam znanych. To wspomniany przeze mnie przed chwilą Michał Budzyński oraz znany uczestnikom DevMeetingów Marek Pawłowski. Bilety do kupienia po 123 euro. Na razie, przyznam szczerze, odnoszę wrażenie, że organizatorom idzie topornie z organizacją, ale kibicuję im, bo im więcej tego typu imprez w Polsce, tym lepiej.

Do zobaczenia we wrześniu i październiku!

Podobne wpisy:

1. Falsy Values 2011 – prawdziwy JavaScriptowy event
2. meet.js – JavaScriptowe spotkanie w realu
3. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings

Rozwiązałem dzisiaj zupełnym przypadkiem dwa problemy związane z niedorozwinięciem CSS-a na jakie trafiam co jakiś czas. Istnieje pewne prawdopodobieństwo, że komuś przyda się moje rozwiązanie, więc o to i ono.

Miałem dzisiaj za zadanie stworzyć typowe drop-down menu rozwijające się po najechaniu. Typowa sytuacja. Ze względów estetycznych otwieranie pozycji powinno się animować, a ze względów UX nie powinno zwijać się od razu po zjechaniu myszką, bo przecież nikt tego nie lubi. Z lenistwa też, niechęci do scriptaculousa i możliwości wymuszenia przeglądarki postanowiłem wszystko zrobić za pomocą CSS transitions. Załóżmy, że stworzyłem sobie taki kod HTML:

<ul id="menu">
	<li>
		<span>Kaczka</span>
		<ul>
			<li>dzióbek</li>
			(...)
		</ul>
	</li>
	<li>
		<span>Donald</span>
		<ul>
			(...)
		</ul>
	</li>
	(...)
</ul>

Pierwszy problem na który trafiłem to niemożliwość tworzenia przejść do height: auto, a nie znam wysokości listy opcji. Googiel pomógł podpowiadając, że mogę zrobić przejście dla max-height. Np. tak:

#menu ul {
	max-height: 0;
	overflow: hidden;
	transition: max-height 0.5s ease-in-out;
}
#menu :hover ul {
	max-height: 1000px;
}

Gdzie 1000px to jakaś wartość, którą możemy przyjąć za bezpieczny szacunek maksymalnej wysokości listy opcji. W wielu przypadkach jednak to rozwiązanie ma spory minus – wizualnie submenu zaczyna nam się zwijać po bliżej nieokreślonym czasie. Ale zaraz… Przecież tego właśnie chciałem – żeby menu zwijało mi się dopiero po chwili od opuszczenia jego obszaru.

I tak właśnie powstał Chocapic (działający przykład).

Rozwiązanie oczywiście idealne nie jest (wspomniany nieokreślony czas na zwinięcie i gubienie hovera od razu po zjechaniu, jeszcze przed zwinięciem) i tam gdzie jakość rozwiązania jest najważniejsza bym go nie polecał. Mi jednak w pełni wystarczyło i spodobała mi się jego prostota.

Przewidując nadchodzące pytania – tak mamy opcję delay dla transition, ale jej użycie spowodowałoby również opóźnienie na starcie (przy rozwijaniu), czego byśmy nie chcieli.

Czy mamy jakiś wpływ na opóźnienie zwijania? Tak. Im większy max-height wybierzemy, tym później menu zacznie nam się zwijać. Skutkiem ubocznym będzie też przyszypszenie™ samej animacji, co jest kolejną niedogodnością.

Podobne wpisy:

1. Dwukolumnowa lista definicji (edit: w HTML5 lista opisów (?))
2. Zen Coding – snippety do kosza

Kto nie był w zeszłym roku na konferencji Front Trends ten, czytając świetne recenzje jakie dostała, na pewno tego żałował. Sam byłem w Warszawie i wiem, że dobrze zainwestowałem swój czas i pieniądze, bo to jedyne tego typu wydarzenie w Polsce, jakie pamiętam. Wystarczy spojrzeć na listę prelegentów, którzy wzięli udział w konferencji. Douglas Crockford, Tantek Çelik, Peter-Paul Koch to bez wątpienia gwiazdy, których przedstawiać nie trzeba. Jednak bardzo dobre wrażenie zrobili na mnie również mniej znani prelegenci, jak Christian Johansen, Zbigniew Braniecki (jako moderator panelu dyskusyjnego), czy Andrea Giammarchi.

Jedyny zarzut (poza drobnymi problemami organizacyjnymi i kilkoma odstającymi poziomem prelegentami), jaki słyszałem w stosunku do zeszłorocznej konferencji to zbyt małe nastawienie na JavaScript. W tym roku Damian Wielgosik i Paweł Czerski, twórcy Front Trends, postanowili wyjść na przeciw krytykom i już za 2 tygodnie, w dniach 18-20 maja w Warszawie odbędzie się konferencja i 2 dni warsztatów pod nazwą Falsy Values. Tym razem, z pewnością, będzie to „True JavaScript Event”. W dodatku obsada zapowiada się jeszcze ciekawiej i równiej. Nie dość, że gościć będą wszyscy wielcy z Front Trends (poza PPK-em), to spotkać będzie można również kilku nowych, dobrze znanych, developerów, m.in. Dmitry’a Soshnikova, Juriy’a „kangax” Zaytseva oraz Kornela „porneL” Lesińskiego.

W chwili obecnej zakupić można jeszcze bilety wstępu (upoważniające również do udziału w konferencji) na wszystkie warsztaty poza jednymi prowadzonymi przez Tanteka Çelika. Do wyboru mamy więc node.js, wstęp do JavaScriptu, gry, ECMAScript 5, Test Driven Development i aplikacje desktopowe. Można zakupić też bilet jedynie na piątkową konferencję. Ceny wahają się w zależności od tematu warsztatów i długości (są jedno i dwudniowe) i wydaje mi się, że nie są wygórowane, w szczególności kiedy porównamy je z dotyczącymi podobnych eventów organizowanych za naszą zachodnią granicą.

Jeśli o mnie chodzi, to ze względu na studia pojawię się tylko w piątek na konferencji (dziękuję tutaj Damianowi za zaproszenie). Zapowiada się wspaniały dzień, ponieważ plan prelekcji jest wyśmienity. Wiem, że ani nie będę mógł się spóźnić (Douglas Crockford na początek), ani wcześniej wyjść (Tantek Çelik na koniec), ani nawet przysnąć w środku (Dmitry Soshnikov). W szczególności nie mogę doczekać się występu tego trzeciego, ponieważ będzie mówił o ECMAScript 6, a kto czytał mnie wcześniej, wie, że interesuje mnie rozwój tego standardu.

Tak więc, do zobaczenia w Warszawie!

Podobne wpisy:

1. JavaScript na jesień 2011
2. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings
3. Obiektowy JavaScript i właściwości chronione – w poszukiwaniu Świętego Graala

Dzisiaj nie będę pisał bezpośrednio JavaScriptcie. Tym razem produkować będzie się ktoś inny. I to nie byle ktoś i nie na byle jaki temat. Otóż DevMeetings zaprasza na cykl (Wrocław, Warszawa, Poznań, Kraków, Gdańsk) dwudniowych, darmowych szkoleń pt. Programowanie gier w JavaScript. Pierwsze szkolenie już 8-9 stycznia we Wrocławiu. Zapisy na stronie. Ilość miejsc ograniczona do 10, tak więc będzie dość kameralnie.

Kto to taki

DevMeetings oficjalnie istnieje od niedawna (dokładnie, to przed świętami strona jeszcze nie istniała :) jednak już rok temu skorzystałem z jednego z ich szkoleń. Za całą inicjatywą od strony organizacyjnej i finansowej stoi przede wszystkim Piotr Zwoliński (m.in. Frontend Force i DevJobs), którego pewnie sporo osób miało już przyjemność poznać podczas szkoleń, na których się pojawił oraz konferencji Front-Trends 2010, której jeśli się nie mylę był współorganizatorem. Piotrek jest niezwykle aktywny i ma dużo ciekawych pomysłów na pobudzenie naszej skamieniałej społeczności, więc mocno mu kibicuję :). Dodatkowo pomagali mu (nie wiem jak teraz) David de Rosier oraz Damian Ferrante Wielgosik, którzy byli też prowadzącymi.

Jak już wspomniałem rok temu odbyło się, kilka cyklów darmowych szkoleń – między innymi cztery z Zaawansowanego JavaScriptu poprowadzone przez Damiana, z których na jednym sam byłem (linki do relacji, stare informacje o szkoleniach).

Jak oceniam szkolenie? Bardzo pozytywnie. Damian jest ekspertem od JavaScriptu (polecam lekturę starszych wpisów na jego blogu). W dodatku świetnie poradził sobie z prowadzeniem szkolenia, które oparł na swojej prezentacji (w wersji angielskiej) oraz programowaniu na żywo. Szkolenie we Wrocławiu, na którym byłem, było pierwsze w kolejności i z tego co wiem później Damian wprowadził sporo ulepszeń do programu i w następnych miastach całość ewoluowała trochę bardziej w kierunku warsztatów.

Szkolenie trwało dwa dni i pomogło mi w krótkim czasie zrobić duży krok w znajomości języka. Oczywiście samo w sobie było bardzo intensywne i później wszystko musiałem sobie na spokojnie poukładać w głowie. Jednak po prawie roku mogę powiedzieć, że te 16h spędzonych z Damianem to jak miesiąc czytania książek.

Szkolenie z programowania gier w JavaScripcie poprowadzi Marek Pawłowski, którego nie znam, ale mogę zapewnić, że również będzie wiedział o czym mówi :) Więcej informacji o nim na stronie szkolenia.

Dlaczego będę

Na szkolenie już się zapisałem i, o ile nie odrzucą mojej kandydatury, powinniśmy spotkać się we Wrocławiu Krakowie (zmieniłem plany ze względu na uczelnię) :). Co ważne – jeśli zgłosi się dużo osób liczyć nie będzie się czas zgłoszenia, a doświadczenie i przydatność znajomości jego tematyki, nam developerom, w karierze zawodowej. W dodatku, jako że informacja o szkoleniu we Wrocławiu pojawiła się bardzo niedawno, możliwe, że zgłosi się do tego miasta mało osób. Polecam więc próbować nawet jeśli nie macie pewności co do tego, że „nadajecie się”.

Tematyka gier, a w szczególności przeglądarkowych, nie za bardzo mnie kręci. Sam gram mało i do tego tylko w symulatory wyścigowe. Jednak to nie gry mnie zainteresowały, tylko technologie, które zostaną omówione.

Szkolenie na którym byłem rok temu było typowym szkoleniem z JavaScriptu jako samego języka. Scope, obiekty, prototypy, tablice, funkcje, dobre praktyki, itd. Szkolenie z programowania gier musi objąć inny podzbiór JavaScriptu, a mianowicie toolkit przydatny przy pisaniu gier i zaawansowane praktyki tworzenia UI. Pojawi się więc responsywność aplikacji, optymalizacja kodu na poziomie języka, optymalizacja operacji na DOM i Canvasie, informacje o engine’ach przeglądarek, komunikacja z serwerem (REST, JSONP, long polling, WebSockety. Dodatkowo mam nadzieję dowiedzieć się więcej o tworzeniu i architekturze dużych aplikacji w JavaScriptcie, ponieważ w programie są informacje o MVC, systemach złożonych z widgetów oraz TDD.

PS

Z informacji od organizatorów szkolenia wiem, że o ile się uda będzie sporo wspólnego programowania. Nigdy nie brałem udziału w takich warsztatach i trochę się boję. Tak więc liczę, że nie będę tam najsłabszy :).

Właśnie przeczytałem swój wpis i stwierdzam, że nie pojawiło się ani jedno krytyczne słowo w stosunku do tych szkoleń :). Ale żeby zachować równowagę, to powiem, że nie dali kawy, a 8ma rano to za wcześnie (rok temu się spóźniłem). Cóż – mimo tych poważnych minusów polecam i sam nie mogę się doczekać.

Zdjęcie autorstwa: Stephen.

Podobne wpisy:

1. Zapraszam na darmowe szkolenie DevMeeting – middle-end w oparciu o NodeJS
2. Moje prezentacje z DevMeetings i MeetJS
3. JavaScript na jesień 2011

Będzie krótko, bo jutro święto jakieś :)

Od bardzo dawna przy wielu stronach natrafiałem na problem w jaki sposób ostylować listę definicji opisów (patrz komentarze) dl, tak aby elementy dt wyświetlały się na lewo od elementów dd. Przy czym kod musiał spełniać warunki:

• lista musiała się nie rozsypywać w przypadku różnej wysokości elementów dt i dd,
• szerokość listy mogła być zmienna,
• ustaloną szerokość miały elementy dt. Elementy dd miały się rozszerzać do maksymalnej dostępnej szerokości.

Nigdy nie miałem ochoty się w ten problem zagłębiać i jeśli już stałem pod ścianą to każdy „wiersz” takiej listy pakowałem do osobnego elementu dl, co rozwiązywało najtrudniejszy problem, czyli odpowiedniego ułożenia elementów w pionie. W sumie, to z tego niezbyt pięknego rozwiązania korzystałem często, bo w ten sposób używam listy definicji do tworzenia formularzy.

Ostatnio postanowiłem jednak rozwiązać swój odwieczny problem i po wielu próbach — między innymi z różnymi kombinacjami floatów, display:inline-block i wieloma dziwactwami — udało mi się znaleźć kilka rozwiązań, które działały, ale np. do momentu kiedy nie rozszerzyło się całej listy do sporej szerokości, albo nie nastąpił jakiś przypadek stosunków szerokości. Wpadłem jednak przed chwilą na rozwiązanie, które działa w każdym interesującym mnie przypadku i aż chcę się pochwalić :).

Skrócony kod HTML:

<dl>
	<dt>Widelec</dt>
	<dd>Jest biały i leży na moim biurku.</dd>
	<dt>Widelec</dt>
	<dd>Jest biały i leży na moim biurku.</dd>
...
</dl>

I skrócony kod CSS:

dl {
	width: 70%;
	min-width: 40em;
	overflow: hidden;
	...
}
dt {
	float: left;
	width: 15em;
	clear: both;
	...
}
dd:after {
	content: '\00a0';
	display: block;
	clear: left;
	float: right;
	height: 0;
	width: 0;
}
dd {
	margin: 0 0 0.5em 18em;
	clear: right;
	...
}

Działający przykład.

Cała magia zawiera się w regule dla dd:after. To ona powoduje, że jeśli element dt jest wyższy od następującej po nim definicji, to następna definicja jest wyświetlana w odpowiednim miejscu (nie przeskakuje ponad swój temat).

Wpis ukazał się początkowo na moim blogu prywatnym, gdzie znajdują się komentarze: Dwukolumnowa lista definicji.

Podobne wpisy:

1. Jak przycinać i skalować obrazki?

Cóż to takiego framework CSS?

No właśnie. Każdy wie co to są frameworki programistyczne, ale CSSowy? Według wiki:

A CSS framework, also known as a web design framework is a pre-prepared library that is meant to allow for easier, more standards-compliant styling of a webpage using the Cascading Style Sheets language. Just like programming and scripting language libraries, CSS frameworks (usually packaged as external .css sheets inserted into the header) package a number of ready-made options for designing and outlaying a webpage.

Czyli, tak jak w językach programowania, framework jest biblioteką (w tym wypadku grupą reguł CSS) która ułatwia implementowanie jakichś standardowych, często powtarzających się funkcjonalności (w tym wypadku pewnych schematów w layoutcie).

Co, według mnie, frameworkiem CSS nie jest? Pisałem w listopadzie o parserze/kompilatorze/procesorze CSS – LESS, który rozszerza składnię CSS o kilka świetnych rzeczy. Między innymi – zmienne, zagnieżdżone reguły, obliczenia, wielokrotne wykorzystywanie reguł. Jakby nie było – nie podchodzi to pod definicję z Wikipedii, ale niestety znajduje się w linkach do przykładowych frameworków. Dla ustalenia uwagi – LESS nie jest frameworkiem.

Czemuż ssie?

Pod mą lupę wziąłem pierwsze linki zwrócone przez Google. Przyjrzałem się chwilkę frameworkom: Blueprint, Elastic CSS, YUI 2 Grids. Prawdopodobnie są lepsze rozwiązania od tych i z chęcią się im przyjrzę jeśli linki pojawią się w komciach :).

Słówko o nieudanym porodzie

Wypada jeszcze wtrącić, dla niezorientowanych, co to za poroniony pomysł ten Grid system. Otóż wpadł ktoś na pomysł, że wygodnie będzie wszystkim (grafikom, programistom) jak ustalimy sobie, że strona składa się z X kolumn po Ypx szerokości każda, między którymi są marginesy po Zpx. Przyznam, że obaj z grafikiem byliśmy zachwyceni, aż do… pierwszego projektu. Życzę np. sporo zabawy z cieniami wychodzącymi poza granice kolumn, w przypadku kiedy nie możemy użyć box-shadow. Szlag trafia wszystkie piękne, okrągłe wartości.

Koniec wtrącenia

Najpierw kawałek kodu z YUI 2 Grids:

<div id="yui-main">
   <div class="yui-b">
      <div class="yui-g">
 
         <div class="yui-g first">
            <div class="yui-u first"></div>
            <div class="yui-u"></div>
         </div>
 
         <div class="yui-g">
            <div class="yui-u first"></div>
            <div class="yui-u"></div>
         </div>
 
      </div>
   </div>
</div>

Tyle się kiedyś mówiło o semantyce kodu i oddzieleniu wyglądu od treści. Ponad pięć lat temu, kiedy zaczynałem naukę HTMLa i CSSa, trwała walka o to aby programiści zaczęli pisać porządny kod. Wydawało mi się, że teraz już nie powinno być z tym problemów, a tu zonk. Patrzę na ten przykład i co widzę?

• Prezentacja zbita razem z HTMLem – żeby zmienić układ strony zmieniamy HTMLa, a nie CSS,
• Kompletnie bezznaczeniowe nazwy klas i identyfikatorów – jedno wielkie semantyczne szambo. Wybrałem akurat framework od YUI, bo jest w tym najgorszy (choć Blueprint mu nie ustępuje). Elastic CSS wygląda trochę lepiej,
• Divitis. W przypadku YUI można chyba akurat dowolnie zmieniać użyte tagi, bo framework resetuje marginesy i paddingi dla wszystkich elementów (co też, tak na marginesie, uważam za kiepską praktykę). Kiedy jednak używając Blueprinta postanowimy zawrzeć którąś kolumnę w listę, to wszystko szlag trafia, bo uwaga… niektóre selektory zawierają nazwę tagu :O
• Narzucona struktura i kolejność elementów w kodzie HTML. Ja akurat poświęcam sporo uwagi temu aby każdy element nawigacyjny był w sensownym miejscu, aby nie używać niepotrzebnych tagów, a wykorzystując framework nie mam tej elastyczności,
• I wreszcie – przecież to wszystko co oferuje framework można w czasie, który jest bez znaczenia w stosunku do całego projektu, napisać ręcznie. To jest kilka reguł, które doświadczona osoba pisze na raz i to od razu z ewentualnym hackiem dla IE6. Tak, wiem, że nie wszyscy mają taką wiedzę, ale wykorzystując framework nigdy jej nie pogłębią.

Tak więc w żadnym wypadku nie widzę sensu w używaniu frameworków do budowy układu strony. Żeby jednak nie było, że w ogóle nie umiem wykorzystywać zewnętrznego kodu – uważam, że przydatne są frameworki poprawiające typografię, bądź też pod niektórymi względami formularze. Muszą jednak bazować na selektorach używających tagów, a nie klas, czy nie daj Boże identyfikatorów.

Podobne wpisy:

1. Zen Coding – snippety do kosza

div#content>h1+p

Wciskam jakąś kombinację klawiszy i dostaję:

<div id="content">
<h1></h1>
<p></p>
</div>

Sprytne, nie? :) Ale to jeszcze mało. Spróbujcie tego:

div#top>h1>a[title=Do strony głównej]{Moja strona}<ul#menu>li.pos$*3>a

<div id="top">
    <h1>
        <a href="" title="Do strony głównej">Moja strona</a>
    </h1>
 
    <ul id="menu">
        <li class="pos1">
            <a href=""></a>
        </li>
        <li class="pos2">
 
            <a href=""></a>
        </li>
        <li class="pos3">
            <a href=""></a>
        </li>
 
    </ul>
</div>

Chyba nie muszę mówić jak bardzo taka pomoc przyspiesza pracę. Napisanie z palca kodu z drugiego przykładu zajęłoby mi przypuszczalnie więcej niż 2 minuty. Gdybym użył snippetów (do których przy HTMLu nie mogę się przyzwyczaić) może skróciłbym ten czas dwukrotnie. Zaś używając wynalazku Zen Coding całość naklepałem w 20s (i to nie mając wprawy). Tak więc gorąco polecam.

Gdyby ktoś szukał wtyczki do VIMa, to powstał plugin, którego twórca zainspirował się Zen Codingiem.

Wpis ten opublikowałem też na swoim prywatnym blogu.

Podobne wpisy:

1. Dlaczego frameworki CSS ssą?

AIR – was ist das?

Za wikipedią:

Adobe Integrated Runtime, w skrócie AIR (nazwa kodowa Apollo) – wieloplatformowe środowisko wykonawcze dla RIA (ang. Rich Internet Application) zbudowanych za pomocą Flash, Flex, lub HTML i AJAX.

Programy AIR mogą być aplikacjami pulpitu.

Czyli? Środowisko dla efektownych i bogatych aplikacji internetowych. Aplikacje te mogą być odpalane jak normalne desktopowe programy. A co to w praktyce? Jeszcze nie do końca wiem, bo w zasadzie, to na bieżąco się uczę pisząc ten artykuł (dla tego proszę o poprawianie jak bym jakoś naginał czasoprzestrzeń), ale na pewno integracja z systemem plików, lokalna baza danych, kontrolki jakie oferuje Flex (o nim pewnie w przyszłości), itd.

Co ważne dla geeków ortodoksów. AIR != Flash. Aplikacje Flashowe mogą używać AIRa by powiększać swe możliwości. Ale Flasha w aplikacji AIRowej może w ogóle nie być. Zamiast niego można z powodzeniem użyć XHTMLa+JS, czy Fleksa+Actionscripta (który to kompiluje się już do obiektu SWF, ale za to ma wolne SDK i nie potrzeba do niego żadnych płatnych narzędzi).

Co trochę znamienne dla strony Adobe – miałem przed chwilą spory problem z podlinkowaniem SDK Fleksa. Niestety nie potrafię się poruszać płynnie po ich stronie i w ogóle nie znalazłem podstrony samego SDK. Ale spokojnie – może trochę dziwnie i niespójnie połączone, ale na stronie(nach) znajduje się cała potrzebna dokumentacja, którą do tej pory oceniam raczej dobrze.

Aha – Flex, jeśli dobrze rozumiem, jest open source’owy :O

Moja pierwsza aplikacja AIR oparta o HTML

Czego potrzebujemy? Na pewno przyda nam się AIR SDK. Co prawda można skorzystać także z darmowej Aptany, albo płatnego Adobe Dreamweaver CS3/CS4 z Adobe AIR Extension for Dreamweaver, ale my skupimy się na najniższym poziomowo rozwiązaniu, czyli AIR SDK (który rzecz jasna należy pobrać). Do tego na pewno będzie nam potrzebna zainstalowana biblioteka uruchomieniowa (czyt. plugin) Adobe AIR. No i na koniec zwykły edytor tekstu (najlepiej gvim :).

Mało odkrywczo zaczniemy od przywitania się ze światem. Nie pokazuje to ani trochę możliwości AIRa, ale w tym wpisie już nic więcej nie zmieszczę – za długi się robi :). Stwórzmy więc sobie katalog HelloWorld, w którym będziemy potrzebowali kilku plików.

HelloWorld.html

plik obowiązkowy – główna strona naszej aplikacji,

HelloWorld-app.xml

również obowiązkowy – konfiguracja aplikacji (z ang. descriptor) w którym między innymi można ustawić ścieżkę instalacji, nazwę, ikony, ustawienia okna, czy ścieżkę do głównego pliku HTML,

AIRAliases.js

plik przydatny – tworzy proste aliasy do JSowych obiektów dostępnych dzięki AIR. Np. zamiast window.runtime.flash.filesystem.File otrzymujemy air.File. Plik ten przekopiowujemy z sciezka_do_AdobeAIRSDK/frameworks/libs/air/.

Na początek HelloWorld.html. Zakładam, że składnię HTMLa znasz i nie muszę nic tłumaczyć. Jakby ktoś chciał więcej szczegółów odnośnie zawartości plików, to odsyłam do źródła skąd cały ten przykład zaczerpnąłem.

<html>
<head>
    <title>Hello World</title>
    <script type="text/javascript" src="AIRAliases.js"></script>
    <script type="text/javascript">
        function appLoad(){
            air.trace("Hello World");
        }
    </script> 
 
</head>
<body onLoad="appLoad()">
    <h1>Hello World</h1>
</body>
</html>

Jak widać – żadnych rewolucji. Pora na HelloWorld-app.xml:

<?xml version="1.0" encoding="UTF-8"?> 
 
<application xmlns="http://ns.adobe.com/air/application/1.5">
    <id>examples.html.HelloWorld</id>
    <version>0.1</version>
    <filename>HelloWorld</filename>
    <initialWindow>
        <content>HelloWorld.html</content>
        <visible>true</visible>
        <width>400</width>
        <height>200</height>
    </initialWindow> 
 
</application>

Wydaje mi się, że wszystko powinno być jasne. Jedynie wartość elementu <filename> była dla mnie niejasna, więc tłumaczę – jest to nazwa aplikacji w systemie (czyli po zainstalowaniu). Wchodzi w to: katalog instalacyjny, plik wykonywalny oraz nazwa w menu systemowym (każdą z tych rzeczy można jeszcze ustawić osobno).

Testowanie aplikacji

Do testowego uruchamiania (i debugowania) stworzonej aplikacji służy odpalany z wiersza poleceń AIR Debug Launcher (ADL). Znajduje się on w sciezka_do_AdobeAIRSDK/bin/. Włączamy więc konsolę, przechodzimy do katalogu HelloWorld i startujemy:

p@d:/air/HelloWorld$ /air/AdobeAIRSDK/bin/adl HelloWorld-app.xml
Jakis trace
p@d:/air/HelloWorld$

Powinniśmy obejrzeć takie o to, piękne okienko:

Jak widać program wydrukował nam też na konsoli „Jakis trace” co jest wynikiem działania air.trace("Jakis trace").

Tworzenie pliku instalacyjnego .air

Pora teraz spakować do jednego pliku instalacyjnego (paczka zip) naszą aplikację dzięki której zapanujemy nad światem. Służy do tego narzędzie ADT.

Pierwsze co trzeba wiedzieć, to że wszystkie AIRowskie aplikacje są cyfrowo podpisane. Temat ten jest mi kompletnie obcy i za pierwszym razem męczyłem się 3h żeby wygenerować jakiś swój klucz. Otóż poszedłem w stronę javowego keytoola, co było dla mnie ślepą uliczką ;). Co prawda nauczyłem się generować wszystkie typy kluczy, ale żaden nie działał :D. Na szczęście jest o wiele prostsza (i przede wszystkim działająca) ścieżka, którą przegapiłem. O niej za chwilę, a teraz cytat ze strony Adobe o bezpieczeństwie:

To ensure application security, all AIR installation files must be digitally signed. For development purposes, you can generate a basic, self-signed certificate with ADT or another certificate generation tool. You can also buy a commercial code-signing certificate from a commercial certificate authority such as VeriSign or Thawte. When users install a self-signed AIR file, the publisher is displayed as “unknown” during the installation process. This is because a self-signed certificate only guarantees that the AIR file has not been changed since it was created. There is nothing to prevent someone from self-signing a masquerade AIR file and presenting it as your application. For publicly released AIR files, a verifiable, commercial certificate is strongly recommended. For an overview of AIR security issues, see AIR security.

Oczywiście przegapiłem zaznaczony fragment i cały akapit poniżej :) A w zasadzie to mam wrażenie, że go tam wcześniej nie było. Ale koniec płaczu nad straconym czasem. Generujemy własny klucz:

p@d:/air/HelloWorld$ /air/AdobeAIRSDK/bin/adt -certificate -cn AIRBegginer 1024-RSA my_key_file dupa.8

W ten o to sposób wygenerowaliśmy klucz na nazwę podmiotu (company name) AIRBegginer, zabezpieczony hasłem dupa.8, który został zapisany do pliku my_key_file. Można go podejrzeć javowym narzędziem keytool:

p@d:/air/HelloWorld$ keytool -list -v -keystore my_key_file -storetype pkcs12
Enter keystore password:  

Keystore type: PKCS12
Keystore provider: SunJSSE

Your keystore contains 1 entry

Alias name: 1
Creation date: 2009-04-25
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=AIRBegginer
Issuer: CN=AIRBegginer
Serial number: 36373061626165333a31323064646264383133663a2d38303030
Valid from: Sat Apr 25 16:46:05 CEST 2009 until: Fri Apr 25 16:46:05 CEST 2014
(...)

Tak utworzonym kluczem możemy teraz podpisać naszą aplikację:

p@d:/air/HelloWorld$ /air/AdobeAIRSDK/bin/adt -package -storetype pkcs12 -keystore my_key_file HelloWorld.air HelloWorld-app.xml HelloWorld.html AIRAliases.js

Zostaniemy poproszeni o hasło i jeśli nic nie skopaliśmy, to ADT stworzy nam plik HelloWorld.air, który jest naszą pierwszą spakowaną i gotową do instalacji aplikacją AIR.

Instalacja

Najprostszy sposób jeśli mamy w systemie zmapowane rozszerzenie .air z instalatorem Adobe AIR (ja standardowo tak miałem) to instalacja jak na Windowsie – przez podwójnego klika w HelloWorld.air. Jeśli nie to wpisujemy:

p@d:/air/HelloWorld$ /opt/Adobe AIR/Versions/1.0/airappinstaller ./HelloWorld.air
unexpected error: ArgumentError: Error #2004
p@d:/air/HelloWorld$ /opt/Adobe AIR/Versions/1.0/airappinstaller /air/HelloWorld/HelloWorld.air

Jak widać skrypt jest zbyt „głupi” żeby sobie poradzić ze ścieżką względną i trzeba podać absolutną. Chwila czekania i zium:

Znów hasło roota i wszystko działa.

Zarządzanie zainstalowanymi aplikacjami na Linuksie

Programy niestety na moim Ubuntu pojawiają się w menu systemowym w sekcji „Akcesoria”. Zainstalowałem już kilka na próbę i zaczął mi się tam robić bałagan. Ustawienie w pliku konfiguracyjnym aplikacji pola <programMenuFolder> zdaje się działać tylko na Windowsach.

Przed chwilą znalazłem także informację o tym jak można zarządzać już zainstalowanymi programami. Otóż są one instalowane jak paczki odpowiednio deb albo rpm. Dzięki temu np. w moim Ubuntu mogłem odinstalować programy z poziomu Synaptica. Nazwa programu składa się z z pola applicationId (np. examples.html.helloworld) oraz publisherID.

Uwaga dla każdego, kto nie znalazł swojej aplikacji – ja musiałem zrestartować system żeby Synaptic się odświeżył.

Koniec

To by było na tyle. Miałem jeszcze w tym artykule (ależ to ładnie brzmi ;P) pokazać jakiś ciekawszy przykład aplikacji, ale wydaje mi się, że byłby to już zbyt długi wpis. Postaram się więc dość szybko zmajstrować następną notkę. I będzie ona albo przedstawiała możliwości jakie daje AIR, albo skrobnę coś o Fleksie. A najpewniej i jedno, i drugie w krótkim czasie :).

Jeśli chodzi o ten wpis, to wszelkie sugestie, uwagi, czy pytania mile widziane. Jak zaznaczyłem gdzieś po drodze – moja wiedza na temat Adobe AIR jest nikła i mogłem popełnić sporo błędów.

Źródło i inne przydatne linki

• Źródło, którego ten tekst jest w zasadzie bardzo luźnym tłumaczeniem,
• Więcej informacji o Adobe AIR na Linuksie,
• AIR Developer Center – sam czubek góry lodowej. Stąd chyba dobrze zaczynać poszukiwania czegokolwiek,
• Dokumentacja Adobe AIR.

Artykuł ten ukazał się równolegle na moim prywatnym blogu.

Podobne wpisy:

1. Podstawy: osadzanie kodu PHP w pliku

console.log("Ten kod powinien się wykonać");

var foo = "bar", x = 12.34, i = 122;

console.log("foo: %s, (int) i: %d, (float) x: %f", foo, i, x);

function Kopytko() {
	this.palec1 = 11.12;
	this.palec2 = "qń";
};
kopyto = new Kopytko();
console.log(kopyto);
console.log(kopyto.brak);

Jednak to nie wszystko. Możemy także pokolorować i nadać znaczenia naszej radosnej twórczości. I tak mamy dostępne metody console.debug(), console.info(), console.warn(), console.error().

Dodatkowo, przydatne (np. przy pracy z Ajaksem, czy manipulacjach w drzewie DOM) może się okazać również drukowanie HTMLa oraz XMLa. Służy do tego metoda console.dirxml(DOMElement). Wyświetla ona drzewo znane nam z zakładki „HTML” Firebuga.

To chyba na tyle o „echowaniu” na konsolę Firebuga. Więcej informacji możecie znaleźć w Console API oraz Rejestrowaniu Javascriptu (damn – nie mogę lepszego tłumaczenia znaleźć :). I tak z poziomu kodu można mierzyć czas wykonania bloku instrukcji console.time("name"); {..} console.timeEnd("name");, czy tworzyć asercje (a jak to się tłumaczy?).

Artykuł ten ukazał się też w zbliżonej formie na moim osobistym blogasku.

Brak podobnych wposów.