Posty z kategorii: Daj się poznać 2017

MagazineManager – czas zamodelować cz. 3

Привет! (rosyjski)

Sobota, więc chwila czasu na ogarnięcie posta, którego w sumie dawno nie było 🙂 Ale wiele się dzieje, dlatego byłem zmuszony poluzować z pisaniem, a nie chcę na siłę pisać czegoś, co będzie mało wartościowe. Co się odwlecze, to nie uciecze i dzisiaj siadamy do dalszego omawiania 🙂

Przedmiot rozważań

Głównym tematem tego wpisu będą tak zwane scenariusze użycia inaczej zwane też scenariuszami współpracy. Każdy przypadek użycia, który przedstawiony jest na diagramie, reprezentuje oczekiwane zachowanie systemu skutkujące osiągnięciem pewnego celu. Do jego osiągnięcia koniecznym jest wykonanie szeregu czynności jedna po drugiej. Właśnie ten szereg czynności modelujemy przy pomocy scenariuszy użycia. Proste, prawda :)?

Charakterystyka scenariuszy przypadków użycia

Scenariusz przypadku użycia opisuje kolejne kroki do osiągnięcia rezultatu oczekiwanego prze zdefiniowany przypadek użycia. Opis ten można wykonać na kilka sposobów. Sam scenariusz jest fragmentem opisu przypadku użycia. Wykonywany jest w postaci listy numerowanej kolejnych kroków lub przez wykonanie diagramu czynności w języku UML. Diagramami czynności zajmiemy się w kolejnym odcinku. Na początek przygotujemy sobie scenariusze w postaci listy, przez co narysowanie diagramów będzie łatwiejsze.

Opis

Pełen opis przypadku użycia zawiera takie elementy jak:

Scenariusz

W repozytorium możesz zobaczyć, jak wyglądają utworzone przeze mnie scenariusze użycia. Jest to lista kroków, która opisuje przebieg całego przypadku użycia. W niektórych miejscach na samym początku jest wyszczególniony warunek początkowy. Mówi, co musi być spełnione, aby dany przypadek mógł zostać uruchomiony.

Zwróć uwagę na charakterystyczną budowę zdań. Składają się one z podmiotu, orzeczenia i dopełnienia (niezbyt rozbudowanego). Jest to bardzo ważne, ponieważ ułatwia wyszczególnić, jakie elementy biorą udział w danym przypadku użycia.

Kolejnym ważnym aspektem jest też pierwszy punkt każdego scenariusza. W zdecydowanej większości przypadków to użytkownik (czy system, który współpracuje z naszym) rozpoczyna sekwencję! Aktualnie nie mam nawet pomysłu, kiedy to nie użytkownik zaczyna 🙂

Dalej, scenariusz nie jest pojedynczą metodą. Scenariusz opisuje interakcje użytkownika i naszego systemu, dlatego też każde orzeczenie zdania odpowiada wywołaniu metody.

Na końcu scenariusza podane są także alternatywne drogi, które opisują, co się dzieje w przypadku wprowadzenia błędnych danych czy innych błędów systemowych.

Zastanawiasz się też może, czemu w scenariuszu nie podajemy punktu typu: System wraca tam gdzie był. Nie robi się tego, ponieważ traktuje się to domyślnie 🙂

Podsumowanie

Dzisiaj króciutko (w końcu!) przedstawiłem Ci, drogi Czytelniku, esencję informacji o scenariuszach przypadków użycia. Zapraszam do repozytorium a po inne informacje, na znaną Ci już stronę. Oczywiście też odsyłam do czeluści internetów i książek 🙂

Zapraszam do komentowania, powiedz proszę, czy wolisz posty krótsze, czy może dłuższe 🙂

A no i ostatnie na koniec 🙂 Zauważyłem, że czegoś brakuje w diagramie przypadków użycia 🙂 Kto mi powie czego :D?

Miłego dnia!

7. tydzień DSP i co u mnie słychać? Cz. 1

ยินดีต้อนรับ! (tajski)

Piątek, piąteczek, piątunio…! W sumie to i wczorajszy dzień był już wolny, bo i ferie wielkanocne się zaczęły na uczelni. Czas świąt jest czasem radości i refleksji, więc i tutaj należy cofnąć się parę kroku wstecz i przejrzeć co się zmieniło, jeżeli się w ogóle zmieniło. To wydaje mi się będzie jeden z trudniejszych postów naskrobanych przeze mnie, ale jak potrzebny. Zatem nie przeciągając do dzieła!

Rzeczy może mniej ważne, ale będące wartością dodaną

Kilka kwestii jest może mniej ważnych, niż to na czym się chcę skupić, ale uważam, że też powinny się znaleźć w tym zestawieniu.

Powitania w innych językach. Może dla Was to taka forma fanaberii czy innego dziwactwa, ale dla mnie jest to fajne 🙂 Lubię poznawać nowe miejsca, jednak niestety bardzo malutko podróżuję, więc to taka nano forma ucieczki w inny zakątek świata, chociaż na kilka sekund 🙂 Dzięki wujku Google! Jeżeli to kogoś zainteresuje, to zbieram pocztówki. Jeśli masz chęć to daj znać i wyślij kartkę! Odwdzięczę się tym samym! 😀 Kiedyś może Wam pokażę moje kolekcje 🙂

WordPress. Blog, który czytasz, biega na WordPressie. Fajna okazja do zapoznania się z tą, jakże wygodną platformą. Wcześniej korzystałem z Joomli, co też w sumie dobrze wspominam. Przy tej też okazji, nakreśliłem ten ascetyczny szablon strony, dzięki czemu zapoznałem się z metodologią ich tworzenia i podpinania do systemu. Teraz sobie powoli rozrysowuję w głowie nowy, docelowy wygląd i niebawem zacznę go kreować, najpierw lokalnie, a jak go dopieszczę, to rzucimy go we świat i niech hula!

Rzecz właściwa, czyli blog

Nic nie dzieje się bez przyczyny. Gdzieś przypadkiem natrafiłem na vloga Macieja Aniserowicza, to był chyba jeden z pierwszych odcinków, o rekrutacji i wymaganiach na Junior Developera. I tak odcinek do odcinka i kliknięcie do kliknięcia i trafiłem na DSP. Od dłuższego czasu chciałem coś zrobić w sieci. Jeszcze nie wiedziałem do końca co. I wiesz, drogi Czytelniku, jak to jest. A nie mam czasu bo to i tamto… Sam z tym walczyłem i będę walczył, ale o tym więcej za sekundę. No i tak o to mówię, biorę udział, to mnie zmotywuje. I tak rozglądałem się za hostingiem, domeną i całą resztą technicznych komponentów. Aż w końcu nadszedł ten dzień i ruszyłem 🙂 I od tego dnia cały czas daję radę i jestem z siebie dumny. Może i to nieskromnie brzmi, może widzisz niedociągnięcia, czy jakieś inne błędy, ale wiedz, że prowadzenie tej strony robi niesamowity przewrót w moim życiu i cieszę się, że nie jako i Ty jesteś fragmentem tego zamieszania! 🙂

Rozwój

