Archiwum

• Sierpień 2008 (4)
• Lipiec 2008 (5)
• Czerwiec 2008 (3)
• Maj 2008 (1)
• Kwiecień 2008 (2)
• Marzec 2008 (3)
• Luty 2008 (9)
• Styczeń 2008 (2)
• Grudzień 2007 (2)
• Listopad 2007 (3)
• Październik 2007 (6)
• Wrzesień 2007 (8)
• Sierpień 2007 (5)
• Czerwiec 2007 (1)
• Maj 2007 (10)
• Kwiecień 2007 (5)
• Marzec 2007 (26)
• Luty 2007 (21)
• Styczeń 2007 (11)
• Grudzień 2006 (4)
• Listopad 2006 (9)
• Październik 2006 (6)
• Wrzesień 2006 (2)
• Lipiec 2006 (1)
• Czerwiec 2006 (13)
• Maj 2006 (2)
• Kwiecień 2006 (9)
• Marzec 2006 (1)
• Luty 2006 (2)
• Styczeń 2006 (17)
• Listopad 2005 (5)
• Październik 2005 (1)
• Sierpień 2005 (1)
• Lipiec 2005 (17)
• Czerwiec 2005 (2)
• Maj 2005 (4)
• Kwiecień 2005 (4)
• Marzec 2005 (7)
• Luty 2005 (20)
• Styczeń 2005 (24)
• Grudzień 2004 (21)
• Listopad 2004 (25)
• Październik 2004 (22)
• Wrzesień 2004 (38)
• Sierpień 2004 (5)

Kategorie

• Batalie (23)
• Emigracja (50)
• Komercha (4)
• Ogłoszenia (19)
• Ogólne (229)
• Opowiadacze (13)
• Pieprzenie (29)
• Podróże (23)
• Prasówka (6)
• Programowanie (39)
• Cocoa (14)
• iPhone (2)
• Mac OS X (17)
• Obj-C (12)
• Technikalia (21)

Czytam

• Ella
• Jajcus
• Lillianna
• Meak
• Patrys
• PSZ
• Siwa
• Smoku
• Smuggi
• Wampirek
• Wawrzek
• Wil Shipley

(Fr)Agile

Ostatnio coraz częściej zderzam się z ludźmi wierzącymi, że mają doskonałe pojęcie czym jest Agile. Zaglądam nawet na wikipedię i zwyczajnie oczom nie wierzę.

Agile zrobił się modny. Wszyscy chcą go używać i jednocześnie wszyscy doskonale wiedzą czym on jest. Problem w tym, że każdy sądzi podłóg siebie, definiując czym jest Agile po swojemu. Takie budowanie wielkiej teorii z niczego. Znajomy podsumował, że konstruują śmierdzącą kupę, pakują ją w celofan i ziu...

To był może niesmaczny cytat, ale jakże trafny.

Odkąd zacząłem pracę w Wielkiej Brytanii, każda firma, dla której pracowałem chwaliła się tym, że Agile wprowadza do swoich procesów biznesowych. Przywykłem nazywać te mutanty Fragile, bo dokładnie tym są. Wielką, śmierdzącą kupą, robiącą więcej zamieszania niż pożytku.

Ponieważ jednak - tak samo jak inni - mam swoją własną teorię na temat jak to działa, a co gorsze - używałem tego z powodzeniem w dużej firmie, może podzielę się swoimi spostrzeżeniami na ten temat.

Agile NIE JEST procesem tworzenia oprogramowania. Jest jedynie WSPARCIEM istniejącego procesu. Teoria głosi kilka podstawowych zasad:

• Programista nie ma pojęcia w ile jest w stanie wykonać dane zadanie
• Manager kocha się rządzić i nie znosi słuchać, że coś jest trudne albo zajmie więcej czasu, niż on sobie wymyślił
• Zmiany last-minute są zawsze do dupy i zawsze psują smaczek pracy w tym zawodzie

Agile nie robi nic innego jak stara się rozwiązać te trzy podstawowe problemy. Z powodzeniem rozwiązuje dwa z nich. Trzeci traktuje troszkę po macoszemu.

Podstawową jednostką pracy w Agile jest SCRUM Team. Zespół ludzi pracujący nad danym fragmentem, bądź też całością kodu. W takim zespole wyróżnia się dwie nietypowe postaci. SCRUM Master ma za zadanie pilnować, żeby ludzie nie skakali sobie do gardeł. Pilnuje, żeby trzymać się reguł, ale nie posiada decyzyjności jako takiej. Product Owner jest przedstawicielem managementu, który chce wszystko i na wczoraj. Licytuje się z resztą zespołu co i na kiedy może być zrobione.

Podstawową jednostką czasu wykonania grupy zadań jest Sprint. Różne firmy, w zależności od natury projektu, wielkości zespołu itp. definiją sprint jako różne okresy. Ogólnie przyjęty jest miesiąc. Początkujące zespoły powinny jednak skracać go do dwóch tygodni. Czemu - wyjaśnimy sobie zaraz.

