poniedziałek, 26 marca 2012

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):

Day 1

19 March, Monday

TimeLuxoftLuxoftLuxoftRoom DRoom E
08:00 – 09:00Registration
09:00 – 09:30Opening
09:30 – 10:30Raffi Krikorian

Twitter: From Ruby on Rails to the JVM

10:30 – 10:50Coffee break
10:50 – 11:50Ken Sipe

Complexity of Complexity

11:50 – 12:00Coffee break
12:00 – 13:00Venkat Subramaniam

Pointy haired bosses and pragmatic programmers: Facts and Fallacies of Software Development

13:00 – 14:00Lunch break
14:00 – 15:00Josh Long

A Walking Tour of Spring 3.1

Frederic Simon

Build Trust in Your Build to Deployment Flow!

Mike West

Dart

Mariusz Sieraczkiewicz

Ewolucyjna architektura (Polish)

Matthew McCullough

Workshop: Git

15:00 – 15:10Coffee break
15:10 – 16:10Sylvain Lebresne

The Apache Cassandra storage engine

Andrey Breslav

Kotlin: A cool way to program for JVM

Sadek Drobi

Non blocking, composable reactive web programming with Iteratees

Tomasz Cejner

Node.js: The Good, The Bad and The Ugly

16:10 – 16:40Coffee break
16:40 – 17:40Toomas Römer

import continuous.delivery.*;

Josh Long

Cloud Foundry and Spring, a marriage made in heaven

Simon Ritter

The Future of the Java Platform: Java SE 8 & Beyond

Wojciech Seliga

"Every Rose Has Its Thorn": Taming automated tests beast.

17:40 – 20:00

Join the Rebellion Party

hosted by ZeroTurnaround
17:50 – 18:50Stephen Chin

BOF: Cleaner APIs, Cleaner UIs with Visage

Josh Long

BOF: Spring and CloudFoundry

Michał Bartyzel

BOF: O kliencie, który wie, czego chce – czyli codzienne sprawy między biznesem a IT (Polish)

Multiple Speakers

BOF: RFID systems security. A contactless use case.

Rafał Wasielewski

BOF: TypeSafe stack 2.0 and Scala Community Talk

Day 2

20 March, Tuesday

TimeLuxoftLuxoftLuxoftRoom DRoom E
08:30 – 09:00Registration
09:00 – 10:00Joonas Lehtinen

Vaadin, Rich Web Apps in Server-Side Java without Plug-ins or JavaScript

Michael Heinrichs

JavaFX for Business Application Developers

Barry O'Reilly

Agile, Lean and Startups practice & principles to create the ultimate value creation machine

Luke Daley

GEB - Very Groovy browser automation

Arun Gupta

Workshop: Java EE 6 = Less Code + More Power

10:00 – 10:10Coffee break
10:10 – 11:10Matthew McCullough

Economic Games in Software Projects

Lars Vogel

What is so cool about Android. 4.x

James Lewis

Micro services - Java, the Unix Way

Patrycja Węgrzynowicz

Hibernate puzzlers

11:10 – 11:30Coffee break
11:30 – 12:30Venkat Subramaniam

Concurrency without Pain in Pure Java

Sadek Drobi

Play 2.0, a Web framework for a new era

Paweł Lipiński

Agile Design

Sławomir Sobótka

Ścisły przewodnik po aspektach miękkich dla ekspertów IT (Polish)

12:30 – 13:30Lunch break
13:30 – 14:30Ken Sipe

Continuous Delivery Best Practices

Luke Daley

Smarter Testing with Spock

Simon Ritter

Java, Kinect and Gestural Interfaces

Sławomir Sobótka

8 klasycznych technik programistycznych leżących u podstaw nowoczesnej inżynierii oprogramowania (Polish)

Wolf Schlegel

Workshop: Exploring parallel programming in Java

14:30 – 14:40Coffee break
14:40 – 15:40Guillaume Laforge

What's new in Groovy 2.0?

Anton Arhipov

Mastering Java bytecode with ASM

Martin Burlinski

Building hybrid mobile apps for iOS and Android with PhoneGap and JQueryMobile

Ken Sipe

Web Security

15:40 – 16:10Coffee break
16:10 – 17:10Venkat Subramaniam

Scala for the Intrigued

Manik Surtani

Infinispan in 60 minutes

Nathaniel Schutta

Designing for Mobile

Szymon Brandys

Developing for Web, In Web - Eclipse Orion

17:10 – 17:20Coffee break
17:20 – 18:20Multiple Speakers

BOF: Groovy and Grails Meetup

Manik Surtani

BOF: NoSQL and Data Grid

Michael Heinrichs

BOF: Game Development with JavaFX

Jakub Nabrdalik

BOF: Beautiful failures

Day 3

21 March, Wednesday

TimeLuxoftLuxoftLuxoftRoom DRoom E
08:30 – 09:00Registration
09:00 – 10:00Venkat Subramaniam

Integrating JVM Languages

Hamlet D'Arcy

Static Code Analysis and AST Transformations

Nathaniel Schutta

The Mobile App Smackdown: Native Apps vs. The Mobile Web

Jacek Laskowski

(map Clojure everyday-tasks) - Clojure for real-world, day-to-day programming

Andreas Krogh

Lift from a JEE perspective

10:00 – 10:10Coffee break
10:10 – 11:10Ken Sipe

MongoDB: Scaling Web Application

Luca Milanesio

Gerrit

Stephen Chin

JavaFX 2.0 and Scala, Like Milk and Cookies

Bartosz Majsak

Acceptance Test Driven Development with Arquillian

Tomasz de Jastrzebiec Wykowski

Leading Individuals

11:10 – 11:30Coffee break
11:30 – 12:30Robert C. Martin

The Three Laws of Test Driven Development

Simon Willnauer

Challenges in maintaining a high performance search engine written in Java

Nathaniel Schutta

HTML5 For Developers

Szczepan Faber

Gradle plugins - build automation evolved

Arun Gupta

The Java EE 7 Platform: Developing for the Cloud

12:30 – 13:30Lunch break
13:30 – 14:30Nathaniel Schutta

Code Craft

14:30 - 14:40Coffee break
14:40 - 15:40Jurgen Appelo

How to Change the World

15:40 - 16:00Coffee break
16:00 - 17:00Robert C. Martin

Demanding Professionalism

Na konferencji pojawiło się wiele znakomitości, takich jak Uncle Bob, czy Venkat Subramaniam.
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.
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 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 Lebresne The Apache Cassandra storage engine


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 Subramaniam - Concurrency without Pain in Pure Java


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.

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.

Venkat Subramaniam - Integrating JVM Languages

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.


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

Nathaniel Schutta Code Craft


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.




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

Brak komentarzy:

Publikowanie komentarza