dr inż. Mateusz Smoliński

Komentarze

• ABArkadiusz Bryl - czw., 29 paź 2015, 16:25

  Witam,
  Poniżej wypunktowałem sugestie i uwagi podczas realizacji projektu i pisania raportu końcowego (mam nadzieję, że będą przydatne dla przyszłych słuchaczy):
  1. Osobiście wybrałem raport końcowy ale podsumowując ilość włożonej pracy, przeprowadzone badania i ilość tekstu jaka została przeze mnie napisana - powinna to być praca końcowa. A dlaczego wybrałem raport a nie pracę? Ano myślę, że tak zostało nam to pośrednio zasugerowane podczas edycji studiów, że część pisemna może być oddana w postaci raportu końcowego, który będzie opisywał w jaki sposób została zrealizowana część praktyczna – rzeczywistość okazała się inna. Dlatego warto już na początku omówić z promotorem co musi zawierać raport/praca końcowa.
  2. Warto przeczytać uważnie „sugestie” promotora dotyczące etapów i zasad przygotowania prac i raportów końcowych – ułatwi to pisanie, realizację oraz, co najważniejsze, akceptację pracy przez promotora.
  3. Szacowany czas pracy (łącznie 160-200 godz. roboczych co w moim przypadku, osoby pracującej i mającej dwoje małych dzieci, przełożyło się na około 2 miesiące):
  - Czas raportu końcowego: 80-100 godz.
  - Czas realizacji projektu: 80-100 godz.
  4. Promotor wymaga przedstawienia osobiście działającego rozwiązania co nie została dokładnie sprecyzowane podczas studiów. Dlatego też, warto pamiętać o tym fakcie i zaplanować spotkanie z promotorem znacznie wcześniej jeszcze przed oddaniem/skończeniem części pisemnej. Chyba nie muszę pisać dlaczego...
  5. Oddanie pracy nie polega tylko na umieszczeniu pliku na platformie WIKAMP i podpisaniu oświadczenia ale wymaga spełnienia kilku formalizmów, jak chociażby odpowiedniego podpisania płyt CD/DVD czy nawet opakowań… polecam osobiste oddanie pracy u promotora co znacznie ułatwia sfinalizowanie wszystkich formalności.
  6. Promotor „nie gryzie”, jest otwarty na pytania i służy pomocą dlatego w przypadku problemów/pytań warto zapytać i poprosić o pomoc.
  
  Życzę powodzenia podczas pisania pracy/raportu końcowego oraz realizacji projektu :-)
  
  Pozdrawiam,
  Arek
  Studia-Linux-ed.10
• GSGrzegorz Skuza - pon., 2 lis 2015, 09:59

  Witam,
  Podaje poniżej moje uwagi dot. realizacji projektu i pisania raportu końcowego w nadziej, iż będzie to przydatne dla przyszłych słuchaczy studiów podyplomowych ,,Nowoczesne aplikacje biznesowe Java EE”:
  1.Bardzo ważne jest przygotowanie sobie czasu na realizacje projektu oraz napisanie raportu końcowego. W moim przypadku zajęło mi to:
  - czas realizacji projektu: 120 – 140 godz. (pierwsza wersja implementacji powstała pod koniec lipca, końcowa wersja była gotowa w ostatnim tygodniu września),
  - czas realizacji raportu końcowego: 120 godz. (raport rozpocząłem pisać w początku sierpnia , skończyłem w ostatnim tygodniu października).
  2.Wybór tematu: ważne jest wybranie i określenie tematu oraz zakresu pracy, najlepiej miesiąc lub wcześniej przed końcem zajęć, co umożliwi nam określenie z promotorem pracy dokładnie co ma ona zawierać, musimy pamiętać że zbyt rozbudowana tematyka i zakres pracy uniemożliwi nam skończenie jej w terminie.
  3.Realizując temat pracy pamiętajmy, iż projekt zrealizowany przez nas może być naszą wizytówką która możemy wykorzystać w trakcie aplikacji na nowe stanowisko w IT.
  4.W tracie pracy polecam częsty kontakt (minimum raz na dwa tygodnie) z opiekunem projektu, pozwoli to na zaoszczędzić dużo czasu na poprawki lub rozwiązania implementacji czy raportu końcowego. Czas na konsultacjach można wykorzystać do przedyskutowania użytych rozwiązań w naszym projekcie lub na inne propozycje. Na poszczególnych etapach pracy na konsultacjach musimy omówić naniesione przez opiekuna poprawki do naszej pracy co pozwoli nam na szybsze skończenie pracy.
  5.Warto pokusić się na użycie w pracy końcowej innej technologii nieomawianej w trakcie studiów podyplomowych. W mojej pracy użyłem frameworków: Spring i Hibernate. Ale polecam ww. propozycję uzgodnić z opiekunem pracy oraz Kierownikiem Instytutu Studiów Podyplomowych.
  W trakcie seminariów dyplomowych można ten temat poruszyć, nasi wykładowy oraz Kierownicy Studiów Podyplomowych są otwarci na inne rozwiązania dot. języka Java.
  6.Chciałbym jeszcze wspomnieć o zebraniu literatury potrzebnej do realizacji projektu, nie polecam zasobów biblioteki Głównej Politechniki Łódzkiej. Korzystałem z niej, brak najnowszych źródeł i mała ilość sztuk dostępnych publikacji dot. programowania w języku Java (frameworka Spring i Hibernate). Proponuje w grupie studiów podyplomowych stworzyć bazę literatury i wymieniać się nią między sobą.
  7.Przed oddaniem pracy warto skonsultować z opiekunem pracy, w celu określenia co ma zawierać płyta CD/DVD oraz polecam osobiste oddawanie pracy u promotora co pozwoli nam na uniknięcie nieporozumień i sfinalizowanie końcowych formalności. Zalecam w tym przypadku o zabezpieczenie się w dodatkowe nośniki CD/DVD oraz oświadczenia, w przypadku naszych błędów możemy to naprawić w trakcie procesu oddawania pracy u promotora.
  Proces ten jest opisanym dokładnie na WIKAMP ale ww. wskazówki uważam za bardzo przydatne.
  8.Polecam szczególnie aktywność na seminarium dyplomowym oraz na zajęciach dot. projektu końcowego. Uważam, iż wykładowcy oraz Kierownictwo jest otwarte na nasze uwagi i potrzeby. Możemy liczyć na pomoc i rozwiązywanie naszych problemów dot. projektu końcowego.
  9.Mam prośbę do przyszłych studentów Javy aby wnosili o rozszerzenie toku studiów, o bardzo potrzebne frameworki Javy m.in. Spring, Hibernate.
  Osobiście Pan dr hab. Inż. Przemysław Ignaciuk na ostatnim naszym seminarium dyplomowym zadeklarował chęć pomocy w realizacji tej prośby studentów studiów podyplomowych.
  10.Innym pomysłem na znalezienie ciekawego tematu pracy i źródeł do jego realizacji jest uczestnictwo w różnych targach i imprezach IT organizowanych w naszym mieście przez Politechnikę Łódzką (targi pracy w kwietniu), Uniwersytet Łódzki (targi IT w końcu października) oraz innych np. firmy Cybercom Poland (maj br.).
  11.Warto również korzystać z informacji zawartej w Internecie, znajdziecie tam bardzo ciekawe artkuły dot. Springa, Hibernate czy programowania w Javie.
  Powodzenia podczas pisania pracy/raportu końcowego oraz pomyślnego zakończenia projektu.
  
  Pozdrawiam,
  Grzegorz
  Studia podyplomowe - edycja 4
  ,,Nowoczesne aplikacje biznesowe Java EE’’
