Claudiu Persoiu

Blog-ul lui Claudiu Persoiu


Archive for 16 October 2011

A new JavaScript game – Minesweeper

without comments

It’s time to publish another JavaScript game, this time is Minesweeper.

The first version of the game was made about an year and a half ago, but meanwhile I’ve completely rewritten it because of performance issues.

I believe this will be the last game that I didn’t make using canvas for compatibility reasons.

Unlike the other games that were made literally over the week-end (the exception was Puzzle Gd) this game proved to be a little more complicated.

For the design I must thank (again) to Cătălinei Radu.

Enjoy!

Written by Claudiu Persoiu

16 October 2011 at 9:47 AM

Posted in Diverse,JavaScript

Tagged with , ,

Internet Explorer, select tag and onload

without comments

Another reason why I hate Internet Explorer.

All new browsers tend to cache form values. Nothing unusual up to here, a little annoying, but not unusual.

We have the following example:

<select id="select">
 <option value=a>a</option>
 <option value=b>b</option>
 <option value=c>c</option>
</select>
<script>

var checkSelected = function () {
 var element = document.getElementById('select');
 alert(element[element.selectedIndex].value);
}

// run after onload
window.onload = checkSelected;

// run before onload
checkSelected();

</script>

Load the page, select the third value and then refresh. Because no form was submitted the first impression is that the result will always be “a”. It seems it’s not really like that:

  • FireFox: c c
  • Google Chrome: a a
  • Internet Explorer: a c

I can understand why FireFox choose to cache the values even when no form was submitted.

I can understand Google Chrome for not caching the page if the form was not submitted.

But Internet Explorer caches the values and them loads them only after the page was loaded? This is confusing to me! I mean you don’t have the option of not using onload? Not even if the form was not submitted?

This test was made on Internet Explorer 9 and compatibility view to versions 7 and 8.

Written by Claudiu Persoiu

9 October 2011 at 2:09 PM

Code quality and development time

with one comment

I’ve started writing this blog about an year ago.

A more delicate issue, and often less discussed by project managers is code quality vs. development time.

Code quality is a pressing issue for programmers, an issue that they confront almost daily.

In what degree is that relevant from the economical point of view?

I’ve created a chart trying to better illustrate this issue:

code-quality

This graph was made about an year ago, when I’ve started writing this post and I wasn’t too sure about it.

Recently I’ve started reading “Clean Code” by Robert C. Martin. When I was reading the first chapter, on my way to work I’ve got to “The Cost of Owning a Mess”. Unlike me analyzing “Code quality” vs “Development time”, in the book there is a graph for “Productivity vs. time”:

I was very excited to find this similar graph. In other words, if is code of good quality, development time will be lower. As the more “unorganized” the code, the more development time is needed.

A fairly popular method of resolving this time issue is rewriting the entire platform. Rewriting a platform may not be a very good choice because of the costs. In the book there is an extra argument, if the two platforms are build in parallel there is a posibility that there are never going to intersect, so the new platform will never get in production. I’ve nerver seen a plan so radical in practice without renouncing to the old project, but a case that I’ve came across in several occasions is when the platform is rewritten end even if the start is very promising and everything is aligned with the requirements, and the old issues are approached in a constructive matter, a time comes when compromises start to appear. Usually an achitectural compromise never comes alone, once you realize that you can make compromises, and the team doesn’t have remorse about them is the first sign that the project will get on the wrong path again.

A partial solution I think is appointing an architect who can set the development path, a person that can manage the project and don’t let it get out of control.

Another perspective is that the older the bug the harder it is to solve. In fact, code quality is a more relevant factor. The better a piece of code is written the easier it is to understand and modify it. As a direct action it is preferred to have a “coding standard”.

The problem with “coding standard” is that not every programmer is ready to embrace it. Usually senior programmers have the tendency to do things as they are used. No standard is perfect, but even an imperfect one if it is implemented in the entire project, the code quality is considerably better because you raspect an approach, you don’t have to guess it.

The moral: take care of the code and you’ll have more spare time, after all life is short, doesn’t worth spending it doing debugging. 🙂

Written by Claudiu Persoiu

4 October 2011 at 9:48 PM

Posted in Diverse

Tagged with ,