Tygodniowy wyjazd ze SnowShow dobiegł końca. Przetrwałem bez kontuzji i załamań. Minusem zdecydowanie była podróż autokarem, która w jedną stronę zajmowała 20-kilka godzin. Nieco w zabiciu czasu pomagał alkohol. Podróży do Francji praktycznie nie odczułem czasowo, za to odcisk na czole od plastykowego uchwytu poprzedzającego fotela towarzyszyl mi przez pierwsze 2 dni.
Z 6 dni na stoku trafiły sie 2 pogodne, pozostałe były raczej pochmurne a czasem przynosiły dodatkowe atrakcje w postaci zamieci i mgieł, jak to w górach - pogoda jak kobieta, zmienna jest.
W Les Menuires ceny charakterystyczne dla kurortów Europy zachodniej: piwo 6-8 euro, obiad w postaci frytek ze stekiem ok 14 euro, w podobnej cenie pizza.
Za to miejsca do pojezdzenia pod dostatkiem, zarowno trasy wytyczone jak i offroad, piekna sceneria a i turystow o tej porze nie było zbyt wielu. Reszte niech oddadzą załączone zdjęcia i filmy.
https://plus.google.com/u/0/108701036453403152884/posts/FFLnX4cnxkR
niedziela, 23 grudnia 2012
Ubuntu - oszczędzanie energii
Znalazlem ciekawy opis narzędzi przydatnych do ustawienia wydajności/oszczędzania energii pod Ubuntu:
http://notatnik.mekk.waw.pl/archives/276-Chodniejszy_laptop_pod_Ubuntu_1110.html
http://notatnik.mekk.waw.pl/archives/276-Chodniejszy_laptop_pod_Ubuntu_1110.html
poniedziałek, 26 listopada 2012
Niewidzialna Wystawa
Czy mieliscie okację na chwile 'zobaczyc' swiat oczami niewidomego? Jesli nie to osobiscie polecam - niezwykle doznanie. Pomoze Wam w tym Niewidzialna Wystawa.
Wizyte rozpoczyna poznanie alfabetu Breila i Braile'owskiej maszyny do pisania. Nastepnie obejrzymy inne przedmioty jakimi posługują się osoby niewidome: kalkulator, który czyta liczby pojawiające się na wyświetlaczu, wieszak na skarpety, dzięki któremu nie będziemy nigdy więcej musieli szukać skarpety pasującej do pary (jakże praktyczne narzędzie, które powinno znaleść się również w każdym domu osoby widzących), krajarka do jabłek, która oddzieli ogryzek od reszty kawałków, czytający termometr, układanki (można nawet założyć zaślepki na oczy i samemu spróbować je ułożyć - nie jest to banalne zadanie), mapy z różną teksturą w zależności czy to morze, rzeka czy ląd, komputer ze zwykłą klawiaturą ale czytający tekst z ekranu. Swoją droga dowiedziałem się, że wiele wynalazków na stronach internetowych, które jakoby miały pomóc niewidomym, w praktyce się nie sprawdza bo wymaga od nich kliknięcia na nich myszką (np przyciski do odczytu tekstu) a z wiadomych względów komputery niewidomych pozbawione sa tego urzadzenia.
Po zapoznaniu się z przedmiotami ruszamy na wycieczkę w ciemnościach. Niewidomy przewodnik oprowadzi nas po pokoju, który możemy przemacać wzdłuż i wszerz, ale uwierzcie mi, robiąc niepewne i krótkie kroczki po omacku trudno będzie zbudować wyobrażenie o wystroju jego wnętrza.
Następnie udajemy sie na ulicę, gdzie co krok napotykamy różne uliczne przeszkody. Nie zdradze Wam jakie, żeby nie psuć zabawy.
Z ulicy wchodzimy do leśnej chatki a następnie do lasu. Słychać potok i śpiew ptaków, poza tym ciemno jak w .... Super !! Można legalnie podotykać (niby przypadkiem) współzwiedzająch lub współzwiedzające, w zależności od osobistych preferencji :) i nikt nikomu nie bedzie mial tego za złe (chyba, w moim przypadku nie miały ;) ).
Gdy już przejdziemy las, wchodzimy do baru. Możemy nawet coś kupić do picia czy zjedzenia ale uwaga - przy wydawaniu reszty :) cięzko stwierdzić, czy barman był uczciwy zanim nie wyjdziemy z ciemności, tym cięzej jeśli płacimy w bilonie.
Podsumowując, przeżycie nietuzinkowe i poszerzające horyzonty, godne polecenia każdemu kto ma wzrok.
Warto wspomnieć, że przed wybraniem się na wystawe należy uprzednio się umówić na konkretna godzine i zjawić na miejscu 15 min. przed czasem. Dobrze tez wziasc płaskie wygodne buty bo patrzenie pod nogi może nam już w niczym nie pomóc, a przeszkód pod nogami czai sie wiele.
Wizyte rozpoczyna poznanie alfabetu Breila i Braile'owskiej maszyny do pisania. Nastepnie obejrzymy inne przedmioty jakimi posługują się osoby niewidome: kalkulator, który czyta liczby pojawiające się na wyświetlaczu, wieszak na skarpety, dzięki któremu nie będziemy nigdy więcej musieli szukać skarpety pasującej do pary (jakże praktyczne narzędzie, które powinno znaleść się również w każdym domu osoby widzących), krajarka do jabłek, która oddzieli ogryzek od reszty kawałków, czytający termometr, układanki (można nawet założyć zaślepki na oczy i samemu spróbować je ułożyć - nie jest to banalne zadanie), mapy z różną teksturą w zależności czy to morze, rzeka czy ląd, komputer ze zwykłą klawiaturą ale czytający tekst z ekranu. Swoją droga dowiedziałem się, że wiele wynalazków na stronach internetowych, które jakoby miały pomóc niewidomym, w praktyce się nie sprawdza bo wymaga od nich kliknięcia na nich myszką (np przyciski do odczytu tekstu) a z wiadomych względów komputery niewidomych pozbawione sa tego urzadzenia.
Po zapoznaniu się z przedmiotami ruszamy na wycieczkę w ciemnościach. Niewidomy przewodnik oprowadzi nas po pokoju, który możemy przemacać wzdłuż i wszerz, ale uwierzcie mi, robiąc niepewne i krótkie kroczki po omacku trudno będzie zbudować wyobrażenie o wystroju jego wnętrza.
Następnie udajemy sie na ulicę, gdzie co krok napotykamy różne uliczne przeszkody. Nie zdradze Wam jakie, żeby nie psuć zabawy.
Z ulicy wchodzimy do leśnej chatki a następnie do lasu. Słychać potok i śpiew ptaków, poza tym ciemno jak w .... Super !! Można legalnie podotykać (niby przypadkiem) współzwiedzająch lub współzwiedzające, w zależności od osobistych preferencji :) i nikt nikomu nie bedzie mial tego za złe (chyba, w moim przypadku nie miały ;) ).
Gdy już przejdziemy las, wchodzimy do baru. Możemy nawet coś kupić do picia czy zjedzenia ale uwaga - przy wydawaniu reszty :) cięzko stwierdzić, czy barman był uczciwy zanim nie wyjdziemy z ciemności, tym cięzej jeśli płacimy w bilonie.
Podsumowując, przeżycie nietuzinkowe i poszerzające horyzonty, godne polecenia każdemu kto ma wzrok.
Warto wspomnieć, że przed wybraniem się na wystawe należy uprzednio się umówić na konkretna godzine i zjawić na miejscu 15 min. przed czasem. Dobrze tez wziasc płaskie wygodne buty bo patrzenie pod nogi może nam już w niczym nie pomóc, a przeszkód pod nogami czai sie wiele.
sobota, 1 września 2012
II Bieg Fabrykanta, Łódź
II Bieg Fabrykanta już za nami. Nie było lekko, inaczej niż się spodziewałem. Już na początku złapała mnie kolka która trzymała przez całe pierwsze okrążenie. Możliwe że dlatego, że nie ruszałem sie cały tydzien, tylko praca i praca.. biurko i komputer i takie tego efekty.
Nagrałem zmagania na Endmondo:
jaki by nie był wynik i tak każdy kto dobiegł do końca otrzymał pamiątkowy medal. To już bedzie trzeci w mojej skromnej kolekcji medali za samo uczestnictwo (bo innego to bym w życiu nie dostał :) )
Wg. nieoficjalnych wyników byłem 273 na 340 mężczyzn i 310 na 419 wszystkich uczesników - 10km w 55 min.
Nagrałem zmagania na Endmondo:
jaki by nie był wynik i tak każdy kto dobiegł do końca otrzymał pamiątkowy medal. To już bedzie trzeci w mojej skromnej kolekcji medali za samo uczestnictwo (bo innego to bym w życiu nie dostał :) )
Wg. nieoficjalnych wyników byłem 273 na 340 mężczyzn i 310 na 419 wszystkich uczesników - 10km w 55 min.
poniedziałek, 30 lipca 2012
Parkrun Łódź
Opornie ale powoli do celu biegną moje próby odzyskania kondycji...
Tym razem w sobote pierwszy raz miałem okazje sprawdzić jak wygląda łódzki Parkrun - bieg organizowany w każdą sobote o 9.00. Udział jest darmowy, wystarczy zarejestrować się na stronie i wziąć ze sobą na start wydrukowany kod paskowy dla swojego konta.
Po biegu dostałem maila z taką oto treścią:
Tym razem w sobote pierwszy raz miałem okazje sprawdzić jak wygląda łódzki Parkrun - bieg organizowany w każdą sobote o 9.00. Udział jest darmowy, wystarczy zarejestrować się na stronie i wziąć ze sobą na start wydrukowany kod paskowy dla swojego konta.
Po biegu dostałem maila z taką oto treścią:
| Witaj Marcin! | ||||
| Ten darmowy bieg w ramach parkrun zorganizowany został dzięki naszym wolontariuszom oraz sponsorom: | ||||
 | ||||
