• Checkbook balancing is a method of verification
• Both banks and merchants can make mistakes
• Overdrawn account, bounced check fees, monthly service fees
• On-line Banking is not always real-time
• Help you budget your money

I like to keep an eye on the transactions, I can easily make sure that I’m not double billed or paying for some unexpected transaction fee.  A topic for another post, is the value of budgeting. I bet even fewer people actually create monthly budgets. I have always maintained a personal budget, though not always been able to live within it!  Because I tracked my spending, I always knew where the money went and how big the problem was. I am back to using personal finance software; I manage and live within my budget and reconcile my accounts every month. It takes no time at all and I always know exactly where I stand. Unfortunately, I have not been able to get my son to balance his checkbook yet, but I do have all of his statements printed out and ready to go; we just never seem get to it. I now realize, this is even more important than I originally thought.. this is a fundamental life skill that I have to share with him, before he sets off on his own.

Over the past few years, a friend of mine has ranted about this problem several times; he actually wanted to teach high school kinds some basic money management skills. Amazingly, neither the public school system nor parents are teaching this fundamental skill, it should be no different from the other fundamentals: Reading, Writing, and Arithmetic. Now, you really know how old I am!  Here is good post that illustrates the point well,  Why Can’t Johnny Balance A Checkbook?

I might have said this in a previous post, but I believe that many developers use Agile as an excuse to avoid following institutionalized processes. They prefer to make up their own extremely lightweight methodology, doing only the activities they enjoy or believe they have time for. By adopting an Agile process, many claim they can eliminate the need for analysis, design, and even code reviews! Personally, I don’t believe this was the intention of the Agile methodology. However, given the substantial number of quality gates and sign-offs that organizations institute to ensure the elimination of mistakes, it is no wonder that Agile becomes the easiest method to subvert corporate mandates and deliver software. I completely understand the theory and goal of these mandates, but it does seem that by the time they are institutionalized, the overhead of the process is more complicated than the actual business to be solved! And before anyone corrects my association of Agile and Pair-programming, I do realize that Pair-programming is a tenant of Extreme Programming, not Agile. Unfortunately, many people seem to commingle the Extreme Programming principles with Agile; XP tends to generate negative connotations in some groups, while Agile is complete accepted.

I’m not sure how many normal people take advantage of Bluetooth technology, but I’m absolutely hooked. I run two and a half miles every morning using my Motorola S9 headphones. They are great for running, I can’t recommend them enough. I’m on my second pair; they unfortunately have an unreplaceable battery and would not hold a charge after a year or so.  My car has hands-free Bluetooth, which I must say that is pretty cool!  And now, my cordless phones are Bluetooth enabled too!

After the purchase of my OBi110, I needed to buy a real phone for the house, I honestly did not have one! I had researched Bluetooth / land-line phone integration solutions several years ago, but they always seemed rather “iffy”. I could never determine how well they really worked. They were always a little pricey, so I never took the risk.  I happen to see that Panasonic  had a line of phones with what they called a “Link-to-Cell” feature.  The phone seemed to get good reviews and was pretty reasonably priced; I picked them up for $57 from Walmart!  I have purchased Panasonic phones in the past and was always happy with them. These phone seem to be well made and comfortable to hold. I have not used the answering machine feature, since Google Voice provides that function for me; but did notice the “Voice Mail” indicator works on the phone! Think about that Integration – Google Voice services tell the OBiTalk network that I have voice mail, and then OBiTalk sends the message to my OBi adapter, which ultimately lights up the indicator on my cordless phone… Pretty crazy!

The Bluetooth integration is pretty slick. You can pair two different cell phones with the unit and assign different rings to each cell phone. You can also download your cell phone’s phone-book to the handsets. The phones even include “talking caller-id”, announcing the phone number or name of the person that called. My cell phone seems to pair instantly with the base unit when I walk into the house, no fuss at all.  The call quality seems no better or worse than using my old Jawbone Bluetooth headset. I think the sound quality is actually very good and have had no problems carrying on a conversation. You can easily make outbound phone calls with your cell phone, just dial the phone number and press the cell button.

I have only had the phones for a couple of weeks, but have been very happy with them. The convenience of being able to pickup a real phone is kind of nice, plus I don’t have to worry about where laid my cell phone down!

