Their prediction is that as machines with many processing cores become more prevalent, the relevant architecture will change from cores sharing a single coherent memory (the model on which threads are based) to one where each core has a limited amount of private memory, and communication is done via message passing between the cores. This gives them (and me :-) hope that the GIL won't be a problem as long as we adopt a parallel processing model.

To bardzo naciągane przewidywanie, zważywszy na to, że dziś nie da się kupić żadnego komputera[1] o takiej architekturze, zaś wszyscy z powodzeniem budują architektury SMP ze współdzieloną spójną pamięcią. Jak widać też na przykładzie maszyn Azul, takie architektury skalują się do setek procesorów: od Azul można kupić maszynę z 864 rdzeniami. Owszem, w przyszłości prawdopodobnie będzie konieczne odejście od modelu spójnej pamięci, ale mówimy tu o przyszłości odległej o 10 lat lub więcej.

Te przewidywania wyglądają więc na zmiatanie problemu GIL (Global Interpreter Lock) pod szafę.

Dla tych, którzy uważają problem jednowątkowości Pythona za wyimaginowany: w Fablo nasz kod działa równolegle na maszynach wieloprocesorowych i nie wyobrażamy sobie równoległości wyłącznie w niektórych bibliotekach. Używamy pojedynczych wątków lub wielu pul z wątkami na różne sposoby i w wielu miejscach. Gdybyśmy mieli pisać Fablo w Pythonie, to GIL byłby poważnym problemem wydajnościowym.

[1] Dostępnego dla normalnych ludzi.

Dotąd infrastruktura EC2 w Amazon Web Services nie gwarantowała jakości połączeń sieciowych między serwerami. Nie nadawała się więc do uruchamiania aplikacji wymagających szybkiej komunikacji. Eliminowało to sporą część naukowych zastosowań obliczeniowych, gdzie kod często zrównoleglony jest za pomocą MPI (Message Passing Interface), czyli synchronicznej drobnoziarnistej komunikacji.

W tej chwili jest inaczej i moim zdaniem pod dużym znakiem zapytania stoi kupowanie przez naukowców własnych komputerów i budowanie własnych rozwiązań. Bardzo trudno jest oferować moc obliczeniową taniej niż robi to Amazon (wiem, liczyłem). Co więcej, klaster w Amazonie można mieć w minutę, a klaster własny — po latach od rozpoczęcia starań.

Finansowo różnica może być kolosalna — jakże często cena rozwiązania jest ustalana w chwili ogłoszenia przetargu, zaś ostateczne uruchomienie i wykorzystanie następuje lata później. Znam ośrodek obliczeniowy, gdzie klaster uruchamiany był przez niemal dwa lata! Po takim czasie jest to już niemalże rozwiązanie przestarzałe.

Co ważne, klaster w amazonie włącza się gdy jest potrzebny, a wyłącza gdy nie jest. Nie trzeba się martwić o starzenie się sprzętu, utrzymanie, chłodzenie, prąd i serwisowanie.

Instytucje finansujące naukę powinny od tej chwili kwestionować wystąpienia o granty, gdzie inwestuje się w sprzęt, zaś ułatwić uzyskiwanie środków na wykupywanie mocy obliczeniowej u dowolnie wybranego dostawcy.

Nie potrwało to długo. Szkoda, bo jak wielokrotnie pisałem, chciałbym widzieć mocną konkurencję dla iPhone.

Czy w tej chwili można kupić jakikolwiek telefon z systemem Android 2.2 (Froyo)?

(jest tam mój felieton — i prawdopodobnie będą też następne)

Dotąd można było wgrywać do nas dane w formatach CSV i JSON (naprawdę nieskomplikowane), zauważyliśmy jednak, że jest dużo sklepów, które już mają zrobiony eksport danych. Okazuje się, że bardzo podobnych danych potrzebują porównywarki cenowe.