Przed rozpoczęciem sprintu, zespół licytuje się z Product Ownerem co ma być wykonane w danej jednostce czasu. Product Owner przedstawia żądania. Zespół funkcjonalności do zaimplementowania. Zespół, z pomocą SCRUM Mastera dzieli podane grupy funkcjonalności (backlog items) na pojedyncze zadania (backlog tasks). Podział powinien być dośc drobny, ale nie ZA drobny. Żeby jasno definiował jak coś będzie wykonywane.

W tak zwanym międzyczasie, Product Owner definiuje priorytety grup (backlog items). Zespół natomiast definiuje czasochłonność, mając na uwadze ile jest do wklepania i na ile trudne/skomplikowane jest to zadanie. Obciąża zadania (backlog tasks) liczbą wykonywalności (story points). Najczęściej używaną sekwencją liczb, są liczby Fibonacciego. Banalniackie zadanie - 1, proste - 2... Później 3,5,8,13... czasem używane jest 21, ale to już BARDZO rzadko.

Kiedy zespół dopiero obywa się z Agile, przyjęło się wybierać najprostrze zadanie z listy (backlog) i obciążać go wartością 2. Każdy kolejny krok przydziału ma referencję do innego prostego zadania. 1nki zdarzają się niezmiernie rzadko. Tak samo jak 21nki... 13 zazwyczaj określane jest jako - szalenie skomplikowane, ale wiemy co robimy. 21 natomiast jako nie mam bladego pojęcia. 21 to taka czerwona lampka, że zadanie powinno zostać podzielone na mniejsze dla jasności i teoretycznie (w praktyce w sumie również) nie powinno mieć miejsca.

Po przydziale punktów (story points) zespół licytuje się z Product Ownerem co wykonają w danym sprincie. Czasem dochodzi nawet do zmian priorytetów. Na początku ludzie mierzą ile dadzą radę zrobić w sprincie "na oko", niestety. Później to procentuje.

Po ustaleniu co zostanie wykonane, pozostajemy z kompletną listą (sprint backlog) definiującą co zostanie zrobione w danym czasie. Ta lista pozostaje niezmienna przez cały okres sprintu. W teorii. W praktyce bywa różnie, ale wtedy SCRUM Master jest naszym obrońcą. Licytuje się co z listy wyjąć, by włożyć coś innego. Zazwyczaj wyciąga się więcej niż wkłada ze względu na specyfikę pracy.

Po zakończeniu sprintu wiemy jedno. Czy się udał. Udał się jedynie wtedy jeśli wykonaliśmy plan w 100%. Jeśli wykonaliśmy 99.9% planu sprint się NIE POWIÓDŁ i należy zrediwować produktywność zespołu. Wszyscy muszą się tłumaczyć. Niepowodzenie powinno być zauważone również wcześniej. Ale o tym zaraz.

Zamknięcie sprintu pozostawia nam również informację za ile punktów udało nam się wykonać zadań w zespole. Ta wartość to wydajność zespołu (team velocity). Ze sprintu na sprint wartość ta będzie coraz stabilniejsza i da podstawy zespołowi, żeby określić ile faktycznie zadań są w stanie wykonać podczas pojedynczego sprintu. Daje to też informacje Product Ownerowi na ile wydajny jest zespół, czy może powinno się go podszkolić/zmienić?

Ostatnim istotnym elementem jest SCRUM daily meating. 15 minut dziennie, kiedy cały zespół spotyka się razem. Każdy członek zespołu jest odpytywany z tego co zrobił poprzedniego dnia, co ma zamiar robić danego dnia i czy stoją mu na przeszkodzie jakieś nieprzewidziane problemy (impediments). Zadaniem SCRUM Mastera jest rozwiązywanie tych trzecich.

Ale SCRUM Meeting to nie tylko sposób na komunikowanie problemów. To dwukierunkowa komunikacja zespół <-> management i, co najważniejsze motywator. Z czasem, jeśli podczas spotkania wszyscy mówią, że zrobili postępy, a jedna osoba nie może się pochwalić żadnymi, sam z siebie będzie robił wszystko, żeby to zmienić. Wymówką od niezrobienia czegoś jest jedynie poważny impediment, którym musi się zająć SCRUM Master.


Agile składa się oczywiście z miliona innych rzeczy, ale kwintesencja działania tego systemu została powyżej rozpisana. Czy działa? Działa znakomicie. Mogę to powiedzieć z całą pewnością, bo wdrażałem ten proces w jednej firmie i z sukcesem używałem przez długi kawałek czasu (dopóki pracy nie zmieniłem :P).

Ludzie dorabiają milion teorii do Agile. Przekombinowują, tłumacząc sobie backlogi jako minimalistyczne kodowanie. Kończy się to tym, że ludzie przepisują z iteracji na iterację cąły kod, bo nie przewidywali kolejnych kroków implementacji. BZDURA!

Jak już napisałem wcześniej - Agile to jedynie wsparcie procesu. Piramida SCRUM Teamów jest oczywista. Na górze architekci z managementem, poniżej Product Ownerzy w postaci architektów itd. To tylko wspomaganie procesów. RUP, planowanie i testowanie definiowane są gdzie indziej. Ludzie konstruują milion dokumentów na temat jak rozwiązane są powyższe problemy. Zupełnie inaczej definiują też zasady działania zespołów.

