Archive for Thoughts

Google I/O Extended 2011 w Warszawie

2011-05-11 9:47

Wczoraj miałem okazję wziąć udział w imprezie Google I/O Extended 2011. W dużym skrócie polegała ona wspólnym oglądaniu (i późniejszej dyskusji) live streamu z konferencji Google I/O w San Fransisco, na której tytułowa firma prezentuje nowe rozwiązania technologiczne, mające pojawić się w powszechniejszym użyciu w najbliższych miesiącach. Nie będę specjalnie rozwodził się na temat treści tych prezentacji, bo można się do nich z łatwością dostać, czytając niusy z dowolnego serwisu technologicznego. Wspomnę tylko o ciekawostkach, które szczególnie zwróciły moją uwagę, a są to:

  • Usługa streamowania swojej własnej muzyki z “chrmury” na dowolne urządzenie (komputer, telefon, itp.), po uprzednim załadowaniu plików – czyli Google Music. Z jej najważniejszych cech należy wymienić przede wszystkim to, że jest dostępna wyłącznie w USA :P
  • Android Open Accessories i ADK – otwarta (przynajmniej w sensie androidowym) platforma programowo-sprzętowa, umożliwiająca tworzenie urządzeń, gadżetów i różnych innych akcesorii, które można następnie kontrolować za pomocą telefonów i tabletów z systemem Android (od 3,1 wzwyż). Otwiera to pole do automatyzacji wielu otaczających nas “interfejsów” technicznych, jak na przykład oświetlenie czy sprzęty kuchenne… w mniej lub bardziej odległej przyszłości ;)

Całość imprezy Google I/O Extended 2011 była organizowana przez Google Technology User Group (GTUG) i było to pierwsze poważne wydarzenie pod auspicjami tej grupy. Skorzystam w tym miejscu z okazji i pozwolę sobie na zachęcenie wszystkich mieszkających w jednym z trzech miast z GTUG-iem (Warszawa, Kraków, Poznań) do zainteresowania się działaniami grup i eventami, które będą przez nie organizowane. Zawsze można się czegoś ciekawego dowiedzieć, a może też wyjść z jakimiś fajnymi gadżetami ;-)

Tags: , , ,
Author: Xion, posted under Events, Thoughts » Comments Off on Google I/O Extended 2011 w Warszawie

Xoom, czyli tablety mają swój urok

2011-04-24 18:02

Sprzętowe odkrycie zeszłego roku – tablety – to wynalazek, którego użyteczność wciąż wymykała się moim zdolnościom poznawczym. Ponieważ jednak staram się zwykle być jak najdalej od negowania czegoś, czego do końca mogę nie rozumieć, chciałem już od dość dawna przyjrzeć się sprawie nieco bliżej. Za bliższe poznanie nie może niestety uchodzić kilkadziesiąt minut raczej bezładnego mazania po ekranie iPada (w obu wersjach), zatem postanowiłem na czas świątecznego weekendu wypożyczyć z pracy inne urządzenie tego rodzaju: Motorolę Xoom. Po kilku dniach korzystania z tego gadżetu sądzę, że już mniej więcej rozumiem zamysł stojący za tego typu sprzętem.

I właśnie tym cennym odkryciem chciałem się dzisiaj podzielić :)

Wyroby komputeropodobne

2011-04-12 23:46

Jeszcze sześć, siedem lat temu sprawa była jasna: komputer to takie dużo pudełko stojące pod biurkiem, a także dołączony do niego (niezbyt wtedy duży) monitor oraz klawiatura i myszka. Laptopy wciąż nie były specjalnie powszechne (a przynajmniej nie w Polsce), telefony komórkowe nadal służyły głównie do dzwonienia i SMS-owania, a słowo ‘tablet’ kojarzyło się niemal wyłącznie ze specjalistycznym sprzętem dla grafików.
Od tamtych czasów (wcale nie takich “starych i dobrych”, swoją drogą) zmieniło się jednak bardzo wiele, jeśli chodzi o bogactwo form i rodzajów zaawansowanych urządzeń elektronicznych zbliżonych do komputerów. Okazało się też, że tradycyjne komputery biurkowe to tylko jedna opcji do wyboru i to nawet niekoniecznie główna i preferowana. Krótko mówiąc poczciwe blaszaki przestały być niezastąpione.