Przygotowanie każdego wpisu zabiera mi dużo czasu, ponieważ chcę, aby to co piszę było naprawdę przemyślane. Dużo czasu zabiera również szukanie źródeł, które czasem Wam podlinkowuję i z których sam uzupełniam swoją wiedzę. I to jest właśnie największą wartością mojego udziału w DSP, to ciągłe pogłębianie swojej wiedzy. Oglądam vlogi Macieja Aniserowicza, Mirka Burnejki, Arka Benedykta, szukam, czytam… Dzięki temu wszystkiemu powoli klaruje się w mojej głowie obraz tego, czym chciałbym się zajmować w przyszłości. Odnośnie uzupełniania wiedzy, jak już wielokrotnie wspomniałem, projekt jest tylko dodatkiem do tego, o czym chcę powiedzieć. Jest przykładem, na którym mogę ćwiczyć i opisywać. Jak widzisz, praca nad nim idzie bardzo wolno, ale to z faktu, że wolę skupić się na treści merytorycznej niż nad samym naklepaniem kodu.

Przyjemność

Prowadzenie tego małego przybytku sprawia mi niesamowitą radość i cały czas nie mogę się doczekać, kiedy znajdę chwilkę, żeby coś porobić związanego z blogiem. Czasem idzie lepiej, czasem idzie gorzej z tym czasem, ale nie olewam tematu 🙂 Na Slacku DSP widziałem rozmowy o fali postów, które nic nie wnoszą, bo ludzie piszą „nie mam czasu, ale dwa posty w tygodniu, więc pisze coś o tak”. Nie chcę tak robić i tak nie robię. Jeżeli nie udało mi się wypuścić dwóch postów, jak np. w zeszłym tygodniu, to nie skrobię czegoś na siłę, bo nie warto, nie o to w tym chodzi.

Rozmowa

Blog jest miejscem, gdzie mogę z Tobą porozmawiać. Czy to w komentarzu, czy na Facebooku, czy w jakikolwiek inny sposób. Jest to miejsce, w którym mogę podzielić się swoim doświadczeniem z Tobą, a jednocześnie mogę zapisać najważniejsze punkty, by nie uleciały z głowy. Ponadto, kiedy mówisz: „ej stary, bo tam ostatnio czytałem u ciebie…” to nawet nie wiesz jakiego kopa do przodu mi dajesz i jeszcze bardziej motywujesz do działania. Jestem tutaj dla siebie i Ciebie.

Przerwa

I znowu jest tyle rzeczy, o których chcę powiedzieć, że wpis się rozciąga, dlatego dzisiaj zakończymy na tym i w przyszłym już tygodniu będę kontynuował 🙂 Życzę Ci miłego dnia i Wesołych świąt! 🙂

MagazineManager – czas zamodelować cz. 2

Byenveni! (kreolski)

Niedziela, 06.04, mija szósty tydzień Daj się poznać. Jesteśmy za półmetkiem, ale mimo to spokojnie idziemy z projektem. Ważniejsze jest dla mnie przekazanie treści i dobre zaprojektowanie, niż naklepanie tego bez przemyślenia z niskiej jakości kodem w dwie noce 🙂 Niestety ten tydzień przyniósł za sobą wiele tematów do ogarnięcia i powstał tylko wpis, który aktualnie czytasz, drogi Czytelniku. Ale wiesz co jest najważniejsze dla mnie? Że ciągnęło mnie do napisania kolejnego wpisu i strasznie mnie złościło, że musiałem w tym tygodniu pofolgować… Uważam to za mój mały wielki sukces 🙂 Dlaczego zapytasz? Bo pomału wchodzi mi w krew prowadzenie tego skromnego przybytku. Czuję też, że dzięki temu się rozwijam i żałuję, że nie mogę poświęcić tyle czasu ile bym chciał, ale żeby tak było, to musiałbym poświęcić wszystko inne i siedzieć całe dnie nad tym, a tego się (niestety) nie da 😀 Widzę także, nad czym muszę popracować od strony technicznej bloga (tutaj jest milion rzeczy do zrobienia), ale także od mojej osobowej strony (redukcja obowiązków oraz lepsze zarządzanie czasem). Mógłbym jeszcze wiele pisać, ale o tym powstanie osobny post 🙂 Czas teraz wracać do naszych schematów.

Wstęp

W ostatnim poście powiedzieliśmy sobie w dwóch słowach o modelowaniu i stworzyliśmy sobie szkice tychże diagramów. W momencie gdy to czytasz, uległy one modyfikacjom. Teraz omówimy sobie ogólnie z czego składają się te diagramy, opiszemy krótko notację, a na koniec powiemy w kilku słowach o systemie.

Diagram przypadków użycia (Use Case)

Pierwszym diagramem, który sobie omówimy jest diagram przypadków użycia. Na nim przedstawione są funkcje, których oczekują użytkownicy od naszej aplikacji lub zewnętrze systemy korzystające z tworzonego przez nas systemu. Na diagramie wyróżniamy komponenty takie jak:

To tak w skrócie, tyle jest potrzebne do zrozumienia całego diagramu. Jeżeli chodzi o symbole, to jak się pewnie domyślasz patrząc na w dymkach opisujemy przypadki użycia, a ludziki reprezentują poszczególnych aktorów. Warto dodać, że jeżeli aktorem jest system zewnętrzny, to możemy zmienić ikonę na inną.

Aktorzy mogą być generalizowani. Przykład? Proszę bardzo. Mamy sklep. W sklepie pracuje kasjer, kierownik, oraz osoba sprzątająca. Każda z nich będzie oczekiwała innych funkcjonalności, dlatego powstanie dla każdej z nich osobny diagram reprezentujący owe przypadki użycia. Ale zauważ, że możemy utworzyć aktora o nazwie Pracownik, który dla którego wyspecyfikujemy funkcjonalności wspólne dla tych trzech typów użytkowników, np. rejestrowanie przyjścia do pracy, rejestrowanie wyjścia z pracy. Relacje generalizacji, oznaczamy przez strzałkę z pustym w środku grotem, jak na poniższym diagramie.

Generalizacja aktorów

Oczywiście to zalążek tego, co można powiedzieć o diagramie przypadków użycia. Po więcej informacji kieruj się w stronę czeluści internetu 🙂 Dodatkowe oznaczenia, krotności oraz pułapki, na które trzeba uważać przy tworzeniu diagramów użycia.

Diagram klas (struktury obiektów)

Modelując program obiektowo szukamy wzorców, czyli klas, stanowiących szablony obiektów, które są ze sobą w jakiś sposób powiązane. I te właśnie powiązania przenosimy „na papier” rysując diagram klas lub diagram struktury obiektów. Dla wyjaśnienia w diagramie klas operujemy tylko na klasach, w diagramie struktury obiektów reprezentujemy relacje pomiędzy konkretnymi instancjami klas, będących w konkretnym stanie.

Klasę (lub obiekt) przedstawiamy w postaci prostokąta podzielonego w pionie na 3 części: w górnej nazwa klasy, w środkowej nazwy pól klasy poprzedzone znakiem + dla dostępu public, – dla private oraz # dla protected oraz po nazwie i dwukropku występującym typie pola, a w ostatniej nazwy metod opisane podobnie jak nazwy pól.

Ponadto wyznaczamy na diagramie relacje zachodzące pomiędzy klasami:

Więcej informacji o relacjach i sposobie ich oznaczania możecie znaleźć pod tym linkiem.

Podsumowanie diagramów

Starałem się dosłownie w kilku słowach wyjaśnić Ci, co znaczą symbole na powyższych diagramach oraz jak je interpretować. Mam nadzieję, że udało mi się to chociaż w małym stopniu. Temat diagramów jest mega duży i nie sposób w kilkuset słowach w poście powiedzieć wszystkiego, ani nawet wystarczającego minimum. Bardzo ciekawym źródłem informacji jest ta strona. Gdyby miał pisać posty tylko o UML to za jakikolwiek kod wziąłbym się za 2 lata chyba 😛 Dlatego jeśli chcesz wiedzieć więcej (a warto!) to zapraszam Cię do przestudiowania powyższej strony, czy poszukania innych, może jeszcze lepszych źródeł. Jeżeli znajdziesz, podziel się! 🙂

