Archive for November 2011
I use gradle a lot at work and I believe one discovery that was a true win was discovering how to fake JNDI when using the jettyRun task for local development. Originally googling and searching the documentation didn’t yield anything so I thought I’d write a quick post detailing how to do it in case you’re like me and googling for the same thing.
First off you need to create a jetty-env configuration file and put it somewhere in your project (I prefer src/test/resources). Here’s a sample of one I use that uses H2 for the dataSource:
This uses an already running H2 instance and runs an init script located in src/test/resources for populating the database with some tables. From our gradle script we need to reference the file from the jettyRun task (I also add it to the jettyRunWar task as well).
Finally, to complete this example, we want H2 running before jetty kicks off. So we add the h2 dependency to our build script and run the main method of
I’ve created a sample spring MVC 3 project that makes use of all the above for local development. Just clone it and run
gradle jettyRun to see it in action!
The other day I was having lunch with a friend of mine who works for a medium sized company (by medium sized I mean large, but not Fortune 500 large). Our discussions touched a variety of topics by one that caught my attention was when he voiced his frustration on his current project. “We’re not doing much programming right now,” he quiped, “for the most part we’re doing static content management and updating pages that is basically a ‘Recent News’ section for the organization.” With all respect to my friend (who is a really good programmer) this discussion really reminded me of what I dislike about companies with large company mindsets.
It’s hard for me to put my finger on it, but the gist of it is that developers paid upwards of $60,000+ a year were doing static content management while a $15 an hour developer fresh out of college would most likely setup Drupal or a WordPress blog and let them update it while he focused on more important things. I’d know… I was once that $15 an hour developer.
It’s a common problem I’ve seen in large companies in my experiences… problem A is easily solved by tool B but tool B is written in language C while the company has embraced language D (and its derivatives). No good equivalent to tool B exists in language D so the developers will spend lots of time doing manual work, in which case you have one to five developers with degrees updating text (I’ve seen it). The worst case (and common) scenario is the company will possibly spend upwards of a quarter million or more developing a poor imitation of tool B in language D that will only work in house and will never be able to be used outside the company.
Why is this? Why is it so hard to just use tool B and keep focusing on the more important tasks at hand? From what I’ve observed in my career is that companies with large company mindsets rarely can consider using languages outside of their core language choice. It requires server provisioning, training, hiring developers or server administrators experienced with language C… and quite possibly the hiring of consultants who specialize in tool B. The prep time for such a task could easily take up to six months or more and in the end it probably will be decided that tool B isn’t up to the task.
Compare this to a more fluid development environment. The developer probably uses language D too but knows tool B would be the best choice to get the job done. He’d probably have the company drop 40 stones on a rackspace instance and install tool B and language C on it and integrate it with the current site written in language D. I’ve seen this done in days, if not hours.
Notice I really try to emphasize “big company mindset” over “big companies” as the guilty party of this tomfoolery. Just because you’re big doesn’t mean you have to act like this and I’ve seen small companies engage in this behavior as well. “Large Company Minded” companies tend to prefer a great deal of process in the way they do business and identify success with solid, foolproof process that can be adhered to by anyone. Don’t get me wrong, I’m not saying absolute chaos of no processes are a good thing but I believe that a business should have a certain degree of fluidity to be successful. Why not just do a quick cost analysis over how much it would cost to have a single server (probably even one already running some other application server) to run language C and tool B rather than redevelop tool B in language D? Why not just determine that that would be the best option and just do it instead of lollygagging around and wasting your company’s money?