Od tego momentu rozpoczął się proces różnicowania urządzeń wciąż nazywanych mniej lub bardziej potocznie komputerami, jak również pojawiania się takich, które dopiero na drugi rzut oka zdają się zasługiwać na to miano. Oprócz aż nazbyt już oczywistych laptopów czy netbooków, a także coraz bardziej popularnych, ale wciąż wątpliwie użytecznych tabletów mamy też nieco bardziej egzotyczne i wyspecjalizowane wynalazki. Interesującą opcją są chociażby e-czytniki, powoli acz nieprzerwanie zmieniające sposób czytania książek, bez wątpienia przyczyniając się zresztą do wzrostu czytelnictwa.
Częstym zarzutem wobec tego rodzaju komputeropodobnych wyrobów jest to, że służą one jedynie do “konsumpcji contentu” (czyli głównie mediów), natomiast domena twórcza zarezerwowana jest wciąż dla pecetów. Wydaje się to przynajmniej częściowo trafioną tezą, jednak powoli i to zaczyna się zmieniać. Powstają nawet takie urządzenia, których twórcze możliwości bardzo ciężko byłoby imitować zwykłym komputerom – jak chociażby swego rodzaju elektroniczna wersja kartki papieru.

Prawdopodobnie najciekawszym aspektem tych przemian form komputerowej elektroniki jest fakt, iż – o ile tylko długoterminowa pamięć nie zawodzi mnie zupełnie – były one w całkiem znaczącym stopniu przewidziane. Szczegóły naturalnie się nie zgadzają, gdyż na początku stulecia modne były raczej prognozy, że urządzenia elektroniczne staną się chociaż w pewnym wymiarze częścią garderoby. Świetnym przykładem są różne “magiczne” funkcje okularów w wielu filmach akcji – jak choćby w początkowej sekwencji Mission Impossible II (rok 2000).
To się oczywiście nie sprawdziło… w powszechnym użyciu (bo prototypy naturalnie są). Myślę jednak, że przy obecnym kierunku ewolucji sprzętu możemy spodziewać się przynajmniej równie efektownych gadżetów w niezbyt odległej przyszłości. Jak zwykle okaże się, iż nie mieliśmy bladego pojęcia, do czego coś może się przydać, dopóki ktoś tego czegoś nie stworzy :)

Tags: , , ,
Author: Xion, posted under Computer Science & IT, Thoughts » 8 comments

Moda na krytykowanie OOP-u

2011-03-19 20:47

Nauczyłem się już lubić fakt, że w przypadku informatyki powiedzenie o “ciekawych czasach” jest truizmem, bo ciekawie jest po prostu zawsze – głównie ze względu na tempo zmian w wielu dziedzinach. Nawet w tych, wydawałoby się, zastygłych na lata. Niecałe trzy lata temu zżymałem się na przykład na zbytnią ufność w doskonałość obiektowych metod programowania. Dzisiaj zaś przychodzi mi robić coś zdecydowanie przeciwnego.
Programowanie obiektowe jest obecnie sztandarowym kozłem ofiarnym i chłopcem do bicia, otrzymującym ciosy z wielu stron. Już nie tylko programiści gier twierdzą, że nie mogą sobie na nie pozwolić ze względu na wydajność i zamiast niego forsują Data Oriented Design. Pokazywałem niedawno, że sprzeczność między tymi dwoma podejściami jest raczej pozorna niż rzeczywista. Teraz natknąłem się na interesującą opinię, która podważa sens OOP-u jako metodologii, wychodząc z nieco innego punktu widzenia niż wydajność dla celów grafiki real-time:

Object-oriented programming (…) is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. [pogrubienie moje]

Anty-modularne i anty-współbieżne? Oczywiście; da się napisać kod obiektowy, który te dwa warunki będzie spełniał doskonale. Ale to nie oznacza, że każdy kod obiektowy je spełnia, a to właśnie jest implikowane powyżej. Nie da się tego określić inaczej niż jako stereotyp – i to w modelowej wersji, czyli negatywnego uogólnienia z pojedynczych przypadków.

Jako antidotum na te rzekome bolączki OOP-u często wymieniane jest programowanie funkcyjne. Nie ujmując mu niczego ze swojej elegancji, nie mogę jednak nie zauważyć, że zamiata ono wiele problemów pod dywan. Określanie wykonania programu jako serii transformacji danych nie rozwiązuje jednak problemu: gdzie i jak te dane mają być zapisywane i chronione przed równoczesnym dostępem z wielu ścieżek wykonania. Sytuacje, w których programowanie funkcyjne lub quasi-funkcyjne sprawdza się dobrze to takie, gdzie problemy te dały się w miarę łatwo rozwiązać. Tak jest chociażby w przypadku vertex i pixel shaderów, gdzie podział danych wejściowych i wyjściowych na rozłączne bloki jest wręcz naturalny. Fakt ten nie jest jednak zasługą programowania funkcyjnego, tylko natury zagadnienia – w tym przypadku renderowania grafiki opartej na wielokątach.

