niedziela, 28 września 2014

Warsjawa 2014

Ogromne podziękowania dla organizatorów konferencji Warsjawa która odbyła się wczoraj i merytorycznie przerosła moje oczekiwania. Nie spodziewałem się aż takiego poziomu na darmowej konferencji. Mógłbym tez nieśmiało stwierdzić ze podobało mi się bardziej niż na 33rdDegree w Krakowie.

Ponadto organizacyjnie wypadło to super. Warsztaty odbywały się w gmachu Wydziału Matematyki Informatyki i Mechaniku Uniwersytety Warszawskiego, jak co roku. Kazdy warsztat w oddzielnej sali, która miała swojego opiekuna. W przerwach były serwowane kanapki z ciężarówek przed gmachem. Mozna tez było korzystać z bufetu.

Na końcu odbyło się uroczyste zamkniecie, podziękowanie i rozliczenie się z wydanych pieniędzy. O ile mnie pamięć nie myli to konferencja kosztowała ponad 60 tys PLN. Końcowa prezentacja powinna się niebawem ukazać w sieci.

"100% Workshop" to formula, która przyświecała konferencji i rzeczywiście, nawet prezentacje miękkie, takie jak "Zdrowy kręgosłup w pracy" zawierały ćwiczenia praktyczne. Ja sam brałem udział właśnie w prezentacji o kręgosłupie i w 2ch warsztatach Venkata Subramaniana (przykłady można zobaczyć tu):
- Programming concurrency
- Creating DSL using Groovy

oraz hackatonie Marcina Grzejszczaka o mikroserwisach na którym dał nam tony ciekawych materiałów i pokazał ze mikroserwisy to nie tylko aplikacje z wbudowanym serwerem odpalane z linii komend ale cala struktura komunikujących się aplikacji. Koncepcja dobrze została przedstawiona na tej prezentacji.

Był to też mój osobisty debiut z warsztatem "Quick prototyping in Grails" z którego generalnie jestem zadowolony, chociaż w drugiej połowie z braku czasu musiałem improwizować i trochę się zamotałem :) Następnym razem powinno być już lepiej.

Konferencja godna polecenia i za rok na pewno będę się wybierał.

niedziela, 22 czerwca 2014

XI Bieg Rzeznika (2014)

O Biegu Rzeźnika już kiedyś pisałem tutaj.
Po 3 latach przerwy lekkomyślnie dałem się namówić na powtórny odział w tym jakże godnym przedsięwzięciu :)
Trasa ta sama, tylko uczestników ponad połowę więcej - ponad 600 par.
Pogoda w porównaniu z pierwszym razem bez wątpienia lepsza. Mozna powiedzieć ze w ogolę nie padało, nie licząc mżawki na początkowym wybiegu z Komańczy.
Trasa była sucha i.. nie powiem ze łatwa. Wymięknąłem na podbiegach. Oto nauczka na przyszłość - trenować, trenować, trenować.. podbiegi. O ile zbiegi i proste odcinki w miarę, to na podejściach wyprzedziłby mnie niejeden 90-latek z noga w gipsie.
Właściwie trudno nazwać to wydarzenie biegiem, jeśli już to marszo-biegiem. Do Cisnej jeszcze trochę biegaliśmy, potem już brakowało sil, zwłaszcza mnie bo mój partner spokojnie machnąłby jeszcze odcinek 'hardcore' (dodatkowe 20km).
Ostatni odcinek od Berechów do mety to była rzeźnia, gdyby mój partner nie wziął mnie na hol to chyba jeszcze do tej pory podchodziłbym pod Połoninę Caryńską. Właściwie nie miałem już siły podnosić nóg i ledwo łapałem oddech, co chwila musiałem się zatrzymywać i odpoczywać kilka minut.
Jakos ostatecznie doczołgałem się do mety w limicie czasowym po ponad 16h od startu.
Oficjalne wyniki biegu znajdują się tutaj.
Nie pamiętam już kiedy (chyba nigdy) wypiłem takie ilości izotonika co tego dnia i kiedy zjadłem tyle batonów i zeli energetycznych. Od Smereka nie mogłem już tego przełykać, ale to było jedyne źródło energii wiec trzeba było się zmusić żeby nie paść.
Poniżej urocza mapka przewyższeń na trasie:




Tak wyglądaliśmy przed biegiem:


.. a tak po:



Na mecie każdy otrzymał pamiątkowy medal oraz browarka, takiego oto:



Ogólnie polecam każdemu kto lubi pot, ból i zmierzenie się z granicami własnej wytrzymałości. Nie przypuszczałem ze dam rade przebyć 80km. To dowód na to, ze ludzki organizm jest wstanie znieść dużo więcej niż mu rozum podpowiada.

