Linux FTW

I can not imagine doing development without Linux.

I don't get how people can live without multiple desktops (even on multiple screens they are a must), without a decent terminal (tabs and bash), or a decent window manager (at least expose, and "allways on top" for a certain window).

And here comes the fun part: I am in a Microsoft Gold certified company. I am using of course Linux (Ubuntu). Our customer uses RedHat Linux, and a JEE stack (JBoss). At home I have another Ubuntu box.

Recently I've bought a g1 (google Android), and now my phone also runs Linux.

Or as Mahatma Ghandi used to say: "And then you win".

Thank you Stallman.

svn real revert

Sometimes it happens that we screw up our code in some file. And we want to go to some previous version of that specific file, hoping in our blind faith in source control versioning.

I don't know how many of you are still using SVN, and not Mercurial. If you do use SVN, you most likely have been fooled at least once by:

svn update -r oldrev path/to/file/to/change

The problem with this is that when you do update to a revision that is from the past, SVN still remember this, and on the next update && commit combo, you will yet again have the newer version of the file.

Thus a better way would be to just reapply the changes, but in the opposite order, without SVNs intervention. What we need is to create a patch from the new version back to the old version, and apply that one to the file.

What many people might not know, is that SVN actually knows how to do create patches between any revisions (not only in ascending way - e.g. from the oldrev to the newrev) including from a newer version to an older one.

So I will ask SVN to do a patch from the new revision to the old revision, and I will apply it directly using the patch command like so:

svn diff -r newrev:oldrev path/to/file/to/change | patch -p1

And by this, we do have the guarantee that only the changes are set into the file, without SVN changing the version of the file.

Update
Looks like the best way to do this, is to use svn merge, which will do also the patching, so the need for the patch command is unnecessary.

svn merge -r HEAD:oldrev path/to/file

Thank you rpetre.

Test Driven Development, How To?

In software there are a lot of methodologies on how to implement software, but really few reduce greatly the time of development or really simplify it.

Most programmers probably know, but even if you don't know, it is good to notice: the great bulk of time in development of a software is spent in bug fixing and maintainance. They can take from 55% in most lucky projects, to around 95%.

The time spent in bug fixing relies mostly on how much you decide to invest in it also. For example having 95% of time used on bug-fixing could mean that the software product emphasizes a great level of quality. For this scenario consider for example a real-time device programming, or an air traffic control software. The later one needs to be stable for years to come, and have minimal downtime.

In desktop programming around 75% of the time is bug fixing. Why does software spends between two thirds to three quarters doing bug fixing instead adding features? Well, last time I've checked, developers were still humans, and they can only keep a limited amount of ideas in parallel; but since they have to focus on memory management, performance, writing useful code, interaction between components, specifications, etc. this will overwhelm quite easily even the best developers.

Test Driven Development (TDD) is a software methodology created to reduce the time of staying in bug fixing "mode". The best qualities of it are:

• detect bugs as early as possible


• has several tests that have input scenarios for the software, and expect some output.


• makes the code to trigger feedbacks to the developer if something wrong happens, before a QA analysis. or in the much worse case, a user noticing it.

Which are the steps to do TDD?

• since it is named test driven, you should write your tests first, before you write the code. Or if the code exists, make tests to reflect the interface (without assuming the implementation is even better).


• make your tests pass with minimal code in the implementation side.


• refactor your code to be as good as you want, as long as it doesn't break the tests

As an example let's say that your application uses nUnit framework to do the unit tests, which are small programs that define a collection of tests.

Here is a test that checks in a real world application if one document has a right working Undo function:

using System;
using NUnit.Framework;
using TreeData.AttributeInterpreter;
using TreeData.NaroData;

namespace NaroTestSuite.TreeData
{
[TestFixture]
public class UndoRedoTests
{
[Test]
public void UndoAppliedEmpty()
{
DefaultInterpreters.Setup();
Document doc = new Document();
Assert.AreEqual(0, doc.Root.Interpreters.Count); // assert 1
doc.Transact();
doc.Root.Update<IntegerInterpreter>().Value = 2;
Assert.AreEqual(1, doc.Root.Interpreters.Count); // assert 2
doc.Commit();
Assert.AreEqual(1, doc.Root.Interpreters.Count); // assert 3
doc.Undo();
Assert.AreEqual(0, doc.Root.Interpreters.Count); // assert 4
}
}
}

It is easy to write tests? Well, you need to define your expectations (or assertions) - things that you believe to hold true. Here are the normal expectations for a class that store a document in a doc.Root tree data (from the example above):

• a newly created document is an empty one and an empty document will have no attributes (assert 1)
• after I will add an integer attribute the attribute count should increase with 1 (assert 2)
• after I will try to save the status of the document (after a "commit") the document should not change the attribute count (assert 3)
• after I do an Undo, the document will decrease to original document count, so it will be zero (assert 4)

Making tests first will do a very important thing for the developer, it will give to it concrete cases how the actual implementation classes (the tested ones) are used and this means real documentation. Also, using a tested class and if the specified class has the tests passing, will mean that some problem is actually coming from another part of the application, or from an incorrect usage of that class in the production code. This inherently removes a lot of assumptions about what breaks and why.

A great thing also is that tests are often much smaller than the entire application. So debugging it will reduce to debugging of the latest usage of the document, is not the entire application that may not work with Undo function.

How about regression testing?
Regression Testing (RT) is almost the same as TDD but is done after application is written (for instance to an user), there is a test written "to not happen again". RT has some downsides:
- the developer (or QA) who writes the test can get the application architecture. This may mean that we can create a test to pass our code, instead our code to pass our tests
- at development time, there are no tests to check if a component is working (excluding the developer will debug the program again and again)