| Rezultaty uzyskane podczas parkrun Lódz nr# 5. Uzyskany przez Ciebie czas to {26:02}. | ||||
|
środa, 13 czerwca 2012
NodeJs, szybki start na Windows
JavaScript staje sie coraz bardziej popularnym i coraz bardziej dojrzalym językiem programowania wiec pora sprawdzić jaka siła dżemie w NodeJs.
NodeJs to JavaScript uruchamiany na maszynie wirtualnej Chrome. Taki serwer JavaScript mozna postawic samodzielnie lub wykorzystac juz istniejace, np. wsparcie od CloudFoundry.
W tym celu rejestrujemy się i ściagamy obraz Micro CloudFoundry. Opisywałem to już w jednym ze swoich postów, dlatego pominę szczegóły.
Żeby komunikować się z CloudFoundry potrzebujemy narzędzie vmc instalowane jako RubyGem.
1. Instalujemy Ruby pod Windowsem
http://docs.cloudfoundry.com/frameworks/ruby/installing-ruby.html#windows
2. Z Ruby shell updatujemy RubyGem
4. Rejestrujemy docelowe srodowisko CloudFoundry, w przypadku Micro CloudFroundry np:
5. Logujemy sie do CloudFoundry swoim loginem i haslem podanymi przy konfiguracji obrazu Micro CloudFoundry
Aby wyswietlic liste dostepnych polecen:
Teraz mozemy stworzyc prosta aplikacje NodeJs i zainstalowac na serwerze:
1. Sprawdzamy wersje zainstalowanego na serwerze NodeJs
2. Sciagamy taka sama wersje NodeJs z http://nodejs.org/dist/ gdzie wybieramy odpowiednia wersje i szukamy instalatora pod Windows *.msi
Po instalacji bedziemy mieli w zmiennych srodowiskowych program node.exe oraz npm.exe
4. Instalujemy modul 'express' przy użyciu Node Package Manager'a
5. Tworzymy plik aplikacji app.js
http://howtonode.org/hello-node
http://docs.cloudfoundry.com/services/rabbitmq/nodejs-rabbitmq.html
http://blog.cloudfoundry.com/2012/05/17/node-activity-streams-app-1/
http://blog.cloudfoundry.com/2012/06/05/node-activity-streams-app-2/
http://coreh.github.com/nide/
NodeJs to JavaScript uruchamiany na maszynie wirtualnej Chrome. Taki serwer JavaScript mozna postawic samodzielnie lub wykorzystac juz istniejace, np. wsparcie od CloudFoundry.
W tym celu rejestrujemy się i ściagamy obraz Micro CloudFoundry. Opisywałem to już w jednym ze swoich postów, dlatego pominę szczegóły.
Żeby komunikować się z CloudFoundry potrzebujemy narzędzie vmc instalowane jako RubyGem.
1. Instalujemy Ruby pod Windowsem
http://docs.cloudfoundry.com/frameworks/ruby/installing-ruby.html#windows
gem update --system
3. Instalujemy VMCgem install vmc4. Rejestrujemy docelowe srodowisko CloudFoundry, w przypadku Micro CloudFroundry np:
vmc target http://api.piczkowski.cloudfoundry.megdzie piczkowski to nazwa mojego konta na CloudFoundry.
5. Logujemy sie do CloudFoundry swoim loginem i haslem podanymi przy konfiguracji obrazu Micro CloudFoundry
vmc login Attempting login to [http://api.piczkowski.cloudfoundry.me] Email: piczmar@wp.pl Password: *********
Aby wyswietlic liste dostepnych polecen:
vmc help
Teraz mozemy stworzyc prosta aplikacje NodeJs i zainstalowac na serwerze:
1. Sprawdzamy wersje zainstalowanego na serwerze NodeJs
vmc runtimes
2. Sciagamy taka sama wersje NodeJs z http://nodejs.org/dist/ gdzie wybieramy odpowiednia wersje i szukamy instalatora pod Windows *.msi
Po instalacji bedziemy mieli w zmiennych srodowiskowych program node.exe oraz npm.exe
node.exe
> process.versions
{ node: '0.6.5',
v8: '3.6.6.11',
ares: '1.7.5-DEV',
uv: '0.6',
openssl: '0.9.8r' }
>
3. Tworzymy folder projektu
mkdir hello-nodejs
cd hello-nodejs
4. Instalujemy modul 'express' przy użyciu Node Package Manager'a
npm install express
5. Tworzymy plik aplikacji app.js
var app = require('express').createServer();
app.get('/', function(req, res) {
res.send('Hello from Cloud Foundry');
});
app.listen(process.env.VCAP_APP_PORT || 3000);CloudFoundry udostepnia port nasluchujacy pod zmienna srodowiskowa process.env.VCAP_APP_PORT
6. Tworzymy plik z zaleznosciami package.json
{
"name":"hello-node",
"version":"0.0.1",
"dependencies":{
"express":""
}
}
7. Instalujemy na CloudFoundry
vmc loginvmc pushE:\git\try-it-out\com.tryitout.nodejs\src\main\hello-nodejs>vmc push
Would you like to deploy from the current directory? [Yn]: y
Application Name: hello-nodejs
Detected a Node.js Application, is this correct? [Yn]: Y
Application Deployed URL [hello-nodejs.piczkowski.cloudfoundry.me]:
Memory reservation (128M, 256M, 512M, 1G, 2G) [64M]:
How many instances? [1]:
Create services to bind to 'hello-nodejs'? [yN]: N
Would you like to save this configuration? [yN]: y
Manifest written to manifest.yml.
Creating Application: OK
Uploading Application:
Checking for available resources: OK
Processing resources: OK
Packing application: OK
Uploading (271K): OK
Push Status: OK
Staging Application 'hello-nodejs': OK
Starting Application 'hello-nodejs': OK
8. Dzialajaca aplikacje mozemy teraz obejrzec pod adresem
http://hello-nodejs.piczkowski.cloudfoundry.me
i wynik.. (niezbyt okazały...)
Wiecej tutoriali do sprawdzenia pod linkami:
http://blog.cloudfoundry.com/2012/05/24/cloud-foundry-supports-node-js-modules-with-npm/http://howtonode.org/hello-node
http://blog.springsource.org/2011/05/03/using-mongodb-redis-node-js-and-spring-mvc-in-a-single-cloud-foundry-application/http://attilamiklosi.net/blog/tag/nodejs/
http://docs.cloudfoundry.com/services/mongodb/nodejs-mongodb.html
http://docs.cloudfoundry.com/services/rabbitmq/nodejs-rabbitmq.html
http://blog.cloudfoundry.com/2012/05/17/node-activity-streams-app-1/
http://blog.cloudfoundry.com/2012/06/05/node-activity-streams-app-2/
http://coreh.github.com/nide/
wtorek, 29 maja 2012
Accreo Ekiden Warszawa 2012
Ostatnio duże zmiany..
Nowa praca, nowe miasto i nowe przygody biegowe :)
W ostatnią niedziele odbyła się w Warszawie sztafeta Accreo Ekiden w której wystartowałem w teamie z pracy. Ja przebiegłem odcinek 7km, pozostali 10, 10, 5, 5 i 5, razem dystans maratoński.
Niestety długa przerwa bez regularnych treningów zrobiła swoje. Zakończyłem z czasem 36 min.
To dało naszej drużynie 192 miejsce na 402 drużyny - całkiem nieźle.
Każdy uczestnik dostawał pamiątkowy medal - to będzie już drugi w mojej karierze amatorskiej biegacza.
Pierwsze zdjęcia już do obejrzenia na stronie http://www.accreoekiden.pl/pierwsza-galeria-zdjec
Wyniki i mapka trasy
Nowa praca, nowe miasto i nowe przygody biegowe :)
W ostatnią niedziele odbyła się w Warszawie sztafeta Accreo Ekiden w której wystartowałem w teamie z pracy. Ja przebiegłem odcinek 7km, pozostali 10, 10, 5, 5 i 5, razem dystans maratoński.
Niestety długa przerwa bez regularnych treningów zrobiła swoje. Zakończyłem z czasem 36 min.
To dało naszej drużynie 192 miejsce na 402 drużyny - całkiem nieźle.
Każdy uczestnik dostawał pamiątkowy medal - to będzie już drugi w mojej karierze amatorskiej biegacza.
Pierwsze zdjęcia już do obejrzenia na stronie http://www.accreoekiden.pl/pierwsza-galeria-zdjec
Wyniki i mapka trasy
sobota, 5 maja 2012
JSON editor w Eclipse
Prosty i przydatny edytor z http://sourceforge.net/projects/eclipsejsonedit/ , jednak instalacja nie byla tak oczywista. 'Instaluj z pliku zip' nie działało. Wystarczyło natomiast skopiować zawartości folderów 'plugins' i 'features' do 'plugins' i 'features' w katalogu domowym Eclipse. U mnie działa :) Sprawdzałem w Eclipse Inigo i Spring Source Tools Suite.
poniedziałek, 26 marca 2012
Grails + CloudFoundry z linii komend
Wykonujemy kolejne kroki:
grails create-app cloudfoundry_example
cd cloudfoundry_example
edit: grails-app/conf/Config.groovy
grails.plugin.cloudfoundry.username = "<your_username>"
grails.plugin.cloudfoundry.password = "<pass>"
Alternatywnie mozna te ustawienia zapisac w
USER_HOME\.grails\settings.groovy gdzie USER_HOME to katalog domowy uzytkownika.Wtedy jednak ustawienie wpisow na poziomie aplikacji (Config.groovy) jest ignorowane.
grails install-plugin cloud-foundry
grails prod cf-push
grails prod cf-update
wiecej komend:
grails cf-help
Odnośniki:
http://blog.swierczynski.net/2012/01/cloud-foundry-grails-lightning-fast-deployment/
33rd Degree Kraków 2012
Druga już konferencja 33rd Degree w Krakowie rozpoczęła się 19 marca 2012
Plan trzech dni wyglądał następująco ( wyróżnione opcjonalne sesje, w których uczestniczyłem):
Czasem trudno było wybrać ścieżkę spośród tak wielu interesujących pokrywających się wykładów. Poniżej przedstawiam sprawozdanie z wykładów, w kórych miałem okazję uczestniczyć.
Raffi pracuje jako Platform Services Director w Twitter. Opowiedział o migracji z Ruby na JVM w Twitterze. Dlaczego była potrzebna, jakie były ograniczenia istniejącej platformy i co nowego zyskała w połączeniu z Java?
Twitter codziennie odbiera od 100 miliona użytkowników ok. 250 milionów tweetów.
Każdy tweet jest duplikowany do followerów co daje średnio 2.5 E9 doręczeń na dobe.
Ruby on Rails charakteryzuje sie tym, że używa interpreterów opartych na jęz. C, jest jęz. dynamicznym, nie jest tak szybki jak jęz. kompilowane (np Java). Zaletą jego jest to, że jest ekspresywny, pisze się w nim łatwo i przyjemnie.
80% serwisów Twittera jest napisanych w Ruby, komunikują się one na końcu z Javą. Do komunikacji uzywany jest szybki protokół SPDY (czyt. Speedy).
Jednym ze sposobów usprawnienia Ruby było napisanie szybszego garbage collector'a - Kiji.
Chociaż obecnie istnieje implementacja Ruby na platformie JVM (JRuby) to w roku 2008, kiedy w Twiterze zaczęto migrować Ruby na platformę JVM, JRuby było jeszcze zbyt mało rozwinięte, dlatego zdecydowano sie na własne rozwiązania.
Java nie jest jęz. zbyt ekspresywnym, więc na celowniku znalazła sie Scala. Jest szybka, statycznie typowana, jest ekspresyjnym jęz. funkcyjnym, ma wsparcie dla współbieżności (w przeciwieństwie do Ruby 1.8).
Zalety JVM:
- zdolność radzenia sobie z obciążeniem serwera
- elastyczność językowa, dobre wsparcie dla innych języków
- prawdziwy model wielowątkowy
Developerzy Tweetera opracowali Finagle - asynchroniczny RPC (Remote Procedure Call), opracowali wlasny JVM, stuningowali JVM garbage collector ściśle zintegrowany z Finagle.
Konkluzja z prezentacji brzmi: przerzucenie się na JVM nie oznacza, że Ruby to pomyłka.
Przy projektowaniu systemów nie należy od razu tworzyc systemu, kóry poradzi sobie ze wszystkim, bedzie skalowalny, wydajny i szybki. Należy raczej projektować system tak, by łatwo było go zmienić, ale nie wprowadzać od początku nieuzasadnionego skomplikowania. Historia Twittera obrazuje, że gdy zachodzi potrzeba, wtedy należy przebudować system, tak jak gdy zintegrowano Ruby ze Scala.
Ken opowiedział o przyczynach skomplikowania. Rozróżnił skomplikowanie systemów na tzw. konieczne, wynikające z tego, że czegoś nie da sie juz zrobić prościej i przypadkowe, wynikające, czy to z niewiedzy, czy z niedbalstwa, czy z przesadnego dbania np. o skalowalność systemu już na samym początku jego istnienia, gdy jeszcze nie wystąpiły takie problemy.
Co oznacza, że coś jest nieskomplikowane? To znaczy, że coś jest:
- proste
- wygodne
- znajome
- przyjazne dla nowicjusza
To nie pojedyncze elementy systemu sa skomplikowane, tylko te same elementy współgrające z innymi elementami. Czynniki sprzyjające skomplikowaniu to:
- zespół: jego rozmiar, doświadczenie, często mówi sie tu o modelu Dreyfusa, w którym wyróznia się następujące poziomy doświadczenia: nowicjusz, zaawansowany nowicjusz, kompetentny, profesjonalista, ekspert
- przesadna troska o wydajność, skalowalność zanim te problemy jeszcze wystąpiły
Tuningować powinniśmy system dopiero, gry wystąpią problemy z wydajnością a nie na zapas.
- użycie technologii przerasających potrzeby, jak gdyby użyć rakiety do wypadu na zakupy
- utknięcie w tzw. 'dobrych praktykach' z pominięciem zdrowego rozsądku i aplikowaniem tych dobrych praktyk wszędzie niezależnie od kontekstu. Dobrze zostało to opisane w książce Hackers & Painters
Dobre praktyki sa dobre dla zaawansowanych nowicjuszy, ale odstraszają ekspertów.
- niejasne wymagania, prowadzą do przypadkowego skomplikowania systemu.
Sylvain Lebresne - The Apache Cassandra storage engine
Aktualnie istnieje ok. 2000 jęz. programowania na platformę JVM. Java integruje w pewien sposób je wszystkie.
Wśród punktów integracji języków można wyróżnić:
- bazę danych
- serwisy (przez JSON, XML)
- język, czyli w kodzie jednego języka używamy konstrukcji wywołujących kod z innego języka.
http://jlaskowski.blogspot.com/2012/03/po-33rd-degree-2012-w-krakowie-nie.html
Plan trzech dni wyglądał następująco ( wyróżnione opcjonalne sesje, w których uczestniczyłem):
Day 1
19 March, Monday
Day 2
20 March, Tuesday
Day 3
21 March, Wednesday
Czasem trudno było wybrać ścieżkę spośród tak wielu interesujących pokrywających się wykładów. Poniżej przedstawiam sprawozdanie z wykładów, w kórych miałem okazję uczestniczyć.
Raffi Krikorian - Twitter: From Ruby on Rails to the JVM
Raffi pracuje jako Platform Services Director w Twitter. Opowiedział o migracji z Ruby na JVM w Twitterze. Dlaczego była potrzebna, jakie były ograniczenia istniejącej platformy i co nowego zyskała w połączeniu z Java?
Twitter codziennie odbiera od 100 miliona użytkowników ok. 250 milionów tweetów.
Każdy tweet jest duplikowany do followerów co daje średnio 2.5 E9 doręczeń na dobe.
Ruby on Rails charakteryzuje sie tym, że używa interpreterów opartych na jęz. C, jest jęz. dynamicznym, nie jest tak szybki jak jęz. kompilowane (np Java). Zaletą jego jest to, że jest ekspresywny, pisze się w nim łatwo i przyjemnie.
80% serwisów Twittera jest napisanych w Ruby, komunikują się one na końcu z Javą. Do komunikacji uzywany jest szybki protokół SPDY (czyt. Speedy).
Jednym ze sposobów usprawnienia Ruby było napisanie szybszego garbage collector'a - Kiji.
Chociaż obecnie istnieje implementacja Ruby na platformie JVM (JRuby) to w roku 2008, kiedy w Twiterze zaczęto migrować Ruby na platformę JVM, JRuby było jeszcze zbyt mało rozwinięte, dlatego zdecydowano sie na własne rozwiązania.
Java nie jest jęz. zbyt ekspresywnym, więc na celowniku znalazła sie Scala. Jest szybka, statycznie typowana, jest ekspresyjnym jęz. funkcyjnym, ma wsparcie dla współbieżności (w przeciwieństwie do Ruby 1.8).
Zalety JVM:
- zdolność radzenia sobie z obciążeniem serwera
- elastyczność językowa, dobre wsparcie dla innych języków
- prawdziwy model wielowątkowy
Developerzy Tweetera opracowali Finagle - asynchroniczny RPC (Remote Procedure Call), opracowali wlasny JVM, stuningowali JVM garbage collector ściśle zintegrowany z Finagle.
Konkluzja z prezentacji brzmi: przerzucenie się na JVM nie oznacza, że Ruby to pomyłka.
Ken Sipe - Complexity of Complexity
Ken opowiedział o przyczynach skomplikowania. Rozróżnił skomplikowanie systemów na tzw. konieczne, wynikające z tego, że czegoś nie da sie juz zrobić prościej i przypadkowe, wynikające, czy to z niewiedzy, czy z niedbalstwa, czy z przesadnego dbania np. o skalowalność systemu już na samym początku jego istnienia, gdy jeszcze nie wystąpiły takie problemy.
Co oznacza, że coś jest nieskomplikowane? To znaczy, że coś jest:
- proste
- wygodne
- znajome
- przyjazne dla nowicjusza
To nie pojedyncze elementy systemu sa skomplikowane, tylko te same elementy współgrające z innymi elementami. Czynniki sprzyjające skomplikowaniu to:
- zespół: jego rozmiar, doświadczenie, często mówi sie tu o modelu Dreyfusa, w którym wyróznia się następujące poziomy doświadczenia: nowicjusz, zaawansowany nowicjusz, kompetentny, profesjonalista, ekspert
- przesadna troska o wydajność, skalowalność zanim te problemy jeszcze wystąpiły
Tuningować powinniśmy system dopiero, gry wystąpią problemy z wydajnością a nie na zapas.
- użycie technologii przerasających potrzeby, jak gdyby użyć rakiety do wypadu na zakupy
- utknięcie w tzw. 'dobrych praktykach' z pominięciem zdrowego rozsądku i aplikowaniem tych dobrych praktyk wszędzie niezależnie od kontekstu. Dobrze zostało to opisane w książce Hackers & Painters
Dobre praktyki sa dobre dla zaawansowanych nowicjuszy, ale odstraszają ekspertów.
- niejasne wymagania, prowadzą do przypadkowego skomplikowania systemu.
Venkat Subramaniam - Pointy haired bosses and pragmatic programmers: Facts and Fallacies of Software Development
Venkat był moim zdaniem najbardziej energetyzującym mówcą. Na jego prezentacji nie sposób było się nudzić. Imponowała prędkośc z jaką poruszał się po omawianych tematach, odpowiadał na pytania, żąglował narzędziami. Cały czas podtrzymywał zainteresowanie swoją ekspresją i żartobliwymi wstawkami. Tytułowy boss to ten drzemiący w nas samych. Kompetentni pasjonaci prowadzą firmę ku zwycięstwu. Problem w tym, aby takiego indywidualiste w sobie obudzić i utrzymać zamiast ulegania konformizmom.
Doświadczenia wskazują, że w grupie ludzie starają się być zgodni z ogółem, dostosowują do większości i za nią podążają. Rzadko kiedy trafia się indywidualista, kóry podąża swoją drogą. Jeśli już dostosowujemy się do większości, dlaczego nie wybrać tych najinteligentniejszych, najbystrzejszych.
Możnaby powiedzieć, że Venkat rozprawiał o rzeczach oczywistych, ale robił to w taki sposób, że niesposób było się nudzić. Przy okazji tez pojawiło się pare wzmianek literatury godnej uwagi:
Venkat mowił o tym, że systemy stają się skomplikowane, dlatego, że zmieniamy je nieustannie, nawet jeśli nie potrzeba - standaryzacja przed innowacją. Powinno być natomiast odwrotnie, najpierw robimy coś innowacyjnie, dopiero standaryzujemy takie rozwiązanie, czyli znajdujemy dla niego wiele zastosowań.
Wspomniał też, że "mniej znaczy więcej" - tak jest np. z nowymi językami programowania. Porównał je pod kątem dyanamiczności i mocnego typowania. Powstała macierz:
Niektóre z nich dają swobodę pisania, są bardziej ekspresyjne od innych. Są tylko narzędziami do osiągnięcia celu. W zależności od danej potrzeby użyjemy jednego bądź innego.
Nie bójmy się eksperymentować i podejmować nowych rozwiązań w myśl:
"A professional who doesn't learn to fail, fails to learn"
Frederic Simon - Build Trust in Your Build to Deployment Flow!
Frederic mówił o Continuous Delivery. Podkreślił jego zalety takie jak:
- zawsze ostatnia wersja na produkcji, nie trzeba wspierać wielu wersji, legacy kodu.
- szybki feedback użytkowników
- użytkownicy są najlepszymi beta testerami
Pokazał przy tym narzędzie od jfrog: Artifactory
Zapewnia ono śledzenie binarnych wersji komponentów i ich źródeł. Dzięki pluginowi dla Jenkinsa, Bamboo i TeamCity możliwa jest integracja Artifactory z narzędziami do Continuous Integration.
Pojawiło się tez pojęcie Agile Lifecycle Managment (ALM), opisane w książce Agile ALM autorstwa Michael'a Hüttermann'a.
Artifactory dobrze wpisuje sie w ten cykl życia.
Sylvain pracuje w Datastax, gdzie zajmuje się Cassandrą.
Cassandra to baza danych:
- rozproszona, brak struktury master-slave
- replikowalna
- skalowalna
- odporna na błędy, brak jednego słabego punktu (SPOF - single point of failure)
Model danych:
- no SQL
- klucz-wartość
- zainspirowana przez Google BigTable
- oparta na rodzinach kolumn (rodzina kolumn jest analogiczna z tabelą w bazie SQL)
Kluczem jest UUID (universally unique identifier), analogicznie do numeryczych kluczy w SQL, natomiast w rozproszonych bazach trudno jest inkrementowac klucz, stąd takie rozwiązanie.
Każdy wiersz (rodzina kolumn) może mieć różną liczbę kolumn. Kolumny są posortowane na podstawie nazwy klucza. Limitem jest 2 miliardy kolumn w jednej rodzinie kolumn.
Mechanizm zapisu/odczytu danych:
Zapis jest trudniejszy do skalowania niż odczyt. Odczytywane dane mogą być cachowane.
Zapis powoduje losowe operacje wejścia/wyjścia na dysku, dlatego zapis jest wolny.
Zapis:
Przy zapisie wiersza najpierw trafia on do pamieci, tzw. Memtable, jednoczesnie na dysku zapisuje sie commit log, na wypadek gdyby nagle node bazy padł, wtedy przy restarcie z commit loga mozna odtworzyc ostatnio wykonywane operacje. Periodycznie dane z Memtable sa zapisywane na dysku jako SSTable. Zapis jest sekwencyjny. Casandra nie rozróżnia zapisu od updatu. Przy updacie jest zapisywany nowy wiersz z nowymi polami. Periodycznie robione jest tzw. kompaktowanie, które zbiera wszystkie wiersze z tym samym UUID i merguje w jeden wiersz. Kompaktowanie ma na celu zmniejszenie liczny SSSTable, w ten sposób search jest szybszy.
Kazdy wiesz ma swoj czas zycia. Jesli czas ten minął to przy kompaktowaniu wiersz taki jest usuwany z bazy.
Odczyt:
Przy odczycie nieskompaktowanych wierszy robiony jest merge i brane najaktualniejesze pola.
Optymalizacje Cassandry otrzymuje się przez:
- cache wierszy
- cache kluczy
- bloom filter (eliminowanie SSTables)
- indexy na kolumnach i wierszach
Spójność danych reguluje się przez określenie przy zapisie ile nodów musi zwrócić acknowledge.
Cassandra nie ma wsparcia dla tranzakcji, ale można je dodać dodatkowym narzędziem takim jak Zookeeper.
Wojciech Seliga - "Every Rose Has Its Thorn": Taming automated tests beast.
Trzymanie wszystkich testów w jednym module i ich odpalanie przy każdym komicie nie jest dobrym rozwiązaniem i konsumującym dużo czasu.
Rozwiązania pozwalające skrócić czas testowania:
- nieużywanie testów UI (np. Selenium), zamiast tego Page Object Pattern
- setup testów z wykorzystaniem serwisów REST zmiast XMLi, np. użycie własnej annotacji @Category zamiast @Ignore pozwala pamiętać o testach pominiętych, dzięki czemu nie są one zapomniane zaśmiecając kod i powodując niepotrzebny nakład czasu przy kompilacji.
- testowanie tylko zależnych testów, np. jeśli wprowdzaliśmy zmiany w module A testowanym przez TA a TB i TC zaleza od A, to testujemy tylko te moduly a nie uruchamiamy wszystkie testy.
- pojedynczy setup dla kilku testów
- podzielenie codebase na mniejsze unity.
Josh Long - BOF: Spring and CloudFoundry
Panel dyskusyjny na temat Spring Cloud Foundry, planów co do jego przyszłości. Uczestnicy zastanawiali się czy SpringSource przyjmie politykę jak Google App Engine i będzie zmuszać użytkowników do periodycznych upgradów software'u do nowych wersji technologii, czy może bedzie też wspierać kilka wersji (MongoDB, Cassandra). Być może SpringSource powinien wystawić deweloperską chmure CloudFoundry na której będą do wyboru wszystkie technologie ze stosu Spring (aktualnienie nie wszystkie są wspierane w chmurze produkcyjnej). SpringSource w połowie roku 2012 zacznie pobierać za CloudFoundry opłaty.
Barry O'Reilly - Agile, Lean and Startups practice & principles to create the ultimate value creation machine
Barry podzielił sie swoim doświadczeniem i narzędziami związanymi z agile, lean i startup.
Jednym z takich narzędzi jest Business Model Canvas, diagram pozwalający na jednej stronie umieścić do kogo skierowany jest nasz business, jak zamierzamy z niego zarabiać, jakimi kanałami dostępu do odbiorców będziemy sie posługiwać itd. Formularz taki można też łatwo pokazać drugiej osobie (klientowi, inwestorowi?) i szybko wyjaśnić o co nam chodzi.
Następnie Barry wyjaśnił jak się tworzy biznes model a potem waliduje z grupą docelową.
Pierwszym etapem jest burza mózgow i ustalenie:
- kim są ludzie związani z businessem (żeby lepiej ich sobie zwizualizować rysujemy te osoby, jak wyglądają, czym się zajmują, gdzie mieszkają itd..)
- uliczne ankiety z potencjalnymi użytkownikami, jakie są ich oczekiwania, jak używaliby naszego systemu?
- ankiety online
Trudno jest stworzyć system który będzie kierowany do wszystkich, dlatego trzeba się ograniczyć do pewnej grupy odbiorców.
W tym temacie można polecić książkę Agile Experience Design.
Kolejnym etapem jest walidacja produktu. Śledzimy statystyki z użyciem Google Analytics i analizowanie gdzie użytkownicy spędzają najwięcej czasu, gdzie spotykają utrudnienia, jak nawiguja po naszej stronie. Informacje te posłuża do usprawnienia systemu.
Przydatną technika jest Value Stream Mapping - rysujemy proces w formie sekwencyjnego diagramu i analizujemy punkty które zajmują najwięcej czasu, aby je wyeliminować/usprawnić. Patrzymy też na intersekcje z innymi systemami, jesli np. nasz serwis ma odsyłacze gdzieś na zewnątrz, przykład: używamy zewnetrznego serwisu do obsługi płatności online.
Im szybciej dostaniemy feedback tym lepiej.
James Lewis - Micro services - Java, the Unix Way
James pracuje w ThoughtWorks. ThoughtWorks wydaje regularnie darmowy magazyn online - Technology Radar w którym podsumowuje zmiany trendów i technologii.
W ostatnim marcowym numerze pojawił się artykuł o Micro Services, który był przedmiotem tego wykładu.
Micro services są alternatywą dla tradycyjnych serwisów, sa to proste, samodzielne aplikacje instalowane poza kontenerem aplikacji. Każdy serwis posiada wbudowany lekki serwer, np Jetty i komunikuje sie z pozostałymi serwisami po HTTP na różnych portach.
Serwisy są odpowiedzią na skomplikowanie aplikacji i szybko zmieniające sie wymagania. Dekompozycja na małe moduły, które można szybko napisać od nowa zamiast zmieniać istrniejący, silnie zależny od siebie kod to interesujące podejście wpisujace sie dobrze w techniki Continuous Deployment.
Organizacja drużyny projektowej wokół niezależnych modułów (Conway's Law) pozwala też lepiej nimi zarządzać i szacować nakład pracy.
James podkreślił w jaki sposób czasami uproszczona architektura ukrywa w sobie skomlikowanie, np. zmiana architektury pear-to-pear w architekture z użyciem ESB (Enterprise Serial Bus) czyli szyny danych. W rzeczywistości diagram systemu jest prostszy ale skomplikowanie nadal istnieje, tym razem wewnątrz szyny.
W książce REST in Practice opisano jak efektywnie zaimplementować coś w REST, co zwykle byłoby robione z ESB.
Przydatny standard to RFC 5023, czyli The Atom Publishing Protocol.
Charakterystyka mikroserwisów:
- małe, wystarczajaco małe by można je było w każdej chwili wyrzucic i napisać od nowa
- samodzielne
- nie działaja w kontenerze, są instalowane jako serwisy unixowe/linuxowe, np zawierają wbudowany serwer Jetty - ma to zalety w testowaniu (inproctester) i ułatwia deployment
- spakowane jako pojedynczy wykonywalny jar zawierajacy konfigurację, standardowe skrypty unixowe rc.d
- umieszczone w różnych repozytoriach VCS (version control systems) dla zapewnienia separacji
- Domain Driven Design
- tworzone wg. Unix Philosophy
- wykorzystanie Puppet do przygotowania serwisów do użycia
Venkat rekomendował doskonałą książkę o programowaniu współbieżnym w Javie: "Java Concurrency in Practice", Brian Goetz.
95% kodu Java jest popsute dla współbieżności i nawet o tym nie wiemy. Programowanie współbieżne jest jak spacer z teściową - ona wie kiedy się wygłupiliśmy ale nie powie nam o tym, będzie się po cichu naśmiewać. Zamiast cierpieć przy wielowątkowości w Javie z całym nadmiarowym kodem dla synchronizacji Venkat pokazał jak wykorzystać biblitekę clojure.jar wprowadzając tranzakcje.
Użył przykłądu ze swojej książki Programming Concurrency on the JVM: Mastering Synchronization, STM, and Actors, do której kod można za darmo ściągnąć ze strony.
Tutaj przedstawiam ten wyekstraktowany przykład uruchamiany na JDK 7 jako projekt Maven.
W przykłądzie wykorzystany jest prosty model biznesowy wyciągu z konta bankowego wykonywanego jednocześnie przez 2 metody - 'deposit' i 'withdraw', każda otoczona tranzakcją. Następnie metoda 'transfer' otacza te 2 metody jeszcze jedną zewnętrzną tranzakcją. Zasada jest taka, że jeśli jakakolwiek z tych metod zwróci wyjątek, zewnętrzna tranzakcja nie powinna się powieść. Np:
z konta = $2000, przelewamy $5000 na inne konto, tranzakcja powinna być anulowana.
z konta = $2000, przelewamy $5000 na inne konto, tranzakcja powinna być anulowana.
Wolf Schlegel - Workshop: Exploring parallel programming in Java
To były praktyczne warsztaty poprowadzone przez pracownika z ThoughtWorks z Hamburga. przy okazji - ThoughtWorks rekrutuje.
Java 7 wprowadza nowe API do wielowątkowości. W czasie tej sesji staraliśmy się porównać szybkość działania sekwencyjnego i współbieżnego dla prostego algorytmu sortowania.
Kody do testów dostarczone przez Wolfa wrzuciłem na githuba razem z prezentacją z warsztatu. Większość czasu zajęło nam napisanie algorytmu sortowania, tak że na zabawę API do współbieżności zostało już niewiele czasu.
Java 7 wprowadza nowe API do wielowątkowości. W czasie tej sesji staraliśmy się porównać szybkość działania sekwencyjnego i współbieżnego dla prostego algorytmu sortowania.
Kody do testów dostarczone przez Wolfa wrzuciłem na githuba razem z prezentacją z warsztatu. Większość czasu zajęło nam napisanie algorytmu sortowania, tak że na zabawę API do współbieżności zostało już niewiele czasu.
Venkat Subramaniam - Integrating JVM Languages
Wśród punktów integracji języków można wyróżnić:
- bazę danych
- serwisy (przez JSON, XML)
- język, czyli w kodzie jednego języka używamy konstrukcji wywołujących kod z innego języka.
Podział jęz. ze względu na liczbe. DSL - doman-specific languages
Poniżej podaje przykładowe api użyte na prezentacji przy integracji języków. W wolnej chwili spróbuje umieścic jakieś przykłady użycia w kodzie.
Java code:
class JavaClass{
public void people(Collection people){
// do sth
}
public void yield(){
// do sth
}
}
Scala -> Java:
val inst = new JavaClass
val names = List("Jack", "Jill")
inst.people(names)
inst.'yield'() // escape keywords
Groovy -> Java
def inst = new JavaClass()
def names = ["Jack","Jill"]
inst.people(names) // Groovy uzywa kolekcji Java, bez problemu konwertuje
inst.def() // Groovy rozpoznaje kontekst wiec wie ze to nie slowo kluczowe
JRuby -> Java
require 'java'
java_import 'JavaClass'
inst = JavaClass.new
names = %w{Jack Jill}
inst.people(names) // JRuby konwertuje bez problemu bo uzywa kolekcji Java
Ken Sipe - MongoDB: Scaling Web Application
Na youtube jest dość śmieszny filmik przedstawiający dyskusje za i przeciw tradycyjnym bazom SQL vs. NO SQL.
MongoDB to baza dokumentowa, struktura dokumentów w postaci JSON, umożliwia auto-sharding i map/reduce. Analogią do kolumny w tradycyjnych bazach SQL jest kolekcja, a analogią wiersza - dokument.
CRUD:
C: db.user.insert({"username":"ken"})
jeśli kolekcja 'user' nie istniała wcześniej, zostanie teraz stworzona
R: user = db.user.findOne({"username":"ken"})
U: user.city = "St. Louis"
jeśli 'city' nie istniało wcześniej zostanie stworzone w kolekcji 'user'
db.user.save(user)
D: db.user.remove({"username":"ken"})
dodanie indexu i sprawdzenie czy istnieje:
db.user.ensureIndex("username":1)
db.user.hasIndexKeys()
Użyteczne polecenia MongoDB:
show dbs
use <database name>
db.user.save(user)
db.user.findOne(...)
printjson(user)
db.user.find(...).explain
db.user.ensureIndex({"username" : 1})
db.shapes.ensureIndex({radius:1},{sparse:true})
Robert C. Martin - The Three Laws of Test Driven Development
Uncle Bob zaprezentował oczywiste rzeczy. Przytocze killka:
- produktywnośc obniża sie z czasem jak kod staje się bardziej chaotyczny
- powinniśmy postawić sobie zadanie, że za każdym razem gdy czeckoutujemy kod z repo będziemy checkinować kod lepszej jakości niż wycheckoutowany.
- zalety TDD w pisaniu czystego kodu: mamy formalną dokumentację, kod jest niezależny od siebie (decoupling), refaktorujemy kod, prawie nie musimy debugować.
- dlaczego nie porzadkujemy swojego kodu? Bo się obawiamy że zepsujemy coś działającego. Dlaczego sie boimy? Bo nie mamy testów, żeby szybko zweryfikować, czy coś popsuliśmy.
- panuje mit, że piszac testy piszemy wszystko 2 razy. Kontrargument? Księgowi rachunki wg. zasady dwustronnego zapisu prowadzą 2 rachunki aby na koniec porównać sumę z obydwu, dlaczego programiści nie mieliby tak samo robić z testami?
Strona do zapoznania się http://cleancodeproject.com
Praktyki jak pisać lepszy kod:
1. Mniej znaczy więcej (mniejszy codebase, mniej templatów, reużywalny kod)
2. Krótkie metody
3. Kompozycja zamiast dziedziczenia
4. Decoupling (TDD pomaga przy tym)
5. Ciągła integracja (CI)
6. Ciągły deployment (CD), nie czekaj na perfekcyjny kod, dostarczaj małymi partiami
7. Review kodu (narzędzia jak Crucible)
8. Metryki kodu (Cobertura, Emma, PMD, FindBugs), pokazuj ludziom diagramy z tych metryk, nie liczby, ludzie lubią obrazki
9. Minimalisuj przypadkowe skomplikowanie
10. Potrzeba zamiast ceremoniału i dobrych praktyk, np użycie bardziej eksppresyjnych języków kosztem statycznego typowania.
11. Nie pracujemy sami, ale z ludzmi - jak przekazujemy więdzę i wartości w zespole? Np. opracowanie podręcznika developera, w którym specyfikujemy ja postawić środowisko developerskie, jak szybko zacząć z kodem.
Książka godna polecenia: "Working Effectively with Legacy Code", Michael Feathers
Jurgen jest autorem książki "Management 3.0" oraz blogu noop.nl
Przedstawił kilka inspirujących pomysłów i linków jak tworzyć innowacyjne rzeczy, mogące zmienić świat.
Książki:
Techniki pomagające w zmianie:
1. Metoda Mojito - użyj dostępnych ale nudnch składników, które razem stworzą interesujący system
2. Model zmian ADKAR
3. Teoria Dyfuzji Innowacji wyjaśniająca w jaki sposób nowe idee i technologie rozprzestrzeniają sie w społeczności.
4. Zastanów sie nad środowiskiem jakie chcesz zmienić, pokoje, biuro, np zacznij umieszać ciekawe plakaty, wlepki stymulujące myślenie.
Tą i inne prezentacje Jurgena można oglądąć na stonie http://www.slideshare.net/jurgenappelo
Ostania już prezentacja, która właściwie nie wniosła nic nowego a jedynie udowodniła po raz kolejny, że Uncle Bob jest doskonałym showmanem. Po raz kolejny rozprawiał nad tym, jak tworzyć czysty kod stosując TDD (gdyby to było takie proste w realnych projektach) i jak być profesjonalistą, który potrafi sprzeciwić się nieosiągalnym terminom w myśl dostarczania rozwiązań wysokiej jakości. Jeśli nie potrafimy zmienić mentalności ludzi w naszej pracy powinniśmy albo zmienić organizację (w sensie organizaje pracy), albo zmienić organizację ( w sensie iść do innej firmy :)).
Z dyskusji z Wujkiem po prezentacji dowiedziałem się, że aby zacząć realnie stosować TDD ponoć wystarczy popracować w ten sposób ok. tygodnia (hm.. czyżby?).
Tym sposobem dobiegł końca 3-dniowy cykl wykładów i warsztatów. Kolejny raz Grzesiek Duda wraz koorganizatorami dowiódł, że warto było wybrać się na 33rd Degree, chociaż może niektóre wykłady były bardziej popisówką aktorską prowadzących, ale nawet to pozwoliło zobaczyć jak można prowadzić prezentację trzymającą w napięciu i bawiącą publikę zamiast niejednokrotnie usypiających wykładów (przeciętne wykłady na studiach).
Duży plus i podziękowania za ogarnięcie logistyczne całości. Można było skorzystać z płatnych co prawda, ale za to niedaleko zlokalizowanych obiadów, a przez całe dni dostępne były darmowe przegryzaki przed salami konferencyjnymi. Tym razem, w porównaniu z ubiegłoroczną konferencją, zdaje się że nawet kolejki przed toaletami były krótsze.
Jak w ubiegłym roku zagościł również kiosk z ksiązkami O'Reilly, które można było kupic za 60% ceny.
Ogólnie na duży plus.
Inne relacje z tego wydarzenia:
http://art-of-software.blogspot.com/2012/03/prezentacje-na-33rd-degree.html
http://jlaskowski.blogspot.com/2012/03/po-33rd-degree-2012-w-krakowie-nie.html
Subskrybuj:
Posty (Atom)