Savio's Notes: Java Book: Effective Java - Chapter 2 - Item 1

The first in a series of notes about the book Effective Java by Joshua Bloch will cover Chapter 2 - Item 1. Some sharp readers would be wondering why not Chapter 1. Those who have read the book will be aware that Chapter 1 is more of an introduction to the book and it also will explain why I didn't make any notes for it. So worry not, you haven't missed anything yet!

Item 1
Use static factories instead of constructors
I never thought of it in these terms, but I had always felt uneasy whenever I used the new operator in code. I always tried to never to use the new operator and have either a third utility class that returned a newly minted instance or have a static method that did the same.

But Joshua Bloch puts it more eloquently and convincingly and here are his reasons:

1. Static factories unlike constructors can have more meaningful names which in turn help code readability
2. Static factories unlike constuctors do need to create a new object every time. They could implement some kind of caching mechanism to enable reuse of instances
   
3. Static factories unlike constuctors can return sub-types of their return types

The book also lists disadvantages of this item as:

1. Classes without public or protected constructors cannot be sub-classed. But he goes on to state that this may be an advantage as it forces the use of composition over inheritance which is further elaborated in Item 14
2. Besides the use of naming conventions there is no way to distinguish a static factory from other static methods in the class

In conclusion the book recommends using static factories unless you are convinced that it dooesn't suit your needs. Alternatively if you are confused go with constructors as they are the norm.

From my part, I will now be trying this pattern more often to put in private constructors and use static factories. Maybe the convention to use would be to have the static factory name as getInstanceUsingXxxx(...)

Savio's Notes: An introduction to a blogging series

I recently got my hands on a copy of Effective Java - Programming Language Guide by Joshua Bloch. I've been meaning to read this book for quite a while now as I've heard nothing but praise from most people I know who have read it. Also, having read Effective C and absolutely loving that book, I'm a little biased because of the title of this book.

So I began reading it and got through the first three chapters and thought to my self: "Hey this is common sense stuff and still there are some common mistakes pointed out too!"

It's always great when someone else (a more famous person than oneself) confirms what one is thinking. Now I'm not trying to say that I've known everything that I've read so far. Quite the contrary I've also learnt a quite a bit of new stuff. Which is exactly why, given my terrible memory I though I should make notes for the same.

Now had I been in the office, I'd have Wiki-ed this. So rather than that, I thought let's start a kind-of series on my blog called Savio's Notes that will track these notes of mine on this and various topics.

As the title of the series suggests, the series is not one that is polished and proper. It is an aid to a quick reference and a summary of sorts of the things I'd like to remember.

I'll use the following convention for the title of the post when I create one that belongs to the series: Savio's Notes: Sub-series: Post title

With that introduction I'll now move to the first post in the series, viz., Savio's Notes: Java Book: Effective Java - Chapter 2 - Item 1 to Item 6

FC 10 - A good distribution that can get better

While helping the Sword CTSpace to set up the office during their transition out of Symphony, I had the opportunity to experiment with FC 10, i.e., Fedora Core's latest release, viz., Version 10.

First impression were excellent. This is a release that just great in terms of ease of use and hardware detection. In fact, up until this release, whenever I installed a version of FC on a laptop, I always ended up removing it because the laptop would never work as it was designed to work.

But this time, I had a new laptop, an Acer Extensa 4620 upgraded to 4 GB of RAM which came with Windows Vista Home Basic, 32 bit edition. The 32 bit edition of Vista refused to recognise all 4 GB and a bit of googling, revealed that this is an inherit limitation of the 32 bit OS.

So the alternative was to get a 64 bit OS on the laptop. Since FC-10 was freshly released I thought of using that and also because a 64 bit Vista required me to shell out more cash.

Well sufficient to say, I've tried it for a fortnight now, and I'm so happy I made the decision. Of course, there are a few things that annoy me, but I can live with them. For the record, here is a list of my failures (only because I gave up) with FC10:

1. Dual display support: I failed with this both on the desktop and the laptop. No amount of R&D and trials & errors seemed successful. Finally from most of what I found on the net was that FC had changed the display related architecture from FC9 onwards and it was still in development.
2. Webcam: The webcam doesn't work, but to be fair, I've not really tried to get it to work. (Now working as per update 3)
   
