Skip to main content

Craftsmanship

It was a busy month, all work no play... more about polishing, both code and UI, to make a better product.

1. Code Polishing

In the current Java Spring project, there are a few things worth mentioning.



1. Service layer for MVC.


My previous projects are mostly architected under MVC pattern. There is nothing wrong about that. However, when the logic gets more complexed, handling all the logic in the controller layer would not be as clean and efficient. Another layer named Service for better data access and logic control is used in the our project. http://stackoverflow.com/questions/5702391/mvcs-model-view-controller-service


The controller would not be handling too many logics, instead, it only handles routing and  parameter passing. Most logics will be handled in the service layer.


2. Exception handling vs error codes


In the beginning, I didn’t do any exception handling in the service layer, neither do I create many exception handlers in the controller layer.After reviewing my peers codes, I realize that it is more elegant to throw exception than returning error code. http://stackoverflow.com/questions/253314/exceptions-or-error-codes


In the project, we used exception handling in the service layer to return exceptions which are inherited from IOException. I found the logic clearer after shifting to the exception handling idea in my codes.


3. Bad thing about lazy fetch type

In hibernate, it specifies the lazy fetch type, which is intended to reduce database memory access for relationships such as @OneToOne, @OneToMany,  @ManyToMany ,etc.
In the following blog post, the author stated some good explanations about the difference of each fetch type. http://howtoprogramwithjava.com/hibernate-eager-vs-lazy-fetch-type/


FetchType.LAZY = Doesn’t load the relationships unless explicitly “asked for” via getter
FetchType.EAGER = Loads ALL relationships”


However, lazy can be very troublesome in some circumstances. I had a lot of null pointer exceptions when trying to get lazy type relationship entities. I've got to manually parse these relationship entities into Map before sending them to the view, which makes the code very dirty.

For instance, in the following code, I want to get all users and their associated roles. Simply get the user list array won't return the roles because of the lazy issue. But I still need to display the associated role information in the view. I've got to use the ugly way to parse the role list into strings before sending to the view. If you know any better approaches, please let me know. Thanks!
    public List<Map<String,String>> getUserList(){
        List<Map<String,String>> userList = new ArrayList<>();
        List<DashboardUser> allDashboardUsers = Lists.newArrayList(userDao.findAll());
        for (DashboardUser dashboardUser : allDashboardUsers) {
            Map<String, String> aMap = new HashMap<>();
            aMap.put("id",dashboardUser.getId().toString());
            aMap.put("email",dashboardUser.getEmail());
            aMap.put("username",dashboardUser.getUserName());
            String roles ="";
            for(Role role:dashboardUser.getRoles()){
                roles+="/"+role.getName();
            }
            aMap.put("roles",roles);
            userList.add(aMap);
        }
        return userList;
    }
2. UI polishing


Switch to angular.js.

Previously, the project is developed under jQuery. The views are not structurally organised, until it becomes quite a messy.The team decided to use angular because it’s clean and structured. After one week's polishing, the codes become much more beautiful, both in the front end and the backend.


I may write another blog about angular when the project gets more polished.

3. Project management


1. We tried to explore the scrum 
meeting(http://en.wikipedia.org/wiki/Scrum_(software_development)) inside the small team. It works quite good. The basic scrum workflow consists of sprint planning, daily scrum meeting and end review meeting.  

The daily scrum meeting is not hard to follow. We started the meeting at 9:45am for <=15 minutes everyday at the same location asking the following questions:

“1. The basic What have you done since yesterday?
2. What are you planning to do today?
3. Any impediments/stumbling blocks? “
The tasks will be noted down by the scrum master and posted on a public wall. It makes every one involved and aware of the progress.

2. Github feature branch

Previously, we develop the features under our own develop branches and make pull requests to the origin develop branch when a new feature was added. However, that’s not a good design. The new feature commits are mixed with the develop branch and you can hardly distinguish which features are added by whom in a structural manner.

Thanks Peng jun and Xu Fan for sharing this. 

http://danielkummer.github.io/git-flow-cheatsheet/

Another tip for using github is to use git stash for saving unfinished changes in the current branch before switching to another local branch.

Comments

Popular posts from this blog

InnovFest 2015

I attended the innovFest 2015 event. It was quite eye opening. Besides the booth, some topics in the forums also interested me. The first topic I joined was the Kopi Chat with Yossi Vardi, a famous Israeli entrepreneur and investor. He is straightforward and humorous. When talking about the most important reason why people wake up with a great idea but ended up sleeping without executing anything, he collected answers from the audiences. One answer pretty much fitted his appetite-- "People fear about losing faces". He shared his opinion with the quotes from Theodore Roosevelt, “It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually st

Challenges are just getting started

It's my first month working with real projects(my real, I mean something that's going to be used by the public). It's so different from school projects. Every detail matters, from the backend logic to the page buttons. These two weeks, I worked closely with two talented designers, one from a well-established startup company named Umeng Analytics and another doing his own startup after quitting a mobile gaming company named HappyLatte. I know the first designer,PJ, in a hackathon. He is really talented, should be the best designer I've ever worked with so far. I persuaded Prof.Tung to send me to Beijing to work with him on the first prototype and it turns out to be a right decision. He is not only good at design, but also good at UX. He reads a lot. He already came up with a wireframe of the project. Next week, he's going to finish designing the first round of UI design(around 15 pages). The market price for a very good designer is around 5k RMB(1k SGD)/page, however

2018 New Year Resolution

This year, let me try to draft the new year resolution based on the Willpower Instinct: Step 1:  List down the best things of the past year. 1. I proposed to my fiancee when she and her mum visited Singapore in July. We were then registered as officially married on her birthday on 28th Nov in Beijing. It was really the most important event of my life so far. After years' of long distance relationship, we finally made it. Though it will still take her another half year before coming to Singapore, we were both thankful that we really made it. 2. I bought my own apartment. It was a tough process to look for properties. I was so happy when I received the keys. Before that, I shared with my bedroom with my room mates for 3+ years. 3. Fooyo's sales was quite satisfying. We has two big customers, one in the Tourism Industry and another in the Logistics Industry. The products we produced were pretty pioneering and beneficial to the industry.  4. Fooyo succ