Szczerze mówiąc, włos mi się jeży na głowie, kiedy czytam te bzdury. Nie znoszę, kiedy ludzie zabierają się za filozofowanie na temat nie mając kompletnie żadnej praktyki w używaniu Agile. Szukają rozwiązań, wynajdując koło na nowo.

Ludzie! Trochę zdrowego rozsądku!

EDIT: Zamiana SCRUMM na SCRUM

Test Driven Development pod Maczkiem

Ostatnio jest niewyobrażalne halo na punkcie programowania dyktowanego testami. Nie powiem, w wielu przypadkach się to przydaje. Na przykład w moim - pisząc frameworka chcę mieć ładne testy regresji i pilnować, żeby nic się przy nowych dodatkach nie schrzandoliło. I niekoniecznie chcę od razu cały kombajn aplikacji do tego, którą chcę pisać później.

Chłopaki z Apple postarali się dostarczyć magiczne coś, co się nazywa OCUnit. Kombajn, którego się tylko karmi klasami do testów i tyle. Wystarczy dodać projekt tego typu, pakować testy i patrzeć jak się ładnie testuje.

Wyczytałem na ten temat mnóstwo dobrego, ale osobiście stwierdzam, że jest to straszliwe badziewie. Ten projekt nie produkuje aplikacji tylko tzw. Bundle. W efekcie znaczy to, że żeby debuggować niewychodzący test trzeba się gimnastykować, czego nie znoszę przepotwornie.

No nic. Pozostaje mi zaimplementowanie własnego środowiska testującego. Zajęło mi to tylko godzinkę, ale efekt jest taki, jaki chciałem.

Na pohybel z tym co wymyślił te durnowate OCUnit!

Technicznym być

Dawno, dawno temu, kiedy strasznie się napaliłem na zostanie "komputerowcem" (czasy podstawówki), nie zdawałem sobie sprawy z czym wiąże się taka droga.

Z urodzenia (genów i tym podobnych) mam umysł raczej humanistyczny, niż analityczny. Powodowało to wiele problemów zarówno w czasach liceum, jak i na studiach, które stały się - z właśnie tego powodu - dla mnie zbyt skomplikowane.

Całe życie wierzyłem, że to właśnie ten brak analityczności jest dla mnie przeszkodą. Że to jest moja pięta achillesowa. Że właśnie z tego powodu nigdy nie będę mógł zostać kimś w braży IT.

Po pierwsze nie okłamuj samego siebie

Miałem (mam) sporo racji w tym rozumowaniu. Pominąłem jednak jeden bardzo istotny element tej całej układanki. Analityczność umysłu rodzi się z dokładności. Dokładności, którą świat komercyjny dziwnie gardzi.

Zabawę z komputerami - w sensie komercyjnym - rozpocząłem dość wcześnie. Oczywistym było, że szef / klient zawsze chciał wszystko na wczoraj. Z założenia wszystko miało działać. Niekoniecznie miało być dobrze zrobione. To pierwszy krok do lawiny problemów. Nieczysty kod się mści. Uczą tego na każdej uczelni. Źle sformułowane założenia mszczą się również. Zaczynamy zmieniać coś, co w zamyśle miało być inaczej. Robimy sobie jeszcze większy bałagan zmuszeni presją czasu.

Jest to złe. Ale bardzo często ciężko to zmienić. Póki ludzie nie zmienią swojego podejścia do programistów, czy ogólnie - tworzenia oprogramowania - zmiany są mało możliwe.

Jak już okłamałeś siebie, nie rób tego innym

Cała idea tyczy się to również ludzi z managementu firm programistycznych. Bardzo często starają się wprowadzać nowinki z zakresu zarządzania projektami. Aktualnie na topie jest coś, co określa się nazwą "Agile". Sam proces ma dużo ciekawych elementów, nie jest to jednak nic odkrywczego. Na całe szczęście jest to konstrukcja, która użyta z mózgiem i pomocą ludzi doświadczonych daje bardzo ciekawe rezultaty. Niestety - w większości przypadków ludzie zbytnio do serca biorą sobie formułę "adaptowania procesu do własnych potrzeb", wybierając sobie z całej idei jedynie fragmenty, które powodują jeszcze większy chaos. Doskonałym przykładem jest pojęcie minimalności (nie mylić z minimalizacją). W każdej iteracji powinno się robić kompletne minimum by spełnić wymagania w niej zdefinoiwane. Nikt oczywiście nie bierze pod uwagę następnych kroków, więc bardzo często trzeba przepisywać duże kawałki kodu, bo ktoś nie pomyślał o tym np. miesiąc wcześniej.

Zupełna strata czasu.

Jak już wszędzie zawiodłeś nie rób z kłamstw swojego hobby!

