Wybrany system kontroli wersji:

• Launchpad https://launchpad.net/

Wybrana metodyka

• TDD http://en.wikipedia.org/wiki/Test-driven_development

Wymagania funkcjonalne wersji 0.0.1

• widok główny zawiera domyślnie 4 okna:
  • okno kodu - okno, w którym użytkownik może wprowadzić kod asemblera, zawiera menu (przyciski):
    • uruchom
    • uruchom ze śledzeniem instrukcji
    • wykonaj następną instrukcję
    • przerwij program
    • wznów program
    • zakończ program
  • okno pamięci - pokazuje stan pamięci
  • okno rejestrów - pokazuje stan rejestrów
  • okno schematu - pokazuje predefiniowany schemat mikrokontrolera
• użytkownik może ukryć/pokazać każde z okien
• użytkownik może kazać programowi wykonanie wprowadzonego kodu asemblera (wybiera opcję "uruchom", "uruchom ze śledzeniem instrukcji" lub "wykonaj następną instrukcję")
  • program wykonuje kod wprowadzony w oknie kodu zmieniając stan pamięci, rejestrów i wyjścia
• użytkownik może na bieżąco śledzić w oknie kodu wykonywane instrukcje (wybiera opcję "uruchom ze śledzeniem instrukcji", przydałoby się opóźnić "skok" do następnej instrukcji, by animacja była płynna)
• użytkownik może zatrzymać działanie programu w dowolnej chwili (wybiera opcję "przerwij program") a następnie wznowić jego działanie z tego samego momentu (wybiera opcję "wznów program")
• użytkownik może zakończyć działanie programu w dowolnej chwili (wybiera opcję "zakończ program")
• użytkownik może wykonać jedną, następną instrukcję (wybiera opcję "wykonaj następną instrukcję")
• program powinien być kompatybilny z rzeczywistym procesorem (wprowadzony kod powinien działać tak samo w naszym emulatorze, w RIDE i na rzeczywistym procesorze)

Jak to zrobimy (i w jakiej kolejności ;))?

• stworzymy najpierw emulator procesora 8051 (moduł czytający z pamięci kolejne opkody i wykonujący operacje na pamięci, rejestrach itd.)
• kod asemblera będzie tłumaczony na kod maszynowy (asemblacja) i umieszczany w pamięci
• zaprojektujemy GUI używając odpowiedniej biblioteki (np. jQuery UI): okienka kodu, pamięci i rejestrów.
• początki interfejsu do tworzenia układów (flash)

Oczywiście zanim przystąpimy do pisania właściwego kodu będziemy, zgodnie z TDD, pisać odpowiednie testy (może potem wrzuci się tu linka z jakimś artykułem o dobrych i złych praktykach pisania testów w TDD).

Specyfikacja implementacyjna

• oparty na systemie operacyjnym Linux
• 2 niezależne procesy (wyświetlanie i zarządzanie) klienta:
  • wyświetlanie - własny lub przerobiony WM pod X11
  • zarządzanie - demon pracujący w tle

Wybór sprzętu i języka programowania

Po stworzeniu prototypu, można przejść do realizacji systemu na Wydziale (ekran + sprzęt). W tym celu musimy wybrać sprzętu i zdecydować się na język programowania. Sprzęt będzie nam ograniczał dostępne języki i odwrotnie. Musimy także uwzględnić całkowity koszt obranego rozwiązania, a także wziąć pod uwagę koszty eksploatacyjne.

Dobrze by było wybrać kilka języków programowania najlepiej nadających się do naszego projektu i pod ich kątem przeglądać możliwe rozwiązania sprzętowe. Z uwagi na charakter koła chcielibyśmy też aby sprzęt był w miarę "otwarty" - dobra dokumentacja, swobodna możliwość "hackowania".

Wreszcie udało się ruszyć z miejsca. Pierwsze spotkanie projektu o kryptonimie "google killer" jest już za nami. 5 sierpnia 2010 spotkaliśmy się w czteroosobowym gronie w sali GE229. Wciąż gęsta mgła dookoła, ale wydaje się, że przynajmniej wiemy na czym stoimy.

Zaczęliśmy od lekkiego wprowadzenia w technologie P2P, a dokładniej DHT. W szczególności skupiliśmy się na protokole Kademlia i wydaje się, że wiemy już zgrubsza jak on działa. Kademlia jest najpopularniejszą implementacją DHT, chcemy spróbować wykorzystać ją w naszym projekcie.

Zastanawialiśmy się, czy dałoby się uruchomić węzeł DHT bez instalowania czegokolwiek na komputerze. Niestety wygląda na to, że odpowiedź jest negatywna. Jeśli trzeba coś instalować, to czy ma to być wtyczka do przeglądarki?, czy też jakiś rodzaj samodzielnej aplikacji? Wydaje się, że pisanie wtyczki jest gorszym rozwiązaniem, bo jest mniej uniwersalne.

Na koniec rozdzieliliśmy się zadaniami: Łukasz Makowski ma przetestować Pythonowe biblioteki do Cademlii, Mateusz Kamola i Piotr Frankowski mają potestować inne sieci oparte o Cademlie, a piszący te słowa Bartosz Sawicki pomyśli nad rozproszonym uwierzytelnianiem autorów treści przechowywanej w systemie.

Ustaliliśmy, że następne spotkanie odbędzie się pod koniec sierpnia.

Coroczne wydarzenia:

Trzecia sobota września - Software Freedom Day

17 maja - Światowy Dzień Społeczeństwa Informacyjnego