Monthly Archives: June 2009

Got a GPS? …Lets Play Geocaching

The other day I was roaming the Internet; link here link there, tweet here tweet there, and I stumbled upon a very nice game called Geocaching.
Geocaching, simply, is a game in which players hide items in any place in the world, and the other players should find, yes…Treasure Hunt. But the fun part is it’s Global, and the GPS is your primary tool!

The players who want to hide an item, should first label it and give it a unique identifier, then record the coordinates (longitude and latitude) of the place they hide it in, and finally they should post the information along with the coordinates on the game’s website

And I was lucky enough to know that there are 17 geocaches in Jordan! below is an image of my first geocache quest result with my good friend Tamim Salem, using my iPhone’s GPS.


The item was broken and this paper is the only thing left.

Can’t wait to quest the rest 😉

A Case We Shouldn’t Use Stored Procedure’s In

We are working on this big project at work in which several teams are assigned to different modules. The modules are, naturally, overlapping in certain areas where they they need to interact with each other through API’s.

One of these modules is central and crucial to the rest of the modules, the dependency is very high that the team has to provide many API’s. Certain API’s was needed by different modules; our team needed a list of entity X, and another team also wanted a list of entity X, BUT…we had different criteria!

For example, Entity X had an Enum property called “Type”. The API provided a parameter to filter on this Type, but the options were limited to couple of choices; either you get entities of THIS type, or you get all entities.  If you needed type A and B only, you will have to get all the entities in the database, or make two hits to the database and join the two lists.

A solution was to give all the various options to the user as optional parameters some of which was Array of values. This resulted in an ugly API signature that had many optional parameters, and when ever a new criteria is needed, the signature would change and break all the already existing calls for the API, and I will not even imagine how the SP would look like!. An ugly alternative as well is to create new SP for each different criteria. Both choices are maintenance killers.

In such cases, the dynamic queries are just wonderful; depending on the properties the end user needs to filter on, a query will be created dynamically with proper operator passed. Usually ORM engines, or similar engines, will provide you with an “internal language”, e.g. SubSonic:
Episode  ep = new Select().From<DA.Episode>().Where(“Title”).Like(“SOA”).ExecuteSingle<DA.Episode>();

Another example is the “query by example” in NHibernate (code snippet is taken from NHibernate help):
IList episodes = session.CreateCriteria(typeof(Episode))
    .Add( Expression.Like(“Title”, “SOA%”) )

And, of course, LINQ:

var episodes = from x in db.Episodes where x.Title.Contains("SOA") select c; 

Or you can build your own ;).

I hope this gives an insight.

DPack for Visual Studio, Better Navigation

There have been couple of code assistance and refactoring products for the Visual Studio IDE, two of the top listed is CodeRush and Resharper; they provide amazing and rich functionality regarding code refactoring and navigation.
But if the built-in refactorings in the Visual Studio itself suffices you (I am comfortable with it), then the only thing you need is DPack for Visual Studio; it’s a simple navigation utility by which you can navigate to the wanted File, Class, Method, or Property as easy as couple of strokes.

“Alt + U” to navigate to a file, the list is filtered as you type and the matching isn’t necessarily made for the beginning of the word:


“Alt + M” navigates to Methods:


“Alt + Shift + P” navigates to Properties:


very simple and handy, one of the tools can’t live without it. DPack everybody.