OK, back to the more traditional blogs starting tomorrow!  I just really wanted to share how well this inexpensive combination of technology really worked, linking together your cellular service, VOIP (Google Voice), and a traditional home phone into an unbelievably simple and convenient package!

Enter Google Voice. I have been a Google Voice user for a long time, even before Google purchased and rebranded it as Voice. I never achieved any great value from their service, but the integration with my Android phones was extremely nice. I mainly use it for the transcription of my voice mails. For the last year, I have used GV as my primary home phone, making most of my calls from the computer, using the Google Voice/Talk combination and a USB headset. This works pretty well, but sometime I miss talking on a real phone!

A couple of months ago, I happened to read about a free VOIP service, using an inexpensive hardware device from a company called Obihai. Their ObiTalk service provides both SIP-based VoIP and Google Voice integration.  ObiTalk provides a great amount of flexibility, including a Softphone solution, as well as applications for both iOS and Android based mobile devices.  To be honest, I really did not care about any of their advanced features, I just wanted the Google Voice integration.  I would have purchased the OBI100, but it was out of stock; so I ordered the OBI110.  Somehow, I happen to catch a deal, and picked it up for $45 from Amazon.

As you would hope, the OBi device takes no time at all to get working after you unbox it.  The first step is to create a ObiTalk account and register your device. The process is trivial, you just need to connect the device to your router and plug-in your phone. Next, click the add device button and follow the on-screen directions.  Simply dial the magic number provided by the site and your device will be connected to your account. I only encountered one surprise, the device unexpectedly rebooted a couple of times.  This behavior was actually expected, as the device has the ability to update itself from the central server. After a couple of auto-reboots, the device as been rock solid.

I have been using the service for about a month now and it has worked amazingly well. I’m not currently a fan of Google Voice’s call quality using my cell phone; I always blamed it on my Verizon service! Most of my calls seem to have a lot of strange echoes and delays, which you would assumed to be a GV server problem, not a Verizon issue.   However, the Google Voice call quality using the ObiTalk device is exceptional; I don’t think you would have any clue that the call was using a VOIP service.  The phone works as you would expect; you just pick it up and listen to that traditional dial tone, just like it always has been! I was also able to keep my Verizon phone number; the process to port  a land-line to Google is a little painful, but easily accomplished.  Because Google cannot port a land line, I had to first convert it to a wireless number, setting up a month-to-month contract. Once it was converted, Google quickly ported it over to their service, for a small $20 fee.

So, what is the downside? Today, nothing. Tomorrow, who knows! The future is the biggest concern; we have all seen numerous technologies quickly come and go over the years.  Google has not actually been very attentive to their GV user base, as enhancements to their service have been non-existent for years. Fortunately, the service continues to roll along and fundamentally works well enough for what it costs. The bigger question is how will Obihai survive?  Where do they get their funding to keep the ObiTalk service running? I’m sure they make a little money on their devices, but it hardly seems enough to fund the company in the long-term.  They provide exceptional service and a quality integration with Google, surely they will have to start charging for their service at some point. I could justify a nominal monthly fee, but if it is too steep, it would be easier to just give the money back to Verizon and user their VOIP package. Ideally, if Google has any long-term vision for Voice, they should seriously consider buying Obihai. It would give Google another open platform that would allow other SIP provides to integrate into their GV network.  It would also create a more economical and conventional solution for the typical, non-technical consumer to take advantage of VOIP technology and further expand the adoption and usage of the Voice product. I just hope that Voice does not end up like other recent Google technology victims…

One last point, Obihai does not seem to be slowing down. They are planning to release a new version of their hardware, the OBi 202. You can actually find quite a bit of information on that site related to Google Voice and the OBi services. You will have to read my next blog to find out what my other toy is!

On to PingTags; a new service, which I believe started earlier this year. It is a pretty simple, generate a QR code and link it with your LinkedIn profile. Give it a try, scan the code to the left! After spending way too much time on my resume and LinkedIn profile, I was rather intrigued by this idea.  I have seen QR codes in magazines, but was never excited by them. They obviously are bound to a paper world and I’m not really much of a paper person. At least 95% of my reading is done through my phone or Kindle, which essentially eliminates the need for scanning QR codes, I just click the link!  So, what is the point of PingTags? What about your business card? That was another interesting suggestion from the webinar; they recommended that everyone have a personal business card, something you can easily share with the people you meet. I honestly have not had a business card in over 15 years. A personal business card is something that I really never thought about, but it does seem like a good idea; and that is exactly what PingTags wants you do to… put the QR code on the back of your business card. I actually thought was kind of cool, in a geeky way! Flip over the card, scan it, and navigate to a nicely formatted mobile version of your profile. Not sure where I will go with this, just good information to know!