Szacunek dla organizatorów za organizacje, logistykę, transport i za wyżywienie i napoje na przepakach, dla GOPR za bycie w pogotowiu. Zorganizowanie takiej imprezy w trudnych warunkach dla ponad 1000 osób to nie lada wyzwanie.

Może jeszcze kiedyś strzeli mi do łba żeby spróbować po raz kolejny. Teraz już wiem jak wygląda trasa.

Tymczasem nasza galeria fotek do obejrzenia tutaj.

Wiecej relacji:
https://www.facebook.com/BiegRzeznika
http://bieganie.pl/?show=1&cat=224&id=6698
http://bieganie.pl/?show=1&cat=137&id=6730
http://justdomi.wordpress.com/2014/06/30/iii-rzezniczek-czyli-podroz-tam-i-z-powrotem/
http://wegankabiega.pl/bieg-rzeznika-cz-1/
https://www.facebook.com/piotr.wojtanowski.7/media_set?set=a.659786397443372.1073741826.100002360537800&type=1
https://www.flickr.com/photos/mcyellen/sets/72157645319780512/
http://www.festiwalbiegowy.pl/album/11-bieg-rzeznika-komancza-ustrzyki-gorne-20062014#.U8Q6kt8cizd
http://www.beskid.tv/film/644
http://www.vegeslonik.pl/rzeznik-na-sojowo/
http://www.maratonypolskie.pl/mp_index.php?dzial=2&action=44&code=40527
http://akademiabiegania.pl/xi-bieg-rzeznika/
http://biegamzpsem.blogspot.com/2014/06/rzeznik-w-80-km-do-spenienia-marzen.html?spref=fb
http://www.awf.gda.pl/index.php?id=24&items=9957
http://www.portalgorski.pl/nowosci/biegi-gorskie/3242-xi-bieg-rzeznika-interrisk-dla-aktywnych-podsumowanie
http://www.magazynbieganie.pl/ja-rzezniczka/
http://www.zyciejestpiekne.eu/bieg_rzeznika/
http://jest-ekskluzywnie.blogspot.com/2014/06/moj-bieg-rzeznika-2014-cz1.html
http://www.200yrs.pl/#!biegrzeznikarelacja/c1hrh
http://rossbieg.przegladsportowy.pl/2014/06/23/slyszalem-w-sobie-ogien/
http://runeat.pl/rzezniczek-czyli-luz-w-d/
https://plus.google.com/u/0/photos/118046623152202969699/albums/6028881124206004385

https://www.youtube.com/watch?v=dT7RRlZKsyM
https://www.youtube.com/watch?v=RjNgj8ghR8Y
https://www.youtube.com/watch?v=FMPPMw_8bY0
https://www.youtube.com/watch?v=ZZMOLkFFwRI
https://www.youtube.com/watch?v=5cRo3GFg07I




niedziela, 8 czerwca 2014

Devoxx4kids 2014

 7go czerwca 2014 odbyły się w Warszawie warsztaty dla dzieci w wieku 6-12 lat pod nazwa Devoxx4kids
Brałem w nich udział jako wolontariusz, któremu przyszło opiekować się grupa 12 dzieciaków 8+ , czyli w wieku 8-10 lat.
Oto jak wyglądał plan zajęć:


Czas \ Grupa
6+8+10+12+
Grupa / Czas
6+ A6+ B8+ A8+ B10+ A10+ B12+ A12+ B
09:00-09:30Rejestracja
(wejście)
09:00-09:30
09:30-10:00
Wstępniak
(416)
09:30-10:00
* Prezentacja agendy
* Omówienie kwestii bezpieczeństwa i opieki nad dziećmi, odpowiedzialność
* Przypomnienie o regulaminie, konieczności zawieszek, robieniu zdjęć itp.
* Uczestnictwo rodziców w zajęciach
Dariusz Kaczyński, Ewa Waliczek, Michał Lewandowski, Tomasz Kucharski
10:00-10:50
Dr Techniko
Agnieszka Lipska
(416)
LightBot
Tomasz Kucharski
(401)
Lego® WeDo
RoboCamp
(404)
Code.org
Damian Leszczyński
(300)
CoLoBot
Raptory Parkowski
(301)
Minecraft
Michał Bareja
(305)
Sonic-Pi
Michał Lewandowski
(304)
Lego® Mindstorms®
Robocamp
(406)
10:00-10:50
11:00-11:5011:00-11:50
11:50-12:30
Przerwa obiadowa
Przerwa na kanapkę11:50-12:10
Lego® Mindstorms®
Robocamp
(406)
CoLoBot
Raptory Parkowski
(301)
Lego® Mindstorms®
Robomaniacs
(400)
Arduino
Michał Kędyś
(401)
12:10-13:00
12:30-13:20
LightBot
Konrad Hoszowski
(305)
Dr Techniko
Agnieszka Lipska
(416)
Scratch
Ewa Waliczek
(300)
Lego® WeDo
Robocamp
(404)
13:10-14:00
13:30-14:20
Przerwa obiadowa
14:00-14:40
14:20-14:40Przerwa na kanapkę
14:40-15:30
Lego® WeDo
Robomaniacs
(400)
Lego® WeDo
RoboCamp
(404)
Code.org
Damian Leszczyński
(301)
Scratch
Ewa Waliczek
(300)
Minecraft
Michał Bareja
(305)
Lego® Mindstorms®
Robocamp
(406)
Arduino
Michał Kędyś
(401)
Sonic-Pi
Michał Lewandowski
(304)
14:40-15:30
15:40-16:3015:40-16:30
16:30-16:50
Podsumowanko
(416)
16:30-16:50
* Czego się nauczyliśmy?
* Wspólne zdjęcie
Dariusz Kaczyński, Ewa Waliczek, Michał Lewandowski, Tomasz Kucharski

