Saturday, November 9, 2013

Programmer's Diary: Interface Naming

This is a repost from my old blog. Original post date March 15, 2013


There was a twitter thread recently about interface naming. How should you name your interfaces? "IProduct" or "ProductInterface" or in another way? To my surprise the majority of the people who replied to that thread suggested "ProductInterface" and than "IProduct".

I suggested simply "Product".

In my view an interface should be named to reflect an abstraction. When you decided to make an interface you had a good reason to do so. If you didn't, your interface has no reason to exist.

In most cases interfaces abstract a higher, more general concept and they have several implementations. Of course, you can't write two implementationa at once, so at the beginning you will have only one implementation, then when you need another you will have another one.

Let me give you an example from our code at work. One of my colleagues, +Vadim Comanescu , wrote some logic in our application to handle sockets. At the moment of writing it, he defined an interface for the socket. He called it "Socket", no "I"s or "Interface" in it's name. Back then there was only one implementation to it "HttpSocket". It was great, it worked well. Today we needed to use our networking logic and communication modules over a UNIX socket. The solution was simple and done in just a few minutes. We created another implementation for "Socket" called "UnixSocket" and everything worked perfectly.

When we name interfaces we think about the clients, the other classes that are using our interfaces. In our networking module at some point we have something like "function writeToSocket(Socket $socket)". This is obvious. It looks great, it sounds logic and it is easy to understand. And one great thing there is that the client does not know that "Socket" is an interface.

Interfaces belong to the clients and not to their implementations; said Robert C. Martin and I totally agree. In the same way interfaces are like any other classes for the clients. What if you decide to change your interface into an abstract class. Very possible. After a few implementations you observe common code throught the implementations and extract it toward a Template Method design patter. Then... you have to change the name of your - now abstract class - interface into something else. An abstract class called "SocketInterface" has little sense.

And finally, a last thought, "Product" is a great name for an interface and it can be implemented by many many classes representing real-life products, for example "Keyboard" or "Mouse". However, there are some rare cases when you need an interface and you will have only one implementation. In those rare cases, I prefer to name well the interface and add "Impl" or "Implementation" to the the implementing class' name. This has more logic since the programmer writing the interface is most probably the one writing the implementation. However the programmer using the interface may be someone else from a totally different team or company or country. Why should that programmer of the client code know that "Product" is an interface or not. What if at the beginning it was a real object and the original programmer decided later that it should be an interface to better accommodate different implementations inside the "products" module? Why should the clients care? Why should they know?

If you are using a dynamically typed language, like PHP, there is almost no real reason for creating an interface that has only one implementation. Period. You have only one implementation and you are sure you need no other ones? Drop the interface.

Friday, November 8, 2013

Programmer's Diary: Just Good Enough


This is a repost from my old blog. Original post date June 8, 2013.

Some people are sloppy and they are doing too little. Others are perfectionists and they are doing too much. I think the best is to be somewhere in-between, to be just good enough and to create what is just enough. At least this is what I am trying to do each day.

But, doesn't "just good enough" means you are doing only the minimum necessary? Not at all. As any coach would say "it depends".

In most cases it takes the same energy to build something 80% perfect as it takes to build the remaining 20%. Closer you get to perfection harder it becomes to achieve advancement. I did no studies, it's just how I feel about what I do. Now, the question comes: "Is 80% good enough?" sometimes it is, sometimes it is not. If 80% satisfies 95% of the users of the product you are building, you did it. You may want to stop there and start a new product or a new feature. Let time and user feedbac guide you on the remaining 20%.

Other times 80% is not enough. If you build a car and you are unable to provide wheels, you are doomed. Nobody will buy your car. In that case you need some extra percents to achieve a minimum viable product.

The hardest thing is to find the 20% that is both difficult to create and also has little or no interest for the user. I have no recipe to solve the problem but frequent retrospectives on my own activity, feedback from others and some objective analyses can do miracles.

I am always trying to figure out where this good enough margin would be. Based on user feedback, or feedback from my colleagues, boss, wife, friends, etc I try to set for myself a little higher than expected targets both in my job and in my daily life. I always try to provide a little more and keep doing it in a consistent manner.

While this is mostly a good strategy I found that with higher quality comes higher expectations which in turn leads to even higher targets for my "good enough". And that's perfectly natural. What I find the hardest though is realizing when you are doing too much and have to take a step backward. Doing more and more each day will at some point hit your physical limits. When that happens you have to take a step back, take things easier for a while and adjust both your and your users expectations.

Only then, you can get back on track.

Thursday, November 7, 2013

Programmer's Diary: Usability Failure

This is a repost from my old blog. Original post date June 9, 2013.

My wife suggested to try and buy eggs from an egg dispenser (vending machine). Not exactly the model on the right, but something similar.

Even though we finally managed to buy the eggs, it was quite an interesting experience. First of all you start by pressing a button to rotate the internal shelfs so that what you want lines up with a sliding door. Each shelf has it's own door.

Than you have to put in the money. We first tried with a 10RON bill for a 3.5RON package. It just refused to take the bill. I can only presume that it had no way to give me the change and this was the reason for the refuse. However there was no indication of such a logic. And yes, I tried a couple different 10RON bills.

Then we went on and found 4 pieces of 1RON bills. After some trial and error it accepted all 4 of them. However I was required to try at least 10 times to insert them. Again, there was no feedback from the machine about the reason why it refused my bills.

Another problem was that there was no way to cancel the operation. So if I inserted 2 bills with success and then if it refused the other 2, I would have no way to get my money back.

