… 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...

Re: NHibernateStarter... Czyli nawiązanie do świetnego posta Procent-a na temat jego sposobu budowy aplikacji. Poniżej zamieszczam moje aktualne poglądy na ten temat. Zieloną czcionką wyróżniłem fragmenty porównujące oba rozwiązania. O czym w ogóle mowaZawsze na początku należy sobie zadań takie pytanie. O jakich w ogóle aplikacjach mówimy? Procent opisywał przypadek nietrywialnej aplikacji biznesowej (OLTP), więc i ja posłużę się takową. Termin "nietrywialny" oznacza dla mnie znaczący stopień skomplikow...

Pod tym enigmatycznym nieco tytułem kryje się notka na temat problemu wymuszania różnego rodzaju zachowania po drugiej stronie łącza między dwoma systemami. O co chodzi? Wyobraźmy sobie dwie aplikację. Pierwsza z nich, nazwana przeze mnie umownie Klientem, chce do drugiej aplikacji (nazywanej dalej Serwerem) przekazać zachowanie. Nie dane, ale zachowanie.