• ASAndrzej Skolimowski - niedz., 22 lis 2015, 23:43

  Witam,
  Chciałbym się podzielić swoimi wrażeniami na temat studiów podyplomowych "Administracja systemami GNU/Linux" edycja 10.
  1. Zajęcia teoretyczno-praktyczne: Sama treść przekazanej wiedzy na zajęciach oceniam bardzo dobrze, natomiast czuje niedosyt zajęć praktycznych.
  2. Zaliczenia egzaminy cząstkowe: bardzo dobra forma utrwalenia wiedzy, dodatkowo mobilizuje do systematyczności.
  3. Raport końcowy (praca dyplomowa): czas poświęcony na cześć praktyczną to ok. 100-130 godzin, część teoretyczna ok. 110-150 godzin. Ale NIE ZRAŻAJCIE SIĘ, każdą wątpliwość wyjaśni Wam promotor. Na pewno jest to dobra forma zakończenia zajęć i zweryfikowania swojej wiedzy.
  4. Wykładowcy: znakomicie przygotowana kadra, każdy z nich to profesjonalista.
  Zachęcam do wyboru tego kierunku studiów podyplomowych i trzymam kciuki za następnych.
  Pozdrawiam
  Andrzej Skolimowski
• HMHalina Madej - wt., 1 gru 2015, 20:19

  Witam,
  poniżej opisałam moje doświadczenia/odczucia/problemy z jakimi spotkałam się podczas tworzenia raportu końcowego oraz samego systemu:
  1) W pierwszej kolejności warto zapoznać się z wymaganiami dotyczącymi tworzenia oraz oddawania pracy. Wymogi formalne, które trzeba spełnić faktycznie zajmują mnóstwo czasu. Przygotowanie raportu/oświadczenia/płyty CD/DVD zajmują wbrew pozorom naprawdę dużo czasu, a spełnienie wszystkich formalności, wymaga dużego skupienia i zaangażowania. Przedstawione wyżej "Etapy i zasady przygotowania prac i raportów końcowych dla studiów podyplomowych" okazały się bardzo pomocne.
  W jednym miejscu znalazło się całe kompendium wiedzy niezbędnej do ukończenia studiów. Dlatego gorąco polecam dokładne zapoznanie się oraz stosowanie do wymienionych wyżej zasad.
  2) Ponadto warto przygotowywać Instrukcję wdrożenia proponowanego systemu/aplikacji podczas faktycznego jego/jej tworzenia. Po czasie, dokładne odtworzenie jest zdecydowanie trudniejsze i bardziej pracochłonne.
  3) Warto dobrze zaplanować sobie realizację całego projektu i trzymać się ustalonego schematu. Łatwiej wówczas o systematyczność i duże postępy w pracy.
  4) Warto korzystać z możliwości spotkań na konsultacjach i zadawać nurtujące nas pytania.
  5) Nie przedstawiam dokładnego czasu realizacji projektu, gdyż tak naprawdę (przynajmniej u mnie) są to niezliczone godziny pracy - czytanie książek oraz forum, a także faktyczna implemantacja i raport końcowy.
  6) Warto na bieżąco (z zającia na zajęcia) przyswajać sobie i wykorzystywać w praktyce prezentowane podczas zajęć zagadnienia.
  7) Warto stawiać sobie realne cele (funkcjonalności proponowanego systemu/aplikacji dostosować do naszego doświadczenia, szybkości przyswajania informacji oraz posiadanego czasu).
  9) I jeszcze na koniec: WARTO CIĘŻKO PRACOWAĆ
  Każdemu polecam studia podyplomowe: Nowoczesne aplikacje biznesowe Java EE, również ze względu na duże zaangażownie i wiedzę wykładowców, które są niezwykle mobilizujące i pomocne podczas tworzenia pracy.
  Pozdrawiam,
  Halina Madej
  Studia podyplomowe: Nowoczesne aplikacje biznesowe Java EE - edycja 4