Natychmiast wysłałem listy na odpowiednie adresy kontaktowe kilku największych porównywarek. Napisałem, że proszę o udostępnienie opisu formatu danych, który następnie będziemy wspólnie promować jako de facto standard wymiany danych sklepowych. Wyjaśniłem, że w żaden sposób nie konkurujemy, bo Fablo nie jest porównywarką cenową. Ba, więcej — bardzo możliwe, że w niedalekiej przyszłości będziemy zapewniać funkcjonalność wyszukiwania w niektórych porównywarkach.

Listów wysłałem pięć, odpowiedzi dostałem… ZERO.

Cisza. Minęły dwa tygodnie i jak kamień w wodę.

Zastanawiam się o co chodzi. Czy w firmach budujących porównywarki ktoś przestraszył się Fablo? Postanowił nie dać formatu, żeby go ukryć? Pomimo, że nie jesteśmy konkurencją? Z nadzieją, że będzie tajny? Że się nie dowiemy, jak wyglądają dane?

A nawet gdybyśmy byli konkurencją, to czy jest sens udawać, że format jest tajny, skoro i tak nie jest?

Dwa tygodnie to dużo czasu dla start-upu. Zrobiliśmy już import danych w najpopularniejszych formatach. Napisaliśmy elastyczny importer, który wybiera z danych to, co jest dla nas istotne, niezależnie od szczegółów formatu. Jeśli sklep jest dziś obecny w którejkolwiek z porównywarek, to jutro może oglądać demo Fablo na swoich danych, a za dwa dni być naszym klientem. Cel został więc osiągnięty.

Szkoda tylko, że nie możemy powołać się na dokumentację formatu konkretnej porównywarki, podając autora i wzorzec. Mielibyśmy na rynku de facto standard wymiany danych, z którego mogliby korzystać różni uczestnicy. A tak — mamy pół-tajne dokumenty (które i tak można znaleźć w sieci) i sporo fikcji.

• Mamy niezmiernie krótki kod. Każda linia kodu to koszt: może w niej być błąd, ktoś musi ją dostosowywać gdy rozwija się kod i środowisko, ktoś musi ją czytać i rozumieć, zaczynając pracę nad kodem, ktoś musi zadbać o testy do niej. Dlatego im mniej kodu tym lepiej. Clojure jest pod tym względem imponującym językiem, szczególnie uzbrojony w biblioteki zewnętrzne. Naszego kodu jest mało (jak na tę funkcjonalność), co pozwala znacznie szybciej go rozwijać i zmieniać.
• Uruchamiamy kod na JVM (Java Virtual Machine). Łatwo nie docenić znaczenia jakości VM dla produktu. Pythoniści wielokrotnie już boleśnie się przekonywali, że liczenie odnośników (reference counting) to nie najlepsza metoda odśmiecania (GC). Implementacje Common Lisp na ogół miały sensowne GC, ale nie były one równoległe. W JVM zrobiony przez Suna poszły lata ciężkiej pracy, zaś algorytmów odśmiecania jest kilka. Ostatnio np. nasze serwery API zaczęły używać algorytmu Concurrent Mark-Sweep, który co prawda zużywa więcej procesora, ale za to daje krótsze pauzy, co jest ważne przy obsłudze zapytań. Mało które środowisko pozwala na takie wybory. Imponujący jest też optymalizator kodu (HotSpot).
• Dzięki JVM mamy łatwy dostęp do wszystkich bibliotek w Javie. Wystarczy dodać jedną linijkę do konfiguracji projektu, a biblioteka z Maven repo ląduje u nas i można jej używać w kodzie.
• Piszemy poprawny kod równoległy. Wszystko u nas jest równoległe i potrafi wykorzystywać dowolną liczbę procesorów. Uruchamiamy wiele wątków do różnych zadań, a operacje typu map/reduce skalują się automatycznie. Utrzymanie takiego kodu w języku innym niż Clojure byłoby niezmiernie trudne. Budowanie takich rozwiązań równoległych, które przetwarzają zapytania dla wielu klientów i potrafią zmieniać wersje bazy bez przerw w pracy, byłoby naprawdę trudne bez wsparcia, jakie daje Clojure. Tu radzimy sobie bez problemu.
• Produkcyjne uruchamianie kodu jest bardzo proste — kompilacja daje w wyniku jeden plik .jar. Wystarczy go skopiować na serwer i uruchomić.
• Incanter załatwia nam dużą część matematyki i statystyki, jakiej potrzebujemy.
• Clojuratica pozwala łatwo prototypować nowe rozwiązania używając największej na świecie biblioteki matematycznej — oprogramowania Mathematica

