(zakończony)Warsztat 17: etap 05: OPROGRAMOWANIE aplikacji TRENINGOWEJ oraz EGZAMINACYJNEJ

Hej

Otwieram (ten) etap nr 5 produkcji  warsztatu o nazwie "OPROGRAMOWANIE aplikacji TRENINGOWEJ oraz EGZAMINACYJNEJ".

Na poprzednim etapie na forum uzgodniliśmy że będą to aplikacje:

• aplikacja treningowa/warsztatowa: system odprawy pasażerów na lonisku
  
• aplikacja egzaminacyjna: system obsługi inteligentnego domu.
  

Czekam na zgłoszenia chętnych desperatów którzy podejmą się napisania jednej z powyższych aplikacji (czy nawet obu!). W poprzednim warsztacie tworzyłem specyfikację tych programów. Teraz jednak zmienię podejście - nie ma specyfikacji. Autor aplikacji oprogramuje ficzery w tych aplikacjach wg własnego uznania. Musi mieć tylko na uwadze, aby nie "szarżować" tzn starać się aby aplikacja była jak najprostsza (posiadająca tylko te ficzery które pokryją program warsztatu 17 (czytajcie listę zagadnień na samym dole dokumentu z tego linka):  https://docs.google.com/document/d/1u-AvfcWESsbD04oKTQK043xIJLarh3L8hHelFYKq0X0/edit?usp=sharing )
Aha i jeszcze jedno ! : trzeba je zrobić w WinForms !

Ktoś kto rozważa utworzenie tych aplikacji a ma jakiekolwiek wątpliwości co do ich specyfikacji (np. nie wie , jak zacząć :p) niech zacznie po prostu od zadawania tu pytań.

Autor wyśle potem gotowe aplikacje do mnie, ja je opublikuję i w kolejnych etapach inni uczestnicy będą się na nich wyżywać (punktować autora gdzie i co ma poprawić)

będzie fun ! ;p

To czekam na zgłoszenia odważnych (kto napisze którą aplikację ??)

Hej.

W sumie korci mnie napisanie którejś z aplikacji ale boję się, że za bardzo poniesie mnie fantazja i będzie to trochę zbyt rozbudowane. Mógł bym poprosić o rozwinięcie jak miała by działać aplikacja egzaminacyjna?

Ja moge sprobowac napisac program do oodprawy na lotnisku, tylko nie wiem ja bardzo ma byc rozbudowany programik i jaki zakres materialu ma zawierac. Czy ma byc zawarta lista lotow oraz lista pasazerow z mozliwoscia przypisywania pasazera do danego lotu? Czy jakos inaczej ma to wygldac?

Cześć,
tez mogę napisać system do obsługi iteligentnego domu.

Super, dzięki za odzew !

A więc moja propozycja jest taka, wg kolejności zgłoszeń:

• polkom21 napisze system odprawy pasażerów
  
• cygnus system sterowania domem
  
• Coffeina: na razie nic, ale będzie 1szym rezerwowym 
  

Co do tego jak mają wyglądać te aplikacje, to rzeczywiście przyda się Wam jednak jakakolwiek specyfikacja tych aplikacji (żebyście mieli na czym się oprzeć). W takim razie potrzebuję jeszcze trochę czasu, obiecuję że specyfikacje tych systemów (+ info do Was) "wypłodzę" gdzieś do czwartku. Założenie będzie takie, że taka specyfikacja będzie moją propozycją, ale w trakcie pisania aplikacji nie będziecie musieli wcale się do niej stosować, bo w trakcie pracy będziecie mieli własne wnioski gdzie moja specyfikacja okazała się "nietrafiona". ... i tak w kolejnych etapach produkcji laborki (np. kontroli jakości Waszego kodu) , kolejni uczestnicy zaczną Wam wysyłać kolejne sugestie poprawek oraz zmiany sposobu działania Waszych aplikacji.

To czekajcie proszę na mój sygnał , gdzieś do czwartku, dzięki !

Przygotowałem dla Was specyfikację (sorry za treść, pisałem "na kolanie" ;p ). Jest na naszym gdrive (w gałęzi "produkcja warsztatów" --> warsztat 17 --> etap 5) , ale daję Wam tu bezpośredniego linka:
https://docs.google.com/document/d/1JGFVG8_HaADBdMze3lN0L6x8jntwzwJ32YHQO8ueA-g/edit?usp=sharing

A więc polkom21 (odprawa pasażerów) i Cygnus (sterowanie domem)  do dzieła :p  !!!!!
Musze Was prosić, abyście sprężyli poślady i machnęli to jak najszybciej (powiedzmy w tydzień ??) , bo każde opóźnienie to opóźnienie całej produkcji laborki. Po wykonaniu całej akcji natomiast (na dalszych etapach wprowadzeniu poprawek zasugerowanych przez uczestników i zaakceptowanych przez Was) ... możecie sobie dać tyle odpoczynku (nawet 100 lat ;p ) ile chcecie przed podjęciem się kolejnego "zadania dodatkowego" w "Madagaskarze"

powodzenia ! (czekam na Wasze ver 1 aplikacji, możecie wysłać np. mailem).

Oczywiście strzelajcie tu pytaniami/wątpliwościami dot. specyfikacji

Hej,
no to ja zacznę strzelać
1. Czy trzecie okno też ma być TichTextBoxem tak jak dwa wcześniejsze, czy mogą być dane szczegółowe o urządzeniach wyświetlane na labelach?
2. Napisałeś w specyfikacji żeby zrobić metodę obliczającą pobór energii, czy to ma być informacja pokazująca się w messageBox czy gdzieś obok przycisku?
3. Rozumiem, że nie robić wywoływania dodatkowych formatek tylko wszytko umieścić na jednej formatce?

Na tą chwilę to bym miał tylko tyle pytań

Cygnus napisał:Hej,
no to ja zacznę strzelać
1. Czy trzecie okno też ma być TichTextBoxem tak jak dwa wcześniejsze, czy mogą być dane szczegółowe o urządzeniach wyświetlane na labelach?
2. Napisałeś w specyfikacji żeby zrobić metodę obliczającą pobór energii, czy to ma być informacja pokazująca się w messageBox czy gdzieś obok przycisku?
3. Rozumiem, że nie robić wywoływania dodatkowych formatek tylko wszytko umieścić na jednej formatce?

Odpowiedź na wszystkie 3 Twoje pytania brzmi:
to jest Twoja decyzja: zdaje się na Twój dobry gust ;p frontendowca .

I tak uczestnicy być może zaczną Ci wywracać do góry nogami kod/architekturę/UI Twojej aplikacji (a jeżeli będą mieli dobre pomysły, to oczywiście warto je będzie wdrożyć).

To samo więc tyczy się logiki - możesz wymyśleć zupełnię inną organizację klas i obiektów , moja specyfikacja jest tylko propozycją (pobudzającą myślenie) , niekoniecznie wytyczną ... możesz się też kurczowo trzymać mojej specyfikacji (Twoja decyzja panie inżynierze )

Jeszcze mam kilka pytań.

1. W tym programie ładowanie danych ma być zrobione w kodzie bez dodatkowych formatek?
2. Rozumiem, że dictionary można użyć skoro były w warsztacie 14?
3. Czy klasa home ma być klasą dziedzicząca po formie (formatka) czy to ma być osobna klasa?

Cygnus napisał:Jeszcze mam kilka pytań.

1. W tym programie ładowanie danych ma być zrobione w kodzie bez dodatkowych formatek?
2. Rozumiem, że dictionary można użyć skoro były w warsztacie 14?
3. Czy klasa home ma być klasą dziedzicząca po formie (formatka) czy to ma być osobna klasa?

Ad.1 Nie wiem czy dobrze zrozumiałem pytanie. Ale tak ! ;p Staraj się logikę aplikacji maksymalnie odseparować (na ile się da) od strony wizualnej czyli od formatek.
Ad.2.Oczywiście można, ale jeżeli np. maż na uwadze dictionary typów urządzeń i ich mocy , to rozważ po prostu użycia kolejnej klasy --> obiektów (jeżeli dojdzie tam 3-cie pole)
Ad.3. Nie !!!! (o ile dobrze zrozumiałem pytanie), ma to być niezależna klasa bez komend formatkowych w środku. Tak jak w w16 - staraj się odseparować logikę aplikacji od formatek (na razie bez użycia np. interfejsów związanymi z wzorcami projektowania), tak aby hipotetycznie można było w miarę szybko zrobić wersję konsolową (na razie nie robimy) tej samej aplikacji , wykorzystująć jak najwięcej klas/obiektów którę obsłużą logikę działania aplikacji

Moje wszystkie 3 odpow. mogą okazać się błędne , jak w kolejnym etapie pozostali uczestnicy zabiorą się za kontrolę jakości Twojego kodu.

Tu znajdziecie kod mojej aplikacji. Jest on jeszcze udoskonalany więc to nie jest jeszcze finalna wersja ale jeżeli ktoś chce ocenić i wytknąć co jest jeszcze nie tak to proszę bardzo. W pliku readme jest link do pobrania aplikacji. Sama aplikacja już działa ale jeszcze potrzebna jest mała optymalizacja i parę poprawek w kodzie.

Polkom21, daruj że się miotam z koncepcją (ciągle docieram procedurę produkcji laborki) - zróbmy inaczej.

Execa którego mi posłałeś umieściłem tutaj (gdrive --> "Madagaskar" --> "produkcja warsztatów" --> "w17" --> "etap5" ...) : 
https://drive.google.com/folderview?id=0ByEDbuEU88x4fnVsUUpKS08zQzUwaTh4VW4yX3NiQ0sxRTFqUDYxNEVIWm5DbjZuRk85LUE&usp=sharing

Masz dostęp write do folderu "odprawa pasażerów...", więc będziesz mógł zakładać kolejne podfoldery i umieszczać kolejne wersje Twojej aplikacji.
Analogicznie , Cygnus ma dostęp "write" do folderu "inteligentny dom...".

Teraz gorąca prośba (nowość dla Was) do polkom21 i Cygnus.  Nie udostępniajcie kodu ! (na tym etapie produkcji) ale tylko i wyłącznie część uruchomieniową Waszych aplikacji (albo instalkę albo po prostu execa). Jeśli możesz polkom21 to wygaś linka do kodu Twojej aplikacji z Twojego poprzedniego posta (ew. zaktualizuj jego treść).

Na tym etapie dogadujmy tylko działanie (oraz UI) Waszych systemów. Kod natomiast będziemy dogadywać w kolejnym etapie (gdy już dogadamy wygląd/działanie Waszych aplikacji), gdzie zaprzęgnę jak najwięcej programistów do zgłaszania opinii.

Jutro zgłoszę uwagi do Twojego kodu (zadecydujesz, czy wdrożysz) , oczywiście resztę też zapraszam do zgłaszania uwag.

@Polkom21
A niech tam , zgłaszam uwagi już teraz do Twojej aplikacji z exec'a: 
https://drive.google.com/file/d/0ByEDbuEU88x4RjJBa1RiSTZyamc/view?usp=sharing

Moje uwagi:

• Jak próbuję nacisnąć "flight " samolotem to w wielu przypadkach leci mi exception (ale rozumiem że to kwestia doszlifowania Twojej aplikacji.
  
• masz tam polskie nazewnictwo . Stosuj (w miarę swoich możliwości) tylko angielskie Tto się tyczy również kodu. Nie stresuj się ew. błędami j.angielskiego ... nasz redaktor (tlawryn) znowu na końcu weźmie Twoje anglojęzyczne słownictwo kodu oraz UI w obroty (na dalszym etapie produkcji aplikacji).
  
• Ja bym komendy typu flight, checkin, calculate weight itd. nie umieszczał w menu górnym To jest wg mnie nieintuicyjne dla użytkownika który zwykle jest przyzwyczajony do tego że menu górne systemów służy do nawigowania po systemie a nie do odpalania konkretnych akcji
  
• fajnie że użyłeś drzewa (to chyba ma sens)
  
• Nie wyświetlasz detali wybranego pasażera (jego id, wagi itd), więc :
  
• ja bym obok drzewa dorzucił jakiś panel detali (label? textbox readonly ?) wybranego z drzewa elementu. Zależnie od levela wybranego elementu (lotniska, albo samolotu, albo pasażera) ten panel wyświetlał by różne dane. Np. Kalkulacja wagi samolotu nie generowała by się po naciśnięciu knefla "Calculate weight" ale od razu pokazywałaby się w panelu detali po wybraniu tego samolotu w drzewie (uruchomienie metody CalculateWeight z klasy "Plane"). Po wybraniu pasażera w tym samym panelu detali wyświetliłoby się jego waga, id, waga jego bagażu  (coś jeszcze ? nie pamiętam). Skoro  jedyny/uniwerslany panel detali ma wyświetlać tak na prawdę stringa (ale o formacie informacji zależnym od poziomu drzewa lotnisko/samolot/pasażer) to rozważ dorobienia do klas Airport / Plane / Passenger metody np. ShowInfo która zwróci z obiektu informację o jego stanie (np. ShowInfo dla Samolotu odpali metody Plane.CalculateWeight() oraz Plane.CalculateAvgAge i zwróci sklejkę informacyjną o stanie wszystkich zmiennych obiektu w formacie biznesowym przyjaznym dla użytkownika). Taka metoda ShowInfo zostanie po prostu wywołana w UI, dzięki temu będzie jak najmniej kodu w formatce
  
• zgodnie z tym co piszę powyżej akcje takie jak flight, checkin, calculate odpalałbym z klawisza (nie menu górnego), ale żeby było śmieszniej to tylko z jednego knefla,  usytuowanego gdzieś obok panelu informacyjnego (a może nawet w tym panelu ?) . Treść oraz akcja tego knefla (odpraw pasażera, lub odpraw cały samolot, lub odpraw wszystkie samoloty, lub zezwól na lot wybranemu samolotowi ? itd. ) zależna by była od zaznaczonego elementu w drzewie. Może to jest trudne do wykonania a może nie, sprawdź, oceń. (czy to nie spowoduje rozrostu kodu , obsługującego coraz bardizej złożoną logikę na formatce , czego lepiej uniknąć, nie wiem jeszcze .. .ale pokusa jest duża, łątwa dla użytkownika obsługa aplikacji!
  

nie musisz się zgadzać z moimi uwagami (i tak na dalszym etapie będziemy wałkować te wszystkie kwestie, ale już w szerszym gremium)

powodzenia  

Hej,
właśnie wrzuciłem na dysk googla instalacje mojego programiku. Czekam na uwagi:)

Cygnus napisał:Hej,
właśnie wrzuciłem na dysk googla instalacje mojego programiku. Czekam na uwagi:)

Nieee no - Wygląda to nieźle
Moje uwagi:

• spróbowałbym dorobić kilka sekcji informacyjnych w tej aplikacji dot. zużycia energii zaznaczonego pokoju , oraz całego domu (obok istniejącej już sekcji info o zużyciu energii zaznaczonego urządzenia) . Chodzi o to , aby te informacje były cały czas dostępne , oraz widniały oraz aktualizowały się live (zależnie od akcji użytkownika), bez konieczności pobierania tej informacji Twoimi klawiszami All devices / All active devices (w kombinacji z radio buttonem All rooms / selected room). Tym samym ze wspomnianych wcześniej klawiszy oraz radiobuttona zupełnie bym zrezygnował.
  

Ktokolwiek śledzi ten wątek na forum niech zgłasza swoje uwagi Cygnusowi oraz polkomowi21 (mnie nie traktujcie jako wyrocznię ... moje uwagi mogą zostać "odkręcone" przez innych uczestników).

Hej,
Myślałem o zrobieniu podglądu na żywo, ale zdecydowałem się na buttona. Ale przerobię to i na żywo będzie się wyświetlać zużycie energii w zaznaczonym pokoju i w całym domu:).