Several months ago, I discovered Scott Hanselman. He happens to work for Microsoft, but don’t hold that against him. He records several podcasts each week or so; I subscribe to two of them and they are both excellent. Scott focuses on a variety of software development issues and technologies. Hanselminutes is more technology oriented, while This Developers Life covers a variety of personal issue, from motivation, drive, to the Egyptian Revolution. I highly recommend going back and listening to all of the old This Developer’s Life episodes; I can’t tell you how insightful and reflective they are. As an added bonus, you get to hear some rather interesting musical choices! The people that he interviews are so interesting and have some really funny commentary. You will hear stories from different types of developers, both famous and infamous. You will learn how they navigated through their careers, sometimes successfully and other times, not so well. All I can say, is they are definitely worth the time! I hope you enjoy them as much as I did.

Wouldn’t it be cool to run all of the unit tests, in your IDE before checking in the your changes? Obviously, this action is expected by the developer and is completely possible without any special tools. However, it is not automatic and requires extra effort by the developer. Usually, it is easier to let the Continuous Integration server run the tests and fix the fallout later. It seems like a simple problem to solve; create a plug-in that automatically executes all of the unit tests saving a file, requiring no additional effort or interaction from the developer. If you are an Eclipse user, you have two good options, JUnit Max and Infinitest. I would really like to try Kent Beck’s JUnit Max, but you need to purchase a subscription to use (and even try)  the plug-in. That is a show stopper for me, as there are free alternatives such as Infinitest. I evaluated the Infinitest plug-in last year, after it was open-sourced. I did encounter some problems with the plug-in, my Spring-based projects did not work; I was quickly discouraged and abandoned the tool. Months later, I was still intrigued by the idea, so I gave it a try last week on a different project and achieved success!

Unfortunately, Infinitest is not currently installable from the Eclipse Marketplace. It can be quickly installed the old fashioned way from the Eclipse update site.  There is only one setting you may want to tweak, the Slow Test Warning threshold. If  you have unit tests that execute for longer than half a second, Infinitest will add a warning to your Problems View for each one; this could be problematic if you have a large number of long running unit tests. You should also notice a huge new “Continuous Test” status bar in your Eclipse footer. It will update automatically based on your coding activity. JUnit Max is a little more subtle, but provides the same type of feedback mechanism. That’s it, you are now ready to write code and auto test!

I’m not exactly sure how intelligent these plug-ins are, related to determining which unit tests to execute based on what code was changed. Hopefully that is the next level of continuous testing evolution. However, if you modify a single unit test, Infinitest will only run that single test; beyond that, I don’t believe there is much intelligence. If your code modification causes any unit tests to fail, the status bar will turn red. Unfortunately, it does not tell you how many test failed, it only provides the number of tests which it executed. If you mouse over the status bar, it will display the names of the tests which failed, but you can not click on them, they are just there for feedback. You will need to look in the Problems View to discover which test broke, the view will now contain markers for each failed test.

The only issue I have with the plugin, is around user interaction. It does not provide its own View for test results, it simply adds the failures to the existing items in the Problems View. I assumed that the Unit Test View would be updated with the test results, similar to manually running a unit test; however, this was not the case.  It appears that both Infinitest and JUnit Max use the same strategy, providing minimal feedback to the developer. Maybe this a good approach, but I was expecting more visual feedback and confirmation. I associate static problems with the Problems View, such as compiler and code quality errors, not dynamic problems such as test failures. The developer should be able to click on a marker (problem) and be navigated to the exact line of code indicated by that marker, giving them the opportunity to resolve the issue .  Here is my problem with this approach, if the developer clicks on the failed JUnit marker, where will they be navigated? The only possible location is the unit test which failed. Generally speaking, this is not where the problem would be found, it would lie in the code that was just changed. Given this issue, I would rather use a different View for continuously executed tests;   maybe even better, find a way to reuse the existing Unit Test View.

