Clean Code, the end
Well, I’ve finished Clean Code, but my blogging each chapter is too far behind at this point. However, I thought I would throw out a quick summary blog, and recommend the book one last time before I shelve Clean Code as a blog topic for now.
Clean Code is a book that every developer should read, agree with it or not. It should probably be the textbook for a course in Computer Science (or Computer Programming, whatever) degrees. It teaches a lot of little rules and heuristics for writing clean, maintainable, good code, but ultimately it teaches a process. Care about your code, care about variable names, class names, formatting, small methods, and single responsibility. Your code won’t always be perfect; it won’t be in the Smithsonian; but it can always be improved, a little bit at a time.
After reading this book, I find myself asking better questions about the code I’m writing. Should this method be here? Should it be named something better? Should it be broken out into smaller methods? Is there any way I can reduce or remove the repetition? While I may not always have the experience and judgment to answer these questions completely and correctly, I think getting in the mindset of always interrogating and improving my code is a good place to be.
I’ve also been privileged to help organize a great group of developers in Columbus area to form a book club for Clean Code this year. The book provided an excellent starting place and guide for discussions, arguments, and stories about coding. I know that I have learned a great deal more about applying the concepts in Clean Code by just talking to smart, experienced developers. So, not only do I recommend the book, I recommend discussing the book.
The Answer to mobile phone development
I attended the CINNUNG Mobile Development Firestarter event today. I learned a great deal, as I always do from these kinds of events, and I had a lot of fun.
But as each platform was discussed—first Android, then iPhone, and finally Windows Mobile/Windows Phone—it occurred to me that the most important question is: which platform do I use (assuming you’ve already answered ‘yes’ to the question: do I need to write a mobile phone app?). This is a very important question, because there really isn’t a way to develop the same app (or, at least, the same code) for all three platforms. Android is Java, iPhone is Objective-C, and Windows is .NET. So, besides all the technical goodness, this was one of my primary objectives for this Firestarter: which platform do I use? And I think I have the answer:
Develop for all three.
Wait a second. Didn’t you just say you couldn’t develop for all three? Well, yes. There is no way to build a native app for all three with the same source code. Ah, you see what I did there? Native app. There is one obvious way to build an app for all three platforms with the same code base. You don’t have to go through a costly/obstructive app store either. It’s called the World Wide Web. You see, I wasn’t actually asking the right question.
Web apps for mobile have been historically dubious because, well, mobile web browsers have been historically dubious. But with Safari for iPhone, Windows Phone 7 Internet Explorer, and the Android Web browser, we get three relatively good browsers (at least two of which are built with WebKit) that arguably rival their desktop brethren. Modern JavaScript can already provide a UI that is responsive enough for many situations, and heck, you can even get stuff like geolocation.
So really, what’s the point of possibly learning a new language, UI framework, API, app store requirements, rules and restrictions, not to mention a possible hefty fee for selling on an app store, when you already have a much more open channel already built in to every platform. Now, I’m not saying web apps are always the answer (see also: the last 20 years of SAAS vs desktop arguments, not to mention my previous post on RTRJ). But I do think there’s something of an app store “bubble”, and when that dust settles, a similar equilibrium (as on desktops) will be reached on mobile platforms, especially if all these new consumers in the smartphone market have a hard time transferring their purchased apps to their next phone or cell network.
RTRJ
Ted Dziuba made some waves recently with his blog post, “I Can’t Wait for NoSQL to Die”. There are a lost of posts like this with sensational titles that are actually well-reasoned, yet provocative posts. However, I do not think this is one of those posts.
There are many things I find wrong and/or disagree with in that post, but here are the three points I want to rebut from this article:
- “Real” businesses use RDBMS’s. Businesses that use OODBMS’s aren’t real businesses
- NoSQL programmers don’t think they need DBAs.
- NoSQL is just a trendy fad, just like Ruby on Rails
1. Real businesses use RDBMS.
This sounds like No true Scotsman to me. “Walmart is a real business, Twitter is not”. What about NYTimes, EA, SourceForge, Facebook, Digg, Ricoh, Boeing, BMW, Merrill Lynch, Hertz, IBM, Intel, etc? I suppose they are the exceptions that prove the rule. I don’t think that relational databases “have lapsed their useful lifetimes”. I don’t agree that “MySQL was the perfect solution to everything a few years ago”. I don’t agree with any of the straw-men or false dichotomies that are sprinkled throughout the post.
2. NoSQL programmers don’t think they need DBAs
“Any company that has the resources to hire a DBA likely has decision makers who understand business reality” is just another version of the same No true Scotsman argument: companies that hire DBAs are smart, companies that don’t are dumb. However, the idea that NoSQL reduces or eliminates the need for DBAs is not an uncommon one; I’ve even seen that attitude when talking about ORMs. But using TDD doesn’t mean you don’t need QA, and using NoSQL doesn’t mean you don’t need DBAs. On the contrary, I’d want to consult with DBAs more when making a decision about what RDBMS and/or OODBMS to use. The above quote begs the question that a company would not hire DBAs because OODBMS’s don’t need them: nonsense.
3. NoSQL is just a trendy fad, like Ruby on Rails
Those kids and their ruby rails and their object databases. You leave the real enterprisey businessy work to us, and you can keep your tweeters and your hula hoops and your baggy pants… I find this point to be especially rude, flippant, and just plain wrong. I’m not a big fan of Ruby as a programming language, I’m not good at it, and I probably wouldn’t use it given the choice. But it would be irresponsible to not recognize the value that the ideas in Ruby/Rails have brought to the development forefront, and the huge influence it’s had on other languages and frameworks. Talented developers are using Rails to deliver real business value every day. I see no reason why NoSQL can’t deliver similar value, get us to think about data differently, and contribute a real option when making technology decisions.
So, Groves, you think NoSQL is better than SQL, and is going to take over, then?
No! All I’m saying is this: Right Tool, Right Job. NoSQL products are just another tool for delivering customer value, and achieving a desired result. They are not the proverbial “every problem is a nail” hammers (and the same goes for SQL products too). In fact, some people have even been so crazy as to suggest that NoSQL and SQL be used in tandem to take advantage of the strengths of each one. Crazy talk, I know.
So what’s the deal, why does this guy hate NoSQL so much?
Who knows? Maybe he doesn’t understand them, is afraid of them, has too much personal investment in relational databases (i.e. a fanboy), or has seen them applied wrongly too often. Maybe he is a DBA who is afraid of becoming obsolete (see above). Or maybe he’s right, and RDBMS is the right tool for most every job. But please, don’t come to that conclusion based on a fallacy: analyze the problem, the environmental factors, the suitability of the solution, the long-term impact, the constraints, and use the Right Tool for the Right Job.
First quarter goals recap, second quarter preview
The first quarter is now over, so I thought I’d recap what I’ve accomplished, in terms of the person & professional goals that I layed out at the beginning of the year, and preview what the second quarter will contain.
Recap of 1Q
I have almost finished two book on my list: Clean Code (which I have been blogging about at a much slower pace than I have been reading), and What Every Programmer Should Know About Object-Oriented Design. Both of these books came highly recommended, and both have lived up to my expectations. I should finished these books shortly.
As far as open source contributions, I haven’t contributed much to PHPExcel. I did release StupidGrid and a Coryat Scorekeeper.
I did not take my PMP exam, because I was picked at random for an audit. The audit took a long time to complete, but it is now complete, and I have scheduled my exam for mid-April.
I gave my CakePHP presentation internally to Quick, and I have submitted two talks to CodeStock.
I have given up the CodeKatas in favor of focusing on Project Euler, which I have also decided to do just in C#.
Blogging and tweeting are going pretty well, but maybe not as frequently as I’d like.
Preview of 2Q
I have already purchased Head-first Design Patterns (in lieu of the GoF book) and it is on its way from Amazon. I haven’t decided what the 2nd book will be yet.
I will take the PMP exam here in a couple of weeks.
I have signed up for Stir Trek and a Mobile Phone Development Firestarter event.
I plan to come up with one more presentation topic and submit it as a lightning talk somewhere.
I also plan to keep chugging away on the Project Euler, and hopefully do a couple more commits to PHPExcel.
My one year anniversary with Quick Solutions is coming up this quarter as well.
Buy my book!
