czwartek, 17 kwietnia 2008

Benchmarki

Wszedłem sobie na portugalskojęzyczną stronę z wynikami testów jak ktoś próbował pokazać jak wydajny jest Tamarin. Trudno mi było uwierzyć, że ActionScript 3 jest szybszy od Pythona. Sam postanowiłem sprawdzić jak to z tym jest? Faktycznie, jak używamy silnego typowania i buforowania łańcuchów danych to się okazuje że nawet wydajnościowo dorównuje C/C++

Najdziwniejszy okazał się silnik skryptowy w Windows, bo nie mogłem zrozumieć dlaczego IE 7 wywala się. Jak użyłem WHScript to się przeraziłem. Poniższy skrypt został wykonany po 10290 ms.


function test() {
var s = "";
var e = 0.0;
var f = 1.0;
for(var i = 1; i <= 10000; i++) {
s += "teste";
e += 1.0/f;
f *= i;
}
return e
}
start = new Date();
test();
end = new Date();
addTime = end-start;
WScript.Echo(addTime + " ms.");


W IE7 taki test powodował pad przeglądarki. Nie zrażony tym chciałem zobaczyć jak JavaScript 2 w IE 7 wykona taki skrypt:


IE7 z JavaScript2 wykonał to w ciągu 375 ms. Opera wykonała to w 203 ms. a Firefox 2 w ciągu 855 ms.

Zastanawiam się czy może być szybciej? Owszem. Wyobrażcie sobie taką przeglądarkę w której mógłbym napisać taki kod



W tym przypadku dochodzi czas na wewnwtrzna kompilację do bajtkodu w pamięci i jego wykonanie. W ten sposób mielibyśmy jedną najszybszych przeglądarek. Coś jeszcze?
Zamiast kazać przeglądarce dokonywać kompilacji wystarczy samo załadowanie bajtkodu.

Wystarczyłoby dodać taka linijkę kodu w dokumencie HTML


Bajtkod jest wyjątkowo wydajny. Zajmuje bardzo mało miejsca. Kod źródłowy w AS3 zajmował mi 578 bajtów to po kompilacji do bajtkodu tylko 291 bajtów. A to jeszcze można poddać kompresji do formatu SWF.

Coś mi się wydaje że trzeba napisać taką przeglądarkę na bazie silnika Flash Playera i wspieraną przez Adobe AIR niż czekać aż upowszechni się JavaScript2.

W praktyce mamy już takie biblioteki jak AS3 Eval czy swfassist
Z tej pierwszej można by zrobić konwersję kodu do bajtkodu, a z tej drugiej ładowanie bajtkodu z plików SWF do aplikacji. A cała koncepcja tkwi w napisaniu odpowiedniego plugina do htmlwrappera

środa, 16 kwietnia 2008

Japońskie triki

Zawsze podziwiałem Japończyków za ich podejście do technologii. W przyswajaniu nowinek technologicznych wyprzedzają resztę świata. Mają bardzo praktyczne podejście. Co przejawia się w tym że ich blogi są pełne wskazówek tłumaczących działanie bibliotek czy rozwiązywaniem pewnych problemów. Adobe pewnego czasu wypuściło kod źródłowy silnika Tamarin z propozycją aby fundacja Mozilla go rozwijała. Ponieważ postanowiono Tamarina dopiero włączyć do Firefoxa 4 (czyli inaczej musi upłynąć sporo czasu). To tylko Japończyków zainteresował Tamarin na poważnie, że zrobili z tego aplikację do uruchamiania skryptów.
Po prostu poczytali sobie o MMgc, o AVM2
, o kompilacji - zajrzeli do repozytorium kodów źródłowych i skompilowali sobie intepreter powłoki (avmshell) aby móc z linii poleceń wykonywać skrypty w ActionScript 3.
Otóż na razie niewielu interesuje się Tamarinem. Otóż warto sprawdzić sobie czym sobie zasłuzył: szybkością. Otóż jest już wersja alfa dla JavaScript2 do ściągnięcia. Zainstalowałem i napisałem sobie skrypcik


Efekt był taki że miałem dla wykonania tej samej funkcji fib(30) i IE7 z tym powyższym silnikiem osiągnęło 3938 ms co biorąć pod uwagę że ta wersja jeszcze jest niedopracowana to i tak już osiąga całkiem dobry wynik.

Natomiast dla porównania napisałem analogiczny kod w JavaScript

