Powstanie, taki sam jak maszyna losująca dla PKW.

_________________
Und schreien

Spring
Erlöse mich
Spring
...

Cześć,
na początek malutkie wyjaśnienie - jestem Jakub, forum przeglądam regularnie, ale jestem "cichym" użytkownikiem. Temat mnie zainteresował. Przeczytałem wypowiedzi kolegów Krauser, Mokrowski, Doman, SunRiver, Mirek i innych i mam następujące przemyślenia (w formie pytań i odpowiedzi).

Po co robimy?
Nauka pracy zespołowej (GitHub, standardy pisania kodu, modułowość sprzętu i oprogramowania). Zrobienie czegoś ciekawego.

Dla kogo robimy?
To jest projekt od hobbystów dla hobbystów, nie ma mowy o komercjalizacji.

Co robimy?
System inteligentego budynku. ALE - uważam, że w tym momencie nie ma sensu wymieniać jakie czujniki będą w systemie, czym będziemy sterować itp. Ostatecznie nie chodzi przecież o stworzenie masy super-urządzeń, które nie będą w stanie się dogadać.

Wg mnie powinniśmy zrobić SZKIELET systemu, mianowicie opracować system komunikacyjny (protokół). Powinien on być modułowy, uniwersalny i niezależny od użytej platformy sprzętowej. Można to zrobić na dwa sposoby:
1. wykorzystać gotowy protokół komunikacyjny (WiFi, ZigBee, Ethernet itp.) i traktować moduły komunikacyjne jak czarną skrzynkę. W tym przypadku trzeba zdefiniować dwa interfejsy: jeden dla użytkownika systemu komunikacyjnego, czyli co możemy wysłać, do kogo, jaka jest struktura ramki itp., i drugi interfejs do wybranego fizycznego portu komunikacyjnego (żeby opakować UARTy, SPI i wszystko inne w tak samo wyglądającą skrzynkę).

2. Zaprojektować własny protokół (jak najprostszy), czyli dzielimy protokół na warstwy:
- warstwa aplikacji, która stanowi interfejs do protokołu komunikacyjnego (czyli w jaki sposób można skorzystać z protokołu: wyślij dane do X, sprawdź status Y, połącz się z siecią itp.),
- warstwa sieci, gdzie zdefiniowana będzie topologia systemu (np. jedno urządzenie nadrzędne - access point, przez który przebiega cała komunikacja, albo system rozproszony, z możliwością bezpośredniej komunikacji między modułami itp.)
- warstwa dostępu do medium transmisyjnego - czyli w jaki sposób rozwiązujemy problemy kolizji (jednoczesna komunikacja na tej samej magistrali lub w jednoczesna transmisja radiowa komunikatów przez kilka urządzeń), jaka jest ramka, adresacja modułów, typy ramek itp.
- warstwa fizyczna - w zasadzie chodzi mi tu o zdefiniowanie funkcji, jakie muszą być udostępnione warstwie wyższej - czyli np. wysyłanie ramki, przełączenie w tryb odbioru, nasłuchiwanie stanu kanału transmisyjnego.

MOżna też połączyć oba rozwiązania.

W obu przypadkach uważam, że celem projektu jest stworzenie systemu komunikacji, bo przeciwnym razie zostanie wyprodukowanych mnóstwo urządzeń, których nie da się połączyć w sieć. Do tego należałoby dorobić moduły komunikacyjne dla wszystkich rodzajów transmisji, które chcemy wykorzystać: radio, dedykowane przewody, PLC (pieśń przyszłości).

czyli krótko: CEL - stworzenie działającego systemu komunikacyjnego, w postaci biblioteki, która ma interfejsy: od góry - umożliwiający używanie protokołu, od spodu - umożliwiający adaptację wybranego modułu transmisyjnego. Bibliotekę możnaby nawet udostępnić w formie kodu źródłowego jak i skompilowaną na różne platformy.

Wszelkie czujniki, centralki, układy wykonawcze - to dopiero potem, kiedy będziemy mieć komunikację i można będzie zabrać się za prototyp rzeczywistego systemu.

Czyli - masa organizacyjnej roboty, babranie się w problemach komunikacyjnych, a rzeczy efektowne - na końcu.

