Author Archives: Nicolas Bize

The Best IDE in the World

First of all, I apoligize for the lack of recent posts. Brushing up things for the Qualys Security Conference took all my free time away for the past 3 weeks. I really want to get back on “the one quality post per week” rhythm so expect more things coming your way in the future!

One of my most memorable experiences in software development occured to me about 8 years ago when I started working for Airbus. I was fresh out of college, all pumped up with my master’s degree in network engineering. I had been swimming in code for the past 15 years (though it was mostly self-learning and small hobby projects) and therefore thought firmly with boasting over-confidence that I was an amazing coder. The truth is… I was clueless about how to produce great, maintainable code. The main issue with someone that is overcome with pride is that it always finds itself faultless, rejecting any type of failure onto something or someone else. For me, 8 years ago, it was always Eclipse’s fault.

In an effort to trend towards open-source usage and cost reduction, Airbus had started shifting most of their software development from C++ and VB/C# to the Java world. Most of the code and testing was also slowly shifting from internal development to outsourcing. I entered Airbus in that period of transition, and downloaded Eclipse for the very first time in 2006.

As an advocate of Microsoft products, Visual Studio was to me the pinacle of the IDEs, making the transition to Eclipse incredibly painful. It was slow: autocomplete would take multiple seconds, it would often freeze… The integration with maven was never working. The layout was awkward. Spell-checking ON but line numbers OFF as defaults?! I was repulsed by it. Everything about it made me feel like it was created at the time when dinosaurs were still on the earth. I hated it with my life. In fact, I hated my job for having to use Eclipse. I was a miserable coder who knew deep inside that it was all Eclipse’s fault. I thought that things would get better with the days, but they didn’t. I kept dreaming about creating the site http://www.ihateeclipse.com/ three years before it was even born.

Two weeks had passed, and then came along Ludo, a whiz kid about 5 years older than me down the hall from me. He had heard me curse at the IDE and asked if he could help. I replied with assurance: “Pff there’s nothing anyone can do about it, it’s just Eclipse who’s being a piece of *junk* once again. I’ll fix it.”. He then asked: “What do you mean once again?” after which I started a 10 minutes whining about how awful Eclipse was and how slow it made me as a coder. I was trying to fix a bug and Eclipse was just throwing random errors.

He listened carefully and then asked if he could take a look at the issue at hand. He picked up a chair and I gave him my mouse and keyboard. Ludo then started typing extremely fast, opening up the preferences, changing a bunch of options, tweaking memory usage, server settings, etc. His hands never left the keyboard. All of a sudden everything on my computer, Eclipse included, seemed so fluid, so fast and so responsive. For each specific action, Ludo knew the exact procedure, the right shortcut. The dialogs would open up and close within seconds. Within a few minutes, he had identified the issue, fixed it, tested it and commited the fix. Before leaving, he said: “Eclipse is just another tool. They are only as sharp as you decide them to be.”

I was blown away and became transformed by that experience. Back with my keyboard and mouse, Eclipse seemed slow again, but now I knew that if I learned how to use the tool well, it could be extremely powerful and fast. And not just Eclipse, but every other tool as well! My OS, my text editor, my browser… Everytime I went back to Ludo’s desk, he was only working through emacs and a linux terminal, something I had never thought possible before. But he had mastered those 2 tools to perfection and was faster at producing efficient code using them than with any other tool.

With the years, I have come to master a small number of tools. For example I know all the shortcuts in Photoshop, I am fluent in Visual Studio, I never use the mouse in Eclipse, I use my own Sublime Text plugins and hand-made extensions in Chrome’s dev console. Just like learning to play an instrument, mastering any tool is hard and requires dedication and a lot of time. I have tweaked Eclipse and Visual Studio in so many ways that not a lot of people can use my instances without feeling that they are a bit awkward. I have modified/treasured the tools in a way that they have become a part of me as a coder. I improved my typing so that I could be fully efficient in both french and english using any type of keyboard layout. And with the years, I have come to the conclusion that one of the best ways to become a better coder is to learn to master the tools that you use. And this is not a learn-everything-in-24-hours type of thing.

Even today we still see a lot of open debates about Eclipse vs Netbeans vs IntelliJ, about .net vs java, about rails vs django vs laravel, the eternal conflict of PC vs Mac, etc. And seeing a title like “the best [insert any word here] in the world” is enough to bring people to frenetic behaviour. To those who seek which tool is better, I want to quote again from the amazing and inspirational coder I met at Airbus 8 years ago: “Tools are only as sharp as you decide them to be”. Now pick an IDE, a browser, an editor that you feel good with, and go master it. Make it your own. Make it the best tool in the world.

The Oyster Effect In Software Engineering

Studies have shown that people value the products they own by how difficult they were to obtain. Things become more valuable when a sacrifice of money, time or energy was provided in exchange. This notion has given birth to hundreds of marketing techniques. This week for example we saw how the organized limited stocks in Apple’s new iPhones generated lines of thousands of fans accross the world. Even if you thought the phone was expensive, the mind somehow justifies the value and price when it sees how difficult it is for someone to actually purchase a brand new iPhone 6.

This marketing tool is used throughout many fields, including product packaging itself:

We’ve all been there… You buy a product and then spend minutes of frustration trying to open a package, using objects at hand such as nails, teeths or car keys, cutting yourselves on the plastic edge and bleeding to death while cursing out loud at the engineers and designers who came up with such a horrible packaging idea…

It turns out that because the package creates a frustration, the achievement of opening it provides a reverse satisfactory effect that continues throughout the initial usage of the product. This marketing technique is one that the French call the Oyster Effect, even though it only makes sense if you like oysters.

Well, I have now grown weary of such practices. In a world where the most valuable resource has become time, I feel like wasting time on opening a package or learning how to use a counter-intuitive product makes the product more expensive than its price tag states. In the equation, I feel like the Oyster Effect actually brings out more negative than positive.