Są oczywiście minusy:

• Pythoniści i Rubyści wspięli się ostatnio na wysoki stołek „języków popularnych", zapominając gdzie kiedyś byli. Straszą nas, że nie znajdziemy programistów Clojure do zatrudnienia w Fablo. Pewnie faktycznie będzie trudniej, ale też dzięki Clojure potrzebujemy tych programistów mniej.
• Niektóre biblioteki do Clojure są jeszcze niedojrzałe (przykładem może być redis-clojure).
• Clojure ma wybitnie nieczytelne komunikaty błędów i często trzeba się domyślać dlaczego kod się nie kompiluje.

Jak widać, listę minusów mam niewielką. Jak dotąd jesteśmy bardzo zadowoleni z wyboru. W żadnym innym środowisku nie przeszlibyśmy tak szybko od pierwszych eksperymentów do skalowalnego oprogramowania produkcyjnego.

Tak, to nie pomyłka — po kilku dniach używania wersji 4.0 stwierdziłem, że jest nieużywalna. Telefon stał się wielokrotnie wolniejszy, niektóre programy przestały działać. Spowolnienie jest tak duże, że niektórych operacji po prostu nie daje się wykonać — oczekiwanie 20s aż zacznie odtwarzać się audio po naciśnięciu guzika plasuje dla mnie to oprogramowanie w kategorii „nie działa”.

Zanim ktoś napisze, że to aplikacje nie są dostosowane do systemu 4.0: jak wiadomo, Apple ma bardzo staranny proces selekcyjny i uważnie filtruje aplikacje, by zapewnić „curated experience”. Jak się powie A, to trzeba powiedzieć B: w tej chwili za problemy z aplikacjami odpowiada Apple.

Jeśli ktoś więc jeszcze nie zrobił upgrade swojego iPhone 3G do systemu 4.0, to uprzedzam: zdecydowanie nie warto. Zyskuje się ikonki w folderach, a traci działający telefon.

Ogólnie odnoszę wrażenie, że Apple ma za dobrze. Używam ich sprzętu i oprogramowania, bo działa, a ostatnio jest z tym słabiej niż dawniej. A mają za dobrze, bo sprzęt i oprogramowanie konkurencji nadal działa gorzej. Bardzo chciałbym, żeby konkurencja nadgoniła.

Opracowaliśmy podstawową wyszukiwarkę — działa lepiej niż większość rozwiązań na rynku. Toleruje literówki, polską odmianę wyrazów i umożliwia szukanie zwykłym ludziom, a nie tylko informatykom i właścicielom sklepu (właściciel zawsze wie jak się co nazywa, więc szuka dokładnie tego co jest w sklepie, dlatego nie zawsze rozumie problemy klientów).

Wyszukiwarka jednak to nie wszystko. Chcąc oferować „Software as a Service” (SaaS), czyli e-usługę, trzeba solidnej inżynierskiej roboty, żeby owa e-usługa działała dobrze. Poprzednio pisałem o rozproszonej architekturze — kolejny tydzień poszedł właśnie na rozbudowywanie owej architektury.

Wynikiem jest możliwość uruchamiania wielu serwerów obsługujących zapytania. Każdy z nich może obsługiwać dowolny zbiór klientów, a rekonfiguracje zajmują po kilka sekund i są sterowane centralnie przez Redis. Możemy więc bardzo elastycznie rozkładać obciążenie. W przyszłości oczywiście dobudujemy automatyczne uruchamianie kolejnych serwerów w razie potrzeby — w końcu po to właśnie używamy platformy Amazon EC2, żeby z takich możliwości korzystać.

