seeseekey.net - Invictus Deus Ex Machina

Mit Java­script und Co. ist mitt­ler­weile eine ganze Menge mög­lich. Das sieht man auch immer wie­der an den unter­schied­lichs­ten Expe­ri­men­ten, wel­che aus dem Hause Google kom­men. In diese Fall ist es buildwithchrome.com.

Lego im Browser

Auf der Seite kann man dabei vir­tu­ell mit Lego­stei­nen spie­len. Lei­der sind nur rote Steine vor­han­den und auch die Stein­aus­wahl ist begrenzt — trotz­dem kann man beacht­li­che Bau­werk erschaf­fen. Alles in allem ist es ein schö­nes Bei­spiel was man mitt­ler­weile im Brow­ser bewerk­stel­li­gen kann.

Wer Entity-Relationship-Modelle bzw. die ent­spre­chen­den Dia­gramme (ERD) erstel­len möchte, der kann hier­für Soft­ware wie die freie MyS­QL­Work­bench nut­zen. Für das platt­form­über­grei­fende Erzeu­gen sol­cher Dia­gramme kann man aller­dings auch die freie Webap­pli­ka­tion wwws­ql­de­si­gner nutzen.

Der ERD-Designer in Aktion

Auf der Web­seite des Autors gibt es eine Demo zum Aus­pro­bie­ren. Die in PHP und Java­script geschrie­bene Soft­ware steht dabei unter einer BSD-Lizenz und ist somit freie Soft­ware. Bei der Instal­la­tion muss das ent­spre­chende Archiv nur auf dem Web­ser­ver ent­packt wer­den und kann sofort genutzt wer­den. Nur wer die Mög­lich­kei­ten der ser­ver­sei­ti­gen Spei­che­rung nut­zen möchte, muss einige Para­me­ter kon­fi­gu­rie­ren.

Wer schon immer das tiefe und uner­klär­li­che Bedürf­nis hatte, Win­dows in der ers­ten Ver­sion aus­zu­pro­bie­ren, der kann dies nun tun. Mög­lich wird dies mit der Web­seite jsmachines.net. Das ganze basiert dabei auf dem unter GPL ste­hen­den PCjs. Dabei han­delt es sich um einen IBM PC Emu­la­tor, wel­cher in Java­script geschrie­ben ist. Der Quell­text soll spä­ter auf Git­Hub zur Ver­fü­gung stehen.

Der Win­dows 1 Emu­la­tor in Aktion

Die Windows-Emulation ist neben eini­gen ande­ren Emu­la­tio­nen (unter ande­rem Zork I und DONKEY.BAS) auf der Web­seite zu fin­den.

In den neue­ren Fire­fox Ver­sio­nen hat man das Pro­blem das sich im Opti­ons­menü kei­ner­lei Mög­lich­keit mehr fin­det, Java­script kom­plett abzu­schal­ten. Der Grund für diese Ent­schei­dung sei­tens Mozilla liegt darin, dass „das Web ohne Java­script ein­fach kaputt ist“. Abhilfe schaf­fen hier Plugins wie NoScript. Aller­dings gibt es auch im Fire­fox direkt noch die Mög­lich­keit Java­script zu deak­ti­vie­ren. Dazu gibt man in der Adress­leiste „about:config“ ein und sucht nach der Zeichenkette:

javascript.enabled

Der Wert kann dann ent­we­der auf „true“ oder auf „false“ gesetzt wer­den, und somit die Java­script­ein­bin­dung kon­fi­gu­riert werden.

Das schöne an zen­tra­len Samm­lun­gen ist das man sie rela­tiv ein­fach aus­wer­ten kann. In die­sem Fall geht es um die Aus­wer­tung der Git­Hub Repo­si­to­ries. Wie der Name „Popu­lar Con­ven­tion“ andeu­tet geht es darum aus den Quell­tex­ten bestimmte Infor­ma­tio­nen über bevor­zugte Kon­ven­tio­nen wie z.B. Leer­zei­chen vs. Tabs zu extrahieren.

Popu­lar Con­ven­tion und Scala

Das Ergeb­nis kann man sich auf der Web­seite http://sideeffect.kr/popularconvention/ für die Spra­chen Java­script, Java, Python und Scala anschauen. Die Soft­ware zur Aus­wer­tung ist dabei freie Soft­ware und steht unter der MIT Lizenz und kann unter https://github.com/outsideris/popularconvention bezo­gen werden.

