maandag 1 december 2008

Flex CoCoMo (Flex nieuwe platform voor Even Richer Applications )




17 November 2008, Adobe brengt de bèta versie van CoCoMo uit. Het is een platform waarop je in Flex op een gemakkelijke wijze realtime socialnetwork componenten aan je applicaties toevoegt. Denk aan VOIP (Voice over IP), FileSharing, andere mensen bekijken via hun webcam, chatten en gedeelde whiteboards. Adobe host zelf het platform waardoor deployment, onderhoud en schaalbaarheid geen issues zijn, dit wordt voor je gedaan. Ook aan beveiliging is gedacht, door middel van een unieke gegenereerde key kunnen alleen mensen die de key hebben inloggen op jouw applicaties en er zijn rollen in te stellen voor gebruikers. Er zijn een aantal standaard componenten aanwezig waar je binnen 10 minuten mee aan de slag kunt, natuurlijk zijn al deze componenten uit te breiden naar eigen gebruik. Het principe is heel gemakkelijk, je kunt voor elke toepassing een zogeheten “Room” gebruiken waarin mensen kunnen inloggen en meedoen aan jouw applicatie. In deze “Room” kun je data uitwisselen met de anderen, wat voor data het ook is.
Het klinkt allemaal veelbelovend, laten we hopen dat ze die verwachting waar kunnen maken als het definitieve product uit komt.



Meer informatie:
http://labs.adobe.com/technologies/cocomo/
http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid=72&catid=759&entercat=y
http://download.macromedia.com/pub/labs/cocomo/cocomo_developerguide.pdf


Voorbeeld:
http://blogs.adobe.com/collabmethods/2008/05/_another_cocomo_experiment_the.html

Registreer en download op:
https://cocomo.acrobat.com/

vrijdag 21 november 2008

Taart voor ISAAC

Vandaag kwam totaal onverwacht een fijne verrassing door onze schuifdeuren naar binnen. Een bakker met een romige slagroomtaart! Het Nationaal Spaarfonds was zo tevreden met onze snelle service dat zij ons daarom beloond heeft met deze taart. Thomas mocht hem in ontvangst nemen samen met Ronald en Tom, samen hebben zij (e.a.) een spaarrekening aanvraagformulier verzorgd.

maandag 6 oktober 2008

Het eerste ISAAC tennistoernooi

Wie denkt dat ISAACi niet sportief zijn die heeft het mis. Afgelopen vrijdag was namelijk het eerste ISAAC tennistoernooi, en er waren maar liefs 12 deelnemers! Dit vond allemaal plaats op onze indoor tennisbaan, gelegen in de Wii-hoek. Hier volgt het verslag:

Het was een koele vrijdagmiddag in Eindhoven, toen de 12 deelnemers aan het eerste ISAAC tennis-toernooi zich mentaal voorbereidden op de veldslag die plaats zou gaan vinden. Het begon allemaal in de keuken onder het genot van een hapje en een drankje, maar al gouw kwam er gekreun en gescheld uit de Wii-hoek.


Merijn was de eerste die het onderspit delfde tegen niet-ontslagen Lars, waarna Xander al snel volgde door van Nick te verliezen. Jasper was veel te sterk voor JW, Edwin verbaasde vriend en vijand door van Rob te winnen, Bart had geluk en versloeg Koen, en Ronald versloeg langharige Rob in 3 games.


De tweede ronde bevatte minder verrassingen: Nick versloeg niet-ontslagen Lars in een zenuwslopende wedstrijd, die zelfs een Matchpoint voor niet-ontslagen Lars bevatte. Het was stil bij ISAAC toen Nick de genadeklap toebracht in de derde game... Jasper versloeg Edwin redelijk eenvoudig (Edwin was gehandicapt!) en Bart (in het roze!) versloeg Ronald.


De finalepoule ging tussen de titanen Nick, Bart en Jasper. Nick versloeg in de eerste wedstrijd Jasper in 2 games, maar daarna versloeg Bart Nick in 3 games... het ging dus allemaal om de laatste wedstrijd tussen Jasper en Bart. Als Bart zou winnen was hij de winnaar, maar als Jasper zou winnen dan zou er extra moeten worden gespeeld...


