Niedawno znowu miałem do czynienia z wybieraniem systemu kontroli wersji (VCS). Spotykam się z tym zagadnieniem średnio raz na rok w różnych okolicznościach i za każdym razem wyboru trzeba dokonywać od nowa. Jest tak głównie dlatego, że od kilku lat mamy do czynienia z prawdziwą eksplozją ilości systemów VCS i wreszcie jest w czym wybierać.

O tym co wybrałem i dlaczego napiszę kiedy indziej, teraz chciałem się skupić na spostrzeżeniu dotyczącym samego procesu wyboru.

Rozproszonych systemów kontroli wersji jest wiele. Przynajmniej cztery stanowią w tej chwili czołówkę: darcs, git, mercurial (hg) i bzr. Zarówno sama technologia śledzenia wersji jak i systemy w tym pomagające są niezmiernie skomplikowane. Mam tu na myśli skomplikowanie samej dziedziny problemu -- nie da się uprościć czegoś, co z natury jest trudne.

Jak zachowuje się umysł ludzki gdy ma dokonać wyboru spośród kilku trudnych do zrozumienia możliwości w niezmiernie skomplikowanym środowisku? Kieruje się intuicją!

Intuicja jest znakomitym sposobem na podejmowanie decyzji i z pewnością w czasach gdy byliśmy rasą polującą na zwierzynę w lesie nie raz ratowała nam życie i napełniała żołądki. Niestety, zawodzi kompletnie przy skomplikowanych technologicznych zagadnieniach. Tu porównywać powinniśmy starannie, krok po kroku, robiąc notatki, wypełniając tabele. Nic na skróty.

Tymczasem warto poczytać fora dyskusyjne albo posłuchać dowolnej dyskusji informatyków na temat systemów DVCS. “git jest za skomplikowany żeby się go dało używać”, “darcs jest wolny”, “mercurial jest jedynym sensownym systemem, jest wspaniały, a reszta jest gorsza”, “bazaar jest najlepszy, bo jest w pythonie i łatwo go modyfikować” -- to tylko niektóre ze stwierdzeń, jakie już usłyszałem. Problem w tym, że każde z nich wygłaszane było przez osobę, która nie zadała sobie trudu przetestowania kilku systemów! Każdy z wypowiadających się zaczął proces testowania i gdy tylko znalazł jeden system, który w miarę spełniał jego wymagania (i którego się w miarę nauczył), zaprzestawał poszukiwań. Dlaczego? Bo tak jest łatwiej! Trzeba włożyć wysiłek i przełamać się, by nauczyć się kolejnego systemu, umysł intuicyjnie odrzuca wszystko co z nim związane. Ten pierwszy wydaje nam się najlepszy, tylko dlatego, że już włożyliśmy tyle wysiłku w nauczenie się go.

Do tego dochodzi intuicja: jeśli czegoś używa więcej osób, to pewnie jest lepsze. Jeśli strona WWW dotycząca jednego systemu jest lepsza niż innego, to ów system jest lepszy. Jeśli...

Problem dotyczy nie tylko wyboru systemu kontroli wersji. Mnóstwo decyzji technologicznych podejmowanych jest bez odpowiedniego zbadania opcji, na podstawie intuicji. Zbyt często też trzymamy się kurczowo pierwszej lepiej zrozumianej opcji, zamiast włożyć wysiłek w zrozumienie wszystkich.

Znacie podobne przypadki? Nie zgadzacie się? Piszcie do mnie.

Oto zdjęcia z Auli 24, ostatniej przed wakacjami. Było tłumnie, więc przydał się balkon, gdzie pomieściła się część uczestników!

Już w najbliższy czwartek druga TechAula! Zapowiada się ciekawie: Marcin Kaszyński opowie o django. Cieszy mnie to, bo od dawna chciałem usłyszeć więcej o django od kogoś, kto sporo go używał. Marcin django używa regularnie i od dawna, co więcej używa go do pisania prawdziwych aplikacji (np. Oiola), więc temat zna doskonale.

