The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
Almost all of us know the GoF patterns. Perhaps not all of the patterns. I forget them from time to time, but with more experience, I remember more and more. (I keep forgetting what a Memento is. 
)
As important as they are, I think there are other, perhaps more important patterns and principles that I follow. Some of them are “in my head” when I code. Some of them are there and I just follow them without naming.
They are fundamental theorems/patterns/principles of programming.
Good idea to review them.
Good idea to write about them.
Good idea to revisit them.
Don’t you think?
Languages and trends pass by. Principles and how we approach our programming tasks stays with us. Forever.
I’m currently deep into Python. Design patterns I learned earlier still apply. I learned JavaScript a while ago. Same thing.
I feel it’s not the languages we know count. It’s how we go about doing the tasks we have on hand. It’s how we craft software no matter what tools we use. Python is good for one thing; Java for other; and Javascript still for another, but we can apply “our learned way” to all of them.
Once we have solid principles in place, we’re able to reuse it from language to language. Deepening and improving that knowlege has the highest return, I feel.
So I’d like to revisit SOLID principles; GRASP patterns. They’re at the heart of programming. Close to my programming heart, at least. More to follow.
Uncle Bob in Clean Code states, “the Boy Scout Rule tells us we should leave the code cleaner than we found it.” Another words, when we make changes to the code base, we should make sure we are leaving it (checking in to repository) cleaner.
The original rule of the Boy Scouts states: “Leave the campground cleaner than you found it.”
This is very relevant to the way we code!
Following this rule is not easy. In some cases it might not even be possible (most likely not a good sign).
Why isn’t it easy?
When I code, I try to follow similar, but fundamentally different rule: don’t make the code base worse than you found it. Worse, not necessarily better. Following this rule is not easy either. It means I have to get a good understanding of the code before I make a change. It means I don’t try to put in a quick fix or a hack, add special exceptions (wouldn’t it be easy to just add a simple “if” statement).
It all starts with one broken window, as the theory of a broken window tells us.
The Boy Scout rule takes it a step forward. It requires you to not only understand the code, but improve it before you check your code in. Just the other day, I saw something that smelled. It had a lot of duplication. My task was to add something similar. Since code was already written, somewhat complicated, I went with the easy route. I followed the same route: I added more duplication! I didn’t necessarily make the code base worse, as it’s already been like that. But I didn’t make it better either.
I did not follow the Boy Scout rule.
If I did, I would have taken the time to refactor the code, generalize it, and make it reusable. I would have removed the duplication and made it easier to modify later on. Read: I would leave it better than I found it.
I’m already feeling resistance. I’m thinking about situations where it might not be possible to follow the Boy Scout rule.
Resistance is good. It means that I have some growing to do. It means that following this rule is…
A challenge!
Yes, it’s going to be a challenge. But the reward is there. Making improvements to the system you’re working on is a reward on its own. Talking about this in an interview should also get me extra points. But most of all, following the Boy Scout rule will make me work harder. It will make me a better programmer.
I’ve been quiet on this blog lately. I’ve been quiet in 2010 as a whole! Only 5 blog posts during the year. That does not make it too active, I must say. As new year’s resolutions go, I plan to change that.
Starting from this week, I set a goal to write a blog post per week. But wait, I have 4 blogs (click Home to see them). So that’s roughly 1 post a month. That should at least double the postings in 2011.
In 2010 I changed jobs. I am now involved with pure Java development, which I love. But it’s also a nice change from using Java sparingly, mostly coding Velocity templates — not too say you cannot get creative, but it’s a “contained” circle. I am now “free” and that should lead to more interesting ideas and topics.
What am I up to lately? Deepening my Java threading knowledge, and Java in general. (I just got an idea for a separate post on this subject. )
What are my plans for 2011? I plan to deepen my Java skills. Java 7 is around the corner (finally!). I’d like to improve my Spring knowledge — if you don’t use it you lose it. Guava — a google collections library. I’d like to learn that as well. I mean, I’d like to find uses for it. I also want to learn bash scripting. Never learned it, but coming across it very often. Time to dig deeper. If time allows, I also want to learn Python. Seems like it should be in my toolbox. I can perhaps combine it with Google App Engine application. Sounds cool.
2011 should be a busy year.
How am I doing it? How do I find the time? Early to bed, early to rise… said Benjamin Franklin. And that’s exactly how. I wake up at 5:15am everyday. And I try to collect at least 2 pomodoros (25 minute sessions, with 5 a minute break; check out ChromoDoro in Chrome) reading, practicing — doing dev-improvement stuff. That’s how. It works for me.
I started learning design patterns a good number of years ago. I learned a few. Probably around half. But others I just kept forgetting. Or I should say, never learned. 
C’mon, you did not learn design patterns!
Knowing design patterns is important. Very important. It’s probably the best “tool” in your toolbox as the developer. Not only the Gang of Four (GoF) patterns, which are the most known, but others as well.
But learning design patterns is hard.
It’s not that the design patterns are hard, it’s the process of learning and retaining that’s hard. Why? If you don’t use it… you’ll forget it.
So a month or two ago, I decided to revisit the subject. I decided to learn the Gang of Four (GoF) patterns. Learn it in a way so I can remember. As I said, not an easy thing to do. (I guess I will really know if I learned it after a few months. )
There is probably only one way to really “learn” it. Use it in code. That’s when you see the context, problem, solution, etc. That’s when you really know all the details about the pattern. And most likely it will “stick” with you and you will not forget it.
If you really want to learn a pattern, use it!
If you can…
I have a few that I have used: Observer, Factory, Builder, Singleton, Facade, Strategy, Template Method, Iterator, Command… I think that’s about it.
OK, that’s less than half of the 23 GoF patterns. What happened to the others?
Blame it on my memory.
On the other hand, I don’t want to just use it because it would be cool. It has to be the right fit. And that does not happen often… But when you do see the opportunity, you should be ready!
BE PREPARED
How do you prepare? Here are some ways.
Read the GoF book several times. OK, that might work for you. For others, it probably will not.
Read multiple books. Yes, that’s probably better, but it still could not work for some of the patterns.
Read multiple books and other references at the same time. Yes, I think this is better. Much better. Why? In How To Read A Book the author explains that this is the highest level of reading, Syntopical Reading. By reading multiple authors on the same subject you have trouble understanding, in this case, it might be a particular pattern, you gain the highest level of understanding.
So that’s what I did: I started reading mutliple resources on GoF Patterns at the same time.
Of course, it would be ideal to have ALL the books available on the subject. I don’t. But I have several and that’s a big help. I also have a subscription to Safari (as part of being ACM.org member), and they have a few books there as well. And of course there is the Internet, loaded with many great references.
I started with the classic GoF book. As I read a pattern, let’s say Abstract Factory, I picked up another book or looked at another website. I read a few until I really “got it.” I also looked at code samples. I read some more. Eventually, I got the “aha” moment.
I’d like to share the resources I have used and that I find valuable on the subject of the Design Patterns. Just so your learning will be, let’s say, a bit simpler.
It’s already taken me a long time to get to this point. So without further ado, here they are.
BOOKS
Design Patterns by Gamma,Helm,Johnson,Vlissides
There is a reason it’s the classic book. Start your learning from this book. The explanations, reasoning and usages are the best in this book. But it’s not an easy book to read. In fact, I think it’s hard if you’re not a C++ programmer. Still, it’s a great book.
Refactoring to Patterns by Kerievsky
I appreciate this book more now than when I first bought it. Filled with very good advice. However, it only covers a few of the GoF patterns.
Agile Software Development by Martin
My favorite book. Not on Design Patterns in specific, as it also does not cover all GoF patterns, but still worth checking out the few that it does cover.
Head First Design PatternsAvailable on Safari, this book is loved by many, not so by others (including me). But still a great book on the subject.
WEBSITES
Wikipedia: Design Patterns
More than anything, it contains great examples.
dofactory
(claims to be #1 in design patterns). Valuable resource.
Houston Design Patterns
Great resource on design patterns.
Examples of GoF Patterns
Lists places in the JDK where the patterns are implemented.
INDIVIDUAL PATTERNS
Bridge vs Strategy
If you get stuck like I did, check out this url.
Factory Method
Good examples on how to implement the pattern.
A few years ago, Cedric Beust, had a blog entry with the same title. I saved it. Here’s a summary of what he recommended for staying sharp:
- Reading (a lot of reading) is certainly a great way to accelerate your skills
- Studying other languages is also a fantastic and fascinating way of learning new concepts that change the way you think.
- Spend time with “curious” colleagues.
- Practice. Find the time!
It’s a very good entry. You should take the time now and read it.
How do you stay sharp?
I think it’s safe to say that you are not going to stay sharp by not doing anything. But that, I mean, just going to work and doing what’s required of you. Sure, it can happen, but imagine how much sharper you would be if you did something in addition to that.
To be honest, I don’t know a definite answer on what’s the key to staying sharp. There are different ways that can work for you. Rather than trying to tell you what you should do, I’m just going to explain what I do.
I’ve tried many things over the years. I would say that I’m an aggressive type. I spend a lot of time on learning and improvement. And I’m trying to adjust as I go along.
So, he’re what I do to stay sharp.
Reading. I think reading is critical. I try to read at least an hour every day. Book reading, that is. Sure, there is a lot of good and helpful material/articles on the web that you can read. I do that as well. I have my list of blogs that I read. I find reading them very helpful. It helps me to know the state of things. But reading books requires you to put the effort and spend some quality time with the book. It also means that the author had put some quality time to make the book. This combination means is more valuable than just reading an article.
Over the years, I have changed the way I read books. I have converted to reading most of the books in the PDF/electronic format. I find that much more useful. And easier. I can take notes. I can read the same book at work without actually carrying it to work. Sure, I still buy a hard copy from time to time, but only the select few.
Practicing. Reading will only take you so far. It’s easy to read. I know. I’ve done that for a few years. I was on a roll, reading 300+ pages per month. But I noticed that I am not learning that much. Certainly not as much as I’d like. Plus, the rate at which I started forgetting things concerned me. Why is that? Just reading is not enough. Reading something just once might not be enough as well. I am in the process of modifying this cycle. It looks more like this now: Read. Take notes. Practice. Re-Read. Notes. Practice. Do what works for you. One thing is clear: by reading alone you’re not going to grow. You’ve got to practice. The more the better.
Doing more with less. This is a recent revelation for me. It’s exciting to constantly move to new things. Have you noticed that getting a new book is very exciting? But after you put the book on a shelf and it sits there for a while, something happens. Your interest in that book decreases after a while. It’s not new anymore. Not in your mind. You have discovered something else that’s new. Maybe you got a different book. So you focus shifts, that new thing is more “interesting.” It’s the same with reading. Once I am almost at the end of a book, I’d like to move on to the next. Even writing a review for that book seems tedious. I’d like to start reading a new book right away. But I have to break that cycle. I noticed that this is one of the BIG reasons why I don’t learn as much as I’d like. I’m trying to do too many things. Not good. Here’s what I am trying to do now to break this cycle. Before I move on to the next great thing, I have to make sure that I really learned it. And that means re-reading the book. That means writing a project based on the new information. That means writing a blog entry. That means creating a wiki/learning page. You see: that means doing more with less!
I know that the old way didn’t work for me. It’s something that I had to change. It’s still too early for me to report the results. It’s not easy to adjust. But I believe it’s the right path for me.
Staying sharp is not easy. But if you read a few books a year, you will learn more than most. Steve McConnell is Code Complete says: “One book is more than most programmers read each year (DeMarco and Lister 1999). A little reading goes a long way toward professional advancement. If you read even one good programming book every two months, roughly 35 pages a week, you’ll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you.” You just have to remember to do something with that knowledge to make it “stick.”
I am excited. For the first time, I can say that Java EE development can actually be fun and cutting edge. Jeremy Norris recently said, and I retweeted it, “If you’ve chosen Spring by default since 2005 for your EE needs, you owe it to yourself to take a real close look at JEE6.” I totally agree.
Just to give you some background. My exposure to Java EE has been limited. I have not really programmed in it. I did for 6 months or so, but it was in the J2EE 1.3 world and it was ugly/slow/overly complicated. I’ve tried to stay away from J2EE. Spring was a bit different. I’ve done Spring programming for a few years and generally have a good experience with it. But I don’t like too much XML configuration. I don’t like the fact you can easily get “tied” to the framework, which I don’t consider a best practice. Spring is a vast improvement over J2EE, but it’s not optimal either.
But now, Java EE 6 and Spring 3 enter a different ball game. I’m interested to see how it plays out. One thing I’m sure: the newest Java EE will be a good Spring competitor. Will it win? We’ll see.
I’ve always wanted the Java EE platform to be easier. JEE 5 went in that direction, but not far enough. Java EE 6 takes a few more steps. And I believe that it has crossed the “innovative/fun/cutting edge” line while allowing you to do some powerful stuff. Of course, it remains to be seen, but that’s what I feel now.
Here are some of the reasons why I think so…
No XML configs. Gone are EJB descriptors. Gone are JSF navigation rules. You don’t need XML for dependency injection. All of this means that this is really a big step forward. In some cases you might still need an XML config, but I like how it’s “configuration by exception” — that is, you might need one if you want to setup something other than the default configuration.
JSF 2 is fun. If you’ve ever developed web apps in Java, you know that it’s not optimal. I don’t like it when I see Java code inside JSPs. Who uses JSPs any more, anyway? Working with Spring MVC/JSTL is limited. Not bad, but tedious. But with JSF 2 and Managed Beans, you get a really nice, simple, and powerful solution. All you really need is one Managed Bean and one XHTML file. Really easy to get started. And I find this model of development intuitive: your view is tightly connected with the data. You don’t have to marshall/unmarshall the request in your controller. It’s done for you. Nice and simple!
JPA 2 is easy to use and robust. Powerful as well. It’s an excellent solution as an ORM. Ability to use JPA as a stand alone solution is also great.
EJB 3.1 is easy. Yes, easy. Want proof? Add @Stateless to your Java class and you’re done. No more configuration is needed. Want more? Create a webapp, add a Java class, and add a @Stateless bean. Deploy it to an app server and you have an EJB application! Done! No, you don’t need to package it to an EAR file (I hated that). Really cool.
Glassfish v3 is solid. It fully supports Java EE 6. I believe it’s the best EE application server out there. Good job to the team! Plus, with a stack of Java EE 6, Glassfish v3, and Netbeans 6.8 (no, it’s not my IDE), you can have a simple JEE app running in 5 minutes or so.
Testability. Embeddable containers. EJB has one. JPA has one as well. It’s really simple to setup some powerful integration testing. This is some serious stuff. You can test your database logic fully with an embedded database. EJB container testing is easy as well! Built in Java EE 6. You can test your EJBs with JUnit!
There are many other nice features with this release. I don’t know them all. And again, these are just my observations. So far, I’ve only read Beginning Java EE 6 with Glassfish 3 and tried a few things. Nothing serious. I’m going to learn more. I’m going to create applications based on it. This is some really exciting stuff. I just hope corporations that are still in the J2EE world move into the Java EE 6 world soon. They have good reasons for doing so now.
I have to admit, my regex skills are not that sharp. I read a book on Regular Expressions before, but still, regex expressions just don’t stick in my mind. Too cryptic.
Can you read the following?
/^[a-z0-9_-]{3,16}$/
The following explanation might help.
DescriptionWe begin by telling the parser to find the beginning of the string (^), followed by any lowercase letter (a-z), number (0-9), an underscore, or a hyphen. Next, {3,16} makes sure that are at least 3 of those characters, but no more than 16. Finally, we want the end of the string ($).
String that matches: my-us3r_n4m3String that doesn’t match: wayt00_l0ngt0beausername (too long)
Clear, right? I love the description. It makes sense! This is an excerpt from an article 8 Regular Expressions You Should Know.
This one is a bit more complicated.
/^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/
DescriptionWe begin by telling the parser to find the beginning of the string (^). Inside the first group, we match one or more lowercase letters, numbers, underscores, dots, or hyphens. I have escaped the dot because a non-escaped dot means any character. Directly after that, there must be an at sign. Next is the domain name which must be: one or more lowercase letters, numbers, underscores, dots, or hyphens. Then another (escaped) dot, with the extension being two to six letters or dots. I have 2 to 6 because of the country specific TLD’s (.ny.us or .co.uk). Finally, we want the end of the string ($).
String that matches: john@doe.comString that doesn’t match: john@doe.something (TLD is too long)
Reference8 Regular Expressions You Should Know, nettuts (very good resource, btw)
Jonathan Danylko posted an excellent set of 20 lessons learned. From a 20 years of experience. Excellent material.
Something to keep in mind as you gain your own experience… and move up the ranks.
Reference20/20: Top 20 Programming Lessons I’ve Learned in 20 Years, Jonathan Danylko
Books, books, books…
I just browsed the new and updated list of books available as part of ACM. I have to say one thing. I’m impressed. They have updated the book list (they now have 1100 books!) and their course list (over 500 courses available). But I’m not impressed with just the number. I’m impressed with the quality of the books. They have some of the best books out there. By best, I mean 5-star rated books on Amazon.
I just wish I had enough time to read them all. Speed reading? I wish. I’m already reading 1-2 books every month. There are so many books I would love to read, but I have to concentrate on reading the best and of most value to me.
What are some of the books available? Ajax on Java, Patterns of Enterprise Application Architecture, CSS: The Missing Manual, Mastering Regular Expressions (3rd), Agile Java, Software Architecture in Practice, Object-Oriented Design Heuristics, Applying UML and Patterns (3rd); many more. (Now, go ahead and read some reviews for these books, you’ll see what I mean.)
By belonging to the ACM, for $99 a year, you get unlimited access to these books. It’s well worth it. If I just had enough time…
Remember, reading is one of the best ways to deepen your knowledge, to improve as a developer, and to stay on top of this ever-changing IT field.
ReferenceACM Safari Books (600)ACM Books24x7 (500)
Simple. Precise. Without the use of buzzwords. The Uncle Bob’s way.
ReferenceWhat is SOA, really?, Uncle Bob
