Joystick 2 Mouse

Aplikacja, której nazwa jest w tylule niniejszej notki, jest bardzo użyteczna - potrafi oddać kursor myszy pod władzę podłączonego pada. Za pomocą wcześniej skonfigurowanych przycisków możemy poruszać kursorem. Niby nic nadzwyczajnego, jednak w pewnych sytuacjach bardzo praktyczne. Podstawowa zaleta, z punktu widzenia programisty gier, to możliwość przetestowania nowego rodzaju sterowania, bez konieczności implementacji obsługi pada. Wystarczy uruchomić Joystick 2 Mouse i już na wstępie podjąć decyzję o dodaniu nowej funkcjonalności. Oczywiście nie zawsze się to sprawdza, szczególnie gdy nasza gra nie jest sterowana za pomocą myszy :). Strona projektu: http://atzitznet.no-ip.org/Joy2Mouse3/

Zaplanowane zadania

Tworzenie kodu źródłowego zazwyczaj odbywa się według określonego przez nas porządku. Wprowadzamy zmiany do istniejącej implementacji, dodajemy nową funkcjonalność... Całość pracy, mimo że podzielona na określone okresy czasu, musi zachować ciągłość. Jednak, jak to zazwyczaj bywa, najsłabszym ogniwem jest człowiek. Ile to razy zdarzyło się, że zapomnieliśmy poprawić działanie jakieś metody, której ostateczną implementację zostawilśmy na sam koniec? :) Przydatnym narzędziem są tzw. listy TODO - posortowana według priorytetu lista zadań, jakie należy wykonać w implementacji. Najprostszym tego typu rozwiązaniem może być zwykła kartka papieru lub plik txt. MS Visual Studio też oferuje dość proste, choć wystarczające rozwiazanie. Otwieramy menu View->Other Windows-> Task List. Pokazuje nam sie niewielkie okno. Dodawanie zadań dobywa się w dwojaki sposób: bezpośrednio w oknie zadań, lub jako komentarze w kodzie - wystarczy tylko wybrać opcję Comments lub User Tasks. Komentarze będące elementami listy zadan muszą zaczynać się od słowa TODO lub HACK. IDE natychmiast wykrywa taki komentarz, dodając go do listy. Mamy także informacje o numerze linii i nazwie pliku źródłowego. Niestety w przeciwieństwie do User Tasks nie możemy ustalać ich priorytetu. Jeśli wykonamy określone zadanie, zaznaczamy stojącego obok niego checkbox'a - misja wykonana :)

Fizyczność logiki

Projektowanie kodu aplikacji jest z pewnością procesem niezwykle złożonym i pracochłonnym. Aplikacja cechująca się wysoka jakością, nie ogranicza się tylko do odpowiedniej funkcjonalności, stabilności i wydajności. Niezwykle ważną cechą jest także możliwość łatwej konserwacji a także ponownego użycia niektórych jej elementów. Oczywiście z pomocą przychodzi nam projektowanie zorientowane obiektowo. Podział kodu na logiczne części (klasy) i opisanie ich poziomu abstrakcji znacznie zwiększa czytelność projektu. Dodatkowo, do dyspozycji mamy też wyspecjalizowane narzędzia temu służące, jak np. UML.

Projekt programu może być dwojaki: logiczny lub fizyczny. Projekt logiczny opisuje problemy występujące na poziomie implementacji. Decyzja o tym, czy dany operator będzie członkiem klasy lub czy dana klasa powinna mieć konstruktor domyślny, zapada na etapie projektu logicznego. Projekt fizyczny zaś, określa zależności pomiędzy poszczególnymi komponentami programu. Wbrew pozorom, obydwa rodzaje są ze sobą ściśle powiązane i często nieświadomie projektujemy aplikacje od strony fizycznej.

Podstawowym elementem projektu fizycznego jest komponent, czyli spójna i niezależna jednostka będąca zazwyczaj klasą (lub zbiorem klas określonej funkcjonalności) zdefiniowaną w pliku nagłówkowym i zaimplementowaną w pliku cpp. Załóżmy, że tworzymy klasę przechowującą punkty na płaszczyźnie dwuwymiarowej. Klasa ta udostępnia pewną podstawową funkcjonalność (dodawanie, usuwanie,sortowanie punktów). Interesuje nas także możliwość przeglądania listy punktów, jednak przy wykorzystaniu iteratora. Tworzona przez nas klasa iteratora powinna znajdować się w tych samych plikach co główna klasa będąca kontenerem punktów. Fizycznie (a także logicznie) stanowią one jeden komponent udostępniający określoną z góry funkcjonalność (przechowywanie i przeglądanie danych).

Pomiędzy komponentami mogą występować określone relacje:

• Jest
• Używa-W-Interfejsie
• Używa-W-Implementacji

Relacja Jest bezpośrednio wynika z dziedziczenia. Klasa A jest Klasą B, jeśli klasa A publicznie dziedziczy po klasie B. Używa-W-Interfejsie oznacza, że dany typ jest wykorzystywany w interfejsie danej klasy. Kiedy tak się dzieje? Gdy typ jest zwracany przez jedną z metod klasy, przyjmowany na liście argumentów lub znajduje się w sekcji prywatnej. Ogólnie rozróżnia się dwa przypadki tej zależności: pełna i z nazwy. Przypadek pierwszy, mówi o tym, że do kompilacji klasy wymagana jest znajomość całej definicji obiektu (dołączenie jej za pomocą #include). Jest to najczęściej spotykany przypadek. Zależność Tylko-Z-Nazwy jest wykorzystywana tam, gdzie mamy do czynienia ze wskaźnikami lub referencjami na obiekt. Wtedy potrzebujemy tylko nazwy obiektu - korzystamy z deklaracji wyprzedzającej. Ostatnia z relacji, czyli Używa-W-Implementacji, jak sama nazwa wskazuje, mówi o tym, że dany typ używany jest w implementacji funkcjonalności klasy. Wszystkie pliki nagłówkowe, niezbędne do kompilacji, należy dodać poleceniem #include w pliku cpp klasy (nie w pliku nagłówkowym). Odpowiednie wykorzystanie wyżej zaprezentowanych relacji pozwoli nam na bardziej przejrzyste zaprojektowanie naszej aplikacji, a także skrócenie czasu kompilacji lub nawet linkowania.

Opera 9.6

Wczoraj, 8 października, Opera Software wypuściła finalną wersję, kolejnej generacji, swojej przeglądarki internetowej. Z podstawowych zmian o jakich należy wspomnieć to ulepszenia w kliencie pocztowym Opera Mail, polegające na dodaniu trybu "połączenia o niskiej przepustowości". Ciekawą funkcjonalnością jest także możliwość przejrzenia kanału informacyjnego RSS przed dodaniem go do Kanałów. Ciekawa jest także Opera Link, umożliwiająca zschynchronizowanie swojej przeglądarki z Operą zainstalowaną na innym komputerze - wystarczy zarejestrować się w serwisie my.opera.com i wybrać opcję z menu Plik->Synchronizuj Operę. Wybrane ustawienia zostaną zapisane na serwerach Opera Software. Tutaj możemy sciągnąć pakiet instalacyjny przeglądarki.