Maar Jasper was meer van de praatjes en verloor in 2 games, waardoor Bart onze eerste Wiisaac tennis-kampioen is! Gefeliciteerd Bart, en hulde!

woensdag 17 september 2008

Walt Disney World: twee toffe web-related systemen

Het zal voor een aantal van de lezers van dit blog geen geheim zijn dat ondergetekende nogal een themaparken-fan is, en dan van de Efteling en Disney in het bijzonder. Afgelopen anderhalve week was het dan ook weer tijd voor mijn inmiddels bijna jaarlijkse bezoek aan Walt Disney World, Florida. WDW (alle freaks zijn te lui om Walt Disney World steeds voluit te schrijven) is ’s werelds meest bezochte toeristische bestemming, meet ruim 100 vierkante kilometer en heeft daarop vier (!!!) Disneyparken, 22 resorts (met elk 2500+ kamers), 62.000 medewerkers, mijlen monorailverbindingen en nog een lading golfbanen, meren, waterparken en wat je al niet meer zou kunnen verzinnen. In totaal komen er meer dan 50 miljoen bezoekers per jaar op af.

Nu is dit natuurlijk het blog van een IT-bedrijf, en niet een timeshare-promopraatje van Disney (hoewel ik dat ook wel naar tevredenheid zou kunnen houden). Daarom wil ik het hier eens hebben over twee relatief nieuwe web-related WDW IT-systemen die ik de afgelopen vakantie heb kunnen gebruiken, en die, zeker gezien hun buitengewone schaalgrote, interessant zijn. Je bent immers niet voor niks IT’er; dan blijf je zoeken naar de techniek achter de grote grijzende Mickey Mouse-facades. De twee systemen die we gaan bekijken zijn “Disney’s PhotoPass” en “Postcard From The Future”. Laten we met die laatste (en qua schaal kleinste) beginnen.

Postcard From The Future
Postcard From The Future is een systeem dat sinds een jaar draait in Epcot, het futuristische toekomst- en culturenpark van Disney. Hét bekendste symbool van Epcot is de geodesische bol (naar een ontwerp van Buckminster Fuller) van 55 meter hoog, waarin de attractie Spaceship Earth is te vinden. Met een Carnaval-Festival achtig transportsysteem rij je in die bol in zo’n vijftien minuten langs scenes die de geschiedenis van de communicatie verbeelden; van prehistorische rotsschilderingen en de uitvinding van het schrift tot de eerste computers en de knutselgarage van Apple CEO Steve Jobs’s ouders aan toe. In 2007 is de sponsoring van deze uit 1982 stammende attractie overgenomen door Siemens, waardoor Disney een update van veertig miljoen dollar kon laten uitvoeren.

Alle honderden wagentjes van het systeem zijn vanaf nu voorzien van een touchscreen, wat vlak na het instappen in Spaceship Earth ook de eerste confrontatie met het “Postcard From The Future”-systeem is. Tijdens de eerste donkere tunnel van de attractie (je moet immers die 55-meter hoge bol in), kies je op dat touchscreen (formaat multimediazuil) één van de zes ondersteunde talen, en je geeft middels een fraai zoombare wereldkaart aan waar je vandaan komt. De taalkeuze heeft meteen ook effect op de in de wagentjes ingebouwde voice-over van de attractie; erg slim gedaan!

Tegen het einde van de donkere tunnel, vlak voor de eerste scène over grotschilderingen, moet je nog even naar een beeldscherm boven de wagentjes kijken; een flits en hop, een foto is gemaakt. Met die foto gaat “Postcard From The Future” aan de slag, zoals later zal blijken.

