Office 2007 i jego pudełko

Wszyscy zapewne wiedzą, że z okazji 15-lecia swojej obecności w Polsce Microsoft oferuje domową wersję pakietu biurowego Office 2007 za niecałe 200 złotych. Są w nim trzy klasyczne i najczęściej wykorzystywane programy, czyli Word, Excel i PowerPoint, oraz czwarta aplikacja – bardzo ciekawy wynalazek o nazwie OneNote. Za tę cenę (niektóre PC-towe gry kosztują niewiele mniej) to naprawdę doskonała okazja, więc oczywiście się na nią skusiłem :)

Najbardziej rzucającą się w oczy cechą tej wersji jeszcze rzecz jasna nowy interfejs, przypominający mi trochę paletę komponentów z Delphi (te same intensywne użycie zakładek). Początkowo dość ciężko się przyzwyczaić do braku paska menu i konieczności wybierania opcji z tej toolbaro-podobnej Wstęgi – jak ją MS ładnie nazwał – ale po jakimś czasie jest już nieco lepiej. Zdecydowanie ciężej nauczyć się obsługi np. edytora vi ;]

Pośród programów wchodzących w skład pakietu najbardziej tajemniczy był dla mnie czwarty z nich – OneNote. Okazało się jednak, że jest on z nich wszystkich najprzydatniejszy :) Śmiało mogę wręcz powiedzieć, że jest to aplikacja, o której marzyłem całe życie. Jest to coś w rodzaju menedżera umożliwiającego prowadzenie wirtualnego notesu. Zawarte w nim notki można katalogować wzdłuż, wszerz i w poprzek na wszystkie możliwe sposoby, a ponadto edytować w niezwykle swobodny sposób. Nic nie stoi na przykład na przeszkodzie, żeby po prostu kliknąć gdzieś na stronie i zacząć pisać. Potem można manipulować tak powstałymi polami tekstowymi, dodawać do nich obrazki, tabele, a nawet tekst z obrazków (przy pomocy modułu OCR). Generalnie jest to świetny program do spisywania pomysłów, wstępnych szkiców, projektów, przemyśleń, idei i w ogóle wszystkiego, co tylko przyjdzie nam do głowy. A dodatkowo wszystko to jest zapisywane automatycznie w określonym katalogu (domyślnie w Moich dokumentach) i nie rozłazi się po całym systemie.

I wszystko było cudownie, gdyby nie pewnie problemy przy… nazwijmy to, instalacji. No dobrze, powiem wprost – chodzi o pudełko, w którym kupuje się pakiet, a dokładniej o sposób jego otwarcia. Sprawa nie jest bowiem taka prosta, jako że spędziłem dobrym kilka minut szukając wskazówek na gładkiej powierzchni plastikowego prostopadłościanu o opływowych krawędziach. A rozwiązanie było całkiem proste: niczego się tu klasycznie nie otwiera, należy po prostu je odpowiednio… przekręcić :) Naciskamy po prostu na akcyzopodobną naklejkę na górze opakowania, przesuwamy je w prawo i voila, naszym oczom ukazuje się błyszcząca płyta DVD.
Mam nadzieję, że dzięki tej radzie ktoś zaoszczędzi sobie intensywnego główkowania, jak się do promocyjnego Office’a dobrać. A dobrać się naprawdę warto, bo taka okazja nie zdarza się często… Zapewne raz na 15 lat ;)

Dziś pomysł, jutro artykuł

Wczoraj naszła mnie niesamowita ochota, aby napisać tekst. Taki zwyczajny programistyczny artykuł, w którym można poruszyć ciekawe sprawy i nauczyć czegoś czytelników. Podobne natchnienie ostatnio nie zdarza mi się często, więc żal byłoby go nie wykorzystać :)
Efektem jest dość spory tekst traktujący o pisaniu prostego modułu do grafiki 2D z użyciem DirectX – czyli czegoś, czym zajmowałem się kilka tygodni temu. Jak sądzę wyszedł z tego całkiem przejrzysty i przydatny opis, w którym udało mi się też poruszyć kilka różnych tematów z zakresu DXa ze szczególnym uwzględnieniem dynamicznych buforów wierzchołków.

• Własny moduł grafiki 2D

Wszyscy jesteśmy dziennikarzami?