Should you use RT? Yes, definetly! RT appears in ways that application you have never expected to crash or to run, does so, and where you don't want it. Also, the user bugs are great to be tracked. A flawed component will most probably crash again. There is a QA 80/20 theory which says: 80% of errors are in 20% of code. TDD will say that for your cases your code will work correctly. But still there are your tests, which may not reflect the real life cases.

As in our example: who creates a single document to store only one integer in it?

Conclusion
We've shown several steps on how to implement TDD, we've been over a minor test case, and we've outlined several advantages of using TDD. We've did a short comparison of TDD with RT.

I hope this will stir your appetite for TDD at least as we're having it here at freeopenidea.

Major facelift on freeopenidea.blogspot.com

As you can see, this blog it's looking now much more nicely. This happened since I got some spare time, and also because of the following opensource/free tools:

gimp and firefox (with firebug).

And of course, my mighty operating system: ubuntu.

MagicGroup 1.2.0 is out

It makes me great pleasure to announce you that MagicGroup 1.2.0 is out.

MagicGroup is a plugin for Eclipse that allows you to group the files you're working on, in a logical way. A longer description of it, you can find in a previous post of mine.

The changes are:
1. Mercurial source code is available on sf.net. Of course, it is EPL and GPL3.
2. MigLayout is now used for the popup used for renaming and creating groups.

Here is a quick "before and after" using MigLayout:

Before

and

After

The plugin is available for download here:
https://sourceforge.net/project/showfiles.php?group_id=224162&package_id=271060&release_id=674924

Have fun.

PostgreSQL bad practices

I was reading the "Tip of the Day" in pgadmin3, when I found this gem:

It is good practice to build application logic into the database itself by using functions and views. This ensures that different front-ends to your products will always see the same views of data and update and modify data in the same way. Better yet, you only have to write it all once for all front-ends!

While the sentence itself, does have some truth it it, in my opinion is misleading. I don't think it's good practice, but rather bad practice. I don't deny that there can be valid, performance related reasons to actually use functions and views (my big problem is with functions, not views, since views are pretty standardized) in the database, but let's be honest: the moment that you have stored procedures in the DB you are married to that vendor of the DB.

Be that vendor PostgreSQL, or even Oracle, it's obviously the same thing; and it's not good practice to be tied to a vendor.

Another issue that I have against this, is that you actually split your business logic into several places. While this doesn't fully invalidate the DRY principle (Don't Repeat Yourself), since really, you don't repeat yourself, it has a sneakier drawback:

Your logic is not found anymore in only one place, but rather divided over different (and most of the time totally different) places (and architectures). It can even be 2 different machines. This alone can make debugging a really tough time.

Thus I find approaches like Hibernate Validators much more enjoyable for the same task. You have your constraints and business logic over the domain in only one place. They can't do complex DB operations, but I think most of the time this can be resolved via Object Oriented programming and some nice services.

As people on the Internet tend to get really heated, I want to outline this again: I'm not saying that stored procedures have no place in an application.

What I am saying though, is that you should be really careful when adding them in the application in the first place. I would go and argument that encapsulating them in a service, that is a wrapper over the stored procedure, so at any given time later to be able to change it for a different DB would be a nice approach.

Conclusion

Here are my 2 cents regarding the previous Tip of the Day:

• Don't get tied to a single vendor.


• Keep your business domain in a single place.


• Have clear boundaries on the stored procedure call, to be able to replace it, if you can't live without it.

I'm a hacker... NOT

Recently I had the pleasure to navigate through milw0rm's exploits. A lot of them are pretty much kryptonite for me, but I think this (milw0rm) is a great place to learn more about security and expand general knowledge about how the exploit works... with more of a "hands on" approach, then security by obscurity promoted by some weird companies.

Until I found this "exploit". It supposed to be some sort of a bug for Firefox 3.0.5, and exposed as "Firefox 3.0.5 Status Bar Obfuscation / Clickjacking".

Let's get a few things straight. Almost all recent browsers represent the page internally under a structure called Document Object Model (DOM). The defacto programming language, that again, almost all recent browsers implement, is ECMAScript, better known under the name of JavaScript.

JavaScript code that runs inside the browser can access the DOM and modify the DOM in almost every imaginable way - actually because of this extreme flexibility the whole Web 2.0 concept was born out.

Back to the main topic. If you have code like this (taken from the "exploit"):

25 <a href="http://www.google.com" onclick="updatebox(event)"><font
26 style="font-family:arial;font-size:32px">http://www.google.com</font></a><br>

that calls a function like this:

 6 <script>
 7 function updatebox(evt) {
 8 mouseX=evt.pageX?evt.pageX:evt.clientX;
 9 mouseY=evt.pageY?evt.pageY:evt.clientY;
10 document.getElementById('mydiv').style.left=mouseX-1;
11 document.getElementById('mydiv').style.top=mouseY-1;
12 }
13 </script>

then please don't say it's an exploit, just say it's expected functionality from any decent browser that has JavaScript enabled.

Notice the DOM manipulation right there: document.getElementById('mydiv').style.left=mouseX-1;

And since we can do DOM manipulations, there's no need to move divs around for the "clickjacking". We can just change the href's target and that's it:

 3 <body>
 4     <script language="JavaScript">
 5         function navigate(element) {
 6             element.href = "http://milw0rm.com";
 7         }
 8     </script>
 9
10     Valid link:
11     <a onclick="navigate(this);" href="http://www.google.com">www.google.com</a>
12 </body>

On a funny note: Hey, this code it's even cross browser!! It also works on several other browsers. Thus I give you: "Firefox/Opera/Safari/IE/... Status Bar Obfuscation / Clickjacking".



You could visit google.com for more information. :P