Joseph W. Yoder

Bio:

Joseph W. Yoder jest założycielem i dyrektorem w The Refactory Inc, – firmie, która skupia się na architekturze oprogramowania, projektowania, wdrażania, konsultacji i doradztwa biorąc pod uwagę wszystkie aspekty rozwoju oprogramowania. Joseph jest międzynarodowym wykładowcą i autorem wzorca „Mud pattern”, wieloletni członek ACM, oraz przewodniczący The Hillside Group – grupy pracującej nad poprawą jakości rozwoju oprogramowania. Joseph specjalizuje się w dziedzinie architektury, analizy i projektowania, jak również jest specjalistą na platformie Java, C # /. NET, Smalltalk, Patterns, Agile Methods, Adaptable Systems, Refactoring, Reuse i Frameworks. Dodatkowo, Joe jest utalentowanym autorem, mającym na koncie kilkudziesiąt opublikowanych prac, w tym jest autorem wzorca Big Ball of Mud, który wychwytuje wiele błędów w podejściu do architektury oprogramowania. Ponadto Joe przeszkolił i mentorował deweloperom różnego rodzaju aplikacji.

Joseph W. Yoder zaczynał od architektury oprogramowania i Patterns group na Uniwersytecie Illinois. W trakcie swojej kariery pracował nad różnymi projektami, które obejmowały wdrażanie nowych technologii. Były to aplikacje zarówno samodzielne, jak i oparte o model klient-serwer, aplikacje internetowe, serwisy internetowe, cloud computing, architektura zorientowana na usługi, wielowarstwowe, opearte o różne bazy danych, obiektowe, frameworki, aplikacji interakcji człowiek-komputer, środowiska współpracy i specyficzne aplikacjie dla specyficznych domen wizualno-językowych. Ponadto projekty te łączyły wiele dziedzin, w tym medyczne systemy informacyjne, systemy finansowe, zamówienia, Import, fakturowanie, drukowanie, spedycja, zarządzanie magazynami, produkcja, badania lekarskie, analizy statystyczne, planowanie scenariuszy, modele klient-serwer w systemie relacyjnej bazy danych do śledzenia wspólnych specyfikacji w środowisku wielu użytkowników, systemy billingowe w telekomunikacji i systemy wspomagania decyzji biznesowych i medycznych.

Zakres nauczania Joe opiewa o zwinne metodyki, wzorce projektowe, projektowanie obiektów refaktoryzację i testowanie w warunkach przemysłowych a także mentoring wielu deweloperów w ramach tych tematów. Inne projekty realizowanych przez Joe tuwzględniają pracę zarówno w środowisk Javy i .NET wdrażających dedykowane języki dla domen klientów. Joe przedstawia tutoriale i wykłady, organizuje warsztaty, organizuje ważne techniczne konferencje na całym świecie, bywa na międzynarodowych konferencjach takich jak Agile, Agile Portugalii, Encontro Agil w Brazylii, AOSD, CBSoft, JAOO, QCon, pyk, AsianPLoP, SugarLoafPLoP w Brazylii, OOPSLA, ECOOP, SATURN i SPLASH. Joe uważa, że oprogramowanie jest wciąż zbyt trudne do zmiany. Chce zrobić coś na ten temat i uważa, że z dobrymi wzorcami i umieszczając możliwość zmiany oprogramowania w rękach ludzi z wiedzą umożliwiającą te zmiany wydaje się być obiecującą drogą do rozwiązania tego problemu. Joe Obecnie mieszka w Urbana, Illinois. (strona główna)

Prezentacja:

Big Ball of Mud: Czy to wszystko na co stać zwinne metodyki?

