33degree

po 2012.33degree, Witam

Pojawiłem się dzisiaj po konferencji 2012.33degree w pracy i zostałem zapytany czego nowego się dowiedziałem. Wyobraźcie sobie zdziwienie pytającego gdy odpowiedziałem: 'Nowe rzeczy można policzyć na palcach u jednej ręki'. Podczas powrotu do domu, zacząłem się zastanawiać czy naprawdę tak mało nowych informacji dotarło do mojej głowy. Informacje które to z jakiegoś powodu zakotwiczyły mi się w głowie przedstawię w poście.

Informacje zostaną uporządkowane wykładami, pomoże mi to na przypomnienie sobie informacji i wam drodzy czytelnicy powinno ułatwić czytanie.

Chcę na początku zaznaczyć, że post będzie długi - po chwili zastanowienia okazało się, że jednak czegoś dowiedziałem się lub przypomniałem sobie. Jeżeli masz ochotę to polecam cały wpis, jeżeli nie to proszę wybierz sobie jeden wykład.

Twitter: From Ruby on Rails to the JVM - Raffi Krikorian

• twitter nadal zostaje na ruby stack, java została wprowadzona tylko w krytycznych elementach systemu
• java okazała się jednak nie tak wydajna jak chcieli, zmodyfikowany został GC zważywszy na charakterystykę systemu - bardzo krótko żyjące miliardy obiektów
• reasumując - jeżeli system ma być ekstremalnie wydajna musi być napisany w pure Java
• architektura twittera - klient komunikuje się z gate-server który to wyznacza serwer odpowiedzialny za odpowiedź

Complexity of Complexity - Ken Sipe

• nie wiem czy usłyszałem to na tym wykładzie: nie pisz nowego frameworka, gdy istnieje już gotowy realizujący to samo i w dodatku darmowy
• programiści bywają fanami komplikowania(nie mylić z kompilowaniem :P) kodu; każdy tworzony kod powinien być możliwie jak najbardziej prosty, biznes zatroszczy się o skomplikowanie naszego kodu
• pisz kod najprościej jak się da, ale nie prościej

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

• pytaj 'DLACZEGO', zawsze 5 razy pytaj 'DLACZEGO', niczego nie przyjmuj na 'wiarę'

Dart - Mike West

• JavaScript i jQuery stworzone zgodnie z religią Google; po co nam to ?

Non blocking, composable reactive web programming with Iteratees - Sadek Drobi

• push jest lepszy od pool; Play2.0 pozwala na informowanie UI o zmianach

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

• budowanie aplikacji to bardzo skomplikowany proces
• rozbijaj projekty na jak najmniejsze
• budowanie powinno odbywać się zawsze w gałęzi gdzie nastąpiły zmiany
• nieraz programowo nie możesz przyśpieszyć builda, dlatego też puszczasz go na 40 noda w chmurze amazona

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

• zostałem zauroczony vaadinem, poużywam go to wypowiem się więcej
• zobaczyłem większy hello world - jestem pełen euforii

Ścisły przewodnik po aspektach miękkich dla ekspertów IT (Polish) - Sławomir Sobótka

• polecam wpis prezentacje-na-33rd-degree

Scala for the Intrigued - Venkat Subramaniam

• ekspresja i energia prowadzącego zachęciła mnie do instalacji kompilatora Scali
• rozbawiło mnie stwierdzenie, że programowanie dzisiaj w Javie jest jak programowanie w asemblerze, gdy mamy do dyspozycji scale, grooviego

Integrating JVM Languages - Venkat Subramaniam

• Venkat zapytany kiedyś dlaczego nie przygotuje takiej prezentacji odpowiadał: 'Przecież integracja jeżyków rodziny JVM działa'
• prowadzący pokazał kilka miejsc gdzie integracja nie działa do końca intuicyjnie
• nigdy nie mieszaj języków w ramach jendego projektu - projekt per język

MongoDB: Scaling Web Application - - Ken Sipe

• hello world dla MongoDB
• MongoDB to rozwiązanie dojrzałe

The Three Laws of Test Driven Development - Robert C. Martin

• opis prezentacji Uncle Bob'a powstał zanim przeczytałem wpis Sławka; teść posta nie została zmieniona, mam wrażenie, że Sławek zbyt wybiórczo potraktował wypowiedzi
• ekspresja i oczywiście Uncle Bob
• zawsze powinieneś pisać TTD, nawet gdy w twoje obecnej firmie się tego nie robi
• jeżeli chcesz by w twojej obecnej firmie kodowano przy pomocy TTD, zacznij kodować w TDD - or you change organization, or you change organization :-)
• każda linia testu obliguje cię do napisania kodu w produkcji
• pisanie testów nie zwiększa twojego czasu pracy o 50% tylko 0 20% bo pisanie testów to zapisanie cyklu myślowego - jak twoja funkcja powinna działać
• miara testów: dobrze napisane testy to takie, że wprowadzenie zmiany w kodzie, przy wynikach testów w postaci green bar daje Ci pewność w 100%, że kod działa poprawnie
• testy muszą się wykonywać w mniej niż 1s
• jeżeli re faktorujesz kod nie zmieniaj testów, skasuj je, to test powinien obligować Cię do napisania linii w kodzie produkcyjnym; tak zdefiniowana re faktoryzacja prowadzi do pisania tylko nowych testów
• każdy 'monster' stworzony w kodzie do którego nikt nie chce komitować zmian musi być jak najszybciej wyrzucony - bezwarunkowo
• testy muszą dawać Ci taką pewność, że w każdym momencie możesz wprowadzić zmianę w kodzie i przy green bar wiesz, że system działa poprawnie

Code Craft - Nathaniel Schutta

• solidny wykład, merytoryczny polecam znalezienie slajdów w sieci

How to Change the World - Jurgen Appelo

• miękki wykład - sporadycznie takie rozumiem :P

Demanding Professionalism - Robert C. Martin

• skupiony byłem na powrocie