W 25 odcinku DevTalk wracamy do tematu architektury. Tym razem moim Gościem jest Szymon Kulec: programista, blogger, prelegent i jeden z liderów Warszawskiej Grupy .NET. Na Twitterze: @scooletz. Dyskutujemy o Event Driven Architecture. Z odcinka dowiecie się czym jest EDA, o jakich zdarzeniach mowa i jak z nich korzystać. Do tego: jak ma się do tego CQRS i Event Sourcing, na czym polega eventual consistency oraz jak obsługiwać/przetwarzać zdarzenia? I… oczywiście, wiele więcej :). Zapraszam do słuchania...

Tyle się mówi o rozwoju programistów. Ba, sam o tym często gadam. Że to dobre, że trzeba, żeby nie stać w miejscu a iść do przodu… Ale powiedzcie mi: jak ma się rozwijać programista w typowym programistycznym polskim (i pewnie nie tylko) dev-kołhozie? Przychodzi do roboty, siada do projektu, po 8h wstaje i wychodzi. Niby normalka, ale… niekoniecznie. Moim zdaniem kluczowe jest pytanie: do jakiego projektu ten pr...

… parafrazując słowa Bena Parkera, wujka Spidermana (wiem, że dla niektórych to żenada tego nie wiedzieć, lecz mimo to wyjaśniam)… Temat wyszedł z moich refleksji o architekturze oprogramowania, więc postanowiłam zrobić z niego prezentację, którą przedstawiłam po raz pierwszy w Białymstoku na grupie .Net. Wiele wątków, które tu umieszczę pochodzi od słuchaczy, post będzie więc kumulacją naszych wspólnych przemyśleń. O co więc chodzi z tą władzą i odpowiedzialnością? Zacznę od tego, że każdy z nasz deve...

Pierwszym etapem przy wdrażaniu się w nowy projekt jest poznanie jego funkcjonalności. Nie będziemy w stanie zrozumieć kodu, nie wiedząc do czego dana aplikacja służy. Jeżeli nieuchronnie zbliża się deadline i nie możemy poznać projektu w całości, skupmy się na jednej funkcjonalności. Ludzie, jakkolwiek nie pisaliby kiepsko, to zwykli pisać konwencyjnie. To znaczy, że opanowanie jednego modułu, otworzy nam drzwi do zrozumienia kolejnych modułów. Wyjaśnijmy to na przykładzie systemu TravelCRM, który pr...

Hi everyone, I was thinking about subject of this post. I tried invent something what wasn't written yet. After few days I asked myself: "What should I expect during reading about programming in Metro?" .The answer: "Workshop!" But not basic "hands-on-lab" which give you some information and recommend you to read many articles if you would like to know more. I was expecting "driving" through all process of project . From bussiness case, architecture, development backend, to Metro application im...

Tydzień temu w pierwszym poście poświęconym synchronizacji, przedstawiłem Wam trzy kluczowe zagadnienia związane z tym tematem. I choć lock, Monitor oraz Mutex pozwalają nam rozwiązać naprawdę dużą liczbą problemów dotyczących wielowątkowości, to warto wiedzieć, że jest to tylko część programistycznego orężu w jaki wyposażył nas Microsoft. Dziś chciałbym Wam przedstawić cztery kolejne klasy, które powinny uzupełnić temat rozpoczęty tydzień temu i zasadniczo wyczerpać kwestię synchronizacji. Bez zbędnego ...

W poprzednich częściach przeszliśmy przez zasady SOLID. S – Single Responsibility Principle (oraz cz. 2) O – Open Close Principle (oraz cz. 2) L – Liskov Substitution Principle I – Inversion Segregation Principle D – Dependency Inversion Principle Słowo SOLID bardzo dobrze odzwierciedla to, do czego te zasady prowadzą czyli do budowania solidnego kodu. Przez solidny kod rozumiem taki, który jest łatwy w modyfikacji i który szybko można dostosować do zmieniających się wymagań. Nie są to jednak wszy...

… na szczęście nie przez wszystkich. Intencją niniejszej serii jest przedstawienie podstaw programowania w trochę inny sposób, dlatego mówiąc najbardziej niedoceniana umiejętność w domyśle tyczy się to początkujących. Starsi albo sami dotarli do odpowiedniej wiedzy albo życie ich nauczyło. Jak wyglądają pierwsze kroki w programowaniu? Po opanowaniu pętli for i foreach, ifów i caseów, Console.WriteLineów oraz tych wszystkich klas i obiektów i nie zapominając o polimofizmach wielu rzuca się w wir poznawan...

Problem oprogramowania, które ulega degradacji dotyczy w głównej mierze projektów, w których zapomina się, iż żyjemy w świecie zmieniających się wymagań, a naszym zadaniem jest tworzenie oprogramowania, które będzie potrafiło te zmiany przetrwać. Tak jest! Wymagania zawsze się zmieniają więc powinno to być jedno z priorytetowych założeń każdego projektu. Będąc świadomym tego stanu rzeczy, należy każdorazowo stosować określony zbiór praktyk, przyczyniających się do uelastycznienia projektu.

Publikując artykuł na temat "małych" i "dużych" byłem ciekawy opinii innych ludzi z branży. Pierwszy odzew otrzymałem od kolegi ze studiów Marka Kozłowskiego i za jego zgodą przedstawiam go poniżej. Marek po przeczytaniu postu wyraził zdziwienie, że taki temat w ogóle pojawił się w rozmowie, a rozbicie kodu na podprojekty jest dla niego czymś naturalnym i oczywistym. Stwierdził również, że nie wyobraża sobie pracy z jednym dużym projektem (Aspekt psychologiczny), na który składa się na przykład 100 p...