IE7 - 10922 ms
Firefox 2 1875 ms
Opera 3000 ms

Idąc dalej pomyślałem że całkiem będzie inaczej jak wykorzystam avmplus.exe jako silnik wykonawczy dla skryptów pisanych w ActionScript. Potrzebowałem pliku wykonawczego więc znalazłem to u Japończyków. I pomyślałem że warto sprawdzić jak to zadziała

Napisałem kod w ActionScript


function fib(n) {
if(n <= 1)
return 1;
else
return fib(n-1) + fib(n-2);
}
start = new Date();
print("fib 30 = " + fib(30));
end = new Date();
addTime = end-start;
print(addTime + " ms.");

Najpierw skompilowałem to do pliku fib.abc za pomocą asc.jar z Flex SDK

java -jar asc.jar fib.as

a potem uruchomiłem to za pomocą następującego polecenia

avmplus.exe fib.abc

Wynik ? 1109 ms

Poczytałem o tym co można zrobić z tym małym plikiem avmplus.exe Okazało się, że można wiele od Japończyków nauczyć się. Pasjonaci ActionScriptu w Japonii zrobili sobie serwis Spark project w którym dzielą się swoimi kodami. Całkiem niedawno (15 marca) zrobili sobie konferencję poświęconą formatowi SWF o nazwie Shibuya.abc W sieci zamieścili nawet nagrania z tej konferencji.
Warto poczytać o tym co można zrobić z Tamarinem. Postawili na ActionScript 3 jako technologię serwer-side.

Następnie pokazali że warto wymyślać nowe języki programowania które w wyniku kompilacji otrzyma się SWF. Streszczenie można poczytać tu



O optymalizacji Flash Lite można posłuchać i poczytać


O dekompilacji i czytaniu kodu binarnego ActionScriptu z SWF można pooglądać


O tym jak rozwija się Gnash - opensourcowy Flash Player można poczytać i pooglądać.


I chyba najciekawsza prezentacja o tym jak można programować w systemie Windows różne aplikacje w ActionScript 3 za pomocą biblioteki winQuery i awmplus.exe


Szkoda, że tak mało się pisze o tym co wymyślają Japończycy.

niedziela, 13 kwietnia 2008

XHTML w FlashPlayerze

Często zdarza mi się czytać uwagi, że Flash Player nie nadaje się do wyświetlania (renderowania) stron w formacie XHTML wraz z obsługą CSS. Ale jak przeszukałem sporo informacji o tym, to się okazało że są już odpowiednie rozwiązania. Są to:
Deng X Browser - silnik renderujący XHTML/CSS/SVG/XForms (czyli obsługuje to czego jeszcze żadna przeglądarka internetowa nie parsuje do końca dobrze).
sFIR pozwala na wykorzystanie potencjału jaki tkwi w typografii - zestawienie przykładów. Głównym problemem było pogodzenie mechanizmów wyświetlania strony, tak żeby dobrze to wyglądało dla robotów - tak powstał pomysł SEFFS.

Natomiast obecnie są dostępne eksperymentalne rozwiązania dla Flex i ActionScript 3: Tall Tylera htmlwrapper oraz próba Adobe w tym kierunku - ale zaniechana o czym pisze Alex Harui. Dla programistów Flexa pozostaje rozwiązanie w postaci osadzania HTML w Flex. Można o tym poczytać u Brian Deitte bądź u Alistair Rutherford.

Ponieważ teraz prawie każda strona wymaga wykorzystania Java Scriptu, bo coraz więcej aplikacji internetowych jest tworzonych z użyciem AJAX. W tej sytuacji pozostaje pytanie czy warto tworzyć aplikacje internetowe osadzone w FlashPlayerze.