Fajnie, że podoba Ci się to od strony GUI, pewnie z kodem będzie gorzej:)

Cyngus. Czy Twoja aplikacja musi być instalowana?

polkom21 napisał:Cyngus. Czy Twoja aplikacja musi być instalowana?

Tak, jak musiałem odpalać instalator. Cygnus może udostępniać tylko execa (tak jak Ty) , bo raczej wszyscy mamy .net'y ... ale instalator też jest ok.

Cygnus napisał:Fajnie, że podoba Ci się to od strony GUI, pewnie z kodem będzie gorzej:)

Na etapie 06 , przyjmę taką strategię że jako jeden z ostatnich będę zgłaszał swoje uwagi jakościowe co do kodu (chcę oddać maksimum inicjatywy innym) ... więc jeżeli przeczytasz że coś jest nie tak w kodzie , to raczej nie ode mnie :p

Admin napisał:

Cygnus napisał:Fajnie, że podoba Ci się to od strony GUI, pewnie z kodem będzie gorzej:)

Na etapie 06 , przyjmę taką strategię że jako jeden z ostatnich będę zgłaszał swoje uwagi jakościowe co do kodu (chcę oddać maksimum inicjatywy innym) ... więc jeżeli przeczytasz że coś jest nie tak w kodzie , to raczej nie ode mnie :p