3. Acer Keys: Some of them worked, like the sound, brightness while others (application quick launches) don't. Most of those that don't I rarely ever used even if I were on Windows. So not a big issue for me.
   
4. Bluetooth: This works sometimes and not the rest of the time. When it does work, it's only for file transfers. I still can't get my Nokia to synch my calendar and contacts. I really miss the way Nokia PC Suite works on Windows and wish that Nokia would get a Linux version of PC suite out. ( (Now working consistently as per update 3)
5. Opera: My biggest miss is that I couldn't get Opera for FC10-x64. It just refused to work. And I'm a BIG fan of the browser. I really miss it and currently get by using Firefox. (Now working as per update 1)

But I still think FC10-86x64 is GREAT! I couldn't think of using something else. Well... Maybe Ubuntu, but I've just gotten used to the way FC works I don't think I'll really shift. And of course there's Puppy Linux. Now that's a distribution that so very cool! I wish, we could have something like that for all our Linux distributions. But till that time comes, I'll stick with FC for my larger computers and keep Puppy as part of my the Emergency Rescue kit as well as for my older hardware and basic browsing needs.

However, my final verdict is still is to say with FC8 if you need stability and don't want to be hassled with cutting edge technology issues. But if your willing to rough it out a bit and learn a lot along the way I'd suggest going for FC-10 and you won't be dissappointed.

Update 1

I finally got Opera to work on FC 10. Yippee!!! Well for the record here's what I did to get it to work.

After a bit of a browse through the forums, I realised that there were a few who go it to work and that there is a special 64 bit version that needed to be downloaded. So back to the Opera download web-site. Unfortunately, the site doesn't recognise 64 bit version of linux correctly and hence I had to manually navigate and select the right version to download. Once done, this would not install because of a dependancy on libXt. When I checked, I had libXt installed and the latest version. Then, why???? Few more tries and it dawned on me... Opera wanted the 32 bit version, not the 64 bit version that I had installed!!! Duh!!! That was strange. So after a yum install libXt.i386 I tried installing opera again and success!!!

A bit strange that opera required the 32 bit library, but I won't complain, because I now have my favorite browser working on my favorite OS!!!

Update 2

Found some good stuff at http://www.mjmwired.net/resources/mjm-fedora-f10.html to help in the setup of FC-10. When used with caution and it is quite helpful.

Update 3

I'm not sure what I did but the webcam has begun to work. I do know that I did a yum update and also installed GYachE Improved an improved client for the Yahoo Messenger. After installing the new client I thought I'll check if it supports the webcam and it worked! I then tried Cheese the Webcam Booth, which I had installed earlier. And it worked this time. So another success on FC-10. Yipeee!!!

I also figured out to get the bluetooth to work consistently. I had earlier set the bluetooth applet for gnome to be visible always. After I changed this to be displayed only when bluetooth was active, everything worked well and consistently!

Update 4

I just managed to get Virtual box to recognize the attached USB devices. However to achieve this I needed to run VirtualBox as root. Which is not what I really want to do. Till I figure out on which file(s) I've not got the permissions on I'll make do with having to run it as root.

svn+ssh setup at home

Finally I seemed to have managed to set up my SVN server to be accessible over the internet using ssh. And I owe it all to the excellent (and simplistic) notes found here.
And I didn't have to open any ports other than the already open SSH port.
Well Istarted off wanting to do it with http, but then thought hey, why open another port, let's get it working with the ssh stuff only. I had tried it once before using these formal instructions but didn't get very far.
Update
I've had trouble getting ssh with keys to work on the home dell box. Turns out it was an incorrect permission setting on the .ssh & key files. Anyways, thanks to this site I traced it out and set the permission to 600 for all the files and to 700 for the directory. Now I can try all the cool stuff I've been dying to try...

Update 2017-Mar-04
Once again, due to system failures and my normal SVN server's desktop refusing to start up I w as forced to migrate my SVN setup to another machine. I imagined it to be a daunting task. but it was surprisingly simple.

I setup the new server on the Samung N150+ netbook. Not ideal, but sufficient for my needs considering I'm patient and cheap. :-)

I've listed the steps below:

1. Ensure svn is installed on the new system.
1. Since my netbook was running fedora 24 I had to issue the following command "dnf install svn". Of course, since I'd installed it before there wasn't much more to be done.
2. Ensure OpenSSH is installed.
1. The command "dnf install openssh" confirmed that I had it installed.
3. Ensure SSH is started at boot time.
1. The command "systemctl enable sshd.service" took care of this requirement.
4. Next I copied over the repository from the system that refused to start.
1. Since my old system refused to start, I un-plugged the HDD containing my SVN repository and took it out of the system.
2. Fortunately it was a SATA drive.
3. So I took the Seagate external HDD that I had and removed the adapter from it.
4. Next I plugged the internal HDD into the adapter and voila, I was able to access this drive using the USB.
5. Then copying the repository across was a piece of cake.
5. Finally, I created a sym-link to the repository using the command "ln -s /path/to/actual/svn/directory /repository"
6. I was able to validate access to the repository with the command "svn svn+ssh://localhost/repository list". And I got my repository listed out.

During the time it took to copy the almost 60GB repository across (to another external USB HDD) I was able to update this blog post and still had time to spare.

Code Reviews

I've been asked repeatedly to document what I look for when I do a code review. While I've never been able to give what I think is a good verbal answer before, what I'll attempt to do in this post is to list down all the things I try to look for during a code review in no particular order.

1. Spelling mistakes: Though calling a variable currentValue or currintValue does not really harm the logic it just makes code look less professional and harder to read and understand.
2. Copy Paste errors: This is something that is most often overlooked and can cause so much of pain when debugging. Getters and setters that are copied & pasted and the variable being accessed/modified isn't. Error messages and codes are copied but not changed
3. Feature correctness: Probably the most important thing in a code review is the answer to the question: 'Is the requirement met?'. Other questions include 'Is it met correctly?' and  'Are the conditions correct?' While reviewing functionality, I usually look at breaking the logic/conditions using negative scenarios.
4. Code reuse: If the same line(s) of code are used in more than one place, it should be refactored.  New methods or new variables need to be created to ensure no two lines of code are exactly the same.
5. Code reuse: Are there existing API's that do the same thing. Can existing API's be tweaked to do the same thing?
6. Documentation: This is another thing that does not affect functionality. But documenting what is being done is very important. Most of the time the question I get is what should I write in the document.I usually ask a question in response: "Tell me what this code does?" And I've always received a great answer from the code-owner. I then tell them to put what they just told me into the documentation. To sumarise the documentation should contian what is being done. How it is being done can be found out by reading the code.
7. Assumptions: Are the assumptions made valid both from a business as well as a technical point of view? Are null values handled?
8. Tests: Is there enough of coverage? Is there a test that fails without the fix? In some cases especially old legacy code makes it hard to write tests. In this case documentation becomes more important. Not only in the code, but it also needs to be informed to QA and a test-case added by QA for their regressions. An update to the bug-tracking tool too becomes mandatory.
9. Conditionals: Remove if/else/switch statements by extracting the logic in the conditions into external classes. Let polymorphism handle the decision making
10. Simplify logic: At every step I look at reductions. Reduce lines-of-code, reduce instances used, reduce complexity. The KISS principle is the guiding force. For the unaware KISS stands for Keep It Simple & Stupid!

The biggest issue with performing code reviews is time. To reduce the time lost in reviews, here are a few suggestions:

1. Code formatters: Today's code formatters have advanced quite a bit and they can be configured to automatically take care of coding conventions and simplistic documentation.
2. Checkstyle: This will highlight coding convention deviations at the time of writing the code itself. So the developer can take care of this at the time of writing the code itself.
3. Developer feedback: The developer should highlight areas of code that need special attention and deviate/change generated code.

Other than time is to imbibe into the developers the habit of performing peer reviews. Peer reviews provide the following benefits:

1. First level of code reviews
2. Learning new coding styles
3. Sharing knowledge across the team. This includes domain knowledge, API knowledge, best practices, implementation styles, etc.
   

Installing a Jacuzzi

Recently we installed a bathtub-cum-jacuzzi at home. I learned a lot during this process and thought of using this post to highlight the same.

First let's give credit where credit is due:
Replacing a Bathtub
This web-site provides excellent step-by-step instructions and diagrams to guide a DIY enthusiast.
How to Install a Shower/Bathtub
This is less illustrative than the previous link but still contains a bit of useful information
How to Plumb a New Bath Tub
This link collaborates and confirms most of the information provided by the other two sites.

Now my 2 paise:
We decided to go with a 6 feet by 2.5 feet rectangular bath tub. We also added a six nozzle jacuzzi, three on each of the two longer sides of the tub. The tub is about 1.5 feet deep.

We started with this project because of a leakage from the bathroom into the one below which required us to remove and completely redo the waterproofing of the bathroom. Since we were tearing the bathroom apart it only seemed like the right thing to start this long overdue project.

Waterproofing the bathroom involves laying concrete followed by a layer of brick-bat, which is bricks along with a tar-like-substance. The bricks are added to absorb an water that might find it's way into this layer. Another layer of a plain cement concrete goes over the bricks. Once this sets then we kept water stagnant in the bathroom for a week to ensure there were no leakages. We also added dyes to the water and changed them out. First we started by adding blue ink to the water and then we switched over to red as the bathroom below already seemed to have a bluish tinge in the celling. (Probably from our previous tests to see the source of the leakage)

Having resolved the leakage problem, the next step was to place the tub. This is tougher than it sounds. Not only is the bathtub heavy it is also bulky with no place where one can get a good hold. We were three guys struggling to get it in place.

The layout of our bathroom did not allow us to place the bath-tub directly on top of a P-trap and hence we had to get an elbow assembly. A word of caution here, a standard CI elbow will not work as we learned the hard way. We ended up getting a Jaguar bathtub elbow fitting.

All plumbing joints for a bathtub should be able sealed. This includes the drain system. Because of the volume of water flowing it would be advisable to have threaded and/or sealed joints. However only using a sealant like M-Seal or car-patch is useless and will not withstand the pressure.

Once all the leak proof drainage is bought and tested it will be time to set the bathtub in place. First, put a layer of bricks and mortar. Though we didn't do this (I though of it after we finished), my suggestion would be to create a single brick platform along the complete area the the tub would rest on. Next, create a border with bricks such that the base of the tub will fit into this border. It does not need to be a tight fit. The idea of this border is to create an area for containment of a PCC slurry. Fill the PCC into this area and then lower the bath tub into this. IMO, this will allow the PCC to fill in any gaps that could exist below the tub thus giving it all the support it needs at the bottom. Since we did not do this, now when we stand at certain place in the tub I can feel the bottom flexing under my weight.

Having laid the tub's foundation, now place the tub gently over the wet PCC slurry. Tighten the drain and over-flow outlets and pay special attention to levelling of the tub. Even though we I did pay attention to this, the tub may have moved and we now have a small area of the tub that does not drain out. Test the levelling with a mug of water and ensure it all drains out.

That's it!!! Let it set for a day and the following morning your tub should be ready for use.

Another suggestion, when testing the drainage joints, block the outlet just before the P-trap (Nani trap). This way you test the complete drainage plumbing too. Most plumber will use the bathtubs drain plug to check for leakages which doesn't let the water enter the drain system at all. Plug the outlet in the P-Trap itself or if possible block the P-Trap to enable a thorough testing of the drainage system. Remember this is a bathtub which will contains tens of liters of water. Once this water gets into the drainage system even a tiny leak will not take long to become a major one and cause you a major headache in future. Everything should be absolutely dry!!! 

How important is the UI

Sameer made a good point about the UI being ignored by most designs. In fact I find this very strange. As far as I understand the client or the end user firsts sees the UI. Only when that is fine do the they evaluate the other things like performance & stability.

This is not only in software development. It's in every aspect of consumerism. When you buy anything, it's got to look good before it attracts you. Only after the first impression attracts you do the other factors come into play.

However, having said that, only a good UI will not clinch the deal. It's just the first step. Can you even think of buying a good looking car that performs terribly. In short, I disagree with Sameer that only the UI matters. No, the UI is 50% of the battle. The other stuff is the other 50%.

However what I think Sameer is trying to get at is that the UI though only cosmetic requires a large part of the time and effort and if not done well can screw up even the best and most stable and robust of applications deliveries. And the vice-versa is also true, i.e., a good UI actually makes the client happy and willing to be patient on the other stuff.