Daniel Janus powie o obsłudze błędów. Temat często zamiatany przez programistów pod szafę, w praktyce staje się bardzo istotny gdy mamy klientów płacących za używanie oprogramowania. Daniel ma spore doświadczenie z kilkoma językami oprogramowania, co daje mu też szerokie spojrzenie na ten temat.

Sam zamierzam krótko przedstawić koncepcję kontynuacji oraz pokazać dlaczego są interesującym tematem jeśli chodzi o aplikacje WWW. Będzie krótko, to raczej pilot serialu niż pełnoprawne wystąpienie, ale mam nadzieję zainteresować tematem kilka osób.

Zapraszamy -- warto też powiedzieć o spotkaniu znajomym programistom, bo nie każdy czytuje blogi.

Oto zdjęcia z Auli 23, która odbyła się wczoraj. Przy okazji przypomnę, że już za tydzień druga TechAula -- program pojawi się wkrótce na http://aulapolska.pl/. Będzie znowu o pisaniu aplikacji WWW: django i nie tylko!

Inauguracyjna KreoAula odbyła się wczoraj. Publiczność dopisała, sala była wypełniona po brzegi. Interesująco rozwinęła się też dyskusja panelowa, w której uczestniczyło sporo osób z publiczności. Skrócona wersja fotoreportażu w sekcji “Photography”...

Krótki fotoreportaż z Międzynarodowego Pikniku Lotniczego Góraszka 2008.

W świecie technologii często zdarza się, że względy inne niż czysto
merytoryczne decydują o tym, która technologia się upowszechni.

Miałem okazję ostatnio porównać ze sobą dwa mechanizmy zabezpieczeń
systemu Linux: SELinux (Security-Enhanced Linux) i AppArmor. Oba
przedstawiane są jako pełnoprawne rozwiązanie kontroli dostępu.

Systemy UNIX tradycyjnie opierają się na nieskomplikowanej kontroli praw
dostępu: każdy element w systemie plików ma prawa dostępu dla
użytkownika, grupy oraz wszystkich pozostałych. Nie zawsze to jednak
wystarcza -- z powodu częstych problemów z bezpieczeństwem
poszczególnych aplikacji, często potrzebne jest ograniczenie praw
dostępu konkretnym programom wyłącznie do niezbędnych dla nich plików,
czy urządzeń w systemie. Co ważniejsze, istotnym problemem w systemach
UNIX jest wszechmocny administrator (root), który ma nieograniczony
dostęp do wszystkiego.

Mechanizmy MAC (Mandatory Access Control) pozwalają na ograniczenie praw
dostępu. Poprzez zdefiniowanie polityki bezpieczeństwa można pozwolić
konkretnym aplikacjom na dostęp do konkretnych elementów systemu,
niezbędnych im do pracy. Co więcej, możliwe jest zdefiniowanie takiej
polityki bezpieczeństwa, w której nie ma wszechmocnego administratora, a
zmiana polityki bezpieczeństwa nie jest możliwa bez restartu systemu i
fizycznego dostępu do niego. Dla systemu Linux powstały dwa mechanizmy
typu MAC: SELinux i AppArmor.

SELinux jest rozwiązaniem nieco starszym. Początkowo opracowane w NSA
(National Security Agency), zostało szybko przyjęte m.in. przez Red Hata
jako rozwiązanie bezpieczeństwa dla systemów Red Hat Enterprise
Linux. Pozwala na zdefiniowanie kompletnej polityki bezpieczeństwa dla
całego systemu i całkowite wzajemne odizolowanie od siebie aplikacji.