Über das Wochen­ende hatte ich einige GPS getagte Bil­der geschos­sen und wollte diese auf einer Karte dar­stel­len. Eine kurze Suche im Netz ergab, das so etwas in die­ser Form nicht exis­tierte (wobei hier natür­lich ein Irr­tum vor­lie­gen kann). Also wurde das ganze auf Basis von Leaf­let implementiert.

Die Webap­pli­ka­tion in Aktion

Leaf­let ist ein Frame­work mit wel­chem man schnell Kar­ten­ap­pli­ka­tio­nen im Web rea­li­sie­ren kann. Um den „Gps Tag­ged Image Viewer“ zu benut­zen, müs­sen die Dateien auf einem Web­ser­ver kopiert wer­den. Die Bil­der wer­den dabei in den Ord­ner „images“ kopiert. Anschlie­ßend wird das PHP Skript „parseimages.php“ aus dem „utils“ Ord­ner aus­ge­führt. Die­ses ließt die EXIF Daten aus den Bil­dern aus und erzeugt die ent­spre­chen­den Mar­ker in einer Java­script Datei. Danach kann das ganze genutzt werden.

Die Karte ist dabei mit drei Kar­ten­ebe­nen ver­se­hen, ein­mal Bing Luft­bil­der (für wel­che ein API-Key regis­triert wer­den muss), sowie Open­Street­Map in zwei unter­schied­li­chen Ren­de­rings. Der Quell­text ist unter GPLv3 ver­füg­bar und kann auf Git­Hub bezo­gen werden.

Da beginnt man den Tag mit dem gemüt­li­chem Debug­gen von Java­script Code und plötz­lich bekommt man von Chrome fol­gende Mel­dung auf der Javascript-Konsole:

Cross origin requests are only supported for HTTP.

vor­ge­setzt. Da stellt sich natür­lich die Frage was pas­siert ist. Die Ant­wort ist rela­tiv ein­fach. Chrome unter­bin­det das die betref­fende Webap­pli­ka­tion etwas von einem ande­ren Ursprung laden kann. Bei HTTP würde so etwas funk­tio­nie­ren. Wenn man das ganze über das „file:///“ Schema auf­ruft wird es etwas kom­pli­zier­ter. Dafür muss Chrome der Para­me­ter „-allow-file-access-from-files“ über­ge­ben wer­den, wel­cher das ganze dann wie­der erlaubt. Unter Mac OS X könnte die Kom­man­do­zeile dann wie folgt aussehen:

open /Applications/Google\ Chrome.app/ --args -allow-file-access-from-files

Danach funk­tio­nie­ren die „Cross ori­gin requests“ unter Chrome auch lokal.

In Java­Script kann man ver­nünf­tig pro­gram­mie­ren, wenn man die schlech­ten Teile weg­lässt. Nicht umsonst gibt es das Buch Java­Script: The Good Parts. Dabei haben sich im Laufe der Zeit einige „Best Prac­tices“ ent­wi­ckelt, wel­che unter ande­rem in Form von Design Pat­terns vor­lie­gen. Auf der Web­seite http://shichuan.github.com/javascript-patterns/ kann man sich diese anschauen und so sehen, was man in Zukunft bes­ser machen kann. Das ent­spre­chende Git­Hub Pro­jekt ist dabei unter https://github.com/shichuan/javascript-patterns/ zu fin­den. Lei­der scheint es keine defi­nierte Lizenz für das Pro­jekt zu geben, so das der Lizenz­sta­tus im Moment augen­schein­lich noch unge­klärt ist.

Bei der Ent­wick­lung wun­dert man sich ab und an, was für inter­es­sante Pro­jekte in den Wei­ten des Net­zes so umher­schwir­ren. So unter ande­rem das Pro­jekt Script#. Dabei han­delt es sich um eine Erwei­te­rung für das Visual Stu­dio 2012 mit wel­cher es mög­lich ist C# Quell­text (so er gewis­sen Kri­te­rien genügt) in Java­Script umzu­wan­deln, bzw. zu compilieren.

Die Erwei­te­rung wel­che im Quell­text unter https://github.com/nikhilk/scriptsharp zu fin­den ist, steht dabei unter der Apa­che Lizenz und ist somit freie Soft­ware. Nach der Instal­la­tion fügt sie dem Visual Stu­dio neue Pro­jekt­ty­pen hinzu, mit wel­chen man anschlie­ßend arbei­ten kann. Lei­der gibt es von Script# keine Mono­De­ve­lop Vari­ante, so das man im Moment zwin­gend an das Visual Stu­dio gebun­den ist. Aller­dings fin­det sich in der Road­map fol­gen­der Satz:

In terms of code con­tri­bu­tion, it would be espe­cially inte­res­ting to see the deve­lop­ment of import libra­ries for com­mon libra­ries, so they are easily usa­ble right out of the box. It would also be inte­res­ting to see the deve­lop­ment of com­ple­men­tary tools/addins, adding sup­port to other IDEs (esp. Mono­De­ve­lop) and other such com­ple­men­tary pro­jects. Or you might be inte­res­ted in the very core, i.e. the com­pi­ler itself.

Also wenn sich jemand bemü­ßigt fühlt, das ganze für Mono­De­ve­lop in Angriff zu neh­men, der muss nun nicht mehr auf die Ein­la­dung war­ten. Die offi­zi­elle Pro­jekt­seite von Script# ist unter http://scriptsharp.com/ zu finden.

Bei melonJS han­delt es sich um eine Java­script Engine zur Spie­le­ent­wick­lung im Brow­ser mit­tels HTML5. Möchte man dort ein Level laden, so geschieht das in Form einer TMX Datei. In melonJS gibt es dabei zwei Metho­den zum laden der ent­spre­chen­den Daten. Diese sind „me.loader.preload“ und „me.loader.load“. Alle Bei­spiele wel­che man im Netz so fin­det nut­zen dabei immer die „pre­load“ Methode:

var g_resources= [
{ name: "desert1",          type: "image", src: "desert1.png" },
{ name: "desert",           type: "tmx",   src: "desert.tmx" },
{ name: "player_male_base", type: "image", src: "player_male_base.png" },
{ name: "fog",              type: "image", src: "fog.png" }
];

...

me.loader.preload(g_resources);

Das Pro­blem ist das man bei grö­ße­ren Spie­len mit ein paar hun­dert MiB Spiel­da­ten, das ganze schlecht kom­plett in den Spei­cher laden kann. Hier­für gibt es die „load“ Methode. Aller­dings ent­hält diese einige Feh­ler wel­che das ganze erschwe­ren. Die „pre­load“ Methode trägt jede TMX Datei in das Array „levels“ im „me.levelDirector“ ein. Bei der „load“ Methode pas­siert genau dies nicht. Des­halb muss man hier anders vor­ge­hen (bis der Feh­ler beho­ben ist). Ein Mini­mal­b­ei­spiel zum laden eines Levels sieht damit so aus:

<!DOCTYPE html>
<html>
  <head>
    <title>melonJS minimal sample</title>
    <meta charset="utf-8" />
  </head>
  <body>
    <script type="text/javascript" src="melonJS.js"></script>

    <script type="text/javascript">
      var jsApp = {
        start: function() {
          if (!me.video.init('jsapp', 640, 480, false, '1', false))
          {
            alert("Sorry but your browser does not support html 5 canvas.");
            return;
          }

          me.loader.onload = this.loaded.bind(this);

          //lade manuell
          me.loader.load({name: "desert1",  type:"image",  src: "desert1.png"}, this.onload);
          me.loader.load({name: "desert",  type:"tmx",  src: "desert.tmx"}, this.onload);

          //zeige Ladebildschirm
          me.state.change(me.state.LOADING);
        },

        onload: function(data) {
          me.levelDirector.addTMXLevel("desert"); //Bugfix
          me.levelDirector.loadLevel("desert");
        },

        loaded: function() {
          me.state.set(me.state.PLAY, new PlayScreen());
          me.state.change(me.state.PLAY);
        }
      }

      var PlayScreen = me.ScreenObject.extend({
      });

      //starte wenn der Browser bereit ist
      window.onReady(function() {
        jsApp.start();
      });
    </script>
  </body>
</html>

Damit lädt man ein Level dyna­misch, ohne auf die „pre­load“ Methode ange­wie­sen zu sein. Mög­lich wird dies durch den klei­nen Bug­fix in der „onload“ Methode:

me.levelDirector.addTMXLevel("desert"); //Bugfix

Die­ser sorgt dafür das der level­Di­rec­tor über die ent­spre­chende TMX Datei infor­miert wird und somit die Datei beim laden des Levels auch findet.