Last week, I downloaded an app to sync up my electric car. After downloading it, I had to register the product before using it. I then had to go through an online 2-pages signup / confirmation process. I then had to set up the default settings. I then had to go through an initial tutorial. Finally I had to figure out how to sync up the car, entering lots of long alphabetic strings of random characters (think UUID) on a tiny keyboard. The whole process took me about one hour. All those steps were time-consuming. It was like trying to find the right scissors to cut through the package. Every step was enforced without any possibility to skip them, using a combination of ackward design and horrible usability before I could even have the app running. It only left me with a sour taste and a sense of frustration for the app itself. And yet I hadn’t even started using it.

One of the most challenging exercice is to ship software in a way that people can use it right away and feel right at home the second it starts.

While there are a lot of guidelines on how to achieve this, here are five that I like to follow whenever I ship a new feature or product:

Give access first. Ask for configuration later.

Noone wants to take some time configuring something they simply want to try out. Keep signup forms to a minimum. Prefer reusing accounts to storing new passwords.

Don’t do this:

Always provide logical and non-obtrusive default options.

If you ship a programming IDE, make sure you ship it with spell checking OFF and with line numbers ON… Do not subcribe your users to anything unless they have desired to do so…

Don’t do this:

Make your software intuitive

Don’t attempt to revolutionize the standards by coming up with another icon for the Save button, or by remapping the shortcut keys that everyone is used to…

Don’t do this:

Aim for simplicity.

Limit the number of clicks required for each action. Keep the displayed information to a strict minimum.

Don’t do this:

Allow for flexibility

Provide advanced options / configuration to provide for all the other use cases you took out when refining the step before.

This week-end I played The Stanley Parable. For those who haven’t tried it, it’s an amazing experience that I don’t want to spoil. But besides providing an awesome game, the guys at Galactic Cafe provided a perfect example of simplicity, intuitivity and usability that you experience as soon as you start the game for the first time. It only takes a few seconds from the time you click Play on your OS to your first Wow.

The main reason why we create software is for our users to use them and enjoy them. The less is required of them to use the products correctly, the better the experience for both the creators and the users. As the French poet Antoine de Saint-Exupéry stated 75 years ago:

It seems that perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Look at your Old Code.

The internet is filled with questions regarding how to become a better coder. And the answers are pretty much the same: read books, do peer reviews, participate in open-source projects, etc. All those are excellent answers, but one issue that remains unanswered is how to measure your improvements as a coder throughout time.

One thing that I always encourage peer coders to do is to archive all the personal code that they write, no matter the language or subject. Put it somewhere safe (ie. git/svn) and keep it as long as you can. Then once a couple of years have passed, take some time to look at it. There is nothing more gratifying than looking at some old code and thinking: “OMG my code was so stinking awful!!”, nothing more satisfying than executing old handmade programs and games.

For example this past week-end I was looking through my archives from 7 years ago and found an old fizzbuzz.rb file laying around with some other ruby source files! I was pretty excited to look at it since I’ve never been a huge fan of it:

# I am part of the chosen 1/200th!!!! :)
# http://blog.codinghorror.com/fizzbuzz-the-programmers-stairwa
y-to-heaven/
(1..100).each{|i|
    if i % 3 == 0 && i % 5 == 0
        print 'FizzBuzz'
    elsif i % 3 == 0
        print 'Fizz'
    elsif i % 5 == 0
        print 'Buzz'
    else
        print i
    end
}

It still executes fine:

$ ruby fizzbuzz.rb

12Fizz4BuzzFizz78FizzBuzz11Fizz1314FizzBuzz1617Fizz19BuzzFizz22
23FizzBuzz26Fizz2829FizzBuzz3132Fizz34BuzzFizz3738FizzBuzz41Fiz
z4344FizzBuzz4647Fizz49BuzzFizz5253FizzBuzz56Fizz5859FizzBuzz61
62Fizz64BuzzFizz6768FizzBuzz71Fizz7374FizzBuzz7677Fizz79BuzzFiz
z8283FizzBuzz86Fizz8889FizzBuzz9192Fizz94BuzzFizz9798FizzBuzz

No major WTF moment. I looked at my code and actually had a couple of positive thoughts:

– I’m glad I put a small comment in there, it helped me remember that I wrote this code after having read Jeff Atwood’s article back in February 2007. This was the first time I had read about it and my reflex was to put it to the test.
– The code gives out correct results.
– The code is pretty readable.

And now I was also glad that 7 years later, a couple of things jumped out at me:

– The if conditionals can be rewritten so they are more readable
– The modulo math operations are performed twice
– The code has a bunch of magical numbers 1, 100, 3, and 5, preventing any easy change in the problem text.
– Nothing is tested

In a couple of minutes, I knew which parts of the code I could improve. Some of the stuff that I didn’t know about 7 years ago had now become reflexes. I then proceeded to write my new perfected version of FizzBuzz and hope to look at it in 7 years.

You never realize how much improvement you’ve made as a coder until you’ve looked at yourself as a coder a few years back. It lets you become the user of your own creations, and it usually brings back some fond memories. A month ago I fell upon this game I created back in college 10 years ago and had a blast finishing it even though it has many bugs (don’t try to skip the intro!!):


You can try it here: ICWars Java Web Start
(self-signed, might trigger some security warnings)

(In game: arrows to move, space to shoot. In starport: arrows to move, enter to select)

Your old code shows your creativity, your weaknesses, your strengths, your evolution and your improvements. It helps you stay humble and patient towards others coders. It’s your history in the byte world. It is precious. I urge you to keep it safe.

 

Creating Better Wheels

Back in february 2013, I was at a clumsy hotel in the business heart of Paris, La Defense, for a week while visiting Qualys’ French headquarters. The golden rule of supply and demand over there drives the prices crazy and I felt robbed as I entered the tiny, smelly and loud room that my company was paying 250$ / night for. A beautiful view on the hotel 20 feet away next door, freshly stained carpet, and exquisite torn tapestries. The final blow came when powering up my laptop and realizing that the wifi signal was like a distant whisper, too weak to be used though it had been paid for… After being disconnected numerous times within the first minutes of usage, I gave up.

