• Part 1: Introduction and game loop
• Part 2: Static blocks and keeping score

Joined or separated?

Think about the way we play Tetris. When the block is moving, we transform and rotate it freely. Cubes that make block are clearly connected and it’s intuitive that their representation in code should be as well. On the other hand, when we try to complete a slice (in 2D – a row) and we succed, the cubes are removed and the block that was their origin doesn’t matter at this point. In fact, it shouldn’t matter – some boxes from a block may be removed and other not. Tracing an origin of a box would require constant splitting and merging geometries and trust me – that would be a crazy mess. In original 2D Tetris sometimes the color of a square was the indicator of the origin block. In 3D however we need a quick way to show z-axis and color is perfect for this.

In our game cubes will be connected when are dynamic and static when they are not. At the end of tutorial we will further optimize static cubes.

Adding a static block

Lets start with a moment when a moving block touches the floor (or another block). The moving block (with merged geometry of few cubes) is transformed into static, separated cubes that don’t move anymore. It’s convenient to keep these cubes in a 3D array.

Tetris.staticBlocks = [];
Tetris.zColors = [
  0x6666ff, 0x66ffff, 0xcc68EE, 0x666633, 0x66ff66, 0x9966ff, 0x00ff66, 0x66EE33, 0x003399, 0x330099, 0xFFA500, 0x99ff00, 0xee1289, 0x71C671, 0x00BFFF, 0x666633, 0x669966, 0x9966ff
];
Tetris.addStaticBlock = function(x,y,z) {
  if(Tetris.staticBlocks[x] === undefined) Tetris.staticBlocks[x] = [];
  if(Tetris.staticBlocks[x][y] === undefined) Tetris.staticBlocks[x][y] = [];

  var mesh = THREE.SceneUtils.createMultiMaterialObject(new THREE.CubeGeometry( Tetris.blockSize, Tetris.blockSize, Tetris.blockSize), [
    new THREE.MeshBasicMaterial({color: 0x000000, shading: THREE.FlatShading, wireframe: true, transparent: true}),
    new THREE.MeshBasicMaterial({color: Tetris.zColors[z]})
  ] );

  mesh.position.x = (x - Tetris.boundingBoxConfig.splitX/2)*Tetris.blockSize + Tetris.blockSize/2;
  mesh.position.y = (y - Tetris.boundingBoxConfig.splitY/2)*Tetris.blockSize + Tetris.blockSize/2;
  mesh.position.z = (z - Tetris.boundingBoxConfig.splitZ/2)*Tetris.blockSize + Tetris.blockSize/2;
  mesh.overdraw = true;

  Tetris.scene.add(mesh);
  Tetris.staticBlocks[x][y][z] = mesh;
};

There is a lot to explain here.

Colors and materials

Tetris.zColors keeps a list of colors that indicate position of a cube on z-axis. I’d like to have a good looking cube, so it should have a color AND outlined border. I’m going to use something that is not very popular in Three.js tutorials – multiMaterials. There is a function in Three.js SceneUtils that takes a geometry and an array (notice brackets []) of materials. If you look in Three.js source:

  createMultiMaterialObject : function ( geometry, materials ) {
  var i, il = materials.length, group = new THREE.Object3D();
  for ( i = 0; i < il; i ++ ) {
    var object = new THREE.Mesh( geometry, materials[ i ] );
    group.add( object );
  }
  return group;
},

It’s a very simple hack that creates a mesh for every material. With pure WebGL there are better ways to achieve the same result (f.e. calling draw two times, once with gl.LINES and second with gl.something) but the usual use of this function is to for example to merge textures and materials at the same time – not different types of drawing.

Position in 3D space

Now, why the hell does position look like that?

mesh.position.x = (x - Tetris.boundingBoxConfig.splitX/2)*Tetris.blockSize + Tetris.blockSize/2;

Our board center on init was placed in the (0,0,0) point. It is not a very good spot, as it means that some cubes will have negative position and others positive. It would be better to specify a corner of an object in our case. Moreover, we would like to think of our boxes positions as a discrete values from 1 to 6, or at least 0 to 5. Three.js (and WebGL, OpenGL and everything else) uses its own units that rather relate to meters or pixels. If you remember, in config we put a value

Tetris.blockSize = boundingBoxConfig.width/boundingBoxConfig.splitX;