This does bring up an interesting question, do these plug-ins minimize or eliminate the need for Continuous Integration? I don’t believe this is the case, but would seem to eliminate the need for some of the more advanced features the vendors are implementing. One such example is TeamCity’s remote build, pre-commit test feature. There are many factors to consider, but if unit tests execute quickly, I do not see the need for this functionality to be provided by the CI server. If the tests execute for multiple hours, we could be adding more risk into the process, by not committing changes when they are ready to integrate. Remote build, pre-commit testing sounds valuable on paper, but I am struggling to see the real benefits. I tend to think this functionality over complicates the Continuous Integration process. One of the main benefits of Continuous Integration is that it is seamless and automatic. Nothing is required by the development team to reap the CI benefits, simply check in your code early and often.  As more education and process overhead are required by the CI process, it is no longer simple nor free.  The focus should be on doing what makes sense, at the right time, in the right place. These IDE plug-ins seem to have correct perspective, pre-check-in on the developers desk, simple, automatic, and efficient.

I hope that you will try to integrate one of these plug-ins into your personal development process. I believe they will help create a more robust development process, creating fewer Continuous Integration failures and ultimately, a more efficient, faster executing test suite. If you have real world experience with one of these tools, please provide some comments. I am still curious, does this approach work on real projects?

I had been a loyal Firefox user for many years. Firefox provided a nice cross-platform experience between Windows and Linux, and was highly extensible. This extensibility was one of the early benefits of Firefox, the ability to add new behavior to the browser through “Add-ons”. Amazingly, I was never a big “Add-on” user, I used a few of them, but did not take advantage or even explore what they could do for me. I used the Delicious Add-on for my bookmarking needs, but recently moved to the Diigo Add-on. I also use Firefox Sync for browser synchronization, including my tabs, bookmarks, history, etc. For posting to my blog, I’m a huge fan of the ScribeFire Add-on.  If you happen to do web page development, you have to try the Firebug Add-on. That is basically the extent of my Add-on usage, I did not ask too much from my browser!

Before jumping ship, I upgraded all of my machines to the Firefox 4 Beta. There were numerous technical improvements, but I was primarily focused on pure usability and how the browser could help me be more efficient. Start-up time was one of my biggest Firefox complaints; the browser seemed to have a tendency to bog down over time. The new version seems to have gone through a pretty dramatic user interface overhaul and addressed multiple performance issues, including start-up.

I was pretty happy with the UI changes, preferring the new, but controversial new tab location. The tabs are now located over-top of the navigation tool-bar; there was apparently quite a bit of debate on this little change! I prefer having two control rows at the top of the browser window, one row for tabs and the another row for navigation, apps, and widgets. I have seen a lot of content about these “web apps”, but it seems a little like pure marketing to me! The Firefox implementation, App Tabs, appear to be little more than a space saving short-cut; however, I can see them providing value for highly used web sites.

I had installed Chrome a couple of years ago, but was not too excited by it; I saw no compelling reason to change browsers. Wikipedia has an interesting graph of web browser usage; I was really amazed to see how the Chrome market share has taken off in the last twelve months. Even on my own blog, Chrome accounts for almost 25% of the traffic. I installed the newest version of Chrome last week and was immediately hooked. Unfortunately, I have become a true Google convert. It started with the purchase of my Android phone and there was no looking back. I am not saying that the following activities can or cannot be done in Firefox, I’m simply saying that I like everything better in Chrome!

A simple, but extremely cool feature is the “New Tab” behavior. It obviously opens a new tab, but its contents are quite different than you would expect. It is basically divided into three sections, Apps, Most visited, and Recently closed. Under the Apps section, you will see the Web Store icon; does everyone need to have their own app store these days? Anyway, the Web Store is a very well done site, that makes searching and installing new behavior extremely easy, using either applications or extensions.

Applications seem like fancy bookmarks, but from my reading, they can be (are) a lot more sophisticated. I looked at the SlideRocket app, it was genuinely cool… however, you can also run the app in Firefox! The app concept seems analogous to a rich user interface experience, one that performs like a real desktop application, rather than a collection of old-fashioned HTML pages.