Kolega fosfolipid ma rację - opracowanie (lub przyjęcie gotowego) protokołu wymiany danych miedzy modułami/urządzeniami sprawi, że dalsze prace nad systemem podzielą się na mniejsze fragmenty - może wtedy powstać kilka-kilkanascie podgrup/zespołów/osób indywidualnych pracujących nad "swoimi" modułami.
Będzie im łatwiej skupić się nad mniejszymi podprojektami.
Każdy z nich może być wykonany na innej platformie sprzętowej - od prostych modułów czujników do których wystarczą procesory AVR, poprzez bardziej rozbudowane funkcjonalnie "Master Controllery" wykonane na procesorach 32-bitowych, aż do modułów opartych na np. RaspberryPi, które mogą odpowiadać za bardziej rozbudowane funkcje (np. komunikaty głosowe, itd...)
Jednocześnie przyjęty standard sprawi, że powstające z czasem kolejne moduły będą kompatybilne z pozostałymi elementami i będą rozszerzać funkcjonalność powstającego systemu.

Obawiam się jednak, że już na etapie opracowywania takiego protokołu pojawią się spore problemy do rozwiązania/ustalenia - i powstające w związku z tym różnice zdań (jak to zwykle bywa).
Jeżeli uda się przez to przebrnąć, to już będzie jakiś sukces

Idea open source (hardware) - jak najbardziej słuszna, bo należy się liczyć z tym, że początkowy entuzjazm i zapał do pracy po pewnym czasie zacznie przygasać (sam ostatnio siedzę nad pewnym projektem w sumie już od 12 miesięcy i czasami człowiek po prostu musi się trochę oderwać bo "mózg się lasuje") i może nawet dojść do zaniechania prac nad konkretnym urządzeniem/modułem.
Ale jeżeli wszystko jest na licencjach otwartych, powszechnie dostępne, to w takim wypadku dalsze prace nad projektem może przejąć nowa grupa zapaleńców. W przypadku kodów zamkniętych - jeżeli twórca porzuci projekt, przestaje on istnieć w przestrzeni publicznej.

W sumie to zahaczamy o modny ostatnio Internet of Things

O żesz ! .... to jeszcze nawet jeden ... ba! nawet pół... gdzie tam nawet 1/6 zespołu nie powstała ... a tu już widzę plan kilkunastu zespołów - Jezu! "coraz lepiej"

to może pójść o kolejny krok dalej i powołać kilkaset mniejszych zespołów
-----------------------------------------------------------------------------------------

haaalo ... halo ... panowie - pooobudka !

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No niestety , ale zabierają się jak do (y) jeża ...
jeszcze trochę zaczną się kłócić , o wyimagowane racje
a niema żadnej budującej konwersacji ...

Panowie: a weźcie dajcie spokój i na wstrzymanie

1. Zbierzcie zespół
2. Wybierzcie zależnie od liczby ludzi do 3ch Managerów projektu
3. Podzielcie zespół na 3 grupy (każda z MP)
- np: Hardware, Base Software, Module Software

4. Ustalcie priorytety Grup/Zespołów
5. Wybierzcie model komunikacyjny (SVN/GIT)
6. Omówcie typ projektu , i wybierzcie platforme sprzętową
7. Omówcie założenia Projektu BAZOWEGO
8. Stwórzcie szkielet i według niego podzielcie się na zadania
9. Zacznijcie coś robić

ech...

_________________
[b]San Escobar! Patria mia! Tu eres como la salud.[/b]

Chcecie zacząć ? liznąć temat pracy zespołowej ?

To niech kilka osób się skrzyknie i np ustali, że dla zabawy i sportu napisze wspólnie np bibliotekę do obsługi np (strzelam) jakiegoś nietypowego wyświetlacza graficznego ... albo i typowego ... ale tak od podstaw do KOŃCA czyli np z opracowaniem ciekawych nadrzędnych oderwanych od sprzętu funkcji do obsługi ciekawych efektów graficznych, obróbki kolorów, animacji, realizacji wykresów dla użytkownika itp itd

ludzie - tak jak każdy kto się zaczyna uczyć programować zaczyna albo od "Hello world" lub migania diodą LED wy także zacznijcie od "hello world" pracy zespołowej. I tak napisanie takiej biblioteki zakończonej ładną dokumentacją DOXYGEN i tak żeby leżała na githubie nadająca się do dalszej obróbki i wykorzystania to już będzie COŚ. Dzięki czemu GŁÓWNY CEL jakim będzie NAUKA WSPÓLNEGO PROGRAMOWANIA, podziału na role, gdzie wtedy pięknie można podzielić zadania np jeden albo dwóch mających dostęp do sprzętu obrabia warstwę fizyczną a kolejni zabierają się za warstwę abstrakcji - oderwaną zupełnie od sprzętu, następny(-ni) odpowiedzialni za łączenie i testowanie.