• SSSzymon Szumilas - śr., 16 gru 2015, 12:10

  Witam,
  chciałbym podzielić się swoimi doświadczeniami z pracy nad swoim system oraz pracy końcową:
  1.Przede wszystkim może napiszę coś, po czym posądzicie mnie o działalność "wywrotową", ale nawet jeśli po pierwszych tygodniach studiów macie już jakieś pomysły na stworzenie systemu - nie warto tego robić. Wiedza z zajęć w drugim semestrze "zburzy" dotychczasowy pogląd na tworzenie aplikacji i spowoduje, że będziecie ją musieli stworzyć praktycznie od początku. Warto jednak "bawić się" NetBeansem, GlassFishem, bo to one najczęściej sprawiają problemy - niepoprawne nazewnictwo, kłopoty ze startem serwera (uwaga: najlepiej zatrzymywać serwer GlassFish przed wyłączeniem systemu i unikać "uśpienia" komputera) i wiele innych, nad którymi spędza się całe godziny. Warto ćwiczyć na elementach tworzonych na zajęciach, a z tworzeniem szkieletu i logiki poczekać. Optymalnym momentem rozpoczęcia pracy nad docelowym systemem jest początek czerwca.
  2.W rozwiązywaniu wszelkich problemów ze środowiskiem/aplikacją znakomicie sprawdza się strona http://stackoverflow.com/ - warto korzystać z udostępnianych tam rozwiązań, ponieważ nie my pierwsi stykamy się z tymi problemami - wielu już to "przerabiało".
  3.Nie do końca precyzyjnie można określić czas potrzebny na realizację kompletnej pracy, bo związane jest to z wieloma zmiennymi,z których główne to wprowadzane poprawki, a to ile ich będzie zależy od rozplanowania funkcjonalności systemu i uwzględnienia jej w części teoretycznej. Moja rada - nie rozwijajcie dodatkowych funkcjonalności już na etapie projektowania, bo wtedy prawie pewne, że będziecie mieć zbyt wiele do zrobienia i w konsekwencji utkniecie. Warto zaplanować tylko podstawową funkcjonalność i starać się ją opracować w pełni - cały CRUD. Prawie w każdym przypadku, podczas jego pisania i testowania dojdziecie do wniosku, że pewnych funkcjonalności brakuje - zaimplementujcie je tylko wtedy, jak już jesteście pewni działania podstawowych elementów. Rozwinięty i skomplikowany, ale pełen błędów i niedoróbek system jest o wiele gorzej postrzegany niż system prosty, działający i niezawodny - chodzi o wykorzystanie wiedzy zdobytej na zajęciach i zaprezentowanie jej w możliwie prosty sposób - bez setek linii powtarzającego się kodu. Mimo wcześniej stworzonej części teoretycznej, po stworzeniu systemu będzie konieczność wprowadzenia zmian i jej uspójnienia - z pewnych narzędzi zrezygnujecie, wprowadzicie nowe elementy, zaprezentujecie elementy warstwy prezentacji itp.
  W moim przypadku na część teoretyczną poświęciłem ok. 100-120 godzin, a na część praktyczną ok. 100 nie wliczając godzin poświęconych na rozwiązywanie problemów z serwerem i "literówkami" w plikach konfiguracyjnych.
  4.Część pisemną pracy obejmującą wdrożenie i instrukcję użytkownika warto stworzyć już po ukończeniu pracy nad systemem, a najlepiej, już po zaakceptowaniu praktycznej części pracy. Polecam spróbować uruchomić stworzony system na zupełnie innym komputerze i krok po kroku rejestrować czynności, które należy wykonać, aby system zaczął poprawnie działać. W ten sposób niczego nie pominiemy - szczególnie takich elementów, które skonfigurowaliśmy "przy okazji" lub takie, które na początku robiliśmy ręcznie, a teraz są ustawiane automatycznie na podstawie tego, co stworzyliśmy.
  5.Warto ściśle przestrzegać procedury oddania pracy/zawartości nośnika i na zasadzie "check-listy", punkt po punkcie sprawdzać wszystkie elementy - mimo, że niektóre z nich mogą wydawać się zbędne. Dokumentacja musi być tak stworzona, żeby nawet nie wprawiona w pracę z podobnymi systemami osoba mogła łatwo uporządkować wszystkie informacje i zapoznać się z efektem pracy. No chyba, że chcecie nerwowo, "na kolanie" nagrywać płyty z poprawkami już przy samej procedurze oddania pracy.
  6.Mój osobliwy przypadek związany z koniecznością przedłużenia terminu oddania kompletnej pracy wskazuje, że przy założeniach i wyliczeniach warto jednak wziąć "poprawkę" na nieprzewidziane okoliczności, które sprawią, że jedynym momentem na spokojną pracę przed komputerem będzie 1 godzina dziennie - pomiędzy 1, a 2 w nocy. Przedłużenie nie jest komfortową sytuacją, chyba, że nie przeszkadza Wam piętno bycia ostatnimi w grupie, o którego wszyscy już pytają: "Przedłuża! Ten to chyba już nie da rady?". Do tego nerwowa sytuacja i wiele szczęścia, które będzie potrzebne, aby nadrobić stracony czas i w pośpiechu nie popełnić wielu prostych błędów.
  Pozdrawiam,
  Szymon Szumilas
  Studia podyplomowe: Nowoczesne aplikacje biznesowe Java EE - edycja 4