AppArmor to alternatywne rozwiązanie, opracowane w firmie Immunix, a
następnie rozwinięte przez Novella. Cele są tu nieco inne niż dla
SELinux: AppArmor służy do chronienia systemu przed konkretnymi
zagrożeniami, ze strony konkretnych aplikacji. Z założenia niewielka
część programów w systemie będzie miała zdefiniowane profile
bezpieczeństwa. Będą to na ogół programy mające kontakt ze światem
zewnętrznym, takie jak np. serwisy sieciowe.

Najbardziej zaognionym punktem spornym w dyskusjach na temat wyższości
jednego rozwiązania nad drugim jest ich podejście do oznaczania plików w
systemie. SELinux operuje na i-węzłach -- odpowiednio oznaczonej
konkretnej zawartości w systemie plików. AppArmor używa tradycyjnych
ścieżek dostępu.

Zwolennicy SELinux twierdzą, że używanie ścieżek dostępu nie zapewnia
odpowiedniego bezpieczeństwa. Można przecież tworzyć dowiązania (hard
links), manipulować przestrzenią nazw systemu plików, czy podmieniać
zawartość plików. W końcu ścieżka do pliku to wyłącznie wskazanie --
"plik, który znajduje się pod tym adresem", nie zaś sama zawartość
pliku. Dlatego SELinux wymaga oznaczania i-węzłów, czyli konkretnej
zawartości, za pomocą specjalnych metek. Do nich później odwołuje się
polityka bezpieczeństwa.

Entuzjaści AppArmor odpowiadają na to: racja, ścieżki dostępu mają swoje
wady. Są za to nieskomplikowane, intuicyjne w użyciu, a wszyscy są do
nich przyzwyczajeni. Politykę bezpieczeństwa tworzy się więc łatwo.

Trudno jest porównać ze sobą mechanizmy, które w założeniach mają
spełniać różne role. W praktyce jednak często staje się przed wyborem,
którego z nich użyć.

Teoretycznie SELinux jest rozwiązaniem technologicznie lepszym. Pozwala
na zdefiniowanie kompletnej polityki bezpieczeństwa, odseparowanie od
siebie przepływów danych, zabezpieczenie całego systemu. Definiowanie
dostępu do konkretnych i-węzłów zabezpiecza system przed wieloma
rodzajami ataków. Są też jednak minusy: i-węzły w systemie plików trzeba
oznaczyć i pilnować, by pozostały oznaczone. Trudniej jest robić kopie
bezpieczeństwa, bo trzeba dbać o zachowanie metadanych. Politykę
bezpieczeństwa definiuje się też trudno.

W praktyce więc AppArmor, pomimo że ma mniejsze możliwości, może się
okazać znacznie lepszym rozwiązaniem. W wielu zastosowaniach lepiej mieć
dobrze wdrożony i działający AppArmor dla ograniczonej liczby aplikacji,
niż nie do końca zaimplementowany SELinux dla całego systemu.

Dochodząc do tytułu tego artykułu: w teorii SELinux jest rozwiązaniem
bardziej zaawansowanym technologicznie, ale w praktyce AppArmor spisuje
się lepiej. Wystarczającym powodem jest tu trudność użycia: są znacznie
większe szanse, że administrator poprawnie zdefiniuje profile
bezpieczeństwa w AppArmor, niż że zrobi to dobrze dla SELinux, a nawet
najlepsze technologicznie rozwiązanie przy źle zdefiniowanej polityce
bezpieczeństwa nie zabezpieczy systemu.

Macie przemyślenia na ten temat? Piszcie do mnie, proszę. Podejmę dyskusję w przyszłych artykułach.

Przysłuchiwałem się niedawno dyskusji podczas spotkania Klubu Informatyka PTI. Samego spotkania sprawozdawać nie będę, zrobili to znacznie lepiej inni -- napiszę jednak o czymś, co uważam za istotne dla sprawy podpisu elektronicznego.

