As a big fan of history, specially military history, I’d like to begin this article with a story. You’ll see why in the end, but in the meantime, bear with me.

When Franz Ferdinand, the Archduke and heir to the Austrian-Hungarian throne, was assassinated in Sarajevo on a 28 of June of 1914, Germany was put between a rock and a hard place.
For one, from a strategic point of view, its generals knew that, after the assassination of its leader, the Austrian-Hungarian empire was bound to declare war on Serbia (eventually), and if it did, it would force the Russians (which at the time were allies with the Serbians) to declare war on the Austrian-Hungarian empire; If that occurred, Germany, as one of Austria-Hungary’s most important allies, would be forced to enter war with the Russians as well, and if this happened, the french, which were also allied with the Russians, would also be forced to declare war on Germany.

Comment: It’s not like the French need much of an excuse to attack the germans, or vice-versa, but that’s a story for another day. But if you’re interested in learning more, Google why the French call Germany “Allemagne” and why France is called… well, “France”. Long story short, the Alemanni and the Franks were two germanic tribes that hated each other.

But we went way off topic, so let’s resume the story.

While we talk about this, we also need to keep in mind that in the geopolitical map of 1914 that meant that Germany had enemies on both its west and east limits. They were paranoid about being attacked because they literally had no way out of the conflict; Otto Von Bismarck, arguably one of the most effective diplomats of the 20th century, had died 16 years ago (in 1898) and Germany’s leader at the time, Kaiser William II was… “incompetent” to put it mildly. While good chap Otto might have been able to talk and negotiate his way out of this conflict, William II lacked the abilities and talents of his predecessor.
German generals knew this, so they started thinking in alternative plans and, against all odds, found out that in reality, they were in a unique position to go “all in”. While you may find it strange that I reference a phrase most commonly used in a poker game, if you’ve been following the story so far you’ll notice that, from a different vantage point, there’s “no way out” for Germany–They’re being forced to fold and leave Austria-Hungary to resolve its dispute with Serbia (and Russia, and France) on its own. In such scenario, they would probably lose and get ‘conquered’, or its leader would be replaced with a French or Russian puppet, and if that were the case, instead of 2, Germany would now have 3 enemies on its doorstep: Russia on the right, France on the left and Austria-Hungary on the South. And then… it was just a matter of time until they were next on the list.

Under such grim context, Germany’s options were… let’s just say… limited.

However, this strategic situation wasn’t entirely unexpected by the germans. Considering the fact that the german empire was relatively new (it was officially founded in 1871, or to put it in perspective, it had only existed for 43 years in 1914–not even a generation ago), the German General Staff had devised a plan to fight a war in what the military refers to as “two fronts” (that is, one of the left—France—and Russia on the right). Originally, the plan had been created by Alfred von Schlieffen, and later on was modified by Moltke the Younger (Chief of the German General Staff) to update it to the current circumstances of the day.

This plan was called “The Schlieffen Plan”.

Also, we also need to consider that, at the time, Germany’s growth was phenomenal. It had great music, brilliant scientists, marvellous artists, a GDP that was one of the biggest in Europe, and one of the most powerful armies in the world. Best of all, it had managed to do this in just 41 years!

Even though their military strength was utterly impressive, they knew that they would never win a pincer strategy by the French and the Russians. But they knew that they could win a one-on-one fight with either armies.

In essence, what the Schlieffen Plan dictated was that, if they could beat either armies fast enough, they’d have enough time to turn around and fight the other side one-on-one. They also estimated that, due to Russia’s vast land size, it’d take them around 950 hours to rally all the troops and take them to Germany. That meant that Germany had only a “window of opportunity” of just a bit more than a month to beat the french and get back to the east of Germany to fight the Russians.

 

 WORK IN PROGRESS 

At one point or another, any developer worth its salt has had to write a bit of SQL. While ORMs such as Hibernate, NHibernate or Doctrine saves us from having to write long, complicated queries–favouring a more object-oriented approach instead–sometimes this is simply inevitable.

So, if you're not familiar with the syntax, you'll probably fire up a browser and head to the 'documentation' section of your DB vendor of choice, such as MySQL, SQL Server, Oracle or PostgreSQL where you'll see things such as:

// Example from PostgreSQL.org
SELECT f.title, f.did, d.name, f.date_prod, f.kind
    FROM distributors d, films f
    WHERE f.did = d.did

Or

// Example from Oracle.com
SELECT EMPNO, LASTNAME, WORKDEPT, DEPTNAME 
     FROM SAMP.EMPLOYEE JOIN SAMP.DEPARTMENT 
     ON WORKDEPT = DEPTNO 
     AND YEAR(BIRTHDATE) < 1930

The title of the talk is "Tracy: A Minimalistic, CSS-Powered 3D Rendering Framework". If you're interested, here are the slides.

Over the course of my career, I have been very fortunate to work with many creative and talented UX/UI and Visual designers that were able to come up with great solutions to very complex problems. Luckily, I still do. But whereas many of my creative colleagues have kept the pace with the advances of technology, it'd seem to me that others are struggling to design responsive websites properly.

Understandably, keeping the pace with the advances of technology, specially web technology, can become overwhelming - specially when you need to practically change your entire set of tools and the way you work every 2 or 3 years (if you want to keep up to date, obviously, which some people decides not to do).

While this sounds daunting, there are certain things that always remain the same. Rules that remain unchanged throughout time and that we can consider set in stone. We'll refer to these things as the "foundations".

One of such 'foundations' is the way browsers accomodate content and the way it "flows" inside a page (bear with me on this, I'll explain it more eloquently later on). That hasn't changed at all. Actually, it works exactly the same as it did 15 years ago. As long as we keep that in mind, anything new that comes out today, or five years from now, will be built on top of these concepts.

Additionally, besides the 'foundations', we also need to be aware of the 'limitations' of web browsers which we'll have to consider when designing or developing a responsive website. Hopefully, by the end of this article you will be able to learn, identify and understand both, and more importantly, you will learn how to design websites in a way that will make you very popular with your nerdy web-development colleagues.

In its most elemental form, particle systems are composed by two main objects: A particle object, which will represent every individual particle, and a generator, which will generate particles themselves.

For the sake of simplicity we're going to approach some things unconventionally. In reality, a particle system can be an inmensely complex system.

So what exactly is a "particle"? In computer science and game development a particle could be described as a small localized object that stores physical properties, such as volume or mass, and dynamic properties such as its position in the X and Y axis (and also Z, if you're working in 3D) as well as its velocity in all two or three axis.

The main purpose of a particle generator is to generate the particles themselves (well, D'Oh!) and to control some properties about the generation, such as the number of particles to generate, their initial speed, spread, etc.

This two definitions will form the basis of our particle system, so let's translate them into a practical and real-world context.

At R/GA Buenos Aires we have an strict hiring process, specially for Open Standard Developers (frontend developers). One of the very first questions that we ask in our technical interviews is how to get the even numbers of an array using JS. Obviously, if you can't answer that extremely basic question we assume that you won't be able to tackle more complex problems.

Some people believe that public speaking is an ability that only a few "chosen ones" can execute well. While I personally don't consider myself to be a great public speaker, I do think that anyone can become one. While the ability of being charming, engaging and persuasive comes naturally to some people (think Steve Jobs), I strongly believe that these are traits that can be learned and, more importantly, perfected over time - case in point, Mark Zuckerberg. His first talks were, for a lack of a better term, utterly pathetic, and he seemed to be unprepared and very nervous all the time. Over time he became more confident and his last talks were just brilliant.

One of my favorite hobbies is watching talks or speeches of people that are extremely passionate about the topic that they are talking about, specially in the realm of technology. However, I have noticed that many of my collegues in software development lack one very important trait: Most of them, almost never use gestures.

As an italian descendant, and just like most italians and argentinians, I use gestures all the time when I speak, sometimes excessively (which is a bad thing), whether in public or in private. To me, gesturing is an extremely important tool, if not essential, when trying to convey a message to an audience - any audience - technical or not. You can think of it as a second language that augments and amplifies whatever it is that you're talking about, and in some cases, the only way to get the audience to really "understand" what you're talking about, or to get them to believe your message is by performing the proper gesture at the proper time. You probably know the idiom "a picture says more than a thousand words". Gestures work in the same way.

 

#1 Link outlines / highlights are misaligned on the Kindle Fire
#2 Semantic clearfix without using "clear: both" in another element
#3 Extremely low performance with the Picturefill polyfill
#4 'Multiple Class' CSS selector bug in Internet Explorer 6
#5 'ID + Class' CSS selector bug in Internet Explorer 6
#6 Box model problems in IE 5.x and 6
#7 FOUC (Flash of Unstyled Content) in Internet Explorer 6
#8 Making IE 5.x ignore a particular CSS Rule
#9 Flashing text when using CSS3 Keyframe Animations and translations in the Z axis
#10 Transparent PNGs in IE 6
#11 Removing outlines / highlights on links in mobile browsers
#12 Orientation change zooming bug in iOS
#13 Stack overflow / Memory problems on IE 7 when using Respond.js v1.1.1 or lower
#14 WebKit ignores the background colour / image of an element when printing the document
#15 Disable the dialogs that show up when you tap on an item for too long on mobile browsers
#16 Customising a page added to the Home Screen in iOS
#17 Custom attributes on iOS (Auto Capitalisation, Auto Correct, Auto Complete, Auto Save)
#18 Remove the dotted outline of select boxes in Firefox
#19 IE7 is not showing PNGs at all
#20 When you change the opacity values, PNG images 'break' on IE6 / IE7

Whoever has seen me working knows that I'm a big fan of customising my tools, specially when it comes to the colours and themes. To give you an example, my vim setup (which is very similar to Mozilla's Paul Rouget's) makes vim look closer to Sublime Text 2 than to the "conventional" vim:

Now that Custom CSS Filters landed in Chrome, I thought that I'd be a good idea to make a small introduction to these things called "shaders" for conventional web developers that are not familiarized with the term (but, unfortunately for them, they'll eventually need to learn how to make or at least use one in the near future).

I'll try to keep this article simple, so bear with me.

Usually, if you read about shaders you'll notice that people talk about "vertex shaders" and "pixel" or "fragment shaders". So what are they? How do they work? And what are they for?

To be perfectly honest, I've attended and spoken at many events, but onGameStart definitely joined the Top 5. As Andrzej Mazur said in his blog, Michal Budzynski deserves an standing ovation, from both speakers as well as attendees. He really is an excellent host and an overall great person.

I arrived to Warsaw on Monday after an 18-hour flight with one stop in Rome, unfortunately the jetlag took over and I didn't have time to roam around the city as I feel asleep the second I entered my room at the excellent Metropol hotel. Michal was actually kind enough to pick me up at the airport and took me to the hotel, we exchanged a couple of words and he went back to work - I can only imagine how hard it must be to organise an event of this magnitude.

As it was my first time in Warsaw, and in Poland, on tuesday I woke up early, had some breakfast and started to walk around the city, where I had the chance to take some pictures of the place. Compared to other cities in Europe (such as Rome, Paris or Berlin), Poland is extremely cheap, specially for things such as food or clothing. At noon I had lunch at a british pub, where I ordered a pint of Guinness and some fish and chips. After lunch I went to the Palace of Culture, the tallest building in Poland, where they were showing a Leonardo Da Vinci exhibition. While the exhibition was a bit dissappointing (they didn't have any original artwork, just pictures) I hopped into an elevator that took me to the top of the building which also allowed me to see the whole city from above - if you ever go to Warsaw you must go there, trust me.

On Wednesday I had the chance to meet some of the other speakers, and to greet some people that so far I had only talked with through Skype or G+ Hangouts. I was extremely amazed and a bit jelous of the level of knowledge the other speakers had and many times I found myself surprised, humbled and extremely privileged to share the stage with these lads. All of them were "World Class" developers.

Very recently, a friend of mine referred me to this article in which Wooga (developers of Pocket Island) outlined 3 technical 'limitations' of HTML5 (on mobile devices) that, to their opinion, prevented their game from being succesful. I must admit that, as an HTML5 Games developer, that article left a bit of a sour taste in my mouth.

In essence, what they said was that:

• HTML5 Games took a long time to load
• Users expected HTML5 Games to behave exactly like native apps
• HTML5 Games on mobile devices had many problems reproducing sounds

Their premise was that these limitations prevented their game from being a 'hit'. What's even worse, the article states that "Despite the fact that Adobe seems intent on killing Flash, for many game developers, Flash is still a necessity".

As an HTML5 evangelist, I feel obliged to debunk some of these points and misconceptions.

Just very recently, one my readers sent me a mail asking which was the most efficient way to add support for day/night cycles in tile-based games such as in Tourist Resort, the final project of my book. I promised him that I'd try to write an article about this, so here it is.

By day/night cycles, I'm guessing that he was referring to the fact that as the sun sets, the tiles should get darker, and when the sun rises the tiles should get lightened up.

Before we discuss how to achieve that effect efficienty, we first need to talk about lights.

Ok sports, gather around. I want to tell you a story. A long long time ago, on a planet not so far away, the Internet wasn't as incredible as it is today. Actually, unless you wanted to keep yourself informed (by reading news, etc.) or to get in touch with other people via email or BBSs there wasn't much to do either.

I'm not going to lie to you, I'm not that old, but before the internet existed if you wanted to keep yourself entertained by playing a videogame you could either get yourself a computer such as a commodore 64, or a Sinclair ZX Spectrum, an Atari, etc. and a game or if you didn't have the means to own any of those, you could go to an arcade room.

EDIT: Google Plus doesn't allow you to embed public videos in external sites. Added links to the posts instead.

In case you haven't heard, as i expect none of you to do, i've been keeping myself pretty busy by working on an easy-to-use, minimalistic CSS-Powered 3D Framework called "Tracy" (Three-Dee + CSS + Crazy, don't tell me it doesn't make perfect sense).

I had experimented with 3D CSS before, but i really wanted to see if i'd be able to make a Wolfestein clone using this stuff as all the elements to make one were certainly there.

WORK IN PROGRESS, DON'T SHARE JUST YET!

In case you didn't know, last week PopCap launched a WebGL-powered version of its famous game, Bejeweled (click here to play it). The port looks and works exactly like the original game as well, which is pretty nice. However, there are two problems with using WebGL that they could have avoided by using the approach that we'll be using in this article. First, is that the game doesn't work in Internet Explorer (as IE doesn't support WebGL) and second, is that obviously the game won't work on mobile devices.

When I wrote my "Let's make a Snake Game" article I stated that many 2D games can be solved by using a two-dimensional matrix, and Bejeweled is not the exception. If you really think about it, Bejeweled is just an 8x8 matrix filled with different indexes (numbers). The objective of the game is to align 3 or more rows or columns with the same index. When a row or a column of indexes is deleted, new indexes are added to the matrix to fill the empty places as seen in this GIF, and here's a visual representation of how the matrix looks like, which will give you a better idea of how it works:

However, you will notice that the initial grid is not completely random and instead have some pecularities in the initial matrix generation algorithm that equally distributes indexes always considering that at least one or more moves are possible. which is why (if you pay attention) you'll notice the emergence of some of the following patterns:

 

You'll also notice that you won't find groups of 3 or more elements with the same index anywhere on the matrix. While replicating the exact same algorithm used by PopCap in Bejeweled is outside the scope of this article, we can get a pretty decent replica by generating the matrix in three steps (the matrix is just 8x8, so performance efficiency is not a concern, really, besides... i'm trying to keep this simple).

The first pass will traverse the matrix column by column, starting on the first row (from the top left to the bottom right) generating a random index number between 0 and 6. If, while traversing the columns, we find that the current position minus 1, and the current position minus 2 are equal to the current random number, we'll assign that number to the current position plus 1, and generate a new random number to place in the current position instead (that of course, has to be different from the one we have right now).

Once we get to the bottom row and the last column, we'll start the second pass in which we'll start traversing the matrix top, down from left to right, just like we did in the first step. The objective of this pass is to avoid having groups of three or more elements aligned vertically. In case that we do find one, if we're located on a column index equal or less than 3, we'll move elements to the right. If our column index is greater than 3, we'll move elements to the left.

The last and final pass will be executing our index matching function, which we'll also use when the user makes a move.

WORK IN PROGRESS.

Many times I've seen developers go nuts to either: A) Find a map editor that can adjust to their game, B) Adjust their game to a predefined format exported by a map editor or C) Decided to make their own map editor.

Truth be told, map editors are extremely useful tools that can help us ease the development of levels for our game, but in practice, most of the time map editors are just grid editors that basically translate that a given graphic corresponds to a given tile type. While it's true that some of them also supports adding additional properties to each tile, in the most basic form that's all they do. Their sole purpose is to ease the creation of levels.

Some time ago I decided to make a small shooter game and had to pick one of those 3 options. After I carefully considered all three, I said to myself "I don't need all this mumbo-jumbo" and like most developers I convinced myself that I could get away by making my own solution, so I set to it and half an hour later I had a working sample.

Back when i started developing the final project for my book i needed a simple but reliable way to preload assets such as images or sounds. I also intended to show a nice progress bar indicating... well, the progress of the load. I finally settled on developing a somewhat short, simple but efficient class called ResourceLoader that could handle images and sounds but can easily be extended to support other media types, such as videos, or JS scripts.

Using it is pretty simple, too. You just need to do:

var rl = new ResourceLoader(printProgressBar, function() {
    alert('Preloading complete!');
});

rl.addResource('image.png', null, ResourceType.IMAGE);
rl.addResource('music.mp3', 'audio/mp3', ResourceType.SOUND);

rl.startPreloading();

function printProgressBar() {
    var percent = Math.floor((rl.resourcesLoaded * 100) / rl.resources.length);
    // Use the percent variable somewhere in your game/app.
}

The complete code for resourceLoader.js is available on GitHub. 

Before we continue, i'll assume that you're using a modern web browser that supports HTML5, such as Chrome, Firefox, Opera, Safari or Internet Explorer 9/10. If you're not, i strongly recommend you to download any of them, otherwise you won't be able to try the examples.

I'm pretty sure we all know (and have played) this famous game about a snake that gets longer and longer as it eats small dots that show up randomnly on a map. It's fun and engaging so it makes it a fun little project to learn how to do game development using HTML5 and JavaScript.

So let's get started, shall we?

To mom: For teaching me how to read at such a young age. For teaching me how to be creative and to "live in the clouds" (AKA, being a dreamer). For all the love. For being my best friend for 21 years. For spoiling me by bringing those delicious sandwhiches to my desk on my 20-hour-long development/gaming sessions. A long time has passed, but i still miss you like i'd have lost you yesterday. May God keep you safe up there.

To dad: For teaching me how to think and view the world like an engineer. For explaining me how the world works, with luxury of details. For never getting tired of answering all my incredibly specific questions, and instead, embracing my curiousity. For being strict, and teaching me discipline. For buying my first, second and third computers and paying for the repairs when i fried the CPU back when i was learning ASM, which finally led me to meet one of my best friends. For teaching me that when life kicks you in the balls, you need to get back up and continue walking.

To my fiancee: For being my best friend, ally and partner in crime. For being patient with my extremely time-consuming endeavors and helping me keep my feet on the ground. I'd surely be on the street without your wise advices. For being there every time i needed you. For all the love you give me every day. For making me smile again every time that tragedy striked my life.

To my grandfathers and grandmothers: For teaching me that if you're willing to work hard enough, the sky is the limit. It doesn't matter where you started, both of you are proof of that. Also, for teaching me that my word is more important than any piece of paper. For teaching me to be decent, hard working and honourable.

To my friends and the rest of my family: For caring for me. For all the moments and experiences we've shared together so far.

To my former bosses and coworkers: For all the stuff we've worked on together over all these years. For making me love my profession every single day of my life. I still remember every single one of you.

To O'Reilly: For publishing my book.

To everyone at #BBG on irc.freenode.net: For being a constant source of inspiration and admiration.

And finally to you: For reading this blog.

Thank you.