I właśnie o tym powinniśmy pamiętać, gdy wyzłośliwiamy się nie tylko na OOP, ale dowolny inny paradygmat programowania. Otóż porzucenie go nie sprawi od razu, że magicznie zaczniemy pisać kod doskonale modularny. A już nie pewno nie spowoduje, że niezwykle trudne zagadnienia współbieżności staną się nagle banalnie proste. To niestety tak nie działa.
Nie znaczy to oczywiście, że nie powinniśmy poszukiwać nowych, lepszych metodologii do konkretnych zastosowań. Dlatego przecież wiele języków (np. C++, C#, Python) ewoluuje w kierunku wieloparadygmatowości, aby możliwe było dobranie właściwych narzędzi dla danej sytuacji. Nie wydaje mi się jednak, aby uleganie trendy nurtom krytykowania jakichkolwiek rozwiązań poprzez odwoływanie się do stereotypów i nieuzasadnionych wyobrażeń o nich było w tym procesie specjalnie produktywne. Zdaję sobie jednak sprawę, że “funkcje wirtualne to zuo!” brzmi lepiej niż “wywoływanie funkcji wirtualnych skutkuje narzutem wydajnościowym związanym z dodatkowym adresowaniem pamięci (które nie jest cache-friendly) i może powodować niepożądane skutki uboczne, jeśli ich wersje w klasach pochodnych nie są thread-safe“. Mam jednak nadzieję, iż nikt nie ma wątpliwości, które z tych dwóch stwierdzeń jest bardziej racjonalne.

Podziękowania dla Rega za podesłanie linków, które zainspirowały mnie do podjęcia tego tematu.

Regulacja głośności jako porażka funkcjonalna

2011-02-21 19:36

Fajnie jest używać oprogramowania, które da się łatwo dopasować do swoich upodobań – zwłaszcza, jeśli da się to zrobić łatwo, szybko i intuicyjnie, bez konieczności czytania długich manuali. Niestety, konstruowanie interfejsu udostępniającego szeroką funkcjonalność oraz wcześniej wspomniane cechy nie jest łatwe. Dla mnie dobrym przykładem tego, co może pójść źle podczas próby uszczęśliwienia użytkownika mnogością opcją i elastycznością konfiguracji jest banalny na pierwszy rzut oka mechanizm: regulacja głośności dźwięku w komputerach PC.

Problem z nim związany polega – mówiąc ogólnie – na rozbiciu zagadnienia na mniejsze fragmenty (dzięki czemu w teorii uzyskujemy większą kontrolę nad każdym z nich) bez zastanowienia się nad niepożądanymi efektami wzajemnych relacji między tymi fragmentami. Regulacja głośności w komputerach PC występuje bowiem obecnie nie w jednym, a w kilku miejscach. W skrajnych przypadkach może być ich więcej, niż da się policzyć na palcach jednej dłoni, gdy w grę wchodzi:

  • sprzętowe pokrętło głośności, będące częścią słuchawek, zestawu głośników lub kontrolek na obudowie laptopa
  • globalne, systemowe ustawienie głośności dźwięku (w Windows dostępne po kliknięciu na ikonkę w zasobniku)
  • globalne ustawienie głośności regulowane w panelu kontrolnym sterownika karty dźwiękowej
  • systemowy poziom dźwięku ustawiany dla każdego z głośników (centralnego, subwoofera, itd.)
  • systemowy poziom dźwięku ustawiany dla poszczególnych aplikacji lub komponentów systemowych
  • właściwy dla aplikacji (np. gier) poziom głośności ustawiany w samym programie

Ałć. Sporo tego, prawda? W celu usprawiedliwienia tego bałaganu można argumentować, że za prawie każdy z elementów tej listy odpowiada ktoś, jako że znajdują się one w rożnych warstwach abstrakcji. Tak też w teorii powinniśmy je traktować i nawet czerpać korzyści z tego faktu, na przykład poprzez przyciszenie efektów dźwiękowych w grze na rzecz muzyki z działającego w tle odtwarzacza.
Teoria zaś, jak wiemy, niczym nie różni się od praktyki – ale tylko w teorii. W praktyce możemy mieć zupełnie inny przypadek użycia, kiedy na przykład próbujemy rozmowy przez komunikator i stwierdzamy, że nie słyszymy drugiej strony wystarczająco głośno. Będąc rozsądnym użytkownikiem (optymistyczne założenie ;]) udamy się wpierw do ustawień programu i tam wyregulujemy głośność. Ale jeśli to nie pomoże, zapewne w drugim kroku pokręcimy odpowiednim pokrętłem lub przesuniemy globalny systemowy suwak. W konsekwencji następny chord.wav czy inny dźwięk będący częścią UI systemu może nam dostarczyć, mówiąc oględnie, zaskakująco intensywnych wrażeń słuchowych ;)

