1. all your base are belong to us

    The spreadsheet has been the tool of choice for my wife’s small business; pretty much wysiwyg with no real hidden data models or business processes or odd UIs. Just type in the data.

    ahh but the problems with these spreadsheets- multiple machines, not backed up, office vs. openoffice… had them all.

    well, since her business already uses some Google services (gmail, calendar), why not Google Docs & Spreadsheets? Yes this solves issues with backups and multiple copies. What about availability? For her, being online is not a problem (and the Google servers have better uptime then her laptop). As for functionality, the simple equations in her worksheets work as expected.
    But this is all pretty boring for me, until you add in the nice set of APIs available to Google Apps (Google Spreadsheets, Calendar, Gmail, etc.). Now look what your code can do with all that manual entering of information:

    Read entries from a spreadsheet as Atom/RSS feeds for product catalog and pricing info. Sure this is easily Spring configured or in a database, but my wife updates this: putty/linux/SQL or typing in a spreadsheet?

    Placing order information into ”template” worksheets for generating packing lists, invoices, late payment reminders.

    Creating calendar events for invoicing, payment and other CRM issues

    Querying on these events to trigger other business (PDF generation and email is easy manually with Docs & Spreadsheets, not sure if API for this is available).

    Most of these APIs utilize the REST influenced GData API to GET / POST / PUT / DELETE information either publicly or securely via the Google Account Authentication.

    There are client libs for java/net/php etc and even JSON for you script kiddies. So try some programmatic access to your blogger data, local maps or youTube videos… but remember, its free and probably beta !

  2. The most complete list of -XX options for Java 6 JVM

    Om du trodde att du hade koll pĂ„ alla -XX options till Java SE 6 sĂ„ Ă€r det nog bĂ€st att kika pĂ„ Eugene Kuleshov’s ”The most complete list of -XX options for Java 6 JVM”.

  3. Expo-C, dag 2

    Idag var jag och en kollega pÄ Expo-C i Göteborg. Det var en dag som mixade intressanta diskussioner och insikter. Dagens talare var av blandad hÀrkomst och Älder vilket belyser tvÄ saker

    • Det tar tid att bemĂ€stra utveckling
    • Tid != Ă„lder, det handlar om att andas utveckling, koda mycket och att vara nyfiken pĂ„ vad man gör!

    Jag gillade Jim Coplien’s review över historien kring Agile och Rickard Öbergs (blog) beskrivning pĂ„ vad en Aspekt var för honom och vilka fördelar han sĂ„g med det (framförallt vĂ€ldigt god Ă„teranvĂ€ndbarhet). Rickards (och kollegors???) tankesĂ€tt har gjort att de kunnat nĂ„ mĂ„l med avseende pĂ„ produktivitet som normalt sett skulle anses omöjliga.

    En annan kÀlla till inspiration Àr Dan North och hans sÀtt att bedriva design genom fokus pÄ beteende (BDD, jBehave) och hur man ökar förstÄelsen för TDD genom att fokusera pÄ detta beteende.

    Jimmy Nilsson (blog) talade om nöden att söka lösningar och metoder utanför sin bekvÀma, upplysta bakgata och Ralph Johnson beörde utveckling av idag och hur det till stor del handlar om att underhÄlla befintlig kod. Ralph talade Àven om refactoring ur ett historiskt perspektiv.
    En intressant reflektion kopplad till BDD som jag just fick upp…mitt beteende i livet driver till stor del min egen utveckling. Dan North kanske inte var först nĂ€r allt kommer omkring?!?!   ;-)

  4. Koda snabbt som F*N! (The IntelliJ way…)

    I min presentation för JavaOne beskriver jag hur du kan skriva ett 3D spel pÄ mindre Àn 50 minuter. Detta har gjort att vissa höjt lite pÄ ögonbrynen och stÀllt sig tveksama till att det faktiskt gÄr att skriva det sÄ snabbt. Spelet som jag presenterar bestÄr av ungefÀr 1400 rader kod, varav ungefÀr 500 Àr automatgenererade getter/setters och dylikt. I princip sÄ har jag alltsÄ manuellt skrivit ungefÀr 900 rader Java-kod pÄ mindre Àn 50 minuter. Det betyder 22,5 rader per minut. Jag rÀknar med i genomsnitt ungefÀr 40 tecken per rad, vilket dÄ resulterar i att jag mÄste slÄ 720 slag pÄ tangentbordet varje minut i 50 minuter för att hinna med alltihop. Jag lÀste pÄ Wikipedia att den genomsnittlige datoranvÀndaren skriver mellan 50 och 70 ord per minut, dÀr varje ord Àr i genomsnitt 5 tecken lÄng, d.v.s. 350 tecken per minut som mest (vÀrldsrekordet ligger pÄ 150 ord-per-minut under 50 minuter, innehas av en Barbara Blackburn). Det Àr alltsÄ en bra bit frÄn de 720 tecken/minut som jag behöver uppnÄ. SÄ hur kan jag hÀvda att det Àr möjligt?

    Beroende pĂ„ hur man ser pĂ„ det sĂ„ fuskar jag. Jag anvĂ€nder sjĂ€lv IntelliJ IDEA (6.0 för nĂ€rvarande) för all Java-kodning. ÖverlĂ€gset stöd för code-completion, refactoring, templates och annat trevlig godis för utvecklare. Ta följande exempel; jag ska skapa lĂ€gga till en ActionListener pĂ„ en knapp. Jag har skrivit följande kod och markören stĂ„r pĂ„ *.

    JButton button = new JButton(”Kör”);
    button.addActionListener(
    *);

    Sen lÄngt tillbaka har vi haft grundlÀggande code-completion dÀr jag skriver variabelns namn, punkt, och sen trycker Ctrl-Space (eller dylikt) och fÄr upp en lista pÄ alla metoder som kan köras pÄ det objektet. IntelliJ tar det hela ett steg lÀngre, nu skriver jag bara följande (i fetstil) och trycker pÄ Ctrl-Shift-Space:

    JButton button = new JButton(”Kör”);
    button.addActionListener(
    new );

    Resultatet nu Àr att IntelliJ fattar att det Àr en ActionListener som ska in dÀr. Den presenterar en lista med alla klasser och interface som skulle passa dÀr (alla klasser som implementerar ActionListener och som ligger i projektets classpath). Nu vill jag inte anvÀnda en fÀrdig ActionListener, utan skapa ett anonymt inre objekt. VÀljer jag dÄ ActionListener av de alternativ som finns i listan sÄ fixar IntelliJ all boiler-plate kod Ät mig automatiskt, resultatet blir alltsÄ, utan att jag behöver skriva ett tecken mer, att jag fÄr följande helt automatiskt (markören hamnar pÄ *):

    JButton button = new JButton(”Kör”);
    button.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent e) {
    *
    }
    });

    Detta funkar för alla typer av anonyma inre klasser och Àven för sÄnt du skriver sjÀlv. VÀldigt smidigt alltsÄ. Denna intelligent code-completion fungerar pÄ fler stÀllen. Definerar jag en variabel av typen Map sÄ rÀcker det med att jag skriver variabelns namn, ett = tecken och new och IntelliJ ger mig en lista över alla klasser som implementerar Map. VÀldigt trevligt.
    Detta Àr bara ett litet smakprov av vad IntelliJ erbjuder dig som kodare. Trivilia saker som ofta krÀver mycket manuellt skrivande görs i ett nafs. Refactoring-stödet Àr smÄtt magiskt och har under de 6-7 Är som jag anvÀnt IntelliJ vÀldigt sÀllan fallerat. Nu vet jag att bÄde Eclipse och NetBeans erbjuder smart code-completion och refactoring, men ingen av dem Àr ens i nÀrheten av de finesser som IntelliJ har.

    Baksidan Àr att IntelliJ kostar pengar. $499 för att vara exakt. VÀl investerade pengar enligt mig. För de som vill testa IntelliJ sÄ kan du ladda hem en trial licens pÄ 30 dagar. Du hittar allt pÄ www.intellij.com.

  5. Javaforum fullbokat — igen!

    Javaforumet den 23:e Maj i Göteborg Ă€r nu fullbokat! Vi har valt att sĂ€tta en begrĂ€nsning pĂ„ 150 deltagare för att det inte skall bli för stort och stelt. Vad tycker du — skall vi öppna upp för fler eller rĂ€cker det?

  6. FrÄga efter JavaObjekt

    Ibland, exempelvis nÀr man har stora datamÀngder i objekttrÀd, kan det vara bökigt att leta upp specifikt data utan att hamna i fula stora iterator-if-else konstruktioner. I dessa lÀgen kan ett objektfrÄgesprÄk vara lysande. I Apache Commons finns JXPath som Àr ett sÄdant frÄgesprÄk. Inte helt vÀldokumenterat, men Bart van Riel har skapat en bra tutorial jag kan rekommendera.

  7. PopulÀra men anonyma bakgrundsbilder

    I morgonens Computer Sweden lÀste jag om en konstnÀrsstudent som letat upp motivet till Windows XP:s bakgrundsbild bliss

    bliss

    och tagit ett eget fotografi pÄ motivet/kullen, typ 10 Är efter att orginalfotot togs. Studenten verkade ha behövt stÄngas med Microsoft brevledes ett bra tag innan han kunde lokalisera kullen. En liknande men utförligare redogörelse om hur en journalist pÄ Vanity Fair med stor möda letade upp motivet till XP:s andra bakgrundsbild autumn

    autumn

    och fann det i Ontario, Canada. Fascinerande detektivarbete.

  8. Ska du till JavaOne?

    Om sÄ Àr fallet sÄ kanske du skulle tycka det vore intressant att trÀffa fler likasinnade svenskar. Bert Rubaszkin pÄ Sun hÀr i Sverige har tagit det strÄlande initativet och dragit ihop en kvÀllsaktivitet för oss svenska JavaOne-besökare den 9:e maj i San Fransisco. SjÀlv tycker jag det vore trevligt om man kunde trÀffas innan ocksÄ, sÀrskilt dÄ jag Äker sjÀlv. Jag kommer flyga frÄn Arlanda klockan 09:45 lördagen den 5:e maj (via Chicago) och bo pÄ Pickwick Hotell. Om det skulle vara nÄgon som ska Äka samma tid eller har lust att möta upp pÄ JavaOne sÄ kan ni ju skicka mig ett mail pÄ erik.hellman(snabel-a)ibs.se.

    Tid och plats för min presentation har blivit spikad nu ocksĂ„. Klockan 18:35, torsdagen den 10:e maj, i Hall E – 135 sĂ„ kommer jag köra min session ”Write a 3-D Game in the Java Programming Language in Less Than 50 Minutes” (TS-3073). Om du planerar att gĂ„ pĂ„ den sĂ„ Ă€r det bra ifall du anmĂ€ler dig i förvĂ€g dĂ„ antalet platser i varje sal Ă€r begrĂ€nsat.

  9. UTF-8?

    Efter att jag skrev mitt inlÀgg om encoding i XML sÄ har jag fÄtt frÄgan om vad som skiljer UTF-8 mot, t.ex., ISO-8859-1. Det kan alltsÄ vara pÄ sin plats att förklara vad UTF-8 egentligen Àr och vad som gör det sÄ bra.

    De traditionella encoding standarderna, t.ex. ASCII eller ISO-8859-1, har alla en sak gemensamt. Varje tecken som den definerar tar lika mycket plats som alla andra, vanligtvis en byte (eller 8 bitar). UTF-8 har en variabel lÀngd för varje tecken, som mest 4 bytes. I princip sÄ gÀller följande;

    - För de gamla hederliga 128 US-ASCII tecknen sÄ behövs en byte. Första biten Àr 0.

    - För alla tecken inom latinska alfabetet (Latin character set), grekiska, cyrilliska, armeniska, hebreiska, syriska och thaanaska sÄ behövs 2 bytes. Första byten har dÄ de tvÄ första bitarna satta medan den följande har första biten satt.

    - Övriga tecken inom det s.k. ”Basic Multilingual Plane” (kort sagt samtliga tecken som anvĂ€nds pĂ„ jorden) anvĂ€nder tre bytes dĂ€r första byten har sina tre första bitar satta och de övriga har första biten satt.

    - En fjÀrde byte kan behövas för vÀldigt speciella tecken. I dessa fall har första biten de fyra första bitarna satta medan de övriga har första biten satt.

    Ok, detta betyder alltsÄ att sÄ lÀnge som du befinner dig inom standard US-ASCII (de första 128 tecknen) sÄ brukar man inte mÀrka nÄgon skillnad mot andra encoding standarder. Det Àr troligtvis dÀrför som sÄ mÄnga har ignorerat hela problematiken med encoding. Problemet för oss i Sverige uppstÄr ju första nÀr vi skriver Ä. À eller ö. Eftersom dessa, nÀr vi anvÀnder ISO-8859-1, ligger bortom de första 128 tecknen, sÄ fÄr vi alltsÄ första biten satt och vÄr XML-parser blir smÄtt förvirrad nÀr den inte kan decoda tecknet som den skall.

    UTF-8 definerar alltsĂ„ totalt 1048576 tecken, tillrĂ€ckligt för alla tĂ€nkbara tecken vi anvĂ€nder idag. Det finns ocksĂ„ tvĂ„ andra standarder, UTF-16 och UTF-32. Dessa tillĂ„ter bĂ„da fler tecken Ă€n UTF-8 medan de fortfarande tar 4 bytes som mest. Problemet Ă€r att de ocksĂ„ tar mer plats generellt, eftersom man sĂ€llan anvĂ€nder tecken ovanför de första 128 . UTF-16 tar som minst 16 bitar och UTF-32 tar alltsĂ„ 32 bitar. Alla dessa tre standarder, tillsammans med ett par andra, ingĂ„r i Unicode version 3.0. Förkortningen UTF stĂ„r för Unicode Transformation Format och siffran efter anger hur mĂ„nga bitar varje ”code point” tar.

    UTF-8 Ă€r designat sĂ„ att den ska passa bra i stream-orienterade miljöer (vilket i princip Ă€r allt dĂ€r vi lĂ€ser och skriver data idag). Det intressanta Ă€r att man faktiskt inte behöver lĂ€sa frĂ„n början, det Ă€r fullt möjligt att hoppa in ”i mitten” och börja lĂ€sa dĂ€r, utan att riskera att hamna ur sync. Detta beror ju pĂ„ att alla bytes som börjar pĂ„ 1 Ă€r en del av ett mutli-byte tecken medan de som börjar pĂ„ 0 eller 11 Ă€r början pĂ„ ett tecken.

    Standarden Ă€r relativt ung (1993) och började inte anvĂ€ndas pĂ„ allvar förrĂ€n XML dök upp. Java har hanterat UTF-8 Ă€nda sen första versionen. Dock har Java gjort tvĂ„ modifikationer pĂ„ UTF-8 internt (kallas modified UTF-8). Den första skillnaden Ă€r att null-tecknet kodas med tvĂ„ bytes nĂ€r man serialiserar ett objekt. Detta för att förhindra att om man lĂ€sa in ett serialiserat Java-objekt i, t.ex., C sĂ„ tolkas en tom byte (8 tomma bitar alltsĂ„) som en avslutning pĂ„ en strĂ€ng och skulle alltsĂ„ stĂ€lla till problem. Den andra skillnaden beror pĂ„ att ett tecken i Java alltid Ă€r 16 bitar (storleken pĂ„ en char). Detta gör att tecken utanför ”Basic Multilingual Plane” (d.v.s., tecken som krĂ€ver 4 bytes i UTF-8) behöver tvĂ„ stycken Java tecken för att kodas. Dessa skillnader slipper dock vi utvecklare tĂ€nka pĂ„ (sĂ„vida du inte hackar pĂ„ kompilatorn eller leker med de interna delarna av String-klassen), sĂ„ vi kan gott leva vidare och tĂ€nka ”vanlig” UTF-8 nĂ€r vi kodar.

  10. TeXML

    Har nÄgon sysslat med TeXML?

    TeX Àr ju ett layoutsprÄk för trycksaker. Mycket moget sÄdant. Verktyg för att generera Postscript och PDF frÄn TeX Àr utmÀrkta, fria, och anvÀnds inom den grafiska industrin.

    XSL-FO (formatting objects) Àr ungefÀr samma sak som TeX, fast i en XML-syntax. Att stila XML med hjÀlp av XSL-FO Àr ju egentligen att transformera sitt kÀlldokument till ett XSL-FO-dokument.

    NÀr man har sitt XSL-FO-dokument sÄ mÄste man ha en renderare för att kunna betrakta, eller skriva ut, sitt dokument. Det finns renderare till bilder, och renderare till PDF. Problemet Àr att dessa renderare Àr mycket mindre mogna Àn motsvarande TeX- (och LaTeX-) renderare.

    TeXML pÄstÄr sig vara rÀddningen. Det Àr en XML syntax som efterliknar TeX-syntaxen. Vilket gör att det blir enklare att konvertera till TeX. Och till TeX Àr renderarna mycket mogna.

    IstÀllet för att stila sina XML-dokument med XSL-FO, sÄ föreslÄr folket bakom TeXML att man ska stila dem med TeXML. Det sÀgs att det Àr precis lika enkelt/svÄrt som XSL-FO.

    Nu undrar jag: Àr det nÄgon som vet huruvida detta Àr sant eller ej? NÄgon som provat?

    http://getfo.org/texml/

  11. [REST 2] Kommunikationsmodellerna: REST och SOAP

    I förra inlÀgget sade jag att REST var ett designmönster dÀr man anvÀnder HTTP som applikationsprotokoll, inte som i SOAP som försöker vara protokollagnostiskt och som betraktar HTTP som ett transportprotokoll, ett slags TCP som kan ta sig genom brandvÀggar.

    NÄ, att REST anvÀnder HTTP som applikationsprotokoll betyder att applikationer skrivna efter REST-mönstret Àrver egenskaperna frÄn den kommunikationsmodell som HTTP bygger pÄ.

    Detta Ă€r ju inget konstigt. SOAP Ă€rver egenskaperna frĂ„n sin kommunikationsmodell. SOAPs modell kan vi kalla för RPC-modellen som i sin tur Ă€r en distribuerad variant av den vanliga ”message passing object oriented”-modellen (Java, C++, m fl).

    Message-passing, det betyder att all interaktion med ett objekt gĂ„r ut pĂ„ att man skickar ett meddelande till det objektet (populĂ€rt kallat: ”anropa en metod pĂ„ objektet”). Oavsett vad meddelandet ska göra (ta bort, lĂ€gga till, förĂ€ndra, ingenting).

    I RPC-modellen finns det ett ”objekt” (eller egentligen ett interface) pĂ„ en annan datamaskin. Metoderna i detta interface kan man anropa, nĂ€stan som vore de lokala anrop (i alla fall Ă€r det sĂ„ det ska kĂ€nnas). Det Ă€r RPC-modellens styrka: den imiterar lokala anrop sĂ„ gott det gĂ„r. Och sĂ„ funkar ju EJB, sĂ„ funkar CORBA, sĂ„ funkar XML-RPC och sĂ„ funkar SOAP:

    //ganska begripligt interface, enkelt att omvandla till
    //distribuerat objekt sÄsom SOAP, CORBA EJB m fl.
    
    public Customer findCustomer( String searchString);
    public void saveCustomer( Customer customer);
    public void removeCustomer( String customerId);
    public double getCurrencyMultiplier( String currencyIso);
    public String[] getCurrencies();
    

    REST Ä sin sida handlar om webben. Och webben Àr bland annat följande:

    • En gigantisk samling resurser, som oavsett vad de Ă€r för nĂ„got, Ă€r Ă„tkomliga via varsin URL. PĂ„ lika villkor.
    • En plats dĂ€r man enkelt kan be om en resurs, och den kommer till en i form av en radda oktetter (bytes). Oavsett om det Ă€r ett foto eller om det Ă€r en vĂ€derprognos eller om det Ă€r ett javaprogram. PĂ„ lika sĂ€tt.
    • Även om webben Ă€r agnostisk i vad den skickar, sĂ„ meddelar den prydligt vad oktettströmmen ska tolkas som: text/plain, image/png, application/x-java-jnlp-file, x-whatever/x-from-the-future.
    • Att be om en resurs kallas för GET. Det finns Ă€ven PUT för att placera en resurs pĂ„ en URL, och DELETE för att ta bort en resurs pĂ„ en URL.
    • Det handlar om en tillstĂ„ndslös kommunikation. I grund och botten struntar protokollet HTTP i om du bad om en viss resurs alldeles nyss, för HTTP Ă€r alla anrop lika. TillstĂ„ndet bestĂ€ms istĂ€llet av vilken resurs klienten rĂ„kar titta pĂ„ för tillfĂ€llet.
    • DĂ€remot innehĂ„ller protokollet sĂ€tt att be en anvĂ€ndare identifiera och autentiera sig, vilket ju Ă€r det vanligaste skĂ€let till att man alls vill ha sessioner. Men autentieringen och auktorisationen Ă€ger alltsĂ„ rum en gĂ„ng per anrop.

    Vad innebĂ€r denna skillnad? Jo…

    Webbmodellen stödjer tre specialmeddelanden: HÀmta resurs, Spara resurs, Ta bort resurs. Verben GET, PUT och DELETE. Precis som ett filsystem, fast med globalt Ätkomliga objekt.

    Kan du nu förklara för mig hur grÀnssnittet ovan (findCustomer() osv) skulle kunna se ut, om man istÀllet tÀnkte i REST-banor?

    Helt riktigt. NÀr man modellerar system, sÄ inser man att dessa tre verb Àr tillÀmpliga pÄ i stort sett alla objekt. PUT Àr en införande, eller en förÀndrande, hÀndelse, DELETE Àr en borttagande hÀndelse. GET Àr ju helt enkelt att betrakta ett objekt, en betraktande hÀndelse, en hÀndelse som inte ska pÄverka objektet sjÀlvt.

    Vi ser att alla metoderna i vÄrt interface ovan Àr av dessa tre slag. Fast för olika resurser:

    GET /customers?name~Ola*
    
    GET /currencies
    
    GET /currencies/USD
    
    PUT /customers/Ola
    
    DELETE /customers/Ola
    

    NÀsta gÄng ska vi titta mer pÄ varför och hur.

  12. Allt du behöver veta som programmerare lÀrde du dig redan pÄ dagis.

    Enligt The Codist Àr reglerna pÄ dagis applicerbara pÄ hur man ska tÀnka och arbeta som programmerare. LÀs mer pÄ The Codist

  13. En enkel lösning för att lÀsa in 3D Modeller i Java

    Som jag tidigare har skrivit sĂ„ ska jag Ă„ka till JavaOne nu i maj och hĂ„lla en presentation med titeln ”How to write a 3D computer game using Java in less than 50 minutes.”. Detta lĂ„ter kanske som ett ganska djĂ€rvt pĂ„stĂ„ende, sĂ„ jag tĂ€nkte berĂ€tta lite om en av de större utmaningarna som jag haft med att ta fram denna presentation.

    Som ni sÀkert vet sÄ brukar man skapa de 3D modeller som anvÀnds i spel med hjÀlp av ett 3D-modelleringsprogram, t.ex. 3DStudio MAX eller Lightwave. Den fil (eller filer) som dessa skapar kan liknas vid ett serialiserat 3D-objekt. För den som vill ladda en 3D-modell sÄ behöver man alltsÄ lista ut strukturen pÄ formatet (eller hitta specifikationen) och sen skriva en parser som lÀser igenom filen och skapar objektrepresentationen av det hela. LÄter ganska enkelt, eller hur?

    Faktum Àr att det Àr vÀldigt enkelt att skriva en parser som laddar en fil frÄn en 3D-modellerare. I mitt fall handlar det om COLLADA-formatet som jag exporterat frÄn 3D modelleraren Blender. COLLADA Àr ett öppet XML-baserat format som anvÀnda för att beskriva en 3D scen (LÀs mer om COLLADA pÄ http://www.khronos.org/collada/). Bland annat sÄ har Sony valt att anvÀnda COLLADA som det standard-format som 3D modeller ska ha i PlayStation 3. Genom att anvÀnda det XML schema som finns för COLLADA sÄ kan jag enkelt generera klasser (Java Beans) för varje element som min 3D-modell bestÄr av. Genereringen gör jag med hjÀlp av ett API som heter XMLBeans. Man tar kort och gott ett XML Schema, kör XMLBeans schema-compiler och vips sÄ har du en jar-fil komplett med kompilerade klasser för alla element som finns beskrivet i ditt schema. DÀrefter Àr det en bara att lÀsa in din XML-fil pÄ följande vis:

    COLLADADocument parsedDocument = COLLADADocument.Factory.parse(new File(fileName));

    COLLADADocument Àr en genererad klass som representerar en COLLADA-fil. FrÄn det objektet kan jag sen stega mig ner till alla element som min 3D-modell innehÄller och enkelt lÀsa upp datan sÄ som jag vill anvÀnda den i min applikation. PÄ detta vis fÄr jag snabbt och enkelt en parser för att ladda mina modeller. Det enda du behöver kÀnna till Àr strukturen pÄ formatet, nÄgot som Àr ganska enkelt att lÀra sig dÄ COLLADA Àr ett öppet format och det finns rÀtt mycket dokumentation för den som vill fördjupa sig.

    Det man upptÀcker rÀtt snabbt dÄ man börjar med 3D programmering Àr att inlÀsning av 3D-modeller Àr nÄgot som stÀller till rÀtt mycket. Det finns en hel del s.k. loaders tillgÀngliga, men alla dessa Àr helt beroende av det 3D API (t.ex. Java 3D eller Xith 3D) som de skrevs för. Du kan alltsÄ inte anvÀnda dessa loaders utan att samtidigt behöva binda upp dig till ett stort och ofta komplext ramverk. Men ovan beskrivna metod sÄ kommer du förbi det problemet. Allt du behöver göra Àr att ta din 3D-modell, lÀsa in den i Blender (eller vilket program du nu vÀljer anvÀnda) och exportera den till ett XML-baserat format (Det finns tvÄ stycken öppna standarder baserade pÄ XML, COLLADA och X3D).

    Eftersom klasserna som skapas med XMLBeans följer JavaBeans-standarden sÄ finns det vÀldigt intressanta saker man kan göra hÀr. Spring Framework för spelprogrammering nÄgon?

    XMLBeans har Àven mÄnga andra anvÀndabara omrÄden, sÄ jag rekommenderar er att ta en titt pÄ det om ni ska jobba mycket med olika XML-dokument i Java.

  14. Dokumentation nÄgon?

    TrĂ€ffsĂ€ker strip om ett projekts olika ”faser”: http://www.noise.se/project.jpg