I had been working on a side project for the past couple of months and had run accross the simple need to have a multiple selection combo box in tune with Bootstrap. I had spent a couple of hours trying to find or play with the closest solutions to my needs (chosen, select2, textextjs, etc) but I was not satisfied with the lack of configuration options. At the time they would all come short of the features I needed: some didn’t allow you to create free entries/tags, all had static layouts, the quality of the docs matched the one of my hotel room (they have all improved on this since), and it was a pain to achieve a pixel-perfect visual with Bootstrap. I had always been told not to reinvent the wheel but as I attempted to work with the existing tools I realized it might take me less time to actually rewrite a plugin from scratch.

A clumsy place with no internet and a poor TV programming for 4 nights was just the perfect moment to create my combobox. I designed it from scratch, with the inspiration of what had been done for the other plugins. It took me about 8 hours to get something that I was satisfied about, and because I had some time left, I took another 4 hours to build the documentation and prepare it to become open source.

While I had made several contributions in the past to other open source projects I was using, this was my first attempt at releasing an open-source project as a creator. I pushed it during the week-end and created a thread on /r/programming to expose it and tract a bit of attention. I was hoping for some good feedback. All i got the first 24 hours was a single comment saying:

http://ivaynberg.github.com/select2/

http://textextjs.com/

I have to say, I felt pretty bad and quickly concluded that my project was useless. I received a bit more neutral feedback afterwards with people who pointed out a few bugs and I spent some time fixing them for the next couple of days. I then exposed the plugin at two other places but always received the same answer: “why are you reinventing the wheel? It’s already been done before a thousand times.”

If you have ever created anything, you have probably been in that case as well. I think it’s pretty safe to say that in the software business, all the needs have been covered one way or another. Whatever you do out there, you will be reinventing the wheel. This is so disturbing it can even prevent you from starting anything. When John Carmack started game development, he felt like he was late to the party and that everything had already been done a couple of years before him. So why even bother?

Well, surprisingly, a year later, my tiny and simple open-source jQuery plugin MagicSuggest has almost reached 900 stars on github. It even was at the top of github’s trending list for a few consecutive days. Small achievement, yet big realization: I started as a plagiarist. I became an innovator.

Take a look at all the software/websites you are currently using and you will realize that almost if not all of them have replaced an existing product / website that was irreplacable at the time. Back in 97 everyone was using AltaVista to search the web. You would have been foolish to create another search engine back then. In 2005, all development teams were using SVN. And there were tens of other VCS available should the standard not fit. Why on earth would you want to recreate another one? Back in 2007 everyone was using emacs / vim / textmate / notepad++ to code. There were thousands of editors out there and you would have been foolish to create another one. The list goes on and on, with similar patterns. similar initial end-users criticisms, similar end-product success.

There’s a quote wrongly attributed to Picasso that is often quoted today: “Good artists copy, great artists steal” that Steve Jobs would often refer to. I prefer the W. H. Davenport Adams version:

“Great poets imitate and improve, whereas small ones steal and spoil.”

The great truth about software is that there is no perfect round-shaped wheel out there. We should be very careful when criticizing those who imitate: the ones who attempt to recreate something are the only ones who can seize the opportunity to make it better. And if you want to contribute to the future, start looking for people who have the guts and skills to question the standards of today.

In our little world of code, innovation is not achieved through creation. It is done through improvement.

How AngularJs will save JavaScript from its $ sign

I usually never rant about other programmers, considering myself only an average programmer. But as a community of developers, I think we are doing an awful job of helping people understand that jQuery != JavaScript. And I think that AngularJS will be a great asset in that regard.

The ever-amazing jQuery
I won’t say it enough: jQuery is an amazing piece of work and I cannot remember or imagine how we ended up building front-end code without it back in the days. It has saved us as developers at a time when every browser was going left and right: in 2006, Internet Explorer 6 was still leading the dance even though it didn’t comply with a bunch of basic w3c standards (boxing hell, transparency hacks, etc.). Firefox was on the rise and Chrome wasn’t to be released until 2 years later. jQuery provided us with the most powerful tools to master the DOM without ever worrying about the browser. It was simply revolutionary. We were also very lucky that its creator, John Resig, only 22 at the time, made it clear from the start that his library would stay completely open sourced, distributed with no strings attached. I want to emphasize that because it deserves to be praised. This was 8 years ago. There was no GitHub. Open source projects weren’t the latest fashion that it has become today. But unlike other people who were more interested about money than about improving the web, John stayed true to his word and conviction by being an advocate of open source software. Like a few others, he is one of the great hackers of our generation who have revolutionized our industry.

JavaScript sucks, jQuery is so cool
jQuery’s success was not only caused by its licence model or its cross-browser dom manipulation power, it was also caused by the fact that JavaScript was (and still is) an unpopular and misunderstood language.

If you ever get a chance to look at client source code from the websites that were built at the time, you will quickly see why people despised JavaScript. Everyone (including me) was doing it wrong, with files scattered everywhere using hundreds of differant coding style. There was no structure. Things could be done a thousand ways and noone would tell you which was the right one. People would randomly create variables on the global scope with very precise names such as data or i. There were memory leaks everywhere. There was no need for jslint, no need for convention, no need for a grumpy old man to tell you what to do. Noone ever bothered to create very clean JavaScript code. It was just something that people usually rushed at the end of the dev cycle in order to produce some quick and dirty client-side effect or field validation. It wasn’t even considered a real language, something that you could put on a resume or that you could brag about.

I’ve always believed that anyone can produce the crappiest code with any programming language or framework. Yet I think that some languages make it easier than others, PHP and JavaScript being the first 2 that come to mind.

The truth is: people didn’t like JavaScript because they didn’t understand the language. They looked at it as some trivial scripting language that anyone could code by typing random keys on a keyboard. People did not take the time to learn the subtleties of the language because they despised it. This is why jQuery came out so strong. People were seeing it as an escape from JavaScript, something that would replace its ackward and aweful syntax. DOM manipulation became easy, and it could be done properly without worrying much about anything else. jQuery was just so cool.