Tijdens de rit zelf zie je het systeem verder niet terug, tot het punt waar je, na de scènes met de garage van Steve Jobs en een Matrix-achtige sourcde-code projectie, begint aan de tocht terug naar beneden uit de bovenste delen van de hoge Spaceship Earth-bol. In de lange en donkere “descent tunnel” (waarin je relaxed half achterover in je wagentje ligt), floepen de touchcreens weer aan, en krijg je een aantal vragen over je ideale toekomst. Hou je meer van werk of vrije tijd? Van private transport of public transport, etc etc. Halverwege de tunnel krijg je op basis van de gemaakte keuzes op je individuele touchscreen een hele toffe en knap gerenderde animatie te zien op basis van je keuzes. Het meest bijzondere hieraan is wel, dat de hoofdjes van de animatifuguren zijn vervangen door de uitgesneden gezichten van jezelf en je medepassagier in het wagentje! De eerder gemaakte foto is dus door een stukje gezichtsherkenninssoftware gehaald, waarbij de gezichten netjes losgesneden zijn van de achtergrond. Daarmee is vervolgens een (waarschijnlijk) Flash-achtige animatie gerenderd. Het ziet er een beetje South-Park achtig uit natuurlijk, doordat er maar één standpunt beschikbaar is voor in de animatie, maar dat geeft het ook wel weer een leuke look.

Wanneer je uit de wagentjes stapt, kom je in de futuristische (veel neon en brushed steel) post-show ruimte terecht waar Siemens wat reclame maakt. Middenin staat een enorme verlichte wereldbol (meter of zes hoog), waarop in de oceanen de foto’s tevoorschijn komen van hen die net uit de attractie stappen. Hierop zie je dus ook wel jezelf, en met een boogje vliegt je foto dan naar de plaats waar je vandaan komt (die had je immers eerder ook opgegeven in de wagentjes). Op die plek blijft ook een klein wit stipje achter. Ik denk dat de wereldbol zich ’s ochtends reset, want er stonden pas een stuk of wat stipjes op noordwest Europa.

Rondom de wereldbol zijn zo’n tien fraai vormgegeven “zuilen” te vinden, met daarop een applicatie waarmee je een kaartje “vanuit de toekomst” (oftewel Epcot) naar huis kunt sturen. Wanneer je voor zo’n zuil gaat staan, zoekt het systeem met behulp van een camera en gezichtherkenning weer naar de juiste foto die in de rit gemaakt is. Dit werkt voor zo’n 90% vlekkeloos. De overige 10% moet even bladeren in een index. Met de applicatie op de zuil kun je het door “Postcard From The Future” gemaakte filmpje sturen naar een paar e-mail adressen naar keuze. Deze ontvangen een link naar de flash-animatie online. Zodra je je kaart verzonden hebt, komt een ansichtkaart-achtig frame uit die animatie ook weer op één van de grote projectieschermen in de post-show ruimte te staan. Deze wisselen dus naarmate bezoekers “Postcards From The Future” verzenden. Fancy!

Al met al een behoorlijk groot systeem; elk wagentje (ik schat dat er zo’n 250 zijn) heeft twee eigen touchscreens, en een individueel lokaal verwerkingssysteem. Vervolgens is er software (op servers neem ik aan) die de animaties rendert en de gezichtsherkenning uitvoert. We hebben de wereldbol met de locatieweergave. En dan zijn er ook nog de e-mail consoles (met overigens een hele mooie Flash-interface vol in en uitschuivende panelen en een on-screen keboard voor de e-mail input), die de animaties klaarzetten op een webserver. En dat voor 2500 bezoekers per uur!

Disney’s Photopass
Het tweede systeem waarvan ik onder de indruk was is “Disney’s Photopass”. In tegenstelling tot “Postcard From The Future” is dit niet beperkt tot één attractie, maar is het in alle parken van Walt Disney World in Florida en Disneyland in California actief (als één globaal systeem).

PhotoPass heeft als belangrijkste doel het opslaan, samenvoegen en online beschikbaar maken van de tientallen foto’s die Disney tijdens een bezoek aan het resort van je groep (party) of familie kan maken. In alle parken van WDW zijn Disney-fotograven te vinden die je op de foto kunnen zetten met het Disney-kasteel, een Disney-figuur (de zogenaamde “characters”, om even in Disney-jargon te blijven), een fraai stukje Disney-natuur of whatever-else Disney. Natuurlijk kun je al die foto’s ook gewoon door een aardige medebezoeker laten maken, maar dat is niet hoe Disney z’n dollars wil verdienen, en —gelukkig voor Mickey’s wallet— ook niet wat de meeste Amerikanen doen.

