Gadu gadu Skype

Archiwum dla 03.2011

mar
27

Reusability? Tak, ale z głową

Spook, Marzec 27 2011

Napisz komentarz

Moim pierwszym pecetem był 486 DX/33 wyposażony w dysk twardy o pojemności 300 Mb oraz w 8 Mb RAMu. Choć wydaje się, że jest to bardzo mało, konfiguracja ta była w zupełności wystarczająca, by uruchomić na niej Windows 95. Ponieważ w czasie, który wspominam, funkcjonowała jeszcze zasada Moore’a, kolejny sprzęt, który postawiłem na biurku był już wyposażony w procesor Intel Celeron (800 Mhz) oraz 392 Mb RAMu, co umożliwiło zainstalowanie na nim bodaj najpopularniejszego do tej pory systemu, Windowsa XP.

Współczesne komponenty komputerów stacjonarnych – w porównaniu z czasami, o których wcześniej wspomniałem – są wyjątkowo tanie. Szukałem ostatnio cen RAMu; 4 Gb (czyli maksymalna ilość, którą można zaoferować 32-bitowemu systemowi) całkiem przyzwoitej firmy kosztuje w tej chwili około 160 PLN. Gwałtownego spadku cen doświadczyłem też kupując dyski twarde. Obecnie mam zainstalowane trzy: 80, 160 i 250 Gb. Wszystkie są tej samej firmy, wszystkie kupiłem praktycznie w takiej samej cenie (błąd około 10 PLN), tyle że pomiędzy poszczególnymi zakupami mijał mniej więcej rok czasu. W tej chwili za tą samą cenę można kupić dysk o pojemności 1 Tb.

Kiedyś jednak cena jednego bajtu – czy to zaszytego w kości pamięci, czy też na dysku twardym – była znacznie wyższa. Komputery PC były bardzo popularne, ale programista pisząc programy musiał brać pod uwagę, iż będą uruchamiane w środowiskach ubogich w zasoby; na porządku dziennym była walka o każdy, pojedynczy bajt używanej pamięci operacyjnej.

Wówczas właśnie zrodziła się idea reusability. Polegała ona z grubsza na osiąganiu oszczędności podczas korzystania z zasobów poprzez wielokrotne ich używanie. Sprowadzało się to na przykład do wielokrotnego używania jednej zmiennej do wielu różnych celów. Tym sposobem zadeklarowany na początku bloku int i najpierw służył jako iterator w pętli, następnie stawał się pośrednikiem dla danych wprowadzanych do programu przez użytkownika, by zakończyć życie jako zmienna przechowująca sumę elementów potrzebnych do obliczenia średniej jakiegoś zestawu danych. Uderzało to znacząco w czytelność kodu źródłowego, ale było też czasami jedyną metodą na zrealizowanie zamierzonego celu. Powiem więcej – metoda ta funkcjonuje z powodzeniem do dnia dzisiejszego w sytuacjach, gdy zasoby dostępne dla programisty są mocno ograniczone – na przykład podczas oprogramowywania różnego rodzaju prostych procesorów.

Współczesne trendy programowania bardzo mocno odbiegają od niegdysiejszych, jeśli weźmiemy pod uwagę ilość zużywanych zasobów. Dosyć powiedzieć, że programy na popularne w tym momencie systemy operacyjne dla urządzeń mobilnych (Android, Windows Phone 7) pisze się teraz w językach przeznaczonych dla maszyn wirtualnych, nie zaś w języku kompilowanym do rozkazów procesora. Kiedyś dla wszystkich systemów opartych na Windows CE można było pisać w C++, teraz programy dla Windows Phone 7 uruchamiane są na wirtualnej maszynie .NET postawionej na urządzeniu. Programy dla Androida, z kolei, pisze się w Javie. Żadną tajemnicą jest fakt, iż programy takie pracują nieco mniej wydajnie, niż gdyby ich rozkazy wykonywał sam procesor. Ale jakie ma to znaczenie w erze, w której na rynek niebawem ma zostać wprowadzony telefon z dwurdzeniowym procesorem i spadek wydajności programu jest prawie nieodczuwalny?