Jakbym mógł korzystać z list, konstruktorów i właściwości to na pewno by to dużo lepiej wyglądało, brakowało tych 3 rzeczy:)

Admin napisał:

polkom21 napisał:Cyngus. Czy Twoja aplikacja musi być instalowana?

Tak, jak musiałem odpalać instalator. Cygnus może udostępniać tylko execa (tak jak Ty) , bo raczej wszyscy mamy .net'y ... ale instalator też jest ok.

Jasne, nie ma sprawy, przyjdę do domu to wezmę przerzucę dll do osobnej klasy w tym projekcie i wystawię tylko *.exe

Mówisz i masz

A ja mam takie pytanie, wgląd do kodu tych aplikacji będzie? Czy wszystko dopiero będzie ukazane na W17?

magicznyWladek napisał:A ja mam takie pytanie, wgląd do kodu tych aplikacji będzie? Czy wszystko dopiero będzie ukazane na W17?

Wgląd do kodu będzie na kolejnym (6-tym) etapie produkcji tego warsztatu. Na razie dogadujemy UI. Żeby było weselej to będzie wgląd do kodu tylko do systemu odprawy pasażerów a nie do sterowania domem. To tej drugiej aplikacji nie będzie wglądu w kod, bo to ma być aplikacja egzaminacyjna, więc nie chcę ludziom podsuwać rozwiązania warsztatu (po co mam Wam psuć zabawę :p) . Także Cygnus ma ułatwione zadanie (właśnie zdałem sobie z tego sprawę) bo on nie będzie ( w przeciwieństwie do polkom21) rozliczany przez resztę z kodu swojej aplikacji (żeby było śmieszniej będzie zaliczał z niej kiedyś egzamin z w17 z poprawnego napisania własnej aplikacji :p   ).

@polkom21  !!! Będziesz bardzo stękał ;p ?? (Wiem nigdy tego nie robiłeś) jak poproszę Cię o przeorganizowanie Twojej aplikacji z kontrolki drzewa na kontrolki list (czyli analogicznie jak u Cygnusa). To mi się wydaje bardziej sensowne przy organizacji dlanych typu Master-Detail (czyli zaznaczam element w liście samolotu (Master), w sąsiedniej liście odświeża mi się lista pasażerów (Detail) a po wybranu pasażera wyświetlają mi się jego detale (Detail lvl 2) ale to ostatnie już nie na liście tylko na jakimś oknie tekstowym.

Kolejnym argumentem przemawiającym za tą zmianą jest scalenie metodologii w aplikacji treningowej (odprawa pasażerów) io egzaminacyjnej (sterowanie domem) aby uczestnik mógł użyć tego samego standardu. A skoro już mamy gdzieś zmieniać to czuję że lepiej będzie w tą stronę (z kontrolki drzewa na listboxa).

To jak ??