My favorite feature of Chrome has to be the Extensions. Extensions add additional behavior to the browser itself. You can see from the picture to the right, I have added quite a few of them! They integrate into the Navigation Bar and look very nice, consuming minimal space while providing significant functionality. They look similar to the icons found in cell phones; many of the extensions have little indicators that track the number of items you need to address. You can find extensions for all of the standard Google tools: Gmail, Reader, Calendar, and even eBay. The Calendar extension is extremely helpful; it will tell you how long until your next appointment and when you mouse over it, it shows you the event details. The WP Stats is another personal favorite; it tells me how many people have looked at my site! Clicking on some icons will navigate you into the corresponding website, much like a short cut. Other icons have specific behavior, such as showing you detailed web site access statistics or an enhanced view of your search history. My favorite blogging tool, ScribeFire is also available in Chrome, but the spell checker is not working! I like the placement and interaction of the Chrome extensions much better than the traditional Firefox “Add-on” view, which is typically at the bottom of the browser window; Chrome make the extensions feel more integrated with the browser and part of the actual user experience.

My final Chrome praise is the synchronization with my Google account. It is pretty cool to watch an extension get automatically installed on my Windows machine, simply by installing it on my Linux machine. No restart or refresh required, it just automatically shows up!  I did notice one small oddity, I still had to configure the extension on the Windows machine. This seems rather strange, maybe it is a bug…. I assumed that Chrome would save each of the extension’s settings and synchronize them too. Even with this little shortcoming, there is no going back to Firefox for me, I hope you give it a try too!

I have probably described many of the same experiences you have encountered with Ant-based projects; they can be even more exaggerated when you start managing multiple projects. One possible evolution path is to define a “standard” directory structure and develop a collection of “shared” Ant scripts that work with the standard directory structure. This allows each individual project’s build XML to be little more than a set of properties. This is exactly where we ended up, utilizing an Ivy-like externalized repository for build scriptlets and Ant’s URL import capability. Hold on, a standard directory structure with reusable build components? Almost sounds like some other tool…

Changing a project’s build tool has a rather large impact and needs be considered from multiple perspectives. I have approached the problem by breaking it down into five (5) different spaces. This might not be the optimal or preferred approach, but does show the high-level differences and addresses the major build challenges. Surely, my next project will be done completely differently, but you have to start learning somewhere!