Finally I had all my money inserted, a total of 4RON for a 3.5RON package. Now, there were about 10 shelfs with 10 doors. Only 1 or 2 doors actually had any products on them. The trick was that the machine had no idea about which shelfs are full and which one are empty. You had to open the proper door and only that. If you, by mistake, opened a door to an empty shelf, bye-bye money... At least there was a red text with an attention sign telling me this. But I totally think that the decision should be the machine's and not mine. If there is no product on a shelf, just don't let me open the door by mistake and loose my money.

I am wondering how many people can actually use this vending machine without falling in any of the above described usability traps? If you are a software developer or some kind of user interface designer, being it physical UI like a vending machine or a purely virtual one like an interactive web-page, keep in mind that we, the users, just want things to be done quickly and as painlessly as possible. Don't put traps and tricks in our way because we will not use your product the second time.


Tuesday, November 5, 2013

Programmer's Diary: Extract Variable NetBeans Macro

This is a repost from my old blog. Original post date June 14, 2013

I've got tired of manually extracting local variables so I wrote a little macro to do the job for me. Just copy-paste it into a new NetBeans macro, and add a shortcut to it.

Then, select the code you want to put into a variable, hit your shortcut and watch the magic happen.

---

cut-to-clipboard
split-line
caret-up caret-end-line insert-break
"$newVariable = " paste-from-clipboard ";"
caret-down caret-end-line "$newVariable"
caret-down caret-begin-line
selection-begin-line rem


---

Monday, November 4, 2013

I Just Visited the Most Unique Waterfall in the World



This is a repost from my old blog. Original post date August 26, 2013.

Last week I was watching the news on TV just to discover that according to THE WORLD GEOGRAPHY the most unique waterfall in the world is just about 150 km away from where I live. Being so close it would be a sin not to go and see it. So last Sunday my wife and I went on a drive to visit Bigar Cascade Waterfalls.


The largest city in it's vicinity is Timisoara, where I live. The waterfall itself is located near a small village called Bosovici, exactly on 45 Paralel. There are several ways to get from Timisoara to the Bigar Cascade Waterfalls.

  1. The shortest road - Timisoara - Moravita - Oravita - Bigar. It is the shortest road but unfortunately about 1/3 of it is in pretty bad shape. The road is all paved with asphalt, but about 50 km between Moravita and Oravita was repaired so many times that you will not be able to recognize the original layer. It will shake you quite hard. Even though you can go quite fast (80-100 km/h) it will not allow you to push as hard as you would like. The portion Timisoara - Moravita is in very good shape, but being a road that leads to the border with Serbia, it is quite heavily used and again you will find yourself blocked behind some slow car and you will not be able to go fast.
  2. The longest road - Timisoara - Recas - Lugoj - Resita - Anina - Bigar. It si about 30-35 km longer than the first option. It has very good road and asphalt quality. The only drawback with it is that Timisoara - Recas - Lugoj is one of the most heavily used roads in the country. So that 60 kms will be pretty uncomfortable to drive.
  3. The one I recommend - Timisoara - Buzias - Lugoj - Resita - Anina - Bigar. This is the one I recommend. Road and asphalt quality is very good. It is not heavily used so you will be able to drive at your own pace all the way to Bigar. It is about 20-25 kms longer than the first option but it is arguably the fastest way to get from Timisoara to the Bigar Cascade Waterfalls. It is also the most spectacular road. You start your trip on plain. Then you go through forests, then hills, then mountains and canyons. The most spectacular part is Anina - Bigar where you will be able savor abrupt serpentines on high altitudes in canyons and mountain forests.

But this should be a story about Bigar. Near the road, following some hand-painted road signs you will find a small waterfall hidden in a valley. The easiest way to recognize the entrance is the big 45 Parallel sign "Paralela 45", a big white road sign with blue letters. You will have to pay a visit tax of about 1 Eur for 2 persons (5 RON). A small bridge over the valley will lead you just above the waterfall to a tiny, beautiful miracle of nature.


On one side of this valley is the Bigar Cascade Waterfall in all of it's glory.


After you are tired of hiking on the rocks around the waterfall and taking pictures and admiring this wonder of nature you can get on a short trip (100m) in the forest to find the waterfall's water source.

 

Just follow the water and the path laid to you.

 

After a few minutes you will find the cleanest water you've ever seen. Just perfect for drinking as it surfaces between the rocks.


That's it folks. The Bigar Cascade Waterfalls and it's source.

If you have time and mood after visiting the Bigar Cascade Waterfall you can go and see some of the oldest water mills of these mountains located in and just after the village called Eftimie Murgu, 15 km distance from Bigar. There are 22 small mills, you can visit about 10 of them. It will take about 1-2 hours to walk near the river and find the mills, so be prepared for a long walk in a quite spectacular mountain landscape.

The mills are small, made of wood, and located in the valley created by the water.

They are all similar but slightly different. The most known characteristic of these mills are the horizontal wheels turned by the water.

 

So, if you happen to be in this part of Romania, the Bigar Cascade Waterfall and the water mills are certainly a great place to visit and spend a day in the mountains with spectacular panoramas.

And finally a little warning. Unfortunately we could not find a single decent place to eat. Nor near Bigar or in Bosovici or on the road. So be prepared with some food for the day when you live from Timisoara.

Friday, November 1, 2013

Programmer's Diary: Zombies and Phantoms

This morning when I checked our continuos integration system I spotted that our integration tests are running since a long time. This is unusual because they should finish in 3-4 minutes at most. After some investigation made together with a colleague of mine, we discovered there were about 2000 zombie processes on our build machine...

An hour before the end of this Friday working day I realised that after the changes we made lately to our software, the notification mails telling that a disk pool has been imported missed a key information: the pool's name! It seems like it turned into a phantom and vanished...

... after all, it's 1st of November.