Karol Nowak (aka Grzywacz), jeden ze studentów wydziału i jednocześnie członek SCI spróbował swoich sił w tzw. Summer of Code (SoC) organizowanych przez firmę Google. I zanim napiszę coś więcej, w skrócie co to jest SoC?
Idea SoC jest następująca: w co rocznych "konkursach" popierać inicjatywę ruchu Open Source. Tak naprawdę nie jest to do końca konkurs, tylko program, gdyż nie odbiera się żadnej nagrody, ale by dostać się do tego programu należy zgłosić swój pomysł - jeśli się on spodoba dostaje się "stypendium" na jego realizację.
W 2007 roku zgłoszono około 6200 projektów - ostatecznie zaproszono do programu 900 studentów i prawie 1500 mentorów (opiekunów), łącznie z 90 krajów, którzy pracowali nad ponad 130 różnymi projektami. W tym oczywiście zaproszono studenta Karola 
Czego dotyczył jego projekt? Karol chciał stworzyć mechanizm interakcji do Wiki "sterowanej zdarzeniami" za pomocą protokołu XMPP, zatem sterowanie Wiki mogłoby sie odbywać praktycznie z dowolnego klienta Jabbera. Większość operacji miałaby odbywać się w odpowiedzi na jakieś powiadomienia przychodzące z Wiki, chodź użytkownik może sam rozpocząć interakcje (np. przeszukując wiki) (abstrakt Karola). Tyle sam pomysł, który został przyjęty przez Google (a tak naprawdę to organizacje Open Source oceniają i przyjmują te projekty, Google tylko to finansuje).
Architektura rozwiązania: Niezależny wielowątkowy "bot" napisany w Pythonie. Z jednej strony nasłuchuje na powiadomienia przychodzące z Wiki (zmiany na stronach, aktywacje kont, etc.), z drugiej jest zwykłym klientem Jabbera/XMPP i umożliwia interaktywną komunikację, wysyłając powiadomienia i obsługując różne komendy. Komunikacja z wiki wykorzystuje XMLRPC (nieoficjalne wiki xml rpc api). Komunikacja może być tekstowa (działa na wszystkich klientach XMPP), lub wykorzystywać Data Forms (XEP-004) do przesyłania całych formatek (w tej chwili implementują to tylko PSI i tkabber). Oprócz tego używane jest rozszerzenie Out of Band Data (XEP-066; jeżeli klient je obsługuje), żeby odseparować treść wiadomości od przesyłanych URLi. Bot stara sie zachowywać "inteligentnie", t.j. np. nie wysyła
wiadomości do osób, których status to Do Not Disturb oraz umożliwia internacjonalizację wiadomości na podstawie ustawień językowych w preferencjach użytkownika wiki.
I teraz najważniejsze. Projekt zakończył się sukcesem - GRATULUJEMY! Wykonane zostały prawie wszystkie założenia. W miedzyczasie udało się znależć i poprawić kilka błędów w różnych klientach jabbera/xmpp, bibliotece pyxmpp oraz wpłynąć, by pewne szczegóły w samych dokumentach xmpp były lepiej opisane.
Sposób pracy… poprosiłem by sam Karol to opisał w komentarzu.
Może nie jest to najważniejsze (uważam, że doświadczenie jest tu na pierwszym miejscu), ale jak wspomiałem dostaje się na realizację projektu stupendium i jak to Karol powiedział "jest ono godne"
Wrażenia Autora projektu? Oto one: "Moje wrażenia: świetny sposób na kreatywne spędzenie lata. Poznałem nowych ludzi, nowe narzędzia, rozszerzyłem znacznie swoją wiedzę (i praktyczne doświadczenie) w zakresie Pythona, Jabbera/XMPP, kontroli wersji (Mercurial) i ogólnie Dobrych Praktyk Programistycznych (choćby testy jednostkowe, intensywny refactoring). Ładnie wyglada też w CV. 
"
Podsumowując, dziękujemy Google za tę inicjatywę i zachęcamy innych studentów do wzięcia udziału w tym programie.
(głosów: 5, średnio: 4.6 z 5)
Loading ...
Huh, Grzywacz zamiatasz jak zwykle. Oczywiścię gratuluję sukcesu i życzę kolejnych ;]
nonono, aż miło poczytać
Witam. Zostałem zobligowany do rozszerzenia wpisu komentarzem nt. sposobu pracy w trakcie SoC.
Oczywiście opis dotyczy mojego projektu, w przypadku innych organizacji mogło to wyglądać zupełnie inaczej.
Wszystko zaczęło się oczywiście od napisania aplikacji (link do abstraktu w treści posta). Równocześnie skontaktowałem się z moimi przyszłymi mentorami na kanale #moin-dev w sieci FreeNode, gdzie niedługo później przeszedłem swoiste interview w formie pokazywania kawałków wcześniej napisanego kodu i rozwiązywania zadań w rodzaju “mając dziś więcej doświadczenia, jak byś uprościł to wyrażenie”, “jak byś zoptymalizował ten fragment kodu”, etc.. Później pozostało czekać na rozpatrzenie kandydatury.
Gdy stało się jasne, że będę miał szansę na realizację sponsorowanego projektu, zabrałem się za sporządzanie dokładniejszych planów (architektura, technologie). Te zostały przedyskutowane (tu dzięki dla Kevina Smitha za pogawędkę nt. Jabberowej strony bota) i z pewnymi zmianami zaakceptowane.
W czasie kodowania prace przebiegały w sposób cykliczny: opisywałem mniej więcej swoje najbliższe cele z oszacowaniem czasu, który będę musiał im poświęcić, i zaczynałem pisanie. W międzyczasie wypływały jakieś problemy, doprecyzowywane były detale, aż w końcu udawało się osiągnąć krótkoterminowe założenia i proces się powtarzał (jedna iteracja miała około tygodnia). Taki pseudo agile development.
Cały czas byłem w kontakcie z moimi mentorami via IRC, zdarzyły się też rozmowy głosowe (Skype, ekiga). Oprócz tego na wiki prowadziłem dziennik postępów z cotygodniowymi wpisami.
Oczywiście powstający kod dość często pushowałem do gałęzi SoCowej, dzięki czemu mentorzy mogli szybko znajdować drobne usterki i omawiać ze mną zastosowane rozwiązania.
Warto wiedzieć, że SoC składa się z 3 głównych etapów oceniania studenta: najpierw wybierane są najlepsze aplikacje, następnie po ok. miesiącu prac następuje ocena dokonanych postępów, od której uzależniony jest dalszy udział w projekcie. Kolejna jest ocena końcowa (ok. miesiąca później), która podsumowuje efekty prac. Od każdego z tych etapów uzależnione są wypłaty części przewidzianego stypendium.
it is great!