bookmarking + mind mapping

Recently, I’ve been using an interesting and useful free online service, GetPocket which helps me to bookmark articles, papers, webpages, etc to read it later. The service even extracts the content and displays it in elegant format. It even allows me to tag, search, add favorite, etc. In short, it’s cool.

I’ve been bookmarking a lot of good articles and links that I’m interested and plan to read them on my free time. Until today I’ve suddenly realized that I actually need a similar service as GetPocket but allows the user to chain/connect them as a MindMap.

Usually, one of my hobby is that for certain topic/keyword, I start searching materials about them. For each article I reach, I read a few first paragraphs and if I encounter a link to another one, I immediately open the link. The routine is as follow:

1 – open
2 – read a few paragraphs until encounter (interesting) links/keywords/concepts
3 – open them
4 – go to 1 repeat.
5 – if there is nothing new, I come back to the previous articles.

It looks like I’m digging up a articles tree, or rather travelling a material map. Then an idea popped up in my mind: Why not combining the two: bookmarking the articles and mind mapping.

I want every time I bookmark a link, I can tag it and link the article to a mind map with some keyword and some description for the article. Then by the time I read back the articles, I can follow the graph and regain the knowledge. The application could render the articles and its graph to follow, just as a mindmap.

Bugs lie in uncertain code

Today after having lunch, I went around articles queue in order to read one or some. As reading the Architecture-Breaking Bugs, a lot of articles I had read before came back to my mind.

The content of article was about flaws in the architecture which the engineers often overlooked, turned out disasters. There was a link to another article which told the story of Airline 5 and has it crashed because only 1 bug at 1 line of code. Going through the articles made me remind of “Clean code” of Uncle Bob, “Don’t Assume It, Prove It” of The Pragmactic Programmer.

Why? Because at the time I was reading the article, I had finished basically a feature in my current project, Migration Process. The process is for migrating old workflow cases into new Process Model Version to avoid too many versions running in parallel. My group was barely finished the process on Friday and had to show it to the Product Owner on next Monday. Honestly, the process was untested, and I was sitting there doing nothing. There were a lot of things to be tested, a lot of scenarios to tests, but I chose to test several of them under the assumption the process will work. HOPE!.

God damn it! I had to go back to do something about it.

The Humble Dialog Box and Ivy Rich Dialogs

Today I’ve read The Humble Dialog Box of Micheal Feather and it is very interesting. The idea of the article is to develop in test-first manner the Model first, all actions, all interactions should be developed and tested against the mockable interface of the View. By doing this, it ends up all the logic are encapsulted in the Model (smart object) and the View provides methods for the Model to update. It is somehow an opposite way of MVC.

After reading the article, it make me start to questioning. The Ivy Framework, the one my company is using as a ground-up for all project, is stating that all Rich Dialogs are developed using MVC. Really? I start doubting from a long time ago if it is true. The Model of the RD is just a simple data structure while all the logic are put in the Logic part and they are tied together very strict. They are hard to test.

So what will I do? I think I should consider whole part of RD is just a View, the model of the RD should be developed first as POJO, then we will start to see the outcome.

Greatness!

Today, when I was riding around the city with my girlfriend as usual, I suddenly realized an important thing and then I asked her:

Kiddie, do you remember a genius who was very poor when he was a child? He had to gather fireflies to make a lamp in order to read books [1]? And another musical genius who had volunteered to serve for free in a theater in order to practice his skills? Do you think they are great because of what they had done or because they was born great so they could do such things?

Her answer was the same as my thought. They had become great persons because they could do great things.

We sometimes look at a person who is famous because he has done wonderful things for the world and admire him for what he has done. We even dub him the word “genius”. But actually what we should respect him is the way he has become the man he is now. Maybe he has to sacrifice a lot, worked harder than anybody else to achieve greatness.

We sometimes are too lazy to do that. Michelangelo said it all:

“If you knew how much work went into it, you would not call it genius.”

P.s: another the post which fit this thought very well “Great man does what lazy people don’t.”

[1] His name is Nguyễn Hiền

Homeless Constants

Today, one of my colleague came to me and asked: “Hey, do we have a place to put a general constant?”. “What?” – I said. “A class, you know, to put all constants that do not particularly belong to anywhere”. Then I looked at him and said: “Dude, we got nothing such as general constants”.

The sad truth is, in our current project, we got a class named GeneralConstants just for putting all those constants in it. It got constants for entity String property lengths (seriously!!), panels’ names, bunch of constants that are irrelevant and only used exclusively with some specific modules. Even worse…

public final static String CLICKED = "CLICKED";
public final static String REMOVED = "REMOVED";

..and why stop if you can have

public final static String BLANK = " ";
public final static String COLON = ";";

It really got ridiculous to see:

String myName = firstName + GeneralConstants.BLANK
+ GeneralConstants.COLON + GeneralConstants.BLANK + lastName;

In my opinion, when you got a constant and wonder where you should put it for others to use. I got just a right place for it: inside the module using that constants and keep it private.

Not all constants are reusable and not all constants should be public. The first time you create a constant, keep it private inside your module and try real hard to encapsulate the use of it. If it really needs to be public, then it deserves its own place.

It should be EntityStringLengths

It should be InvokablePanels

It should be AllowedDialogActions

In case of BLANK and COLON, just use the fucking literal String. It is not making them reusable. It is overkill, too much fine-grained. They produces verbose & hard-to-read code. Moreover, doing this does not benefit you any performance. Please don’t do this.

Next time when you got a constant. Ask yourself:

  • Am I really going to use this constants somewhere else?
  • Could I encapsulate the use of this constants via methods?
  • What should I name the class containing the constant to make everybody know what it is?

Thoughts when reading How to Win Friends and Influence People

After reading section “Twelve Ways to Win People to Your Way of Thinking”, I recalled that I’ve applied the principle “Start with questions to which the other person will answer yes” months ago with one of my colleagues.

At that time,  my team was working on a project with another team, they started first and later we  joined. At first, the way we created & updated the database actually sucked. The first time when I looked at the sql files, I had no idea how to run those. There were sql files and batch files to run the scripts and one could not know which one to run first just to look at them. So we had to run back and forth to ask the other team for support.

So I decided to sit down and re-wrote all those scripts and batch files with one thing in mind: I just wanted to make me and my team setting up the database as fast as possible. Finally I did came up with a solution and implemented it. But I needed the confirmation of the other team to follow my new way of hanlde updates of database.

I wrote an email to express my solutions and listed what we (both team) could benefit from doing this. The solution was creating two folders: initial and update. The folder initial contained all the scripts up to this time and a batch file to run all those script. And the updates will have sub folders whose name is a combination of both team’s sprint numbers. At every sprint, we put the update scripts into there appropriate sprint folder and I wrote a batch file to run those script at every sprint or run all of them.

The Scrum Master of the other team agreed with most of the points in the email but he still wanted all developers must added the changes into both places, the old scripts and the new scripts,  just to make sure there was no problem.

He, the Scrum Master, was not an easy-going man. So I decided to make an private Skype conversation with him to convince him not doing that. At first he did not agree. He insisted that all developers must do so because that makes everything in sync. The conversation went like this:

Scrum Master (SM): No, we have to keep updating the old script with ALTER and then add the merge the update into the brand_new_update. So if we run the brand_new_update, the customer will have a full database. We just run the old script with the updating parts.

Me: I have a question: If we run all the initial & update script.

So I asked him if we run the initial first and then run all the updates, did it considered the database is up to date. He answer YES. Then I asked him if two solutions results in equivalent