$(2 + 2)
From that point on, jQuery was adopted into every single website out there. And any website who didn’t use it would have been foolish not to do so. This was at the time when people would test each browser version number and specify which was supported. Chrome was released and butchered the old version numbering traditions by going from Chrome 1 to Chrome 8 in less than a year. It became impossible to go by without using jQuery’s hassle-free cross browser code. And yet, while jQuery solved many issues for us at the time, it didn’t address the most important one: people were still coding in JavaScript without knowing anything about JavaScript. All the complex parts of the language were wrapped and hidden so that anyone could build clean client code using the library. How many times have I wished that jQuery’s scope management hadn’t been left out to die, forcing people to keep references of this and that everywhere. (kudos to ExtJS for doing the exact opposite by the way)

And so it was that everyone’s toolbox was soon to be only filled with this all-in-one hammer called jQuery. You have a JavaScript problem? jQuery is the answer! Just look at StackOverflow’s JavaScript questions and answers. Every “vanilla” (I’m not found of that word…) JavaScript question is answered or tagged with a jQuery answer, making it even more complex to differenciate one from the other. jQuery started as a helper library. It became an imposed non-requirement. It’s been said a thousand times:

when all you have is a hammer, everything starts to look like a nail.

At that rate, I was predicting that people would soon do simple math using the $ sign. I would have bought some candles for Brendan Eich. This is where I am ranting about our community of developers. We need to do a better job of helping people understand that jQuery is not JavaScript. We should not answer with jQuery when it is not needed. We should also provide JavaScript answers to jQuery questions when jQuery has nothing to do with the problem. It is our duty to help others understand the language more, as it is quickly becoming the most important programming language in the world. We need to help people open up jQuery’s source code, understand its magic methods like $.extend or $.ajax, or how it manipulates the DOM. Just like 10 years ago, anyone today who has only done object-oriented programming will be thrown off by JavaScript’s prototype-based language and dynamic typing. But if one starts digging into what makes JavaScript unique, understanding the concepts of closures, anonymous functions, first-class functions, class-less syntax, he/she will immediately realize how beautiful, complex, and powerful JavaScript can be.

AngularJs to the rescue!
It seems hard for Google to create something that isn’t amazing. Their quality standards are part of what makes the internet great today. AngularJs came out late 2010. With about 2 releases a month using entertaining codenames like sneaky-seagull or barefoot-telepathy, it quickly started getting recognition as a new way to build complex, rich and unified single-page applications. As of today, it is one of the hot and trending tag you want to put on your resume.
Of course there have been other breakthroughs with the JavaScript usage, such as its usage on the server side. But the unique thing about AngularJs is that when designed correctly, your app should not include both angular.js and jquery.js. When designed correctly, AngularJS makes jQuery obsolete by taking care of the DOM manipulation in its own way. And as people stop using jQuery, they once again have a chance to dig into the wonderful world of JavaScript they had once despised.

Don’t misread me. I’m not saying that people should forget jQuery and replace it with AngularJS. It would be of no worth to replace an all-in-one tool with another. But as people strive to have multiple tools in their toolbox, they might end up realizing that they don’t need a sledgehammer to crack a nut.

CodingGamers

I have been thinking about a new game concept for a while. It targets a niche community so if you are part of that community I would love to hear your feedback as I make progress on this hobby project.

This post will be long because it describes the gaming concepts. No TL;DR; sorry.

Title: CodingGamers
Genre: Educational / RPG / Small games
Description: Programmers and Gamers will meet on this platform to create and play games with an RPG flavor, retracing the history of computer Gaming.
Inspirations: Game Dev Story, Upgrade Complete, CodePen, PlayMyCode, and the recently discovered awesome Untrusted

Starting up
Registration is free and is done through Tw / Fb / G+.
The user starts the game with the following stats:
– money: 150₲ (virtual currency)
– # games made: 0
– reputation: 0
– game company: none
– experience: 0
– year: 1980 (first era of time)

The virtual currency ₲ is used to:
– purchase/upgrade a more recent computer
– play games compatible with the acquired hardware
– purchase a game engine to create better games
– enhance a game engine

The objective of the game is to unlock all perks, advance through the years and reach the hall of fame with a stellar game. A user is both a gamer and a game developer.

Eras of Time
– There are 5 eras of time (1980, 1982, 1985, 1989 and 1992) that can be unlocked once the user reaches a certain amount of XP points.
– Experience is gained by shipping the games one creates and by finishing games others created.
– The site’s bootstrap theme, the available hardware and games reflect the era that the user is in.

WebSite Presentation
Once registered, the user can login to his homepage.
– Dashboard Tab : stats about the user’s company, his game sales #, his gaming stats, his friends stats, gaming news, game ads
– Tseam Library Tab : library of all the games the user has purchased with ₲.
– Coding Lab Tab : library of all games in current development
– Dry’s Electronics Tab: shop where the user can purchase new computers, parts, and game engines.
– iShopGame Tab : shop where the user can purchase games developed by the other users.

Whether or not the user will be mostly a player or a programmer, he cannot do anything until he has purchased his first computer, which is why he starts off with some ₲. Initially the user is set back in 1980. He can only purchase the most basic computer:

– Computer Name: IBN Personal Computer
– Requirements: 100₲ + year > 1979
– Specs: 1-bit display (black&green), 80×24 characters display, 8kb memory
– Upgrades available: memory up to 32Kb: 4kb = 20₲

The user is then led back to the homepage where he can:
#1/ start playing games that his computer can handle
#2/ start his own game company and career as a game developer

#1 : Playing Games
The user goes to the Games Shop where he sees all the games that have been released by other users and which match the era/period that he is in. Each game has a price (₲), a description, a cover image, user rating, the developer’s reputation (overall rating on the games released), and finally hardware requirements.