Zajęcia z lego poprowadziła zewnętrzna firma RoboCamp. Przedmiotem było wybudowanie z klocków, według instrukcji,  lego helikoptera ze śmigłami napędzanymi silnikiem zasilanym z USB.

Zajęcia ze Scratch miały za zadanie zaprogramowania duszka, który miał poruszać się w labiryncie nie przechodząc przez jego ściany.

Ostatnie zajęcia mojej grupy to Code.org - podobne do programowania w Scratch, tyle ze przedmiotem było przejście przez dwadzieścia kilka poziomów. Każdy poziom polegał na takim zaprogramowaniu ruchów figury, żeby doprowadzić ją do pożądanego celu. Gra jest dostępna online, każdy może sam spróbować: http://learn.code.org/hoc/1

Dzieciaki okazały się bardzo rozgarnięte a niektóre odpowiedzi na pytania wręcz zaskakujące :)
Dzielnie przetrwały cały dzień, chociaż na ostatnim warsztacie widać już było przemęczenie i chęć wyjścia do domu. W cale się nie dziwie bo za oknem pogoda zachęcała do zajęć na świeżym powietrzu a nie siedzenia w gorących dusznych salach szkolnych.

Sam również sprawdziłem się w roli opiekuna i nie zostałem zjedzony żywcem przez zgraje rozbestwionych dzieciaków, tak jak się na początku obawiałem. Było wręcz przeciwnie, dzieciaki okazały się bardzo przyjazne i grzeczne :) i to nie kwestia tego ze się mnie bały, bo były bardzo kontaktowe. To niecodzienna odmiana dla programisty nerda, który większość cześć życia spędza i porozumiewa się z komputerem :)

Oto kilka zdjęć zrobionych przeze mnie










I jeszcze wiecej fotek:

https://picasaweb.google.com/114911144671165469374/Devoxx4KidsPL

czwartek, 29 maja 2014

Atmosphere Conference, 2014

19 i 20 maja miała miejsce w Warszawie druga edycja konferencji Atmosphere, przeznaczona dla DevOps-ów, czyli tych, których praca zawiera dwa światy: Development i Operations.
Ponoć czasy kiedy człowiek z działu Operations nigdy nie tykał się tego co  Development i odwrotnie, dawno już minęły i w obliczu szybko zmieniających się technologii i konkurencji na rynku rzadko kiedy odpowiedzialności są tak podzielone.

Konferencja moim zdaniem ciekawa, chociaż nie wiem czy warta wpisowego, które w wersji 'last-minute' sięgnęło astronomicznej kwoty 1000 PLN ! Ja byłem tym szczęściarzem, któremu Michał Bartyzel udostępnił wejściówkę za darmo.
Faktem jest że organizacja konferencji była na bardzo wysokim poziomie.
Tak wyglądały przygotowania:

Super miejsce z dobrze przystosowanym audio/wideo (oczywista sprawa, gdyż było to kino), no i ciekawe tematy (2 ścieżki). Prawdopodobnie niebawem ukażą się nagrania na youtube. Na razie są tylko z poprzedniej edycji tutaj.
Zanim się ukażą postaram się kilka z nich streścić:


Dzien 1

PHIL DIBOWITZScaling systems configuration at Facebook: the paradigms, design, and software behind managing massive numbers of systems with open source and small teams

Troche o prelegencie:


Przedstawił następujące problemy w swoim teamie:
- support wielu konfiguracji z rożnych projektów
- ok. 100 000 serwerów do utrzymania
- brak centralnego miejsca przetrzymywania konfiguracji klastra
- jedna domyślna konfiguracja nadpisywana per projekt
- wiele niewielkich zespołów, każdy wprowadza swoje zmiany
- duża nadmiarowość: cześć wspólna się nie zmienia i zaciemnia wgląd w to co konkretnie się zmieniło w projekcie.

Celem było dojście do stanu gdy 4 osoby mogą utrzymać 100 000 serwerów.
Brali pod uwagę rożne narzędzia: Puppet, Chef, Spine.
W końcu wybrali Chef. Powodem była jego łatwa rozszerzalność i adaptacja do workflowu.
Osiągnęli:
- usuniecie wielu zduplikowanych plików konfiguracyjnych
- usuniecie nieużywanych settings
- stworzyli domyślną konfiguracje nadpisywaną potem w Ruby specyficznymi ustawieniami

Architektura wygląda tak, ąe jest serwer tzw. Service of Reference (SOR), który trzyma rekord węzłów w klastrze. Serwery Chef są bezstanowe, nic nie wiedza o istniejących węzłach.
Na węzłach jest zainstalowany Ohai plugin i podłączony do konkretnego SOR.
Handlery do raportów monitorują instalacje. Konfiguracje są trzymane w SVN.
Przykład:

Stworzyli tez zestaw własnych narzędzi dostępnych na githubie.
Ciekawie zapowiada się jeden z nich: test-tester - ponoć umożliwia testowanie konfiguracji bezpośrednio na serwerach produkcyjnych nie powodując dla nich zagrożenia w przypadku błędów (do końca nie zrozumiałem jak to działa).

DANIEL TOROKOur Continuous Delivery Pipeline

Daniel pracuje w Prezi
Przedstawił w jaki sposób ewoluował ich system Continuous Delivery.
Oto moje niezdarne schematy w poszczególnych fazach :) byłyby lepsze, gdyby nie jakość zdjęć z telefonu nie nadających się do niczego.

1. Każdy node monitoruje wersje uploadowaną na Amazon S3 z zainstalowaną u siebie i jeśli się zmieniła do ściąga i instaluje

Minusy: trudność w monitorowaniu procesu i utrzymaniu: każdy node konfigurowany ręcznie.

2. Dodano Zookeeper do zarządzania konfiguracjami i mission control do monitorowania


3. Lepszy monitoring Inciga (każda aplikacja ma swój health endpoint, który jest co jakiś czas sprawdzany) i parsowanie logów w Logster. Następnie statystyki są przedstawiane real-time na diagramach z użyciem Graphite i służą do analizy instalacji a także w przypadku gdy coś się wywali na produkcji.



MAXIMILIANO FIRTMANThe mobile web challenges

Maximiliano jest autorem bloga http://www.mobilexweb.com/ na oraz prowadzi ranking kompatybilności przeglądarek http://mobilehtml5.org/

Developmnet aplikacji mobilnych to prawdziwa dżungla, biorąc pod uwagę różne typy aplikacji:
- natywne
- webowe
- hybrydowe
oraz mnogość urządzeń


W przypadku aplikacji webowych mamy też mnogość przeglądarek, których popularność różni się od regionu geograficznego. Z ciekawostek - rejon Indie, Pakistan, Bangladesz używa najczęściej (98%?) przeglądarki UC Browser, o której słyszałem pierwszy raz.

Nie ma jednej słusznej zasady tworzenia aplikacji mobilnych, wszystko zależy od zastosowania i docelowych użytkowników. Zawsze najważniejsza jest percepcja użytkownika, np czy użytkownikowi wydaje się że aplikacja działa wolno, czy nie. Niektóre ograniczenia urządzeń mobilnych, jak np. słabą przepustowość łącza, można zminimalizować:
- ładując zasoby, np grafikę w tle
- pre-renderując HTML po stronie serwera w zależności od rodzaju urządzenia, języka, wielkości ekranu itd.
Inne ważne zasady:
- nie frustruj użytkownika (np przy logowaniu z użyciem sieci społecznościowych nie wymagaj dostępu do wszystkich danych użytkownika jeśli tego nie potrzebujesz)
- wydajność aplikacji jako główny cel (tworzenie stron tzw. responsywnych, które dobrze renderują się na urządzeniach mobilnych ale przy okazji zasysają ogromne ilości CSS i JS to nie zawsze najlepszy pomysł, szczególnie gdy docelowa grupa prawie nigdy nie używa desktopów).