Takie podejście umożliwi wręcz zrobienie LIB'sa oderwanego od sprzętu ... albo jeśli komuś kolejnemu się zachce to przy dobrze zrobionych interfejsach warstwy abstrakcyjnej spokojnie dorobi drivery do innej czy innych platform.

To oczywiście nie musi być wyświetlacz ale jakiekolwiek inne urządzenie - chociaż tam gdzie mówimy o wizualizacji jest zwykle większe pole do popisu ... bo od razu przy testowaniu widać efekty

spójrzcie np na biblioteki FatFS czy PetitFS które można śmigać na AVR, ARM/STM, PIC, 8051 itp ....

Jak widzicie - zastanawianie się na początku jaką platformę wybrać jest TOTALNIE nietrafionym pomysłem bo projekt zawsze warto podzielić co najmniej na takie dwa etapy (mówię o prostych projektach)

a wy tu o jakichś mega systemach inteligentnych domów piszecie .... Jak ktoś rzuca takie hasło - to zanim to zrobi - niech spróbuje przysiąść do rozpisania algorytmu chociaż ogólnego działania takiego systemu - to po chwili przyjdzie czas na ochłonięcie i zachłystywanie się pomysłami na start ....

Tymczasem gdy w takim prostym zadaniu uda się w ogóle zebrać mini zespół i ludzie się dotrą, uznają że warto dalej działać bo są fajne efekty to wtedy można nawet pokusić się na coś większego a nawet komercyjnego i jeszcze zarobić - czego wszystkim życzę

------------------------ [ Dodano po: kilkunastu sekundach ]

O, Sun mnie uprzedził a mniej więcej o to samo chodzi ....

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Szczególnie demokracją w ostatnio widzianym wydaniu .
Sorki za wtręt, ale patrząc na pracę tych biednych żuczków "na dole" to naprawdę żal poświęconego czasu.

--
Grzegorz...

Kolega Mirek widzę, że bardzo jest złośliwy
Na razie to przecież tylko luźna dyskusja - można omawiać każdy wariant.
Ja akurat siedzę trochę w automatyce domowej, więc ta tematyka nie jest mi obca - może dlatego od razu przeskok do sedna problemu (na etapie jaki mnie interesuje).
Podejrzewam, że na forum jest więcej takich osób - być może każda z nich pracuje nad własną wersją systemu.
Może nawet ich prace są dość zaawansowane.
Gdyby połączyły siły i uczyniły swoje systemy kompatybilne (np. przez wspólny protokół, zasady sterowania), to może była by szansa na stworzenie wspólnie jakiegoś sensownego systemu HA - w czasie krótszym niż to dla każdego indywidualnie wypadnie.

No, ale na razie się na to nie zapowiada, jak widać.

Jeśli tak to odebrałeś to uprzejmie przepraszam ....

ale mylisz się to ŻADNA złośliwość - tylko troszkę sprowadzenie na ziemię. Bo o ile jeszcze mogę zrozumieć to co piszesz teraz dalej - to mnożenie bytów do chociażby kilku zespołów - podczas gdy ty piszesz już o kilkunastu ..... No to zaczyna być hmmmm sam nie wiem jak to nazwać a nie chciałbym być posądzony o kolejną złośliwość.

Więc jeszcze raz - powolutku i mniejszymi kroczkami a może się uda.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Napiszę, bo już mnie trochę to całe gadanie mierzi!



