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

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!

XMPP.Framework - wielki comeback

Ja chyba nigdy nie będę w stanie być słowny.

Tym razem postaram się po raz kolejny. Projekt iTalk'a nadal w powietrzu, czeka nieustannie, aż skończę XMPP.Frameworka do jako takiej sytuacji, żeby można było przynajmniej gadać normalnie.

I chyba w końcu prawie mi się to udało. Wszystko co miałem przepisałem praktycznie od zera. Zamiast swoich rozwiązań XMLowych użyłem NSXMLElement. Ponieważ od Tigera również jest libsasl, jego również tam znajdziecie, zamiast moich wypocin, które mogą być pełne wad. Oczywiście wziąłem do siebie ideę "KISS". Podszedłem do sprawy również na tyle inteligentnie, że najpierw zaprojektowałem co chcę zrobić. Efekt to doxygenowa dokumentacja interfejsów wersji 0.1. I trochę moich prywatnych wypocin jak co zrobić pod spodem.

Przy okazji podszkoliłem już mój Objective-C na tyle, że nauczyłem się pisać metody prywatne (korzystając z ładnego ukrywania rozszerzeń), co też odśmieciło kod.

Pod spodem oczywiście Expat. Jestem zadowolony. Zaczyna działać. A jeśli będzie tak dobrze, jak już wygląda, to niebawem wersja ta wyjdzie i będę mógł dołożyć jakiś interfejs graficzny na szybko :)

Ale nic nie obiecuję. Nie wychodzi mi to najlepiej.

Wkurzyłem się

Tygrysek i dodatkowe pół giga RAMu już do mnie jedzie. Bo w tym tempie i z tak przestarzałymi narzędziami jak XCode w wersji 1.5 (ostatnia wersja wydana na Panterkę) wobec obecnej wersji 2.4.1 to jednak kamień łupany.

Do tego musi się szybciej kompilować, bo za dużo czasu tracę na pierdoły. I dobrze debuggować, bo w 1.5 debuggowanie wielowątkowych aplikacji kuleje koszmarnie.

Jeszcze jakieś 2-3 dni czekania i będzie.

W końcu!

Się dzieje! - czyli wołanie o pomoc

Prace trwają nieprzerwanie i powoli już okienka zaczynają wyglądać. Niebawem (czyli dziś) zaczną być już również funkcjonalne, ale ja nie o tym chciałem.

Potrzebuję ikonek! Pilnie!
Aktualnie podprowadziłem ikonki stanów z psi crystal roster, ale pasuje mi to jak pięść do nosa.

Poratowałby ktoś czymś skromnym, ale i porządnym? Małym, ale zgrabnym i maczkowatym? :)
Będę wdzięczny za każdą pomoc.

A oto jak się prezentuje roster (z tymi beznadziejnymi ikonkami), co by designerzy wiedzieli do czego projektują :P

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.

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!

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

Słownik

Podczas pisania (i poprawiania) rozdziałów, nagle zabrakło mi jakiegoś słowa.
Zgłupiałem. Potrzebowałem słownika online, ale słówka akurat tam nie było. Z pomocą przyszedł dopiero współlokator i jego słownik Collinsa.
Niby słownik nie znów tak zajebisty, ale co potrzebowałem to miał.
Wiedząc, że istnieje projekt obsługi baz Collinsa pod linuxem, postanowiłem wziąć bazy tego słownika i korzystać z tego ncurses'owego narzędzia pod maczkiem (w końcu to UNIX).

Szybko mi to zbrzydło. Ponieważ YdpDict ma prostą bibliotekę do obsługi tych plików baz danych, szybko sklepałem swoje własne okienka.
I oto i one:
Niby nic specjalnego, ale sam znajduje słowo (rozpoznaje sam język) i wyświetla ładnie pokolorowane wyniki.

Zastanawiam się właśnie czy to nie spaczkować. W sumie robota żadna, ale może jest chętny?

Pedeefujemy podręcznikowo

Opublikowane dotychczas krótkie notki o programowaniu pod Maczkiem nie są może jeszcze czymś nadzwyczajnym, ale zdążyłem dopisać kilka rozdziałów. Dlaczego ich nie opublikowałem? Bo zacząłem zdawać sobie sprawę, że ominąłem wiele kwestii, które powinny się znaleźć wcześniej.