that is responsible for conversion. So as a summary:

 // transform 0-5 to -3 - +2
(x - Tetris.boundingBoxConfig.splitX/2)
 // scale to Three.js units
*Tetris.blockSize
 // we specify cube center, not a corner - we have to shift position
 + Tetris.blockSize/2

Nice test

Our game is still very static, but you can open your console and run:

var i = 0, j = 0, k = 0, interval = setInterval(function() {if(i==6) {i=0;j++;} if(j==6) {j=0;k++;} if(k==6) {clearInterval(interval); return;} Tetris.addStaticBlock(i,j,k); i++;},30)

It should animate filling the board with cubes.

Keeping score

A small utility function to keep score:

Tetris.currentPoints = 0;
Tetris.addPoints = function(n) {
  Tetris.currentPoints += n;
  Tetris.pointsDOM.innerHTML = Tetris.currentPoints;
  Cufon.replace('#points');
}

You can call it from console as well.

• Part 1: Introduction and game loop
• Part 2: Static blocks and keeping score

Preparation

First you need to download Three.js: https://github.com/mrdoob/three.js

I also use Stats from mrdoob: https://github.com/mrdoob/stats.js

In both cases you need only files from build directory.

Blox is a nice font for menu and points: http://www.dafont.com/blox.font

To use it you have to convert it with Cufon: http://cufon.shoqolate.com/generate/

In my project all JS files go to js folder, music into music folder and html in root.

HTML

I’m lazy so all the CSS goes directly into html header. It’s not as bad as it sounds – it’s very short and there is only one page so caching is unnecessary anyway. There is not much to explain, just some CSS for the intro and score counter. Also you have to include all js and init cufon.

<!DOCTYPE html>
<html>
  <head>
    <title>Three.js Tetris</title>
	<style>
		body {margin: 0; padding: 0; overflow: hidden;}

		#menu {
			position: absolute;
			width: 200px;
			height: 250px;

			top: 50%; left: 50%;
			margin: -125px 0 0 -100px;

			text-align: center;

			border: 3px solid #fff;
			border-radius: 15px;

			background-color: #E36B23;
			box-shadow: 2px 10px 5px #888;
		}

    #menu p {font-weight: bold; color: #fff;}
    #menu p a {color: #fff;}

		#menu button {
			width: 80px;
			height: 25px;

			background-color: #C44032;

			border: 3px solid #fff;
			border-radius: 5px;	

			font-size: 14px;
			font-weight: bold;
			color: #fff;
		}

		#points {
			position: absolute;
			width: 120px;
			height: 16px;	

			padding: 12px;

			top: 20px;
			right: 80px;

			border: 3px solid #fff;
			border-radius: 15px;

			background-color: #E36B23;
			box-shadow: 2px 10px 5px #888;	

			font-size: 14px;
			font-weight: bold;
			color: #fff;	

			text-align: right;

			display: none;
		}
	</style>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
	</head>
  <body>
	<div id="menu">
		<h1>Three.js Tetris</h1>
    <p>
      Movement: arrows<br>
      Rotation: AD/SW/QE<br>
      Author: <a href="http://www.smashinglabs.pl">smashinglabs.pl</a>
    </p>
		<button id="play_button">Play</button>
	</div>

	<div id="points">
		0
	</div>

	<script type="text/javascript" src="js/Three.js"></script>
	<script type="text/javascript" src="js/Stats.js"></script>
	<script type="text/javascript" src="js/tetris.js"></script>

	<script src="js/cufon-yui.js" type="text/javascript"></script>
	<script src="js/Blox_400.font.js" type="text/javascript"></script>	

	<script type="text/javascript">
		Cufon.replace('#menu h1');
		Cufon.replace('#points');
	</script>
  </body>
</html>

Basic Structure and Three.js init

There are many ways of organizing your game. If you want to host it on a gaming portal, you may need to use some kind of closure (i.e. not use global variables). If your game is very complex, inheritance becomes useful. But for the simple game working fullscreen all these concepts show as hard to maintain and not without some impact on preformace. The project will use one global namespace

var Tetris = {};

All objects, functions and variables will be a member of Tetris. It’s a very useful way to maintain your code and to avoid usage of “this”. To make things even better, every object I use is a singleton. There are some drawbacks – it’s a classic god object and a mixture of everything, but as long as it’s small I don’t care and you shouldn’t either.

