CEnhet

Jag ville använda unit-tester till ett Cocoa-projekt.

Dum som jag är så gjorde jag ett nytt försök med OCUnit, vilket jag skrivit om tidigare. Jag vet inte varför jag ens brydde mig. Det suger inte bara för att Steve Jobs har bestämt att man ska använda det på ett idiotiskt sätt, utan även för att det saknar dokumentation, saknar ett uppenbart sätt att köra sina unit-tester programmatiskt och presenterar sina resultat på ett dåligt sätt.

Nästa steg var att testa med Google C++ Testing Framework, som vi kör på jobbet. Det funkar ganska exakt som man vill att det ska göra, letar automatiskt upp ens testfall, kör dem och ger vettig output. Google Test är dock C++, och även om det går bra att blanda C och C++ så ska man tydligen inte försöka blanda C, C++ och Objective-C. Nitlott igen.

Samtidigt som Björn Skifs och Arne Hegerfors hoppade fram och vrålade "TREDJE GÅNGEN GILLT" i örat på mig (det piper fortfarande), så drog jag ner CUnit. Jag säger som Neal: "Aaaaah..." Det är lite mer jobb än med Google Test, eftersom C inte har RTTI, så man får snällt registrera sina testfall, men det som är trevligt med CUnit är att det går att använda på ett vettigt sätt. Och med lite snabbt hopkokad hjälpkod så är den extra ansträngningen för att registrera testsviter och testfall minimal.

CUnit får 3 sälar på den grönländska betygsskalan.

Ska de va så svårt då?

Vad är svårt när man försöker lära sig Cocoa?

Objective-C: 19%

Om det är ett ganska klassiskt objekt-orienterat språk som är det värsta med att lära sig Cocoa så låter det som beröm till Apple. Beroende från vilket håll man kommer ifrån så är det olika saker man tycker är krångligt med Objective C.

I Didn't Know ANSI C: 12%

Det kan låta som science fiction för vissa av oss: någon gång i framtiden, t.ex. 1984, så finns det folk som programmerar men inte kan det etablerade standardspråket C. Men nu för tiden får man inte ens lära sig det när man pluggar datavetenskap. Tydligen är det alldeles för nischat att syssla med sådana lågnivågrejer nu för tiden, trots de ganska uppenbara pedagogiska fördelarna med att utgå från hur hårdvaran ser ut. Det är en sådan där sak som det är svårt att få in i huvudet utan att skriva kod.

Cocoa is Really Big: 11%

Översatt till svenska: jag är för inkörd på ett specifikt ramverk. Vet man ungefär vad som brukar finnas och hur det brukar se ut så är ett klassiskt designat system som Cocoa väldigt lätt att hitta i. Sen finns det naturligtvis en massa detaljer som är oklara, men sådant har en förmåga att släppa ganska fort. Åtminstone inom ett par år, vilket är ungefär vad som behövs för att lära sig en programmeringsmiljö ordentligt.

Memory Management: 10%

Låter som en underkategori till Objective C och I didn't know ANSI C. Minneshantering är ofta klurigt när man ska lära sig ett nytt språk som är mer eller mindre högnivå än vad man är van vid. Själv trodde jag att jag skulle göra det lättare för mig genom att slå på garbage collection. Det gav mig istället kluriga problem när jag skulle blanda ihop vanlig C-kod och Objective C.

Interface Builder and NIBs/XIBs: 10%

Ja, det är en del magi som pågår här. Det blir mindre kod att skriva, men saker blir inte mer nybörjarvänliga för att man flyttar ut dem till ett grafiskt verktyg. Det är snarare så att det är mer kryptiskt i början, innan man har lärt sig hur det verkligen funkar under ytan. Personligen har jag mycket lättare att förstå Glade, där det bara finns callbacks. Men om man sätter sig in i data bindings så kan jobba mer effektivt med Interface Builder, istället för att koda sina observers själv.

I Was Used to Java or C++: 10%

Ännu en språkkategori.

Delegates: 8%

Nu ser jag ut som ett frågetecken. Kanske är det dokumentationen, kanske är det att de som har valt det här alternativet helt enkelt röker för mycket hasch, eller så är det jag som är för 1337. Delegates är ett ganska grundläggande koncept, så om man har svårt att förstå det så har man nog helt enkelt programmerat för lite.

Overall Cocoa Model: 8%

Javisst, det är det här som det tar tid att lära sig. Och kanske är ovanstående punkt helt enkelt ett specialfall av den här. Man kan lära sig att göra grejer ganska snabbt, men att förstå hur man ska göra dem på bästa sätt tar en massa tid.

I Didn't Know Object-Oriented Programming: 8%

Samma som ovanstående punkt: det tar tid att lära sig en ny typ av språk. Det är som Othello: det tar en minut att lära sig reglerna (eller kanske en vecka) och en livstid att bemästra (eller kanske ett par år).

Learning How Documentation is Structured: 5%

Jag vet inte om det är strukturen på dokumentationen som är problemet. Den är helt enkelt dåligt strukturerad. Det finns en väldig massa dokumentation, men jag har inte hittat något vettigt sätt att navigera i den, bortsett från att skriva saker i sökrutan. API-referensen är för kortfattad och guiderna är alldeles för pratiga. Ungefär som det brukar vara alltså.

Cocoa Bindings: 5%

Ett specialfall av Overall Cocoa model och/eller Interface Builder.

Xcode: 3%

Det här handlar mer om frustration. Det är rätt okej som IDE, men på många sätt har den bit kvar till Visual Studio, Eclipse och t.o.m. Codewarrior. Framför allt gäller det debuggern och det knepiga fönsterhanteringssystemet.

Good news, everyone!