Argumenty za rozwojem tych bibliotek:

  • Stosowanie typografii (do tej pory nikt nie zrobił dobrego rozwiązania w tym zakresie)
  • Łatwość rozbudowy dokumentów XHTML w kierunku wykorzystania innych standardów np: SVG czy CSS3. Myślę, że na bazie Flash Playera / AIR szybciej powstałby silnik renderujący takie standardy jak MathML, XPath, XForms. Daje to potężną przewagę nad przeglądarkami bo korzyścią jest to że użytkownicy i twórcy stron nie musieliby narzekać że coś tam nie jest obsługiwane w IE5 czy IE6 (bo wszędzie będzie wyglądać identycznie). Dużym plusem może być też (hipotetycznie) że może stać się pierwszym silnikiem obsługującym HTML5.
  • Współpraca z AJAX jest możliwa na kilka sposobów. Użycie biblioteki Flex-Ajax Bridge pozwala programistom na dynamiczne tworzenie interfejsu użytkownika za pomocą komponentów Flexa. Innym rozwiązaniem jest wykorzystanie biblioteki as3corelib do obsługi danych w formacie JSON. Można poczytać o tym na blogach Mike Chambers czy Parranoidferret.com
  • Głębokie linkowanie - coraz więcej aplikacji internetowych wymaga stosowania czytelnego zapisu adresów URL. Aplikacje internetowe "osadzone" w Flash Playerze są często jakby niezależne od nawigacji w przeglądarce. Przecież wystarczy wykorzystać wbudowanych w Flex 3 bądź biblioteki UrlKit
Zastrzeżenia:
  • Silnik renderujący to nie wszystko. Coraz więcej aplikacji internetowych wymusza stosowanie JavaScriptu, napisano miliony linii kodu w JavaScripcie co może skutecznie zniechęcić do przechodzenia na ActionScript, a jak wiadomo FlashPlayer nie obsługuje JavaScriptu więc kod w JavaScript będzie musiał zostać przepisany na ActionScript. Kolejnym problemem może być obsługa DOM. Nie znalazłem jeszcze informacji o tym jak DOM znany z przeglądarek zastąpić e4x. Trzeba by napisać bibliotekę AS3 do obsługi DOM wykorzystującą e4x. No chyba, że ktoś już używał biblioteki as3query.
  • W przypadku popularności biblioteki htmlwrapper można by spodziewać wysypu "wtyczek", a ostatecznym przypadku powstawanie kodu CSS tylko dla obsługi przez Flash Playera, co teoretycznie oznacza, że każdy może standard rozszerzać o nowe rozwiązania.
  • Pozostaje też kwestia przebudowania oprogramowania po stronie serwera, może się okazać że wykorzystanie Flash Remoting okaże się lepszym rozwiązaniem niż budowanie aplikacji na AJAX. Tylko jeszcze nikt nie napisał pośrednika z AMF do aplikacji wykorzystującej AJAX.
  • Na koniec pozostają uprzedzenia i stereotypy. Nic nie poradzę na że sporo ludzi kojarzy Flasha i format SWF z animacjami oraz filmami niż z profesjonalnymi aplikacjami czy bibliotekami. Kolejne argumenty że strony oparte na FlashPlayerze nie dają się indeksować przez Google albo, że zawartość z pliku SWF jest niedostępna dla screenreaderów są wynikiem tego, że mało komu chce się dodać klika linijek kodu więcej.
  • Najważniejszą barierą w upowszechnieniu się tych bibliotek jest brak ludzi, którzy chcieliby to wykorzystać. Inaczej mówiąc brakuje ludzi którzy biegle znali się na programowaniu w ActionScript 3 oraz pisali o tym. Uważam że te problemy o których pisałem powyżej są do rozwiązania.

czwartek, 10 kwietnia 2008

Google Engine App

Ponieważ lubię Pythona to mnie ucieszyło że Google zrobiło kolejną usługę tym razem dla programistów. Google Engine App jest usługą pozwalającą hostingować małe aplikacje napisane w Pythonie. Ściągnąłem SDK i pomyślałem, że warto spróbować. Szybko zainstalowałem i przerobiłem to na Windows XP Getting Started Guide. Ale cóż nie ma róży beż kolców. Gdy chciałem obsłużyć statyczne dane pojawiał mi się błąd "regex invalid: unbalanced parenthesis" podczas uruchamiania testowego serwera. Na ich forum znalazłem rozwiązanie.
Trzeba zmienić linie kodu 2369-70 w katalogu SDK\google\appengine\tools\dev_appserver.py z:

regex = os.path.join(re.escape(regex), '(.*)')
path = os.path.join(path, '\\1')

na:

regex = re.escape(regex) + '/(.*)'
path = path + '/\\1'

To dotyczy tych, który używają Windowsa XP. Znalazłem posta o tym jak łączyć PyDev z Google Engine App SDK. Ale najciekawsze były kody źródłowe aplikacji pracujących z Google Engine App SDK. Przykłady w praktyce? muvmuv (kod źródlowy) Django Questbook (kod źródłowy) oraz przykładowy szablon aplikacji w Django. Dla tych. którzy chcieliby stawiać pierwsze kroki w Django ( już znają inne języki programowania) to polecam zapoznanie się z artykułem Shabda Raaj opisujacym jak tworzyć aplikację Django (sondę z kodem źródłowym) w App Engine.

