Taken from the famous book “Domain Driven Design” —
Manufacturing is a popular metaphor for software development. One inference from this metaphor: highly skilled engineers design; less skilled laborers assemble the products. This metaphor has messed up a lot of projects for one simple reason—software development is all design.
How true! I have heard of organizations where designers design and coders code! I would hate to work with such organization either as a Designer or as a coder.
I’v been reading this great book “Clean Code: A Handbook of Agile Software Craftsmanship” By Robert C. Martin. This book is going to be another classic like the “Code Complete” or “Refactoring“. Anyway, I liked and agreed so much with the author about what he wrote about comments that I couldn’t resist sharing a few lines from the book —-
“The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.
So when you find yourself in a position where you need to write a comment, think it through and see whether there isn’t some way to turn the tables and express yourself in code. Every time you express yourself in code, you should pat yourself on the back. Every time you write a comment, you should grimace and feel the failure of your ability of expression.”
When we learned programming in our college, we were told by our teachers that you should always write comment! Even when we joined job, our experienced seniors also told us to write comments! It took me a long time to realize that comments should only be used to document some domain knowledge, writing api/library documentation, not to describe code. If you use comments too frequently in every piece of code you write, you should read all three books I mentioned earlier.
Your code should speak for itself. Period.
Long ago, a very historic unix hacker was surprised to see I don’t know what “Screen” is! Seeing him so excited, I looked into screen. Basically it is a terminal multiplexer/emulator which gives you the facility of multiple terminal over a single terminal screen. Back then, I had just started my career and the tool didn’t seem very essential to me. If I need multiple terminal, I can just open multiple terminal, right! Huh! How naive I was. I didn’t realize the beauty of screen until I had to maintain a production system over a very slow internet connection where I had to first ssh into one machine, from there, ssh into another machine, then do the work. I had to do this for 3-4 terminal just to get going, But that is until I started to use Screen properly. Now I open a single connection and use Screen to emulate multiple terminal. The added advantage is, You don’t loose your ssh session even when your connection goes down, you simply reattach to that session after reconnecting. This is specially helpful when you don’t want to stop your process even if the terminal that spawned the process dies. (You can also use nohup for that).
First install screen:
$ yum install screen
Anyway, here are the screen commands that I use frequently and can help you get started.
1. Start Screen:
$ screen
You will see some greeting message. You can set it off by putting this line in your $HOME/.screenrc file
startup_message off
OK, now you can see the same old terminal screen where you can do anything that you used to do in your main terminal. But keep in mind that, its not your regular terminal, you are actually in the “Screen” application. So this is your base screen terminal with index 0. You can continue your work with it.
Now, If you want another terminal, on the “Screen” terminal, hit
CTRL-a CTRL-c
. You are now in another terminal(this with index 1). To go back to previous terminal, hit
CTRL-a '
(that is press CTRL-a and then press ‘). you will see an emacs style prompt asking your the index: .
CTRL-a CTRL-a
will switch between most resent two terminal.
CTRL-a 1
will directly take you to terminal 1 . Cool! Now you can start as many screen as you want and play around! If you want to list all active screen terminals :
CTRL-a "
Now that you have the very basics of screen, here comes the most powerful feature: Attaching to a previous screen session and Detaching from an existing screen session.
When you are inside screen, press :
CTRL-a d
This will detach you from an existing screen session. To connect back to the screen session use:
$ screen -r
It will connect you to the screen session, But what if you have multiple screen? You can see the screen list like this:
$ screen -ls
Now you can use the screen name to reattach:
$ screen -r mysession
But you surely don’t like the screen name which is provided by default. You can provide a screen session name when you created a screen session like this:
$ screen -S mysession
Now that you get the basics and have the feel for it, you can explore more advanced options like cut/copy/paste , history etc.
I’ll leave that on you to explore.
When I started my career, the first thing I made up my mind about is I have to “Stand on the shoulders of giants”. From the very beginning, I tried to learn from the best coding practices, design patterns, case studies, books etc etc. In fact, there are so much materials around that one has to be overwhelmed! But there are some lessons that I had to learn the hard way. Although they are in the books, I didn’t realize them until I made the mistakes over and over again.
In this series of blog post, I’ll try to share them with the rest of the world. Note that these are not my philosophy, I just think they are the most important among all other principles.
Lesson 1 : Pareto’s Law – The 80/20 principle:
While the 80/20 principle is applicable to a lot of areas, I am only talking about the software modules and codes. If you are involved in a big project, You will see only 20% of the code is performing the core task, the rest 80% is just supporting codes. If you have 10 components in the system, only 2 of them is actually performing the task, the rest are just there to help the 20% (This applies if you group your functionality in a proper way rather than scattering them all around).
We software developers often overlook this, we often put our focus in the wrong place. One thing you need to think about is the Return of Investment. If you claim to be an engineer, one thing that an engineer does is Optimization and Trade Off. Say you are developing a plugin framework – the framework itself is much more important than the plugin. If you have limited time and you try to put equal effort on both of them, you will get none of them right. We always work with deadlines, we never get infinite time, so we have to effectively use that time.
Perfection takes a lot more time than getting something done. You have to make wise decision about which areas you need to perfect and which areas just need to work. Abstraction is the key here. If you have good abstraction, you can always go back and improve your code. I was watching this presentation by Eric Evans about “Strategic Domain Driven Design” for large project where he talked about the same thing. I was quite surprised how our view seemed kind of same! Well, Great men think alike 😉
Anyways, the point I am trying raise is that , we developers become too much obsessed with our code and technology and forget to think about the Deadline, estimation and all these stuff. If you don’t think about ROI (Return of Investment), your project is going to suffer from it. This will even make more sense when you think about Agile development, Changes is requirement and “Throw-away System” from The Mythical Man-Month(Another lesson I’ll talk about).
In the next post, I will talk about the Lesson 2: Abstraction
If you haven’t heard about Domain Driven Design, dude! Its high time you catch up. If you liked the concept, and wonder how to implement it in your spring app, here comes the Sample Application implementing the famous Cargo application from the DDD Book. And the best part is, the DDD guru Eric Evans is the main developer! I have been looking for it for a long time and can’t wait for my maven to finish compiling the code!
I am obsessed with computers. I spend at least 12-14 hours a day in front of a screen, that includes even the weekends. With all the blog posts stored in my google reader, with all the e-books piled in my reading list, with all the news letters marked unread in my gmail, its really hard to stay away. But many a times I couldn’t be online just because I was too lazy/too tired to sit in front of my desktop or my laptop was too heavy to bring into the bed. But gone are those days with my Samsung NC10. This must be the coolest piece of gadget I’v had so far. Now I can power on my pc and go online in about 60 seconds and can do that right after I open my eyes in the morning(my nc10 sleeps right beside my pillow). I can even run my eclipse with terracotta clustering and do the experimental codes!!! What else can you ask from a 1.3 kg laptop with < 500$ price!
Now I realize what I missed all these days. I am hooked with the ultra portable concept and can’t live without one for the rest of my life. If you are someone like me who just can’t keep your hands off a computer, you must get one of these. I am looking forward to get another one with a better processor , May be the Sony VAIO TX series but that is when I can afford them.
Lazy Programmer's Shortcut 