Jeśli chodzi o narzędzia i testowanie też nie jest łatwo. W zależności od platformy mamy do dyspozycji symulatory, emulatory lub urządzenie fizyczne.
Są tez strony gdzie możemy przetestować jak nasza aplikacja zachowa się na różnych urządzeniach, np.
http://developer.samsung.com/remotetestlab

Kilka wskazówek jak być przygotowanym na przyszłość i to w jakim kierunku rozwija się mobile dev.:
- technologie "push" - push z serwera na klienta
- detekcja dostępnych funkcji urządzenia (GPS, akcelerometr, itd.) i dostosowanie zachowania aplikacji do nich
- synchronizacja - śmieszny przykład jaki dał Maximiliano to gdy w środku nocy w pokoju, w którym trzyma kilkanaście różnych urządzeń mobilnych dostaje e-maila i każde z tych urządzeń dostaje "push" - nagle jego pokój zamienia się w wesołe miasteczko, wszystko gra i świeci :D
Użytkownik powinien mieć możliwość wyboru co chce na danym urządzeniu synchronizować, np gdy tableta używa do czytania prasy, książek, a telefonu do sprawdzania poczty.

Inne metodologie o których nie słyszałem wcześniej:
- RESS (Responsive Design with Server-Side components) to sposób tworzenia aplikacji klient-serwer, w którym pomiędzy klienta i serwer daje się jeszcze jedną warstwę pośrednią służącą poprawę wydajności na kliencie (np dostosowanie rozmiaru grafik do ekranu urządzenia, dostosowanie HTML, CSS, JS)


ADAM MICHALCZYKEverybody lies

Adam z Allegro zastanawiał się dlaczego ludzie kłamią, niezależnie od swojej roli w projekcie: czy to Developerzy, Product Ownerzy, Operations..
Powody bywają różne, jak:
- wygodnictwo
- wzajemne niezrozumienie
- opieranie się na opiniach, nie faktach
- strach przed konsekwencjami

Adam jest propagatorem kultury pracy, w której nie boimy się popełnić błędy o ile są one bezpieczne ("safe to fail" a nie "failsafe"), tzn istnieje cały mechanizm zabezpieczający przed tym by błędy nie były kosztowne i wychwycone wcześnie (jak np continuous integration  z testami aplikacji). Powołuje się na książkę Joy Inc.
Kultura pracy nie powinna piętnować popełnianych błędów, wręcz przeciwnie - zachęcać do eksperymentowania i otwartości.

SZYMON PRZYBYLSKIOptimising and Automating your Front End Workflow

Jakich narzędzi powinien dziś używać front-end developer by ułatwić sobie życie?
Apki JavaScript-owe bardzo ewoluowały w przeciągu ostatnich kilkunastu lat. To już nie tylko język który upycha się gdzieś w stronę JSP ale pozwalający tworzyć kompletne aplikacje po stronie klienta i serwera. Narzędzia godne poznania to:
- npm
- bower
- grunt
- gulp
- walidatory: JSLint, JSHint, ESLint
- frameworki do testowania: Jasmine, Mocha, QUnit

KRZYSZTOF DEBSKILet's build a solid base for a scale.

Krzysiek pracuje w Allegro, które obchodzi w tym roku 15 rocznicę powstania. Od czasu, gdy powstało przeszło sporą ewolucję technologiczną od homogenicznego sytemu do skalowalnego w chmurze z 15 mln. użytkowników.
Obecnie architektura opiera się na mikro-serwisach komunikujących się ze sobą rożnymi API (REST, SOAP, CORBA..) Modernizacja trwa. W grę wchodzą takie technologie jak:
Zookeeper - jako rejestr serwisów
Swagger - biblioteka do generacji dokumentacji dla serwisów REST, dostepne także Swager UI, całkiem przyjemna strona HTML do wizualizacji dokumentacji.

Do tworzenia REST API używany jest Jersey, wersjonowanie REST API  za pomocą HTTP nagłówka Accept.

Konfiguracja serwisu kilkustopniowa:
- Zookeeper
- zmienne środowiskowe
- argumenty linii komend

Początkowo serwisy były bootstrapowane w zewnętrznym Jetty ale działało to zbyt wolno, stąd przejście na embedded Jetty a potem na embedded Undertow. Dzięki temu każdy serwis jest samodzielny, nie potrzeba go deployować na serwerze.

Monitoring z użyciem:
- Logstash
- Kibana
- NxLog
- Graphite



Obecnie trwają eksperymenty z użyciem Dockera.

MaTeusz HarasymczukRE:SPONSIBILITY.

Ten wykład był poprowadzony w zastępstwie za Andy Hawkinsa.
Mateusz zastanawiał się nad tym po co skupiać się na poprawie jakości istniejących rozwiązań skoro klient za to nie płaci tylko za nowe funkcjonalności. Otóż warto, bo to właśnie utrzymanie kosztuje najwięcej.