Podjąłem zatem decyzję, że na modłę Poradników przerzucę się na pisanie PDFów. Będzie to ciągła praca, rozwijany dokument z każdej możliwej strony. Poprawioną wersję z dodatkowymi rozdziałami, wstępniakiem staram się właśnie poskładać z wersji HTMLowej w coś bardziej czytelnego.

Tutaj mam prośbę do czytelników. Czy moglibyście mi poradzić coś do składania PDFów pod maczkiem (używam Pantery na G4)? Najlepiej bezpłatnego. Wiem, że to trudne, ale niestety chwilowo nie stać mnie na wydawanie kasy na programy. Tzn stać mnie, ale chcę to zrobić jak już kupię sobie nowiuśkiego maczka, na którego aktualnie składam :)

Od razu informuję, że nie będę pobierał żadnych opłat za tę "książkę". Wystawię jedynie możliwość płatności PayPal, jeśli ktoś stwierdzi, że warto wrzucić parę groszy za ten wysiłek.

Ów poradnik pojawiłby się szybko i byłby w kółko aktualizowany. O tych aktualizacjiach informowałbym oczywiście na blogu. Komentarze mile widziane.

Obiecane skrinszoty programów też powinny się pojawić niebawem. Bo w sumie jest już co skrinszotować :)

Za pomoc w doborze narzędzi, z góry dziękuję.

Tego pełno a Ty chcesz jeszcze pisać coś nowego

Natchniony jedną bardzo starą notką Smoka, stwierdziłem, że troszeczkę uogólnię i napiszę coś od siebie na temat wolnego oprogramowania :)

Kiedy dawno dawno temu ktoś przekonał mnie do używania Maczka, ludziska dookoła pukali się tylko w głowy. Bo przecież drogi, bo jakiś taki gadżetowaty. No i przede wszystkim - nie dla mnie. Bo jedyny soft, jaki tam działa dobrze, to soft do obróbki obrazu i dźwięku.

Tylko, że właśnie to był powód mojego wyboru!

Jakiś czas temu starałem się zmusić do napisania kilku rzeczy. Swojego oprogramowania. Chciałem się sprawdzać, chciałem być znany. Chciałem dużo robić szumu wokół siebie i silić ego uznaniem innych.

Bardzo tandetne, ale prawdziwe. Najciekawsze jest to, że do tej pory nic się w tej materii nie zmieniło.

Potrzebowałem bodźca, którym byłby właśnie wspomniany brak oprogramowania. Dlatego chciałem pisać swoje. Chciałem, ale musiałem się jakoś do tego zmusić.

Wciąż były wymówki. Używanie maczka zbyt rzadko, posiadanie alternatyw. Dopiero wyjazd na zachód uświadomił mi ile straciłem czasu. Zabierałem się za wszystko jak pies do jeża.

Teraz obkupiony w książki, chłonę wiedzę i faktycznie coś robię. Jestem bliżej niż kiedykolwiek jakiegokolwiek wyniku (nawet jeśli mizernego).

Przeszła mi już chęć ekspanowania siebie i próby zdobycia uznania za wszelką cenę. Teraz najważniejsze jest dla mnie napisać ten program. Bo jest mi potrzebny, bo polubiłem programowanie pod maczkami, bo widzę już rezultaty (choć nadal mizerne) i za nic nie chcę się nimi podzielić ze światem (jeszcze nie).

Nie będę kłamał, że na uznaniu mi nie zależy. Wręcz przeciwnie. Jest mi bardzo potrzebne. Bo kiedy dotrę do jakiegoś wydania - produktu, który będzie już działał w miarę. Jeśli zobaczę, że nikt więcej go nie używa, przestanę go rozwijać. I znów spali na panewce cały wielki plan. Rozpalony, niczym łuczywko, znów stracę cały swój impet.

Na to nie mogę sobie już pozwolić.

Oczywiście na wszystko brakuje czasu. Nie żyje się komputerem. Ale mimo wszystko jakoś idzie.
Wczoraj miałem wydać artykuł, ale jakoś się nie złożyło. Jest dla mnie zbyt mało ważny w porównaniu z samym projektem.