MagazineManager – diagramy, kontynuacja

Teraz kilka słów o diagramach stworzonych do MagazineManager’a.

Diagram przypadków użycia odzwierciedla to co jest zapisane w pliku PDF. Jest jeden aktor, ponieważ każdy użytkownik będzie sobie indywidualnie zarządzał bazą.

Diagram klas przedstawia logiczną hierarchię interakcji kolejnych klas. Zastosowana relacja kompozycji określa zależność, iż na przykład magazyn może istnieć bez egzemplarzy, jednak egzemplarz magazynu nie. Określone również zostały krotności relacji. Zależność pomiędzy klasami jest liniowa, ideowo program jest dość prosty.

Diagram klas odzwierciedla rzeczywiste obiekty. W dalszym kroku przygotowane zostaną diagramy klas, które zostaną zaimplementowane w programie, czyli uwzględnią warstwy widoku, prezentera oraz transferowe. Ale to przyszłość 🙂

Czas kończyć…

Dzisiaj bardzo owocny dzień. Przygotowanie tego posta zajęło mi ok. 6 h. Długo, niedługo, starałem się jak najlepiej to zrobić i jak najwięcej pokazać 🙂 Zachęcam do dyskusji w komentarzach! Chciałbym, żeby ktoś świeżym okiem na to spojrzał i powiedział: „Stary, a może tak będzie lepiej?” Bardzo lubię z kimś rozmawiać w czasie projektowania, ponieważ wtedy mózg pracuje na 500% i rzeczywiście model jest najlepszy 🙂

Nie przeciągając, życzę Ci dobrego przyszłego tygodnia oraz do zobaczenia przy kolejnym wpisie 🙂 Cześć! 🙂

MagazineManager – czas zamodelować cz. 1

Xush kelibsiz! (uzbecki)

Niedzielne popołudnie, a ja już drugi tydzień wyrabiam normę trzech postów w tygodniu. I… dobrze mi z tym! Mam nadzieję, że uda się utrzymać tę passę, ponieważ prowadzenie tego małego dobytku sprawia mi naprawdę dużo frajdy 🙂 Dokładniej sobie o tym porozmawiamy już niedługo, więc na ten temat na razie się nie będę rozpisywał 🙂

Za to dzisiaj rozpiszę się o czymś innym. Mianowicie o modelowaniu i narzędziach do niego wykorzystywanych. Znów to troszkę potrwa, ponieważ wiele zagadnień chcę poruszyć dla Ciebie, drogi Czytelniku, ale również dla siebie, żeby usystematyzować swoją wiedzę na ten temat. Sposób nauki poprzez tłumaczenie komuś, tego co się nauczyło, bardzo pomaga w dokładnym zrozumieniu tematu i utrwalaniu wiadomości (o czym, np. ostatnio słyszałem we vlogu Mirosława Burnejki oraz o czym też mówi Mirosław Kardaś – drugiego Mirosława polecam, jeżeli ktoś chce zacząć zabawę z mikroprocesorami rodziny AVR). Dlatego też rozwój projektu jest dosyć powolny, ponieważ traktuje go tylko jako dodatek oraz podkładkę do nauki i przykład praktycznego zastosowania teorii. 🙂

Co to jest modelowanie i po co ono jest?

Jak widzisz, bardzo dużą wagę przykładam do projektowania aplikacji. Czy to dobrze, czy źle… Ja uważam, że dobrze. Za kilka tygodni zobaczycie, że zakodzenie dobrze zaprojektowanej aplikacji trwa moment. Dlatego bardzo ważnym etapem projektowania jest modelowanie. A co to w ogóle jest? Modelowanie jest narzędziem pozwalającym na zobrazowanie potencjalnie trudnych i skomplikowanych zagadnień, które będziemy chcieli rozwiązać przy pomocy tworzonego przez nas oprogramowania. Brzmi trudno, jednak w rzeczywistości jest odwrotnie! Modelowanie pozwala na pokazanie obiektów i interakcji między nimi oraz pozwala zrozumieć architekturę tworzonego systemu nawet przez osoby nie będące programistami (ale to dzięki zapisowi o którym zaraz).

Jak i czym modelować?

Oczywiście powstało wiele narzędzi do tego. Jednym z nich, powszechnie używanym jest język UML. Ustandaryzowana struktura diagramów i symboli umożliwia opisanie rzeczywistości, obiektów w niej się znajdujących wraz z ich stanami oraz powiązaniami. Po dokonaniu tego opisu możemy zamodelować kod, który powinien być zgodny z tym, co odnajdujemy w świecie rzeczywistym. Warto może tutaj dodać, że skupiam się na modelowaniu obiektowym, bo i w takim paradygmacie tworzę swoje oprogramowanie oraz paradygmat ten jest najbardziej popularny dzisiaj na świecie (jeżeli się mylę poprawcie mnie!). Więcej o samym języku UML możecie poczytać na Wikipedii lub w książce profesora Michała Śmiałka Zrozumieć UML 2.0, z którym miałem przyjemność mieć zajęcia własnie z przedmiotu Modelowanie oprogramowania w języku UML. Serdecznie pozdrawiam! 🙂

Narzędzia

Do modelowania w języku UML oczywiście jest programów. Ja miałem okazję skorzystać z programu Enterprise Architect, a do tworzenia diagramów dla MagazinManagera wykorzystam darmowe narzędzie UMLet. Po pierwszym użytkowaniu mogę stwierdzić, że bardzo przyjemnie się z niego korzysta. Prostota narzędzia nie zaciemnia obrazu podczas tworzenia diagramu.

O samym języku będziemy sobie opowiadać przy okazji kreowania kolejnych diagramów – najlepiej tłumaczyć na praktycznym przykładzie.

Modelowanie struktury obiektów/klas

Cechą paradygmatu obiektowego jest tworzenie oprogramowania zgodnego z naturalną, rzeczywistą strukturą zagadnienia. W świecie istnieją pojedyncze obiekty, byty, każdy z inną tożsamością, posiadające cechy oraz zdolności wykonywania pewnych czynności. Obiekty są konkretnymi egzemplarzami schematu zwanego klasą. Klasa definiuje zestaw cech oraz czynności, które obiekty będące egzemplarzami klasy posiadają. Dlatego w pierwszym kroku stworzę diagram z wykorzystaniem języka UML przedstawiający, jakie rzeczywiste klasy obiektów będę wykorzystywał w swoim oprogramowaniu.

Modelowanie funkcjonalności aplikacji

Następnym diagramem opisującym system jest diagram przypadków użycia. Ma on za zadanie zobrazować, jakie funkcje system ma dostarczać funkcje, ze względu na zdefiniowanych użytkowników. Użytkownika określamy mianem aktora.

Podsumowanie

W kilku zdaniach opisałem Ci, co będę robił w najbliższym czasie. W repozytorium projektu znajdują się dwa diagramy opisane powyżej. Przejrzyj je, zobacz, czy są one zrozumiałe. W następnym odcinku omówimy sobie ich budowę oraz porozmawiamy o kolejnych diagramach, które powstaną. Zachęcam do komentowania i wspólnej nauki! 🙂 Cześć! 🙂

Warszawskie Dni Informatyki – znowu okiem studenciaka, cz. 2

Fáilte! (irlandzki)

