Sławomir Sobótka w Toruniu

Dobre praktyki, Eclipse, Google, Info, Java, Konferencje, Wtyczki do eclipse Komentarze (1) »

TGD.NET

Nawet nie wyobrażacie sobie mojego zdziwienia gdy rano zaraz po przebudzeniu sprawdziłem maile na telefonie a tam informacja z Toruńskiej Grupy Developerów .NET , że Sławek Sobótka wystąpi w Toruniu.

Fajnie rozkręca się TGD .Net, niedawno byłem na organizowanej przez nich konferencji, teraz zaprosili Sławka - gratuluje.

Szkoda, że w Toruniu żaden JUG nie działa.

Wykłady:

  • Domain Driven Design - Wszystko ma swoje miejsce i wszystko jest na miejscu

“Czy zastanawialiście się co jest przyczyną rozkładu średnich i dużych systemów? Czy jest on nieunikniony i jest jedynie kwestią czasu? A może jednak istnieje jakiś sposób na utrzymanie entropii w ryzach? Podczas prezentacji zobaczymy w jaki sposób Domain Driven Design pomaga w okiełznaniu chaosu. W prezentacji znajdą się główne techniki modelowania takie jak Ubiquitous Language, Bounded Context, Strategic Design. Zostaną przedstawione również podstawowe techniki implementacji DDD: przykłady Building Blocks, Command-query Responsibility Segregation, system zdarzeń, przypadki racjonalnego wykorzystania zarówno ORM jak i czystego i SQL.

  • Command-query Responsibility Segregation - ewolucja architektury warstwowej w stronę modularyzacji i skalowania

Z biegiem kariery, tworząc kolejny system lub aplikację, stajemy przed problemami innej klasy. Inna klasa problemu to inne wymagania odnośnie technologii, metodyki i architektury. Popularne architektury warstwowe mogą być nieodpowiednie do pewnych klas problemów - mogą np. narzucać nieracjonalne wykorzystanie ORM lub promować naiwne modelowanie domeny biznesowej. Podczas prezentacji przedstawię nowe ujęcie warstw - architekturę Command-query Responsibility Segregation, która wspiera aplikacje średniej i dużej skali. Architektura CqRS promuje zdobycze nowoczesnej inżynierii oprogramowania takie jak: Domain Driven Design i noSQL, otwiera system na skalowanie oraz w naturalny sposób rozwiązuje typowe problemy z mapowaniem relacyjno-obiektowym. Główne składowe nowej architektury to: dwa stosy warstw, rozwarstwienie logiki, komunikacja zdarzeniowa oraz opcjonalnie event sourcing (składowanie danych w modelu behawioralnym - w przeciwieństwie do klasycznego modelu strukturalnego)

Miejsce: Wydział Matematyki i Informatyki (ul. Chopina)

Data: 13.05.2011

Godzina: 17.00 - 20.00

Rejestracja: WSS , CodeGuru

Do zobaczenia w piątek 13.  ;-)

Head First Design Patterns

Książki, Wzorce Projektowe Komentarze (0) »

headfirst W zeszłym tygodniu skończyłem czytać książkę “Head First Design Patterns”. Wg mnie książka jak najbardziej godna polecenia. Każdy wzorzec został dokładnie opisany w charakterystyczny dla serii Head First lekki sposób. Autorzy przedstawiają nam kolejne wzorce poprzez przykłady. Stawiając przykładowym aplikacjom kolejne wymagania refaktoryzują kod aby korzystał z określonego wzorca argumentując swoją decyzję i wskazując możliwe skutki uboczne. Książkę czyta się lekko - czasem nawet zbyt lekko. Jeśli miałbym cokolwiek zmienić byłaby to objętość - 650 stron to trochę za dużo - jednak mam świadomość ,że odbyłoby się to kosztem lekkości czytania. W mojej subiektywnej ocenie książka otrzymuje 9 na 10 punktów.

Teraz zabieram się za czytanie książki Mariusza Lipińskiego “Przygotowanie do certyfikacji SCJP 6″

Clean Code w pigułce #1

Czysty Kod, Dobre praktyki, Java, Książki Komentarze (0) »

Jak już pisałem w poprzednim poście jestem w trakcie czytania książki Czysty Kod. Podręcznik dobrego programisty. Pomyślałem sobie, że w trakcie czytania będę starał się wypisywać zawarte tam rady. Efektem tychże notatek będzie właśnie ten wpis. Mam nadzieję, że komuś taki spis dobrych zasad w pigułce się przyda. A ja będę miał go w jednym miejscu :)

Zdecydowałem się na wypisywanie porad zgodnie z rozdziałami książki.

1. Znaczące nazwy:

  • nazwy przedstawiające intencję
  • unikanie dezinformacji
  • wymawialne nazwy
  • nazwy łatwe do wyszukania

2. Funkcje:

  • możliwie jak najkrótsze (max 20 wierszy)
  • najlepiej bez lub jedno argumentowe
  • pojedyncza odpowiedzialność
  • jeden poziom abstrakcji
  • bloki try{} catch{} w osobnej funkcji

3. Komentarze:

  • jak najmniej (samo komentujący się kod)
  • dozwolone komentarze:
    • komentarz z rodzajem licencji
    • TODO
    • komentarze ostrzegające
  • nie komentujmy na siłę
  • nie zostawiajmy za komentowanych fragmentów kodu

4. Formatowanie:

  • małe pliki (klasy) są lepsze niż duże
  • u góry klas najogólniejsze metody poniżej coraz bardziej szczegółowe
  • pionowe odstępy między segmentami kodu
  • funkcja wywoływana zaraz pod funkcją wywołującą
  • wiersze maksymalnie 120 znakowe
  • spacje wokół operatorów
  • wcięcia poziome oddzielające bloki kodu
  • spójne formatowanie w całym zespole

5. Obiekty i struktury danych:

  • NIE dodawać na ślepo setterów i getterów
  • przestrzegajmy prawa Demeter
  • unikanie “wraków pociągów”, czyli kodu postaci: a.getB().getC().getD().getZ().doSth();
  • unikać hybryd (trochę obiekt, trochę struktura danych)

6. Obsługa błędów:

  • wyjątki zamiast kodów powrotu
  • NIE zwracamy null
  • NIE przekazujemy null
  • tworzenie komunikatów błędów z informacją o typie awarii i co miało się wykonać oraz przesłanie ich w wyjątku

7. Granice:

  • separacja obcego kodu od naszego
  • testy “uczące” obcego kodu
  • wzorzec Adapter

8. Testy jednostkowe:

  • kod testów jest tak samo ważny jak kod produkcyjny
  • czytelność testów
  • w testach nie jest tak istotna wydajność
  • jedna asercja na test - niekoniecznie
  • jedna koncepcja na test
  • testy powinny spełniać zasady F.I.R.S.T.
    • Fast - szybkie
    • Independent - niezależne
    • Repeatable - powtarzalne
    • Self-Validating - samo kontrolujące się
    • Timely - o czasie

9. Klasy:

  • organizacja klas (od góry):
    • publiczne stałe statyczne
    • prywatne zmienne statyczne
    • prywatne zmienne instancyjne
    • publiczne metody
    • prywatne metody
  • klasy powinny być małe
  • pojedyncza odpowiedzialność (SRP)
  • niewiele zmiennych instancyjnych
  • zachowanie dużej spójności
Silnik: Wordpress - Theme autorstwa N.Design Studio. Spolszczenie: Adam Klimowski.
RSS wpisów RSS komentarzy Zaloguj








2zł Nordic Gold