Jeszcze wstawię tutaj jakiś głęboki cytat
Niespodziewana zmiana stanu obiektu jest jedną z częstszych przyczyn błędów programistów. Dwoma, moim zdaniem, najczęstszymi przypadkami, w których zmiana może być zaskoczeniem są:
4 kwietnia odbyła się w Warszawie konferencja 4 Developers. Z racji że uczestniczyłem w niej w poprzednich latach postanowiłem że nie opuszczę jej także w tym roku.
Monika Konieczny – Gramification
Ciekawy temat, niezbyt ciekawe wykonanie. Wykład dotyczył kolejnej metody motywacji pracowników, w tym programistów. Metoda ta polega na wprowadzeniu elementów gry podczas realizacji projektu, tak aby pracownicy czerpali radość z pracy. Jako przykład podany zostało rozgrywanie jakiejś gry w określonych odstępach czasu przy czym warunki początkowe gracza zależą od jego tygodniowych wyników (np. liczba kulek do Paintboala rozdawanych w comiesięcznej rozgrywce zależy od części projektu jaki wykonał pracownik). Według prelentki powinno się jednak szybko z gier indywidualnych przechodzić do zespołowych. Ogólnie prezentację oceniam na dobry minus.
Greg Young – zapomnij o szczegółach liczy się efekt
O autorze tej prezentacji przeczytałem na blogu Sławka Sobótki. Początkowo sądziłem że Sławek przesadza z mówiąc że wysłuchanie Grega powoduje efekt "I know kung-fu". Jednak później się przekonałem, że ma rację. Prelekcja była skierowana głównie do programistów Java, dlatego skrytykował on na samym początku używanie potężnych Framewoków i bibliotek w projektach w których samo ich skonfigurowanie zajmuje więcej czasu niż wykonanie projektu, dodatkowo powodując całą masę dziwnych błędów. Jak to określił "Frameworks are DSLs to converting XML into exceptions". Przez dłuższy czas było precyzowane stwierdzenie że klasa rozwiązań powinna być dobrana do klasy problemu. Że zupełnie inne rozwiązania powinno się stosować pisząc pamiętnik dla młodszej siostry, a inne tworząc aplikację nadzorującą działanie układu chłodzącego rdzeń elektrowni atomowej. Greg poruszył też zagadnienie zaciągania "technologicznego długu" podczas pracy nad projektem. Zastosował on sformuowania "Dobry dług" i "Zły dług" zaczerpnięte z publikacji Roberta Kiyosaki. Jedna z wypowiedzi mówiła o zasadności (nie)stosowania testów jednostkowych w projektach które będą rozwijane nie dłużej niż 2-5 lat. Według programistów pisanie testów jest dobrym zachowaniem, jednak wg. kadry zarządzającej powoduje całą masę pracy, która kosztuje i zmniejsza dochodowość projektu. Greg bardzo trafniej porównał stosowanie Testów jednostkowych do wzięcia na kredyt Lamborgini. Dla osób dla których kluczowym elementem sukcesu jest wizerunek (np. gwiazdy sportu i filmowe, prezesi dużych przedsiębiorstw) jest to z pewnością inwestycja("Dobry dług"), jednak dla przeciętnego zjadacza chleba koszty kredytu i utrzymania samochodu tej klasy przewyższają zarówno potencjalny wzrost zarobków a nawet same zarobki("zły dług") i analogicznie stosowanie testów jednostkowych ma sens w systemie bankowym gdzie pomyłka w algorytmie naliczania odsetek może kosztować zarówno bank jak i producenta oprogramowania miliony złotych, jednak mija się z celem w aplikacji napisanej dla sklepu ze skarpetkami gdzie na upartego można w ciągu jednej nocy wprowadzić ponownie wszystkie wystawione i odebrane faktury z ostatniego miesiąca. Kolejną kwestią poruszoną przez Grega była kwestia wzorców projektowych i sensu ich stosowania. Skrytykował on podejście w którym na siłę próbuje się stosować wzorce projektowe (tylko po to by je stosować). Podkreślił jednak ich rolę w komunikacji między proramistami (podając jako przykład Fabrykę Fabryk Fabryk której opisanie bez znajomości wzorców zajęłoby więcej niż ten wpis na blogu).
Ciekawostką jest fakt iż Greg nie posiadał przygotowanej prezentacji także nawet nie włączył projektora.
Michał Gruchała – Architektura skalowalnych systemów Webowych
Prezentacja dotyczyła zagadnienia optymalizacji prostych serwisów poddawanych bardzo dużemu obciążeniu (rzędu kilku milionów wejść na godzinę). Z racji że nie zajmuje się tym zagadnieniem nie specjalnie słuchałem prelegenta.
Sławomir Sobótka – Nowe bardziej racjonalne podejście do warstw
Prezentacja Sławka dotyczyła CQRS (Command Query Responsibility Segregation) która jest rozwinięciem Domain Driven Design. Podejście to zaleca oddzielenie serwisu zwracającego dane od serwisu je zmieniającego, co w dużym uproszczeniu oznacza rezygnację ze zwracania jakiś wartości przez metody które dokonują jakichkolwiek zmian w składowanych danych, oraz rezygnację z modyfikowania danych w metodach dane zwracające. Sławek podobnie jak Greg zwracał uwagę na zastosowanie na dostosowanie rozwiązania do problemu oraz że Domain Driver Design ma zastosowanie głównie przy pisaniu złożonych aplikacji biznesowych, z resztą wyraźnie widać było że Sławek przesiąkł myślą techniczną Greg'a. Nie czuję się na siłach aby przekazać ideę całego wykładu ponieważ sam muszę ją zgłębić.
Stephan Hochdöerfer – DDD jeszcze raz ale inaczej
Podobnie jak pierwsza prelekcja Ciekawy temat nieciekawe wykonanie.
Greg Young – Uwolnij swoją domenę
Wykład ten można potraktować jako rozwinięcie wcześniejszego wykładu Grega i wykładu Sławka Sobótki. Podobnie jak w przykładzie prezentacji Sławka nie podejmuje się analizy tego wystąpienia.
Ogólnie konferencję oceniam bardzo dobrze, a napewno lepiej niż zeszłoroczną. Lepiej dobrano lokalizację (Hotel w Poznaniu śmierdział według mnie komuną, a budynek Wyższej Szkoły Menagerskiej w Warszawie nawet jeżeli nie był nowy to był bardzo dobrze odnowiony), do zalet należy też zaliczyć fakt iż w tym roku posiłek był wliczony w koszt konferencji, oraz że nie zabrakło przystawek. Do wad lokalizacji należy zaliczyć dużą odległość od centrum Warszawy oraz brak ścieżki .Net oraz przedstawicieli firm Adobe, Microsoft i Oracle (może i byli ale ich widać nie było).
Podczas prac w PHP(z którego na szczęście rzadko korzystam) bardzo wkurza mnie fakt iż nie jestem w stanie zdefiniować (przy pomocy PHP Doca) iż jakaś funkcja zwraca tablicę elementów określonego typu. Przez co chcąc prze-iterować po wyniku takiej funkcji mam lekko utrudniony dostęp do pól i metod danej klasy (uzupełnianie kodu Eclipse nie radzi sobie z taką sytuacją zupełnie). Dlatego jakiś czas temu wpadłem na pomysł dodawania do każdej (a właściwie prawie każdej) nowej klasy statycznej metody Cast:
class Moja {
/**
*
* Pseudorzutowanie na typ
* @param mixed $item
* @return Moja
*/
public static function Cast($item) {
return $item;
}
public function JakasFunkcja() {
;
}
}
Teraz mogę sobie w kodzie spokojnie zwracać wyniku typu tablicowego i iterować po nim:
W tej chwili jedyną wadą tego rozwiązania jaka mi przychodzi do głowy jest dodatkowa ilość generowanego kodu.