W związku z tym, że prosiliście mnie o opinię na temat prelekcji czy warsztatów, w których ja uczestniczyłem, to postaram się teraz jak najbardziej obiektywnie przedstawić, jak to wyglądało i wyrazić subiektywną opinię na ten temat. Krótkie bio prelegentów znajduje się na stronie WDI.

Dzień 1.

W pierwszym dniu uczestniczyłem w otwarciu całego eventu. Nie będę się rozpisywał na ten temat, bo pewnie nie o to Wam chodzi 🙂

Pierwszą prelekcją w której brałem udział była „Asseco keynote: Scenariusze rozwoju technologii mobilnych” prowadzona przez Radosława Semkło z firmy Asseco (bio przeczytacie na stronie WDI). Niestety z powodu przeciągnięcia się rozpoczęcia i mojej wizyty u promotora musiałem dość wcześniej wyjść, byłem tylko na wstępie. Nie mogę zatem zbyt wiele wypowiedzieć się na temat całości, chociaż wstęp zapowiadał się ciekawie.

Kolejną prelekcją była prowadzona przez Jacka Borka „Accenture Technology Vision 2017 – Technology for people. The Era of intelligent enterprise”. Omawiał on raport przygotowany przez Accenture Technology Labs, który badał, jak w najbliższym czasie rozwijał się będzie przemysł IT, w którą stronę programiści pokierują swoje kroki. Treść raportu w wersji pełnej, 15 minutowej i 5 minutowej znajdziecie tutaj. Bardzo się cieszę, że akurat wybrałem tę prelekcję, ponieważ raport stanowi esencję tego, co dzisiaj się dzieje na świecie i jakie wyraźne trendy się wyklarowały.

Potem zrobiłem sobie chwilę przerwy na wycieczkę do stoisk praodawców. Chwila wytchnienia.

Następnym etapem przygody z 1. dniem WDI były warsztaty ze wstępu do Springa prowadzone przez Dominika Ciborowskiego. Wybrałem te warsztaty, ponieważ chciałem w końcu zaprzyjaźnić się ze Springiem. Robiłem jakoś nie dawno podejście do niego, ale potem się jakoś rozeszło po kościach i tyle. Na początku prelegent zrobił krótkie wprowadzenie teoretyczne oraz przygotował krótki pokaz działania aplikacji. Jak wiadomo, kod pisany na żywo co często nie chce zadziałać od razu i tak było tym razem. Z doświadczenia wiem, że opowiadanie o czymś słuchaczom i pisanie w międzyczasie kodu, nawet nieskomplikowanego, może skutkować drobnymi błędami, które można łatwo poprawić patrząc świeżym okiem. Przykład omawiany na zajęciach znajdziecie na GitHub. Ciekawa prezentacja, widać, że autor mimo młodego wieku ma dużą wiedzę na omawiany temat. Ogólnie łapka w górę 🙂

Przedostatnią rzeczą tego dnia, w której brałem udział, był panel dyskusyjny prowadzony przez Macieja Aniserowicza, a rozmówcami byli: Mateusz Mikulski, Artur Wiza, Paweł Wadyl oraz Borys Musielak. Panowie w dyskusji „walczyli co jest lepsze” – Startupy vs korporacje. Przedstawiali swoje doświadczenia oraz jak to startup z czasem musi przerodzić się w korporację i na czym to właściwie polega (w skrócie: trzeba usystematyzować swoją pracę poprzez wprowadzenie procedur, co jest trudne z uwagi na przyzwyczajenia ludzi).

No i na koniec prezentacja prowadzona przez Jakuba Kołakowskiego o Design Sprincie, czyli modyfikacji podejścia do tradycyjnego sprintu. Wartościowa rzecz, a więcej możecie znaleźć np. tu.

I tak oto minął dzień 1.

Dzień 2.

To był dzień spędzony z ekipą DevTalk, co możecie zobaczyć na Instagramie.

Zacząłem od wykładu Mirosława Burnejki prowadzącego bloga Chmurowisko.pl, który opowiedział o tym, dlaczego chmury są fajne i ułatwiają życie architektom, programistą i wszystkim zainteresowanym 🙂 Materiały do tego wykładu znajdziecie w tym linku. Przyznaje się, że jestem laikiem jeśli chodzi o chmury, a mimo to rozumiałem o czym mówimy i jak to działa 🙂 Super!

Drugi wykład prowadził Arkadiusz Benedykt (benedykt.net) o tzw. Internet of things. Początek wykładu to opowieść o rozwoju elektroniki i tym, jak dzisiaj mamy to ułatwione. Przedstawił moduły Arduino, RaspberryPi i wiele innych, które niejako są kluczowe dla IoT, z uwagi na to, że dzisiaj wielu ludzi może sobie samemu w zaciszu domowym stworzyć np. sterowane oświetlenie w domu. Jednak w całym spotkaniu chodziło o to, żeby nie odpłynąć z tym podłączaniem wszystkiego do internetu, ponieważ niesie to za sobą liczne zagrożenia. Dlatego powinniśmy zabezpieczać się przed wyciekiem danych poprzez te podłączone do sieci urządzenia.

I ostatnią (niestety) rzeczą na WDI, w której wziąłem udział, był panel dyskusyjny o tym jak technologia zmienia naszą przyszłość. Prowadzili to Mirosław Burnejko, Arkadiusz Benedykt, Maciej Aniserowicz oraz Jarosław Pałka (na którego prezentacji niestety być nie mogłem). Najfajniejszą rzeczą tego panelu było to, że tak naprawdę każdy mógł (i brał) czynny udział w dyskusji.

Podsumowanie

Zdałem Wam sprawozdanie z tego, w czym brałem udział. Mam nadzieję, że rozwiałem Wasze wątpliwości i zaspokoiłem ciekawość 🙂 Bardzo się cieszę, że nabieram z Wami kontaktu. Dużo daje mi to motywacji i jednocześnie satysfakcji. 🙂 No i oczywiście dziękuję za kubeczek DevTalk, który udało mi się zdobyć podczas prezentacji o IoT oraz dziękuję za wspólną fotkę! 🙂

Czas kończyć i pomóc chłopakom w pracy 🙂 A gdzie i w jakiej? Zobaczycie i przeczytacie o tym niebawem! Śledźcie, lajkujcie, udostępniajcie! Do zobaczyska!

Warszawskie Dni Informatyki – znowu okiem studenciaka

Bienvenue! (fr.)

Środa wieczór/czwartek noc. Ostatnie dwa dni były dość długie, ale bardzo fajne. Czemu spytacie? A no temu, że na kampusie głównym Politechniki Warszawskiej na Wydziale Matematyki i Nauk Informacyjnych odbywała się wielka konferencja połączona z targami pracy IT zwana Warszawskimi Dniami Informatyki. W tym roku była to siódma edycja tego wydarzenia, moja już trzecia, więc mogę powiedzieć, że jestem stałym bywalcem 🙂 Oczywiście moja krótka i subiektywna ocena tego wydarzenia musi się pojawić na blogu, bo warto zanotować pewne spostrzeżenia dla potomnych 🙂

Miejsce, logistyka i inne szczegóły techniczne

Gmach Wydziału MiNI jest według mnie bardzo fajnym miejscem na tego typu wydarzenie. Dużo, naprawdę dobrze wyposażonych sal i przede wszystkim wygodnych sal, klimatyzacja – to robi dobrą robotę. Ponadto położenie gmachu w centrum miasta ułatwia dojazd uczestnikom (in my opinion of course). Jedynym minusem jest mała ilość miejsca przy stoiskach firm wystawiających się w ramach targów pracy. Ale ogólnie i tak duży plusik 🙂