Przy przejrzystym i prostym kodzie z małą liczbą zależności utrzymanie to przyjemność a jakiekolwiek zmiany są szybkie do implementacji.

Każdy powinien być zawsze odpowiedzialny za swój kod, nawet po tym gdy kod już trafi na produkcję. 


Wyobraź sobie że Twój kod jest użyty do obsługi przyrządów w samolocie, którym właśnie poleci Twoje dziecko, czy wpuściłbyś je spokojnie na pokład?

MACIEJ LASYKScaling and securing node.js apps

 Źródło informacji o security w node.js: https://nodesecurity.io/
Aplikacje node.js działają blisko systemu operacyjnego przez co narażone na wiele błędów związanych z bezpieczeństwem.
Co więcej, mnogość bibliotek pisanych często bez nadzoru zewnętrznej instytucji pozwala przecieknąć do naszej aplikacji potencjalnie niebezpiecznym kodom, dlatego zewnętrzne kody co do których nie jesteśmy pewni powinny być przeskanowane pod kątem użycia niebezpiecznych konstrukcji takich jak:
- eval(code)
- setInterval(code, ..)
- setTimeout(code,..)
- str = new Function(code)
- global namespace polution - gdy wszystkie zmienne w kodzie serwerowym są wspólne dla wszystkich klientów, należy o tym pamiętać, że w aplikacjach node.js wszyscy klienci używają jednej metody serwerowej, która działa w jednym wątku, dlatego też współdzielą jej zmienne.

Przykładowy błąd:
Gdy jeden klient zostaje zautentykowany, zapisujemy w globalnej zmiennej, że ma dostęp do zasobów.
Następnie serwer obsługuje request innego klienta, który jeszcze się nie logował ale ponieważ stan został zmieniony przez poprzedniego klienta, ten drugi może bezprawnie dostać się do zasobów chronionych.

- niełapane wyjątki powodujące wywalenie się głównej metody serwera i tym samym stopujące serwer (teraz już po konferencji wertując sieć natknąłem się na taką stronkę o wyjątkach w node.js)

Metody prewencji:
- strict mode ("use strict;"), również dla dołączanych bibliotek - dzięki temu parser wychwyci wszystkie metody, w których przekazywane mogą być komendy systemowe w stringu.
- JSHint (node-jshint), JSLint (node-jslint
- statyczne analizatory kodu
- retire.js
- użycie gotowych modułów do autentykacji zamiast pisać ręcznie i narażać się na błedy, np passportjs
- express-domain-middleware
- sandboxing - proces nodejs nie jest uruchamiany bezpośrednio w systemie operacyjnym ale w chronionym środowisku, które nie ma dostępu np do prawdziwego systemu plików, czyli wirtualizacja, np: SELinux Sandbox


Dzien 2

MICHAL CZAPRACKIScalability and Websockets: Creating a Websocket CDN with DIASP.

Zalety websocket:
- ciągła komunikacja
- komunikacja dwukierunkowa
- zabiera małą część łącza
- wiele bibliotek implementujących
Wady websocket:
- wiele jednocześnie otwartych połączeń
- trudne do implementacji w standardowych frameworkach
- niekompatybilne z większością proxy (np Varnish, Squid)
- brak warstwy cache

Michał brał udział w tworzeniu rozwiązania opartego na websocketach dla gazera.pl web i sport.pl web (obie około 2mln ściągnięć na urządzeniach mobilnych). Z powodu ograniczeń standardowych bibliotek websocket musieli napisać własne rozwiązanie które pozwalało na cachowanie, tzw DIASP (Diasp Is a Socket Proxy)
Testy pokazały że jest ono w stanie obsłużyć 20 000 jednoczesnych połączeń na maszynie z 300MB RAM
W dniu prezentacji rozwiązanie zostało OpenSource-owane na
https://github.com/AgoraTech/diasp

MACIEJ KUZNIARSwitching from monolithic approach to modular cloud computing, within the context of providing high availability application

Maciej opowiedział z grubsza o serwisach dostarczanych przez Octawave, czyli generalnie wszystko o czym można poczytać na https://www.oktawave.com/pl/instancje-chmury.html

DARIUSZ ELIASZCentralized log management based on Logstash and Kibana - case study.

I znów pojawiają się znajome nazwy (na razie jedynie nazwy bo nie próbowałem tego jeszcze).
Darek opowiedział o swojej drodze do stworzenia systemu zarządzania logami i monitoringu aplikacji.

Pierwszy etap to wybór właściwego protokołu komunikacji. Rozważane opcje:
- RFC 3164 - limitowany do 1KB, stały format, niezbyt elastyczny
- JSON - lekki, elastyczny, bez limitu co do formatu, duże wsparcie istniejących bibliotek i narzędzi

Architektura zbierania logów:
Sender:
wiele interfejsów wejściowych (ftp, tcp, udp socket), wiele rodzajów parserów (BSD log, JSON)
jak najwięcej się da przetwarzania logów robi Sender zanim pości je dalej.
W pierwszej wersji użyty był NxLog, potem zastąpiony syslog-ng

Log Router:
w pierwszej wersji Logstash + Redis, potem tylko Redis.

Log Collector:
zbiera, parsuje, zapisuje logi, dodaje dodatkowe atrybuty jak geolokalizacje, zapisuje do elasticsearch na podstawie IP z którego pochodzą logi

Full text search engine:
elasticsearch, logi zapisywane w formacie JSON, indeksy replikowane i shardowane, partycjonowane względem czasu, usuwanie starych wpisów na podstawie daty
konfiguracja - Marvel plugin

GUI:
Kibana 3


ANDRZEJ GRZESIKGo, go, go - the one language to try in 2014. (or: "write only an eight of the code" ;-))