• GDGrzegorz Dybała - niedz., 17 gru 2017, 13:40

  Witam,
  chciałbym wskazać kilka najważniejszych moim zdaniem zasad koniecznych do wykonania i uzyskania oceny za pracę końcową:
  1. Zacząć wykonywanie jej jak najwcześniej, tzn. temat, założenia, wybór technologii oraz pierwsze scenariusze przypadków użycia muszą być znane i wykonane do końca maja.
  2. Zrealizowanie powyższego, będzie rozpoczęciem pisania dokumentacji raportu końcowego, czyli na pewno zostanie wykorzystane na pierwsze obowiązkowe seminarium.
  3. W czerwcu należy zacząć kodować i do końca miesiąca wykonać pełny CRUD, tak aby w okresie wakacyjnym nie mieć opóźnień z powodu urlopów i własnej mniejszej efektywność w tym czasie. Pomoc jest w tym okresie dużo większa, należy to wykorzystać, bo potem będziemy żałować !
  4. Należy korzystać z przykładów z zajęć, przy czym należy pamiętać, że nawet te same wersje SampleWebShop mogą mieć różne bardzo ważne dodatki w zależności od zajęć, np. dodatkowy kod z obsługi błędów lub mechanizmu blokad optymistycznych a także walidacji.
  5. Proponuję skupić się na jednym, maksymalnie dwóch przykładach prac końcowych, po wcześniejszym ogólnym przejrzeniu wszystkich propozycji - chodzi o oszczędność czasu oraz wrażenie, że zbyt dużo przykładów może spowodować trudności w wyborze i kolejnym kroku naprzód. Czytanie przykładów nie jest wytłumaczeniem na brak aktywności.
  6. Nie należy rozbudowywać aplikacji, bo każda kolejna funkcjonalność "ponad wymagania" zabiera czas i komplikuje postępowanie w następnych etapach, które muszą być wykonane z uwagi na cele postawione przez oficjalne formalne wymagania konieczne do zaliczenia.
  7. W związku z powyższym, jak najczęściej należy konsultować się z Promotorem. Nabyta na konsultacjach wiedza i doświadczenie, to w pewnym sensie, jak praktyki w firmie. Na pewno czas ten jest niesamowicie cenny pod kątem szybkiego podnoszenia wiedzy oraz polubienia pracy z kodem. Podkreślę: bo to jest praktyczny czas pracy z kodem.
  8. Konsultacje dla mnie to bardzo ważne praktyczne doświadczenie i polecam każdemu współpracę z Promotorem, a jeśli jest okres urlopowy, absolutnie nie należy zwalniać, ale poprosić innych wykładowców. Okres urlopowy nie jest argumentem na brak naszej aktywności oraz wytłumaczeniem braku zmieszczenia się w terminie.
  9. Do końca sierpnia powinna być wykonana aplikacja, a ew. końcówka np. obsługa błędów powinny być zrealizowane do końca pierwszego, maksimum drugiego tygodnia września. Jeśli aplikacja nie będzie gotowa do połowy września, to są bardzo małe szanse na zakończenie pracy w terminie.
  10. Od początku września należy kontynuować pisanie dokumentacji raportu końcowego. Ponieważ będzie co-najmniej kilka poprawek, dokument należy wgrać do oceny, startując z jego publikowaniem nie później niż w połowie września, jeśli chce się zakończyć pracę w terminie. Inaczej - moim zdaniem - tylko się będziemy denerwować, a naprawdę nie będzie szans na zmieszczenie w czasie. Poprawki mogą zająć 2 tygodnie (jeśli wszystko jest zrobione jak w przykładach i aplikacja miała już wszystkie wymagane funkcjonalności !), ale normalny czas na dokumentację to nawet 1,5 miesiąca, bo tak wiele rzeczy wychodzi jeszcze do zrobienia.
  11. Procedury oddania raportu/pracy końcowej mogą zaskoczyć, więc należy płytę oddać Promotorowi co-najmniej 2 dni wcześniej i przy założeniu, że przed tym terminem było omówione, co i jak ma być oddane. Na pewno nie należy podawać w ostatnim dniu do sekretariatu lub pocztą, bo to jest proszenie się o brak akceptacji naszej pracy z powodu niedoczytania wszystkich szczegółów formalnych.
  ---
  Podsumowując: nie należy czekać i odkładać, ale starać się zrobić nawet wcześniej wg planu, a na pewno warto i polecam korzystanie z konsultacji wykładowców.
  Pracę końcową należy wykonać, bo to jest bardzo cenne doświadczenie oraz możliwość uzyskania pisemnego poświadczenia nabytych ważnych na rynku pracy kompetencji !
  Powodzenia !
  Grzegorz Dybała
  Studia podyplomowe: Nowoczesne aplikacje biznesowe Java EE - edycja 6