Dalej – wielki szacun za ogarnięcie całego wydarzenia. Z tego co mówili, pracowało przy tym ponad 100 osób, dlatego należy im się solidne dzięki za całą pracę w to włożoną. Co osobiście bym zmienił, poprawił? Na warsztaty czy prelekcje każdy uczestnik zapisuje się poprzez odpowiednią stronę. Co z tego, że uczestnicy się zapisuję, jak nikt potem tego nie sprawdza i o ile na wykładzie, można posiedzieć na podłodze, o tyle na warsztatach już fajnie jest gdzieś postawić tego laptopa. Z drugiej strony ciężko jest komuś odmówić uczestniczenia w tak ciekawych zajęciach. Tu może należałoby pomyśleć o jakiejś optymalizacji.

Więcej chyba nie ma co się rozdrabniać. Kawał ciężkiej pracy, który z nawiązką się zwrócił!

Merytoryka i jej skutki

Przeróżne ścieżki, warsztaty, prelekcje. Mnogość tematów sprawia, że każdy znajdzie coś dla siebie. Jako odbiorca, zwykły szary student, zebrałem dawkę mega ciekawej i przydatnej wiedzy, chociażby pod względem obrania swojej drogi rozwoju. Myślę, że to jest clue całego wydarzenia: motywacja, inspiracja. Wiecie dlaczego chcę być w tej branży? Bo ta branża żyje swoim życiem, a co najważniejsze żyje razem! Community działa naprawdę prężnie i człowiekowi chce się rozwijać, ponieważ inni go do tego motywują. Dlatego biorę udział co roku w WDI, dlatego innych zachęcam do wzięcia w nich udziału. Ludzie, którzy są mistrzami w swojej dziedzinie przychodzą do młodych, szukających szczęścia ludzi łaknących wiedzy, motywacji i inspiracji. Oni przychodzą do nas i rozmawiają jak równy z równym, bez względu na to, że widzimy się pewnie pierwszy i ostatni raz. Ja patrząc na nich mówię „skoro dla nich jest to takie proste i przyjemne, to czemu ja miałbym się nie odnaleźć w tym świecie”? Przy okazji możesz spotkać ludzi, którzy Cię inspirują (co możecie zobaczyć na Instagramie, ponadto zdobyłem kubeczek DevTalk i mega się z niego cieszę, chyba aż wrócę do picia kawy 😀 ).

Podsumowanie

Czy warto? Warto. Opłaca się brać udział w życiu community i się rozwijać razem z innymi. Motywuje to bardzo. Postawiłem sobie dzisiaj cel, że w ciągu najbliższych dwóch lat, wezmę udział w konferencji (niekoniecznie tej) po drugiej stronie barykady. Wiem, że będzie mnie to kosztowało wiele pracy, bo trzeba stać się specjalistą w jakiejś dziedzinie, ale na pewno będzie to warte poświęcenia. Prowadziłem już różne prezentacje, warsztaty i zajęcia, ale to będzie mega wyzwanie i mega satysfakcja, jeżeli wyjdzie. Trzymajcie kciuki, żeby się udało osiągnąć ten cel!

To tyle na dzisiaj. Krótko, zwięźle i mam nadzieję na temat. Zapraszam do komentowania! A tymczasem dobranoc, cześć! 🙂

Już wiem, co aplikacja ma robić!

Üdvözöljük! (węgierski)

Niedziela, piękna pogoda, więc kończymy posta i idziemy na spacer 🙂

Dzisiaj będzie króciutko, bez odkrywania świata. Bardziej to będzie wpis sprawozdawczy.

Co w specyfikacji piszczy?

Troszkę popracowałem, co może być stosunkowo mało widoczne, jeśli chodzi o objętość dokumentu, ale dużo posiedziałem, poczytałem i przemyślałem. Co z tego wynikło? Rozpisując się nad dodawaniem artykułów do bazy itd. przypomniałem sobie o CRUD. CRUD to skrótowiec wywodzący się od angielskich słów Create, Read, Update i Delete. Obojętnie czy to będzie całe czasopismo, kategoria lub artykuł, zawsze muszę mieć dostęp do tych czynności. Aplikacja będzie interfejsem pomiędzy zbiornikiem danych a użytkownikiem, więc wiele więcej funkcjonalności mieć nie będzie. Ponadto poza samymi funkcjonalnościami jak widzisz dokument zawiera parę innych rzeczy, które są związane z realizacją tych funkcjonalności.

Baza danych

Zdecydowałem się zastosować silnik mySQL rozwijany przez firmę Oracle z uwagi na szeroko dostępne narzędzia takie jak XAMPP czy WAMP, które każdy, kto kiedyś pisał cokolwiek związanego ze stronami internetowymi ma na komputerze. Ograniczy to konieczność stosowania przez szarego Kowalskiego dodatkowego silnika bazodanowego poza tym co ma.

Co dalej?

Kolejnym krokiem w projektowaniu aplikacji będzie jej zamodelowanie z wykorzystaniem języka UML. Trochę sobie porysujemy i porozmawiamy o tym co, jak i z czym. 🙂 W międzyczasie chcę w końcu zmodyfikować też sam wygląd bloga, aby był bardziej ludzki i dawał więcej funkcjonalności.

LaTeX

Powiedziałem kiedyś, że powiem wam w dwóch słowach o LaTeXu. Jest to język, który służy do składania dokumentów. W mojej opinii jest to taki Word dla programistów, bo tam cały wygląd dokumentu opisujemy odpowiednimi znacznikami. Dzięki LaTeXowi unikamy przykrego rozjechania się dokumentów przy przenoszeniu między różnymi wersjami oprogramowania biurowego, o przejściu Word — LibreOffice/OpenOffice nie wspominając. Kompilator wypluwa plik PDF niezależnie od tego, gdzie to kompilujemy. Odkąd nauczyłem się z tego korzystać, używanie pakietu biurowego dąży do zera. Zachęcam do zapoznania się z tym, kod macie u mnie w repozytorium (pliki z rozszerzeniem .tex). Na koniec posta załączę przykładowe linki z tutorialami itp.

Dobra to chyba wszystko na dzisiaj. Założyłem sobie 3 posty w tym tygodniu i cel spełniłem, z czego jestem dumny. W końcu udało mi się napisać krótszy post niż 800 czy 900 słów, co też jest może i małym sukcesem 🙂 W najbliższym czasie postaram się pisać częstsze i krótsze posty, zobaczymy, jak to rozwiązanie się sprawdzi 🙂

Miłego dnia!

Linki:

https://www.matematyka.pl/latex.htm

http://www.fuw.edu.pl/~kostecki/kurs_latexa.pdf

Kompilator mikTEX: https://miktex.org/

Środowisko TexMaker: http://www.xm1math.net/texmaker/

Zwinne testowanie

Welkom! (holenderski)

Witam Cię w poniedziałkowy wieczór znów na mojej stronie. Tak szybko kolejny wpis? Tak! Nadrabiamy zaległości, poza tym dzisiejszy temat jest kontynuacją wczorajszego, więc idę za ciosem. Dzisiejszy dzień jest bardzo ważny dla mnie z różnych powodów i zwieńczenie go wpisem, będzie wisienką na torcie. Może zastanawiasz się, co z projektem? Te posty są bezpośrednio z nim związane. Otóż jak pisałem, bodajże w opisie projektu na stronie konkursu, wybrałem stosunkowo prosty projekt po to, żeby móc pokazać troszkę wiedzy i poglądów na pewne tematy oraz nauczyć się nowych technologii na jakimś żywym przykładzie. Także w projekcie dzieje się cały czas! No ale już nie przedłużając, jedziemy z dzisiejszym tematem.

