piątek, marca 23

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



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

7 komentarzy:

  1. Sam skomentuje swój post:P
    @Scala, należy zwrócić szczególną uwagę na val i var, oraz na fakt, że parametry wejściowe do funkcji są zawsze final.

    OdpowiedzUsuń
  2. 100% racji panie blogerze. Ja wczoraj w pracy na pytanie o konferencję odpowiedziałem: 1/3 nudy, 1/3 rzeczy oczywiste, 1/3 szoł z rzeczami oczywistymi (venkat/uncle bob).

    OdpowiedzUsuń
    Odpowiedzi
    1. Wygląda na to, że mimo moich starań w doborze tematów, aby były one trafione do bardziej zaawansowanych developerów, Wasza wiedza i doświadczenie były zbyt wysokie na tą konferencję.
      Może w przyszłym roku podzielicie się Waszą wiedzą z tymi mniej doświadczonymi. Serio mówie...

      Usuń
    2. Witam Grzesiek,
      Miło mi, że zainteresowałeś się moim postem.
      Po tygodniu mogę powiedzieć, że początkowa bardzo surowa ocena konferencji teraz jest oceną umiarkowaną. KONFERENCJA PODOBAŁA MI SIĘ, myślę, że zbyt dużo oczekiwałem po prelekcjach Unclea Boba. Oczekiwałem olśnienia i teraz z perspektywy czasu wiem, że nie było możliwe streszczenie 420 storn z Clean Code w 1h i olśnienie widowni.

      Myślę, że ludzie spodziewali się, że Uncle Bob będzie jakimś nadczłowiekiem(przynajmniej ja) i po 1h naprawi wszystkie bolączki z jakimi spotykamy się w dniu codziennym. Robert C. Martin okazał się być porządnym, ekspresyjnym speakerem, no ale jak taki speaker może konkurować z nadczłowiekiem ;P.

      Usuń
  3. A ja zapytam o powód braku wyboru mojej prezentacji o Clojure? Chętnie poznam powód braku zainteresowania językiem Clojure, albo jedynie moim wystąpieniem. Jeśli to drugie, to śpię spokojnie(j).

    Gdybym jednak poznał powody na nie dla moich wystąpień i/lub Clojure, mogłoby to uprościć życie moje i moich słuchaczy (którym nie zamierzam odpuścić w tym roku - do samego czerwca! :))

    OdpowiedzUsuń
    Odpowiedzi
    1. Witam Jacku,
      zbyt krytycznie podszedłeś do tematu braku widowni na twojej prelekcji, pozwól, że przedstawię Ci proces myślowy który skierował mnie na prelekcje Verkanta, a nie twoją. Wybrałem Verkanata ponieważ nie będę miał już okazji posłuchania go, w momencie dokonywania wyboru byłem pewien, że będę mógł jeszcze zobaczyć twoją prelekcję o Clojure w tym roku (inne konferencje, wliczając darmową Confiturę), a nie mogłem tego samego powiedzieć o wystąpieniu Verkanta.

      Usuń
  4. Tak też sądziłem! Nie miałem złudzeń, że ułożenie mnie z Venkatem nie przyniesie wiele dobrego dla mojego wystąpienia.

    Czuję się usatysfakcjonowany Twoim tokiem myślenia i liczę na ostrą krytykę przy nadarzającej się okazji udziału w moim wystąpieniu.

    Jak teraz sobie myślę, liczba osób u mnie była zdumiewająco wysoka (ca 60 ludzi), kiedy Venkat za rogiem. Dziękuję za zwrócenie mi uwagi na to!

    OdpowiedzUsuń