Google Maps V3 GeoCoding Example

July 24, 2011

Today I was working on a real estate search wrapper idea and trying to integrate Google Maps. I wanted to use there Javascript API for mapping but needing to translate the addresses to longitude and latitude aka GeoCoding. Turns out Google of course has an API for this but I didn’t find a straight forward example right away so I figured I would post one. Minor disclaimer on this, its the SIMPLEST possible example to just take one address and turn it into a longitude and latitude (visit here if you need more info on the API). Hopefully this is helpful to folks.

Script Include

Before using the below code you’ll want to add a script include within the head element of your HTML page first.

<script type="text/javascript" src=""></script>

The Code


1:  var geocoder = new google.maps.Geocoder();  
2:  var results = geocoder.geocode(  
3:    {  
4:      address: "Duke University Durham, NC 27708"  
5:    },   
6:    function callback(results){  
7:      alert(results[0].geometry.location);  
8:    }  
9:  );  

A Simple and Free UML Tool

July 17, 2011

Now that I have lost my MagicDraw license, I have been looking for a free alternative to do some UML. In looking around I found a great alternative called Violet UML.

I’m a big fan of it mainly because of how simple it is to use. The usability directly attributable to how stripped down it is or at least appears to be. Honestly it looks to have all the functionality that I need, supporting the following diagrams with necessary objects.

  • use-case diagram
  • class diagram
  • activity diagram
  • sequence diagram
  • state diagram
  • object diagram

It doesn’t have a ton of functionality to generate code, create unusual diagrams or objects, or a million menu options to sort through. I completely appreciate those engineers who leverage that extra functionality, there are situations where you sometimes can’t do without it, so if that’s the case then this tool isn’t for you. Extremely good though for just creating a diagram.

Windows PHP Dev Made Easier

June 18, 2011

I have recently developed a semi strict policy of avoiding spending significant time messing around with serious server software installations on windows. Just because of the lack of windows machines in my life. Yesterday I needed to setup for the first time in a long time apache/mysql/php on a windows machine and I found a decent productivity boost for those of us who are still wired to operate in linux land called WAMP. If your not familiar with administering apache and mysql it could possibly be a HUGE productivity boost for you.

WAMP packages together Apache HTTPD, Mysql, and PHP with a convenient management interface for starting, stoping the services and getting to configuration files.

Get it at ->

Should just take literally seconds to get everything up and running. Of course if you have version requirements on any of those packages then you maybe out of luck and downloading, installing, and configuring everything independently, which may or may not be  huge deal for you.

Tech Resume Ideas

June 17, 2011

I just recently finished a job search and while it was fresh I figured I would throw out some resume ideas/opinions I have generated after talking with other people about resumes and seeing what worked. These aren’t specifics on format or a style guide at all, they are thoughts on how to determine what content to put on your resume. I have done a lot of interviews and the 10 page resume does no one any good, I try and keep my resume to 1 page with a second page that described the companies at the time of employment for people not familiar with them.

Resume Ideas…

  • Don’t fill it with crap you don’t care about or hate, in the end you want to be identified for the stuff you liked to do and work with. Of course there is some boiler plate stuff you need on it but keep it to the point.
  • Start writing your resume with simple bullets of what you think and your peers state your strengths are in all aspects of your life from personality, experience, and skills. Once you have those bullets make sure every part of your resume brings out those.
  • Be concise. If you can’t skim the resume in a minute or so and get an idea of what technology you have worked on and what roles you have played on projects, you have too much content.
  • Have your spouse (or someone else who has no idea what you really do) review your resume. Despite the technical jargon, they should be able to “get it” and “get you”. The reason for this is sometimes its the HR folks screening resumes, not technical junkies, to have a chance they need to be able to understand you. Also they generally will catch grammar or flow issues easier (and never let you forget it ūüėõ ).
  • Putting something like ‘SOAP/JNDI/TCL/BASH/XML/XSL/XSLT/CORBA/XSD/ICMP/TCP/UDP/ATM/PCI’ on your resume may get you to pop up in some automated system but any person can see through it in two seconds interviewing you. If they can’t see through it, I wouldn’t want to work for them. Only put experience and technology on your resume you are willing to talk to in a interview and if there is too much cut it down the most relevant technologies to the position and/or you.
  • Stand out on your resume but make sure your being true to your personality and profile. If there is something unique your involved in or interested in put find a way to get it on there. However don’t exaggerate or put statements which don’t match your personality.