W samej dyskusji brałem udział biernie, tylko się przysłuchując. Nie uważałem, żebym miał wiele do dodania, w końcu dyskutowali ludzie, którzy od lat zajmują się tym tematem. Rozmowa toczyła się wokół problemów z adopcją podpisu elektronicznego w Polsce. Jako główne problemy wymieniane były ceny (sprawdziłem -- certyfikat kwalifikowany to minimum 300zł rocznie, co zakrawa na żart) oraz brak świadomości istnienia podpisu elektronicznego w społeczeństwie.

Dodałbym trzeci powód braku adopcji. Choć zapewne nieznaczący w ujęciu statystycznym, w gronie ludzi zajmujących się informatyką może okazać się istotny. Dlaczego ja sam nie używam podpisu elektronicznego?

Bo się boję.

W pędzie do popularyzacji podpisu elektronicznego zapomnieliśmy o edukacji. Podpis taki daje co prawda wiele korzyści, ale niesie także ze sobą zagrożenia. O tych drugich mało kto mówi, mam też wrażenie, że mało kto zadaje sobie trud pełnego ich zrozumienia.

Centra certyfikacyjne sprzedadzą nam certyfikaty, karty kryptograficzne, czytniki kart, wszystko z zapewnieniem, że są to produkty najwyższej klasy bezpieczeństwa. Istotnie tak jest. Problem jednak w tym, że większość klientów owe wysokiej klasy produkty podłączy do swojego komputera PC, prawdopodobnie z systemem Microsoft Windows. W najlepszym przypadku nie będzie wiadomo, co się na nim dzieje, jaki kod jest wykonywany, z czym się komunikuje i co robi. W rzeczywistości, czyli w większości przypadków, ów komputer będzie jednym wielkim zoo, gdzie wśród żyraf (programy obserwujące zachowania) i bawołów (wirusy) będą zwinnie bujać się na linach małpy (keyloggery).

Owszem, szybko odpowiedzą eksperci -- ale to nie ma znaczenia, bo podpis generowany jest na specjalnej bezpiecznej karcie z mikroprocesorem! Nie można go ukraść i nie można nim nic podpisać, gdy karta nie jest włożona do czytnika. Tak faktycznie jest. Niestety, nadal można nim podpisać kilka różnych rzeczy zamiast jednej. Temu zaradzi czytnik z klawiaturą (pin-padem) -- zakrzykną eksperci! To prawda -- nawet wtedy jednak pozostaje główny problem: użytkownik nie wie, co podpisuje.

Pamiętajmy, że to co akurat wyświetla na ekranie nasz komputer, nie musi mieć żadnego związku z tym, co do podpisania dostaje czytnik. I tak prawie zawsze podpisem opatruje się funkcję skrótu dokumentu, a nie cały dokument, użytkownik zaś na ekranie widzi dokument. Głównym jednak problemem dla mnie jest to, że nie mogę być pewien czy faktycznie podpisuję to, co widzę na ekranie.

Jeśli ktoś w tym momencie twierdzi, że taki atak nie jest prawdopodobny, to jest naiwny. Wiele osób twierdzi, że programy przechwytujące naciśnięcia klawiszy (keyloggery) to problem wydumany. Tym polecam pobudkę, na przykład poprzez przeczytanie o Mumbai, gdzie wręcz wymaga się od kawiarni internetowych instalowania takich programów.

Cały problem w tym, że mając bezpieczną infrastrukturę do podpisu elektronicznego, wprowadzamy do niej element, któremu nie można ufać: komputer PC. Wydawało mi się to tak oczywistym przeoczeniem, że nie chciałem wierzyć, że twórcy ustaw o podpisie elektronicznym nie pomyśleli o tym problemie. Wczytałem się więc w akty prawne. Co się okazało? Pomyśleli -- i nawet opisali precyzyjnie jakie wymagania musi spełniać "bezpieczne urządzenie do składania podpisów elektronicznych":