Bo to jest rzecz, która najbardziej mnie przeraża. Przeglądając tony różnych projektów Open Source natrafiam na ten sam problem. Ludzie traktują swoją pasję - programowanie - jak kompletną szmatę. I nie jestem tutaj żadnym chlubnym wyjątkiem. Widzę doskonale jak popełniam te same błędy co inni, "skomercjalizowani" koledzy. Wydaję kawałki kodu, które nie spełniają nawet moich własnych wymagań. Pomijam implementację części specyfikacji, bo uznaję je za niepotrzebne. Chełpię się osiągnięciami, które są przecież dziurawe jak sito! Wprowadzam sobie we własny świat złe nawyki z świata komercyjnego, raniąc przy tym siebie nie mniej od innych. Zatracam się w tym biegu po wszystko tracąc na kunszcie, na którym przecież tak bardzo mi zawsze zależy.

Wyobraźcie sobie na przykład, że fizyk ma przed sobą wyniki badań z jakiegoś doświadczenia. Było to jednak doświadczenia na innym sprzęcie, więc może on uzyskać lekko odmienne wyniki na swoich przyrządach. Ze względu na brak czasu, pomija on etap powtórzenia eksperymentu i od razu wykonuje eksperyment dla niego potrzebny i wnioskując na otrzymanych dokumentach i własnym doświadczeniu tworzy wyniki.

I jeśli nawet te błędy będą minimalne. Do pominięcia, a badania robił dla takiej elektrowni atomowej - na ten przykład - to nagle robi się wielkie BUM i pół Europy zamienia się w nowe morze ze świecącymi rybami.

A wszystko z braku czasu na dopracowaniu szczegółów.

Warto zwalczać?

Oczywiście, że warto! Nikt mi sianem nie wykręci, że informatyka za takie rzeczy nie odpowiada. Oczywiście, że odpowiada. A sterowanie samolotami? Promami kosmicznymi? Bankami, gdzie leżą pieniądze ludzi? Nie pracujecie nad tym? Ale moglibyście, prawda? I co wtedy? Przez waszą pomyłkę - brak czasu - samolot spada, prom wybucha, ludzie tracą oszczędności całego życia i lądują pod mostem.

Apokaliptyczna wizja? Nierealna? Zdziwilibyście się.

Open Source może na tym więcej zyskać niź stracić. Pokazując, że ludzie z pasją, którzy nie pozwalają sobie na tego rodzaju błędy. Że coś co jest darmowe, powstawało znacznie dłużej (limit czasu plus dodatkowa poprawka na tę dokładność), ale jest znacznie bezpieczniejszy!

Jak zwalczać?

Rozmawiać. Podważać opinię ZAWSZE jak myślimy inaczej. Nie ważne czy rozmawiamy z człowiekiem o super doświadczeniu, czy ze zwykłym uczniakiem. Pomysły ma każdy i czasem zmienia sens naszego rozumowania.
Z drugiej strony być otwartym na krytykę. Nie budować Flame War z byle przyczyny. Szczególnie, jak ktoś twierdzi, że może pomóc.
Tworząc swoje oprogramowanie zbudować sobie grupę ludzi, którzy zawsze służą radą i zawsze wytkną. Jeśli boisz się krytyki otwartej (jak na przykład ja), nie odkrywaj kodu przed wszystkimi. Najpierw dopracuj go z ludźmi, którym ufasz. Uodpornisz się na błędy i usuniesz te najbardziej trywialne.

I przede wszystkim kochać to, co się robi. W końcu to jest tworzenie. Twórcy nie są nieomylni, ale przynajmniej powinni się starać być dokładni.

STARTTLS i SASL Gotowe!

Jestem zaskoczony rozwojem sytuacji. Po kilku tygodniach wytężonej pracy w końcu udało mi się osiągnąć najważniejsze elementy nowej biblioteki. Negocjacje szyfrowania połączenia TLS jak i logowanie SASL (metodą DIGEST-MD5 i PLAIN) są gotowe!

Pozostaje jedynie posprzątać trochę kod, dodać parę callbacków i można zabrać się za kolejny etap - czyli obsługę zarzeń (message, presence no i oczywiście iq). Na początku będzie to obsługa podstawowa. Jedynie, by odpowiadać na zapytania version i obsłużyć roster. Ale to już coś!

Będzie można do tego dołożyć kilka okienek w Cocoa i będę już na etapie iChata. A to już dużo, szczególnie, że elastyczność rozwiązań daje łatwą możliwość rozbudowy możliwości biblioteki.

Nie mówię jeszcze hop. Prawdziwy test biblioteka przeżyje niebawem, kiedy obsłużywszy co trzeba spróbuję się zalogować na wszystkie serwery, na których mam konta (z gTalk włącznie).

Przepełnia mnie duma i radość.

Dla mnie to już duże osiągnięcie.

Problemy z OpenSSL

Rozwiązawszy już moje potworne problemy z pamięcią (oczywiście byłem debilem :P), zabrałem się za implementację TLS. Ostatniej rzeczy, jaka mi została do zrobienia. Używam biblioteki OpenSSL, ponieważ jest częścią systemu maczkowatego. Natknąłem się jednak na nie lada problemy.

Mało jest pomocniczych przykładów jak tego używać, w szczególności odnośnie TLS. Robię coś takiego:
SSL_library_init();
ssl_context = SSL_CTX_new(TLSv1_client_method());
ssl_ptr = SSL_new(ssl_context);