• RORobert Olejnik - pon., 5 lut 2018, 10:11

  Dzień dobry, jestem absolwentem studiów podyplomowych - edycja 12 i chciałbym przedstawić swoje odczucia co do realizacji raportu końcowego.
  Pracę udało mi się oddać w terminie dodatkowym i to w ostatnim jego dniu, oczywiście takiego scenariusza nie brałem pod uwagę. Myślę, że przyczyną takiej sytuacji była zbyt duża pewność siebie, marginalizowanie pewnych sytuacji problemowych związanych z zadaniami z podręcznika, oraz braku systematyczności polegającej zaniechaniu testowania ich w środowisku wirtualnym.
  W trakcie pisania raportu końcowego natrafiłem na problem z usługą katalogową i integracją autoryzacji z innym systemem. A więc cały plan i optymistyczna wersja pisania raportu końcowego legła w gruzach. Poszukiwanie błędu konfiguracji , zmieniające się wersje oprogramowania, przeciągały cały proces. Nie powiem Państwu ile czasu spędziłem nad raportem ale brak wiedzy na temat problemu spowodował, że każdą wolną chwilę poświęcałem na jego rozwikłanie. Dziesiątki testowych maszyn wirtualnych, rozpisanych instrukcji i metod, godzin spędzonych w sieci szukając rozwiązania – tak można opisać ostatnie tygodnie, gdzie w godzinach nocnych i w akceptowalnej ciszy realizował się plan ukończenia raportu końcowego.
  Teraz czuję pewnego rodzaju satysfakcję z podjętego trudu, również z tego że zrealizowany projekt jest obecnie wdrażany w moim miejscu pracy, a całość dopina fakt, że będąc już absolwentem studiów podyplomowych „Administracja systemami GNU/Linux” otrzymuję zaproszenia od firm IT z propozycją współpracy co jest bardzo miłe. Pomimo tego że było ciężko, warto przedzierać się przez zawiłości konfiguracji systemu aby doświadczyć takiej chwili.
  Poniżej zamieszczam kilka punktów związanych z realizacją raportu końcowego, które z perspektywy czasu wydają mi się ważne:
  - starać się testować wszystkie listingi z podręcznika poznanych technologii. Pozwoli to na wcześniejsze wyeliminowanie niejasności związanych z konfiguracją w systemie. Co ważne, prowadzący zawsze służą pomocą przy wyjaśnieniu problemu.
  - wybór tematu w moim odczuciu powinien być ustalony wcześniej , aby móc się z nim „oswoić”, przejrzeć dostępną dokumentację, literaturę. Najlepiej gdy studia jeszcze trwają wtedy jest możliwość dopytać promotora co taki raport powinien zawierać. Bardzo dobrą propozycją politechniki jest zasób elektronicznych pozycji - NASBI
  - część praktyczna musi być udokumentowana w postaci teoretycznej/raportu, pamiętajmy aby zachowywać jak największą liczbę działających komend czy całych listingów z konfiguracji systemu, które później będą tworzyły pewnego rodzaju ciągłość realizacji krok po kroku. Sama część praktyczna to nie wszystko. Ostateczna wersja raportu musi być przejrzysta i zawierać konkretne informacje na temat wdrożenia systemu. Poszczególne listingi konfiguracji systemu muszą posiadać stosowny opis. Na stronę merytoryczną raportu również trzeba poświęcić sporo czasu realizując dział po dziale według przygotowanej wcześniej makiety raportu.
  
  Z tego miejsca chciałem bardzo podziękować całej kadrze wykładowców oraz mojemu promotorowi Panu dr inż. Mateuszowi Smolińskiemu za pomoc w realizacji raportu końcowego. Natomiast Państwu sił i motywacji do działania bo to nie jest prosta sprawa jak na początku może się wydawać. Powodzenia.
  Robert Olejnik.
  Studia podyplomowe: Administracja Systemami GNU/Linux. Edycja 12, 2016/2017 r.
  
