33degree

arekborek.blogspot.com 1 dekada temu

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ć, iż post będzie długi - po chwili zastanowienia okazało się, iż jednak czegoś dowiedziałem się lub przypomniałem sobie. o ile masz ochotę to polecam cały wpis, o ile nie to proszę wybierz sobie jeden wykład.



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

  • twitter przez cały czas 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 - o ile 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, iż 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, iż Sławek zbyt wybiórczo potraktował wypowiedzi
  • ekspresja i oczywiście Uncle Bob
  • zawsze powinieneś pisać TTD, choćby 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, iż wprowadzenie zmiany w kodzie, przy wynikach testów w postaci green bar daje Ci pewność w 100%, iż 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ść, iż w każdym momencie możesz wprowadzić zmianę w kodzie i przy green bar wiesz, iż 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

Idź do oryginalnego materiału