sock_bio = BIO_new_socket(sock, BIO_NOCLOSE);

if (sock_bio == NULL)
return NO;

SSL_set_bio(ssl_ptr, sock_bio, sock_bio);

if (0 == SSL_connect(ssl_ptr))
return NO;


Niby jak z przykładów. Problem w tym, że wszystko przechodzi gładziutko, ale jakiekolwiek próby użycia SSL_read() lub SSL_write kończy się całkowitą klapą. Rzuca błędem odczytu/zapisu i już.

Co ja do cholery robię źle?

Postępy

Na stronie projektu dodałem sobie zadania, jakie muszę wykonać, żeby zamknąć pierwszy kamień milowy. Masakra. Nawet w przypadku równouprawnienia wszystkich zadań (tj. faktu, że każdy zajmie mi tyle samo czasu i sił) to mam zrobione dopiero 15%.

Ciężka robota przede mną jeszcze.

Eh.

Strumienie w Cocoa

Cocoa ma bardzo wygodną i w sumie czystą implementację strumieni. Korzystamy z metody jednej klasy i już po chwili mamy śliczne strumienie wejściowe i wyjściowe działające gdzieś w tle, a my tylko siorbiemy, tudzież wysyłamy dane. Niestety NSStream jest dość niestabilne. Dlatego sugeruję jednak korzystać z POSIXowych rozwiązań, które zdają się być jednak bardziej użyteczne. Sam nadbudowałem ładną klasę do obsługi takowych. Nie jest to trudne, więc polecam.

Z drugiej strony - mój program wciąż rzuca SIGBUS, a ja, głupek, nie jestem w stanie wciąż zlokalizować dlaczego.

Eh...

DIGEST SASL DONE! Problem prawie rozwiązany

Właśnie. Prawie.
Z kompletnie niezrozumiałych dla mnie przyczyn na reinicjację strumienia, po otrzymaniu encji <success /> dostaję następującą wiadomość:

<?xml version='1.0'?>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='823265377' from='bazyl.net' xml:lang='en'>
<stream:error>
<invalid-namespace xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
Czy ktoś mądry może mi wyjaśnić, czego ta pierdoła ruska w postaci serwera ode mnie chce? Nie dość, że zaczął cały strumień XML od zera (a nie tylko tag sesji), to przypieprza się do przestrzeni nazw, którą sam sobie narzuca i zmienia w drodze?

O co tu, kurwa, chodzi???

XMPP (Postępy i pytanie)

Wczoraj dość niewiele udało mi się wykonać. Głównie przez zmęczenie i brak czasu. Dodałem jedynie rozpoznawanie adresu i portu serwera XMPP na podstawie JID'a (DNS i wpisy SRV). Dziś GSASL. Jutro może TLS. Zobaczymy jak to pierwsze mi pójdzie.

Chwilowo dręczy mnie jednak inne pytanie. Czy ktoś ma postawionego gdzieś jwchata? Strona projektu jest u mnie zablokowana na proxy firmowym, a nudzę się tak przeokrutnie, że przynajmniej posiedziałbym na IMie :P

Za każdą pomoc gorąco dziękuję.

XMPP.Framework

Pracowałem nad tym już wcześniej, publikując Jabbaha, który w jakimś tam stopniu był funkcjonalny. Przeszło mi, bo zapotrzebowanie było.. hm.. żadne? :)

Teraz sprawa ma się zupełnie inaczej. Staram się za wszelką cenę zaimplementować pełen protokół XMPP. Zarówno XMPP Core jak i XMPP IM. Oczywiście będzie też implementacja kolejnych rzeczy. Chwilowo jednak te elementy są dla mnie najważniejsze. Oznacza to na przykład pełne wsparcie dla języków i przestrzeni nazw XMLa. Z autoryzacją opisaną w protokole, czyli SASL. W planach jest obsługa jedynie dwóch sposobów logowania. Oczywiście są to SASL Digest i SASL PLAIN. Założeniem jest również utrzymanie biblioteki w bardzo czystej i wygodnej do wykorzystania formie. Nie będzie to jednak zwykły projekt Open Source. Na pewno jednak będzie można z niego za darmo korzystać.

Cała biblioteka przygotowana jest do projektu, który już powstał i powoli się rozwija. Jest jakby jego częścią, ponieważ na czymś funkcjonalność trzeba testować. Na razie idzie mi silnie pod górkę. Okazuje się bowiem, że tak jak i GSASL nie działa pod Maczkami jak trzeba, tak i obsługa zwykłego, głupiego TLS jest tam troszkę niedopracowana. Nie można dokonać "przerzutu" ze zwykłego połączenia na połączenie TLS. Oznacza to dodatkowy nakład pracy w zaimplementowanie własnej wersji Socketów. BXStream, BXInputStream i BXOutputStream.

Bardzo jednak zależy mi na uniknięciu wynajdowania koła od nowa, więc będę się starał wbudować znane biblioteki obu tych elementów do frameworka i nadbudować nad nimi jedynie interfejs w Objective-C.

