Do zobaczenia na GET.NET Łódź
This post has been imported from my previous blog. I did my best to parse XML properly, but it might have some errors.
If you find one, send a Pull Request.
GET.NET w Łodzi nadciąga wielkimi krokami. Mam nadzieję, że zarezerwowałaś/-eś sobie sobotę 22 kwietnia jako czas poświęcony na pogłębienie swojej pasji i wiedzy. Razem z wieloma prelegentami, będę miał przyjemność podzielić się z Tobą swoim doświadczeniem i wiedzą podczas mojej prezentacji The Only Thing That Matters jak i dyskusji w przerwach. Aby umożliwić Ci łatwiejsze dostanie się na konferencję, przygotowałem mały konkurs. Wystarczy, że krótko opiszesz:
“Najciekawsze zagadnienie architektoniczne z którym się ostatnio spotkałaś/-eś”
Jak rozumieć architekturę, co opisać, to pozostawiam Tobie.
Odpowiedzi wstawiajcie w komentarzach pod tym postem. Nie zapomnijcie podać maili! Wśród zwycięzców (wyłonionych metodą pseudolosową Random) organizatorzy przygotowali 2 bilety.
Termin zgłaszania odpowiedzi: 29 marca (włącznie).
Comments
Przez ostatni czas z wielkim zaciekawieniem zgłębiam tajniki szeroko rozumianego projektowania i modelowania, ściśle związanego z terminami takimi jak DDD, SOA czy marketingowym określeniem podkategorii SOA czyli mikroserwisów.
Szczególnie podobają mi się różne podejścia do rozwiązania problemu w zależności od poziomu jego złożoności. Tu chciałbym się zatrzymać właśnie na takim zagadnieniu.
Chodzi o stan obiektu, a dokładniej jak zmienia się zachowanie obiektu w zależności od jego stanu. W najprostszym podejściu można używać prostych if'ów switch sase'ów w zależności od wykonywanej akcji, lecz taki kod jest nieelegancki i przy pojawieniu się kolejnego stanu czy jakiejkolwiek zmianie utrzymanie go jest zbędnym wyzwaniem. Wtedy z pomocą przychodzi wzorzec stanu w którym to klasy będące konkretnym stanem implementują interfejs określający wszystkie zachowania zależne od stanu. W przypadku tego wzorca wszystko jest w porządku kiedy każdy ze stanów w pełni implementuje wszystkie zachowania określone w interfejsie, problem zaczyna się pojawiając gdy trzeba rzucać wyjątkami typu 'nie możesz wykonać tej operacji będąc w tym stanie'. Wtedy pozostaje nam explicit state modeling zakładający że każdy stan jest oddzielną encją zawierającą zachowania tylko dla swojego stanu, więc w tym przypadku nie będzie problemu z wyrzucaniem wyjątków typu 'nie możesz wykonać tej operacji będąc w tym stanie' ponieważ nie będzie istniał taki obiekt. Ten komentarz to tylko zajawka, polecam poczytać o explicit state modeling.
by Mariusz Zieja at 2017-03-29 12:17:12 +0000
Na styczniowej grupie WG.NET pokazałeś różnego rodzaju mechanizmy dostępne na platformie Azure. Było to świetne wprowadzenie do zmiany mojego myślenia o projektowaniu aplikacji właśnie na tę platformę.
Dotychczas Azure wykorzystywałem do prostych rzeczy jak hostowanie WebApp, Cloud Services czy VM. Nie dostrzegałem wtedy w czym Azure mógłby mi pomóc przy większych aplikacjach. Jaki jest w nim potencjał.
Dopiero na tej prezentacji udało mi się zrozumieć idee jaka stoi za chmurą. Nie jest to jedynie hosting, w której uruchamiamy kolejne VPS czy instancje WebAppów. Azure oferuje wiele gotowych narzędzi, które zostały wymyślone tak, aby umożliwić prostszą skalowalność aplikacji. Różnego rodzaju kolejki, storage, triggery. Prawdziwym majstersztykiem jest wykorzystanie tych mechanizmów do skomponowania skalowalnego i stabilnego rozwiązania. Bez bottlenecków i single-point-of-failure. Tak, aby nasza aplikacja zdołała obsłużyć stu jak i tysiąc użytkowników.
W wyborze rozwiązań trzeba również patrzeć na cenę. W końcu chmura została stworzona, aby móc dzięki niej oszczędzić. Skalując zasoby dla naszej aplikacji (czy ilość ich instancji) możemy w łatwy sposób ograniczyć nasze wydatki lub zwiększyć moc obliczeniową kiedy tylko wymaga tego sytuacja.
Wiele z tych mechanizmów jest specyficzna dla środowiska chmurowego. Może dlatego miałem problem ze zrozumieniem ich do tej pory?
by Paweł Iżycki (@pizycki) at 2017-03-26 15:29:55 +0000