§ 6. Bezpieczne urządzenie do składania podpisów elektronicznych oraz bezpieczne urządzenie do weryfikacji podpisów elektronicznych mają możliwość obliczania i prezentowania przynajmniej jednej z funkcji skrótu w stosunku do danych służących do weryfikacji bezpiecznego podpisu elektronicznego lub poświadczenia elektronicznego, będących dla osoby składającej bezpieczny podpis elektroniczny lub weryfikującego bezpieczny podpis elektroniczny punktem zaufania. (ROZPORZĄDZENIE RADY MINISTRÓW z dnia 7 sierpnia 2002 r., Dz. U. Nr 128, poz. 1094) (podkreślenie autora)

Oto i rozwiązanie mojego problemu -- mam komputer PC, który wyświetla mi na ekranie dokument i pokazuje jego funkcję skrótu. Równocześnie, ów dokument przesyłany jest do zaufanego urządzenia zewnętrznego (najlepiej z otwartym, audytowalnym), które niezależnie liczy funkcję skrótu i wyświetla mi ją na wbudowanym ekranie LCD. Do urządzenia zewnętrznego mam zaufanie, wiem też, że jego oprogramowania nie da się zmienić, bo jest zapisane w pamięci ROM. Mogę więc porównać oba skróty i spokojnie autoryzować podpis, wiedząc co podpisałem.

Nie rozumiem dlaczego na stronach Sigillum jest informacja, że bezpiecznym urządzeniem do składania i weryfikacji podpisu elektronicznego zgodnie z wymaganiami ustawy i rozporządzenia są zestawy czytnik + komputer PC + oprogramowanie. W żaden sposób za bezpieczny (czyli spełniający wymagania opisane w Rozdziale 2 rozporządzenia) nie może być uznany komputer PC z oprogramowaniem, chociażby dlatego, że nie ma kontroli nad wyświetlanym obrazem na ekranie oraz nad danymi wpisywanymi z klawiatury. Wytłumaczeniem nie może być ograniczenie technologiczne, bo istnieją czytniki z wyświetlaczem -- i jak przypuszczam, wynik funkcji skrótu potrafią wyświetlić.

Nie jestem bynajmniej jedynym, który zauważył problem. Przykładem może być chociażby praca "Digital signature in insecure environments".

W profesjonalnej analizie o bezpieczeństwie zawsze mówi się jako o kompromisie. Można mieć system albo bezpieczny, albo wygodny w użyciu. Na drugim wykresie pokazać można ryzyko finansowe: ile klient ryzykuje, wybierając mniej bezpieczny system. O ile wybory te są świadome, można dobrze dobrać politykę bezpieczeństwa do realnych wymagań. W przypadku podpisu elektronicznego jestem w stanie zrozumieć, że w wielu zastosowaniach biznesowych (takich jak np. masowe podpisywanie faktur wykonywane na zaufanym i zabezpieczonym systemie) obecne rozwiązania mają sens i są rozsądnym kompromisem. Nie jest tak jednak w przypadku osób fizycznych. Tu systemy są znacznie gorzej zabezpieczone (to dopiero eufemizm!), a względne ryzyko finansowo-prawne nieporównywalnie większe.

Jeśli chodzi o mnie, podpisując na komputerze z systemem Linux czułbym się lekko niekomfortowo, ale zaakceptowałbym ryzyko, w końcu system jest audytowalny i kod systemu i aplikacji jest regularnie oglądany przez wiele osób. Na moim MacBooku z Mac OS X byłbym już dużo ostrożniejszy, zaś z Windows nie odważyłbym się na podpis w ogóle. Dopóki więc na rynku nie będą powszechnie dostępne czytniki kart z klawiaturą (pin-padem), wyświetlaczem pokazującym funkcję skrótu oraz audytowalnym oprogramowaniem, dopóty nie będę używał podpisu elektronicznego, który może rodzić dla mnie skutki prawne.

