Kategoria: ohjelmointi (maaliskuu 2007)

Tuli tylsää viime viikonloppuna ja aloin naputtaa vihdoinkin IRC-asiakasohjelmaa S60:lle. Varsinkin kun nyt E61 on niin irkkaus voisi olla ihan ookoo sillä taas. PuTTY ei nappaa ihmeemmin, fontitkin rumia jne.

Joten varmaankin tänään tuossa viimeisten testien jälkeen tulee saataville ensimmäinen 3rd edille tehty IRC-asiakasohjelma. Perustoiminnot löytyy ja lisää tulee joskus. Mutta onpahan tehty.

Ja tulee 2nd edillekin jossain välissä.

Watch this space.

Tuhlasin sittenkin hetken iltaa. Muutamia ongelmia tuossa on, olin huomaavinani että T9-kirjoitus samalla kun kanavalle tulee tekstiä poistaa viimeisimmän sanan (ah ihanaa vakiokontrolleja) ja /clear puuttuu ainakin. Eikä toisten nickinvaihdot näy. Hups O:) Mutta niihin korjaus seuraavaksi heti.

Eli saanko esitellä: mIRGGI

And now there's version 0.3b available, with Windows 1251 codepage support for all my friends in Russia. Also UTF-8 sending, nick/quit messages in right windows etc. Enjoy!

Ihmeiden aika ei ole ohi. Forum Nokian foorumissa kysellään kehittäjiltä mitä API-funkkareita pitäisi höllentää jotta niitä voisi käyttää ilman testausta/devcertiä. Kiva. Toivottavasti oikeasti jotain tehdäänkin.

Itse olen ehdottanut jo useasti ihan uutta lähestymistapaa koko kapoihin, joka laittaisi käyttäjän päättämään eikä testitaloa, joka ei tiedä yhtään mitä softa oikeasti tekee. Tässä kommenttini foorumille.

I have made this suggestion before and will make it again: make most of the caps user grantable runtime.

What I mean is this:

When an application wants to determine the location of the user, it will use Location API. The user is presented a query "Do you allow the SW to find out your location?" and selections: No, This time, Through this SW use, Always.

This way the USER is in control. THEY will decide if they want to allow the SW to get the information.

And naturally this woul be extended to all areas: reading/writing SMS's, contact information, email, network, camera etc etc etc.

Platform security is a good idea, but the security should come fom the user. Not from some third party testing house that doesn't really know what the SW will do after a month, year, 100 executions etc. And this way you wouldn't have hundreds of disgusted developers screaming at you.

This has already been done for JVM's in many phones and it is not a hard thing to implement.

Also another thing: it is stupid that we must declare the caps in the MMP file when compiling. Think about this:

I compile a SW. I want to test it with a devcert in my device but I also want to give it out. I use e.g. Location API. Now I must compile two versions: one that has one set of caps in the MMP, sign it with devcert, then another version that has another set of caps and sign it with another cert.

Since the functions can already have return values that say "no no, you are not allowed to do this", why should we tell the caps in MMP? Just so that the user can be presented with the list in application install? Not if you did it the way I described above.

Also, it's not nice to see the list when installing. The SW can "make calls or use network." So, which is it going to do? I want to allow it to use network, but not make calls naturally. The user is quite unsure at this point. Also other caps are too broad for the user to grasp, this is why more fine separation and runtime querying would be nice.

But if you're only going to relax APIs, I too vote for at least Location and Cell ID queries to be allowed without devcert/symbian signed testing.

Tuli tuossa tarve lähettää ja vastaanottaa dataa asynkronisesti (siis protokolla asynkroninen, itse komentojen ei tarvitsisi olla). Tuli sitten huomattua myös miten ihanaa se on Symbianilla kun kaiken mahdollisen pitää olla asynkkia.

Jos haluaa vuorotellen kirjoitella ja lukea, ongelmia ei tule juurikaan. Tietysti "aktiiviset objektit" ovat ärsyttäviä käyttää muutenkin, mutta mitään lisähankaluutta tästä ei tule. Mutta sitten jos onkin tilanne jossa kumpikin pää voi lähetellä tietoa miten haluaa, joudutaan tekemään paljon monimutkaisemmin.