Ponieważ dawna reusability (w kontekście implementacji kodu źródłowego) straciła sens, współcześnie pojęcie reusability zostało uogólnione i jest interpretowane w zupełnie inny sposób. Programowanie stało się bardzo istotną gałęzią przemysłu, więc jak grzyby po deszczu zaczęły powstawać różne techniki pozwalające na zwiększenie wydajności pracy programistów i ograniczenie kosztów produkcji oprogramowania. Jedna z nich polega na skupieniu się na modularnej konstrukcji architektury programu. Każdy z modułów musi w jak najmniejszym stopniu zależeć od innych, jednocześnie realizując pewien zamknięty zestaw zlecanych mu zadań. Tym sposobem istnieje możliwość wyekstrahowania go z jednego projektu i włączenia w drugi, w którym istnieje potrzeba zrealizowania podobnej funkcjonalności. Ponowne użycie tego modułu (reuse) pozwala na znaczne ograniczenie czasu potrzebnego na realizację kolejnego projektu, a to właśnie czas jest teraz najdroższym elementem rozwoju oprogramowania.

Mimo iż pierwotna reusability (w kontekście oprogramowania dla komputerów PC) nie ma zwykle większego sensu i współcześnie jest uznawana za technikę, która poprzez obniżenie czytelności kodu źródłowego przyczynia się do zwiększenia zasobów potrzebnych do realizacji projektu, spotkałem się ostatnio z kilkoma przypadkami jej zaistnienia – których skutki były opłakane.

Mówię teraz o lokalizacji programów, czyli o dostosowaniu ich do różnych języków i kultur, a ściślej – o procesie tłumaczenia interface’u użytkownika. Proces ten odbywa się poprzez ekstrakcję wszystkich ciągów znaków, które pojawiają się w programie, a następnie przetłumaczeniu ich na inny język i włączeniu do zasobów programu. Tym sposobem raz napisany i skompilowany program może być uruchamiany w wielu różnych wersjach językowych – włącznie z przełączaniem ich w trakcie jego pracy. Przykładem takiego programu jest ProCalc 2 dostępny w dziale download: w zależności od wersji językowej systemu operacyjnego uruchomi się on z napisami po polsku, po włosku lub – w każdym innym wypadku – po angielsku.

Tłumaczenie interface’u niesie ze sobą również zagrożenia związane z tym, że gramatyki różnych języków są zbudowane w odmienny sposób. Polacy znają tylko trzy czasy, tymczasem ktoś naliczył się u Anglików i Amerykanów aż czterdziestu dziewięciu różnych wariacji na temat czasu przeszłego, teraźniejszego i przyszłego (a czasem nawet ich kombinacji). Z drugiej strony Polak jest w stanie odmienić rzeczownik przez siedem przypadków, podczas gdy Amerykanin korzysta tylko z dwóch – mianownika i – rzadziej – dopełniacza (poprzez dodanie ‚s). Innymi słowy, wyrażenie zapisane tak samo w jednym języku, a mające kilka znaczeń, w innym może wyglądać w każdym przypadku inaczej. Na przykład „Elements saved” oznacza: „Elementy zostały zapisane”. Ale jeśli wyrażenie to wystąpi po liczbie, na przykład: „10 elements saved”, należy je przetłumaczyć nieco inaczej: „10 elementów zostało zapisanych”.

Okazuje się, iż wielu projektantów oprogramowania nie bierze powyższego faktu pod uwagę i podczas ekstrakcji ciągów znaków stosują starą zasadę reusability. Jeśli więc w kilku miejscach w programie (ba, czasem nawet w kilku programach) występuje fraza „Elements saved”, do biblioteki tłumaczeń włączają oni to wyrażenie tylko raz i stosują je wielokrotnie. Tym sposobem tłumacz postawiony jest przed zadaniem niemożliwym do zrealizowania, bo – jak pokazałem wcześniej – nierealne jest przygotowanie tylko jednej wersji tłumaczenia, która będzie pasowała wszędzie.