Po ostatnich spotkaniach bootstrapowych i aulowych nasunęło mi się kilka spostrzeżeń na temat sposobu prezentowania, szczególnie gdy czas prezentacji jest bardzo krótki. Spisuję je w formie rad -- nie dlatego, żebym sam trudną sztukę wystąpień publicznych opanował w stopniu doskonałym, ale po to by pomogły tym, którzy dopiero zaczynają się tego uczyć. Oto kilka rad, których warto się trzymać:

1. Przećwicz sam lub przed znajomymi swoją prezentację zanim powiesz ją publicznie. To jest niezmiernie ważne, szczególnie dla prezentacji krótkich (5 minut), gdzie każda sekunda ma znaczenie. W żaden inny sposób nie dowiesz się czy zmieścisz się w czasie, co jest naprawdę trudne do oszacowania nawet dla doświadczonych mówców. Jeśli ćwiczysz ze znajomymi, dodatkowo skrytykują oni Twoją prezentację, zwrócą uwagę na to, co jest niejasne i poradzą skrócić to, o czym mówisz za długo. Jeśli ćwiczysz sam, nie rób tego na skróty: wygłoś prezentację, a nie czytaj w myśli. To są zupełnie różne rzeczy.

2. Miej sposób na skrócenie lub wydłużenie prezentacji, jeśli zajdzie taka potrzeba. Wydłużenie jest nietrudne: wystarczy mieć na końcu dodatkowy slajd lub dwa, a na nich rozwinięcie ciekawszych wątków. Skrócenie jest trudniejsze, ale niezmiernie cenne, bo znacznie lepiej jest zamknąć prezentację własną puentą niż mieć ją przerwaną brutalnie na 2-3 slajdy przed końcem. Sam staram się na końcowych slajdach mieć kilka punktów, których w razie potrzeby mogę nie omawiać.

3. Nadaj swojej prezentacji strukturę. Niech będzie widoczne z jakich części się składa i na którym jej etapie jest słuchacz w każdej chwili. Struktura zaczyna się od dokładnego przemyślenia prezentacji, ale potem można ją też podkreślać formatowaniem slajdów, kolorem paska z boku lub na dole, "progress-barem", a nawet przejściami między slajdami. Warto też dodawać wskazówki słowne ("kolejne zagadnienie, o którym powiem", "drugi temat to", "ostatni temat dotyczy" itp.). Niedoścignionym mistrzem nadawania struktury był dla mnie Michael Dertouzos, szef MIT Laboratory for Computer Science, który potrafił wygłosić 45-minutowy wykład bez slajdów (!) tak, by w każdym momencie dowolny słuchacz wiedział dokładnie o czym jest mowa, gdzie obecny temat mieści się w ogólnej strukturze wykładu i co będzie dalej. Słuchając go na konferencji ACM1 zrozumiałem, jak bardzo wiele jeszcze muszę się nauczyć jeśli chodzi o publiczne wystąpienia.

Dla dłuższych prezentacji warto wstawić blisko początku slajd opisujący strukturę, zaś potem trzymać się punktów z tego slajdu.

4. Zadbaj o aspekty techniczne. Jeśli masz prezentację na urządzeniu USB, wgraj ją wcześniej na komputer organizatora. Jeśli masz własny laptop, sprawdź wcześniej, czy działa z rzutnikiem i czy masz poprawne ustawienia ekranu. Wyłącz Wi-Fi i Bluetooth, żeby nie dostać kompromitujących komunikatów od kogoś w czasie prezentacji.

⁃ Jeśli używasz Windows: wyłącz screensaver, posprzątaj pulpit, by nie było tam poufnych bądź kompromitujących rzeczy (tak, tak).

⁃ Jeśli używasz Mac OS: nie ustawiaj swojego maka w tryb "mirror", tylko w Keynote wybierz "present on secondary display", w ten sposób Twój pulpit nigdy nie pojawi się na ekranie rzutnika. Ważne: zawsze podłączaj rzutnik do komputera, nigdy rzutnik do przelotki wetkniętej do komputera (wiele osób robi to drugie, przez co komputer ma kłopoty z wykryciem rzutnika).