Ale skąd!.. Pan Mirek ma rację. Nie tak dawno pytałem/prosiłem o pomoc w projekcie, nad którym obecnie siedzę. Pytanie/prośba dotyczyła wcale nie żadnych spraw programistycznych, ale właśnie elektroniki - czymś na czym ludzie tutaj dobrze się znają. I co? Zapał do pomocy, że nie wiem co.. Ale spokojnie... Ja jakoś powolutku rypie to sam i w zasadzie, na chwilę obecną żadna pomoc teraz nie jest mi już potrzebna. Stan swojego projektu określam na jako: zaawansowany, chociaż generalnie mógłby być już skończony. Nie mam do nikogo żalu, bo wiem jak jest w życiu: umiesz liczyć - licz na siebie. Poza tym każdy ma własne życie, rodzinę, PRACĘ etc. Projekt, o którym wspomniałem też miał być z założenia open-source. Też na początku było dużo gadania, achów, i ochów. Kiedy zaczynałem projekt, o którym wspomniałem brałem pod uwagę -a jakże: najgorszy wybór z Prawa Murphy'ego- że będę to robił sam, zakładając na ile to czy tamto potrafię (uwzględniając tak programowanie różnego typu jak i elektronikę).
Także kochani Koledzy, to żadna złośliwość ze strony Pana Mirka, tylko raczej doświadczenie życiowe i słuszna uwaga, żeby niektórych sprowadzić tutaj na ziemię -jak rozumiem- w znaczeniu: mierzyć siły na zamiary.

Co do TUTEJSZEGO projektu to ja cierpliwie czekam, aż w końcu ktoś przedstawi coś bardziej konkretniejszego w kwestii: interfejsu, sterowania, protokołów wymiany danych, elementów elektronicznych i innych spraw jak np. ew. dokumentacji, czy narzędzia do pracy zespołowej. Póki co jest tylko dużo gadania. Jeżeli projekt ma ruszyć to powinni znaleźć się jacyś przysłowiowi Prometeusze=Menadżerowie Projektu (Pomysłodawcy?), którzy będą na tyle doświadczeni i zaawansowani w tym czym chcą się zająć, że będą w stanie poprowadzić mniejsze zespoły (z -jak rozumiem- rotacyjną/niestabilną ilością osób w zespole).

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Może z tymi kilkunastoma zespołami, to się trochę zagalopowałem
Czasami się szybciej pisze niż myśli.
Jak to mówił Smoleń (albo Laskowik - nie pamiętam dokładnie) : "kolega jak coś chlapnie...."

W każdym razie sam mam dokładnie takie same doświadczenia jak kolega J23. Nawet swojego czasu udostępniałem w sieci swój wcześniejszy projekt HA - na zasadach open source.
Ale zainteresowanie nim było minimalne i po kilku latach strona zniknęła (skończył się czas na serwerze hostingowym).

Dlatego pisałem o zamkniętych - może nawet niezależnych zespołach/pojedynczych twórcach, bo zainteresować kogoś wspólnym projektem, nie zatrudniając go i płacąc mu za to, jest bardzo ciężko. Łatwiej chyba by było, żeby "każdy sam sobie rzepkę skrobał", a jedynie dostosował się do wspólnego standardu.

Inna sprawa, że z pracą zespołową to raczej mało będzie miało wspólnego, więc nie o to koledze założycielowi wątku zapewne chodziło

W tej chwili interesuje mnie tylko czy uda się wypracować jakiś wspólny protokół komunikacyjny - zasady adresowania, format przesyłanych danych, stała/zmienna długość pakietu, itp...
Co do reszty to już mniej ważne - można sobie to "wenkapsulować" do dowolnego protokołu sprzętowego (radio/ethernet/przewód).
Ja jak na razie oprogramowywałem inne elementy - właśnie bardziej te sprzętowe.
Protokół powstał do celów testowych - dosyć uproszczony (w tej chwili nie przytoczę szczegółów, musiałbym spojrzeć w źródła).
Nastawiałem się raczej na minimalizm tj. tylko to co w/g moich założeń niezbędne, zamiast jakiegoś uniwersalnego, rozbudowanego protokołu.

Problem tu jest zawsze z tym, że każdy ma jakąś swoją indywidualną wizję i koncepcję, i nie za bardzo ma ochotę dostosowywać się do innych
W rezultacie powstaje 10 indywidualnych projektów jednoosobowych, niekompatybilnych wzajemnie, których stworzenie trwa latami, bo pracy ogrom, a osoba tylko jedna programuje.

Jeszcze raz nieśmiało przypomnę - poniżej jest cytat z pierwszego postu autora tematu:

Dla mnie celem projektu jest zgodnie z powyższym nauka jako taka pracy zespołowej, poznanie jak się to robi naprawdę, a nie na zasadzie pospolitego ruszenia (w sumie nie każdy może być w zespole i nie chodzi tu o wiedzę). Przy takim podejściu jakie widzę, to się nie uda, nie mówiąc o zespołowym zrobieniu jakiegokolwiek wyrobu finalnego chociaż to powinno być akurat "narzędziem" do osiągnięcia celu - to tak tylko kilka słów wcale nie teoretyka jeśli chodzi o realizację projektów (hardware & software) w zespole.