Jedno jest pewne. Jestem silnie zdeterminowany, żeby poprowadzić dobrze ten projekt. Nie mam zamiaru odpierdzielać fuszerki. Pewnie dlatego zajmie mi to stanowczo za dużo czasu. Cieszę się bardzo, że są ludzie, którzy wspierają mnie przy tym. Smoku daje z siebie wszystko co tylko może, najbliźsi rozumieją, kiedy chowam się w kącie ze swoim komputerem i klnę cicho pod nosem, kiedy coś po raz setny nie chodzi jak trzeba. Jajcuś zapytany, zawsze stara się odpowiedzieć. Wytykają mi nieumiejętne czytanie specyfikacji protokołu. Ale to dobrze. Bo to musi być solidnie zrobione. Źródła już są na sieci. Nie są jednak publiczne. Mają dostęp do tego jedynie wybrańcy. Więc jeśli ktoś będzie zainteresowany obejrzeniem samego kodu - zapraszam. Dokumentacja korzystania z frameworka zostanie opublikowana bardzo niebawem. Niestety jeszcze przed samym frameworkiem. No ale cóż. Plan już jest od dawna. Tylko doba za krótka, żeby wszystko zrobić dostatecznie szybko.

Wynajduję koło od nowa

Niestety sprawa wygląda tak:


@interface BXSASL : NSObject
{
    uint8_t mechanism;
    NSString *realm;
    NSString *username;
    NSString *password;
    NSString *nonce;
    NSString *cnonce;
    NSString *rspauth;
}

- (id)initWithUsername:(NSString *)usr password:(NSString *)pwd andMethod:(NSString *)meth;
- (void)dealloc;

- (BOOL)getAnswer:(NSString *)answer toChallenge:(NSString *)challenge whichIsBase64Encrypted:(BOOL)enc;
- (BOOL)saveRspAuth:(NSString *)theRspAuth whichIsBase64Encrypted:(BOOL)enc;

@end


Tak tak. Poczytałem trochę i wynajduję koło od nowa i implementuję własną obsługę SASL. Na razie zaimplementuję tylko metodę DIGEST-MD5 i (być może) PLAIN. Mam GSASL za wzór. Musi wystarczyć.