Dzisiaj chcę z Tobą, drogi czytelniku, pociągnąć temat zwinności i metodyk z nią związanych. Jeżeli widziałeś ten szkic specyfikacji, który powstał i leży sobie spokojnie na GitHub, to może zwróciłeś uwagę na końcowe zdanie. Do budowy aplikacji zostanie wykorzystana metodyka Test-Driven Development. Ale co to tak naprawdę jest?

TDD

TDD, czyli Test-Driven Development jest uważana za metodykę zwinną głównie ze względu na spełnienie manifestu: „Działające oprogramowanie ponad obszerną dokumentację”. Testowanie oprogramowania ogranicza (nie eliminuje!!!) występowanie błędów, a dobrze napisane testy mogą usprawnić dokumentowanie kodu, możemy potraktować je jako formę specyfikacji. Wróćmy do początku i zdefiniujmy sobie dokładnie hasło TDD. Za tym pojęciem kryje się cykliczne wykonywanie kilku kroków (za Wikipedią):

  1. Projektujemy test
  2. Implementujemy funkcjonalność
  3. Refaktoryzujemy kod

Brzmi to jednak bardzo pobieżnie i enigmatycznie, jednak kryje się za tym bardzo duża siła (czym jestem ostatnio zafascynowany i dlatego teraz, razem z Wami poznaję tę tematykę).

Co w trawie (TDD) piszczy?

Sednem TDD nie jest tak naprawdę pisanie oprogramowania niejako od tyłu, no bo w sumie po co i czemu tak, a w ogóle to te całe testy to nie wiadomo po co są, szkoda klawiatury. Pozwól jednak, że udowodnię Ci nieprawdziwość takiego podejścia!

Z definicji test jednostkowy ma przetestować pojedynczy element programu, jego zachowanie w różnych, mniej lub bardziej sprzyjających warunkach. Rozpoczynanie tworzenia aplikacji od zdefiniowania testów, które nawet się nie skompilują ze względu na brak reszty szkieletu zmusi do myślenia i wyciągnięcia z odchłani mózgu, co tak naprawdę chcemy uzyskać. Wychodzimy ze sztywnych więzów implementacyjnych na rzecz interfejsu i funkcjonalności, co w sumie jest zgodne z Agile (znów).

W kolejnym kroku następuje implementacja brakującego szkieletu (z tego co się orientuję to VS i Eclipse udostępniają automatyczne narzędzia, trzeba się będzie przekonać :), ponadto w tym kroku solucja się skompiluje ale uruchomienie wywoła test, które siłą rzeczy nie przejdą) i wypełnienie tego szkieletu logiką (o i działa :D). W tym miejscu zaczynają przechodzić testy. Przechodzimy zatem do punktu 3., czyli refaktoryzujemy kod. Ta wstępna implementacja jest pisana tak z marszu, po to, żeby testy przeszły. Osiągamy przez to jeden cel działającej funkcjonalności spełniającej nasze oczekiwania. Refaktoryzacja jest bardzo ważnym krokiem. Otóż kod powinien być sporządzony w taki sposób, aby testy zawsze kończyły się wynikiem pozytywnym, zatem refaktoryzacja kodu nie ma prawa wpływać na wynik testu. Jeżeli tak jest, to należy się zastanowić, czy sam test został sporządzony poprawnie (znaczyłoby to, że funkcjonalność jako taka nie została dobrze określona). W przeciwnym razie popełniliśmy błąd w przebudowie kodu i należy przeprowadzić ten proces jeszcze raz.

Refleksja

Czy warto jest stosować TDD? Tak! Jednak jak ze wszystkim musimy być rozważni. Już tłumaczę w czym rzecz. Takie podejście do stworzenia oprogramowania pozwala na minimalizację liczby błędów występujących w tworzonym oprogramowaniu. Nigdy nie jesteśmy w stanie wyeliminować ich w 100%, ale minimum jest zawsze najlepszą opcją 🙂 Ponadto testy stanowią dokumentację funkcjonalności dostarczanych przez pakiet oraz mają w sobie przykłady użycia – zatem bezsensowne staje się pisanie zewnętrznego manuala jako dokumentu, jeżeli śledząc kod testu możemy tego dotknąć na żywca.

Oczywiście też jest druga strona medalu. Testy są oczywiście kodem do utrzymywania – dla części osób może to stanowić poważny problem, bo jak wiemy programista to z natury leniwe coś. Samo podejście od tej strony nie jest łatwe, jednak wszystko się da. Materiałów jest cała masa, czy to właśnie podobnych dywagacji czy tutoriali. Pod postem coś tam podlinkujemy fajnego 🙂 To chyba tyle, pamiętaj też, drogi czytelniku, że to tylko narzędzie i trzeba z niego odpowiednio korzystać 🙂

Nie samym TDD człowiek żyje

To co, tak zachwalał i tłumaczył i teraz ucieka? Nic z tych rzeczy 🙂 Ale przy tak świetnej okazji trzeba wspomnieć o ewolucji narzędzia TDD, znanej jako Behavior-Driven Development, w skrócie BDD. Szukając w internecie informacji na ten temat przygotowując się do tworzenia tego posta, często spotkałem się ze stwierdzeniem, że BDD to TDD a TDD to BDD. W istocie rzeczywiście tak jest. Rozszerzenie BDD względem TDD polega na wykorzystywaniu narzędzi do definiowania funkcjonalności oraz przygotowywaniu tzw. user scenarios, które to opisują przebieg krok po kroku konkretnej funkcjonalności. Świetny przykład formowania user scenarios znajduje się pod tym linkiem. User scenarios zapisuje się np. za pomocą języka Gherkin, który współpracuje z narzędziami wspierającymi BDD, np. Cucumber, z którego ja będę korzystał, ale to już w kolejnym poście. BDD też można określić jako metodykę nie będącą tak bardzo restrykcyjną jak TDD. Jednak ta różnica jest jak mówiłem bardzo nikła. Wikipedia angielska mówi: „Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.”. Myślę, że lepszej konkluzji się nie znajdzie 🙂

Podsumowanie

I tak o to po raz kolejny z wieczora zrobiła się już w sumie noc. Znów post zamiast krótkiego, będzie miał ok. 1000 słów. Mam nadzieję, że w takim telegraficznym skrócie opisałem Ci, co to jest TDD i BDD oraz dlaczego są one takie przyjemne. W kolejnym poście już popracujemy bezpośrednio nad aplikacją, ale musiałem zrobić ten wstęp, by zachować jakiś porządek logiczny 🙂 Mam nadzieję, że Ci się podobało! Zachęcam do komentowania i poprawiania mnie, jeżeli się mylę 🙂 Chciałem także podziękować mojemu koledze Michałowi, który podesłał mi parę linków i zainspirował do pogrzebania na ten temat 🙂 Dziękuję! 🙂 Tymczasem mówię Ci do zobaczenia, ale przewiń stronę dalej, by poklikać w przydatne linki 🙂 Miłego czytania! 🙂

Przydatne linki

TDD Wikipedia: https://pl.wikipedia.org/wiki/Test-driven_development

O testach na Devstyle.pl: http://devstyle.pl/category/tech/tests/

O TDD u Arkadiusza Benedykta: http://www.benedykt.net/2010/11/07/tdd-czyli-test-driven-development/

BDD Wikipedia: https://en.wikipedia.org/wiki/Behavior-driven_development

Narzędzie Cucumber: https://cucumber.io/