Wydawałoby się, że opisany przeze mnie problem jest oczywisty i żaden rozsądnie myślący programista nie dopuści do jego powstania. Niestety, najwyraźniej tak nie jest. Otóż bowiem tak doświadczony w projektowaniu wielojęzycznych interface’ów użytkownika developer, jakim jest Microsoft popełnił w swoim programie takie oto tłumaczenie (mowa o wersji release oprogramowania):

Zachęcam do zgadnięcia, o jakim programie mowa, jakie tłumaczenie powinno wystąpić w tym miejscu i z czego wynika zabawna pomyłka tłumacza.

Nieprawidłowe tłumaczenie jest tylko jednym przypadkiem nieprawidłowego stosowania opisanej przeze mnie techniki. W pracy analizowałem kiedyś kod, który pisał dla nas zewnętrzny programista. Stosował on tam archaiczne reusability bez skrępowania i argumentował to zwiększeniem wydajności programu i zmniejszeniem zajmowanych przez niego zasobów. Przesłał nam też tytuł książki, na której bazował wszystkie „optymalizacje” wprowadzone do swojego kodu. Okazało się, iż książka ta traktuje o optymalizowanie kodu dla procesorów Pentium i 486 i została wydana w 1997 roku. Sporo mieliśmy pracy z poprawieniem jego algorytmów tak, by dało się z nimi później pracować.

Nie należy lekceważyć technik związanych z reusability. Pozwalają one na realne ograniczenie czasu pracy programistów. Nawet pierwotną reusability można stosować z powodzeniem w niektórych przypadkach. Jednak – jak to w życiu bywa – technika niewłaściwie zastosowana bardzo szybko obraca się przeciw jej użytkownikowi, utrudniając tym samym pracę nad projektem.

Reusability? Zdecydowanie tak. Ale z głową.

mar
12

Nokia i Microsoft – co z tego wyniknie?

Spook, Marzec 12 2011

Napisz komentarz

Ostatnimi czasy interesuję się wszelkimi wydarzeniami mającymi miejsce w świecie urządzeń, technologii i oprogramowania mobilnego. Nie mógł więc ujść mojej uwagi bardzo kontrowersyjny alians Nokii z Microsoftem.

Jeśli przyjrzymy się historii Nokii z przeciągu ostatnich pięciu lat, alians ten okaże się znacznie mniejszym zaskoczeniem niż mogłoby się to na początku wydawać. Cofnijmy się na chwilę do roku 2007. Nokia jest u szczytu swoich możliwości, kończy rok ze sprzedanymi przeszło 437,1 milionami telefonów (drugi jest Samsung utrzymujący się na poziomie 161,2 milionów, źródło). Pod koniec października 2007 roku kurs akcji Nokii osiąga wartość nie notowaną od pięciu lat – blisko 40 USD. I aż trudno uwierzyć, że właśnie w takich okolicznościach zaczyna się wielki upadek tej popularnej firmy.

Jest 9 stycznia 2007 roku. Apple, po długim okresie domysłów i plotek ogłasza, iż pracuje nad projektem nowego, rewolucyjnego telefonu – iPhone’a. Musi minąć jeszcze przeszło pół roku, żeby telefon ten trafił na rynek, jednak marketing Apple’a robi swoje: ludzie ustawiają się w kolejkach przed sklepami nawet na sto godzin przed premierą, stoisk z nowymi telefonami spod znaku jabłuszka w nocy poprzedzającej premierę strzeże policja i ochrona. iPhone – mimo dosyć wysokiej ceny – sprzedaje się w zastrzaszającym tempie: 74 dnia po premierze został sprzedany milionowy egzemplarz.

Na czym polegał sukces Apple’a? Oczywiście marketing odegrał tu swoją rolę. Jednak Apple uderzył w rynek innowacją: postawił na ekran dotykowy (wprawdzie takie telefony były już wówczas na rynku, ale niezbyt popularne), skonstruował atrakcyjny, efektowny i użyteczny interface użytkownika przystosowany do obsługi palcami oraz wyeksponował multimedialne cechy urządzenia: bardzo duży ekran (jeśli dobrze pamiętam, największy w urządzeniu tego typu w czasie premiery) oraz dużo pamięci przeznaczonej do przechowywania multimediów. Urządzenie nie było bez wad – do głównych zaliczany był brak schowka, niemożność wysyłania MMSów, a także zamknięcie możliwości instalowania oprogramowania firm trzecich, które nie przeszło procesu cyfrowej certyfikacji, nie przeszkodziły one jednak w wielkim sukcesie Apple’a.