Mnóstwo osób nie zwraca uwagi na takie rzeczy, a mają one duże znaczenie dla odbioru mówcy i jakości prezentacji. Jeśli ktoś zaczyna spóźniony pięć minut po wielkiej walce z laptopami, kablami, ekranami, desktopami i ustawieniami, to ma znacznie gorszą pozycję wyjściową niż inny mówca, startujący na luzie i bez problemów. Mówca jest zestresowany, publiczność znudzona lub (gorzej) rozbawiona. Naprawdę lepiej to dobrze przygotować.

5. Gdy przedstawiasz "elevator pitch", czyli radykalnie nowy pomysł na biznes w wielkim skrócie, koniecznie na początku powiedz na czym polega pomysł. Oczywiste? A jednak. Widziałem już sporo prezentacji w których po kilku minutach nadal nie było wiadomo o co chodzi, za to dowiedziałem się dużo o konkurencji, rynkach, trendach i innych mało istotnych rzeczach. Jeśli nie umiesz opisać czym jest Twój pomysł w jednym zdaniu na jednym slajdzie, to nie powinieneś go prezentować.

Jak wiadomo, statystyki kłamią. A skoro kłamią, to nikt nie powiedział, że raz opublikowanych wyników nie można zmienić. Na ostatniej Auli rozdałem uczestnikom tę samą ankietę, którą dostali wszyscy na Ogólnopolskim Barcampie. W ten sposób pozyskałem prawie dwudziestu nowych respondentów. Oto jak poprzesuwały się obszary zainteresowań:


Starałem się utrzymać ogólną orientację grafiki podobną do tej poprzedniej -- wymagało to odwrócenia jednego ze składników podstawowych i poobracania wykresu ręcznie.

Co widać nowego? Niewiele -- za to wyniki się skonkretyzowały. Tematy popularne ("mainstream") są zgrupowane ciaśniej razem. Erlang odjechał zgodnie z przewidywaniami w stronę języków funkcyjnych. Lua, SeaSide i Arc nadal leżą na końcu znanego świata, zaś makra wyraźnie już wylądowały w grupie mainstream, więc większość respondentów nie widzi ich jako metaprogramowanie.

Chciałbym przygotować animację zmian w miarę jak przybywa respondentów, lecz nie wiem czy znajdę na to czas. Są niestety ekspertyzy i oprogramowanie do napisania...

26 lutego na Ogólnopolskim Barcampie rozdaliśmy wszystkim do wypełnienia ankietę. Chodziło o przygotowanie TechAuli, czyli nurtu technologicznego spotkań Aulowych.

Opracowanie wyników zajęło mi trochę czasu, głównie dlatego, że musiałem nauczyć się kilku nowych dla mnie technik. Wyniki jednak są interesujące. Oto wygenerowana automatycznie infografika podsumowująca jedną ilustracją wyniki ankiety:



Powyższa infografika zawiera mnóstwo informacji. Wielkość czcionki i jej kolor oznaczają średnie zainteresowanie danym tematem (większa czcionka i "gorętszy" kolor to większe zainteresowanie). Koła odpowiadają znajomości danego pojęcia: im mniejsze koło, tym więcej osób zaznaczyło zero przy danym pojęciu, co oznacza że w ogóle go nie znali. Położenie pojęć wynika z analizy czynników podstawowych i jest najlepszą projekcją danych w dwa wymiary przy zachowaniu wzajemnych odległości między pojęciami. Odległości definiowane są przez korelację odpowiedzi, co oznacza że pojęcia na które ludzie odpowiadali podobnie powinny znaleźć się bliżej siebie. Odpowiednio, na przeciwnych biegunach grafiki znajdą się pojęcia, na które ankietowani odpowiadali skrajnie różnie.