Inne:

http://softwareengineering.stackexchange.com/questions/135218/what-is-the-difference-between-writing-test-cases-for-bdd-and-tdd

http://softwareengineering.stackexchange.com/questions/111837/relation-between-bdd-and-tdd

Zwinnie pracujemy – Agile, Scrum i wszystkie takie dziwne słowa

Oi! (port.)

Witam Cię w tę właściwie już poniedziałkową noc. Zeszły tydzień upłynął pod znakiem targów pracy i innych rewolucji życiowych, dlatego też pojawił się tylko wpis o Inżynierskich Targach Pracy. Ale nadrabiamy zaległości i w tym tygodniu może się uda wypuścić 3 posty, żeby nadrobić zaległości w DSP, a tematów jest cała masa! 🙂 Zaczynamy!

Żeby móc z Wami rozmawiać (tutaj te słowa kieruję do osób, które gdzieś tam zaczynają swoją przygodę z programowaniem, bo ludzie „z branży” na pewno to znają, ale może powstanie jakaś ciekawa dyskusja, do czego zachęcam!) musimy porozmawiać o tzw. zwinnym programowaniu.

Słowo wstępne

Na początku projektu zdefiniowaliśmy sobie pojęcie inżynierii oprogramowania oraz modeli, w jaki sposób można rozwijać oprogramowanie. Założyłem, że na czas trwania konkursu, przyjmę model wodospadowy (ang. waterfall) z możliwością przejścia w model spiralny realizowany przyrostowo. Dlatego też zaczynam od zdefiniowania wymagań i funkcjonalności, które system ma zapewniać oraz zebranie tego w odpowiednich dokumentach. Dla wielu pasjonatów bariera tworzenia dokumentacji jest nie do przejścia (kto by to pisał, sic!), jednak ja uważam, że warto jest to tworzyć, bo życie potem staje się prostsze. Ale tworzyć w sposób mądry.

Oczywiście to o czym będziemy mówili, nie tyczy się tylko tworzenia dokumentacji ale życia całego projektu.

Programowanie zwinne

Z czym kojarzy się słowo zwinny? Słowo zwinny według słownika języka polskiego oznacza skoczny, zwrotny, zręczny, poruszający się sprawnie. A jak odnosi się to do tworzenia oprogramowania? Zwinność ta odnosi się do obserwacji zachowań klienta. Wymagania klienta, funkcjonalności, jakie system ma dostarczać, często ewoluują zmieniają się w czasie trwania samego projektu. Dlatego należy często dokonywać przeglądu wymagań klienta i dynamicznie modyfikować dostarczane oprogramowanie. Programowanie zwinne, z ang. agile software development to zbiór metodyk umożliwiających realizację częstych przeglądów. Metodyki te opierają się na modelu spiralnym i realizacji przyrostowej.

Agile

W 2001 roku zdefiniowano tzw. manifest agile, który zbiera najważniejsze zasady będące sednem idei programowania zwinnego. Są one następujące:

  1. Ludzie i interakcje ponad procesy i narzędzia
  2. Działające oprogramowanie ponad obszerną dokumentację
  3. Współpracę z klientem ponad formalne ustalenia
  4. Reagowanie na zmiany ponad podążanie za planem

Jak można wywnioskować, zwinność polega na złagodzeniu sztywnych więz narzuconych przez określone modele. Lepiej rozmawiać ze sobą, niż wypełniać formularze, lepiej być elastycznym w stosunku do zmieniających wymagań, niż sztywno trzymać się zapisów. Jednak należy zauważyć, że słowo ponad nie znaczy zamiast. Dobry przykład? Działające oprogramowanie ponad obszerną dokumentację – niestety zdarzają się zespoły, które interpretują to jako nie tworzenie dokumentacji w ogóle, co jest oczywistym błędem! Jest to główne nieporozumienie związane z zastosowaniem agile w pracy zespołu. Ten punkt znaczy tyle, że dokumentacja nie ma być książką o 5000 stron, tylko ma zawierać punkty odniesienia, filary projektu, nie dające się wyczytać bezpośrednio z kodu. Zapewnia to jej elastyczność, łatwo się utrzymuje i będzie ona aktualna.

Podstawą do pracowania w ten sposób, jest praca w niewielkich, łatwozarządzalnych grupach ludzi.

Scrum

Scrum jest jedną z metodyk zgodnych z manifestem Agile. Polega na podzieleniu docelowego produktu na mniejsze partie, tak by można było je wykonać w krótkich okresach czasu, tzw. sprintach. Każdy sprint kończy się wydaniem działającej wersji oprogramowania, która może być oddana do użytku, zatem zmiany wprowadzone w każdym sprincie muszą być „klikalne”.

Sprint jest przygotowywany: planowana jest lista wymagań użytkownika, która ma zostać w danym etapie wprowadzona, szacowany jest czas (należy w tym uwzględnić „pożary” na produkcji), planowany jest przebieg sprintu. Ważna jest ciągła współpraca z klientem, co pozwala na rozwój oprogramowania zgodnie z oczekiwaniem. Dobrą praktyką podczas pracy w Scrumie są retrospekcje na koniec sprintu. Dzięki temu programista jest w stanie przemyśleć, co było fajne, co było złe, nad czym trzeba popracować. Ponadto podział projektu na podprojekty realizowane jako sprinty dobrze wpływa na myślenie człowieka – wolimy wykonywać drobniejsze zadania i szybciej się z nich „czyścić”. Ponadto po każdym sprincie zebrany feedback od klienta umożliwia dopracowywanie aplikacji w każdym calu. I w tym momencie możemy zacząć mówić o zarządzaniu zmianą.

Dla klienta ważny jest widoczny rozwój aplikacji, której na początku został wykreślony tylko ogólny kształt. Może on zacząć korzystać z jakiejś części funkcjonalności.

Narzędzia

Ciekawym i bardzo przydatnym narzędziem w pracy z metodyką Scrum są tak zwane daily stand-up meettings. Są to spotkania krótkie, „na stojaka”, trwające 15 – 20 minut, w których każdy członek zespołu opowiada, co udało mu się zrobić dnia poprzedniego, jakie problemy napotkał. Przy czym staramy się opowiadać o funkcjonalnościach, jakie zrealizowaliśmy a nie, że napisałem 3 klasy i 4 interfejsy, bo to nie ma żadnej wartości dla pozostałych członków zespołu i nie pokazuje wymiaru pracy, jaki został ukończony.

Jeżeli chodzi o jakieś narzędzia typowo przeznaczone do wspomagania pracy programistów oraz kierowników zespołów, są to narzędzia klasy ALM (Application Lifecycle Management). Ułatwiają zarządzanie całym cyklem życia oprogramowania: projektowaniem, implementowaniem i utrzymaniem. Przykładami takich narzędzi są Team Foundation Server od Microsoftu albo Jira.

Podsumowanie

Dwa często wymawiane pojęcia, niebywale ważne w dzisiejszym świecie developmentu. Wprowadzenie metodyk zwinnych zmieniło diametralnie podejście do tworzenia oprogramowania. Dzisiaj znakomita większość zespołów pracuje wykorzystując metodyki tego rodzaju, sam pracowałem w zespole Scrumowym (pozdrawiam zespół oprogramowania w dziale badawczo-rozwojowym w Trumpf Huettinger w Zielonce!), co było mega fajnym i uczącym doświadczeniem.

I to chyba tyle wstępu do kolejnego, mega ciekawego w mojej ocenie wpisu, który już się przygotowuje w mojej głowie i mam nadzieję pojawi się bardzo szybko! 🙂 Miłego czytania i zapraszam do komentowania! Dobranoc 🙂