I dlatego to robię. Bo lubię i jest to platforma na której można to pokazać. Bo tam brakuje softu. Stąd też cykl artykułów. Żeby zachęcić innych ze środowiska OpenSource, żeby tworzyli soft na Mac OS X. Bo go tam po prostu nie ma.

Wiem, wiem. Mało kto ma maczki w Polsce. Mało komu się będzie chciało.

Ale i tak spróbuję.

Bo w sumie i tak mnie nic to nie kosztuje.

A zaniechanie tego - będzie kosztowało.

Moje ego.

O tym jak ruszyć obiekta

Ostatnim razem prawie udało nam się skończyć naszą pierwszą klasę. Pozostało nam jedynie pozmieniać kilka znaczków wewnątrz ciągu znaków. Problem jedynie leży w naturze klasy NSString.

Obiekty (nie-)modyfikowalne

Jest to bowiem tak zwany obiekt niemodyfikowalny (ang. immutable). Oznacza to, że raz zainicjowana wartość pozostaje w nim niezmienna. To czego my jednak byśmy chcieli to obiekt modyfikowalny (ang. mutable). Na całe szczęście istnieje taka wersja klasy NSString. I - jak łatwo się domyśleć - jest to właśnie NSMutableString. Owa klasa dziedziczy oczywiście po oryginalnym NSString co oznacza, że łatwo będzie "przerzucać" te obiekty jako NSString.

Stwórzmy więc nową metodę, która będzie zwracała nam ciąg znaków przerobionej wartości argumentu, którą trzyma.
Szybka deklaracja
-(NSString *)convertValue;

I definicja w pliku .m
-(NSString *)convertValue
{
  NSMutableString *convValue = [[NSMutableString alloc] init];

  [convValue setString:value];

  // Now change the chosen characters
  [convValue replaceOccurrencesOfString:@"&" withString:@"&"
    options:NSLiteralSearch range:
NSMakeRange(0, [convValue length])];
  [convValue replaceOccurrencesOfString:@"<" withString:@"&lt;"
    options:NSLiteralSearch range:
NSMakeRange(0, [convValue length])];
  [convValue replaceOccurrencesOfString:@">" withString:@"&gt;"
    options:NSLiteralSearch range:
NSMakeRange(0, [convValue length])];
  [convValue replaceOccurrencesOfString:@"'" withString:@"&apos;"
    options:NSLiteralSearch range:
NSMakeRange(0, [convValue length])];
  [convValue replaceOccurrencesOfString:@"\"" withString:@"&quot;"
    options:NSLiteralSearch range:
NSMakeRange(0, [convValue length])];

  [convValue autorelease];

  return convValue;
}

I wszystko jasne! Ale potłumaczmy conieco z tego, co tutaj się dzieje. Szybko tworzymy sobie obiekt typu NSMutableString. Metoda replaceOccurrencesOfString: WithString: options: range: podmienia nam wystąpienia ciągu znaków na inny ciąg znaków. Ostatnie dwa parametry metody to dodatkowe opcje (u nas wybieramy dosłowne szukanie) i zakres - my chcemy szukać w całym ciągu. Dlatego za każdym razem zliczamy jeszcze raz długość ciągu znaków, ponieważ po każdej podmianie może on ulec zmianie.
Na samym końcu oczywiście robimy autorelease, żeby nie pogubić pamięci i zwracamy!

Teraz wystarczy nam jedynie zmodyfikować jedną linijkę z metody toString z:
retValue = [retValue stringByAppendingString:value];

na:
retValue = [retValue stringByAppendingString:[self convertValue]];


I to w sumie wszystko! Teraz już wszystko nam się przerabia jak trzeba.
ale...

NSMutableString to coś znacznie więcej! Pozwala na wiele innych operacji. Między innymi rozwiązuje problem konkatenacji ciągów znaków za pomocą metody:
- (void)appendString:(NSString *)aString


I tak oto powstają dwa zadania domowe!

Zadanie domowe dla leniwych

Zmodyfikować metodę toString tak, żeby korzystała z NSMutableString i konkateonowała ciągi znaków w miejscu, zamiast rozwalać się po niesamowitej ilości obiektów typu NSString.