Perspective	Changes
Dependencies	To end up with an application that compiles in Eclipse, this change and the next have to be done in parallel. The easiest approach is to create a POM and focus on the dependencies section. If you are already using Ivy to manage your dependencies, this will not be that big of a change. Using a public Maven repository like MVN Repository to locate dependencies is very simple and saves a ton of time. The easiest way to create a POM is to let Eclipse make it for you; you will need to install the Maven plug-in first.  Once you have your project loaded into Eclipse, simply “Enable Dependency Management” in your project’s properties. You can also add dependencies directly from the  plug-in; I’m a little old school and prefer to edit the POM manually, but either approach works fine.
Local Development	I never liked the required Maven directory structure; I must have subconsciously adopted the Eclipse project structure as my personal standard. Converting the project’s directory structure was trivial and soon realized it was not that big deal after all; I aways separate my source and test files anyway. The main difference is everything lives under the source root, including the WebContent directory. I’m not sure what the “preferred” process is for loading a Maven project into Eclipse, probably using the Maven Eclipse Plug-in, which will create the appropriate Eclipse property files. Since I was doing a conversion, I don’t think this plug-in would be too helpful. Because I’m fairly Eclipse savvy, I simply wired everything up myself. Having the Eclipse Maven Plug-in will enable your dependencies  to be automatically added to the build path. With the addition of the Eclipse “Deployment Assembly” options dialog, it is extremely easy manually configure your project. You need to have a Faceted Dynamic Web Module for the “Deployment Assembly” option to be visible, but that should be a fairly simple property change as well. At this point, you should have a fully functional, locally deployable web application.
The Build	Now we can ignore Eclipse, and focus on building our WAR file using Maven. Even with the minimalist POM shown to the left (plus your dependencies section), it is possible to compile the code and create a basic WAR file. Use mvn compile to ensure that your code compiles. Using the Maven package goal, the source code is compiled, the unit tests are compiled and executed, and the WAR file is built. All of this functionality, without writing one line of XML!  One of the more time consuming parts of an Ant-based build is integrating all of the “extras” typically associated with a project, making them available to the continuous integration server. The extras include: unit test execution, code coverage metrics, and quality verification tools such as Checkstyle, PMD, and FindBugs. This tools are all typically easy to setup, but every project implements them slightly different and never put the results into a standard place! The general process for adding new behavior (tools) to a build appears to be the same for most tools. You simply add the plug-in to the POM and configure it to fire the appropriate goals at the appropriate time in the Maven lifecycle. Ant does not have this lifecycle concept, but it seems like a very elegant way to add behavior into the build. From the following example, I added the Checkstyle tool to the POM. The <executions> section controls what and when the plug-in will be executed. In this example, the check goal will be executed during the compile phase of the build process. Simply executing the compile goal, will cause Checkstyle to be invoked as well. This seems like a very clean integration technique, one that does not cause refactoring ripples. The Cobertura integration is another very good example. I have been a fan of the Clover code coverage for many years. Since losing access to Clover, I needed to look for an open-source alternative,  and had never tried EMMA or Cobertura. They both seemed like capable tools, but I had more success integrating Cobertura with Jenkins. I’m highlighting this point, as doing code coverage with Ant and Clover can sometimes be a little tricky and usually messy. The Cobertura plug-in takes compete responsibility for instrumenting the code, executing the unit test, and generating the report; completely non-intrusive.
Continuous Integration	Most development teams also want their project monitored by a Continuous Integration (CI) process. Modern CI tools such as Hudson/Jenkins provide excellent dashboards for reporting a variety of quality metrics. As I previously stated, it is rather time consuming to develop and test the Ant XML required to generate and publish these metrics; combine that with configuring each CI server job to capture these metrics and you have added a fair amount of overhead. I knew there was support for Maven-based projects within Hudson/Jenkins, but never took the time to understand why it would be beneficial. The main benefit is right there in the description, had I bothered to read it! Configuring a Maven-based job is little more than clicking a few check boxes. No need configure them in Jenkins, using the information provided by Maven, it is basically automatic. This is one interesting aspect of the Hudson-Jenkins fork. Sonatype, the creator of the Nexus Maven Repository manager and the Eclipse Maven plug-in, have chosen the Hudson side of the battle. I wonder what this means for Maven support on the Jenkins side. Obviously, it will not go away, but that might end up being a Hudson advantage in the long run. I still believe that the Jenkins community will quickly out pace the Hudson community.
Deployment	I’m not going into much detail on this point, other than to say that I would like to see the deployment process completely separated from the build process, maybe even done by two different people or organizations. I have seen too many projects combine building and deploying into one system, creating artificial dependencies, time consuming, unreliable, and unmaintainable deployment processes. I have also experienced complete deployment overkill, causing simple deployments to take over thirty (30) minutes, with no real guarantee that it would be successful. Hopefully teams (developer and operations) will strive for a minimal deployment overhead/process, one that provides just enough security and control to enable continuous, rapid deployments.

I have barely touched upon the real power of Maven and know that some people are going to say my requirements are too simple to be valid. I’m sure there are projects far more complicated than mine, but I do feel that this project is highly representative of the 80-20 rule. If developer’s can have a little self control, conform, and do what is required verses what would be really cool, simple Maven POMs should satisfy a large number of corporate projects with very little overhead. That is the goal, correct?  I can even see using Maven for my toy projects; why do I want to waste time writing and maintaining a bunch of useless build scripts? I never realized that you could ease into Maven; I think that is the real point of the post! And, it is not actually a huge investment.

When I was Googling for this topic, I found many interesting articles. I truly believe the biggest reason preventing teams from evolving and adopting new approaches is simply fear, fear of change and the unknown. I still think Maven is a rather large “pill to swallow”, but have now experienced enough value to continue investing time into this technology. I took the typical developer approach and dove into Maven with little preparation or understanding… I would not suggest this approach, unless you to have lots of time to waste! If you are unfamiliar with Maven, I hope the following collection of articles will provide a quick overview of the basic concepts. I realize that some of them are a little old, but you should start with the Maven basics, and those really have not changed.

An Introduction to Maven2
Should you move to Maven2
Maven vs Ant: Stop the Battle
How to Migrate from Ant to Maven: Project Structure
Top Ten Reasons to Move to Maven 3
Maven over Ant + Ivy
Automated Deployment with Maven – Going the whole nine yards