In totaal lopen er zeker op honderd plaatsen in de parken fotograven rond. Wanneer je voor het eerst op de foto gaat bij één van hen krijg je een plastic pasje van het PhotoPass systeem, met daarop een 16-digit (unieke) code (alfanumeriek) en een 2-dimensionale barcode. De PhotoPass-fotograaf scant die barcode met een klein extra dingetje aan zijn camera, waardoor de foto een unieke link krijgt met je PhotoPass ID. Om de paar minuten lopen ze even “backstage”, om daar hun memory card te legen op het Disney PhotoPass-netwerk, waardoor de (high res) foto’s altijd snel in het systeem beschikbaar zijn. Natuurlijk gebruiken Mickey, Pluto, Goofy en Peter Pan die tijd ook om (zonder hun warme pak) even bij te komen onder de airco. Bij een volgende fotograaf geef je gewoon weer even je PhotoPass, deze scant de barcode, et voila: weer een foto in je virtuele PhotoPass-album.

Een geavanceerder stukje van het PhotoPass-systeem zie je bij de zogenaamde “on ride”-foto’s. Dat zijn foto’s die tijdens een rit in een attractie door een automatische camera worden gemaakt, bijvoorbeeld in een achtbaan of waterattracties. We kennen ze hier in Nederland wel van de Python of het Carnaval Festival in de Efteling. Bij de Efteling staan bij de uitgang van de attractie wat monitoren waarop je de gemaakte foto kunt zien, en die bij een bemande balie ook meteen kunt laten afdrukken. In WDW hangen die monitoren er ook, maar eronder is een mooi PhotoPass barcode-scannertje geplaatst. Als je de tijdens de rit gemaakte foto tof vindt, scan je gewoon even je PhotoPass, en ook deze foto staat voortaan in je album.

Op verschillende plaatsen in het resort (en ook in de lobby van elk hotel) zijn PhotoPass Access Points te vinden, waar je door je pasje te scannen al je foto’s kunt bekijken, en, indien gewenst, meteen kunt laten afdrukken. Het staat daar natuurlijk vol met medewerkers die om het hardst roepen hoe tof en bijzonder je foto’s wel niet zijn, zodat je maximaal gaat investeren in prints. Deze PhotoPass Points kunnen ook de foto’s van meedere PhotoPasses combineren tot één album (twee pasjes scannen en klaar), of er wat eenvoudige bewerkingen op doen (leuk randje om de foto, jaartal erbij, handtekening van een Disney-figuur uit de database erop, etc etc). Allemaal via een toffe Flash-achtige user interface.

Natuurlijk kun je je PhotoPass-album ook online bekijken. Op een speciale website kun je inloggen met je PhotoPass ID, waarna alle foto’s mooi op park en datum gesorteerd inzichtelijk te maken zijn. Wil je je foto’s aan anderen laten zien? Geen probleem: er is een “Share With Friends” optie, waarmee je het album ook voor vrienden inzichtelijk kunt maken via een ge-emailde link. Natuurlijk heeft Disney daarvoor wel weer een naam en e-mail nodig, waardoor hun spam-emaillijst groeit als kool.

Als Disney eenmaal weet welk e-mail adres bij een PhotoPass ID hoort, gebruiken ze dat ook volop om je te blijven herinneren aan die toffe foto’s die je nog in je album hebt staan, en die schreeuwen om een print. Online even aanvinken welke je hebben wilt, de foto’s weer bewerken met wat fraaie edit-tools (allemaal in-browser), en je krijgt ze de zelfde week nog thuis gezonden. Als canvasschilderij, als sleutelhanger of als horloge-achtergrond wellicht? Ook geen probleem. Je krijgt alleen nooit zomaar toegang tot de high-res bronbestanden van de foto’s. Die houdt Disney —heel slim— zelf. Tenzij je de hele boel op een Kodak PhotoCD thuis laat sturen, maar dat kost je meer dan 100 dollar.

Als software-ontwikkelaar ben ik vooral erg onder de indruk van de omvang van het systeem. Honderden high-res foto’s per minuut moet dat systeem verwerken, die allemaal minimaal een maand behouden blijven op de Disney-servers. Ook de bewerkingsopties op de website zijn heel erg handig, snel en mooi ontwikkeld. Commercieel is het natuurlijk weer een typische Disney meesterzet. Je hoeft immers niet meer steeds snel in een park te beslissen of je een foto hebben wilt of niet, maar kunt dat rustig thuis —met de hotel en entreerekening al weer vergeten— doen. En dat is de money-making magic van Disney.