Choć wiele uwagi koncentruje się na wysoko-poziomowych wzorcach architektury w oprogramowaniu, to co jest w rzeczywistości, de facto standardem dla architektury normalnego oprogramowania rzadko jest omawiane a jest tym koncepcja the Big Ball of Mud (Błotna bryła). Big Ball of Mud to chaotycznie zorganizowana, rozwalony, niechlujna, klejona taśmą klejącą, wyglądająca jak spaghetti dżungla kodu. Wszyscy takie widzieliśmy. Systemy te wykazują niewątpliwe oznaki nieuregulowanej rozbudowy i losowego, niezorganizowania łatania pojawiających się problemów. Informacje są udostępniane zbyt luźno wśród rozproszonych elementów systemu, często do punktu, gdzie prawie wszystkie istotne informacje stają się globalne lub powielone. Nieco ku naszemu zdumieniu, gdyż nasze oryginalne zdefiniowanie tego problemu w późnych latach 90-tych nie doprowadziło do większej dyskucji na ten temat. Jednak to podejście trwa i rozwija się. Dlaczego ta architektura jest tak popularna? Czy jest tak źle, jak się wydaje, czy może też służyć jako sposób-stacja na drodze do bardziej trwałych, eleganckich artefaktów? Jakie siły napędzają dobrych programistów do budowania brzydkich systemów? Czy możemy tego uniknąć? Czy powinniśmy? I jak możemy takie systemy ulepszyć?

W czasie tej prezentacji zbadamy paradoksy, które leżą u podstaw Big Balls of Mud, co je powoduje i dlaczego są one takie ważne. Które praktyki Agile pomogą nam uniknąć lub poradzić sobie z błotem? Czy praktyki Agile takie jak TDD naprawdę mogą pomóc zminimalizować błoto? Co robimy dobrze? Co w praktykach Agile przyczynia się do problemu? Czy powinniśmy zachęcać do tworzenia błota? Czy tworzenie błota to najwięcej na co stać Agile? Czy tak ważne w metodyce Agile skupianie się na procesie, a nie na designie jest jej tajną bronią czy piętą achillesową?

Warsztaty:

Twórcy reguł i narzędzi: Adaptacyjny model obiektowy jako zwinny podział zadań

Ostateczna zwinność: Niech twoi użytkownicy wykonywać Twoją pracę!

Praktycy Agile cenią zarówno przyrostową dostawę opgrogramowania jak i prostete designu. Jednakże podczas pracy nad projektów prowadzonymi w Agile, deweloperzy mogą zostać przytłoczoni tempem zmian wymagań. Łatwość, z jaką wymagania można zmienić zachęca użytkowników do przytłaczania nas prośbami ododanie nowych funkcjonalności. Wynik: Mnogość funkcji, która promuje pośpiech w budowie źle zaprojektowanego oprogramowania do obsługi tych funkcji. Zaprojektowanie ekspresyjnego modelu domeny dla projekt może zostać zagubione w pośpiechu by napisać działający kod. Adaptacyjne modele obiektowe (AOM) zapewniają wsparcie zmienności modelu domenowego poprzez implementację reguł biznesowych jako interpretowane dane oraz reprezentujące je obiekty, własciwości i relacje w zewnętrznych deklaracjach. Na pierwszy rzut oka, systemy AOM zdają się przeczyć z wartościami Agile. Jednak okazuje się, że w odpowiednich warunkach, architektura AOM sprawia że nasi użytkownicy są szczęśliwsi i otrzymali możliwość kontrolowania tempa zmian. To jest właśnie ostateczna zwinność!

W czasie tego warsztatu przedstawione zostaną podstawowe elementy architektury AOM w oparciu o przykład z działającego systemu i pokaże inne wzorce niezbędne do tego stylu architektury. Zaprezentuję następnie kilka wdrożonych systemów AOM i pokażę, w jaki sposób oddano użytkownikom kontrolę nad rozwojem ich systemu. (Więcej informacji)

Laptopy nie są potrzebne an ten warsztat.

Limit uczestników: 30



  • jdd

Organizator

Złoci sponsorzy

  • e-point
  • j-labs

Srebrni sponsorzy

  • Lumesse
  • Luxoft
  • SII

Sponsorzy

  • Redhat
  • WITS

Sponsor Afterparty

  • WITS

Patroni medialni

  • helion
  • Polish JUG
  • Poznan JUG
  • SDJ