2009 ...

januari (9) februari (8) maart (9) april (9) mei (6) juni (9) juli (8) augustus (10) september (6) oktober (3) november (11) december (1)

NetFlix' New Instant Viewer

2009-03-02 16:52  i1667     [permalink]

ha!

http://slashdot.org/article.pl?sid=09/03/01/2120224

Sounds like New Coke all over again

→

Lua

2009-03-09 23:48  i1677    [permalink]

Kende ik niet. Heeft roots in Brazilië, vandaar de Portugese naam. (via http://nl.wikipedia.org/wiki/Freeciv)

http://www.lua.org/

→

Fast (fast!) battery charger on it's way?

2009-03-12 14:20  i1679    [permalink]

Hilarisch! Het is toch goed om te blijven rondkijken. Neem nu dit:
Reuters: RPT-US engineers find way to build a better battery
Dit lijkt wel klaar om zo op simple.wikipedia.org te belanden, maar dit:
The Register: Superfast-charging batteries? Whoa there, MIT
geeft er direct de nodige plaatsing en draai aan zodat je wel nog veel beter weet waar het over gaat. En dan dit, lachen:

The power level involved would be similar to an oven: even if it somehow could be made to work without melting the phone, special domestic wiring would probably be required and the charger would be large and expensive.

Ik las bijna explosive.

→

The difference between a Netbook and an ultrathin...

2009-03-16 12:52  i1682    [permalink]

ha! de grapjassen!
http://www.theregister.co.uk/2009/03/13/miniature_computer_field_guide/

→

WikiLocal+WikiEngine+SVN+xxm: comittable wiki!

2009-03-16 23:40  i1684    [permalink]

Aah, vandaag is het eindelijk allemaal tesamen gekomen:

http://xxm.svn.sourceforge.net/viewvc/xxm/trunk/Delphi/demo2/svnwiki/

Ik wou al lang (al lang!) een oplossing om een wiki mee in SubVersion te stoppen, dus moest het in files. Het is een van de begin-redenen om aan WikiEngine te beginnen. Al was het dat ik PmWiki's syntax wou overnemen om gemakkelijk bestaande data te kunnen gebruiken/importeren.

Voordelen daarvan zijn:
- de wijzigingen kunnen in verschillende files/pagina's tesamen worden gecommit,
- de history zit kant en klaar in de svn history
- de wijzigingen/toevoegingen aan de documentatie kunnen direct tesamen met de wijzigingen/toevoegingen aan de source-code (en dus de functionaliteit) worden gecommit

Alleen hoe maak je het wat gemakkelijker om niet direct voor iedere working folder en/of branch een website te moeten opzetten naar de wiki? (Hou die URL's dan maar eens bij!) Dus is WikiLocal ontstaan, opnieuw met wat invloeden van PmWiki zoals groups en de side-bar, en toch met wat me opvallend afwezig leek in PmWiki: (snelle, bruikbare) backlinks!

Maar toch, voor bepaalde doeleinden (zoals de trunk of de release branch) is het nodig om een website te hebben om de content in de wiki te publiceren. En daar komt [[xxm]] van pas! Met WikiEngine.dll kan je de wiki-data omzetten naar HTML, en via doodgewone HTTP-GET calls kan je aan de HEAD revision van de wiki-data-files.

(Nu nog ergens vinden waar ik goedkoop xxm kan hosten...)

→

AutoClick

2009-03-17 23:06  r1303    [permalink]

→ AutoClick

→

Moscow, Belgium

2009-03-22 21:33  i1693    [permalink]

Mo! Wasiennekikier tussen al de andere staan!:
http://www.apple.com/trailers/independent/moscowbelgium/

"Barbara Sarafian delivers a Oscar-caliber performance." Jadadde!

→

Large attachments? Share your files with this website! Hype Hype!

2009-03-24 22:13  i1696     [permalink]

http://www.google.be/search?q=share+files

Ik vind dit een uiterst gevaarlijke evolutie. Ik word er ongemakkelijk van. Het zijn zo van die dingen waar je eigenlijk wel van snapt dat mensen er in lopen. Misschien een beetje zoals pyramidespelen en van die mails van verre familie van omvergeworpen Afrikaanse dictators.

Bij officiële dingen kan je nog de kleine lettertjes lezen, maar bij deze dingen is een soort 'technisch gezond verstand' nodig om je te waarschuwen dat er iets niet deugd. En jammer genoeg zijn de argumenten-voor alleen te ontkrachten met technische details waar gemiddelde mensen niet (meer) van wakker liggen.

Om ver uit de buurt te blijven van het plakkerige net van argumenten-voor, hier zijn mijn argumenten-tegen:

De bedoeling van attachments zijn dat er dingen -bij- de mail zitten. Als de mail aankomt, zitten er documenten bij. Als ik dus een mail krijg, wil ik niet nog dingen moeten downloaden van een of andere website. Niet alleen heb ik liever dat ik het net, samen met de mail, heb gedownload, ik heb het ook graag dat ze samen met mijn mail in mijn archief belanden en geindexeerd worden door eventuele zoek-oplossingen. Als ik bestanden op een site staan, heb ik er geen controle over. Als ze dan nog eens beperkt zijn in tijd, dan ben ik ze kwijt in de toekomst. Ik kan ze apart bewaren, maar dan is de koppeling met die e-mail weg. Jammer. Lastig.

Stel je krijgt binnen het bedrijf een mail met een URL waar je de bestanden kan downloaden. Ergens in America. Het downloaden gaat traag, en loopt misschien zelfs vast de eerste keer, wat wel eens gebeurt met grote files. Niet alleen ben ik er een hoop tijd en moeite mee kwijt (je vraagt je al af hoeveel langer het heeft moeten uploaden want kleinere upstream), de grootte van de file is twee keer aan bandbreedte verloren gegaan (op kosten van het bedrijf). Want het had ook op de file-server in de kast kunnen staan (op kosten van het bedrijf).

En natuurlijk, het argument waarmee je iedere niet-techneut verliest: security! Hier speelt het zelfs ook juridisch een rol. Wat moet je bedrijfs-gevoelige data bij een externe organisatie? Privacy Shmivacy! Het had het bedrijfsnetwerk niet mogen verlaten. Meer nog, de data staat op een server ergens (weet je waar?), betaald door iemand (weet je wie?), misschien wel kant en klaar om te misbruiken (weet je hoe?).

De wereld is toe aan een nieuwe e-mail. Jammer dat dat gezever van Sender-ID of zo er bij moet komen, want spam vind ik eigenlijk geen zo'n groot probleem.

→

ISO-3166-1

2009-03-26 08:32  i1698    [permalink]

handige link, moet ik ergens bijhouden:

http://en.wikipedia.org/wiki/List_of_countries_by_continent_(data_file)

→