Jak donosi Rzeczpospolita, w myśl precedensowego orzeczenia Sądu Najwyższego, serwisy internetowe należy traktować tak samo jak… prasę. Jeżeli tylko strona jest aktualizowania częściej niż raz na rok, podpada pod bycie czasopismem i jako takie powinna być zarejestrowana. Jeżeli zaś nowe treści pojawiają się na niej częściej niż co tydzień, wówczas jest już w myśl tego orzeczenia dziennikiem.
Absurd? Oczywiście. Nie pierwszy raz zresztą w naszym pięknym kraju powstaje prawo, które z logiką i zdrowym rozsądkiem ma niewiele wspólnego. Tak przynajmniej wydaje się na pierwszy rzut oka. Pomyślmy na przykład o sytuacji, w której istnieje strona dynamicznie generowana po stronie serwera – za każdym razem z inną zawartością – którą autor porzucił kilka lat wcześniej; czy ona nadal jest dziennikiem? A gdzie się “kończy” jeden serwis internetowy, a “zaczyna” drugi? To przecież niezbędne do określenia, ile tytułów należy zarejestrować! A jak określić nakład takiego “tytułu prasowego”? I tak dalej, i tak dalej…

Pomińmy to jednak i zastanówmy się, jakie konsekwencje miałoby zarejestrowanie wszystkich serwisów internetowych jako czasopism lub dzienników. Przede wszystkim nikt nie mógłby prowadzić np. anonimowego bloga, bo po jego nazwie z łatwością można by dotrzeć do “redaktora naczelnego”. Mit anonimowości w sieci jest naturalnie już dawno tylko mitem, jednak obecnie dotarcie do autorów treści publikowanych w Internecie wymaga interwencji służb porządkowych, zatem dotyczy tylko treści zabronionych przez prawo. W sytuacji gdy serwis jest tytułem prasowym, każdy może dotrzeć do tej informacji.
Ale to jeszcze nie wszystko. Najciekawiej wygląda połączenie pomysłu rejestracji stron jako prasy z utrąconym na szczęście projektem ustawy lustracyjnej. Zawarta w niej definicja dziennikarze obejmuje każdego, kto kiedykolwiek przesyłał jakiekolwiek materiały dowolnemu tytułowi prasowemu… Czy zamieszczanie niusów, komentowanie artykułów czy nawet wypowiadanie się na forum dyskusyjnym jest takim “dostarczaniem materiałów”? Jeśli serwisy internetowe są tytułami prasowymi, to czemu nie?

Tak oto wszyscy mogliśmy nagle stać się dziennikarzami. Pomyślmy, jakie wrażenie wywierałaby wtedy taka oto pozycja w CV:

2004 – 2007: intensywnie komentowałem wszelkie artykuły w Onet.pl jako czuly_wojtek

Kariera gwarantowana ;]

System GUI #5 – Okno

Dawno temu w firmie Xerox wymyślono, że interfejs użytkownika można zapakować w zestaw prostokątnych, nakładających się na siebie okien. Pomysł okazał się niezwykle trafiony i zaowocował nawet wielce kreatywną nazwą pewnego systemu operacyjnego ;) Od tamtej pory trudno sobie wyobrazić zaawansowane UI posługujące się czymś innym niż właśnie zestawem okien.

Nie jest trudno otrzymać na ekranie puste okno. W środowiskach RAD – w rodzaju Visual C# czy Delphi – mamy je najczęściej dane automatycznie, gdy tworzymy nowy projekt. W przypadku programowania niewizualnego (jak np. z użyciem czystego Windows API) sprawa jest nieco bardziej skomplikowana, ale i tak zamyka się w nie więcej niż kilkudziesięciu linijkach.
Takie puste okno wydawać się może mało interesujące czy wręcz zbyt oczywiste, aby zwracać na nie uwagę. Rzadko zwracamy uwagę na to, że ten pozornie trywialny prostokąt sam w sobie potrafi bardzo wiele. Wśród typowych możliwości mamy chociażby:

• przesuwanie za pomocą przeciągania za pasek tytułu
• zmianę jednego z wymiarów poprzez przeciąganie brzegów
• zmianę obu wymiarów poprzez przeciąganie rogów okna

   

• minimalizacja, maksymalizacja i zamykanie okna przyciskami na pasku tytułu