Zadanie domowe dla gorliwych

Ponieważ to koniec lekcji podstawowych i przechodzimy do Cocoa, potrzebujemy jeszcze jednej klasy. Mianowicie klasy XMLNode. Nasza klasa będzie wyglądała tak:
@interface BXXMLNode : NSObject {
NSString *name;
NSString *lang;
NSString *nspace;
NSString *value;
NSMutableArray *attributes;
NSMutableArray *subNodes;
NSAutoreleasePool *pool;
}

// Constructors and destructors
- (id)init;
- (id)initWithName:(NSString *)nodeName;
- (void)dealloc;

// BXXMLNode attributes accessors
- (NSString *)name;
- (void) setName:(NSString *)newName;
- (NSString *)lang;
- (void) setLang:(NSString *)newLang;
- (NSString *)nspace;
- (void) setNspace:(NSString *)newNspace;
- (NSString *)value;
- (void) setValue:(NSString *)newValue;

- (void)addAttribute:(BXXMLAttribute *)attr;
- (void)addAttributeByName:(NSString *)attrName andValue:(NSString *)attrValue;
- (NSString *)getValueOfAttribute:(NSString *)attrName;

- (void)addNode:(BXXMLNode *)node;
- (BXXMLNode *)getNode:(NSString *)nodeName;

- (NSString *)toString;
@end

Jak łatwo zauważyć, korzystamy z dodatkowych bajerów, jak NSMutableArray, czyli modyfikowalnej tablicy. W tym wypadku jeden obiektow typu XMLAttribute a drugi obiektów typu XMLNode. Dla tych, którzy chcą się pobawić, podaję kilka dodatkowych wskazówek, które mogą uprościć życie:

• NSString posiada miłą metodę compare
• Zamiast importować inne nagłówki w nagłówkach warto użyć formuły @class XMLAttribute. Takie zagnieżdżone importowanie wydłuża kompilację, a tak szybko informujemy w innym miejscu, że taka klasa jest i i na pewno się o niej dowiemy.

Powodzenia! Bo już niebawem wchodzimy maczkowi w kakao :D

Za krótka doba

Doba jest stanowczo za krótka. Nie starcza czasu na zrobienie wszystkiego, co by się chciało.

Wczoraj obiecałem komuś pomóc i zwyczajnie nie zdążyłem. A tutaj lista się wydłuża. Już prawie 4 dni zabieram się do kolejnego artykułu, a pierwsza wersja Jabbah nadal nie ujrzała światła dziennego, bo jest jeszcze tysiące rzeczy do zrobienia.

Bardzo mi nieodpowiada taki stan rzeczy. Dziś koniecznie trzeba zamknąć sprawy zaległe. Pomoc musi zostać udzielona, artykuł wydany, a ja powinienem już testować pierwsze okienka Jabbah. Chciałbym jeszcze w lutym wydać jego wersję 0.1.

Ponieważ Jabbah swojej strony nie ma (i nie wiem czy będzie miał, bo nie ma kto jej zrobić/utrzymywać) opiszę tutaj stopniowanie wersji:

Wersja 0.1:
Podstawowa fukncjonalność. Logowanie, wymiana messydżów, obsługa rostera w podstawowej formie: dodać usera, usunąć usera. Roster będzie brzydki, nie będzie obsługi dźwięków (bo nie ma kto mi ich zrobić :P) ani emotek.

Wersja 0.2:
Dodajemy rejestrowanie nowych użytkowników i obsługę transportów. Roster zostaje wymieniony na bardziej cukierkowy. Okno rozmowy wzbogacone o obsługę emotek (emotek nie będzie, póki mi ich ktoś nie dostarczy :P). Emotki będą mogły być animowane. To nie problem :)

Wersja 0.3:
Spełnienie funkcjonalności protokołu XMPP w pełni. Dodanie kilku JEPów (w tym od avatarów). Końcowa wersja rostera, konfigurowalne tematy.

Wersja 0.4:
Dodanie obsługi przesyłania plików i mechanizmu dodatków (pluginów) wraz z podstawową wersją pluginu do obsługi jogger.pl

Wersja 0.5:
Metakontakty, dodatkowe JEPy (listy tutaj nie będę przytaczał)