We will focus on this structure later, now lets initialize Three.js. I used a tutorial by Aerotwist which is very simple, but plain and good enough. You should probably read it before you proceed.

Tetris.init = function() {
  // set the scene size
  var WIDTH = window.innerWidth,
      HEIGHT = window.innerHeight;

  // set some camera attributes
  var VIEW_ANGLE = 45,
      ASPECT = WIDTH / HEIGHT,
      NEAR = 0.1,
      FAR = 10000;

  // create a WebGL renderer, camera
  // and a scene
  Tetris.renderer = new THREE.WebGLRenderer();
  Tetris.camera = new THREE.PerspectiveCamera(  VIEW_ANGLE,
                                  ASPECT,
                                  NEAR,
                                  FAR  );
  Tetris.scene = new THREE.Scene();

  // the camera starts at 0,0,0 so pull it back
  Tetris.camera.position.z = 600;
  Tetris.scene.add(Tetris.camera);

  // start the renderer
  Tetris.renderer.setSize(WIDTH, HEIGHT);

  // attach the render-supplied DOM element
  document.body.appendChild(Tetris.renderer.domElement);

  // to be continued...

The introduced Tetris.init is creating a Three.js objects and store them in global namespace. There is a renderer, a scene and a camera. I want the game to be fullscreen so I use window.innerWidth and window.innerHeight. You may want to experiment with fullscreen API there. The camera needs to be pulled back and an exact distance should be determined by the size and position of the game world you use.

Our game world is a 3D wireframe box with lines showing where boxes can be dropped. When you work on a game it’s important to realize that the final effect is what matters most. Don’t be afraid to cheat! In this case, there is no good reason to draw lines on bounding box. We may as well use a normal box geometry, place a vertex on every line cross and connect vertices with lines instead of usual triangles. And luckily there is a Three.js syntax just for that!

  // configuration object
  var boundingBoxConfig = {
    width: 360,
    height: 360,
    depth: 1200,
    splitX: 6,
    splitY: 6,
    splitZ: 20
  };

  Tetris.boundingBoxConfig = boundingBoxConfig;
  Tetris.blockSize = boundingBoxConfig.width/boundingBoxConfig.splitX;

  var boundingBox = new THREE.Mesh(
    new THREE.CubeGeometry(
      boundingBoxConfig.width, boundingBoxConfig.height, boundingBoxConfig.depth,
      boundingBoxConfig.splitX, boundingBoxConfig.splitY, boundingBoxConfig.splitZ),
    new THREE.MeshBasicMaterial( { color: 0xffaa00, wireframe: true } )
  );
  Tetris.scene.add(boundingBox);

  // first render
  Tetris.renderer.render(Tetris.scene, Tetris.camera);
  // to be continued...

A Three.js API describes CubeGeometry constructor as:

(width <Number>, height <Number>, depth <Number>, segmentsWidth <Number>, segmentsHeight <Number>, segmentsDepth <Number>, materials <Array>, sides <Object>)

and we make use of “segmentX” options to define how many boxes can be fitted into our gameboard. We use also MeshBasicMaterial option wireframe to draw lines instead of triangles.

Last things to do in init function:

  Tetris.stats = new Stats();
  Tetris.stats.domElement.style.position = 'absolute';
  Tetris.stats.domElement.style.top = '10px';
  Tetris.stats.domElement.style.left = '10px';
  document.body.appendChild( Tetris.stats.domElement );

  document.getElementById("play_button").addEventListener('click', function (event) {
    event.preventDefault();
    Tetris.start();
  });
};

We add FPS stats and bind Tetris.start() to the play button. What should be done in start()?

Tetris.start = function() {
   document.getElementById("menu").style.display = "none";
   Tetris.pointsDOM = document.getElementById("points");
   Tetris.pointsDOM.style.display = "block";

   Tetris.animate();
};

Hide instructions, show score box and start first animate() function.

Game loop

You may wonder why there was no setInterval for animation. There is a much better function for that – requestAnimationFrame(). It calls specified functions when the browser is not busy, but no more than 60 times per second. It means that you will have exactly the number of FPS that is possible to render. No need to worry about calculating the best time step for setInterval or clots if you try to render more FPS than it’s possible to calculate. The function is still something new, so on top of our script we will place a compatibility code:

if ( !window.requestAnimationFrame ) {
  window.requestAnimationFrame = ( function() {
    return window.webkitRequestAnimationFrame ||
    window.mozRequestAnimationFrame ||
    window.oRequestAnimationFrame ||
    window.msRequestAnimationFrame ||
    function( /* function FrameRequestCallback */ callback, /* DOMElement Element */ element ) {
      window.setTimeout( callback, 1000 / 60 );
    };
  })();
}

Now we need to write animate() function. Tetris is real-time, but a step of game is quite long, like one z-axis move per second. We need to calculate when to move our block forward, so some time-related variables have to be introduced:

Tetris.gameStepTime = 1000;

Tetris.frameTime = 0; // ms
Tetris.cumulatedFrameTime = 0; // ms
Tetris._lastFrameTime = Date.now(); // timestamp

Tetris.gameOver = false;

Now, the animate function in simplified version has to call Three.js render method and call itself again using requestAnimationFrame. This would make our game static, so we need to calculate a passage of time and act if it was long enough.

Tetris.animate = function() {
  var time = Date.now();
  Tetris.frameTime = time - Tetris._lastFrameTime;
  Tetris._lastFrameTime = time;
  Tetris.cumulatedFrameTime += Tetris.frameTime;

  while(Tetris.cumulatedFrameTime > Tetris.gameStepTime) {
    // block movement will go here
    Tetris.cumulatedFrameTime -= Tetris.gameStepTime;
  }

  Tetris.renderer.render(Tetris.scene, Tetris.camera);

  Tetris.stats.update();

  if(!Tetris.gameOver) window.requestAnimationFrame(Tetris.animate);
}

If you noticed stats update, you may think it’s a little redundant. Stats are obviously counting FPS and we do the same thing. You may want to dig into stats code and re-use some data, but I’ve found it simpler to write my own few lines of code. Stats were not intended for such usage and the overhead is close to zero. Besides, if you’d like to remove FPS counter from your game when it’s released, it could be a problem. The less dependencies the better.

And, at last, we should call init() when the page is loaded:

window.addEventListener("load", Tetris.init);

As always, you can download it from github.

I had a lot of feature requests since last version and I hope I covered them all.
Here is what’s new in 3.3.0:

• clustering
• fixAfterResize – fixing issues with loading gMaps in tabs
• changeSettings – works with most of initial options
• mapclick(callback) – bind for map click event
• geocode(address, callback) – shorthand for geocoding
• draggable markers (thanks to theMarvin)

I’m getting close to the point where I’ll consider gMap completed. Now it’s just about the time to improve documentation, which is still in 3.1.0 (sorry for that) and to complete test coverage.

I’d like to share a link to Magic Gallery WordPress Plugin: http://www.magicgalleryplugin.com/ It uses gMap and has a very nice design.

If you want to support my work and make my Christmas even better, please consider donating (button on the right sidebar).

That’s all the news, merry Christmas everyone!

Some highlights of things that has changed:

Trace JIT is no more

I was surprised by the news that trace JIT was removed from Firefox trunk. I hoped that it will grow and replace method JIT completely one day. Post from from David Mandelin explains details behind this  decision.

Method JIT works better than I expected

During my talk I stated that using config object (which e.g. jQuery plugins do) may break JIT and that the safest way is to use integer and float arguments only.

I got a very detailed description from Rob Brackett on how JIT works with objects:

Passing config objects to functions can often cause them to run slower — most engines use a concept of “shape” to JIT code related to objects (shape is basically the set of keys on your object, so {a:”a”, b:”b”} and {a:”c”, b:”d”} are the same shape but {a:”a”, c:”b”} is a different shape). The function will generally have to be JITed once for each shape that is passed in. Some engines stop re-JITing after they’ve seen a certain number of shapes (the threshold is different for different engines) and some do not.

My second statement, about integers and floats was based on NanoJIT capabilities. Since it was removed from Firefox with Trace JIT, I can now safely say that any argument type that fulfill static “shape” description above can be JITed.

Source: http://groups.google.com/group/jsmentors/browse_thread/thread/9286c04c908cd722

Reflow is blocking

I got a question, if reflow has been or could be moved to separated thread, so it won’t be blocking. The short answer is “no”. There are plenty of functions that depend on calculated result and it would require synchronizing very often. The list of functions that require reflow to be completed.