woensdag 3 september 2008

g Cr


Incase you don't know what the above means, it's simple, first of all is the symbol for Googol (or was it Googolplex? I always mix them up), and the second for Chromium. Combing them together with some missspelling results in something now known as Google Chrome.


This is a new browser, by Google, that is ought to take away the "pain" in webbrowsing. While I can't say everything about it, having used it for a mere 30 minutes, I can tell you my first impressions of this "beast".

But first of all, let us explain why I am not writing this in Dutch, even tough it's my native language. 1. It's late. 2. I'm lazy. 3. Context Language "switching" is expensive for me. And I may do a Dutch translation if there is enough demand. A later post may include a Dutch translation by default.

Anyway, back to Google Chrome! Before anyone can complain, these are my, and my alone, first impressions. So don't bother complaining. You know who I'm refering to. ;-)

  1. For a supposedly new and innovative browser, it looks and feels remarkably like Opera, I haven't yet found a feature that isn't in Opera. With the possible exception of the multiple processes (see later) and the App mode. But the latter is a counterpart to Opera's Widget system. I suppos OmniWeb will feel similar as well, for Mac users (from what I've heard). Look and Feel also looks a lot like Opera.
  2. It's, for now, XP/Vista only.
  3. Installation was painless, just run the exe you download and say if you want to place a shortcut on the desktop/quicklaunch and if you want to import from IE or FireFox (strangely enough not Opera nor Safari), which you can't cancle after you accidently make a mistake (so I started with the RunMeFirst of IE as my homepage). One thing to note, it will plant itself into the the Local AppData of the running User (in Vista), no way to define something else. In XP this will be a similar place (ApplicationData for example).
  4. The only "innovative" feature I could find was the 1 process per tab idea. I currently have eight tabs open, with a total of ten chrome processes. So one master monitoring process, one for the actual browser "chrome" (to use a FireFox term, it's the GUI around the actual web content), which, if the rumors are right is also a webpage. And one for each tab. So I guess the actual browser window is a webpage. Thread-wise the master process currently uses 27 threads, maybe a bit excessive, not sure. Each browser window 5 threads and roughly half the memory, even less for workingset memory. Each tab process has 2 threads. I think one for the JavaScript, and one for the, required, Windows Message Pump (it's a Win32 API thing). Or maybe for the rendering, if that's done my the tab process itself. Memory-wise it's similar to a window process, basicly confirming (yeah, not very scientific, I know) that a window is a webpage.
  5. Scroll is too fast.
  6. The Mozilla Prism/Adobe Air/MS Silverlight/Opera Widget part consists of placing a shortcut in either QuickLaunch or the Desktop telling the Chrome application to start with an url, the exact url from where you chose to create an app out of a webpage. Apps open in a new window. But share the infrastructure of the other Chrome apps (which means it will launch the master Chrome app if it's not yet present). If you open a page/tab in the new App window it will open a new tab in the last used window, that is not an App window. It also means it will start 2 new processes under the Chrome master process, which makes sense because a window is a webpage and the actual app is also a webpage.
  7. It does not yet pass the Acid3 test (63%), even tough the nighlies of WebKit (which is the render engine used in Safari and most of the webbrowser-like applications found on the Mac, and on other platforms) already do for some time, and I believe the latest beta of Safari does this as well. Acid2 test also isn't yet pixel perfect (like it is on Opera ^_^), just like Safari. So I think they are currently using the WebKit (or a near) version to the one used in the latest stable Safari release.

That's it for now!
I'll might do a more indepth (and comparison with other browsers) article in the future.

--Maarten

PS.

Written from within g Cr!

PPS.

Next morning now, and I think I forgot to mention something last night. I put quotes around the word "innovative" in point 4, why did I imply sarcasm there? Well, a little language has been known to casually support tens of thousands of processes at the same time. What is the difference? Well, those processes are lightweight and use the shared nothing approach to concurrency. In fact, most processes/threads in Erlang are so called "green threads" or "fibers". In Chrome, they are spinning up real, heavy, processes. One for each tab.

But I have to admit, it is very Google in mentality (the spinning up of processes), Google's famous "MapReduce" is infact implemented to spinning up processes that do part of the job, actually they spin up entire machines for this!

maandag 1 september 2008

Hug a developer today...

donderdag 17 juli 2008

Star Trekavond en Pizzarecord


Na de drukte rond de verhuizing (met saaie zaken als tafels en bureaustoelen plaatsen), zijn we langzaamaan eindelijk weer toe aan het komen aan de essentiële zaken van het ISAAC-bestaan. Eén daarvan is het houden van de inmiddels "Befaamde Ende Traditionele" Star Trekavonden.

De benodigde beamer en het projectiescherm zijn vorige week al opgehangen in de Wii en Star Trekhoek, en hoewel we het nog zonder Dolby 5.1 geluid moeten doen, konden we gisteravond wel voor het eerst in het nieuwe kantoor genieten van Deep Space 9 en The Next Generation. Kortom: ISAAC Star Trekavond nummer II!

Tijdens de vorige Star Trekavond kregen we het voor elkaar om een New York Pizzabestelling te hebben van meer dan 80 euro, maar die paste nog wel nèt in één scooterbox van de bezorgpuber (met wat nadelige pleteffecten als gevolg). Dat moest natuurlijk dit keer overtroffen worden! Met wat zachte dwang besloot iedereen dit keer dan ook om rijkelijk side-dishes te bestellen; met daarbij ook een groter aantal Star Trekkijkers, kwamen we uit op een totaalbestelling van 126 euro! Daarmee was ook het expliciete doel van deze bestelling bereikt, namelijk om niet één, maar twee bezorgpubers-op-scooter tegelijk onze bestelling te laten bezorgen! Whoahahaa! Volgens mij moeten we intussen toch wel een key-account zijn bij NYP.

Op het programma stonden wat fijne Dominion en Cardassian afleveringen van Deep Space 9, met daarna de klassieke dubbelaflevering Decent uit The Next Generation. Dat is die episode waarin prof. Steven Hawking zelf ook nog even een cameo rolletje heeft.

Enfin, het was natuurlijk weer een groots succes, maar de doelstelling voor de volgende keer is een pittige. Want hoeveel pizza's moeten we wel niet bestellen om (in goede IT-traditie), van 2 naar 4 bezorgpubers te komen bij Star Trek Night III?

Live long and prosper!

woensdag 18 juni 2008

Het is me in de (aard)bol geslagen


“In mathematics, you don't understand things, you get used to them.” von Neumann

En met dat in gedachte zal ik toch proberen om een verhelderend stuk te schrijven over dit favoriete vak van menig programmeur. Waar heb ik dat aan te danken, hoor ik je denken en ergens heb je gelijk. Waarom zou ik je lastig vallen met een onderwerp waar je vroeger al slecht in was en wat je sinds het behalen van je diploma waarschijnlijk achteraan in je hersenen hebt geduwd (nog achter die genante herinneringen van toen je veertien was en je je geluk waagde bij het mooiste meisje van de klas). Hiervoor verwijs ik je naar Google in Mountain View, Californië. Die bedachten enkele jaren geleden dat het grappig zou zijn om een virtuele aarde te maken met aaneengeregen foto’s. Google Earth is in een korte tijd uitgegroeid tot een begrip en steeds vaker word je geconfronteerd met opdrachten waarbij locatiegegevens en kaarten een rol spelen. Het is een kwestie van tijd voordat je oog in oog komt te staan met de opgave om de afstand tussen twee coördinaten te berekenen en erachter komt dat deze coördinaten (uitgedrukt in lengtegraden en breedtegraden) niet altijd even ver van elkaar af staan. Met alleen de stelling van Pythagoras, die je ooit uit je hoofd hebt geknald omdat je wiskunde docent je wist te vertellen dat je hiermee alles kon uitrekenen, kom je letterlijk en figuurlijk nergens. Wat jij nodig hebt is een stevige dosis haversinus.

De haversinus formule kun je gebruiken om de afstand tussen twee coördinaten te berekenen en wel op de volgende manier:


  • Je neemt de radius van de aarde (R), 6371 km

  • Je neemt het verschil tussen de twee breedtegraden (∆b = b1 – b2)

  • Je neemt het verschil tussen de twee lengtegraden (∆l = l1 – l2)

  • En dan gooi je die in de onderstaande formule:

    afstand = R * (2 * atan2(√(sin2(∆b/2) + cos (b1) * cos(b2) * sin2(∆l/2) ), √(1-a)))


Ho ho ho, even een stapje terug, wat was die laatste? Laat me het uitdrukken in Java code, dat begrijp je vast beter.


public double calculateDistance(double long1, double long2, double lat1, double lat2) {
Integer r = new Integer(6371);
Double deltaLong = Math.toRadians(long1 - long2);
Double deltaLat = Math.toRadians(lat1 - lat2);
Double x = Math.sin(deltaLat/2) * Math.sin(deltaLat/2) + Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * Math.sin(deltaLong/2) * Math.sin(deltaLong/2);
Double y = 2 * Math.atan2(Math.sqrt(x), Math.sqrt(1-x));
Double z = r * y;
return z;
}

Ok, laten we het er maar op houden dat je in wiskunde niks begrijpt, maar er aan went.

dinsdag 17 juni 2008

Mozilla 3 Merge conflict


Mozilla heeft met Firefox 3 een behoorlijke verbetering geleverd op de vorige versie, minder geheugengebruik en snellere opstarttijden lossen het grootste probleem van de browser op. Maar dat neemt niet weg dat we niet nog een schop onder de gordel kunnen geven in de richting van Mozilla. Neem een kijkje naar de afbeelding, dit is de site zoals die live stond op de releasedag van Mozilla FireFox 3. Het ziet er naar uit dat er een SVN/CSV merge conflict door het net is geglipt.

maandag 9 juni 2008

Een webservice in 5 minuten


EJB 3.0 en webservice annotations maken het mogelijk om webservices te maken, zonder alle details te kennen van WSDL of binding of wat dan ook. Sterker nog, je kunt in enkele minuten een webservice maken. Het enige dat je nodig hebt is een interface klasse, een implementatie klasse en een paar annotations. Laten we dit eens van dichtbij bekijken met het aloude “Hello World” voorbeeld. Maak een EJB 3.0 project en maak daarin allereerst de interface klasse.

package nl.isaac.ejb.service;

import java.rmi.Remote;

import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style = Style.DOCUMENT)
public interface HelloWorld extends Remote {
String hello(String name);
}