Czy iPhone był naprawdę tak dobry, żeby zacząć wypierać z rynku telefony Nokii? Myślę, że raczej nie. Nokia była w stanie zaprojektować i wypuścić na rynek telefon o podobnych (albo nawet i lepszych) parametrach i pozbawiony wad iPhone’a. Jednak w kierownictwie Nokii ktoś popełnił poważny błąd, ponieważ z wielkiego sukcesu iPhone’a nie wyciągnięto wniosków i Nokia nie zmodyfikowała swojej rynkowej strategii, aby sprostać nadchodzącym wyzwaniom.

Co dzieje się dalej? Nokia wydaje na świat model 5800, który stał się pierwszym telefonem z ekranem dotykowym, który został przyjęty pozytywnie przez rynek (Nokia 7700 nigdy nie weszła do sprzedaży, zaś 7710 z Symbianem S90 nie odniósł większego sukcesu). Telefon nie miał jednak szans konkurować z iPhone – był raczej ewolucją niż rewolucją w stosunku do poprzednich modeli, ponadto do użytkowania potrzebował czasem rysika, podczas gdy iPhone został zaprojektowany pod obsługę przy pomocy palców. Ponadto sukcesowi marketingowemu – jak na złość – przeszkodziła wadliwa konstrukcja słuchawki, która przestawała działać po bardzo krótkim czasie. Nokia oczywiście zadziałała szybko i umożliwiła darmową wymianę wadliwego komponentu, jednak wydarzenie to z pewnością wpłynęło na statystyki sprzedaży.

Po umiarkowanym sukcesie modelu 5800 Nokia postawiła na telefony z serii N (od eNtertainment) – lata 2008 i 2009 przyniosły modele N78, N79, N85, N96, a także N97. Jednak wszystkie stanowiły tylko wariacje na temat: zmieniała się wersja systemu, parametry sprzętowe i rozdzielczość wbudowanego aparatu fotograficznego, ale nadal brakowało czegoś nowego, rewolucyjnego.

Tymczasem konkurencja Nokii nie spała, a wręcz przeciwnie – różne firmy prześcigały się w pomysłach na „iPhone killera”.

W trzecim kwartale 2009 roku pojawia się popularny Samsung Omnia. Czwarty kwartał to premiery telefonów z Androidem, między innymi Motorola Droid oraz HTC Hero. Początek roku 2010 zaznaczył się wejściem do sprzedaży telefonu Google Nexus One, a niedługo potem Sony Ericsson zaatakowało rynek XPerią X10. I dopiero po tych wszystkich premierach, pod koniec 2010 roku Nokia zaczyna wprowadzać telefony nowej generacji, z systemem Symbian^3: Nokię N8, a niedługo potem C7 i E7 (która, moim zdaniem niesłusznie, odziedziczyła po świetnej serii handheldów miano Communicator).

Rynek był jednak bezlitosny wobec Nokii i długi okres stagnacji, gdy fińska firma wypuszczała jeden po drugim telefony różniące się głównie wyglądem, mocno odznaczył się w historii finansowej firmy. Wystarczy tylko popatrzeć na kurs akcji Nokii w okresie od 2007 roku do dziś.

Źródło: www.dailyfinance.com

Jest początek roku 2011. Nokia systematycznie traci zainteresowanie rynku, konkurencja co chwilę wprowadza telefony, które budzą wielkie zainteresowanie, zaś premiery fińskiego producenta przechodzą bez większego echa. Nokii potrzeba rewolucji – czegoś, co wstrząsnie rynkiem. I w takich właśnie okolicznościach decyduje się ona na sojusz z Microsoftem.

Nie zdziwiłem się specjalnie, że Nokia wykonała tak gwałtowny ruch, ponieważ było to dla niej mniej więcej jak być lub nie być, natomiast zachodziłem w głowę, dlaczego fiński producent nie zdecydował się na bardzo popularnego Androida, tylko na odsuniętego w tło Windows Phone 7. Wszystko stało się jasne, gdy przeczytałem, kim był wcześniej obecny CEO Nokii, pan Stephen Elop.