Zły jestem. Zawsze pod górkę. No ale takie życie :(

TLS

Mojej radości nie ma granic. Apple się postarał i strumienie (klasa NSStream) ma wsparcie do TLS!!!

Ależ roboty mi to ujmie! Pozostaje jedynie ten nieszczęsny SASL. Niestety GSASL robi mi hopsasy i nie chce się ładnie skompilić. Czeka mnie albo wciąganie całej biblioteki do projektu (Expat już się tego doczekał. A było z tym jazdy co nie miara! Jak można include'ować inne pliki .c wewnątrz innego pliku .c??? I to po 3-4 razy!).

Muszę jeszcze pogrzebać na stronach Apple'a. Może coś się tam dla mnie znajdzie. Mój najlepszy przyjaciel, jakoś ostatnio mało pomocny jest :(

Trzymać dalej kciuki!

SASL

Z racji faktu, że staram się być w pełni zgodny z protokołem XMPP, staram się zaimplementować SASLową implementację autoryzacyjną.

Przyznam się szczerze, że pisanie od zera tego mechanizmu się mi nie widzi. Czy ktoś zna wygodną bibliotekę, z której można skorzystać do tego celu?

Czy GSASL jest dobrym rozwiązaniem?

Każda rada mile widziana.

NSURL robi psikusy a NSStream nie wie o co chodzi

Ponieważ rzeczy podstawowe nadal zapełniają po kolei karty mojego mini-podręcznika, podzielę się drobną uwagą na temat programowania w Cocoa.

Uważajcie z NSURL. Jeśli podacie mu adres bez podanego protokołu (np bazyl.net zamiast http://bazyl.net na ten przykład) to nie wyrzuci błęda. Ale wywołanie metody pobrania czystego adresu zwróci NULL. Bardzo nieprzyjemne.

Problem jest tym większy, że jak Wam wpadnie do glacy korzystać z tej klasy do sprawdzania poprawności adresu przed otworzeniem strumieni (NSStream) to możecie się nieźle zdziwić.

Konstruktor NSStream przejdzie gładziutko. Dostaniecie notyfikacje, że strumienie został otwarte i są gotowe na przyjęcie danych. Dopiero próba napisania czegoś po strumieniu wyjściowym (NSOutputStream) zwróci -1 jako błąd, po czym rzuci zdarzeniem błędu do metody nasłuchującej.

Moim skromnym zdaniem - to trochę głupie.

iCollins

Tak jak już obiecałem, wystawiam paczkę mojego interface'u słownika Collinsa pod Mac OS X.

Osobiście uważam, że implementacja, czyli program AngelaX jest znacznie wygodniejszym rozwiązaniem, to mogę się pochwalić przynajmniej ładnym kolorowaniem składni.

Nie wiem czy będę kontynuował ten projekt. Chwilowo spełnia moje wymagania, ale wszelkie uwagi są oczywiście mile widziane.

Chciałbym, żeby program był ściągany jedynie z tej strony, a nie rozprowadzany pocztą pantoflową. Gdyby jednak ktoś chciał to wystawić gdzieś u siebie, bardzo proszę o uprzedni kontakt ze mną (na mail, JID, czy co tam innego).

Życzę miłego korzystania

Technicznie o Maczkach?

Chciałbym się Was zapytać, czy byłby sens stworzenia bloga mówiącego o programowaniu pod Maczki. Tj. programowania w Cocoa, używanie narzędzi i bibliotek NeXTSTEP i tym podobnych rzeczy.

Nauczyłem się już dość sporo o tym światku i sam mam pewne przemyślenia na ten temat. Pewne doświadczenia.

Jeśli znajdzie się choć kilka osób chcących to czytać i sami wejść w świat programowania pod Maczki, proszę o kontakt. Wtedy zdecyduję się na taki ruch. Bo wiem, że polskiej książki na ten temat nie ma. Tylko jakieś banialuki podstawowe.

Czekam na odzew ;]

Technicznie

Wiem, ze ten blog techniczny juz nie jest. Zapewne pomysle o otworzeniu dodatkowego (zapewne na joggerku :P) specjalnie do tych celow.

Do rzeczy jednak.

Lata temu mialem plan napisac klienta jabbera (ktorego ten pan ochrzcil juz nawet imieniem (Jabbah). Sprawa upadla. Z braku checi.

W ramach moich wewnetrznych zmian w koncu zmusilem sie, zeby do projektu wrocic.

Aktualnie jest on podzielony na trzy podprojekty.

Pierwszy z nich to GLid. Komponent wizualny Cocoa dostarczajacy funkcjonalnosc grid'a (siatki). Jednakze rozbudowany jest o pewne bajery, takie jak animowane zmiany wierszy, wkladanie grafik, stylizowanie tekstow, budowanie drzew. Niestety standardowe komponenty Cocoa niezbyt taka funkcjonalnosc daja. I jak pewnie sie latwo orientujecie, potrzebuje tego do implementacji rostera. Projekt nawet nie zobaczyl jeszcze zbudowania drzewa katalogow ;] Zajme sie tym na samym koncu. Teraz moge udawac te funkcjonalnosc uzywajac istniejacych elementow.

Drugim podprojektem (najdynamiczniej sie teraz rozwijajacym) jest Jabber.framework. Jest to biblioteka komunikacyjna jabbera pisana natywnie na Mac OS X i bedaca calym sercem projektu. Oparta na znanym wszystkim expatcie. Byc moze wyda sie to Wam zabawne, ale biblioteka jest TYLKO i WYLACZNIE do uzywania pod Mac OS X. Uzywa bibliotek NeXTSTEPa i jest pisana w Obj-C.
Dlaczego tak? Bo natywnej biblioteki pod maczka zwyczajnie nie ma, a przeciez sa ich setki. A te ktore sa naprawde cos warte, jak gloox uzywaja glib'a, ktorego pod maczka nie ma :(. Celem jest doscignac glooxa, co raczej jest niemozliwe bez pomocy ;] Na razie biblioteka stawia pierwsze kroki. Zaczyna sie logowac do serwera, wysylac wiadomosci, czy nawet pobierac roster. Ale to przeciez tylko podstawowe rzeczy :)

Ostatnim podprojektem - wykorzystujacym pozostale jest oczywiscie Jabbah sam w sobie. Czyli pierwszy natywny, ladny (w przeciwienstwie do pozostalych) i w pelni funkcjonalny (znow uklon do brakow, chociazby iChata spod Tigera) klient jabbera pod Mac OS X.

Dlaczego to wszystko opisuje?

Bo potrzebuje pomocy. Kazda, jaka jestescie w stanie mi dac.

• Code revision biblioteki, zeby sprawdzic, czy nie psuje czegos i nie interpretuje zle standardow XMPP.
• Dostarczenie roznych implementacji serwerow do testow, tj zalozenie mi tam kont testowych i oczekiwanie, ze beda przychodzic zapewne bledne komunikaty podczas testow :)
• Testowania aplikacji samej w sobie. Jestes posiadaczem Maczka? Moze mi pomozesz to testowac!
• A moze masz maczka i chcialbys ze mna troche pokodowac? Nie obraze sie. To darmowy projekt. Nigdy nie mam zamiaru z niego dusic pieniedzy
• Potrzebuje rowniez projektu ikonek. Do rostera, ikonki programu... Nie jestem grafikiem. Czy ktos moze przyjsc z pomoca?
• A stronka wszystkich projektow? Czy ktos moglby pomoc mi taka stworzyc?

Duzo tych rodzajow pomocy :) W kazdym razie, jesli mozesz pomoc, odezwij sie, zostaw komentarz, badz odezwij sie na moj JID.

Kazda pomoc bardzo mile widziana :)

Pokazmy, ze na Maczkach tez pojawia sie potega Jabbera :)

XGL + Debian

= wielka porażka. Praktycznie każda dystrybucja ma już w swoich pakietach xgla. Jedynie debian jest w tyle. to samo z fglrx (sterownikiem ATI). Mają tak starego, że nóż się w kieszeni otwiera. Naścierałem się, żeby nowy Xorg ruszył z tym sterownikiem. A teraz się okazuje, że żadna z magicznych recept, któ¶e znalazł mi mój przyjaciel do niczego się nie nadaje.