• AIAnna Izydorczyk - czw., 5 gru 2019, 19:16

  Poniżej znajdują się moje przemyślenia, które są efektem realizacji projektu końcowego w ramach studiów podyplomowych Nowoczesne aplikacje biznesowe Java EE, edycja 8.
  CZĘŚĆ PRAKTYCZNA:
  • Warto mieć pomysł na aplikację jak najwcześniej, pozwoli to uniknąć paniki w czerwcu. Nawet jeśli sam temat się później zmieni pewne cechy aplikacji pozostaną podobne.
  • Program, który będzie budowany powinien być zgodny z posiadaną wiedzą i doświadczeniem na tyle, żeby reguły biznesowe miały odzwierciedlenie w rzeczywistości.
  • Zaplanować co aplikacja ma robić, jakie dane mają być przechowywane w bazie, uwzględnić dane typu logicznego (boolean), które znacznie ułatwiają tworzenie warunków oraz zapytań JPQL. Dobry plan skraca czas wykonania o tyle, ile czasu zabrałyby poprawki.
  • Lepiej zaplanować mniejszy, ale funkcjonalny program, niż większy, ale niedopracowany. Dodatkowe przypadki użycia można zaimplementować jeśli zostanie czas, kiedy plan minimum został w pełni wykonany. Obsługa błędów zajmuje całkiem sporo czasu, co również trzeba mieć na uwadze.
  • Implementację warto zacząć od przypadków użycia dotyczących kont użytkowników, ponieważ jest to część wspólna wszystkich aplikacji, warto konsultować się i współpracować z innymi słuchaczami przy tworzeniu pierwszego CRUDa.
  • Nie wymyślać wszystkiego od zera, korzystać z przykładów z zajęć oraz gotowych rozwiązań dostępnych w sieci.
  • Nie kodować do ostatniej chwili, na dokończenie raportu potrzeba przynajmniej dwóch tygodni!
  RAPORT KOŃCOWY:
  • Dokładnie zapoznać się i spełnić wymagania opisane w procedurze przygotowania i oddania pracy końcowej!
  • Rzetelnie i terminowo przygotowywać kolejne wersje raportu lub pracy końcowej. Niezwłocznie poprawiać sprawdzone przez opiekuna wersje pracy, zgodnie z przekazanymi przez niego sugestiami.
  • Po poprawieniu wersji 0.5 raportu przemyśleć i krótko opisać to co musi zostać zawarte, dłużej to co jest ciekawe, co projekt wyróżnia. Na listingach zaprezentować kod zawierający jak najwięcej zastosowanych rozwiązań, do których będzie można odnieść się z różnych rozdziałów pracy końcowej.
  • Kod w formie listingów warto zamieszczać w raporcie już po zaliczeniu części praktycznej u opiekuna pracy.
  OGÓLNIE:
  • Zapoznać się z wymaganiami! Ewentualnie poprosić o doprecyzowanie i spisanie wszystkich wymagań dotyczących projektu końcowego – o niektórych dowiedzieliśmy się ustnie od opiekuna pracy niedługo przed końcem terminu złożenia pracy końcowej.
  • Korzystać z konsultacji w okresie wakacyjnym nie tylko u opiekuna pracy, ale także u innych wykładowców.
  • Na konsultacje można przychodzić grupowo gdyż problemy we wszystkich projektach są podobne, a opiekun nie musi każdemu osobno tłumaczyć tego samego.
  • Pisać na forum grupy o problemach, których nie udało się samodzielnie rozwiązać – być może ktoś inny sobie z podobną sytuacją poradził.
  • Robić na bieżąco notatki z przemyśleniami co jest do zrobienia lub do poprawy. To bardzo ważne żeby o niczym nie zapomnieć, a po wykonaniu zadania można odhaczyć punkt
  Realizacja projektu końcowego zajęła mi sporo czasu. Dokument w postaci raportu z projektu końcowego około 140-150 godzin wraz z obróbką rysunków, rzutów ekranu, diagramów, tabel. Implementacja systemu nawet dwa razy dłużej, czyli około 300 godzin, z czego wiele godzin poświęciłam na sprawdzanie zastosowanych rozwiązań, wprowadzanie poprawek, obsługę błędów, itp.
  Dzięki wsparciu i cennym radom mojego opiekuna, dr inż. Mateusza Smolińskiego udało mi się zakończyć projekt z wynikiem pozytywnym, czego również życzę osobom z kolejnych edycji studiów podyplomowych.
