I really like Java enums as a way to organize and consolidate all the string constants that come with building systems with a lot of settings files. In our case in particular, we have an ETL process that moves data between sources that have no knowledge of each other. All checks to ensure that there are only valid values in each system need to happen in the Java code. Enums are perfect for this, but some of our settings are hierarchical and it’s a little unclear how this would work in code. Our lexicon looks a little like this:
music
\
jazz
pop
funk
blues
rock
|
article
\
blog
feature
review
|
video
\
music
interview
comedy
Creating an enum for the top level is straight-forward:
public enum Scheme { music, article, video; }
So now how do we get Scheme.music to return the valid values for it’s subtypes? First we need to create a marker interface:
public interface SchemeClass {}
You can add abstract methods on an enum, so we can create a method that will return an array of SchemeClasses:
public enum Scheme { music, article, video; abstract public SchemeClass[] getClasses(); }
And while we’re at it, lets create the enums for the sub-categories (consolidated here, but in practice I put them in different files):
public enum MusicClasses implments SchemeClasses { jazz, pop, funk, blues, rock; } public enum ArticlesClasses implements SchemeClasses { blog, feature, review; } public enum VideoClasses implements SchemeClasses { music, interview, comedy; }
The important thing is that all of these enums implement the SchemeClass interface. Now to get the Scheme enums to return the list of valid subtypes.
Now all that’s left is implementing the abstract method for each of the possible values in Scheme.
public enum Scheme { music { public SchemeClass[] getClasses() { return MusicClasses.values(); } }, article { public SchemeClass[] getClasses() { return ArticleClasses.values(); } }, video { public SchemeClass[] getClasses() { return VideoClasses.values(); } } ; abstract public SchemeClass[] getClasses(); }
JBoss Hot-Deploy With Maven
If you’re a web-developer, one of the best features of Eclipse is the JBoss IDE plugin. The mere fact that you don’t have to re-compile/re-deploy the war for every change saves countless hours per build.
If you don’t want to use Eclipse, you can replicate this behavior with Maven and run the app out of your working directory. The first step is to navigate to the location of your code (hereon referred to as $CODE_DIR) and execute the maven task:
$ mvn war:inplace
This will create the entire war structure in $CODE_DIR/src/main/webapp. Take a look. You’ll see a classes and lib directory under WEB-INF.
This is probably a good time to exclude these directories from version control. I use Git, so I added the following lines to .gitignore at the top level of the project:
src/main/resources/webapp/WEB-INF/classes src/main/resources/webapp/WEB-INF/lib
Now that you have a complete war you can have it deployed in jboss by creating a symlink. Assuming that $JBOSS_HOME is set, you need the following command:
ln -s $CODE_DIR/src/main/webapp $JBOSS_HOME/server/default/deploy/web.war
Startup JBoss and you can now edit your non-compiled resources, like Javascript, JSPs and CSS at will, without a compile/deploy cycle.
If you want similar behavior for changes to code or libraries, there’s just one more step. Running:
mvn compile war:inplace
on its own won’t redeploy the classes. For that, you’ll need to touch the web.xml file. You can do this with the maven exec plugin. This part is Linux/Mac OSX only. If you’re on Windows, well you have bigger problems beyond hot-deploy.
Open up $CODE_DIR/pom.xml and add the following lines:
<plugin> <groupid>org.codehaus.mojo</groupid> <artifactid>exec-maven-plugin</artifactid> <version>1.1</version> <executions> <execution> <goals> <goal>exec</goal> </goals> </execution> </executions> <configuration> <executable>touch</executable> <arguments> <argument>src/main/webapp/WEB-INF/web.xml</argument> </arguments> </configuration> </plugin>
Now running mvn compile war:inplace exec:exec will redeploy the project right from your working directory. I have this configuration mapped to a keystroke in Intellij to make the process seamless.
The benefits of this approach is that it will work with any IDE or development environment. It also works with JBoss 4.2 and 5.0 (JBoss tools has had some issues with 5.0 because of the VFS changes). It also works every time. JBoss tools would occasionally not update static files.
The downside is that it’s not as seamless nor as fast. It will redeploy the webapp, just as if you had pushed a new war.
The time savings are still substantial and I would give this approach a try if you use an environment other than eclipse for your java development.
Splitting Personalities
I’m not a software developer, entrepreneur, or engineer. That’s just what I do. There’s a lot that I’m interested in beyond my work. For the longest time, my online presence has been at ViJedi.net. However, in the era of micro-blogging and increased social interaction on the web, I’ve found myself holding back from posting things that I find interesting. I’m always faced with the fact that half my audience doesn’t really care that I went to park and took some pictures. The other half doesn’t care that Slicehost rocks or are interested in a new Spring MVC trick.
So from today on, ViJedi.net will be about software, technology, the software development process and other startup-y topics. All my personal posts, like pictures, random thoughts and the rest will be at a new blog tejus.tumblr.com. Thanks for reading.
Dear Eclipse
It’s over, we’re done. No need to come by and collect your stuff. Your workspace is already in the trash. There’s no trace you were even here.
I still remember when I first gave you a shot. I had tried other IDE’s, but all they seemed to offer where headaches. Vim and Ant simply worked better.
But then you came along, with compile as you type and amazing CVS integration. Suddenly, my collection of a half dozen command line utilities were reduced to one. I was so taken with SWT and it’s ability to look native on each platform, that I even wrote an entire application in it.
My love only grew when I took a professional development job. I had to use Windows, you made it possible to get something done. But looking back, that’s also when our relationship started to crack. We switched from CVS to SVN, negating one of the greatest advantages you had.
I switched jobs again and this time I was introduced to Intellij IDEA. Sure it was nice, but it didn’t compare to you. It’s version control integration was confusing. It didn’t support all features and languages you did, and it’s auto-compile just didn’t work as nicely. I stuck with you.
But the cracks that appeared earlier started growing. Each new feature you supported and every new plugin written for you never seemed to work right. Everything had rough edges, caveats, and felt distinct from everything else in the system.
You just didn’t take care of yourself. As computers got faster, you got slower. Every editor seems slow to respond to keyboard input. The XML editor is the single worst editor I have ever used. Typing in your IDE shouldn’t feel like telneting over a dial-up connection. You started bloating up to the size of a beached whale in a sad attempt to be everything to everyone. While you allowed everyone to attach to you, you forgot about what made you great in the first place, Java development.
You didn’t keep up with the best practices. You don’t work well with maven projects. Refactoring doesn’t work across the entire workspace. You should never ask me for the location of the source for a class when it is in your workspace. It’s 2010, these are things you should do right by now.
One of your great features was the ability to use external editors for resources managed by the IDE. Unfortunately, whether or not that file was refreshed in the workspace seemed like a decision that rested in God’s hands.
Lets not even talk about version control. The subclipse/subversive split was a disaster and your git support is a joke. You once replaced my entire stack of tools. Now to get anything done, I now have to open a bunch of terminals, gitx, textmate, and you.
Remember that other IDE I played around with? It’s kept itself in shape. It looks better than it ever has. It never promised to do everything, and that’s left it with few wrinkles and sharp edges. It works with a Maven project structure, has real support for Git, and does a fantastic job of editing Java. And now it’s open source too, just like you.
That’s why it’s over. It’s always sad to see something with so much promise ruined by neglect and bloat. But it is what it is and it’s time to move on.
Sometimes a full blown javascript library like JQuery, MooTools, or Dojo is impractical.
I just had such a project, but the one feature I could not live without was CSS3 selectors. Walking the DOM manually would have taken hours to implement correctly, especially since each page needed to be treated differently. My first thought was to rip out the JQuery selector functions. That’s when I discovered Sizzle.
Sizzle is the CSS3 selector engine written by John Resig that was originally written for JQuery and is now also used in Dojo. Since it’s a standalone library, you can also use it directly for your projects.
The first step is simple, you need to include the Sizzle js file in your page. Once you do that, you can call Sizzle just as you would call $ in normal JQuery.
Examples:
// get all divs Sizzle("div")
// Get all links in the paragraphs in the sidebar Sizzle("#sidebar p a")
// Get all li elements under a ul Sizzle("ul > li")
Just like JQuery, right? Well no. Unlike JQuery, which returns a JQuery object that can be accessed with JQuery’s easy and cross browser API’s. Sizzle returns a list of elements.
If you wanted to set the text of the first link element to “Go To This Page,” then what you’d have to do is the following:
var elements = Sizzle("#sidebar p a"); a[0].innerHTML = "Go To This Page";
If the necessary manipulations are simple, using Sizzle standalone is the way to go. It’s much smaller than a full blown JS library and it gives you what’s normally the most painful part.
2009 In Review
It’s the first work day of the new year and in order to delay heading out into the frigid cold (it’s about 15 right now), I figure it’s a good time for a 2009 recap.
It was definitely one of the busiest years of my life. The year started normally enough, with both Sonali and I working for a large public company. Unfortunately, it didn’t take long before the economic meltdown affected them as well and the downsizing started in our division. This overarching storyline probably made the year seem more stressful than it really was, due to the multiple rounds and the general sense that something wasn’t quite right as far back as March. That all ended in September 30th, coincidentally my birthday, when both Sonali and I were let go. On the upside, I had an interview scheduled for later that afternoon. On the downside there was a going away lunch, complete with tequila. More on that later.
While this was all going on, I still needed something to do while building my rails chops and started putting some hours in Journalistics on the nights and weekends. We’ve launched one product, and are coming really close to launching the first preview of our main offering.
Perhaps the biggest work difference in 2009 was some first hand experience on the management and organizational side of product development. The challenges and solutions are significantly different than development. The biggest lesson learned is to not come up with a product plan without also coming up with a sales plan. It doesn’t matter what you build if you can’t convince people to use it.
While much of this post focuses on the negative, it was overall a very positive year. We did some very good work in my time at Premiere and it’s unfortunate we never got our product out the door. While the economic conditions resulted in a lay-off on my birthday, it had a happy ending. The interview was at Vertical Acuity, an Atlanta startup building a new syndication model for publishers. It was a great fit for both parties and I accepted their offer.
2010 finds me back where I want to be, in an small startup working on interesting problems. Being part of a small team with a lot on the line is very appealing to me. Also, since I apparently don’t like to sleep much there’s aforementioned Journalistics beta and the launch of Scoutmob. It’s going to be another busy year, but one that should be as enjoyable as 2009.
The holiday season is in full swing, which means shopping, lots of eating, some traveling and lots of pictures. If you’re not 80 years old, every photo you you take is now digital. Of course there are always a few each year that you really want a physical copy of, and maybe one that you would love to see blown up hanging on your wall.
There’s no shortage of digital photo printing options, all touting different benefits and prices. I’m not exactly what you’d call a professional photographer. There’s a lot of subpar pictures on my Flickr account. Therefore, I’ve generally gone with more consumer grade printing services, thinking that it’s not really worth the extra cash for some of the more professionally oriented printers. You can get a 20″x30″ blowup for $9.99 at Costco’s photo center. Even if the picture sucks, it costs less than lunch.
I had a picture that I really liked and decided to spend the cash to get it printed at a real printer. A friend of mine suggested FotoFlot. They’ve got a unique system that prints on high-quality photo paper then fuses it to an acrylic backing. It comes with a mount that secures the pictures via magnets, making it trivial to swap out pictures as you desire. All the coolness comes with a hefty price tag. The same 20″x30″ print that costs $9.99 at Costco will cost you $185 at FotoFlot.
I went ahead and ordered at 15″x30″ crop at FotoFlot and, out of curiosity, a 20″x30″ blowup from Costco. I had expected the FotoFlot to be better, but I was surprised at how much better.
The first obvious difference is the the color. For best results, you can include your color profile with FotoFlot and they will make adjustments to their printing process. With Costco, you upload just the original image and they do the normal big-box color correction.
In this picture, I’ve overlaid the FotoFlot print on the bottom of the Costco print to capture the difference. The grass is much greener in the FotoFlot print, while both made the mud redder. Personally, I like the richer green, even though it’s not as bright in the source print.
Far more important than the color differences is the difference in detail. Take a look at the close up of the Peugeot (FotoFlot on top, Costco on the bottom).
You can see that the lines on the Peugeot in the top frame are far crisper and sharper. A zoom in comparison of the Peugeot badging on the side of the car really highlights this difference.
In the top frame, almost every letter is legible. Only the P, U, and G are clear in the Costco print.
The definition of objects is clearer when looking at the Mazda6 sign. It’s bold and clear in the FotoFlot, but faded in the Costco print.
In the FotoFlot print, the individual pieces of rubber are clearly visible. On the Costco print, only the very large chunks appear. The rest blend into the track. Even more troubling on the Costco print are the vertical lines left by the printing process. The FotoFlot doesn’t have any introduced artifacts of the process.
While the price difference is as large as the differences in photo quality, I think getting large prints printed professionally is completely worth it. The details that made the picture interesting are simply lost in commodity printing. If it’s good enough to put on a wall, then it deserves a quality printer. I see myself using FotoFlot a lot more in the future. I couldn’t be happier with the results. If you would like to see all the images associated with this review, you can find them in this Flickr Set.
Zimbra Disaster Recovery
I had queued up a post about the improvements/deprovements in Zimbra 6. Except a comedy of errors led the power supply my mail server to die before I had the chance. This is the second hardware failure this year, so we decided to move our mail and calendars to Google Apps.
That was the easy part, the not so easy part was moving the 4+ years of email sitting on the dead servers hard drive. Most of the process is general recovery hacking: pull out the hard drive, put it in a new machine, do a backup. Restoring onto a new server is where it got a complicated.
I used VirtualBox to host my Centos 4.8 vm with a Mac OSX guest. This Guide on the Zimbra wiki is the correct procedure to recover from this situation. Its very accurate, but it’s worth mentioning a few important highlights.
First, make sure you’re setups are identical. I had forgotten to install a few of the services on my restore machine which caused all sorts of problems and startup failures.
Also, for reasons that I have yet to determine, Zimbra is incredibly crash prone when running in a virtualized environment. You may have to restart often. When trying to test this process, I encountered multiple segmentation faults in Zimbra’s services.
Since this means that you’ll restart often, it’s best to shut off all extraneous services.
You only need these
Changing these setting will allow for quicker reboots, shutdowns, and reduce the number of things that can go wrong. I also disabled SSL on my zimbra instance, to future reduce the number of problems.
Now you’re ready to move your email. The best approach is to use imapsync. This utility, written in perl, is like rsync for your mail. It will only move mail that does not exist in the remote location. It can also be restarted after a crash to continue on after a crash (see a few paragraphs above). You’ll probably have to baby-sit the process for a bit, but within a few hours, you should be off your self-hosted email solution and into the manged services of Gmail.
