Monthly Archives: January 2012

Don’t lose the ability to be surprised


Any fair-experienced CSS developers know that, if we want to be sure that a parent-div truly contains a child-element, we should put “overflow:hidden” in the parent div.

I was told that, too.

Ok, that solved the problem. And we continue going without truly knowing the reason “WHY”?

“Don’t fix what ain’t break” – people say.

In fact, I’m type of people who don’t like to invest time into things that aren’t useful. So I accept that trick as it is. Until today.

I was surprised (or remember that I was surprised) – like the first time I heard the trick. It took no more than 10 minutes to find an answer… but the question is that WHY I didn’t ask that question any sooner. How can I let the “magic” slip without wondering???

I suddenly remember a lot of other things that I take for granted. When I first come to this field, everything is new and shiny. After a while, things get normal bit by bit. And gradually I forgot my ability to wonder.

I remember the time when I was assigned to do OAuth 2.0 for a Facebook application. Instead using a library, I “silly” re-wrote the whole authentication process by Servlet/ HttpRequest & Response. By now I’m nearly sure that there must be pre-built library to do that thing somewhere. Whatever, I don’t regret. The time I put in studying how OAuth 2.0 works let me confidently say that I fully understand it, and I can (and did) manually write authenticate process for both Twitter & FB… They are all HTTP requests, basically.

What’s the way of your choice: learn just enough to do things – or learn intensely to truly understand how things work?

P/s: I have some ideas about “Key Concepts” (to overflow:hidden, it’s Document flow). But this post’s long enough.

Start at StackOverflow: The right time to ask


A time has passed after my last post in the series “Start at StackOverflow”. It may be because that I don’t find much time to wander there anymore. Still, it’s still a useful resource, and one of the fruitful source when I try to do things that my peers may did already.

But now I think I found a simple question, that, though it seems A LOT OF useful, not many people ask. Even I just notice it after more than a year with this site.

It is:

What is the best time to ask at StackOverflow?

Why is this question important? Answer: the answer’s ratio for your question certainly depends on the number of users who see it.

If you work in a very-narrow technology domain, and ask at the time when most SO users about that field are sleeping, surely you must wait for an answer.

If your question is on a general field (Java, .NET…), don’t feel lucky too early. There are tons of general quesions dump to StackOverflow every minutes, so your question will soon flow to the end of the list… and well, may take at most 20 views.

Reversely, if you are new to the site & want to play the reputation game, you should do the opposite: online at the time that most people are offline to answer questions with much slower speed…. and help the guy in need, ofcourse :)

When the problem is found, I realize that I’m not the first person asking that question.

But I myself come up with a fairly different answer. In the post of Jeff ArtWood (about 3 years before), the best time is around 15:00 and 22:00 GMT/UTC. In my experience, with Java-related questions, the best time is around 2pm – 5pm at Vietnamese time. In GMT, it’s about 7am – 10am.

Javascript is an object-oriented language (1) – Encapsulation

Javascript is a powerful tool. No web developer can live without it. Without Javascript, the webs will be much poorer, as most of user-experience enhancement don’t exist.

Powerful tools are often misused. Javascript is in the same fate. Easy to write, easy to mess. And it soon earn the dispute as one of the most messy language. But investigating further, Javascript is one of the most mis-understood language.

Javascript is an object-oriented language.

That maybe a suprise to some people, and so do I. You see, javascript is often written in one big files, with the statement lined up from start to end… Global variables, C-like syntax,… it just seem to be a typical procedural language.

In fact, Javascript is heavily object-based. Everything in javascript is viewed as an object. Function is an object. Array is an object. But surely, “just because a language has objects doesn’t make it OO.”

You may say: but every property in a Javascript object is public? Aren’t we told that a language can only be called object-oriented when it has “encapsulation“, “inheritance” & “polymorphism“?

For the first question, I can confirm: yes. All property in a Javascript object is public. But Javascript is still an object-oriented-able language. Following I will show you how:

1. Encapsulation

Encapsulation can be achieved by a special feature of Javascript: the closure. Simply put, that’s the ability which allow the inner function has access to local variables in the outer function. A simple piece of code should says more than I could:

var Merlin = function() {
var say = function() { alert(advice); }

// Local variable that ends up within closure
var advice = 'One must complete what he started';
return {say: say};

var apprentice = new Merlin();
apprentice.say(); // alert 'One must complete what he started'
alert("Let's look inside of Merlin: " + advice); // alert nothing, since advice is not a global object

To be fully understand the concept of closure, one should study about how Javascript define scope for its object. In the above example, you can easily see that, the function say() can still access the local variable “advice”, even after function Merlin() has completed. Other languages (Java, C, for example) often requires the local variable disposed as soon as the function is complete. This is a strange mind-set, but as you see, it do the “hiding” job just well.

(to be continued)

P/s: Thanks to Mr. An to give his time explaining this to me, which most of the books never make a comment.

Split the way


Dear my friends, fellow programmers & readers,

Thank you all for supporting my blog for a whole year. Your encouraging helps me maintain this blog, since I feels it’s useful to others.

The following lines was written, at the beginning of this blog:

As its name implied, in this blog I am going to share about my experience with technology and innovation. Just one of thousand blogs out there, I know. Thousands of blogs are thousands of views: this blog is my view, and if you like or dislike it, I’m more than pleased to discuss things out.

Truthfully saying, I didn’t follow the rule well. “Technology & innovation” is not a good description for this blog. After a while, it becomes more & more like a group of simple programming articles. So things must change, to reflect what it really is.

I decide to setup a new blog, which is at . I will dedicate my explorer spirit for new technologies, & innovation methods there. This blog will remain as a record for my journey as a programmer.

Unit test – call the agel out of the stone


Angel, please come out of the stone

“I saw the angel in the marble and carved until I set him free” – Michelangelo

After the previous post when I managed to make Spring context wired for Unit test to run, now there’s more thing into it. Well, I gave my Test class the ability to do IOC (Inversion of Control), and from now they can call service beans, access databases, and so on… It seems the remaining should be easy, since the hardest part has been completed.

Well, things don’t easily go as we expect, in lots of occasions.

I actually made a running code, but when I try writing my first unit tests for my current working web-application, things turn bad. It turns out that I can’t write much meaningful non-trivial test, without making test-running-time tremendous slow. Why? It’s because:

1. Most of my code logic lies in the service. AND the service (in this project) OFTEN (if not always) works with Database. And when I says Database, it means the test is not the unit test anymore. It’s an Integration Test.

2. There’s some logic in my project which doesn’t relate to database. But I feels pretty confident about them – they are mostly simple. According to Pareto’s 80/20 rule, I don’t want to write tests that doesn’t enhance maintenance ability.

Those may be (some of) the reasons that my seniors don’t encourage me to write unit test. Unit tests are meant to be fast. If it’s not fast, there’s no reason to run it frequently, to help refactoring or development.

Another problem I meet is to set up the Database to a known state before running the test. Only then the test results will have some meanings.

So… are the efforts all useless. Absolutely no. The main problem here is that I need to stop regression bugs, by regularly running some kind of test. Whatever it is, but let me find bugs soon, and stop the system broken by ill-refactoring.

“And I have found the solution. The way to call the angel out of the stone”. If I can put up an in-memory database instead of Postgres, the running-time will be fast. I can also prepare the environment by database script or bootstrap code.

DBUnit seems to be a fair choice for a solution.

Configure UnitTesting with Autowired in Spring context

/* Vietnamese:  Một bài viết trình bày cách viết Unit Test sử dụng Dependency-Injection(Autowiring) trong Spring Framework. */

Unit-testing is surely not a new idea, since it was proposed around the 1980s. But it’s still one of the core concepts of Test Driven Development, Agile programing, Scrum,… & some other “hot” programming methodology that arise recently. In “Clean code”, Robert C. Martin writes: “If you want to write a line of debug/log message, consider writing a test instead”.

Those ideas are really cool – if you want to know more about how writing tests stop regression bugs, improve productivity & help the designs overall, go on & read “Clean code”. I will return to the topic here: How to write Unit test in Spring context.

The second I read those above lines of Martin, I decided to try it right away. But to do Unit test in a Spring web project, I need a way to inject my services into the test case (well, there’s a HUGE pile of services). The way is easy, but only if you know what to do.

It took me quite a time to make a running system.

Here’s how I did it:


import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

public class ActionServiceImplTest {
	private ActionService actionService;

	public void testHelloAction() {
		assert actionService.helloUnitTest().equals("Hello Unit Test, hope we have a good time together!");

Hope that should cover the topic

Source code can be found here:

Reference: (not all of these links are referred in this article. But every of them help me “go near the truth”, so I put them all here.)