• s-słuchacz14 --- - czw., 27 sty 2022, 21:21

  Jestem studentem edycji 11 studiów podyplomowych spjava_e11. Moją pracą dyplomową jest “System wspomagający zakup sprzętu komputerowego”. Tylko sklep i aż sklep.
  Aby zbudować system w wymaganym czasie dobrze wprowadzić rygor, który będzie jednocześnie wyzwaniem dla naszego stylu życia:
  
  Przerabiać w tygodniu każde weekendowe zajęcia (same testy nie wystarczą): pisać kod!
  
  Uczestniczyć aktywnie w zajęciach pisząc kod równo z prowadzącym - mózg się uczy i później jest łatwiej.
  
  Wypoczywać aktywnie minimum jeden dzień w weekend bo to mózg musi odpocząć, a pół godziny w poniedziałek z kodem jest znacznie wydajniejsze niż cała… niedziela.
  
  Przerobić trochę materiału np: z javastart ale… pisząc kod!
  
  Pisząc pracę zostawić na ostatni miesiąc “zabawę” z PrimeFaces, Lombook itp. Dodając to do gotowej pracy zaoszczędzicie mnóstwo dodatkowego czasu.
  
  Wszystkie nadmiarowe elementy systemu typu: system zarządzania bazami PostgreSQL, praca w Intellij (na zajęciach mieliśmy NetBeans) tylko oddalają Was od osiągnięcia celu: napisania pracy w terminie.
  
  Ambitnie można podejść do tematu stosując dodatkowe elementy, które zawiera przykładowy SampleShop typu: dziedziczenie w klasach encyjnych, @SecondaryTable czy rozwiązania użyte w budowie i przeszukiwaniu kont wzorcowego programu.
  
  Początkowo dużym rozczarowaniem było dla mnie to, że nie mogłem zbudować kompletnego systemu i zostałem “ograniczony” ilością przypadków użycia. Zapewniam jednak, że po skończeniu pisania wersji 1.0 można spokojnie dodać w tydzień wszystkie brakujące funkcjonalności - tak duży poziom już sobą reprezentujemy.
  
  Bardzo ważne zajęcia to w moim odczuciu zajęcia podsumowujące WZP06 podczas których budowana jest nowa aplikacja w kierunku od bazy danych do frontendu. Jednak polecam zacząć od tego co ma się wyświetlać użytkownikowi.
  
  Przykładowy SampleShop da się uruchomić, da się w nim kilka rzeczy wyklikać ale jest niekompletny: zostały z niego usunięte niektóre elementy ale jednocześnie jest rewelacyjnym przykładem jak w programowaniu w Javie daną rzecz można zrobić na wiele różnych sposobów. Polecam pisanie pracy tylko na podstawie SampleShopa ze względu na to że zawiera wszystkie wymagane elementy aplikacji warstwowej.
  
  
  Jednym z drażliwych tematów był brak Springa… Myślę, że to bardzo trudny framework i zrozumiały dopiero po napisaniu kompletnej pracy. Inny ciekawy temat to to, że uczymy się JavaServer Faces, Bootsfaces czy Primefaces, które są starymi technologiami. No niby tak ale ta technologia jest najłatwiejsza do implementacji dla nas i znacznie ułatwia wyświetlanie danych w ładnej formie. No i nadal jest używana przez sporo stron internetowych.
  
  
  Na koniec tylko wspomnę: Soteria na pewno działa, a jak nie działa to na 99,9% jest gdzieś Null Pointer Exception po drodze… po prostu sout Waszym przyjacielem w każdej wywoływanej metodzie.
  
  Co do firm, które się odezwały: są to znane, duże firmy, które chcą inwestować w pracownika nie tylko czas swoich seniorów, ale także zasoby w postaci darmowej nauki angielskiego w trakcie pracy.
  
  Życzę Wam powodzenia oraz wytrwałości przy pisaniu pracy i radości w jej oddaniu na tydzień przed terminem!
• OROleksandr Radiuk - wt., 13 gru 2022, 11:08

  Witam,
  Jestem studentem edycji 12 studiów podyplomowych.
  Podaje poniżej moje uwagi dot. realizacji projektu i pisania raportu końcowego:
  - Przerabiać w tygodniu weekendowe zajęcia: niestety, ale taka jest prawda, w programowaniu ważna jest praktyka. Możesz przeczytać 100 książek np. o Java czy o JS, a jak usiądziesz po nich pierwszy raz do pisania kodu to uwierz mi... możesz mieć problem nawet z poprawnym Hello World.
  - Dodatkowo przerobić trochę materiału np:
  https://www.freecodecamp.org/news/learn-java-free-java-courses-for-beginners/
  https://www.learnjavaonline.org/
  https://exercism.org/tracks/java
  https://medium.com/javarevisited/10-best-places-to-learn-java-online-for-free-ce5e713ab5b2
  - Raport końcowy (praca): czas poświęcony na cześć praktyczną to ok. 250-300 godzin, część teoretyczna ok. 150-200 godzin.
  - Gdybym mieliście jakieś wątpliwości to promotor „nie gryzie”, zawsze chętnie pomaga.
  - Warto przeczytać sugestie promotora dotyczące etapów i zasad przygotowania prac i raportów końcowych – ułatwi to pisanie, realizację oraz, co najważniejsze, akceptację pracy przez promotora.
  
  Życzę powodzenia podczas realizacji projektu ;)