Przypuszczam, że takie podejście Google jest rywalizacją z Amazonem (Simple Storage Service) oraz z Microsoftem (SQLServer Data Service).
No cóż zaczyna być ciekawie. Czyżby zaczynał sie schyłek pisania oprogramowania webowego w klasycznym SQL na rzecz zdalnego hostingu danych i obrabianych ich w jakimś dialekcie SQL (GQL, FBQL, LINQ) a bazy danych zaczynają obsługiwać kilka TB danych (technologie BigTable, SimpleSB).
Warto śledzić takie inicjatywy jak Force.com, dostarczające szereg usług dla programistów.

Trzeba tez zwrócić uwagę na to że są inne usługi Google z których można korzystać przy pomocy API GData. Dla programistów Google Engine App polecałbym bibliotekę Google Data Python Library. Warto przeczytać wprowadzenie do tej biblioteki
Mozna spróbować też użycie wirtualizacji w celu symulowania działania aplikacji na bazie SDK (do ściągnięcia stąd).

Ja nawet przewiduję wbudowanie w przeglądarce serwera WWW na przykład w Pythonie co sprawi że użytkownik ściągnie sobie aplikację i będzie mógł ją udostępniać ją innym do pobrania tak jak w przypadku sieci P2P. W takim rozproszonym modelu klasyczny hosting idzie do lamusa. Dlaczego? Usługi hostingowania aplikacji dostarczą API dzięki której użytkownik będzie miał pewność, że jego dane będą unikalne i w każdym razie nie musi być przechowywane na serwerze a w cache przeglądarki i każdy kto będzie chciał pobierze to z przeglądarki kogoś. Jak będzie wyglądała wtedy strona WWW? Będzie to paczka z kodem dla wbudowanego w przeglądarce serwerze WWW. Pobierasz raz i niejako instalujesz ją i co pozwala na pracę lokalnie z innymi użytkownikami równocześnie. To ma sens jak działalność użytkownika ogranicza się do odczytu danych. Natomiast jak ktoś potrzebuje doda komentarz to są dwa sposoby aktualizacji: wysyła to portem UDP do innych którzy mają uruchomione przeglądarkę i zainstalowaną paczkę z aplikacją co powoduje automatyczna aktualizację. Natomiast hostigodawca aplikacji trzyma informacje o IP przeglądarek z uruchomionym serwerem i przyjmuje dane do zapisania i w ten sposób aktualizuje paczkę jakiś danych. Następnie serwer w przeglądarce pyta sie serwera aplikacji czy są jakieś aktualizacje i wtedy pobiera aktualizację od serwera albo od innej przeglądarki która już ma zaktualizowaną bazę.

środa, 2 kwietnia 2008

Discover the Next Web

W Warszawie 31 marca odbyła się konferencja Microsoftu "Discover the Next Web" poświęcona nowym technologiom.

"Szybko, szybciej, MVC"
Prelegent: Bartłomiej Zass, Microsoft Polska
W ciągu kilkunastu miesięcy sposób budowy aplikacji WWW uległ drastycznej przemianie. Środowiska takie, jak Ruby on Rails czy Django istotnie wpłynęły na skrócenie czasu programowania i testowania serwisów internetowych. Jakie podejście prezentuje w tej kwestii Microsoft? To jeden z najciekawszych wykładów. Nareszcie Microsoft wprowadził dodatek ASP.NET 3.5, który pozwala na programowanie wg wzorca MVC. Teraz zamiast programowania na zdarzeniach i formularzach WebForms (co zawsze sprawiało problemy z wygenerowaną stronę jeśli chodzi o kod HTMLa), Microsoft proponuje tworzenie serwisów w oparciu o wzorzec MVC i routing (ładne tworzenia URL) za pomocą biblioteki ASP.NET MVC Preview 2. Prelegent pokazał jak tworzyć ładne adresy URL, obróbkę na modelach danych za pomocą LINQ (to jest taka technologia pozwalająca używać składni SQL na obiektach danych w pamięci aplikacji). Następnie pokazywał jak używać systemów szablonowych (podobnych do Smarty w PHP) - są to Brail, NVelocity, HAML. Potem omówił założenia tworzenia aplikacji internetowych opartych na tworzeniu testów TDD z VisualStudio, NUnit, MbUnit (piszesz najpierw interfejs, potem test, a dopiero po napisaniu testów pisze się implementację interfejsu programistycznego). Linki z dokumentacjami o tej technologii: QuickStarts, materiały video, oraz kod źródlowy tej biblioteki. Podsumowanie: to jest dobre rozwiązanie dla firm której programiści stosują oprogramowanie webowe opartych o wzorzec MVC - Ruby on Rails, Django, Symfony czy Springs i chcą tworzyć średnie i duże projekty internetowe w oparciu o technologie .NET.