Teraz ciekawe co nastąpi najpierw. Czy ja zmienię dystrybucję, czy Debian wyda XGLa w pakietach.

Sic!

Nowe

Przychodzi nowe. Od dawna z tym walczę, ale niestety mój kochany maczek ma akurat z tą technologią sporo problemów.
Niestety pora wyciągnąć lapa firmowego i zabrać się za całą sprawę na poważnie w poważnych systemach.

BenQ-Siemens EF81

Ostatnio coraz większym zainteresowaniem cieszą się telefony komórkowe. Kiedy powstała nowa marka (BenQ-Siemens) przez wykupienie przez tajwańską firmę dział komórkowy Siemensa, zaczęło się robić ciekawie. Zaczęto promować nową markę, gdzie telefon klapkowy (z ang. clamshell mobile phone) o numerze EF81 odgrywa dość istotną rolę.

Telefon ten jest skierowany dla bogatszych odbiorców. Ma bardzo duży wyświetlacz wewnętrzny (240x320 pixeli o 16bitowej głębi kolorów) i całkiem ciekawy wyświetlacz zewnetrzny (120x160 pixeli i też głębi 16 bitów). Ciekawostką jest metalowa obudowa i bardzo wytrzymała na rysy ochrona wyświetlaczy.

Warto też zwrócić uwagę na oprogramowanie wewnątrz telefonu. Nie daje odetchnąć konkurencji, dostarczając użytkownikowi wszystko, czego potrzebuje. Wszystko to, na gęstych wyświetlaczach daje naprawdę dobry efekt. Wzorowany na GSMowym telefonie Motorolii RAZOR V3, może nie dościga jej designem, ale jest technologicznie bardzo ciekawy. Videotelefonia (UMTS), odtwarzanie wielu formatów audio/video, całkiem zgrabna przeglądarka internetowa (HTML a nie tylko WAP) pozostawia wiele do życzenia. Ważnym hintem jest jednak, że Opera Mobile chodzi na telefonie bardzo ładnie.

Do minusów zaliczyłbym przede wszystkim brak USB mass storage. Jakakolwiek wymiana danych z komputerem może nastąpić jedynie przez dedykowany soft (Mobile Phone Manager).

Chciałbym również przestrzec zapaleńców, którzy mogą dać się nabrać na głupoty wypisywane na temat tego telefonu przez wielu wariatów z sieci. Telefon nie ma systemu opartego na linuxie. Jest to komercyjna platforma, która z linuxem nie ma nic wspólnego.

Dlaczego piszę o tym telefonie? Jestem użytkownikiem. Jak większość z nas. Wkurzają mnie braki, jakie widzę w innych telefonach. Wkurzają mnie mało wygodne GUI (EF81 oparty jest zdziebko na GUI poprzedniego modelu tej generacji SXG75, który nie trafił na polski rynek) i prezentuje się bardzo wygodnie. Jest czytelny i można mu ustawić tak duże czcionki, że nawet moja babcia byłaby w stanie czytać z jego ekranu. Po prostu bardzo mi się ten telefon podoba.

Ale mnie na słowo też nie dokońca należy wierzyć. Dlaczego? Ponieważ ten telefon jest produktem w pewnej mierze polskim. Oprogramowanie zostało do niego napisane we Wrocławiu w tutejszym dziale R&D firmy BenQ Mobile (Wcześniej Siemens Mobile). I jestem dumnym współprojektantem i współtwórcą tego telefonu.

Telefon wychodzi na rynek w najbliższym tygodniu. Operatorzy jednak zaczną go sprzedawać dopiero za jakiś czas (za miesiąc - a polscy, to cholera wie kiedy), więc na kupowanie go za obniżoną kwotę cyrografu (umowy z operatorem) musimy jeszcze trochę poczekać.

Przyjazność mozilli

Ostatnio mozilla wydała mi się troszkę mniej przyjazna. Chyba głównie dlatego, że nie są skorzy do rozdawania narzędzi, które promują.

Ostatnio poczułem potrzebę zrobienia czegoś dla firefoxa. Niestety - narzędzia do tworzenia modułów dla niego istnieją tylko dla windowsa i linuxa. I ani słowa o macach...
Ogarnęła mnie wściekłość. Ale jednak się da. Jedynie Gtk+ i libIDL jest potrzebny, żeby skompilować gecko SDK pod maczka. Niby proste. Ale jednak trzeba się napracować. Mnie się udało.
Jakby ktoś chciał się kiedyś w to zabawić, to pamiętajcie, że libIDL potrzebuje wskazania rodzaju platformy ręcznie (--host=powerpc). Będzie krzyczał, że mu coś nie gra, ale pójdzie dalej.
Co do kompilacji gecko SDK, to potrzeba zaciągnąć pełne źródła mozilli i skompilować je z flagą --enable-standalone-modules=xpcom. Dzięki niej nie zbudujemy całej mozilli a jedynie jej część do budowy XPCOMów. I Voila.