Zaraz, zaraz, zaraz.... Na razie ja osobiście skupiłbym się właśnie na wspólnym protokole komunikacyjnym do wymiany informacji, bo żeby się szybko dogadać w pewnych złożonych kwestiach trzeba mówić tym samym -niestety- ścisłym i zwięzłym językiem.
Ludzie kochani, wiem że to jest ciężkie do przetrawienia, ale nie gryzie i AŻ TYLE czasu nie zabiera, a przyrost mocy przerobowej jest całkiem, całkiem mierzalny. Innymi słowy zachęcam do:
- zapoznania się z językiem UML z tego linka do znalazłem: http://edu.pjwstk.edu.pl/wyklady/pri/scb/index161.html
- zachęcam wypożyczyć z biblioteki uniwersyteckiej/politechnicznej, załatwić, kupić (dalsze możliwości zostawiam waszej wyobraźni) książkę Pana Stanisława Wrycza, B.Marcinkowskiego, K. Wykrzykowskiego pt: "Język UML 2.0" - UWAGA!!! Nie czytać całej książki! Tam na końcu są takie plansze, diagramy UML'a z przykładami.
- zachęcam spróbować przynajmniej opisać to co się da tak jak kto to widzi (najwyżej później się to poprawi i już).
- tam na końcu książki gdzie są te diagramy jest bardzo ciekawy diagram analityczny (co prawda do badania analitycznego), ale można by go przerobić do badania analitycznego elektroniki
Zdaje się był taki ciekawy post gdzie kolega Weles opisywał projekt inteligentnego domu. Może od tego warto byłoby zacząć?
Ostatecznie kartka, papier i ołówek i zeskanować.
Jest taki prosty diagram do wstępnego planowania i nazywa się diagram modelowania analitycznego.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Na początek ktoś musi to koordynować, jeżeli ma być UML, to musi być osoba znająca UML itd.

Bo w ten sposób wyjdzie na to, że trzeba będzie poznać mnóstwo narzędzi, ale bez praktycznego pokazania ich zastosowania to raczej będzie ciężko.

Jeżeli ktoś z zabierających głos w dyskusji, chce zacząć od strony sprzętowej, jestem za. Inna grupa może zajmować się szablonami, ideą pracy zespołowej etc.
Bo widać, że są dwa obozy. Jedni chcą już konkretów, a inni chcą tylko poznać metodykę działania w grupie.

Dlatego może by powstał nowy temat, gdzie spisane były by założenia projektu idomu, następnie podział na osoby kto chce robić którą część. Nie widzę problemu, po powstaniu ogólnych założeń, można je precyzować z czasem. Może i nic z tego nie wyjdzie, ale sama próba jest już jakąś nauką.

PS. Dokładnie o to też mi chodziło kolego Jado, bo często i gęsto są ciekawe projekty, ale jak każdy robi po swojemu, to potem ciężko po pierwsze pomóc, czy rozwijać wspólnie projekt. Jeden z kolegów miał tu odrobinę pretensji, że nikt nie pomógł mu w projekcie.
Tylko właśnie o to chodzi by wypracować wspólny standard. Tak też rozumiem wspólną pracę.
A że jak dobrze kolega mokrowski zauważył, że nie ma co na nowo wynajdywać koła, trzeba po prostu zaimplementować istniejący standard, szeroko stosowany jest modbus i pochodne.

Mi ten watek juz dostarczyl sporo radosci i zabawy a nawet troche informacji

Glosowanie zaproponowalem tylko na managera, uC i taktowanie - czy to duzo? Cala reszta to juz dyktatura managera !

Projekt moze nie dojsc do skutku z bardziej prozaicznej przyczyny niz wasze gradobicie - jesli nikt na szefa sie po prostu nie zglosi

Zapewne git
Zapewne eclipse
Zapewne C
Zapewne i2c/1wire + radiowka

Ale ostateczne zdanie ma szef. Tu nie ma miejsca na glosowania

Nie ma tez co przesadzac - chcemy zrobic projekt ktory jest w stanie zrobic 1 osoba - tylko w zespole
Nawet jesli projekt ruszy ale nic z tego nie wyjdzie to j uz daje sporo do myslenia!

Kandydatury są, teraz tylko głosowanie i zostanie nominowany

