Generally speaking, I hate frameworks. Most frameworks I’ve met fall into one or more of these camps:
- Frameworks so lightweight that they’re not worth the hassle of using them. These frameworks can be useful when you need some functionality that you don’t want to learn in detail how to do. This is almost never the case for me, because I like fully understanding any technologies I rely upon. That’s why at Aptima I wrote my own AJAX JavaScript library. It was something like 50 lines of code, worked flawlessly, and worked exactly as I wanted it to.
- Frameworks so heavy the work to utilize them approaches the work of rolling your own. This often happens with frameworks that start out simple and are expanded to encompass too much functionality outside of the original scope.
- Frameworks that are staunchly inflexible in how they are used and how they work. Using a software tool to make your life easier should not like implementing an ERP system. This often happens when when the framework was designed for a specific purpose then released as a separate product. See The Cathedral And The Bazaar.
- Frameworks that are completely opaque or have an unreasonable learning curve. Most meaningful operations in software have some sort of side effect you need to be aware of. Insufficient documentation and software that does not follow the mantra of the Principle Of Least Astonishment can make diagnosing problems a nightmare.
I’m currently working on my knowledge and skills with Spring and Hibernate. They continue to fail to suck. I was very surprised how easy they were to implement, how much they’re for me, and how flexible they are. Spring is a framework that specializes in (among other things) inversion of control to promote decoupling and testability, and Hibernate is an object relationship mapper that eases the burden of persisting entities in a database. There are many good tutorials on the Intertubes, but I’ve been working my way through the book Spring Recipes, which covers both technologies very well.
Read on…
Those who know me will back me up on this; I evaluate things fairly. You will never hear me say $FOO is clearly superior than anything else, and there’s no reason for anyone to use anything else. That includes Linux and Linux distros. I calls them as I sees them, and I do not feel that Linux is always better in every situation for every user, nor is one distribution/brand of Linux clearly the best for all situations. And I’ve been using Linux since Red Hat 4.2 in 1997 (I still have the disks).
I recently installed Ubuntu Karmic (9.10), waiting a few months after release as I usually do so the major bugs are already fixed, and ran into many more problems than I expected. I find this unfortunate, because one of the main reasons I switched from Fedora to Ubuntu is no longer valid. Some of this post is about this release, and some is about the state of Linux in general.
Read on…
I am no longer at Litle & Co. My separation agreement prevents me from discussing the details, but it’s fair to say I’m not very happy about it.
I have been a hands-on Manager, a Team Lead, and a Principal Software Engineer. I’m looking for a full-time position in the Greater Boston area (but not downtown Boston) developing Java, preferably in an Agile environment. I have extensive experience in software design and development, as well as hands-on management. My strengths are my diversity and depth of experience, perseverance, ability to learn new technologies quickly, and organizational skills. My specialty is cross-platform development and tools.
You can read more about my skills and projects, and download my resume, on my portfolio page.
Some think Agile is all seat-of-your-pants. That’s not true at all. Agile requires knowing where you are right now and what you need to do in the near future; it just doesn’t put a lot of faith in guesses where you’ll be 8 months from now.
The various forms of Agile all contain a set of practices to follow and others to stay away from, each with their strengths and weaknesses. Successful implementation of Agile requires selecting and implementing practices that complement and support each other, covering all required needs without duplication (which is where a good deal of the efficiency comes in). It’s bad enough if you pick a set of practices that don’t support each other, but it’s much worse to chose the right practices but not implement them right. That’s because it can create a false sense of security. Read on…
I’ve actually felt this way for a very long time. If I died and got to come back as something else besides a human, my (presumably non-traditional) choice would be to come back as an octopus.
- They are very well adapted to their environment, and do pretty well in some other environments
- They have ample appendages to manipulate their environment
- They have the ability to live in many places and eat a variety of foods, which makes them resilient to hard times.
- They have turbo boost! And [some have] camoflage!
This article I found on Wired’s website talks about new examples of some species of octopus which have shown real tool use! Not just real tool use, but carrying around tools for later use. And that’s the part that distinguishes intelligent tool use from instinctive behavior. I’ve seen documentaries on them solving various physical puzzles, but this is even cooler. They even have a Beatles song about them.
Yet another mailing list I’m on is Peteris Krumins’ blog, good coders code, great reuse. He posts about software development, hacking, security, code reuse, etc. This post is on advanced use of obscure Perl operators.
There is a mysterious underground Perl organization that hardly anyone has heard of. Their primary mission is to discover new secret Perl operators but they are not allowed to talk about them. I managed to infiltrate this organization and steal some of their secrets. Here are 8 secret Perl operators that I retrieved from their mysterious hoard.
This is a great (and entertaining) article. However, it exposes the thing that I like the least about Perl; its reliance on punctuation marks to greatly change the meaning of a block of code, and the ability to replace a perfectly good explicit code block with a few squiggles and variable names to show how clever the developer is. The trouble is, this cleverness make the code much harder to understand by the next person that needs to work with it. These days, 9 times out of 10, code legibility and malleability will benefit a company much more than brevity.
From the wonderful folks at the Boston Sci-Fi Marathon, I present 13 Things Horror Movies Taught Us. These people run other movie marathons, like HorrorThon (which I attended), but the Sci Fi marathon is their biggie. It’s a 10 day event (starting 02/05/10), ending in the 24-hour marathon (which I hope to go to). I just wish their website was in better shape.
According to this article (and others), Python creator and BDFL (“Benevolent Dictator For Life”) Guido van Rossum froze the Python language’s syntax and grammar in their current form for the the next few releases, and possibly longer. The reasons are good ones; To let developers catch up to the latest release, to let the rich array of third-party tools stabilize, and to improve the quality of the existing libraries. I think it’s a bold move, but the right move.
This is an awesome article. I found the link from the Semantic Web group on LinkedIn. I haven’t spot-checked it for accuracy, but there’s a fair amount of dispute over the history of computers and the Internet anyway. But this article is very enjoyable, and includes many related historical points, like when certain companies formed, and the history of tangential technologies that made the Internet possible. It’s a good read for geeks, and a great primer for geeks-in-training.
I mentioned in this post that I got laid off from Metatomix back in October. I just landed a Java/J2EE Software Engineering job at Litle & Co.. I started Monday, but I wanted to wait a few days to “make sure it takes”. But it feels good, I’ve already checked in some code, and have adapted to their pair programming environment. I wrote a bit about them in this post while I was still researching them, and I liked what I found. I already have a taste for their flavor of Kool-Aid, having done Agile and pair programming before, and similar work in similar technologies. This has all the makings of a good, long, run.