Hierin zie je twee annotations staan. De eerste “@WebService” geeft simpelweg aan dat het om een webservice gaat. De tweede geeft aan welk soort SOAP binding je gebruikt, hierin heb je twee smaken “RPC” en “Document”. In het voorbeeld gebruik ik “Document”, maar in dit geval maakt het niet uit om hier “RPC” van te maken (Het verschil tussen document en RPC is grofweg gezegd dat RPC maar een enkel element als resultaat geeft en document een uitgebreid XML document terug kan geven). In de interface klasse staat verder alleen onze methode gedefinieerd. Let er wel op dat de interface jave.rmi.Remote extend. Nu kunnen we onze implementatie klasse maken.

package nl.isaac.ejb.service;

import javax.ejb.Stateless;
import javax.jws.WebService;

@Stateless
@WebService(endpointInterface = "nl.isaac.ejb.service.HelloWorld")
public class HelloWorldImpl {
public String hello(String name) {
return "Hello " + name;
}
}

Let erop dat, ondanks dat dit de implementatie klasse van een interface is, je deze niet implementeert met de code “implements HelloWorld”. Dit gebeurt in de annotation @WebService, die in deze methode zijn endpoint interface instelt. Deze verwijst naar de interface klasse die we zojuist gemaakt hebben. Onze methode wordt geïmplementeerd en voilá, een webservice is geboren. Deploy je project in JBoss en controleer voordat je een client maakt of je service draait door de WSDL file aan te roepen. Dit kun je doen door de URL van je project in IE in te voeren met daarachter “/HelloWorldImpl?wsdl”, dit zou je een XML document moeten tonen met alle details over de webservice.