PS. dlatego też jeżeli już nawet zieloni w "was" nie wierzą , no ale jak wyżej wspomniałem, skoro ktoś zna UML, niech pokarzę chociaż przykład.

Bo mnie UML to się kojarzy tylko z umlautem .

No i macie powyżej, Scruma w mikro pigułce - ale faktycznie aż się prosi aby tu spróbować zastosować niektóre tego elementy.

Dlaczego się tak upieracie na tego UMLa? j23 polecasz ksiażkę żeby poznać UMLa ale nie chcesz, żeby czytano całą ksiażkę. Chcesz żeby tylko zajrzeć na jakiś diagram analityczny... tylko, że w UMLu nie ma takiego diagramu. UML bez określonych kroków postępowania nie nadaje się do niczego, a tutaj nie wszyscy znają UML. Służy raczej w bardzo mocno sformalizowanych procesach produkcji (zazwyczaj oprogramowania). Tak jak mokrowski sugeruje, w takim przypadku tylko miękki metodyki. No i posłuchajcie mirekk36 napiszcie najpierw jedną "małą" bibliotekę, później trochę rozbudujcie. Zajmie Wam to o wiele mniej czasu niż automatyka budynku, mniej decyzji do podjęcia, a będziecie mieli możliwość przekonania się jak wygląda praca w zespole i czy faktycznie możecie przejść do automatyzacji domów.

Nie wiem, czy nie lepiej byłoby rozdzielić tego wątku na dwa - jeden o pracy grupowej, a drugi o automatyce domowej - dla zainteresowanych. Bo mam wrażenie, że rozmowa o managerach projektu nie sprzyja konkretnym rozmowom o konkretnych pomysłach i rozwiązaniach.

Bo widzisz pierwszy post nagle ewaluował nie w dyskusje co trzeba zrobić (zaplanować) aby poznać jak pracować w zespole i jakich narzędzi się nauczyć, tylko poszedł w kierunku "zróbmy razem gotowe urządzenie" najlepiej takie np. jak sterowanie domem - to po prostu się nie uda - przy takim podjściu to może zrobić pojedynczy człowiek (jak się uprze i będzie miał zapał, czas i pieniądze) ewentualnie ktoś mu pomoże (ale wątpię) i nie będzie miało to nic wspólnego z pracą w zespole.

Niedługo jeśli chodzi o ten wątek to będzie można zmienić mu tytuł na: "Jak nie należy podchodzić do pracy zespołowej" .... i to nie jest żadna złośliwość ....

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Wątek i tak jest ciekawy po pokazuje pewne mechanizmy

Problem tu jest o tyle taki, że ludziom łatwiej jest się zaangażować w coś co jest namacalne (a więc projekt konkretnego, fajnego urządzenia) niż w prace przygotowawcze - gdzie najpierw trzeba wykonać dużo pracy ogólnej, zanim przystąpi się do konkretów.

W życiu realnym, gdzie np. w firmie tworzy się taki projekt, ten system jest jak najbardziej prawidłowy - jednakże ludzka motywacja wynika z tego, że dostają oni konkretną pensję za konkretną pracę.
W sytuacji wirtualnej współpracy motywacja jest inna - samo zainteresowanie tematem, chęć posiadania danego urządzenia, pasjonatyzm, chęć nauki, itp....

Jest jeszcze coś takiego jak masa krytyczna - gdyby projekt był w fazie gotowości pozwalającej już na jego używanie/korzystanie i można było by to namacalnie zobaczyć, to zapewne więcej osób było by chętniejszych do włączenia się w coś czego efekty już widać (sukces ma wielu ojców).

Skądś to znam


TO zostawmy ten wątek, w końcu sam temat brzmi [Luźny pomysł], a konkrety proszę już założyć w właściwym dziale. Tj. na temat pracy zespołowej, UML, oraz innych czarów i dziwów .

No cos w tym jest - to jest tak jak z nauką np. C dla AVR - najlepiej jakby od razu można było diodą migac i było widać tego efekt na płytce uruchomieniowej.

Przecież cel już padł, w dodatku kilku krotnie, łącznie z małym na mega8/88.