"Interfejs użytkownika 2.0"
Prelegent: Szymon Kobalczyk, InterKnowlogy
Jednym z ważnych skutków fali serwisów Web 2.0 jest skupienie uwagi na komforcie pracy użytkownika. Wygląd oraz ergonomia pracy często stanowi jedno z pierwszych kryteriów wyboru aplikacji, niezależnie od tego, czy dostarczane są w zafoliowanym pudełku, czy poprzez przeglądarkę internetową. Podczas prezentacji prelegent zaprezentował sposoby projektowania aplikacji z bogatym, niestandardowym interfejsem graficznym, wykorzystującym zalety technologii Windows Presentation Foundation i Silverlight. Pokazał przykłady oparte o istniejące komercyjnie wdrożenia. Wykład miał charakter przeglądowy. Pokazywał jak bardzo zmienia się wygląd aplikacji pod Windows w których wykorzystano technologię Windows Presentation Foundation co sprawia że wygląd bardziej staje się zbliżony do interfejsu serwisów internetowych i jak aplikacji z interfejsem 3D. Ponieważ jest potrzeba tworzenia bardziej "elastycznego" interfejsu użytkownika do aplikacji internetowych to Microsoft wprowadził technologię SilverLight Pokazał przykładową aplikację wykorzystujące interfejs 3D - 3D Collabolator i aplikacje desktopowe przypominające interfejs strony internetowej. Pokazywał też przykładowe aplikacje w Silverlight 2.0 - iZooFari Podsumowanie: moc kart GPU pozwala na wykorzystanie interfejsu trójwymiarowego w aplikacjach komputerowych i jak internetowych.

"Świat z klocków"
Prelegent: Michał Żyliński, Microsoft Polska
Windows Live Services to gama mało znanych w Polsce usług pozwalających na łatwe wzbogacenie funkcjonalności serwisów WWW i aplikacji komputerowych. Podczas sesji prelegent dokonał ich przeglądu oraz pokazał kilka ciekawych zastosowań w praktyce.Usługi MS dla serwisów WWW i aplikacji to:

  • Live Photos ma API do zarządzania własnymi zdjęciami
  • Writer edytor do blogów, który ma własne SDK do rozszerzania funkcjonalności
  • Spaces jest dla programistów którzy chcą tworzyć serwisy społecznościowe
  • Live Search pozwala dodać wyszukiwarkę Microsoftu na własną stronę
  • Messenger pozwala na używanie komunikatora w własnych aplikacjach i na stronach WWW
  • Alerts - rozsyłanie komunikatów - odpowiednik Twittera
  • Live Agents - dodawanie awatarów (z syntezą mowy) do własnych aplikacji i stron WWW


Prelegent wspomniał jeszcze o SQL Server Data Services (SSDS) zapewniającą "wirtualny hosting bazy danych" i bibliotece ADO.NET Data Services komunikującej z taką wirtualną bazą danych. Dla programistów potrzebujących zdalnych narzędzi do zarządzania obiegiem informacji w organizacji to Microsoft przygotował usługę BizTalk Services. Natomiast dla programistów internetowych zaproponował projekt Volta generowanie kodu JS/Ajax za pomocą języka C#. Warto zobaczyć Popfly najbardziej zaawansowany edytor aplikacji internetowych (mashupów) dla serwisów internetowych, a także jako przykład nowej generacji serwisu społecznościowego. Wniosek: te technologie są w cieniu ich odpowiedników Google, jedyną zaletą jest interfejs programistyczny - WebServices (SOAP) pozwalający na osadzanie tych usług w aplikacjach komputerowych.