More

It was linked in my slides, but I’d like to say it again – read David Madelin’s slides Know Your Engines from Velocity Conf 2011. It’s the most detailed source about engines I’ve found so far.

I’ve asked some questions on JSMentors group, you may want to check it out.

Bonus: some photos from the event

My main topics were:

• Optimization in general
• DOM
• Reflow/repaint
• Garbage collector
• JIT
• Google Closure (Compiler/Tools/Library)

You can check my slides here. I collected plenty of links and wrote a few examples.

Feel free to comment and criticize. I’ll be happy to add anything that I’ve missed or to correct any mistakes. There are few good optimization resources and I had some doubts in few cases.

I’m not going to describe here how the Compiler works in detail. In short words, it scans your files looking for comments in a specific, JSDoc-like format and makes use of them. There is also a tool called calcdeps which is a linker – it scans files for dependencies and helps compiler to merge files in the correct order.

My project structure

To make it even more fun, I decided to write a Makefile which will be a final jaw-dropper.

PYTHON   = python
CALCDEPS = ~/closure/closure-library-read-only/closure/bin/calcdeps.py
CLOSURECOMPILER = ~/closure/compiler.jar

all:
	$(PYTHON) $(CALCDEPS) -p src -i src/init.js -o compiled -c $(CLOSURECOMPILER) > scripts/ai-bot-compiled.js

It works like charm, “make” is compiling all required files from src folder, merging them into one.
I was surprised how easy it was – calcdeps takes a path (-p) where you store all your libraries and an initial file (-i). The rest is based on goog.require(classname) and goog.provide(classname) calls from files. I barely used Google Closure Tools so far, but the Compiler is absolutely great!

Google Closure: http://code.google.com/intl/pl/closure/
Book: http://www.amazon.com/Closure-Definitive-Guide-Michael-Bolin/dp/1449381871

Asynchronous testing in QUnit

The most important part to understand is how to deal with code that is asynchronous. Consider this example:

test('addTwo test', function() {
   elem.slideDown();
   equal(elem.height(), 200);
}

In this very simple piece of code very common problem is hidden. There are plenty of such functions, related to animating elements, showing popups, highlighting, querying data, waiting for loading data and so on. They all share one concept – the call is made, function is working on something, but the rest of the code is executed at the same time. It’s considered to be very good – lets us code non-blocking scripts and provides means of creating very active content. But what we lose here is the ability to use a result of function immediately after its call. In this case, for test purposes.

Asynchronous – the good way

The good way of dealing with such code is a great example of why writing tests is so important. It always reminds me hacking – it forces you to think about all possible outcomes and to stretch your application to its limits. In this case writing tests shows what almost every plugin should have, an onComplete function. By providing it you may internally check if everything is finished and if other code may proceed. I decided that I need it when I discovered how long it takes for Google Maps to load markers with addresses instead of coordinates. This is a good practice that jQuery, jQuery UI and a most of other serious libraries use. Testing with onComplete function is simple:

test("map with address markers", function() {
    map = createNewMap();
    map.gMap({
        markers: [...], // some markers
        zoom: 12,
        onComplete: function() {
            data = map.data('gmap');
            ok(data.markers[0].getPosition().lat() && data.markers[0].getPosition().lng(), 'marker position correct');
        }
    });
});

This is a part of my gMap tests. Something is still missing here and you may have noticed. Using an onComplete function does not prevent code from moving on. Plugin init is called and immediately test function is finished. Depending on your testing framework it may still work, assertion will be called eventually and its result will be shown. The problem is, that meanwhile the state of your testing suite may change. You can see here, that my test starts with createMap() function, which clears old map and creates a new one. This is an obvious case where running two tests at the same time can’t work. QUnit solves it like that (explanation in code comments):

test("map with address markers", function() {
    map = createNewMap();
    map.gMap({
        markers: [...], // some markers
        zoom: 12,
        onComplete: function() {
            data = map.data('gmap');
            ok(data.markers[0].getPosition().lat() && data.markers[0].getPosition().lng(), 'marker position correct');
            start(); // let other tests continue
        }
    });
    stop(); // when the end of the function is reached, do not run any other test until start() is called
});

Asynchronous – the ugly way

The problems start when you are depending on some function that doesn’t support onComplete callback. For example, if you open an popup in Google Maps, animation takes some time but there is no callback (sorry for referring to maps all the time, but it’s what I know best). It makes sense from their point of view, as nobody sane would ever call anything when html is loaded to a popup. Well, but I don’t care too much about my sanity and I had to, so what now? This is quite long listing, but shows the popup problem described above.

test("infowindow", function() {
    map = createNewMap();
    map.gMap({
        markers: [
            {
                latitude: 50.083,
                longitude: 19.917,
                html: '<div class="test_marker">marker 1</div>'
            }
        ],
        zoom: 12,
        onComplete: function() {
            data = map.data('gmap');
            equal(data.infoWindow, null, 'infowindow empty');
            equal($('.test_marker').size(), 0, 'no .test_marker');
            google.maps.event.trigger(data.markers[0], 'click');
            window.setTimeout(function() {
                ok(data.infoWindow, 'infowindow set');
                equal($('.test_marker').size(), 1, '.test_marker present');
                start();
            }, 1000);
        }
    });
    stop();
});

The dirty hack here is calling a test in setTimeout. It works almost the same way as onComplete, except for the part where you have to guess how long may it take. You have to be very careful with that. If your guess is to low, your test may fail at random. Also you should think, whether too long execution time may affect normal user. If so, you should either document it very well or think about some other way of implementing it. Using our example, you may push the popup problem forward to the user and let him ignore it or fix it, or you may create another wrapper with onComplete callback. Considering performance and code length I usually choose the first option.

Accessing internal parts of plugin

A good plugin is not changing your global variables. It’s cool, but causes a problem when you want to test internal functions. Testing input and output of plugin is fine, but without checking some mid-results you will quickly find that finding and error is not as simple as we would like it to be.

Now, if you read something about jQuery plugin development you probably already have methods array and a nice dispatcher that lets you call $(selector).myPlugin(‘methodName’, arguments);. It seems like a perfect way to expose plugin internals and usually it is. But in case of testing it really isn’t. Keep in mind that these methods are useful AFTER initialization. There is really no good way of testing what happens inside, without any overhead. The options I considered are:

Debug mode

You may put in your config object an debug callback. Then call it in any place you want, like that:

methods = {
    _someInternalMethod: function() {
        // do something
        if(opts.debug) { opts.debug({
            //object with debug data
        }); }
    }
}

However, this makes your code look like crap and with big plugins every line of code counts. In gMap I use log option, but in a very limited way.

Use $.data()

This is something that I hesitated about for a long time. $.data() binds any desired data to your DOM element. I’m a performance freak, so it always gives me goosebumps. DOM interaction is very slow, can’t be compiled as far as I know and it’s always kinda weird. It’s against MVC, storing data in view when you want to use them in controller. However, jQuery plugins are usually designed to be stateless, or at least to hide theirs state. This is one of the fastest ways to expose your internal data and I use it sometimes. I’m not going to put any new example here, you can see use of $.data() in almost each previously shown. It requires some work to ensure that exposed data are always correct, especially when something internal changes, but here tests becomes handy and saves a lot of time. If you use $.data(), prepare a lot of them and check everywhere if it’s working. Also try to use the fastest method of data binding which is, at the moment, $.data(jQueryObject, key, value).

Turn your plugin into a builder

Builder is a very good design pattern. It works like a stack – you can add some config options with provided methods and call execute() or build() when needed. This is how I should have designed gMaps to begin with  and now with every version I introduce more and more functions for changing map setup. It’s very useful for both your users and testing.

Time for an overkill example:

test("changeSettings - fit new center", function() {
    map = createNewMap();
    var markers = [
                {
                    latitude: 50.083,
                    longitude: 19.917
                }
            ];
    var markers2 = [
                {
                    latitude: 50.083,
                    longitude: 19.917
                },
                {
                    latitude: 50.20917,
                    longitude: 19.75435
                },
                {
                    latitude: 50.502343,
                    longitude: 19.91243
                }
            ];
    map.gMap({
        markers: markers,
        zoom: 9,
        latitude: "fit",
        longitude: "fit",
        onComplete: function() {
            map.gMap('removeAllMarkers');
            window.setTimeout(function() {
                map.gMap('addMarkers', markers2);
                window.setTimeout(function() {
                    map.gMap('changeSettings', {
                      latitude: 'fit',
                      longitude: 'fit'
                    });
                    window.setTimeout(function() {
                        var center = map.data('gmap').gmap.getCenter();
                        ok(Math.abs(center.lat() - (50.083 + 50.502343)/2) < 0.001, 'center latitude correct');
                        ok(Math.abs(center.lng() - (19.917 + 19.75435)/2) < 0.001, 'center longitude correct');
                        start();
                    },1000);
                },1000);
            },1000);
        }
    });
    stop();
});

Here all mentioned methods are combined. One array of markers is added, then removed, second one is added and new center calculated. And the best part is that at the every mentioned stage you can add test coverage. I don’t do it, as I have separated tests for these things, but it’s possible.

This is probably the best way of dealing with testing and plugins in general. If you or your user at any moment would like to alter configuration, it is the proper way to deal with it. And I’m so confident about that, because for a long time I encouraged people to get Google Map object and markers from $.data() and manipulate them manually. It’s not very effective, it’s slow and forces user to know a lot about programming in general. Your users are not always newbies, but if they are, there is no way they could learn advanced stuff fast enough. Encourage people to find out how your code works, but never force them to do so.

Bonus: continuous integration

Just a quick note here. These are two very good tools that you can integrate with your git, or any other, not as good, version control.

JS test driver

The image is quite self-explanatory. You push your changes to the repository, JS Test Driver reads source and config, on its server multiple browsers are started, tests are runned and result is sent back. Simple and genius, you don’t have to start every browser manually and wait for test results.

http://code.google.com/p/js-test-driver/

Testling

Testling is built on the same concept, but is provided as an SaaS. You send test file in specified format to Testling via wget and you get your reports back. It’s a paid service, but provides a free account for limited CPU time (30 min, at the moment). If you don’t want to setup your JS Test Driver, which usually requires separate machine, try Testling.

http://testling.com/

Summary

This is the end of the series, I hope you liked it. On my github you can find code for the first two parts. For this one you have to download gMap and tests are here.

jQuery Mobile – szybko, tanio, prosto… ale czy na pewno?

Adrian Gadzina i Krzysztof Ścira opowiedzieli o swoich doświadczeniach z jQuery mobile. Prezentacja zwróciła uwagę na wiele problemów z którymi zmaga się projekt (obecnie w wersji RC1). Myślę, że na wyróżnienie (negatywne) zasługują ciągłe zmiany w API, ciężkie stylowanie i chwalenie się na wyrost kompatybilnością z wieloma platformami. Zobaczyliśmy kilka rozwiązań takich problemów, integracje z PhoneGapem i stylowanie elementów. Pod koniec prezentacji znajduje się kod QR z linkiem do przykładowej aplikacji.

Prezentacja (PDF)

Geolocation

Lidia Wilczyńska zaprezentowała krótko tematykę geolokacji. Dowiedzieliśmy się jakie metody działają a jakie nie w przypadku przeglądarek, jak wygląda obiekt pozycji, co można z nim zrobić i jakie metody używać do śledzenia zmian. Został też poruszony ważny temat prywatności w sieci.

Prezentacja (www)

Responsive Web Design

Tobiasz Glazar zaprezentował metody budowania dynamicznych systemów gridowych dla przeglądarek w zróżnicowanych środowiskach. Pokazał kilka problemów (i rozwiązań) skalowania obrazów i serwowania różnego contentu dla różnych ekranów.

Prezentacja (www)

Node.js – server side javascript

Maciej Jastrzębski zaprezentował podstawy node.js i jego testy przeprowadzone w Dreamlabie Onetu. Wydajność w porównaniu z Apache + PHP czy Tornado + PyPy była znacząco wyższa. Sam test był bardzo sprytny, zamiast hello world które łatwo cacheować, w teście użyto timestamp serwera aby content był odświeżany za każdym razem. Oprawa graficzna prezentacji jest świetna i dobrze wyjaśnia jak właściwie działa node.js i dlaczego może być o tyle szybszy w niektórych zadaniach.

Bardzo miłą niespodzianką był też mały press release ze strony Onetu – 1 stycznia 2012 Dreamlab uruchomi Onet.cloud, serwis PaaS, SaaS i IaaS. Prawdopodobnie część backendu będzie oparta właśnie na node.js.

Ta prezentacja wywołała zaciekły flamewar długą dyskusję, argumenty obu stron wyglądały mniej więcej tak: pro1, pro2, con1, con2. Konkluzja – node.js jest jeszcze mało dojrzały, ma niewiele stabilnych i dobrych pakietów (pomimo gigantcznego repozytorim npm), ale w wyspecjalizowanych zadaniach jest bardzo szybki i wart użycia.

Prezentacja (pptx) Polecam też post o node.js na blogu Dreamlabu.

Asynchroniczna pułapka

Meet.js został zaplanowany tak, aby poziom trudności kolejnych prezentacji był lekko rosnący. Gdyby jednak chcieć umiejscowić prezentację Piotrka Koszulińskiego w odpowiednim miejscu, musiałaby być siedemnasta, może osiemnasta w kolejności. Ilość i poziom kodu na slajdach zwalała z nóg, ale dla wytrwałych nagroda była wielka. Piotrek pokazał problemy które spotykamy (głównie korzystając z node.js) przy funkcjach wywoływanych asynchronicznie. Funkcje które powinny być wywoływane równolegle lub sekwencyjnie tworzą zazwyczaj przerażająco zagnieżdżony kod, pełen callbacków i nadmiarowych linijek. Lekarstwem na to mają być biblioteki które ostatnio mnożą się na githubie. Piotrek pokazał bliżej dwie – async i deferred, które systematyzują i upraszczają najczęściej spotykane struktury.

O ile async był prawdopodobnie dla wszystkich zrozumiały, o tyle deferred jest oparty na bardzo magicznych właściwościach JavaScriptu i dla niewprawnego oka wygląda strasznie. Po spokojnym przejrzeniu kodu widać elegancję takiego rozwiązania, więc polecam to wszystkim.

Prezentacja (www)

Konkurs

W czasie meet.js zorganizowaliśmy mały konkurs na najlepszy pomysł na grę w przeglądarce. Po dogrywce nagrody zdobyły dwa pomysły:

• miejsce I i wejściówka na Front Row Conference od Lunar Logic Polska – Angry Nyan Cat, Jacek Złydach
• miejsce II i książka “The Essential Guide to HTML5: Using Games to learn HTML5 and JavaScript” ode mnie - Sokoban QR, anonimowy uczestnik (proszę o maila jeśli ktoś zna )

Blog-O-Ben – tutorial

On his blog Ben (I couldn’t find his full name) is posting a series of lessons about WebGL. It’s similar to learningwebgl.com, but it’s explained and structured very well. It involves some basic awesome math that anybody willing to work with 3D simply has to know. For the time being it covers six topics:

• Context in canvas
• White 2D triangle
• Rotating triangle
• Wireframe 3D object
• Full transformation matrix
• Torus-shaped strip (types of draw call explained in the example)

It is exactly what I was looking for – very thorough and not avoiding difficult parts. I hope it will grow soon and cover more topics. For now it is about less complex things that those covered in learningwebgl.com, but it’s a great way to start.

A3 – new rendering framework

While I have almost nothing to say about A3 itself (but I’ll dig into it), I would like to point your attention at videos on framework page. They show how the engine was designed and they are really worth watching. There are only two for now – introduction and vectors – but I’m waiting for more! It’s like 101 course to 3D engine math with examples in JS and some important explanations. Also, a guy who records them is a little bit crazy, so it’s fun to watch.

http://aerotwist.com/a3/

So, that’s it! Two websites, one for hardcore math nerds and the other one for fun math nerds. Check them out.

UPDATE:

It’s not pure WebGL, but if you are lazy and not willing to ever write your own engine, go with three.js, basic tutorial for it and then http://learningthreejs.com/ for further ideas.

Among other countries (Norway, Finland, Denmark, Sweden) which already have passed this limit, we are the first with over 10M internet users.

«Die IE6, DIE!» By Mike Rohde (rohdesign.com). Sous Licence CC.

But before we could open a bottle of champagne, take a look at our local, not-so-optimistic statistics. IE6 still has around 1.5% and IE9 has only 3% of the market. This numbers are improving, as more and more people move from older versions to IE9 or to better browsers but still, only 3%? Microsoft, it’s really time to force (or at least strongly encourage) browser updates.