MagazineManager – co on właściwie ma zrobić? Cz. 2

Hi!

Witaj w kolejnym wpisie dotyczącym rozwoju tworzonej aplikacji. W poprzedniej części rozważyliśmy model w jakim będziemy tworzyli oprogramowanie. Wybrałem model kaskadowy, który w przyszłości będzie można przekształcić w model spiralny. Umożliwi to w łatwy sposób dodawanie funkcjonalności. Teraz na potrzeby konkursu założymy sobie pewne wymagania i je po prostu zrealizujemy właśnie zgodnie z modelem kaskadowym. A już w przyszłości, poza konkursem, kiedy w trakcie korzystania z tej aplikacji czegoś mi zabraknie, to to dopiszę. Jednak z takim dopisywaniem funkcjonalności oraz modelem spiralnym wiąże się Agile czyli zbiór metod, założeń tzw. zwinnego wytwarzania oprogramowania oraz Scrum jako jedna z metody zgodnych z Agile. Temat rzeka, jednak już niebawem o tym także porozmawiamy.

Specyfikacja funkcjonalna – opis wymagań, które system ma spełnić

Kiedy klient przychodzi do firmy tworzącej oprogramowanie, ma ku temu jakieś tam powody. Potrzebuje narzędzi, które programiści są w stanie mu dostarczyć. Stawia przed nimi wymagania, mające zaspokoić jego potrzeby. Dlatego w pierwszym kroku klient siada z odpowiednim zespołem i razem opracowują dokument, zawierający funkcjonalności realizowane przez powstający system. To nie jest łatwe zadanie i zajmuje stosunkowo dużo czasu. Zespół musi wdrożyć się niejako w dziedzinę, dla której oprogramowanie jest tworzone po to, aby wyciągnąć co się da od klienta, bo dla niego pewne rzeczy mogą być oczywiste, jako „osobnika z branży”, zaś dla deweloperów już niekoniecznie. Poza tym często jest problem z samym sposobem opisu. Mówi się, że jeden obrazek może zastąpić 1000 słów i to naprawdę tak jest. Ponadto przecież ten sam cel można osiągnąć pokonując różne drogi prawda? Jest dużo takich rozbieżności, używanie różnych terminologii, jeżeli z systemu ma korzystać wiele użytkowników, to każdy z nich co innego by chciał od oprogramowania i tak można wymieniać w nieskończoność. Dlatego ten etap jest kluczowym w rozwoju oprogramowania, bo ewentualne błędy potem odbijają się czkawką przez długi czas.

Czy wymagania są tylko funkcjonalne?

Oczywiście, że nie. Wymagania funkcjonalne jest to tylko część całego systemu, o którym trzeba myśleć. Poza nimi są tzw. wymagania niefunkcjonalne, definiowane jako specyfikowalne z perspektywy czarnej skrzynki jako jakościowe cechy rozwiązania. Wymagania te określają, jakie ograniczenia są nakładane na system, np. spełnienie wymogów określonej normy, integracja z istniejącymi już systemami, które nie mogą być modyfikowane pod nasze rozwiązanie, sprzęt, na którym oprogramowanie będzie miało działać… Znów wymieniać można w nieskończoność i zdecydowanie jest to temat na kolejny odcinek tej serii. Chciałem tylko rzucić temat, może i Ty mi coś ciekawego podpowiesz? 🙂

Jak definiować wymagania?

Jak mówiłem wcześniej – TO NIE JEST TAKIE PROSTE ŻEBY ZDEFINIOWAĆ WYMAGANIA! Dlaczego? Część z tych cech wymieniłem już wcześniej: każdy ma swoją wizję na świat i produkt, który ma uzyskać widzi inaczej, ciężko opisać pewne „ficzery”. Dalej, nie są one oczywiste dla wszystkich a przy okazji mocno ze sobą powiązane. Istny misz masz. Dlatego przechodzimy w opisie wymagań od ogółu do szczegółu w kolejnych krokach:

Jakość opisu wymagań i cechy

Dlatego mówimy także o jakości sporządzonego opisu. Zastanówmy się więc, jakie cechy powinny mieć wymagania i opis, by rzeczywiście dało się coś z tego urzeźbić. Same wymagania przede wszystkim powinny być kompletne i dokładne. Mówiłem o tym wcześniej. Należy wycisnąć co się da z klienta, by rzeczywiście spełnić jego oczekiwania. Przy okazji należy pamiętać o tym, że wymagania muszą być realistyczne i osiągalne, ale tego chyba nie trzeba tłumaczyć. Dalej każde z wymagań powinno być opisane w sposób jasny oraz jednoznaczny – tutaj właśnie przydają się różnego rodzaju diagramy, które eliminują rozbieżności znaczeń języka naturalnego. Ostatnią cechą powinna być weryfikowalność stawianych wymagań. To pozwoli na uniknięcie nieprzyjemnych sytuacji typu nieuregulowanie płatności za pracę, bo produkt nie spełnia wymagań. To chyba tyle, może Ty masz jakiś pomysł?

Co zatem trzeba umieścić w dokumencie zbierający wymagania nałożone na system? Przede wszystkim należy zadbać o to, by dokument nie zaprzeczał sam w sobie w różnych jego częściach. Jeżeli tak jest, to błąd został popełniony na samym początku, przy procesie ich zbierania. Ponadto ma opisywać sposób pracy systemu, jego zachowania zewnętrzne, czy w przypadku niepożądanych lub skrajnych sytuacji. Sam dokument, który opisuje nie tylko funkcjonalności dostarczane przez system musi zawierać nakładane na oprogramowanie ograniczenia lub możliwości zmian/rozwoju aplikacji.

Dokumentacja

Oczywiście to co już zbierzemy, trzeba jakoś ładnie zebrać. W moim przypadku sporządzę dokument napisany w LaTeXu. Polecam się zapoznać z tym mega fajnym narzędziem! Odkąd zacząłem go używać, to Word służy mi jedynie do otwierania dokumentów w nim napisanych. Poza stworzeniem czegoś, co można wydrukować, są narzędzia, które pomagają podczas realizacji funkcjonalności przez programistów. Ale to znów tak obszerny temat, że powstanie o tym kolejny wpis na blogu 🙂 O tym podpowiedział mi mój kolega Michał, dzięki! Jak tylko to ogarnę sobie i będę w stanie Wam to przekazać, to na pewno to zrobię 🙂

MagazineManager – jakie są moje oczekiwania?

W końcu do sedna. Miało być krótko, a wyszło jak zwykle. Jest tyle rzeczy, którymi chce się z Wami podzielić, że wpisy się rozciągają, ale (przynajmniej mam taką nadzieję) mają przez to jakąś wartość dodaną, aniżeli tylko rozwój projektu. Zatem w kilku słowach opiszę, co chcę uzyskać, zaś mam nadzieję, że dzisiaj bądź jutro na GitHubie pojawią się pliki z dokumentacją.

Może od myślników będzie najczytelniej (to nie jest w żadnym porządku logicznym, po prostu co mi do głowy przychodzi na moment pisania tego posta):

I to chyba tyle jak na razie. Na pewno wszystko znajdziecie w dokumencie, który powstanie.

Tym czasem kończę, proszę o komentarze oraz udostępnianie mojego bloga! Dzięki temu będzie nas więcej! 🙂 Miłego dnia! 🙂

P. S. Postanowiłem bardzo spontanicznie, że będę się z Wami witał w różnych językach, tak dla frajdy 🙂

1 2 3