Potem lista jest jeszcze długa, ale dotarcie do wersji 0.5 już jest sporym wyzwaniem i mam dziką nadzieję, że po drodze znajdzie się ktoś, kto mi pomoże. Wersja 0.1 musi wyjść już nie bawem, bo mnie świeżbią troszkę paluszki :D Widzę, jak się wszystko łączy i śmiga... Nie mogę się doczekać, żeby dorzucić te kilka dodatkowych okienek i puścić taką brzydulę w świat :)
Wiem, że tego brzydactwa na początku nikt nie będzie używał, ale dla mnie to też kop, żeby samemu zacząć używać mojego dzieła. A jak doskonale wiemy - jeśli samemu zacznie się używać programu, który się rozwija, to rozwój nabiera już wtedy poważnego tempa :)

Tylko czemu doba jest tak krótka!?!?

Jabbah dorobił się ikonki!

Projekt Jabbah idzie coraz mocniej do przodu!
Kolejne artykuły już w drodze, o tym jak się bawić w Cocoa. Tymczasem, dzięki Damianowi Mokry oraz firmie LemonIT, dostałem zestaw propozycji ikonki programu!

Nie będę oszukiwał, że wybór padnie dzięki jakiemuś ogólnemu głosowaniu :) Wybrałem ją sobie sam i zdecydowanie będzie to właśnie ta ikonka:

Cieszę się jak dziecko, a projekt nabiera tempa!

Trzymajcie kciuki!

Wprowadzenie: Fajnie, ale czemu taki dziwny język?

Każdy podręcznik zaczyna się od podziękowań i masy innych informacji na temat bardziej ogólny.
Uczynię to samo, w bardziej jednak skróconej formie. Chciałbym mianowicie skoncentrować się na jedynym elemencie, który może zainteresować ewentualnego czytelnika, czyli dlaczego ten cały Mac OS X używa tak kretyńskiego języka programowania jakim jest Obj-C?
Żeby zrozumieć ten dziwaczny fakt, trzeba się nieco zagłębić w historię firmy Apple tudzież historię jednego z jego założycieli.

Steve'a Jobs'a.

Jeśli więc interesuje Cię skąd ten pomysł i dlaczego się sprawdza - polecam dalszą część lektury.

Nie będę oszukiwał, że wiedzę tę posiadłem z powietrza. Wspieram się tutaj na informacjach z sieci, jak i materiale jednej z bardziej interesujących książek na temat programowania pod Mac OS X. Zainteresowanych głębszym zbadaniem tematu polecam jej lekturę. Jest to "Cocoa programming for Mac OS X" autorstwa pana Aaron'a Hillegass'a.
Traktuję to raczej jako wiarygodne źródło, ponieważ jest to były pracownik zarówno drużyny NeXT jak i firmy Apple.
Przejdźmy może jednak do konkretów.

Kiedy firma Apple zaczęła rozwijać się w zastraszającym tempie, współwłaściciele w osobach dwóch Steve'ów nie byli już w stanie kontrolować sami tego co w niej się dzieje. Idąc zatem po rozum do głowy zatrudnili z zewnątrz dyrektora - John'a Sculley'a. Doświadczony poprzez poprzednie firmy, ów dyrektor robił wszystko, żeby właściciele nie wtryniali się zbytnio w to w jaki sposób firma funkcjonuje. Wiedział dobrze o tym, że wprowadzi to więcej zamieszania niż pożytku.

Problem polegał na tym, że Steve'owi Jobs'owi podobało się to raczej średnio. Frustracja jego sięgała już zenitu, kiedy postanowił założyć sobie jeszcze jedną firmę, tym razem mniejszą. Firmę znaną początkowo jako NeXT Computers.

Główne cele firmy były dość podobne do celów Apple. Ale ze względu na braki w kadrach (firma miała pozostać mała) jak i wielu innych czynników, o których pisać nie warto, skoncentrowano się na jednym zestawie narzędzi do tworzenia aplikacji GUI. Ów produkt nosił nazwę NeXTSTEP.