Uzyskanie podobnej funkcjonalności, zaczynając od zera, jest bardziej pracochłonne niż może się wydawać. W moim przypadku otrzymanie czegoś, co przypomina w pełni funkcjonalne i interaktywne okno, zamknęło się w ok. dwóch tysiącach linijek kodu – nie licząc oczywiście modułu grafiki 2D, potrzebnego do rysowania okien.
To całkiem sporo. Skutkiem ubocznym tej pisaniny jest też to, że obecnie patrzę na stare poczciwe okna systemu Windows z nieco większym respektem :)

Autopowitanie

W programie mIRC – kliencie IRC dla Windows – możemy definiować sobie przeróżne skrypty wywoływane przez komendy rozpoczynające od znaku backslash. Zintegrowany z programem język jest wprawdzie wybitnie toporny składniowo, ale oferuje całkiem spore możliwości.

Pozwala on na przykład definiować sposób, w jaki program ma reagować na pewne zdarzenia. Tego typu odpowiedzi programujemy za pomocą wbudowanego w program edytora skryptów. Wystarczy wybrać z menu Tools | Script Editor i przejść na zakładkę Remote, by wyświetlić i edytować plik remote.ini.
Możemy tam wpisać np. taką linijkę:

W ten sposób stworzymy prosty mechanizm automatycznego odpowiadania na powitania wypowiadane przez nowo przybyłych na kanał IRC. Bardzo podobnie można też – będąc opem lub halfopem – stworzyć prosty filtr wykopujący userów, którzy w wypowiedziach użyją przekleństw czy innych niedozwolonych słów.

Losowanie tabelkowe

W niemal każdym programie chociaż raz zdarza się potrzeba, by “rzucić kośćmi” i pozwolić, by wydarzyło się coś losowego. Oznacza to skorzystanie z generatora liczb pseudolosowych, aby uzyskać ‘przypadkową’ wartość. Nie będzie ona faktycznie losowa, lecz dzięki zastosowaniu matematycznych formuł o dużej nieregularności rezultat może być bardzo zbliżony do ideału. Istnieje oczywiście wiele algorytmów wyznaczania liczb pseudolosowych, różniących się faktyczną przypadkowością uzyskiwanego wyniku.
W różnych językach programowania mamy natomiast odmienne sposoby na uzyskanie liczby ‘losowej’. Zwykle najwygodniejszym jest wartość z zakresu [0..1], bo odpowiada to matematycznemu pojęciu prawdopodobieństwa. Aby w C++ uzyskać taki rezultat, wystarczy napisać proste opakowanie na biblioteczną funkcję rand:

Mając taki generator, możemy już łatwo sprawdzić, czy “zdarzyło się” coś, czego prawdopodobieństwo znamy:
// doświadczenie losowe z określonym prawdopodobieństwem
bool RandomOccured(float fProbability) { return Random() <= fProbability; }[/cpp] W ten sposób możemy na przykład rzucać wirtualną monetą. Sprawa się jednak komplikuje, jeżeli możliwych wyników doświadczenia jest więcej, a przy okazji mają one różne prawdopodobieństwa zajścia. Tak się dzieje na przykład w grach RPG, w których konieczne jest obliczanie rezultatów zadanych ciosów (trafienie, pudło, unik, blok, itp.). Skuteczność postaci w walce zależy zwykle od jej statystyk, więc szanse poszczególnych wyników nie są stałe i zmieniają się w trakcie gry.
Dobre generatory liczb pseudolosowych są zaś nierzadko względnie kosztowne obliczeniowo. Dlatego zamiast wykonywać po jednym losowaniu dla każdego możliwego rezultatu (zaszedł – nie zaszedł), znacznie lepiej jest załatwić wszystko jednym losowaniem. Nie jest to trudne:
// doświadczenie losowe z prawdopodobieństwem określonym tabelką
int RandomResult(const float* aProbs, int n)
{
float fRand = Random();

float fAccum = 0.0f;
for (int = 0; i < n; ++i) { // sprawdzamy, czy wylosowana liczba mieści się w zakresie p-stwa if (fAccum <= fRand && fRand < fAccum + aProbs[i]) return i; fAccum += aProbs[i]; } // błąd return -1; }[/cpp] Tak naprawdę liczymy tutaj dla każdego możliwego rezultatu wartość tzw. dystrybuanty. Ale chyba nie warto wnikać w takie teoretyczne szczegóły – grunt, że powyższa metoda działa w praktyce :) Trzeba tutaj jednak pamiętać, aby prawdopodobieństwa sumowały się do 1. Jeśli tak nie jest, można przeskalować wylosowaną liczbę.

Bolączki C++ #1 – Pimp(l) my code

Kiedy programuje się w języku, który jest – jak to ładnie mówią Amerykanie – ‘standardem przemysłowym’ w danej dziedzinie, chcąc nie chcąc trzeba się do niego przyzwyczaić. A to oznacza, że musimy nauczyć się żyć z jego wadami, które niekiedy mogą być tylko irytujące, a niekiedy bardzo nieprzyjemne. Ważne, by mieć świadomość ich istnienia i w miarę możliwości sobie z nimi radzić.
C++ jako ustandaryzowany język ma już prawie dziesięć lat, więc lista jego niedoskonałości w porównaniu z nowszymi językami siłą rzeczy staje się coraz dłuższa. Takie listy są jednak w dużym stopniu subiektywne, zatem i ten, który rozpoczynam poniżej, absolutnie nie pretenduje do miana ostatecznej wyroczni :) Na pewno inni usunęliby z niego część pozycji, niektóre uznali za mniej lub bardziej dotkliwe, a także dodali własne propozycje.

Dla mnie sprawą, która w C++ jest powodem największego bólu zębów, jest sposób organizacji kodu zaproponowany w tym języku. Jest on bodaj jedynym mi znanym (poza swoim poprzednikiem C), w którym występuje podział plików z kodem na dwa rodzaje: pliki nagłówkowe (*.h, *.hpp) i moduły kodu (*.cpp). W tych pierwszych teoretycznie umieszczany jest interfejs klas i funkcji, czyli informacje potrzebne do ich użycia w innym miejscu programu. W tych drugich jest zaś zawarta implementacja rzeczonych klas oraz funkcji.
Tyle teorii. W praktyce osiągnięcie idealnej separacji obu tych elementów wymaga sztuczki nazywanej szumnie wzorcem projektowym, o nazwie Pimpl (skrót od private implementation). Wygląda on na przykład następująco:

Wtedy faktycznie nie widać, co siedzi w środku naszej klasy, ale cena takiej hermetyzacji to konieczność stworzenia dodatkowej klasy i przekierowania do niej metod. Może nie jest to dwa razy więcej roboty, ale przynajmniej 10-20%.
Z drugiej strony większość języków nowszych niż C++, jak Java, C# czy Python, w ogóle zna takich pojęć jak ‘prototyp funkcji’ czy ‘deklaracja zapowiadająca’. Tam kod piszemy od początku do końca: funkcję zawsze z jej treścią, a klasę zawsze w całości łącznie ze wszystkimi polami i kodem wszystkich metod. Nie ma podziału na pliki z ‘interfejsem’ i z implementacją.
A w C++ ten podział istnieje i tak naprawdę służy on tylko i wyłącznie… wygodzie kompilatora. Dzięki temu, że treść plików nagłówkowych jest taka, a nie inna (i np. zawierają one deklaracje prywatnych pól klas, które są przecież częścią implementacji), mogą być one zwyczajnie dołączane do modułów przy pomocy arcyprymitywnej dyrektywy #include. Dla kompilatora jest to najprostsze rozwiązanie, bo może on pracować nad każdym modułem osobno i nie musi się martwić żadnymi niejawnymi zależnościami między plikami. A dla programisty oznacza to wybór między wygodą kodowania, a jakością i “odpornością” stworzonego kodu.

C++ stoi więc w pewnym sensie pośrodku i wcale nie jest to złoty środek. Z jednej strony mógłby pójść w kierunku wyznaczonym przez wspomniane nowsze języki, czyli wprowadzenia jednego typu plików źródłowych, zawierających kod bez podziału na deklaracje i implementacje. To by było jednak mało oryginalne :) Bardziej interesujące byłoby, jak sądzę, polepszenie istniejącego rozwiązania w odwrotnym kierunku; być może automatyczne stosowanie wzorca Pimpl dla każdej klasy jest jednym ze sposobów.
Niestety, patrząc na obecny roboczy szkic standardu C++0x, w którym nic na ten temat nie znajdziemy, nie możemy raczej oczekiwać, że coś tu się zmieni w przewidywalnej przyszłości.