"Nasza jutrzenka: Silverlight 2.0"
Prelegent: Bartłomiej Zass, Microsoft Polska
Silverlight to technologia istotnie zmieniająca sposób konstruowania zaawansowanych, bogatych graficznie aplikacji internetowych. Dostępna publicznie od kilku tygodni nowa wersja testowa przyniosła wiele istotnych zmian i usprawnień. Właściwie prelegent zrobił to co jest pokazane na tych wideoscreenach Silverlight to konkurent dla Adobe FlashPlayera. Obydwie technologie opierają się na wtyczkach do przeglądarki. Silverlight 1 przypominał mi FlashPlayera 6 Posiadał możliwość tworzenia animacji i osadzenia multimediów za pomocą języka znaczników XAML. Można było pisać skrypty JS z poziomu przeglądarki do sterowania animacjami. Silverlight 2 beta to już prawdziwy konkurent Adobe FlashPlayera. Posiada własny silnik wykonawczy CLR wbudowany, co pozwala na pisanie bibliotek dll sterujących aplikacja w Silverlight. Cala aplikacja jest trzymana w jednym pliku *.xap (który jest spakowanym zipem). Posiada kontrolki (takie jak w MXML Flex) Programuje się deklaratywnie (XAML) i jak z poziomu C# (wymaga kompilacji) i jak z poziomu skryptów DLR w Pythonie lub w Ruby) oraz można sterowanć z poziomu strony WWW za pomocą JavaScriptu. Jest łatwy dostęp do danych XML poprzez Linq (w Action Script mamy e4x). Występuje komunikacja binarna za pomocą socketów. Wygląd aplikacji można stylować poprzez CSS albo zastosować skórki. FlashPlayer ma jeszcze przewagę nad Silverlightem bo pozwala na dwukierunkową transmisję wideo i audio Prezentowane narzędzia to: Silverlight Tools for VS2008 dla programistów używających Visual Studio 2008 Microsoft Expression Blend 2.5 March 2008 Preview - dla programistów (takich którzy nie chcą używać Visual Studio) Dla grafików poleca się narzędzie Expression Design 2 beta a dla webmasterów ASP.NET i PHP to jest narzędzie Expression Web 2 W praktyce można serwisy wykorzystujące Silverlight robić notatnikiem albo jakimś opensourcowym edytorem typu SharpDevelop

Krótka sesja niespodzianka - Hubert Turaj z Making Waves omawiał testowanie użyteczności aplikacji Flex na przykładzie Kalkulatora Energii. Dla mnie ta aplikacja Flex jest przykładem jak interfejs użytkownika znany z gier komputerowych wkracza w sferę poważnych aplikacji internetowych. Dla mnie ta aplikacja też jest przykładem wykorzystania WebServices ASP.NET po stronie serwera w celu dostarczania danych i jak frameworka Cairngorm 2 w celu zarządzania widokami aplikacji Flex

Sylwetki prelegentów:
Szymon Kobalczyk, InterKnowlogy
Szymon zatrudniony jest na stanowisku Senior Software Engineer w firmie InterKnowlodgy. Od 7 lat zajmuje się różnymi aspektami technologii .NET, głównie w zakresie projektowania interfejsów dla aplikacji internetowych oraz urządzeń mobilnych. Obecnie specjalizuje się w budowie rozwiązań opartych o Windows Presentation Framework. Szymon jest również jednym z liderów i częstym prelegentem Krakowskiej Grupy Deweloperów .NET oraz członkiem ciała doradczego Patterns & Practices "Prism". Ostatnio został zdobywcą pierwszej nagrody w prestiżowym konkursie "Lab49 WPF in Finance Innovation Contest

Bartłomiej Zass, Microsoft Polska,
ISV Developer Evangelist w dziale Developer & Platform Group polskiego oddziału Microsoft. Zajmuje się współpracą z polskimi firmami wytwarzającymi oprogramowanie, pomagając w skutecznym doborze technologii oraz wykorzystaniu najnowszych rozwiązań. Jako programista uczestniczył w wielu projektach informatycznych. Prelegent polskich i zagranicznych konferencji technicznych. Do jego głównych obszarów zainteresowań należą technologie internetowe oraz zagadnienia konstrukcji interfejsu użytkownika.

Michał Żyliński, Microsoft Polska,
W firmie Microsoft Polska odpowiada za kontakt z szerokim rynkiem partnerskim, specjalizując się w producentach oprogramowania. Służy pomocą w kwestiach technicznych i biznesowych (dobór programów partnerskich, inicjatywy marktingowe). Prowadzi serwis InnovateOn