I have to admit when I first experienced Adobe Flex, the successor to Adobe Flash for rich internet application development, I thought it was a fragile toy that wasn’t good for much more than pretty moving pictures. At my current day job, I had to not only learn it, but spend about half my time working in it (as opposed to my current favorite language, Java). One thing I’ve learned from the experience is that it wasn’t so much Flex that I had a problem with, as much as Flex Developers. The Flex developers I’ve worked with up until this job came to Flex from being Illustrators, Graphic Artists, or just kinda fell into it. They never learned the art of software development, never learned to appreciate best practices, and never learned to value code quality or readability. But as a long-time Software Engineer, I know you can create bad software in any language. But now I’ve spent about 10 months working in Flex, and feel I can opine fairly. Read on…
Generally speaking, I hate frameworks. Most frameworks I’ve met fall into one or more of these camps:
- 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.
I had a conversation the other day with a fellow Software Engineer about a web-based project I want to start. There are several advantages of these two technologies, and clearly either one would be sufficient to do the job. As a Software Engineer who is constantly striving to improve and up my skillset, I also have to think about what technologies are going to further my career. Developers, I would love to get a discussion going on this topic, so please leave comments. Oh, and I am purposely sticking to these technologies because I believe strongly in cross-platform tools, and these are the two top contenders in that arena. And we’re talking server-side options. So no whining from the .NET/Flex crowd.
Microreview: Most Excellent!
I bought this book because I was working on some gnarly multithreading problems. I was hoping to get up to speed on the wonderful new concurrency classes added in Java 1.5 to replace the boring old Thread class. What I got was so much more. It goes into great depth in:
- Preventing thread data escaping (what happens in thread, stays in thread)
- How to divide work among threads
- Exactly why the New Hotness is better than the Old Stuff
- The difference between the various implementations of the New Hotness
I published a post a while ago on what I thought was wrong with Java. To be honest, I never really understood why some of these problems existed. Well, in my new job, I’ve dug a little deeper into them.
In my searches, I found this article on Java generics, and why you simply can’t do anything serious with them and not get warning messaches about unchecked conversions. The short answer is, to remain binary compatible and to not break millions of lines of code, generics type information is thrown away using erasure, and is not available at runtime. They aren’t reified. It offers several solutions, too.
I also found this other article on serialized classes, and what the serialVersionUID field is for.
And finally, a good explanation of closures in Java, and how they could be added in.
OK, so I’ll admit a lot of my posts so far have been links to other articles, along with my notes and opinions on them. While I don’t feel guilty about that (as long as I’m adding value or finding content others might not have found), I’m going to try to add more original content.
I love Java, but there are a few very large issues I have with it.