Konferencja – CodeDive – relacja

Zapraszam na relację z konferencji CodeDive, która odbyła się we Wrocławiu 5 listopada 2014 w Hali Stulecia.
Konferencja była bardzo udana i merytorycznie stała na wysokim poziomie. Organizacja też nie pozostawiała, żadnych niemiłych wspomnień. Organizator zapewnił wodę i małą pizze w czasie przerwy. Wszystkie wykłady są dostępne na stronie http://codedive.pl/live.html w postaci dwóch długich filmów.

Poniżej relacja z wykładów, na których byłem:

  1. HOW TO BUILD ARCHITECTURE OF YOUR SYSTEM?

Wykład prowadził Jarosław Pałka @j_palka. Wykład był dobrze prowadzony i poruszał następujące tematy:

    • Anit-Paterns„, albo anty-wzorzec . W szczególności „Warm Bodies„, „Design by committe„, „The Grand Old Duke of York” (ten szczególnie polecam, często się go widuje w korporacjach).
    • Przedstawienie definicji architektury oprogramowania jako „procesu”. Procesu, który przekształca architekturę aplikacji ze starej w nową.
    • Zachęcenie do analizy jak często zmiany w oprogramowaniu wpływają na ilość testów, które nie przechodzą na przykład w środowisku ciągłej integracji.
    • Omówienie koncepcji kwadratów Michael Feathers-a. Wyszukiwanie tych miejsc w oprogramowaniu, które nadają się do przebudowania.
    • Punkty warte uwagi podczas projektowania architektury: kto używa systemu? kto zna się najlepiej na systemie?
  1. IRON MAN VS PONY. HOW TO MAKE YOUR JAVA DEVELOPERS WORKING EFFICIENTLY WITH DESIGNERS?

Wykład był prowadzony bardzo szybko. Wykład miał trwac 1:30 godziny a trwał 20 minut. Zrozumienie mocno na tym ucierpiało. Na wykładzie były jednak poruszone nastepujące kwestie:

    • Wytłumaczone zostały określenia – „IronMan”  – które oznaczało programistów, którzy są specjalistami w swoich dziedzinach i skupiają się na tworzeniu oprogramowania i wizji sukcesu. Były przedstawione również wady:  nie zwracanie uwagi na końcowych użytkowników, ponieważ są specjalistami i uważają, że dobrze jest coś fajnego stworzyć . Określenie – „Pony” oznaczał o ludzi z biznesu charakteryzujących się brakiem wiedzy technicznej, miłych i wykazujących się dużą empatią (to było jeszcze bardziej ciekawe).
    • Następnie została użyta ciekawa metafora do tworzenia oprogramowania. Tworzenie oprogramowania zostało przedstawione jako bieg na orientację. Podczas biegu na orientację biegniemy kawałek a następnie patrzymy na kompas i sprawdzamy kierunek. Jeśli kierunek jest dobry biegniemy dalej. Jeśli nie korygujemy. Podobnie powinno być z oprogramowaniem. Tworzenie oprogramowania małymi krokami z częstym sprawdzaniem czy obrany kierunek jest akceptowalny dla użytkowników.
    • Następna cześć przebiegła tak szybko, że skupię się tylko na tym co było najważniejsze. Najważniejszym wnioskiem było aby programiści byli bardziej skłonni wczuć się w role ludzi z biznesu a ludzie z biznesu powinni nauczyć się trochę programować. (naprawdę tak było powiedziane)(a wiec do dzieła cały dział księgowy do nauki C#, SQL-a i koniecznie Spring.Net-a).
  1. CORE PRINCIPLES AND PRACTICES FOR CREATING LIGHTWEIGHT DESIGN

Wykład prowadzony był przez gościa specjalnego @Venkat-a Subramaniam-a. Wykład był świetny. Venkat potrafił przyciągnąć uwagę i wytłumaczyć prosto i łatwo wszystkie poruszanie kwestię. Mówił profesjonalnie i wykazywał się idealnym zrozumieniem tematu.

Na wykładzie omówione zostały dobre praktyki programowania:

  1. THREADING: DOS AND DON’TS

Wykład był prowadzony ciekawie. Był na wysokim poziomie merytorycznym. Omawiał główne problemy przy tworzeniu kody równoległego w C++. Jednak większość poruszanych kwestii jest aktualna w każdym z języków programowania również w C#.

Na wykładzie omówione zostały dobre praktyki programowania:

    • Główne problemy podczas przetwarzania równoległego: problem współdzielenia zasobów, synchronizowanie wartości, blokowanie zasobów.
    • Na wykładzie zostały przedstawione zalety mierzenia wydajności aplikacji równoległych. Częste sprawdzanie czy zmiany, które wprowadzamy mają faktycznie wpływ na wydajność.
    • Omówiony został przykład, który obrazował sposób działania CPU i jego pamięci CACHE w przetwarzaniu równoległym. Przedstawione zostało rozwiązanie, które alokowało większą ilość pamięci CACHE dla zmiennej aby zapobiec odwoływaniu się do tej samej komórki pamieć.
    • Zostały przedstawione sposoby radzenia sobie z problemami wielowątkowych aplikacji. Głowy koncept polegał na unikaniu: współdzielenia zasobów, zmiennych globalnych oraz tablic.
    • Zostały przedstawione zalety używania typów atomowych w C++. Dla przypomnienia typy atomowe w C# to
      bool, char, byte, sbyte, short, ushort, uint, int, float, and reference types.
  1. FUNCTIONAL PROGRAMMING? TECHNICAL REASONS TO ADAPT

Ostatni wykład prowadzony był znów prowadzony przez Venkat-a Subramaniam-a. Co było na marginesie super. Wykład był znów świetny. Venkat potrafił przyciągnąć uwagę i wytłumaczyć prosto i łatwo wszystkie poruszane kwestię, i tak znów było. Wykład pokazywał korzyści płynące z zastosowania programowania funkcyjnego.

Na wykładzie omówione zostały dobre praktyki programowania:

    • Został przedstawiony problem oprogramowania, którego złożoność ciągle rośnie w czasie.
    • Następnie zostały przedstawione podstawowe cechy programowania funkcyjnego takie jak nie zmienność obiektów.
      Dla przypomnienia odpowiednikiem języka funkcjonalnego w .Net-cie jest F#
    • Następnie zostały przedstawione główne zalety używania języka funkcyjnego wraz z konkretnymi przykładami. Zalety to: brak efektów ubocznych z powodu nie zmienności obiektów,  pewność, że każda funkcja dla tych samych parametrów zawsze zwróci ten sam efekt. Dzięki temu, kompilator może lepiej optymalizować kod co powoduje, że kod funkcyjny może mieć lepsza wydajność.
    • Przedstawienie różnic pomiędzy programowaniem deklaratywnym a imperatywnym. Główna różnica przy imperatywnym stylu programowania, to, że napisany kod mówi, co robimy i jak to robimy. Za to przy deklaratywnym, widzimy co robimy, bez pokazywania jak to robimy.
    • Przedstawienie zalet anonimowych funkcji, wyrażeń lambda oraz leniwego przetwarzania. Dla developerów java była to gratka ponieważ w Javie 8 wprowadzono wyrażenia lambda.