To jest właśnie przykład niepożądanej interakcji pomiędzy zachodzącymi na siebie fragmentami zagadnienia. Ale w przypadku regulacji głośności nawet pożądane interakcje nie są oczywiste. Czy łatwo jest bowiem określić, w jaki sposób X% nadrzędnego i Y% podrzędnego poziomu dźwięku przełoży się na to, co ostatecznie usłyszymy w głośnikach? Wymaga to chwili zastanowienia, a przecież mówimy tu o czynności, którą powinno się wykonywać automatycznie, bezwiednie i niemal zupełnie nieświadomie! Nie spodziewam się też, aby statystyczny użytkownik miał jakiekolwiek pojęcie o istotnym tutaj prawie Webera-Fechnera, które dodatkowo wpływa na faktycznie słyszaną intensywność wynikowego dźwięku.

Z tych wszystkich narzekań wyłania się wniosek, że regulacja głośności w PC-tach to zagadnienie o sztucznie zawyżonym poziomie komplikacji. Mogłoby ono być znacznie prostsze, gdyby nie obciążono go balastem pozornej konfigurowalności. Jako dobry przykład może służyć analogiczny mechanizm w telefonach, opierający się na dokładnie jednej sprzętowej kontrolce poziomu dźwięku (np. przyciskach) i braku zależności między poszczególnymi ustawieniami (np. multimediów, dzwonka czy rozmowy).

Tags: , ,
Author: Xion, posted under Computer Science & IT, Thoughts » 9 comments

Dwa podejścia do technologii

2011-02-05 1:36

Tematy związane z technologiami komputerowymi są zaskakująco często motywem wielu zażartych sporów między ich użytkownikami. Nie jest to w sumie nowość, bo tak zwane święte wojny są niemal tak stare, jak szeroko pojęta kultura hakerska – a więc liczą sobie dziesiątki lat. Teraz jednak wspomniane technologie są wszędzie i w związku tym dyskusje między zwolennikami poszczególnych rozwiązań zataczają o wiele szersze kręgi. Wydaje mi się też, że w przeważającej części inny jest też ich charakter. Zaryzykuję też twierdzenie, że wiele z nich – w tym te najbardziej prominentne – maja u swych podstaw jedną przyczynę, której uczestnicy sporów nie są najczęściej świadomi.

Uważam mianowicie, że istnieją dwa wyraźnie różne podejścia do rozwiązań technologicznych dowolnego rodzaju. Z braku lepszych terminów określę je mianem geeka i laika. To właśnie zasadnicze różnice w postrzeganiu nowoczesnych technologii między tymi dwoma podejściami są, według mnie, główną przyczyną zażartych, często jałowych i zawsze niekonkluzywnych pojedynków na słowa.
Doprecyzowując, chodzi o priorytety: skłonność do poświęcenia pewnego zbioru cech produktów, rozwiązań i technologii na rzecz innego zbioru właściwości. Nie muszą to być zresztą własności ze sobą sprzeczne, ale zwykle każdy ze zbiorów może być dość jednoznacznie przypisany do jednego konkretnego rozwiązania z danej kategorii.

W przypadku, gdy mówimy o laiku, pożądanymi własnościami będą przede wszystkim: atrakcyjne wykonanie, bezproblemowe działanie i prostota obsługi. To będą główne kryteria, jakimi kierować się będzie osoba reprezentująca to podejście i będą one wpływały na dokonywane przez nią wybory konkretnych opcji spośród wielu możliwości.
Przykłady oczywiście znaleźć nietrudno. Jeśli ktoś reprezentuje taką postawę, to będzie używał raczej systemu Windows (lub OS X-a) niż Linuksa; przeglądał sieć raczej za pomocą Chrome’a niż Firefoksa; posługiwał się raczej iPhonem niż innym rodzajem smartphone‘a; preferował raczej laptopy lub tablety niż komputery stacjonarne – i tak dalej, żeby wspomnieć tylko o tych najbardziej rozgrzewających Internet debatach.
Dla geeka cennymi wartościami będzie natomiast zupełnie inny zestaw: elastyczność, rozszerzalność i szerokie pole manewru w zakresie dostosowywania do specyficznych potrzeb. To zaś potencjalnie koreluje z opcjami, które w wymienionych wcześniej alternatywach były określone jako mniej prawdopodobne.