Proponuję zobaczyć, jak zareagował rynek na opublikowaną 11 lutego decyzję o aliansie Nokii i Microsoftu.

Moim zdaniem decyzja Nokii to zdecydowany strzał w kolano. Po pierwsze, system Microsoftu nie zyskał zbyt dużej popularności; najlepszym epitetem, którego można użyć do określenia interface’u użytkownika WP7 jest „ascetyczny”. Wystarczy zobaczyć, jak wyglądają pewne wspólne elementy każdego systemu mobilnego w Symbianie, Androidzie i Windows Phone 7:

Ekran główny
Menu
Kontakty
Ustawienia

Screenshoty z Nokia RDA, Android Emulator oraz dzięki uprzejmości MicrosoftFeed.com

Windows Phone nie przegrywa jednak z innymi systemami tylko z powodu swojego interface’u. Większym problemem jest fakt, iż wszystkie technologie Microsoftu są zamknięte, tymczasem zarówno Symbian jak i Android są systemami otwartymi, w każdej chwili można z Internetu ściągnąć kompletne kody źródłowe każdego z nich.

Jest jeszcze jeden problem. Miarą współczesnego systemu operacyjnego dla urządzeń mobilnych jest liczba developerów, którzy piszą dla niego oprogramowanie. Nokia udostępnia SDK Symbiana darmowo na swoich stronach, a poza tym na Symbiana można pisać w QT. Poza tym programy napisane dla Symbiana można bez problemu publikować i każdy może instalować je bez większych ograniczeń (w przypadku programów korzystających np. z połączeń telefonicznych lub wysyłających SMSy wymagana jest certyfikacja). Google również udostępnia kompletny SDK dla Androida; ba, istnieje nawet odpowiedni plugin do Eclipse’a pozwalający na łatwe projektowanie i programowanie aplikacji. Oczywiście programy również można bez ograniczeń publikować w postaci pakietów apk.

Microsoft jednak nie przepuścił okazji do zysku. Wprawdzie, jeśli chodzi o środowisko programistyczne, pobił na głowę zarówno Symbiana, jak i Androida, ponieważ udostępnił darmowo specjalną wersję Microsoft Visual Studio przeznaczoną do pisania programów dla Windows Phone 7. Na tym jednak kończy się otwartość tej firmy: żeby zainstalować napisany przez siebie program na fizycznym urządzeniu, trzeba je najpierw odblokować. Aby jednak mieć taką możliwość, trzeba być zarejestrowanym developerem Windows Phone 7, co wiąże się z rocznymi opłatami (obecnie $99). Ale i na tym nie koniec; odblokować można tylko kilka urządzeń do celów deweloperskich, natomiast publikowanie programów może odbywać się tylko przez Microsoft Marketplace. Warto wspomnieć o jeszcze jednym ograniczeniu: zarejestrowany deweloper może opublikować tylko 100 darmowych programów, za publikację każdego kolejnego musi zapłacić $19.99 (ograniczenie to nie dotyczy programów płatnych).

Jestem fanem Nokii od mojego pierwszego telefonu. Przez moje ręce przeszły modele 3210, 3510i, N-Gage, 6230i, E66 i C7. Obawiam się jednak, że moja przygoda z tą marką ma się już ku końcowi. Ponieważ zbliża się termin przedłużenia umowy abonamentowej, mam możliwość wybrania nowego telefonu i będzie nim najprawdopodobniej HTC Desire Z lub HTC Desire HD z Androidem na pokładzie – zainstalowałem już Eclipse i Netbeans, aby nauczyć się pisać aplikacje na tą platformę.

Strategia Nokii jest bardzo ryzykowna. Będziemy musieli jednak poczekać jeszcze trochę, by dowiedzieć się, czy firma ta zaskoczy nas niedługo jakimś nowym, rewelacyjnym telefonem, który pozwoli jej wrócić na falę, czy jednak Windows Phone 7 stanie się ostatnim gwoździem do trumny tego bardzo popularnego niegdyś producenta komórek.