• RARafał Augustyniak - wt., 14 lis 2023, 18:38

  Witam, ukończyłem trwającą od listopada 2022 do listopada 2023 (w formule zdalnej) edycję 13. studiów podyplomowych „Nowoczesne aplikacje biznesowe Java/Jakarta EE”. W moim przypadku realizowany poza aplikacją był raport końcowy. Niestety, mimo wstępnych planów, koniec końców nie mierzyłem czasu spędzonego nad rozwojem aplikacji i pisaniem raportu – luźna estymacja to 130h na wytwarzanie oprogramowania oraz 90h na raport końcowy. Podobnie jak moi poprzednicy, których wypowiedzi z poprzednich lat widzimy powyżej, zamieszczam kilka rad i obserwacji dla przyszłych słuchaczy.
  
  1. Warto trzymać się sugerowanych terminów i zaproponowanych kamieni milowych przygotowania pracy końcowej. Przykładowo, nawet jeżeli zdajemy sobie sprawę, iż treści które przygotowujemy w raporcie końcowym w kontekście wersji 0.5 ulegną istotnym modyfikacjom do wersji ostatecznej, to później ich szybki przegląd wraz z aktualizacją pójdzie szybko, w przeciwieństwie do pisania wszystkiego naraz na ostatnią chwilę. Wersje cząstkowe są bardzo dobrym motywatorem do regularnej pracy. Podobnie zresztą jak konsultacje z opiekunem – one również pomagają podtrzymać systematyczność. We własnym interesie warto być na nie przygotowanym, tj. mieć przemyślaną listę pytań i zagadnień, jakie chcemy poruszyć w umówionym terminie. W moim wypadku sierpień był miesiącem najmniejszego postępu od rozpoczęcia tworzenia pracy do jej zakończenia, zapewne spowodowane to zostało mniejszą motywacją po mojej stronie związaną z brakiem terminów kamieni milowych oraz ustalonych spotkań z opiekunem w tym miesiącu. Dodam jeszcze, że w moim wypadku aplikacja i raport końcowy powstawały dość równolegle – przynajmniej od momentu osiągnięcia wersji 0.5, numeracja wersji raportu i aplikacji szły dość synchronicznie. Piszę o tym, gdyż z poprzednich komentarzy mogło wynikać, że najpierw wytwarzana była aplikacja, a dopiero po jej finalizacji raport końcowy.
  
  2. Powtórzę mniej więcej to, co już się pojawiało w komentarzach z poprzednich lat. Niech wasz projekt nie będzie ‘kolosem na glinianych nogach’. Planujcie aplikację skromną i schludną. Sytuacja i tak się pewnie zdąży skomplikować nawet dla wydawać by się mogło prostego projektu. Jak ktoś pofolguje za bardzo wodzom wyobraźni na etapie projektowania ogólnego zarysu aplikacji, to może skomplikować sobie życie. Osobiście wyszedłem z założenia, że aplikacja ma być jak najprostsza spełniając zarazem wymagania, zaplanowałem projekt obejmujący cztery poziomy dostępu i około dwadzieścia przypadków użycia. Konsultacje z opiekunem pozwoliły upewnić się, że zmierza to w dobrym kierunku – warto oczywiście omówić naszą wizję, opiekunowie zasugerują jeżeli czegoś istotnego nam brakuje, bądź jeżeli zaplanowaliśmy coś zbyt zaawansowanego. Samo wybranie tematu w moim wypadku miało miejsce jakoś pod koniec maja. Myślę, że był to właściwy czas na tę decyzję. Warto przejrzeć udostępniane przez prowadzących prace końcowe z poprzednich lat i na ich podstawie przeanalizować jaki temat będzie dobrze wybrać.
  
  3. Morale w czasie studiów zmieniało się nieco sinusoidalnie – bywało lepiej i gorzej. Najmniejsza pewność siebie przypadała w moim wypadku chyba mniej więcej na połowę drugiego semestru (okolice kwietnia), kiedy następowało pewne zagubienie i ciężkim zagadnieniem wydawało się jak następujące po sobie tematy uda się zespolić na potrzeby wytwarzania projektu końcowego.
  
  4. Ważnym momentem do przezwyciężenia niepewności opisanej w punkcie wyżej były warsztaty końcowe. W naszej edycji były one postaci dwóch dni zajęciowych (w drugiej połowie czerwca, na niedługo przed końcem zajęć), obejmujących utworzenie od zera pewnej wczesnej fazy aplikacji w duchu wymaganej aplikacji końcowej. Oczywiście na dwóch zajęciach aplikacji takiej jak końcowa się nie stworzy, ale może powstać prosty system oferujący na przykład generalny CRUD. Na podstawie komentarzy stąd wiedziałem, żeby zwrócić szczególną uwagę na tę zajęcia. Potwierdzam, pozwalają one ‘ustawić się w blokach startowych’ jeżeli chodzi o pisanie własnej aplikacji końcowej. Możliwe, że prowadzący zajęcia poprosi przed tymi zajęciami grupę o zaproponowanie tematu aplikacji, jaką będziemy ‘na szybko’ wspólnie wytwarzać. Należy wówczas zgodnie z rekomendacją się zastanowić i przed zajęciami ustalić z resztą grupy jedną lub kilka propozycji – tak, ażeby czas tych zajęć przeznaczać na wspólne konfigurowanie projektu i kodowanie, nie na wydłużające się rozważania i planowanie.
  
  5. W którymś momencie studiów zostanie otwarta w kursie aktywność służąca do wyboru opiekuna pracy końcowej. W przypadku edycji w jakiej brałem udział, miejsca u części opiekunów dość szybko zostały pozajmowane. Osobiście nie dokonałem pośpiesznego wyboru i trafiłem do opiekuna, u którego zostały wolne miejsca – do dr. inż. Mateusza Smolińskiego. Jestem jak najbardziej zadowolony ze współpracy i wsparcia, jakie otrzymałem przy tworzeniu pracy końcowej. Najważniejsza jest własna systematyczna praca, wierzę że jeżeli tego nie zabraknie to pod opieką każdego z prowadzących uda się doprowadzić kwestię pracy końcowej do szczęśliwego finału.
  
  6. IT to dobry kierunek rozwoju. Jeżeli jesteś na tych studiach i czytasz te komentarze, a nie spędzasz czasu w sposób bezproduktywny, to duża szansa, że robisz to dobrze. Powodzenia!