Rocking Gingerbread on my original Motorola Droid. I’m pretty impressed with the stability, speed, and the smoothness on a 1ghz kernel. Big ups to Pete Alfonso for the new ROM Get it at http://goo.gl/HSYPm.
Can’t sleep… It’s 3:30AM EST and I can’t sleep! So, I figured I’d write about my recent battles with Maven, Anthill, and Junits.
I’ve recently converted a project from an Ant build over to a Maven build. The motivation for doing this was that the project structure was starting to get a little messy and the development teams could benefit from having a well defined project structure for future development efforts not to mention dependency management. While making the conversion, I decided to turn on junit reporting as this is standard practice in any healthy development project. Since our build environment is backed by Anthill, I needed to emit junit report xml files so that Anthill could dutifully package junit reports for distribution to a mailing list. I also wanted to have Anthill fail the build if a junit failed or errored out . Sounds simple right?
Unfortunately, I encountered a few hurdles in getting Maven to play nicely with junits and getting Anthill to play nicely with the Maven way of doing things. The problem was that:
In order to achieve my goal, I needed to fall back to Ant tasks. The Ant tasks that follow simply concatenates the generated junit test results into one file. After concatenation, I load the file into a Ant properties so that I can search for key indicators of failure or errors. If these are present, I flag the build as a fail and let this bubble up to Anthill to fail the build.
Anyway… This isn’t the most elegant solution, but it works. Hope this helps someone.
org.apache.maven.plugins maven-antrun-plugin test-reports install run
The turkey has been placed in its brine. Now its time to let osmosis take its course and let flavor flow freely through membrane and tissue until it finds perfect equilibrium. Damn I love the science of Thanksgiving!
Seriously though, it will be nice to stop for minute, breathe, give thanks and reflect on what we have been given. Our family has been blessed this year and I’m happy to celebrate that.
Cheers!
Alejandro
Added captcha to the registration process. Getting tired of the registration emails from .ru and .pl extensions 
I spent some time today trying to figure out why my Weblogic domain takes FOREVER to start when running under a Linux virtual machine on my new laptop. I found a couple of things that I didn’t event think to look for. Here they are:
Now, where does this leave me? Fortunately, I’ve helped get some inertia behind moving projects to a Maven2 model. My goal is to re-organize projects into a Maven structure and leave Eclipse behind fully. This will eliminate the need to bring a bunch of tools to the table when developing as Maven and JRebel play well together. As a side effect, it might be possible to leverage a smaller application container for local development (Glassfish comes to mind). When things are nice and tight, we can promote it to Weblogic using profiles to configure for that environment.
I spent a rainy Sunday rooting my Motorola droid. Nothing too exciting… I patiently waited for the stock 2.1 update to roll out and played with it for a few weeks. Honestly, the updates were pretty unimpressive save for the new gallery. I decided it was time to take the plunge and root, install a custom mod, and overclock. This is just a quick cruise through the process I went through with a list of apps that I’ve installed.
In order to root, I needed to fall back to the stock 2.0.1 install. I decided to flash the device with a stock SBF. This gave me a way to flash back to stock in case something went really wrong. I wasn’t really concered with data loss as most of my important stuff lives on the Google infrastucture and would be available after I reset my phone. I did pull off any pictures from my SD Card and saved them to another location.
After flashing back to 2.0.1. I chose a couple of different ROMs to play with. First, I tried the latest DroidMod. I liked it at first, but things were a bit buggy when I tried to install other apps. Maybe it was the process that I used to update, but it didn’t really play nicely and the market app kept force closing. I wiped my phone and re-applied DroidMod and everything went well. After a bit of hunting, I found ROM Manager. This little app allowed me to choose custom ROMs pretty easily and let me bounce around different ROMs to see which one I liked best. I ended up with the latest cyanogen mod. I picked cyanogen for a couple of reasons. The base mod gave me everything that I liked and the defaults were reasonable. I especially liked the ability to orient the screen 360 degrees. Once I overclocked to 1ghz and things are very smooth. After a day, battery life seems reasonable.
The apps that I have installed:
gTasks – TO DO manager that links up to Google Tasks
Google Maps – Google Maps, what else?
Pandora – Internet Radio
Dolphin Browser – Better browser than stock – IMHO
StopWatch – Simple stockwatch to clock things when I need to.
BuzzLock – I hate ringtones. My phone is always on vibrate.
NoLock – Bypasses the “swipe to unlock” screen.
Twidroid – A decent Twitter client
SlideIt – A swipe to type replacement for keyboard input as the stock keyboard sucks.
Pure Calendar – A calendar widget that integrates with Google Tasks.
Now that I have a nice base image, I am interested in taking a snapshot of my install for restore later; however, I haven’t looked at the backup apps in much detail.
Lots of stuff going on over the passed few weeks. My life is strapped to a roller coaster that has a mind of its own, or so it feels.
Anyway… Soldiering on… I found myself with the need to work with a bit mask today, or so I thought at first. I wrote an email sender that I wish to control through configuration. Basically, I want emails to be sent in production; however during development, I want to log them to a file, a database table, or all three. My first instinct was to knock up a bit mask similar to:
Original enumeration…
public enum MailSenderBehavior {
NONE = 1 << 1,
SEND = 1 << 2,
LOG = 1 << 3
}
You get the idea... But a second look at the Java language turned up EnumSet. MUCH simpler to put together and code against than the old school bit masks. Nice!
New enumeration...
public enum MailSenderBehavior {
NONE,
SEND,
LOG,
STORE
}
Adding behaviors....
final EnumSet<MailSenderBehavior> behaviors = EnumSet.noneOf(MailSenderBehavior.class);
behaviors.add(MailSenderBehavior.valueOf("LOG"));
behaviors.add(MailSenderBehavior.valueOf("SEND"));
System.out.println(behaviors.contains(MailSenderBehavior.LOG)); // true
System.out.println(behaviors.contains(MailSenderBehavior.SEND)); // true
System.out.println(behaviors.contains(MailSenderBehavior.NONE)); // false
The properties value in my properties file... I simply split the list on a delimiter, create enums of them, the add them to the EnumSet.
SMTP.sendBehavior=LOG,STORE,SEND
The usage...
try {
// log for behavior
if(behaviors.contains(MailSenderBehavior.LOG) || behaviors.contains(MailSenderBehavior.STORE)){
logNotification(id, model, result, behaviors);
}
} catch (MailException e) {
logger.error("An unexpected exception has occured while logging notification.",e);
this.getExceptionBuffer().add(e);
}
try{
// send for behavior if prepared successfully
if(behaviors.contains(MailSenderBehavior.SEND) && this.isPrepared()){
((JavaMailSender)this.getMailSender()).send( ((MimeMailMessage)result).getMimeMessage());
}
this.setResult(MailSenderResult.SEND_SUCCESS);
} catch (MailException e) {
this.setResult(MailSenderResult.SEND_FAIL);
logger.error("An unexpected exception has occured while sending notification.",e);
this.getExceptionBuffer().add(e);
}
}
Kinda neat...
This week, I’ve been looking at Git. Git, if you don’t know, is a distributed version control system. I really like Git for one reason – local branches. I really, really, really, really, like the reality of having a local branch that I can commit to without having to go across the network. I’m stingy. I like my own sandox of code. I like working with my own snapshot of a source tree to do whatever I want with it. If my changes are good, I can commit them back as a coherent change set. If they suck, I can roll them back and no one will ever know what I was up to. The reality of local branches gives me the ultimate in flexibility.
I was once in pretend land where I though that SVN gave me the same flexibility. However, I needed to create branches on the repository, then check the branch out, then switch to my newly created branch, then check my changes back into the newly created branch. Finally, I need to merge between branches. This is okay for changes that are long lived (more than a few days at least…). For example, I’ve worked on stories that span more than a few days. Since I like to experiment, I would branch the trunk and work on something experimental, then merge in my changes with the trunk. This is status quo for SVN users. Textbook examples of using branches…. When I was satisfied with my work, I would merge my changes back into the trunk and life would go on. Life was good, so I thought…
The problem is that branches are expensive in SVN. I need to do a lot of work to materialize a branch. It’s also visible to everyone. What if I wanted to work out something non-trivial? Does everyone need to know that I’ve branched the trunk to work on story “xyz”? Further, I need the network to branch. I can’t do it without a connection to the repository. Kinda sucks if I’m on a plane or at Starbucks with a crappy wi-fi connection!
What if I’m working on a team with several developers on the same feature? I need to commit back to the mothership (SVN repo) in order for my changes to be visible to other committers. What happens if I only want to work with a subset of the team on a specialized sub-feature? The very nature of commit -> publish -> update model disallows this.
So… Where does this leave me? Well, I can’t shift the organization to a git repository. That would require me swimming upstream. There are way too many SVN users in the crowd and I think I’m the only one who would entertain git for practical usage at the moment. Perhaps there are others, but I haven’t heard any rumbles.
I’ve retreated to wrapping my mind around git and the integration with SVN (git-svn). So far, the learning curve is rather steep. Specifically, I’m having trouble wrapping my brain cells around gits ability to rebase. I’m pretty satisfied with happy-path workflows using git and svn. However, when I get into conflicts or I need to re-examine my git index, I get into la-la land. I’m much more comfortable than I was last week; however, I’m still not confident in my git skills.
The take away… Local branches are the right way to go. There should be no reason why I need to connect up to the repository to do feature work, experimental work, or hot fixes. In my opinion, the very nature of software development requires that code should fork from a stable basis in order to evolve. It doesn’t have to follow lock step with a repository commit in order for it to be useful. Once changes satisfy a need, they can be committed back to the mothership.
Git speaks to my heart when it talks about local branches and I’ve been looking for such a workflow for some time now. SVK seems to support local branches with the promise of speaking SVN, but its still SVN under the covers. If I’m going to exhause brain power on managing local branches, I might as well commit to a tool that does it as a cleanly as git.
Bottom line… Git is the new hotness for me. The learning curve is steep and its going to take me some time for feel as comfortable with it as I do SVN. SVK is a non-starter for me. If anyone has a decent workflow for git-svn, let me know… I’d be interested in trying it out. Also, if anyone knows of any other tools that let me whip off local branches for later commits back to a repository, let me know. I’ve found none thus far – other than bitkeeper, but Linus already told me that
Grrr…. I recently upgraded to Xubuntu 9.10 (Karmic Koala) and found that my video drivers have been put in the “legacy” category according to ATI’s support page. ATI no longer supports drivers for my video card under Linux and Ubuntu reved up to Xorg 1.7 as part of the 9.10 release. The end result is that I need to fall back to the opened source drivers which don’t support 3D acceleration at all. I have a Radeon X850XT, which is a pretty decent card for being ~4 years old. My system was running so crappy under the OS drivers that I ripped out my Radeon card in disgust tonight and fell back to using the my, on board, Nvidia nForce 430. I now have a somewhat kick ass paperweight on my desk. I guess its going on Ebay soon…
The reason why I bought the ATI card was because it was pretty high end back in the day. Now, I can’t use it unless I revert back to 9.04 or some other Linux distro that hasn’t reved beyond Xorg 1.6.0. WTF?! Thanks ATI! Thanks Xorg! Thanks Ubuntu!
I think I’ve just become an Nvidia customer… AMD, you’ve lost me!
So, this is a much debated topic. I’ve read countless articles on the subject and none offer a practice in terms of managing interface changes between client and service. I’m going to rattle off my thought process and see if I can come to a conclusion.
First… Let me set the stage. I have web services deployed. I have clients bound to web services. I have concurrent development happening where clients and services are changing simultaneously. I have a build process to manage. I have a deadlines to meet where these deadlines depend on service availability and correct implementation.
That said… I need a simple approach to versioning web service interfaces such that clients can continue to build and deploy. I must admit that the current model is broken. The current “model” in my shop is such that clients re-build against WSDL on every CI build and every scheduled build. This works our great when interfaces are static. When things change, things get whacked. I think that this approach breaks down since client applications consume the WSDL of a service at compile time – always. While this is great for realizing interface changes, it becomes a blocker when significant revisions to dependent services are made. Specifically, this setup precludes a client from being stable when significant changes to a dependency are made. We can regard significant changes as ones that break interfaces. The current model is akin to you going out to your car everyday and re-compiling your mental model of how you interact with your headlights, turn signal, and steering wheel. If you’ve already bound yourself to this interface, why do it again? Can’t you rely on your previous experience (your last, known, good, compile)?!
So, what do we do? I propose that we version service interfaces and abstract versions based on URIs. For example, major revisions should be parked at a URI that attributes a revision change such that the URI denotes a revision. Amazon does this (api1.service.com or api.service.com/v1?wsdl, etc…). Client applications should consume a WSDL and internalize it. This means that a client application needs to store the WSDL, and related schema, as part of its source tree. During compilation, the build should pull the stored version of WSDL necessary for the application. This protects the application from compilation failure due to revision change it is not ready to accept. Some options would be to store only the WSDL in the source tree or compile down the relevant schema and WSDL into a deployable artifact. I would version this artifact in line with the service provider’s published version and keep in a centralized repository. It becomes a dependent artifact of my client code base that I can pull by version. Endpoints need to be adjusted as required to ensure that the client is pointing to the proper endpoint that matches service impl and version. I have a gap when it comes to multiple environments… If I move from DEV to QA, what does this mean? How do I manage endpoints without relying on some convention like [dev|qa|uat].service.com/v1?
Service providers need to ensure that service implementations are available for supported versions. This increases the overhead on service providers such that they need a version strategy for build management. For example, a service provider needs to maintain versions 1, 2, and 3. As a result, a service provider should maintain source trees that are relevant to these revisions. I would suggest that service providers branch off lines of code relevant to the revision they intend to maintain. This gives the service provider the ability to bug fix any defects or regressions on a given source tree. When it comes time to deprecate a branch, the service provider can do so by implementing revision notification code on a deprecated branch. This, coupled with monitors on client usage, should be enough to govern service lifecycles.
I dismiss stamping version numbers in request and response bodies. This begs for logic in a centralized routing mechanism. I don’t think that this is transparent enough for consumers of services to make proper decisions. I don’t want my request magically transformed on a service bus to another content body that accommodates a brand new interface. I didn’t turn over custody of my request to an arbiter of XML content routing. I bound myself to a version of an implementation and that’s what I want! This might work for super stable services, but I think it creates noise in highly dynamic services.
I’m shooting for a simple solution to interface changes. I’d rather not have a lot of governance overhead involved in the process of managing change. Change is hard enough to deal with, especially when systems are evolving concurrently. I’m starting to become a fan of versioning services by URI rather than by content. I know this flies in the face of RESTful concepts, but it is what it is…
Thought?