Teraz prośba, albo zainteresowani będą się co dziennie logować na forum i wpisywać w temat, albo to nie ma sensu, bo albo od teraz podejmujecie kroki w celu wyłonienia poszczególnych członków danego szczebla, zgodnie z hierarchią opisaną przez mokrowskiego, albo kończ waść wstydu oszczędź .
W sumie fajnie jak dwu co by nie było ogarniętych w temacie (Mirek i Sun) od razu sprowadza temat do parteru.
Dlatego panowie konkrety podał Mokrowski.
Czyli albo zaczynacie działać, tj. nie na zasadzie raz na dwa dni ktoś wejdzie w temat, tylko wypadało by już zacząć efektywnie tworzyć zespół. Kto jest zainteresowany, kto się widzi na jakim stanowisku.

Ja mogę być beta testerem

Namazane ze smarta.

_________________
Usługi druku przestrzennego - www.drumik.pl

Kandydatury proszę umieszczać w tym wątku.

topic9343.html

Z pomysłów, skoro ma być niezależne od platformy, mają być założenia, oraz cel.

To z mojej strony na początek czysto programistyczne rozwiązania.

Np. nie blokujące, miganie diodą.
- brak użycia delay
- możliwość dowolnego ustawienia czasu włączenia i wyłączenia diody
- możliwość ustawienia ilości mignięć w jednostce czasu.
- możliwe jak najmniejsze wykorzystanie zasobów.
- dodatkowy parametr określający kolor diody, czyli wysyłamy, czas, ilość mrugnięć oraz np. kolor diody.

Proszę, proste na początek. Testerem może być każdy, menadżerem projektu też.

To tylko taki luźny pomysł, opis algorytmu, założenia określone precyzyjnie w/g upodobania menadżera. itd. takich "prostych" projektów można mnożyć.

Czyli od początku najpierw szablon, założenia co ma robić, cel, docelowy klient, czyli np. Pan Kleks, co lubi kolorowo, Dioda RGB, czyli możliwość uzyskania 3 kolorów na początek. itd.

Reszta jak kolega mokorowski, jeżeli ktoś zna narzędzia do zarządzania projektem, pomysłów jak mrówków. Skoro ma być prosto, to można od migania diodą zacząć.

Po pierwsze NIGDZIE nie upieram się, że musi być UML. UML'a znam tak sobie, myślę że na tym forum znalazłyby się osoby lepiej znające go ode mnie.
Po drugie, to że napisałem (wspomniałem), że może być UML i zaproponowałem użycie diagramu modelowania analitycznego było spowodowane właśnie takimi postami jak Twój, że ludzie zanim zobaczą co to jest UML i z czym to się je, to już naprzód zaczynają narzekać.

No i w związku z tym zaproponowałem w miarę łagodny diagram analityczny, który jest w standardzie UML w ujęciu biznesowym, ale możnaby go dopasować do warunków tego projektu, bo jest to prosty diagram do opanowania, a z niego łatwo jest przejść do ew. innych diagramów, np. diagramów przypadków użycia, czy diagramów maszyny stanowej.
Tutaj jest trochę o diagramie analitycznym (po polsku).
Po trzecie Ktoś później w dyskusji zaproponował scrum i ja to podejście jak najbardziej popieram, chociaż przyznam szczerze, że nie znam scrum'a (dopiero uczę się: co i jak ze scrum'em). Niemniej ogólny zarys tej metodyki postępowania znam i wiem, czemu Kolega Mokrowski popiera scrum'a.

Popieram zamysły Kolegi Mokrowskiego i energię decyzyjną Kolegi Resasurmar.

Pozdrawiam! j23 Jarek

P.S. Edytowałem, żeby skasować moje ostre jak żyleta i niepotrzebne uwagi.

_________________
"O sygnałach bez całek" Czesław Frąc

Temat trochę przycichł a celu nadal nie ma a i osoby, które wstępnie się zgłaszały zniknęły. Znając potencjał udzielających się na tym forum użytkowników myślę, że projekt, który zaproponował kolega Krauser ma szanse powodzenia tylko trzeba go doprecyzować w pewnych aspektach.
To czego dotyka jego cel jest ćwiczone przez wielu z nas z osobna trzeba to tylko poskładać projekt w całość.

Panowie jest możliwość zrobienia czegoś oryginalnego i niepowtarzalnego więc czemu nie skorzystać z tej okazji ucząc się przy tym nie tylko programowania ale poznania całego procesu powstawania projektów (oczywiście pomijam osoby, które już takową możliwość posiadają).

_________________
Karkołomne zadanie, ogarnąć C.

Spokojnie, część osób to zagląda tu rzadziej niż na nieszpory .