Były to zamierzchłe czasy. Obiektowość była czymś nowym. Na język C++ więcej narzekano, niż chwalono. Chyba głównie z tych względów ekipa NeXT nie chciała się zdecydować na ten język. Do tego dochodził problem kompilowania. Nie wszystkie kompilatory do różnych procesorów posiadały możliwość kompilacji kodu C++. To jeszcze bardziej odstraszyło naszych innowatorów. Byli jednak tak zafascynowali ideą obiektowości, że szukali złotego środka. Okazał się nim właśnie język Objective C.

Dlaczego on? Ponieważ stworzono go na podstawie dwóch języków - ANSI C, który miał kompilatory na wszystko i Smalltalk'a - niedoścignionego ideału obiektowości, który jest tak idealny, że nie nadaje się specjalnie do niczego. Twórca - Brad Cox - zwyczajnie wziął język C, dorobił do niego preprocesor radzący sobie jakoś z teorią obiektowości i całość ochrzcił właśnie imieniem Objective-C.

Oczywiście wielu rzeczy nie da się tam zrobić, a znów inne wymagają od programisty wyjątkowej ostrożności. Ja sam, w sumie nie zakodowawszy zbyt wiele, popełniłem już taką masę prostackich błędów, że będę się starał je mocno podkreślać w serii tych artykułów, próbując ustrzec ewentualnych czytelników.

Mimo to język ma w sobie to coś i mimo faktu, że z początku straszliwie go nie lubiałem, teraz z dumą mogę stwierdzić, że z przyjemnością siadam do kodu. Wynika to zapewne z faktu, że większość życia programowałem wyłącznie w C, a C++ zdziebko mnie denerwował. Dla mnie osobiście jest to złoty środek, ale wiem, że możecie mieć w tym względzie inne zdanie. Nie będę próbował się nawet kłócić. Powiem jedynie, że ekipa NeXT też polubiła to rozwiązanie. Co więcej - idąc zupełnie inną drogą niż inni, nie stworzyli API polegającego na implementowaniu setek interface'ów i setki razy dziedzicząc po różnych klasach. Wręcz przeciwnie. Cała biblioteka NeXTSTEP opiera się głównie na dwóch szablonach projektowych. Delegacie i MVC.

Co więcej - takie podejście mnóstwo rzeczy uprościło. Pisanie prostych aplikacji zaczęło zajmować coraz mniej czasu. Pokochali to głównie programiści bankowi, którzy wiecznie pędzili z terminami w absurdalny sposób narzucanymi przez management. Dzięki temu NeXT Computers, które już zdążyło się przechrzcić na NeXT Software, zaczęło zarabiać. I to całkiem nieźle.

W tak zwanym międzyczasie, Apple doszedł do granic swoich możliwości. Postanowił porzucić pomysł, który miał na system wcześniej i stworzyć coś zupełnie nowego, opartego o mikro kernel BSD Mach. Brakowało im jedynie pomysłu na systemy okienkowe. Każdy kolejny projekt okazywał się fiaskiem. Postanowiono więc kupić jakiś z zewnątrz. Firma Steve'a była oczywistym wyborem. A dzięki faktowi, że firma była mała, a Apple duży... po prostu przejęto całość pod skrzydła z jabłuszkiem.

I tak właśnie system NeXTSTEP przechrzcił się na Cocoa. Jak szybko zauważycie, wszystkie klasy zaczynają się od literek NS, co nasuwa szybkie skojarzenie, że nawet nie chciało im się zmienić ich nazw. Mimo to sprawdza się znakomicie, a Mac OS X okazał się wielkim sukcesem.

Problem polega jednak na tym, że mimo prostoty tego języka i łatwości w jego używaniu, mało kto w Europie ma na jego temat jakiekolwiek pojęcie. A sami przecież wiecie, że na maczki softu OpenSource jest jak na lekarstwo.

Dlatego to piszę.

Chcę uruchomić ciekawość polskiego światka OpenSource i namówić, byście razem ze mną pokazali, że Mac OS X też jest wstanie mieć dużo fajnych programów :)

Będziemy poruszali się etapami. Wiele tajników jest i dla mnie jeszcze czarną magią, ale ilekroć przejdę jakiś kolejny próg będę się nim z Wami dzielił. Już dziś - podstawy języka Obj-C a jutro pierwsze kroki w Cocoa.