Kreski pod pojęciami reprezentują "potencjalne zainteresowanie". Zakładając, że jeśli ktoś zaznaczył "0" przy danym terminie, to dziś nic o nim nie wie, ale bardzo chciałby się dowiedzieć, policzono nowe średnie zainteresowanie. Kreski i ich kolor odpowiadają różnicy pomiędzy średnim zainteresowaniem oraz tym "nowym", uznającym zero za "bardzo interesujący temat". Jak widać, są tematy które są zarówno nieźle znane, jak i mają spory potencjał (np. django), są też tematy oklepane (Perl) i kompletnie nowe (Lua).

Interesujące jest, że Erlang i Prolog znalazły się blisko najbardziej znanych pojęć. Nazwy te brzmią znajomo dla wielu osób, wygląda to na efekt dobrego marketingu, którego nie ma np. Lua. Inne ciekawe spostrzeżenia, to że makra znalazły się zdecydowanie zbyt blisko Perla i technologii doskonale wszystkim znanych, z czego można wnioskować, że uczestnicy ankiety interpretowali to pojęcie jako makra tekstowe, a nie programistyczne (z języków typu Lisp). Podobnie nieoczekiwane jest umiejscowienie "pattern matching" i "non-deterministic programming". Pierwszego oczekiwałbym raczej w okolicy języków funkcyjnych (być może mylony był z wyrażeniami regularnymi), drugiego przynajmniej bliżej języka Prolog.

Na najbliższych spotkaniach Auli i TechAuli zamierzam znowu poprosić tych, którzy jeszcze ankiety nie wypełnili, o odpowiedzi. Ciekaw jestem, jak poprzesuwają się kółka na grafice!

Wkrótce pierwsze spotkanie TechAuli, czyli nurtu technologicznego spotkań Aula Polska. Przygotowania zajmują mi sporo czasu -- trzeba określić tematy wystąpień, znaleźć mówców, przekonać że chcą być mówcami, umówić. Trochę jeszcze może to potrwać.

W międzyczasie krótki "teaser", czyli opis koncepcji TechAuli:

TechAula jest miejscem do dyskusji o nowych technologiach informatycznych. Dyskutowane tematy mają z założenia być kontrowersyjne. Koledzy z dużych firm będą stukać się w głowę, mówiąc "kto o tym słyszał? przecież nikt tego nie używa! wiadomo, że świat przechodzi na technologię X!". Tym lepiej: by zbudować firmę typu start-up niezbędne są technologie, które pozwolą wybić się z tłumu, wyjść ponad średnią. Przecież nikt nigdy nie osiągnął sukcesu robiąc to samo, co wszyscy! Warto więc o nowych i kontrowersyjnych technologiach słuchać, nawet jeśli połowa z nich okaże się być kiedyś niewypałami.
TechAula to nie jest miejsce do dyskusji o tym, jak najlepiej wytłoczyć kolejną aplikację w Java Enterprise Cokolwiek ani o tym jak zrobić, by kod w PHP działał dwa procent szybciej. Nie rozmawiamy tu o "industry standard practices", nie mówimy o trendach, tendencjach i modach. Nie jesteśmy zapatrzeni w to, co robi "świat". Jeśli technologia jest powszechnie używana, automatycznie przestaje być nośnym tematem dla TechAuli, chyba że można przedstawić jej interesującą krytykę.
Rolą TechAuli jest poszerzanie horyzontów. Nawet jeśli nigdy nie użyjemy danego języka programowania, to pewne pojęcia, jakie on wprowadza, mogą okazać się użyteczne. Podobnie jest z wieloma technologiami i pomysłami. Stąd szeroki zakres tematyczny i dodatkowe punkty dla tematów, o których pojęcia jak dotąd nie ma nikt.

Korzystając z okazji: jeśli ktoś przeczytawszy powyższy opis ma ciekawy temat do zaprezentowania, to zapraszam do kontaktu ze mną!