(Games can be sorted by name, # sales, release date, company, rating. Some games are grayed out as the user might not have the required specs to play them such as unsufficient memory, etc.)

Every time the user purchases a game, 50% of the ₲ goes to the developer.
The game gets added to the user’s game library where the user can play it, complete it, and then rate it.

The user gains experience by completing other user’s games and rating them once he has completed them. (ratings make up for the developer’s rep) Once he has enough experience, he may advance to the next era: the website theme is modernized, more advanced computers and parts can be purchased. The new hardware allows the player to play games with higher requirements.

#2 : Creating Games:
The first time the user goes into the Coding tab, he will be required to create his game company with a permanent name and custom-made pixel-art logo. (which will be displayed at the start of the games he makes)

He will then see all the current games that he has in development.
He can edit or create a new game.
Should he decide to create a new game, he is first asked to select one of his computers to develop the game on as well as a game engine to use. This choice cannot be changed after for that game.
The user is then taken into a CodePen-like environment where he uses the game engine to produce a full game.

Game Engines
Game Engines need to be bought to build games with. They require a certain type of hardware before purchase.
The better the engine, the more features it has (palettes, fonts, collision, music, sounds, etc.)

Example for first available engine:

– Name: 7UPERTXT-NG-3000
– Price: 30₲
– Required Tech: IBN Personal Computer
– Great For: Tiny Text-Based Games
– Speed: 5 FPS
– Available API methods to interact with display:
void write(txt, [x], [y], [color])
string input(txt, [x], [y], [color], callback)

Each game engine tech is a subset of a full custom yet fairly simple HTML5 game engine.
Each game engine comes with its manual (basically the API doc). New engines include descriptions / tutorials of the new API methods that were unlocked.

Programming
Coding is made in javascript and will use the API methods provided by the selected engine version.
Once a computer and game engine have been selected, the user enters into creative mode with an editor on the left and the results on the right.
Each game is required to have an ending. The length of the source code (# characters) is limited by the computer memory specs. Developers will not be able to write source code that exceed the amount of his computer.
Gamers cannot play games whose source codes exceed the memory amount of their computer

Assets have to be hard-coded in the game code. Images will be arrays of color pixels matching a given palette.
Musics will be transformed from string (http://keithwhor.com/music/, http://en.wikibooks.org/wiki/QBasic/Appendix#PLAY)
Sounds will be fetched from a provided sound library.
This means that the entire game can be exported as a single file and used freely elsewhere.

Once the game is ready for release, the player submits a unique title, a game type, an uploaded squared 256×256 image logo and a selling price in ₲. He can also purchase an ad campaign that will give his game more visibility to the other users (it appears in people’s dashboards, gets promoted in the Game Store, etc.)
The requirements for gamers to buy the game match the developer’s machine specs.
The developer can also decide to open-source his game so that others can view the source code freely.

The game is then in green-light beta, meaning that they have to be approved by the website’s mods before being public.
Website mods will have to play the game to moderate it (check if ending possible, no hacks, no spam…) and then assign the amount of xp gained when completed. Once approved, the game is released and appears in the store. Developers gain XP when a game goes gold, they also gain ₲ from game sales.
With enough XP, they can advance to the next era. The ₲ allows them to purchase better computer, computer parts, game engines, and make better and more expensive games.

Proof of Concept:
Here is a simple hangman game created with the most basic game engine / game computer combo. You can see that the main game loop is already in place and the rendering is done by the engine. The code is updated live and should be running in its own frame for security.

Additional Notes:
Users can gain additional ₲ by promoting the site (social network shares), getting referals (new users), or simply being active: logging in, reviewing
games, etc.
A game that reaches a certain amount of sales is called a hit. These games can have sequels which have benefits (people who game good score to the original game are notified of the new release, etc.)
Every week a new game theme is given. At the end of every week, one game from each era is selected to get a theme award.
Once a game has been released, it cannot be re-edited. Code is view-only. Bugs remain bugs. This is the floppy disk era. Release when bugfree!
Every month a high-end game is selected to be elected to the Hall of Fame (another front page tab) and the programmer wins the game.
Everything reflects the era the user is in: the web app interface, the code editor, the games, etc.
The Game Engine API will be open sourced on GitHub

Technical Notes:
Executing someone else’s javascript is always a bit frisky… We’ll have to take the same disposition as jsfiddle / codepen.

Possible computer specs according to the accessible eras:
Computer Name: IBN Personal Computer
Requirements: 100₲ + year > 1979
Specs:
– 1-bit display (black&green)
– 40×24 characters display (320×192)
– 8kb memory
– 1 simultaneous keys
Upgrades available:
– memory up to 16Kb: 4kb = 20₲ for ex.

Computer Name: ZED Spectrum
Requirements: 300₲ + year > 1982
Specs:
– 2-bit display CGA (8 colors)
– 80×48 characters display
– 16kb memory
– 2 simultaneous keys
– music 1 channel support
– up to 16 simultaneuous sprites

Upgrades available:
– additional fonts
– additional palette
– memory up to 32kb

Computer Name: AGIMA 1000
Requirements: 500₲ + year > 1985
Specs:
– 3-bit display EGA (64 colors)
– 320×200 pixel display
– 32kb memory
– 3 simultaneous keys
– mouse support
– music 1 channel support
– sound 1 channel support
– up to 32 simultaneuous sprites

Upgrades available:
– additional fonts
– additional palette
– additional sounds
– memory up to 64kb

Computer Name: 386SX25
Requirements: 1000₲ + year > 1989
Specs:
– 4-bit display VGA (256 colors)
– 320×200 pixel display
– 128kb memory
– 4 simultaneous keys
– mouse support
– music 4 channel support
– sound 4 channel support
– up to 64 simultaneuous sprites

Upgrades available:
– additional fonts
– additional palette
– additional sounds
– memory up to 1028kb

Computer Name: 486DX2-66
Requirements: 2000₲ + year > 1992

Specs:
– 4-bit display VGA (256 colors)
– 640×480 pixel display
– 512kb memory
– 4 simultaneous keys
– mouse support
– music 8 channel support
– sound 8 channel support
– up to 256 simultaneuous sprites

Upgrades available:
– additional fonts
– additional palette
– additional sounds
– memory up to 4096kb

And the best shared hosting service is… nearlyfreespeech

Being a blogger

A couple of years ago I tried to create a constructive, public-friendly blog that served mostly as a welcome page for doing contracting work on the side. It had a nice presentation layer to it which helped me to gain enough credibility to sign a contract with a big company. At the time, I had the objective of writing great posts often, along with beautiful pictures and highlighted code. All of my inspiration was coming from Jeff Atwood’s blog that had always fascinated me by the steady quality of its articles for years. I got started and was on fire! I wrote 4 long posts in 4 days! The 4th one ended with: “Blogging is easy! I could do it for 10 years straight!”… And that was my last post for 6 months.

Yeah, blogging for others is actually really hard. It requires time, dedication, self-discipline, patience, and humility. Kudos to all of you who have been maintaining public blogs for years. You are the memory of the internet!!

A few months ago I needed to keep personal technical notes again. I wasn’t going to go along the same route as before. My only objective was to write often, and I knew I couldn’t do that if I set the bar too high for myself. So instead I set the bar as low as possible by getting rid of anything that was not mandatory: colors, images, fancy templates, Javascripts, etc. My blog was just going to be plain, simple text, along with the cheapest shared hosting service to keep it on. I went from producing a tesla blog to a peugeot blog. It didn’t matter, I was not expecting more than a few visits a day from people who had mistyped some value and hit the I’m feeling lucky button. I didn’t care if it was fast. I didn’t care if it was pretty. I just needed to keep my notes on some blog somewhere.

The cheapest one out there
After comparing prices, I found out that the cheapest hosting service that you can find today is nearlyfreespeech.net. Go pay them a visit and you will notice right away a resemblance with this blog. We’re like 2 brothers sharing the gene of ugliness. Nothing there to attract the eye… But boy is it cheap! And it’s cheap because it’s fair: you only pay for what you consume. To give you an example I have 6 sites hosted there now:

  • Dynamic Sites : $0.06/day (6 sites)
  • DNS : $0.02778/day (7 zones, 2 external, 1 hosted, 4 registered & hosted)
  • MySQL Processes : $0.02/day (1 process)

6 sites that have handle about 300 visits per day (mostly related to my open source projects). 10 cents per day, that’s 3$/mo w/tax! AND this includes the whole package: FTP/SFTP/SSH access, advanced logging, unlimited databases, phpMyAdmin, etc. No other services in the world comes near in terms of price.

No pancake so thin it only has one side
Now shared hosting is great for websites that have little to no traffic. It wasn’t my first experience. I once happened to have a few hundred visits a day on another shared hosting service that I won’t name for their sake (ahem 1&1). As soon as I started to have very limited traffic, I received an email urging me to upgrade to a higher-tier or have my services disconnected. It bugged me but I recognized that it was fair. Those hosts have shared resources and should restrain you to your shared amount.

And I had always expected nearlyfreespeech to do the same thing…

Until last saturday.

I had written down my experience as a coder who happened to be often involved in the recruitment process at my last company. A friend of mine found it interesting and advised me to post a link to hackernews and reddit, after which I left to a kite festival with my wife and boys for the day. Had I known… The article went viral within a few hours and my blog was submerged. 85,000 views in less than 24 hours… I feel very humbled just thinking about it, and I was amazed to realize that so many people felt the same way as I did on that subject.

But as I saw the # of simultaneous connections increase hour after hour on analytics’ mobile app, I only had one thought in mind: “it’s just a matter of minutes: when will my blog crash? when will nfs pull the plug on me?”

They didn’t. They handled the charge perfectly, and my blog was super responsive the entire time.

But all that traffic? You pay for what you consume right? Yes… I went from paying 10 cents to 30 cents that day.

How they managed to pull that off and deliver that quality of service, I still don’t know… but I take it at heart to thank them for the awesome work that they do. They deserve to be more famous and have more business. So if you’re thinking about hosting some PHP somewhere cheap, look no further. And if by that time you’re used to reading my blog, you’ll find its design extremely attractive!

cheers, and thanks for reading.

How I ended up conducting the most successful technical interviews with a single question

The hiring process
A big part of my previous job was to take part in the hiring process and conduct technical interviews. That process was quite forward:

1/ An interview conducted by HR determined if the candidate is a serial killer / psychopath
2/ An interview conducted by technical experts determined if the candidate is a good programmer
3/ An interview conducted by big boss determined how low the candidate is willing to get paid

I interviewed 2 types of people: interns and future employees. Interns only went through #2 while the others went through all three steps. In the span of 2+ years working at that company I must have performed 200+ technical interviews. It was an enriching learning process for me, and I ended up figuring it out one step at a time. Now it is important for you to note that this occured in France, where you simply cannot fire people. Hire the wrong guy and you will be stuck with that person forever. It is critical to filter out the best candidates and not make any mistakes about it. It was a tedious process, and I loved every single part of it.

The very-specific lottery quiz
I conducted my first tech interview in 2008. At that time, the company already had a working process that I followed: interviews were 1 hour. The candidates would have 30 minutes to answer a 15 questions quiz. Then we would spend 15 minutes talking about their answers plus an additional 15 minutes answering questions about the job. I quickly realized how terrible that questionnaire was. I mean, I think that even if you tried, you wouldn’t be able to come up with something that terrible. About 50% of the company’s projects were in java, so the quiz was very java-centric. It contained 5 trivial questions and then 10 very hard questions specific to the java frameworks we were mostly using :

It went from

- What is the difference between a class and an object?

to

- What is the purpose of the execAndwait interceptor in 
  the struts 2 framework?

Heck even I couldn’t explain or expand on half the stuff that was asked... Every single time I would pray so that they wouldn’t ask questions about the questions! Pretty ironic for the interviewer... Anyways I would usually skim really fast (2-5 mins) through their answers and spend the rest of the time talking about their resume. It sucked big time and I wanted to improve it. So I went online and compared hundreds of interview questions. At that time I believed in the quiz format. It just had to contain the right questions in order to reveal how good people were. The right quiz for the right people.

The very generic quiz
After about a month of research, I had come up with the best 50 questions I could find online. I felt that they were good questions because they could be answered in any language, and they were in a smooth crescendo of difficulty. I scattered the 50 and ended up with 5 sets of 10 great questions that I would hand out randomly.

Example:

What is a singleton and when would you use it / not use it?

This was much better. or so I thought... The questions were good and I would also usually get good answers in return. I went on for a few weeks but somehow didn't feel completely right. I couldn’t shake off the feeling that even if what I did was good, it just wasn’t great. Yes it did test whether or not the person knew programming theories, but in the end it left me clueless as to whether or not the person could code. In the end I’m not sure that we ended up hiring anyone better using that method than with the caveman struts 2 questionnaire. The more I thought about it, the more I realized that there were 2 big issues with those 5 questionnaires:

1/ The questions were too generic. by not going into language specifics, I couldn’t talk about SQL, front-end specifics, etc.
2/ The quiz was too short. 10 generic questions just didn’t cut it. There was no way I could know if they were good programmers or not.

What I really needed was a lot more questions, and questions specific to the job the person was applying to.

Quiz manager 3000
This is where things got a little out of hand. I went ahead and created (with the help of an intern) a fully automated quiz tool: quiz manager (QM). The tool made the hiring process perfect: after the first interview, HR would select 3 topics related to the job description. The tool would then automatically create a multiple choice question quiz with 3 x 20 = 60 random but specific questions with a difficulty matching the person’s experience.

Example:

(javascript)
var i = 0;
function a(){
  var i = 2; 
  i++;
} 
a(); 
alert(i);    =>    0 ? 2 ? 3 ?

It would then draw little graphs, generate and email reports to HR, displaying the results compared to the average along with a bunch of other useless metrics. Man was I proud of that tool! I was looking forward to having candidates take the test! I would sit next door with HR and watch the candidate’s live score on the intranet app as the answers were selected. QM made all of our lives so much easier, it seemed perfect… Until we tested it on our own developers!

Well... Turns out that a lot of our great developers were getting the same score as some of the people I had refused. That's right, QM was proven useless! I had spent so much time building the tool that it took me a long time to realize the big mistake I had made: our desire to automate the results had constrained me to only ask multiple-choice questions. The user could only select one answer, and the questions ended up being mostly trick questions. The outcome was that we were not testing software development skills at all! It was tough for me to swallow my pride, but in the end I admitted that the tool was counter-productive, reflecting the wrong impressions about developers more than anything.

Just let ’em code
8 months had passed since I had the job. I did some more research and checked at how some US companies did their screening process. This is when I decided to go for another method: just have them code. That’s the reason they get paid, so why not show me right now how they do it. Quite logical when you think about it... Having learned some lessons with the first months, the test became quite simple: I would give out 3 algorithms to be solved in 30 minutes. Candidates could pick the language of their choice and have access to a machine (disconnected from the internet). Those were classic problems found online: One algorithm usually dealt with string operations (such as reverse words in a sentence), another with recurrence (such as calculate a term in fibonacci’s suite), and the last one with collections (such as ordering a list).

Example:

print out digits 1-100.
for multiples of 3, print out foo.
for multiples of 5, print out bar.
for multiples of both 3 and 5, print out foobar.

Everything got much clearer and better. I could directly see those who was indenting, commenting, using conventions, finding the solutions, etc. It gave me a pretty good sense of how much programming the person had done in the past. moreover, discussing about their solutions was also very informative. I like to think that candidates were comfortable with those tests because I had tried to take off all the pressure out of them. They could take their time, choose the language they wanted, ask for advice, etc.

I was initially happy with the results and did that for a couple of months. But then again I started feeling that I was missing something… Something that just wasn’t right… It's true that I could easily spot the ones who could solve algorithms from the others. But were they really the great programmers I was looking for? When you think about it, is the quality of a programmer defined by how well he/she can solve a math problem, or whether or not he is able to sort a list in O(n log n) and not O(n^2)?

The one question to rule them all
I can remember exactly when I first started programming. QBasic was shipped with MSDOS 5.0 way before windows 3.1 came out. It contained its own help screen with all of the functions and keywords of the language, like the perfect offline man page. To this day I distinctively remember the feeling that grasped me every time I hit F5 and saw my programs execute before my eyes. A single printed line, a prompt for a name, some colors, a puzzle... I was in heaven. I remember putting line numbers before each command, filling my code with horrible GOTOs, learning with excitement and fascination something new everyday. I loved programming. I would spend hour after hour creating games, solving problems, showing stuff to my parents and friends. Years went by, I went from qbasic to pascal to vb, wrote games for our BBS "Atomic BBS” that we ran from our home phone line through a 2400bps modem. I wasn’t really good. Well in fact I really sucked and my code was pretty horrible! But man did I love it!! I just couldn’t let it go... I guess some people feel that type of adrenaline the first time they fly a plane, sail a boat, smoke weed, eat at in n out... For me it was programming, compiling, executing. I gained that feeling 25 years ago, and it has never left me since. I was born for this. I’ve always been a programmer.

I have always been convinced that those who love code do not restrict their coding activities to their work. They take home that love and continue to create for fun as a hobby. How many times have I felt frustrated at work because of a struggling eclipse, only to find relief and joy when writing ruby on rails code back home!

And so it was, that after 1 year of trial and error, I completely stopped handing out technical tests. I would sit down with the candidate, read and comment his resume without asking him any questions for a good 5-10 minutes. And then I would flip over the resume, look at the candidate in the eyes and ask: “we have about 30 minutes left. Will you please tell me about the best project that you’ve ever created?”

That simple, unique and nonjudmental question was the key. Some answered vaguely about their previous work or school project. And then some others became suddenly alive and excited, even those who appeared to be the shyest. They would talk passionately about the game they were creating, the website they had made, the open source projects they had contributed to, the utilities they made after being stuck in the middle of nowhere without any internet access. They were proud to show me. I was always fascinated by what I heard and would ask about all the details of the project they had treasured. They opened up and talked about the technical difficulties that they had overcome, about the little personal touch they added. It was their baby. And as they talked it was impossible to miss: I could see that light in their eyes, the excitement of a child that compiles and runs his first hello world. I would know right then that we had something in common. They were programmers too.

Most of them didn't have a clue about struts or some other specific framework we were using. Yet once they got the job, they always ended up being golden developpers. They learned faster, they produced better code, they inspired others with their creativity and positivism. They were coders at heart.

And in the end that’s all that matters.

[Update 07/27/14]
I never thought that this would escalate so let me clarify 2 things:
#1: The question I would ask would include all types of projects, and I would put work projects at the exact same level as hobby projects. It was great (but rare since they were changing jobs) to meet people who were passionate about their work project. There is no perfect interview method, no method that will work perfectly for every single candidate out there. But I came to find out that even the best could freeze in front of a simple FizzBuzz problem, just because of the interview context pressure. So basically instead of asking the candidate if they knew "this" or "that", this question allowed candidates to bring me to their world, tell me who they were and what they knew best.
#2: The first 5-10 minutes weren't minutes of terror and silence. I just didn't ask deep questions about the resume. I used those first minutes to chit-chat and make the candidate feel as comfortable as possible, by reading and making positive comments about the experience he had written down. After all, it's easy to put anything on a piece of paper. My main objective was to spend most of the interview time listening to what he had to say on the thing he was most passionate about. I never looked down at candidates because each of them was unique and you never knew how good they were just by reading their resume. Also i've always been surrounded by amazing programmers so I've learned to listen more than to talk.

The big flaw with today’s open-source fashion

I’ve always been a fervent advocate of open-source software.

It’s been said over and over again: open-source software has won. Github has become the biggest freeware distributor in the world. You have something interesting to show to the world? Make sure it’s on there and open sourced. While you’re at it, make sure it’s also licensed under the most permissive licence possible. “GPL you say? I won’t even look. I can probably get the equivalent for free under MIT or WTFPL in your neighbor’s repo!”
and chances are that he will too… Hence the trend continues, encouraging all the software to become free to use, free to alter and free to redistribute.

So what? Why complain when everything is becoming more open, transparent, and (having to comfront public eyes) cleaner?

The reason is very simple: noone treasures something that is free.

It’s not against anyone, it’s a law of nature. we only treasure what we made sacrifices to get. And so by pushing developers towards the give-all-you-make paradigm, the value of their code is diminished, destroying its worth. Consumers take it for granted. After all, free IS the norm. They open feature requests after feature requests because they expect the software they use to be just as perfect, if not more, than a pricey software. As a result, they often never seek solutions to their own problems. They request them. everyone looses.

I can remember a time (ATDT…) when you would have to purchase a piece of software for 20-30 bucks. It had its flaws, but it was yours. You couldn’t really hack it, but you worked your way around it. Heck you had no choice, you bought it. You were not just a consumer, you became a contributor. If it didn’t fill all of your needs, you managed to still pull it off. It would make you proud, and you would treasure the tool that you bought, because it made you better than what you were before.

Today everything is open source. We are spoiled by it. We cannot appreciate it. And that’s its biggest flaw.

So how can we avoid this from happening? How do we balance things out?

I don’t have the solution but my personal thought is that open-source software should never be free. Perhaps starting at a symbolic $1, people should then choose the amount they want to pay depending upon what it’s worth to them. Developers will feel proud about their non-obligatory gains. Consumers will feel proud about their prized possession. Call it however you want, I call it the “Pay-Whatever-You-Want-Do-Whatever-You-Want” licence.

Well, what do you think?

Javascript inheritance without loosing class names

There are a LOT of articles out there that talk about Javascript inheritance, or even object-oriented javascript in general. There’s been thousands of frameworks that have provided javascript with the notions of encapsulation, classes, etc. This is probably because prototype-based programming is not intuitive to all those who work regularly with object-based languages such as java, php, ruby, c#, etc. Just look for object-oriented javascript stuff on github, you’ll find thousands of open-source frameworks / snippets… So why do people bother so much about turning javascript into something it’s not?

Well my personal thought is that it’s actually a good exercice. It really helps one understand and appreciate the depths of the prototype-way of thinking. In fact, I think that all javascript developers should create their own $.extend framework so that they may discover the subtleties and power of prototypes.

Anyways… I was reading some of the most famous inheritance scripts out there, starting out with this bright snippet from John Resig. I also went through the sources of the most appreciated related github projects (oolib, oorja to credit a few) and quickly realized that all of them shared a big issue, which is best described in one of John’s comments : “@Justin: I don’t think there’s a reasonable way to actually assign a name to the classes, which is unfortunate.”

The problem

There are two ways to define a class in javascript:

1. var myclass = function(){...}
2. function myclass(){...}

Even though they may look alike, those 2 methods are very different :

1. creates a function that doesn’t have a name (anonymous function) and assigns it to the variable myclass
2. declares the function named myclass

It is important to note that “you cannot change the name of a function, this property is read-only.”. In other words, once you have started using an anonymous function to create your class, you will never be in control of the class name.

The impact

Let’s take John’s Resig’s code snippet and apply it in the console:

var Person = Class.extend({
  init: function(isDancing){
    this.dancing = isDancing;
  },
  dance: function(){
    return this.dancing;
  }
});
 
var Ninja = Person.extend({
  init: function(){
    this._super( false );
  },
  dance: function(){
    // Call the inherited version of dance()
    return this._super();
  },
  swingSword: function(){
    return true;
  }
});
 
var p = new Person(true); 
var n = new Ninja();

Both object’s class names are ‘Class’:

p.constructor.name; // 'Class'
n.constructor.name; // 'Class'

While this may not be a problem when dealing with small examples, it becomes a huge PITA when debugging a big javascript project based on anonymous functions. Try making an HTML5 game with it and you will see how fast it gets on your nerves. hence I looked at about 20 different pieces of code but the same issue / code pattern was there. In fact I haven’t seen any framework that could provide me with ninjas beeing Ninjas and persons beeing Persons (did I miss it along the way??).

So last night I wrote my own little inheritance snippet. It uses dynamic function naming to circumvent the issue above:

moo.js

There are a couple of objectives I wanted to achieve:

– achieve basic inheritance
– allow subclass methods to override / call upon their super methods
– have classes retain their class names
– support for event management

The code is released under the MIT licence. Feel free to use it at your convenience. I think it can be very useful for games or other object-oriented programs. It’s been tested with jasmine.

– Project home with its documentation
– Source code hosted on github

I’m sure it can be improved and i’m always open for feedback and criticsm so if you’ve got something to say, use the comments section below or create an issue in the github project.