GO to język ułatwiający programowanie aplikacji wielowątkowych, coś jak mix C++ z Ruby, nie ma zależności w runtime od bibliotek systemu (biblioteki łączone statycznie). Ponoć Andrzej brał udział w przepisaniu apki Springowej na GO, dzięki czemu zredukował ilość linii kodu do 1/8 początkowej ilości.
Chciałbym zobaczyć jak wygląda taka apka. Andrzej pokazał proste konstrukcje języka, ciekawe cechy:
- GO narzeka jeśli jakieś importy nie są używane, nie pozwala skompilować kodu
- brak wyjątków, zamiast tego są kody błędu
- formater kodu wbudowany w interpreter ("go fmt")
Miała być to zachęta do spróbowania języka samemu.

TOMASZ BARANSKILockless programming

Wstęp do tego jak programować współbieżnie nie używając semaforów, zamiast tego mechanizmów takich jak:
- operacje atomowe (Compar And Swap, Fetch and Add, Add And Fetch)
- memory barriers - wymuszać na kompilatorze, żeby nie optymalizował naszego kodu i nie zmieniał kolejności instrukcji read/write zmiennych (Read Read Barrier, Store Store Barrier) np:
przed kompilacja:
read X
barrier
read Y

po kompilacji:
read X
read Y

Rozwiązania dostępne w Javie:
AtomicInteger
AtomicReference
AtomicStampedReference
AtomicIntegerArray

Przyznaje bez bicia ze trochę odpłynąłem na tym wykładzie, nie wszystko było dla mnie jasne i dawno nie wchodziłem w tak niskopoziomowe programowanie, nie miałem tez takiej potrzeby projektowej.

ADAM DUDCZAKJUnit: beyond the basics

Wiele pożytecznych sztuczek w pisaniu testów JUnit
https://code.google.com/p/junitparams/
- org.junit.experimential.theories
- randomized unit testing 
- @Rule - reusable @Before/@After
- mocking external services:
co.freeside.betamax.*
WireMock
- JUnit Benchmarks
- expected exception rule
- nowe "assertions": Hamcrest, Fest / AssertJ
- organizowanie testow w @Suite, w kolejnych wersjach JUnit zamienione na @Category

Prezentacja dostępna na: https://bitbucket.org/maneo/junit-presentation

JAMIE WINSORChef Development and Release Patterns for Software Engineers

Jamie na GitHubie: https://github.com/reset
Termin "deploy window" to jasny wyznacznik tego, że system buildów nie działa poprawnie.
Deploy powinien móć być robiony bez obaw w każdej chwili poprzez kliknięcie jednego przycisku :)
Zasady powinny być takie:
- automatyzuj i testuj co tylko się da
- wersjonuj, pakuj i wypuszczaj wszystko (kod, DB)
- wbuduj deployment w build process
- buduj nawet serwer buildow (z użyciem np Valgrant)

Toolbox:
- Elixir - jezyk na bazie Erlanga
- Chef Deployment Kit
- Berkshelf
- KitchenCI

Na konferencji można było tez spotkać ludzi z Octawave, porozmawiać o ich serwisach w chmurze oraz dowiedzieć się jak wygląda rekrutacja w Allegro (głównego sponsora konferencji).
Drugiego dnia między prezentacjami można było też pooglądać w salach kinowych wywiadów z prelegentami -w sumie ciekawa opcja, nie spotkałem się z czymś takim na innych konferencjach.