Felix and Websphere 7

December 25, 2010

Recently I have ran into issues running Apache’s Felix Project in IBM Websphere 7. When you try and start an embedded Felix OSGi container you get class cast exceptions that classes are not properly matching the interfaces. Specifically I saw that the bundles implementations don’t match BundleActivator interface. Also you could see issues with the “getBundleContext” method not existing on the Bundle class. After some gnashing of teeth I have found the fix for this and its took a little digging so hopefully this will save folks time with the same issue.

The problem…

Websphere 7 (and possibly 6.1+) is including on the classpath org.osgi.core packages which include versions of the interfaces used included in the Felix jars. Also the classes get loaded into the bootstrap classloader which is prefered by Felix when when loading classes. The net result is if you have class loading set to parent first (the default setting) you will see missing methods on interfaces being called, specifically Bundle.getBundleContext. If you have parent last classloading set you will still see issues and all your bundles will not be able to initialize because of class casting issues on BundleActivator (or maybe other interfaces as well). The casting issues are from classes being loaded from different classloaders, bootstrap verses application, when that happens classes even if they have the exact same methods on them will not properly cast to each other. I believe you’ll see most of your issues in the System Bundles for class casting.

The Solution…

There is a pretty simple two part solution which can be accomplished via no code changes…

  1. Ensure your Felix and related classes are included in your war file or some other class loader ahead of the bootstrap class loader in a ‘parent last’ setting. Generally this means set your Web Application to parent last class loading. If you are loading Felix classes from somewhere else ensure the class loader you are loading them with is a parent last classloader.
  2. Update the org.osgi.framework.bundle.parent configuration to ‘framework’. The easiest way to do this just add that exact property name as a system property with value ‘framework’. By default Felix delegates class loading to the bootstrap class loader overriding the class loading strategy set on the initializing code which is what is causing the class cast exception due to multiple versions of the classes getting loaded.

For more configuration properties available for Felix visit

The Importance of Being Testable

October 31, 2010

Designing and building for testability in software at all levels (functional and unit testing) is one of those things most people don’t get. When I first started out in software I remember getting stuck with a last minute task of creating a web client for a test team who needed to test a XML web service. At the time I cursed the task and didn’t really think there was much value in creating the test client. Now though I try and put testing hooks like that all over the place. After looking back at software systems I have designed or worked on, I have realized that one of the main things that people have cursed or praised code on is testability.

Why Testability is Important?

Every developer has their own style for design and coding and some of them are going to think anything else is basically wrong, even if it works. So trying to win people over with coding style or awesome design is a losing battle. The central concept to all good code and systems though regardless of style or design is being able to validate if it works (aka testability). The more you can isolate each part of the system into individual testable parts the easier it becomes for people to feel confident in making changes. Which is ultimately what it’s all about. If someone can come into a system they have never worked on before, make a change, and feel confident about the change, they can’t get too upset.

Designing for Testability

Testability is all about isolation. If you are creating a system with dependencies on another system you need to be able to eliminate the need for that other system for testing. There will be scenarios where you don’t want to have the dependency whether it’s during a unit test or you don’t have access to that system in certain testing environments. Solutions for this could involve the ability to configure different end points at run time and/or putting proxies in front of calls to intercept and return mock responses. The same goes for code, you need to be able to isolate units of code and make them fail or pass tests only if that code is broken. This will involve using factory patterns, dependency injection, and/or other loose coupling strategies.

All Systems Must be End User Testable

Even if your developing a service which operates over an obscure protocol with proprietary message format, there is no excuse for not having a test interface available to allow non-developers to test the functionality. In many cases this means creating a test program or test interface on a system. This may not be in the requirements however it should be. It’s left out many times because they are written in the context of an integrating system which drives testing. Unfortunately the integrating system may or may not be available in all environments and also there could be bugs in the integrating system requiring alternate testing interfaces to validate your system which should validate the need for a end user test interfaces. One of the main places you’ll find integrated systems missing is working locally as a developer. All these aspects of testing make it desirable to get end user testability in what you are developing and it will help people down the line as well.