Na razie jednak ciekawszy jest efekt uboczny tych prac. Jak pisałem poprzednio, nasza wyszukiwarka jest w stanie przełączyć się płynnie na nowy indeks klienta, bez przerwy w obsłudze zapytań. Teraz dodatkowo jesteśmy w stanie zrobić zmianę (upgrade) wersji oprogramowania, wprowadzając ulepszenia, bez jakiejkolwiek przerwy w obsłudze zapytań. Nasi klienci nawet nie zauważą, że prowadzimy prace, po prostu kolejne zapytania zaczną zwracać lepsze wyniki.

Jestem ciekaw, czy nasza konkurencja, która tak obszernie wypowiadała się o tym co ma i czego nie ma (!) Fablo w wątkach dyskusyjnych na AntyWeb, może się pochwalić tym samym. A może nadal jest to pudełkowe oprogramowanie instalowane na serwerach, które trzeba samodzielnie utrzymywać, ograniczone do jednego serwera, którym trzeba administrować, zaś upgrade lub zmiany wersji wymagają wyłączenia obsługi zapytań?

Zapowiada się ciekawie :-)

Pierwsi klienci szybko uświadomili nam, że sama wyszukiwarka nie wystarczy: ściąganie i indeksowanie danych jest bardzo ważne. Jak się okazało po kilku spotkaniach, nasi klienci spodziewają się znacznie szybszej aktualizacji niż sądziliśmy: są firmy, gdzie lista produktów zmienia się co kilka minut!

Zabraliśmy się więc ostro do roboty. A ponieważ w startupie nie ma czasu na robienie rzeczy po kilka razy, postanowiliśmy zrobić raz a dobrze. Zaprojektowaliśmy w pełni rozproszoną architekturę, gdzie wydzielona została część indeksująca. Możemy teraz mieć wiele serwerów ściągających i przetwarzających wstępnie dane, oraz wiele tzw. indexerów, które faktycznie przeliczają wszystko, co potem jest potrzebne do wyszukiwania. A ponieważ nasza wyszukiwarka jest dość zaawansowana, owego przeliczania jest całkiem sporo.

Wszystko działa na serwerach Amazon EC2, a synchronizowane jest za pomocą Redisa. Z bazy tej jesteśmy bardzo zadowoleni. W zasadzie nie wiadomo czy można Redisa nazwać „bazą danych”, bo jest to połączenie rozproszonej synchronizacji z bazą danych i systemem kolejkowym. Ważne, że świetnie działa i pozwala szybko budować całkiem skomplikowane architektury.

Efekt? Nowa architektura jest w stanie ściągnąć i przeliczyć dane klienta w czasie poniżej minuty. Co więcej, przełączanie na nowy indeks odbywa się płynnie, bez jakiejkolwiek przerwy w obsłudze zapytań.

Dodatkowo, co jest wielką zaletą, można ustawić skróty klawiszowe na przenoszenie okienek między monitorami.

Na codzień pracuję z trzema monitorami i ten drobny program znakomicie ułatwił mi życie.

We're experienced tech entrepreneurs looking to support and invest in Europe’s most passionate geeks. We’re a pre-seed investment company designed to enable great people to launch great ideas.

Ciekawe. Bardzo dobrze, że w Europie zaczyna się coraz więcej dziać. Dobrze też, że powstaje sensowna konkurencja dla SeedCampu, którego konkursy i warunki nie zawsze były atrakcyjne.

Podoba mi się też ich przejrzyste podejście: wystarczy spojrzeć na (ramowy) wzór umowy. Mało kto tak podchodzi do start-upów.

Totalne nieporozumienie.

iPhone 4 wprowadza trzy nowe duże rzeczy. Każda dla informatyka jest nieistotna, a dla kupujących — olbrzymia:

• Ekran o bardzo dużej rozdzielczości: już pisałem, że powoduje to, że „całe” strony WWW zmieszczą się teraz na ekranie. Dodatkowo, każdy kto lekceważy potrzebę dużej rozdzielczości ekranu w telefonie komórkowym, nie ma pojęcia o rynku japońskim.

• Filmy: nagrywanie i fantastycznie łatwa edycja w iMovie na telefonie.

• Wideo-telefon, który działa. I jeśli ktoś mówi, że to jest już od lat, nie rozumie różnicy między działającym a niedziałającym rozwiązaniem. Na podobnej zasadzie telefonia VoIP istniała przez 10 lat przed Skype — i co z tego? Nikt poza brodatymi informatykami w swetrach nie był w stanie zadzwonić przez internet. W wideo-połączeniach Apple możliwość błyskawicznego przełączania z przedniej kamery na tylną jest fantastyczna.

Nieważne są parametry techniczne — ważne dla kupujących jest to, że 1) zobaczą czytelny tekst na ekranie, 2) będą mogli nagrać film z dzieckiem i natychmiast go zmontować w atrakcyjnej formie, 3) będą mogli zadzwonić do bliskich i zobaczyć ich na ekranie.

Istotny jest też czas pracy na baterii — na oko znacząco większy od dowolnego z telefonów z Androidem.

Oto mój ekstrakt z rad:

Jakie błędy popełniliśmy? [...] Nie przewidziałam, że harmonogram rzeczowo-finansowy jest sztywny i że nikt nie pochwali mnie za oszczędności. No i terminy - obowiązują wszystkie strony umowy, ale nas jakby bardziej. Przygotowywanie papierów to niemal cały etat, a tego w ogóle nie wzięliśmy pod uwagę.

[...]

Kiedyś wydawało mi się, że jeśli urzędnik mi coś powie, to znaczy, że tak jest. Spotkałam niestety kilka niekompetentnych ludzi, za których błędy musiałam zapłacić. Od tej pory lubię mieć na piśmie ich opinie i interpretacje.

Całkowicie się z tym wszystkim zgadzam. Dokładnie takie same doświadczenia mamy jak dotąd w naszym projekcie (Fablo. Na szczęście rozliczamy nasz projekt w Mazowieckim RIF, a to jest instytucja o której mam jak najlepsze zdanie. Wszystkie kontakty z RIF jak dotąd były u nas sprawne, kompetentne, konkretne i bezproblemowe.

Nie chcę wnikać w szczegóły — owszem, wierzenie w to, co mówią urzędnicy, jest naiwnością. Racją jest też, że urzędnicy powinni ostrożniej i staranniej się wypowiadać. Ważne jest jednak co innego: PARP pełni rolę instytucji zaufania publicznego, rozdzielając pieniądze z funduszy Programu Operacyjnego Innowacyjna Gospodarka (POIG). Co więcej, ta rola jest bardzo zyskowna: PARP dostaje za rozdzielanie pieniędzy POIG pokaźne sumy pieniędzy.

Awantura „Oszukani przez PARP”, jak również incydenty takie jak kolejki obstawione przez wynajętych ochroniarzy, wyrzucających w szamotaninie ludzi, pokazują wyraźnie, że PARP źle wywiązuje się ze swojej roli. Niezależnie od wyrafinowanych wyjaśnień przedstawianych przez kierownictwo PARP, coś jest bardzo niedobrze.

Zamiast udawać, że problemu nie ma, należy poważnie rozważyć czy inna instytucja nie nadawałaby się lepiej do obsługi programów POIG.

Mnie interesuje jednak co innego — kodek SILK, dający znacznie lepszą jakość dźwięku niż te stosowane normalnie w telefonii. Jestem zmęczony złą jakością dźwięku i połączeń w telefonach komórkowych. Trudno się prowadzi rozmowy, pewne niuanse umykają upakowane brutalnie kodowaniem GSM. Nieco kuriozalne jest, że umawiam się często na rozmowy przez Skype, bo połączenia są znacznie lepsze niż te przez telefony komórkowe.

Chętnie bym płacił za lepszą jakość dźwięku.