Mam nadzieje ze niczego nie przekłamałem, a jeśli tak to proszę mnie poprawić :)





niedziela, 18 maja 2014

Robothon, Lodz 2014

17 maja 2014 odbył się w Łodzi Robothon, czyli warsztaty, na których złożyliśmy a następnie oprogramowaliśmy robota z wykorzystaniem Arduino Uno.
Wydarzenie zostało zorganizowane przez firmę Cybercom.


 

Było to pierwsze wydarzenie tego typu w jakim miałem przyjemność uczestniczyć, wyjątkowe pod tym względem, ze na ogół w pracy programisty (software developera) efekty pracy nie są tak namacalne jak przy tworzeniu maszyny, która porusza się zgodnie z napisanym kodem (a przynajmniej powinna :)).
Mieliśmy do czynienia z silnikami, czujnikami, diodami, czyli elementami elektronicznymi, które dla każdego adepta elektroniki są banalne w obejściu, ale już nie tak oczywiste dla programistów aplikacji serwerowych/webowych.
Platforma Arduino dla osób takich jak ja otwiera nowy, szeroki wachlarz aplikacji, gdzie granicą jest tylko wyobraźnia.
Wiedza uzyskana w czasie Robothonu jest dobrym startem by dalej próbować z Arduino nie tylko w robotyce, ale automatyce domowej, czy tzw wearable electronics.


Ilość komponentów dostępnych na rynku do tworzenia projektów z Arduino jest przeogromna: odbiorniki radiowe, WIFI, bluetooth, moduły Ethernet, wyświetlacze LED i LCD, czujniki temperatury, wilgotności, sterowniki silników itd.

Oto kilka filmów i zdjęć z warsztatów:









Do zobaczenia za rok !!

wtorek, 6 maja 2014

Wings for Life World Run 2014 Poznan

Wings for Life to pierwszy tego typu bieg organizowany w Polsce, w ktorym meta goni biegaczy.

Wpisowe z biegu jest przeznaczone na badania nad leczeniem uszkodzen rdzenia kregowego, czyli mowiac potocznie zlamania kregoslupa.
Aktualny stan wiedzy na ten temat mozna sledzic tutaj.

Wszystkie informacje o biegu, lacznie z przebiegiem trasy, mozna znalesc tutaj

Ukonczylem bieg jako 411 / 1135 osoba w Polsce i 6933 / 34418 na swiecie :D

Oto moj wynik:


oraz pamiatkowy dyplom.

Pozostale wyniki: http://live.wingsforlifeworldrun.com/en/results

Filmy i opisy wydarzenia:

http://live.wingsforlifeworldrun.com/en/videos
https://plus.google.com/u/0/photos/114111822723343060181/albums/6010038577508621633
http://justdomi.wordpress.com/2014/05/05/wings-for-life-czyli-biegniemy-dla-tych-ktorzy-nie-moga/?preview=true&preview_id=1540&preview_nonce=edcba17d85
http://www.tvn24.pl/on-przez-przypadek-ona-z-kontuzja-polscy-triumfatorzy-wings-for-life-world-run,424714,s.html
http://www.tvn24.pl/poznan,43/the-best-of-wings-for-life-w-poznaniu-caly-bieg-w-3-5-minuty,424988.html
http://www.tvn24.pl/raporty/wings-for-life-world-run,829



środa, 23 kwietnia 2014

Lodz Maraton Dbam o Zdrowie 2014



13 kwietnia 2014 odbyl sie w Lodzi Maraton Dbam o Zdrowie, ktory ukonczylo 1638 biegaczy

Drugi w zyciu maraton juz za mna, zyciowka lepsza o ok 5 min.

Miejsce: 1391
Nr startowy: 238
Czas: 04:31:34
Tempo min/km: 06.26
Diff net: +2:20:53
Checkpoints: 1:02:25 / 1492 2:10:24 / 1432 3:10:00 / 1384 3:49:23 / 1369 4:26:28 / 1391

Wszystkie wyniki sa tutaj 

Pogoda dopisala wysmienicie - sloneczko, ale nie za goraco. Przygotowanie zdawalo mi sie gorsze niz na ostatnim maratonie - po zimie zapuscilem troche brzucha, a jednak okazlo sie ze nie bylo najgorzej.

Mysle ze sporo zawdzieczam Panu Antoniemu z Gdanska (62 lata, czas 04:26:10) z ktorym przebieglem jakies 1/3 trasy a ktory to narzucal godne tempo. Niestety dla mnie na ostatnich 10 km wachalem juz tylko za nim kurz.

Tutaj jestesmy razem gdzies na polowie trasy:



A tutaj juz ostatni odcinek - nie wygladam najlepiej :)