Jag har börjat experiment-twittra. På engelska. Blaj är ju vad jag gör bäst, så varför inte? Jag har fortfarande inte fattat poängen, men jag kanske gör det snart. Och så försöker jag bevisa för mig själv att jag inte är för gammal för att lära mig något nytt.

Jag har installerat lftp och laddat upp version 0.2 av Lister. Detta har hänt:

- Fönstret är inte ett fönster längre, utan en verktygspanel, vilket gör att det håller sig överst hela tiden. Tack Olof!
- Tabellen i fönstret som inte är ett fönster längre ändrar storlek automatiskt ("automagiskt" - Monika Danielsson anm.) när fönstret som inte är ett fönster längre ändrar storlek när användaren som kanske är en invandrare drar i det. Tack igen Olof!
- Om assistive devices (hjälpenheter?) inte är påslaget när man slår på Lister så slår Lister på System Preferences (systeminställningar?) och ber en slå på assistive devices. Tyvärr slås System Preferences på även om man redan har slagit på assistive devices, så till nästa version har jag tänkt slå på en fix som fixar det. "Fixelifix", som min företrädare på mitt förra jobb skulle ha skrivit i inchecknings-kommentaren.
- Avgjorde ikon-tävlingen, utsåg mig själv till vinnare och la in en ikon föreställande mig själv i en cool pose, så att användaren som kanske är en invandrare aldrig glömmer tacka gudarna för att jag finns till. Tack alla som ställde upp och skickade in fina ikoner!


(Bilden är konverterad och putsad av Hollowman, och är klippt från ett demo som heter LCP Memories, där jag har sällskap av sådana legender som Macx, Booger och Maktone. Freshness!)

Om man inte tycker om ikonen så kan man fixa det genom att lägga in en bild på sig själv istället. I en cool pose. Typ med en klubba i munnen och med höger långfinger utsträckt i sin fulla prakt. Bara ett litet tips. Tipselitips!

woes of the n00b

så jag tänkte att jag skulle fixa klart en 0.2 av lister men det går inte så bra för jag vet inte hur man kan få tableviewen av ändra storlek när man ändrar storlek på fönstret det borde gå automatiskt i och med att autoresizes subviews är ikryssat överallt i buildern men det kanske inte alls betyder vad det låter som att det skulle betyda och eventuellt måste jag hålla på och ta hand om delegerade saker någonstans ifrån men det borde bara funka automatiskt jag har säkert gjort något idiotiskt n00b-fel men det finns inget sätt att få reda på det och inte ens google verkar ha något att komma med så det är lite jobbigt i övrigt har det inte hänt så mycket med programmet jag är ganska nöjd med det så när jag har fixat lite mera smågrejer så kommer det kanske snart en version 1.0 och stor internationell lansering med tårta och fyrverkerier vi får se

sen en liten reflektion över det här med klassiska ui-toolkits som cocoa det blir väldigt stora api:er eftersom man låter ett lager i api:et ta hand om både kontrollen och det visuella vilket gör att api:ets storlek exploderar och man får tusentals kontroller eftersom en kontroll inte bara måste ta hand om kontrollen utan dessutom måste klara av att se ut på olika sätt vilket en typisk kontroll inte klarar så man får göra en ny kontroll om man vill att den ska se lite annorlunda ut mwc for the win yo och om man applicerar det på viewen så inser man att ui-toolkit inte är en view utan en kombination av control och view

nu är jag lite trött på att skriva oläsbar skit så nu ska jag posta det här

Linus - Xcode 1 - 0

Xcode är svårjobbat av en anledning: det envisas med att öppna varje källkodsfil i ett eget fönster. (Det finns sätt att ha flera filer i ett fönster och växla mellan dem, men inte på något vettigt sätt.) Om man har ett projekt med ett par tusen källkodsfiler och en djup katalogstruktur så funkar det inte att växla mellan filer genom att klicka på dem i projektvyn, och Exposé hjälper inte när man har 30 öppna fönster med vit bakgrund och svart text.

Kommer man från Visual Studio så kanske man tror att tabbar för källkodsfiler är en bra idé. Det är det, om man inte har flera än 8-10 stycken öppna, i så fall duger inte det heller. Det jag vill ha är en vertikal lista, sorterad i bokstavsordning, eftersom det skalar bättre.

Så jag gav mig på att skriva ett program som listar Xcodes öppna fönster, visar dem i en lista som hålls uppdaterad när man öppnar och stänger fönster, och där man kan visa ett fönster överst genom att klicka på dess namn i listan. Det var lite knepigare än vad jag hade trott, inte minst för att jag inte kan varken Objective-C, Cocoa eller Interface Builder. Men det gick att få till i alla fall, även om det är ett antal grejer i implementationen som är rätt märkliga. Såhär kan det se ut:



Vill man testa så finns källkoden här: http://www.puterman.se/lister-0.1.zip

För att få det att funka så måste man slå på möjligheten att pilla på programs UI:n utifrån, vilket man gör genom att gå in i System Preferences, till Universal Access och där kryssa i Enable access for assistive devices. Jag har inte en aning om varför det inte är påslaget som default, men så är det.

Saker som återstår att fixa:

• Inställningar, t.ex. kanske man vill använda det här med andra program än Xcode.
  
• Pollnings-intervall, det är just nu hårdkodat till 5 sekunder, d.v.s. det är så ofta fönsterlistan uppdateras. Det bästa vore givetvis om man kunde sätta en observer på appen man vill bevaka, men det är jag osäker på om det går.
  
• Sökning i listan via textfält, så att man kan börja skriva namnet på fönstret man är ute efter.
  
• Hitta på lite mindre märkliga lösningar i koden. Det borde gå att göra utan att embedda AppleScript, plocka events från listan via shouldSelectRow etc.
  

Men för tillfället är jag hyfsat nöjd. Nu ska jag ut i solen.