Dropwizard and some memories
Not too long ago I was catching up on some Java Posse episodes and I came across the Dot War (what is it good for?) episode.
This episode, recorded live at the Roundup, was not what I expected. Maybe I was not paying attention before I started listening but I thought a Java/.Net discussion was coming. Instead I was pleasantly surprised to hear the guys talk about container-less application development.
Initially I was not so much interested in using any particular technology among those discussed. It was the idea that we should not necessarily build software using a specific pattern, framework or technology because it's popular or because we know it (insert "hammer-nail" analogy here). We should, as we once said, do some analysis and design work (a little learning is not a bad idea).
What first came to mind was that portion of the software development heritage which took us from single user applications to the internet. Roughly speaking the single user application gave way to networked applications which were replaced by client-server applications. Next we talked thin and rich clients as we flirted with browsers using various languages, frameworks, and libraries until we landed (or at least some have) in almost-complete HTML5 land.
This rough description of the application development timeline leaves out some important truths. At least given the experience I have had and continue to see. That is to say some of the so-called paradigm shifts...didn't. Over the years I have looked at more than my fair share of other people's code. Fortunately for me, I love the debugging process but that's where the fun usually ended.
The sad reality is that some folks never fully grasped what we called client-server and they built single user applications adding some slightly newer technology. As we progressed to thin and rich clients many liked the name but decided fat clients could be delivered under the new moniker. In the Java space, EE was very popular despite varied expertise and in many cases actual need.
What I have referenced, simply put, is the application (or misapplication) of a variety technologies. I have seen this done in some cases with little understanding of the technology or despite the fact that the solution did not match the need.
It's not my impression that the folks on the podcast or the creators of Dropwizard are against using application containers for all use cases. I believe their minds are open to solutions which may not necessarily be popular but are creative, efficient, pretty cool, and most importantly nicely matched to the need.
If you have the time, check out Dropwizard. It's definitely creative, efficient, and very cool. I recently built a very nice application with it in a matter of hours. While the development time was fast, the truth is I had already built a version which will run in a traditional container. The main benefit for this particular application will come with deployment, support, and performance.
If it does not match a use case that's currently in front of you (I did not have one when I first read about it), consider what it might represent. That is what I have taken quite a few words above to say: Learn technologies. Apply appropriate technologies.
This episode, recorded live at the Roundup, was not what I expected. Maybe I was not paying attention before I started listening but I thought a Java/.Net discussion was coming. Instead I was pleasantly surprised to hear the guys talk about container-less application development.
Initially I was not so much interested in using any particular technology among those discussed. It was the idea that we should not necessarily build software using a specific pattern, framework or technology because it's popular or because we know it (insert "hammer-nail" analogy here). We should, as we once said, do some analysis and design work (a little learning is not a bad idea).
What first came to mind was that portion of the software development heritage which took us from single user applications to the internet. Roughly speaking the single user application gave way to networked applications which were replaced by client-server applications. Next we talked thin and rich clients as we flirted with browsers using various languages, frameworks, and libraries until we landed (or at least some have) in almost-complete HTML5 land.
This rough description of the application development timeline leaves out some important truths. At least given the experience I have had and continue to see. That is to say some of the so-called paradigm shifts...didn't. Over the years I have looked at more than my fair share of other people's code. Fortunately for me, I love the debugging process but that's where the fun usually ended.
The sad reality is that some folks never fully grasped what we called client-server and they built single user applications adding some slightly newer technology. As we progressed to thin and rich clients many liked the name but decided fat clients could be delivered under the new moniker. In the Java space, EE was very popular despite varied expertise and in many cases actual need.
What I have referenced, simply put, is the application (or misapplication) of a variety technologies. I have seen this done in some cases with little understanding of the technology or despite the fact that the solution did not match the need.
It's not my impression that the folks on the podcast or the creators of Dropwizard are against using application containers for all use cases. I believe their minds are open to solutions which may not necessarily be popular but are creative, efficient, pretty cool, and most importantly nicely matched to the need.
If you have the time, check out Dropwizard. It's definitely creative, efficient, and very cool. I recently built a very nice application with it in a matter of hours. While the development time was fast, the truth is I had already built a version which will run in a traditional container. The main benefit for this particular application will come with deployment, support, and performance.
If it does not match a use case that's currently in front of you (I did not have one when I first read about it), consider what it might represent. That is what I have taken quite a few words above to say: Learn technologies. Apply appropriate technologies.
Comments