XML4J to Xerces Version

September 22, 2010

I have always thought the fact that IBM packages in their websphere JRE libraries a re-packaging of several xml jars specifically Xerces and Xalan. They call it the XML4J jar (the file name will be xml.jar). You can check out the version of the XML4J which is associated with your IBM JRE by running the following

java  org.apache.xerces.impl.Version

That’s supposed to give you the Xerces version However that’s the XML4J version not the Xerces version. I was able to find on an IBM support forum ( which lists out the version mapping. I have place it below as well for folks to see as well.

XML4J Version Xerces Version
3.2.x 1.4.1 + defect fixes
4.0.x 2.0 + defect fixes
4.2.x 2.4 + defect fixes
4.3.x 2.6.2 + defect fixes
4.4.x 2.6.2 + defect fixes
4.5.x 2.8.1 + defect fixes

The No Exception Business Process

September 10, 2010

One of real challenges with custom software is maintenance after the fact. There are always trade offs being made for cost over flexibility. An example that has been a thorn in my side for quite sometime now are business processes developed with no way to plan exceptional cases by a business user. I think the mistake here is idenification of what type of process you are working on. Software developers look at processes and are inclined to think “technology process” not “business process”. With a “tech process” such as rolling logs or backing up files a developer would be right to have assume no exceptional cases are necessary to be administered by a business user. But a nightly business critical process such as moving approved changes or clearing processing queues needs to able to be administered by business users otherwise there will be duplicated efforts, both a business user and a engineer will need to assist. Identifying proper administration over processes will reduce support cost and produce a system which has the necessary flexibility to support the business process.

Keep Your Project Files in the WAR

July 13, 2010

Have you ever created a project and had someone say (maybe that person was yourself) “we better put that file in an external place so I can be changed at runtime just in case”? Chances are¬†if you did and followed through on it without a specific requirement for it then I would be willing to bet you ended up never changing the file at runtime (presuming you have a relatively¬†strict change process at your shop). I have put myself in the same situation many times creating overly complex software which involved many random file system structures¬†external to the central package (in JEE the WAR file) because of the “in case we need it” rationale. I want to convince people that we should stop unless its required.

When you start creating file system dependencies or other dependencies on your code outside the package you are basically trading increased complexity for¬†flexibility. In most cases I have seen this trade off made (outside of requirements) because people are trying to anticipate issues with the code but it actually¬†just heightens the probability for issues in the future because of the increased complexity. It’s not that you won’t code it right the first time but in the future it can and¬†probably will cause confusion and problems with new developers without a lot of extra work. The extra work being creating hooks in the build process, handling¬†potential environment differences, and deployment issues beyond the initial build.

In the end if you have the belief you can code it write in the first place then just code the simplest solution right, don’t over shot the¬†mark. Unless you¬†have a compelling need avoid creating external dependencies on your application.

Exim4 HELO config in Debian

July 7, 2010

Not a normal post subject for me but I spent sometime today toiling with getting Exim properly configured to work with my new scanner today. Figured maybe someone else can save themselves sometime.

The scanner has the ability to email scans but when I adjusted all the configurations, I got a SMTP communication error on the scanner. Checking out my /var/log/exim4/mainlog I saw something like the following…

2010-07-06 21:12:42 rejected HELO from [X.X.X.X]: syntactically invalid argument(s): DIGITAL_MFP

With a quick search on the web I found this message thread. Seemingly it had all the information I needed. However I have a Ubuntu server install and it doesn’t seem use the default configuration setup (/etc/exim4/exim4.conf) it has a template configuration file (/etc/exim4/exim4.conf.template) and then a variable file (/etc/exim4/update-exim4.conf.conf). Using debian package config you won’t have the flexibility to add or update the needed configuration…

helo_allow_chars = “_”

But you can just add it to the top of /etc/exim4/exim4.conf.template file and then run through debian package configure and your problem will be fixed!  Hopefully that saves someone some pain, its a pretty obvious thing to try but I went through a couple of other guesses wasting quite sometime.