Koska luku ja kirjoitus ovat molemmat asynkronisia, tarvitsee joka kutsun jälkeen asettaa olio aktiiviseksi ja odottaa viestiä valmistumisesta. Täten kun normaalisti asetetaan soketti lukemaan dataa ja kertomaan kun jotain tulee, on olio koko ajan aktiivinen. Jos samalla yrittää kirjoittaa, se onnistuu, mutta tästä tulee ihan sama eventti ja on aika hankalaa (ellei mahdotonta) erottaa oliko nyt kyseessä luku- vai kirjoituseventti.

Ratkaisu? Tehdään kaksi oliota, joista toinen lukee ja toinen kirjoittaa sokettiin! Oi kun nättiä. Mahdollisesti myös onnistuisi jonkinlainen select-tyyppinen ratkaisu tai monimutkaisesti erotella onko kyseessä luku- vai kirjoituseventti (en heti keksinyt miten tällainen onnistuisi). Mutta kahden olion käyttäminen tuntuu yksinkertaisemmalta, vaikkakin turhan monimutkaiselta.

Lienee sanomattakin selvää että tuli ikävä .NETin BeginReceiveä ja synkronisia kirjoitus- ja lukuoperaatioita :P

Jonkin aikaa jo The Daily WTF -sivustoa seuranneena tuli eteen kyseisen sivuston nimenmuutos. Aika paljon meteliä nousi kun WTF tarkoittaakin nyt Worse Than Failure. Jotkut kritisoivat kovasti: miten jokin voisi olla pahempaa kuin epäonnistuminen? Onneksi sivuston ylläpitäjä kirjoitti artikkelin aiheesta.

Artikkeli on oikein hyvä, kannattaa lukea. Siinä esitetään hyvä kysymys: miksi jokainen softaprojekti on onnistunut, jos softa saadaan ulos? Vaikka softa on täyttä kuraa, suunniteltu päin mäntyä (tai ei suunniteltu ollenkaan), tehty huonosti, sekoilee, vaatii jatkuvaa päivitystä jne, se on silti olevinaan onnistunut ja projekti oli menestyksekäs. Saatiinhan softa sentään ulos!

Hyvä vertaus on talonrakennukseen: jos talo saadaan valmiiksi mutta heti vuoden sisällä katto vuotaa ja perustat homehtuvat, onko se onnistunut projekti? Ei varmasti. Miksi vastaava softa sitten on?

Itse ainakaan en pidä kaikkea tekemääni onnistuneena vaikka valmista on saatu. Sen verran itsekritiikkiä pitää olla, vaikka sitä ei ulospäin kaikille toitottaisikin. Olisihan se itsemurha yrityksille sanoa: "okei, valmista tuli mutta ei tää kyllä ihan sitä ole mitä haluttiin tehdä eikä tää toimi välttämättä ilman korjailuja ja päivityksiä nyt kauaa, mutta..."

Mutta ei nyt silti käsitetä että kaikki tekemäni (tai muidenkaan tekeleet) olisivat moisia, kyllä sitä oikeitakin onnistumisia on. Toivottavasti alalla vain alettaisi vaatia - niin asiakkaiden kuin tekijöidenkin taholta - parempaa laatua. Mutta sitten päästään taas siihen iänikuiseen miettimiseen mitä laatu on jne ad nauseam.

Mutta niskasta kiinni nyt kaikki ja pitämään huoli että softista tulee parempia. Itse ainakin lupaan yrittää entistä enemmän.

(Tämä ajattelumaailma muuten sotii ouppensorsan "release early, release often"-ajattelumallia vastaan hyvin paljon, siellähän ei väliä mitä oikeasti tulee ulos, aina voidaan korjata ja paikata. Ja siinä onkin yksi syy miksi monet eivät pysty luottamaan moisiin systeemeihin.)