Te dwie postawy nie są w żadnym wypadku wykluczające się – zwłaszcza wtedy, gdy przejawiają się wyborami w osobnych, mało związanych ze sobą dziedzinach. Sądzę jednak, że przewaga częstości występowania jednej lub drugiej mogłaby sugerować związek z jakimiś bardziej fundamentalnymi cechami charakteru czy osobowości danej osoby. Przy okazji należałoby oczywiście oszacować wpływ takich czynników jak podatność na działania marketingowe czy łatwość zmiany przyzwyczajeń.
W sumie więc mógłby to być interesujący temat do badań porównawczych, potencjalnie skutkujący gazetowymi nagłówkami w stylu: Amerykańscy naukowcy odkryli, że użytkownicy Linuksa jedzą więcej fistaszków ;-)

Duże i małe commity

2011-01-29 23:49

Mam ciekawą obserwację związaną ze sposobem używania różnych systemów kontroli wersji. Dokładniej mówiąc, chodzi o dość wyraźną różnicę w częstotliwości commitów między zwykłymi a rozproszonymi VCS-ami. Do tych pierwszych kod commituje się stosunkowo rzadko, ponieważ każda zmiana jest od razu widoczna w publicznym repozytorium. To ma zaś daleko idące konsekwencje, jak choćby natychmiastowa dostępność naszych modyfikacji dla innych osób pracujących nad projektem. Dlatego też trzeba starać się, aby nie wypuścić bubla. Minimalnym wymaganiem jest kompilowalność commitowanego kodu, a dobrze by było, żebyśmy też poddali go choćby wstępnemu testowaniu.

Gdy z kolei pracujemy z rozproszonymi systemami kontroli wersji, możemy teoretycznie robić dokładnie tak samo. Wówczas jednak nie tylko nie korzystamy z faktu posiadania lokalnego repozytorium, ale wręcz dodajemy sobie pracy. Osiągnięcie tego samego efektu (upublicznienia zmian) wymaga bowiem dwóch kroków – dodatkowym jest push, czyli synchronizacja z globalną bazą kodu. Będąc przyzwyczajonym do scentralizowanych VCS-ów można łatwo o nim zapomnieć.
Dlatego też wydaje mi się, że przy systemie rozproszonym warto nieco zmienić nawyki. Commitów można bowiem dokonywać częściej – znacznie częściej. Ponieważ żaden z nich nie wydostaje się automatycznie poza nasz komputer, nie muszą one dodawać kompletnych funkcjonalności albo w pełni poprawiać znalezione wcześniej błędy. Nie muszą działać. Ba, w zasadzie to nie muszą nawet się kompilować. Grunt, żeby zawierały modyfikacje, które wydają nam się warte zachowania i opatrzenia komentarzem. W praktyce w ciągu dnia można w ten sposób wykonać nawet do kilkudziesięciu commitów – w porównaniu do dwóch lub trzech w przypadku pracy z system scentralizowanym.

Czy taka częstotliwość dobrze wpływa na efektywność kodowania? Z początku nie byłem o tym przekonany, ale teraz widzę, że ma ona niewątpliwe zalety. Wykonując częste commity (a zwłaszcza opisując je), programujemy w sposób bardziej zdyscyplinowany. Trochę trudniej jest wtedy napisać wysublimowany, barokowo skomplikowany i ogólnie przekombinowany moduł albo takąż klasę. Mamy raczej większe szanse na to, że poczynimy jakieś realne postępy w pracy nad projektem. Dodatkowo częste “odhaczanie” wykonanych zadań i poczynionych postępów (nawet jeśli są bardzo drobne) jest bardziej motywujące niż oznaczanie zmian rzadkich a duże.
A co jeśli naszą przeszkodą w wykonywaniu częstych commitów jest brak weny twórczej odnośnie komentarzy do nich?… No cóż, wtedy zawsze można poszukać inspiracji tutaj ;-)

Tags: ,
Author: Xion, posted under Programming, Thoughts » 5 comments
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.