Sunday, December 30, 2007

The Best Internet Speed Testing Web Site

About every couple of months I run a speed test on my broad-band connection to make sure that everything is running properly and my ISP is providing an adequate level of service.

I never had one web site that I would always go to - to do a speed test. Typically I would do a Google search for "online Internet speed test" and find one that seemed to be doing an adequate job.

Today, I came across and I must say that I really like the site and it will become part of my arsenal of tools.


SpeedTest has one of the best interfaces for a speed tester. In addition it stores information about your last tests as well as allows you to compare your results with other ISPs and rate your own ISP. For those who might be interested, there is one version of SpeedTest that you can include on your web-site and another version that allows you to rebrand SpeedTest for commercial purposes. - The Global Broadband Speed Test

Friday, December 28, 2007

Cocomo II Application for Software Cost Estimation (C.A.S.E) by Dr. Joel Henry - Handango Pocket PC Software


What now to me seems like eons back I was part of a team that released the first software cost estimation tool based on COCOMO for the hand-held. It was called C.A.S.E (as it was a computer aided software estimation tool as well as CoCoMo II Application for Software Cost Estimation).

As the software was developed as part of a software engineering course that I took under Dr. Joel Henry we branded the software under the University of Montana logo.

The software is still available for purchase from Handango: Cocomo II Application for Software Cost Estimation (C.A.S.E) by Dr. Joel Henry - Handango Pocket PC Software

The application was written in what was called eMbedded Visual Basic a pre-cursor to the now mature development tools for the PocketPC platform. This version had almost no concept of encapsulation and object oriented development and hence we had to come up with some weird implementation mechanisms that allowed us to leverage OO concepts (one of which was to create separate forms - each form representing one class). Some day when I have the time - I would like to see what it would take to port the code over to .NET CF.

Twenty Three and a Half Rules of Thumb

Jim McCarthy was the leader of the C++ team at Microsoft. In his role as a lead he wrote the now famous "21 rules of thumb for shipping great software on time". Jim now runs his own software consulting group and you can find a revision of those rules as a series of podcasts called Twenty Three and a Half Rules of Thumb.

I first came across these rules in a software engineering class that I took at the University of Montana under Dr. Joel Henry. The ones about shipping on time I think are some of the most important and useful rules of thumbs.1781315

Here are the original 21 rules:

(also available in this book: Dynamics of Software Development: Don't Flip the Bozo Bit and 53 More Rules for Delivering Great Software on Time)

21 Rules of Thumb for Shipping Great Software on Time (Jim McCarthy, Microsoft Corporation)

Shipping great software on time is a difficult but not impossible task. Elements you think would count the most count for very little. Development methodology, process, technical prowess, excellence of tools and depth of project management skills all influence the outcome of a software development project; but nothing indicates success as much as the manager’s ability to focus on a few critical and conceptually simple things. These things can be expressed as rules of thumb.

I enumerate twenty-one of these rules of thumb. Pick a handful (or so), apply them, and your project will be more likely to succeed. I lump them into three groups: "Shipping," "Great Software," "On Time". Duh. I cover them in a different order, because the concepts build a bit.


On Time

1. Don’t know what you don’t know.

It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn’t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this "lucid ignorance," disaster will surely befall you.

Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don’t know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength to resist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty.

The organization surrounding you will undoubtedly abhor uncertainty, would infinitely prefer pseudo-order and will make countless attempts to magically convert your ignorance to knowledge. Your job is to make uncertainty an unshakable fact, and to coerce the reshaping of the surrounding organization to cope with the uncertain situation. The organization must learn to thrive in an uncertain environment for its own well being.

You should expend a great deal of effort making sure that all the people on the project are aware of their ignorance rather than naively converting it to falsehoods. Bear down on them until they realize they haven’t comprehensively assessed the unknowns. In the successful project, this is much easier in the early stages, or during times of change. This is no time for niceties. People ultimately prefer success even if disillusionment is a prerequisite.

2. Get to a known state and stay there.

The function of QA is to know (and articulate) the quality of the product at all times in the development cycle. This should be achieved by abbreviated, repeatable tests conducted daily, and full product sweeps conducted weekly or biweekly.

It is not properly the job of QA to determine when a product is ready to ship; rather, the moment of shipworthiness in a product development cycle is evident to everyone involved, and is non controversial. This is because shipping has been the goal of the entire effort. Crossing the finish line, while it has intangible emotional and definite financial rewards, is no surprise when you’ve observed every single painful step toward it.

The only reason you’ve been able to make these micro-observations is because you got to a known state and stayed there, and your QA is how you did it.

Achieving a relatively accurate view into product status is a very challenging goal, requiring a highly motivated and competent QA team. It is also a pre-requisite for success. Many software development organizations have rudimentary or no real QA assets, and there is little that can be done for them until they make the appropriate investments in creating a modern development organization.

A known state consists of all components having accurate status information at a given point in time. You know that it’s accurate because the status has been tested by QA.

A developer articulating the status of his/her component is an exercise that does produce information, but if it happens to communicate the component’s status, it is only coincidental. This is someone else’s job.

Status should consist of a comprehensive listing of tested and missing functionality, bug count sorted by severity, bug arrival rate, bug fix rate, projected total bug count, and other vital metrics.

3. Remember the triangle.

There are only three things that you are working with as a development manager: resources (people and money), features and the schedule. Changing one has an impact on at least one other axis, usually two. It is a simple enough matter to mentally run through the sides of the triangle, or force others to do so, when discussing any part of it. Since the people, the product or the schedule is almost always what you’re discussing, this means that you must constantly envision the triangle. This leads to the most fruitful line of thought.

4. Don’t go dark.

Some features have long development lead times, months or even years. Yet slips usually happen a little bit every day, and must be compensated for a little every day. This means that the granularity of development tasks must be such that deliverables are achieved at intervals sufficiently small that slips can be compensated for. A week is a long time to go without knowing what is happening. While micromanaging is always a danger, and will certainly be an accusation leveled against you from time to time, if the goal of the project is to ship great software on time, and if everybody accepts that goal as uppermost, they generally enjoy the chase. Team interdependency is also a powerful motivational force.

5. Use zero defect (ZD) milestones.

Organize the project around the concept a reaching milestones with zero defects. Zero defects does not mean that the product does not have bugs, or missing functionality; it means that the product achieves the quality level that had been set for that milestone. The product is tested to that effect. The essential point of ZD milestones is that nobody makes the milestone until everybody does, and nobody leaves it until everybody does. This enables the team to discover what aspects of the project are in trouble. Load balancing can occur. Awareness of unknowns rises.

At a milestone, the team and its leadership also have the opportunity to perceive the whole project status simultaneously, to draw conclusions about erroneous practices, to remedy bad design decisions and to reorganize for peak performance. Shipping is just the final milestone. Though the external organization cares most about shipping, which adds special pressure to that milestone, the team develops extraordinary focus and introspection about each and every milestone.

6. Beware of a guy in a room.

This is really just a special case of "Don’t go dark." Specialist developers who lock themselves away in a room, going dark for long stretches, are anathema to shipping great software on time. Without regard to their individual brilliance, before investing a developer with a significant assignment, it is essential that they understand and agree with the type of development program you intend to run. They must be capable of performing on a team, making their work visible in modest increments and subjecting it to scrutiny as it matures. Some people find this intolerable, and though there is a role for people of this disposition in the software world, it is not as part of a team devoted to shipping great software on time.

There are many pathologies at play here as well as certain healthy patterns of creative behavior. One pathology is a type of savior complex that cannot be satisfied without blowing every single deadline but the last, and then emerging victoriously with a brilliant piece of work five minutes late. A more healthy pattern is that of the true innovator who is truly designing something great, but who has no personal resources left over for anything but the work at hand. Every ounce of psychological, emotional and intellectual energy is being consumed in the work itself. Teamwork, in this case, is an insignificant factor to a person immersed in this sort of creative experience.

But whether or not the cause is healthy or bogus, the results are uniformly fatal to the professional development organization. Beware. Extricating yourself from this trap is nearly impossible.

7. Never trade a bad date for an equally bad date

Generally, you know you’re going to be late before you know when you’re going to be done. Further, everybody on the team and everybody they come in contact with knows you’re not going to hit the schedule. The pressure to reset the end-date (or the milestone date) is enormous. Even though your information is obviously better now than when you originally set your goal, it is probably insufficient to make a new schedule. This is because with each slip, you and your team are spending your credibility. It is essential that after a slip, the next milestone be hit. This is so the team believes in their ability to manage the project, and so that the reserves of credibility are rebuilt for later consumption.

It is difficult to say precisely and in all cases when you should "officially" slip. A good general rule is that the schedule should be reset when the total extent of the slip is known for each component, the causes of the slip are understood, and remedies are in place. Usually, this takes the effort of the entire team and its leadership, and must be an explicit, focused activity. After this level of work is achieved, create a new, closer and more conservative milestone which the team is very likely to hit, and promulgate that. Avoid just sliding the schedule out. Your near-in milestone should be extremely realistic, and uncertainties about later milestones will remain and should be highlighted.

8. When slipping, don't fall.

Slipping is what happens when information that was unknown becomes less unknown. Though slipping is widely perceived to be a "bad" thing, it is the symptom of a good thing, as a fever is the sign of the body’s immune system at work. Although it is undesirable to have so many unknowns that slippage occurs, it is not an unusual situation, and may even be the norm. This is because much of contemporary software development is essentially experimental, i.e., new platforms, new operating systems, new programming technologies often coalesce on new programming projects to create a high degree of uncertainty.

In order to avoid calamity, certain measures should be undertaken in connection with a slip. Ideally, one or more of the pre-identified unknowns caused the slip. It is important that everybody involved understand that the risk to the schedule had been known previously. Alternatively, it is essential to understand how the unknown/s had come to be overlooked. How this gap occurred should become part of the group knowledge for future success. Also, determine whether or not people are working on the correct things. Often, slips occur because members of the team become occupied with features of marginal consequence, or features that are not part of the core product message.

If the slip was a surprise, your communications system is broken, and dramatic communications efforts are required. Large amounts of detail must be brought to the surface for everybody on the team to see. Assess the reality of all current near-term estimates. Expose denial. Team defensiveness will have to be pushed back for the purposes of group learning. Slips reveal your team’s weaknesses, presenting a good opportunity for insightful management and mentoring. Make sure that each individual who has a role in the slip receives the needed guidance and support.

Slips are also an opportunity to re-evaluate the feature content and resource loads, generally with an eye toward decreasing the features and shoring up weaker areas on the team.

A good slip should be a net positive.

9. Low tech is good.

A smaller effort is almost always more desirable than a larger one. Shipping great software on time requires that we value an understood solution much higher than one fraught with unknowns. Keep in mind that customers would almost always rather see progress than promises.

10. Design time at design time.

The product will ship when the design can be shown to be implemented. Developers and their managers often ignore the exigencies of time when creating a design. Instead, they should consider the implementation time as a critical design element. When evaluating alternative design decisions, the one that takes longer to implement is consuming more time and should therefore be disadvantaged in comparison to the alternative. This must always be weighed. Often, when appropriate design value is awarded to timeliness, implementation time can be substantially compressed.

11. If you build it, it will ship.

Conversely, if you don't, it won't. The product should be built every day, along with all setup scripts and on-line help, in a public place, where QA can conduct appropriate assessment of daily status, and the entire team can observe progress or its lack. This is the single biggest indicator that a team is functional and a product being developed.

12. Portability is for canoes.

And system software. Even discounting the added development burden, with the addition of each additional platform the job of QA increases substantially. While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.


Great Software

13. Enrapture the customers.

Most software is a renewal business. Customers buy multiple releases over a relatively long period of time. As a consequence, the market has a deep understanding of your software and its flaws, and your organization and its flaws. Often, the market has grown uncomfortably dependent on software that doesn't meet its needs. In many software situations, customers spend hours per/day uncomfortably shoe-horning their lives into your product. As a consequence, they crave your understanding, and will respond enthusiastically to the least sign of it. Normal success, meeting customer expectations, means to improve the most outrageous and flagrant violations of their needs from version to version. They will likely stay with you if you are faithful about that, though they may well be sullen if not mutinous.

Great software, however, requires that you pivot your entire technology so that it flows in the direction of their deepest needs. You must innovate in ways that clearly affirm their inarticulate desires. Surprise them by articulating and resolving in your product concerns and fantasies that heretofore had been rumbling about only in their pre-conscious. The fantasies of the market are generally centered on issues of empowerment, control and security. The market wants to be able to do things with its computers that it currently can't. Customers often find they can't even publicly admit these needs for fear of computer illiteracy. They derive value and security from being able to apply your software. To admit that they can't do what they want to do requires a sense of security beyond most customers’ reach.

Market understanding is the foundation of great software. To repeatedly demonstrate through a series of two or three releases that you genuinely understand the market will result in enormous customer loyalty and brand equity. You will be viewed as the source of the market's empowerment. They will be rapturous.

Gaining this understanding and embodying it in your software requires skill, tenacity and creativity. You must recognize the central market need and organize all your technology and communications efforts in the direction of satisfying that need. While good listening, careful observation and concept testing will be required for you to identify the correct need, addressing it in your product will have these effects:

  1. It will appeal to the customer's sense of security.
  2. It will extend the customer's control.
  3. It will be such that if all else were dropped from your product, but the central need was met in unique ways, the product would be compelling.
  4. It will clarify your product messages.
  5. It will simplify your product's use.
14. Remember one thing: Unity.

Unity is the master principle of great software. Each element in the product is necessary to the value of the whole and all necessary elements are there. Since everything you need is there, you aren't tempted to go beyond the present experience, and since nothing is there that isn't required, your absorption into the world of the product will not be disturbed. Unity of purpose and unity in execution should be the hallmark of your team. Unity is achieved in a product by following certain creative principles (#15-#19, below), whether intuitively or consciously.

15. State your theme.

Theme is the dominant idea that constitutes the basis of the design. All of the values of the product must stem from the theme. In order for people to comprehend the theme, it must be rendered with surpassing clarity. Theme is analogous to purpose. The more specific the purpose, the greater the effect. Having a theme to the product will require that you eliminate or at least minimize orthogonal values. This is painful and involves risk.

16. Vary it.

Variation is the theme restated and elaborated in slightly altered and embroidered ways. Variation is the means by which we intensify the user's comprehension and appreciation of our theme, and leverage his/her growing consciousness in new ways.

17. Balance it.

Allocate appropriate emphasis among the various elements of the product. If a key component supporting the theme, encountered every time the thematic function is enacted, is weak, the theme is weakly stated and the product will be justly criticized.

18. Evolve it.

Evolution is when earlier parts determine later parts. Lessons learned in one part of the product apply to the others. Things progress in a way that is pleasing. Outcomes, if not predictable, are satisfying because the product foreshadows them in countless ways.

19. Your product should be a hierarchy.

Hierarchy is when the elements of the product gain attention in proportion to their importance. Closely related to the property of balance, hierarchy provides a means for establishing and evaluating balance. If the theme is the top of the hierarchy, elements at the next level have balanced value with respect to each other, all equally supporting the thematic function, and so on throughout the rest of the hierarchy.

20. Establish a shared vision.

It seems absurd to even have to state this, yet it is perhaps the most difficult thing of all to achieve. Everybody on the team must know what they are trying to achieve, what the finished product will look like, what the basis of the product strategy is, and when they must deliver it in order for it to have its intended effect. Contradictory visions must be resolved and unified. Harmonious purpose must be achieved, or greatness is out of the question and even shipping becomes infinitely more complicated.



21. Get the team into ship mode.

There is a moment on every development project when it is ideal for a team to enter ship-mode. Ship mode is a high performance period characterized by efficiency and determination. It is a period of flow. Before a team can enter ship mode, several pre-requisites must be satisfied.

  1. Shipment must be the next milestone.
  2. Everybody (or nearly everybody) must believe that achieving the milestone is possible.
  3. All members of the team must understand precisely what they must do prior to shipping. All unknowns are factored out.
  4. Management must lead the team to ship mode by entering ship mode first. That is, superfluous management hoo-ha is eliminated, the manager’s awareness of detail climbs, fire-drills and other de-prioritizing activities are eliminated entirely and tremendous focus is brought to bear.
  5. The team must desire to ship. Generally, a complete awareness of the effect of shipping (or not shipping) will create desire.

The team becomes especially vigilant about thinking things through, and looking for traps. Check-ins are made with extra precaution. Stabilization of the product is the principle goal. All development is complete but for bug fixing.

The endgame, the last stage of shipmode, is different yet again. It is conceptually a very simple exercise. There is a list of activities. When every activity on the list is complete, you ship. Though the list might have hundreds or thousands of items, it is still just a list. There is no time for any effort that does not contribute toward completing the items on the list. Everybody is expected to complete their items as promised. As unanticipated items arise, after appropriate resistance, they are put on the list.

A daily meeting should be established, with final decision-makers in attendance. Agenda is ad hoc, assembled at the beginning of each meeting. No item is postponed that can be handled now. The team is aware that all issues can be brought to this meeting for expeditious remedy. Management is involved, leading the team toward their goal.

The goal is an acceptable quality level at ship time. Only showstopper bugs should be addressed at all. Showstoppers are bugs that will either effect more than a handful of users or will cause unacceptably serious errors. Cosmetic changes, performance enhancements, new functions are not appropriate changes. The purpose of beta feedback during this period is to prove there are no showstoppers, provide advance warning of unanticipated market reaction and provide input to the next release.

Understand the range of quality that is acceptable to your customers. How many low priority bugs did your product ship with last time? Was it a problem? Are the customers better off with this product including this bug? Since destabilizing the software is more of a problem than most bugs, be very careful about which bugs you fix. This is why we have "ReadMe’s" and bug lists.

Shipmode is basically a succession of daily milestones climaxing with the product’s shipment.

Mint | Refreshing Money Management


I recently was introduced to It is a money management website where you can track all your credit card, savings and checking accounts, etc.

And I have got to say - I recommend it with 2 thumbs up. 

Mint | Refreshing Money Management supports all my credit cards and my big bank accounts. The only one that it doesn't yet support is a small one from Missoula. is secure as nobody but you can access the account data. The visualization options are great too and you get alerts about when bills are due.


The service is currently still in beta (which web service is not - almost seems like an extended beta as mandatory in these days of web2.o). As it matures I am sure it is only going to get better.

I have tried Microsoft Money (too complicated) and Wesabe (liked it - just didn't support all my accounts). Wesabe has one cool feature - it uses social information to label transactions as well as you can ask other users to answer questions you might have about managing money.

On the other hand, continuously looks through your accounts and interest rates and gives you suggestions of accounts to which you can move to, to save money. The budgeting options are simple - which makes it nice to use and you get to compare your expenditure to average US numbers.

Tuesday, December 25, 2007

FileMenu Tools

Ever needed to customize the Windows context menu?

I constantly keep adding tools such as Register, Unregister, Register using VS2005, etc. One way to get the job done is to edit the registry directly, but that requires to remember to many registry paths, variables and settings.

Enter FileMenu Tools.

FileMenu Tools allows you to customize and edit your File Menu Context menu in many different ways. It has extremely convenient features that even allow you to add commands and specify on what types of objects they should be available (folders or files - as well as file types, such as dlls, exes, etc).

You can also edit the Send To option.

FileMenu Tools (FMT) comes with quite a few built in customizations that out of the box extend your context menu almost off the screen. But as the tool allows for complete customization of the context menu - you can pick and choose the ones you like the most.

Awesome tool!

Also works flawlessly in Windows Vista (32).

FileMenu Tools

Building GDAL Source using Visual Studio


Here is a quick post on how to build the GDAL source.

  1. Download the latest source code.
  2. Unzip the contents of the folder onto your hard drive.
  3. If you are going to use the GDAL bindings (such as the bindings for C#) then download SWIG.
    Build the swig binaries if required and copy the swig executable (SWIG.exe) to the GDAL source root folder.
  4. In the root directory of the GDAL source that you just unzipped find the file nmake.opt and open it in a text editor and perform the following edits:
    1. Set the version of VISUAL STUDIO that you are going to use to build the GDAL binaries.
      For Visual Studio 2008 - set MSVC_VER = 1500
    2. Set the GDAL_HOME variable to the GDAL source root folder. This is where all the binaries, includes, library files and html files will be copied upon successful build of GDAL.
      I prefer adding Build to the source path - as all the built files will reside under one single folder.
      eg: GDAL_HOME = "C:\Development\GDAL\gdal-1.5.0\Build"
    3. In case you are going to be building the bindings then set the location for SWIG (also see step 3).
      eg: SWIG = C:\Development\GDAL\gdal-1.5.0\swig.exe
  5. To begin building
    1. Open a Visual Studio command prompt and navigate to the folder containing the GDAL source.
    2. Run each of the following commands
      nmake /f
      nmake /f install
      nmake /f devinstall

      At the end of running all 3 of the above commands you will find that the GDAL dlls will reside in the GDAL source root folder. Under the Build folder you will find additional folders containing the include files, library files, html files as well as GDAL utility executables.
  6. To build the SWIG bindings for GDAL
    1. Navigate to the folder containing the bindings for the language that you need it for.
      For example for C# navigate to the following folder:
    2. Run the following commands
      nmake /f interface
      nmake /f
    3. Once the bindings have been successfully built - the dlls and executables will be found in the root folder of the language. In this case the folder will be:

For the official guide to building the GDAL sources see:
The page also lists all the different options available in the nmake.opt file.

Friday, December 21, 2007

Merry X'mas

Here is wishing all of you a merry x'mas and happy holidays.

Don't send a lame Holiday eCard. Try JibJab Sendables!

Building GDAL 1.4.4 using Visual Studio 2008

Or this post could also be called - fixing C3136 error during GDAL build.

I have the release to market (RTM) edition of Visual Studio 2008 on my machine and decided to try building GDAL 1.4.4 binaries under Visual Studio 2008 (Professional Edition). Unfortunately when I first tried it, I got the following error:

error C3163: '_vsnprintf': attributes inconsistent with previous declaration

So how do you fix it?

I think the issue is that _vsnprintf is now being declared in some native header of Visual Studio. This results in a clash with any product that might be defining the function in its code. (And I think there might be a ton of projects that might be defining the function and hence will definitely cause a head-ache for many developers out there).

To fix it: Look for _vsnprintf in your code. If you see a line similar to

#define vsnprintf _vsnprintf

Then comment it out and you should be back in business. (For the GDAL source - that offending piece of code was found in port\cpl_config.h)

note: (update 12.25.2007) GDAL version 1.5.0 builds fine with Visual Studio 2008. All you need to do is set the correct MSVC_VER number in the nmake.opt file

Wireless Home Theatre System

The one reason that I don’t have a home theatre system right now is that my wife forbade me from having wires hanging or snaking across our living room. There are some solutions out there - but most of them are wireless only for the rear speakers and are typically analog solutions.

Finally NeoSonik has come up with a solution that is completely wireless and in addition is digital. (This means less interference - the hissy crackly noises that can make you feel like you are sitting in a dollar theatre).


The system is scheduled to be released in 2008 at the CES show. But at a cost that could range from $6k to $15k - I don’t think I will be getting a home-theatre system any time soon. (My biggest problem with the projected price is that I most probably will be able to get a Bose or Onkyo system and pay for a professional to hook the wires through the walls or do it myself, and still be left with a good deal of change)

But nevertheless - its a cool new product - that is more that overdue in the market.

Come to think of it - I wonder how hard it would be to leverage the home WiFi connection to create your own wireless digital solution?

Bug Labs: Electronic Lego blocks

 Bug Labs


Ever wanted a set of electronic components that you could plug together just like LEGO blocks to build a final device? One can do it with computers and plug n play peripherals, but why not with your camera or GPS system.

For example: If you had a digital camera and a little later you decide that you are sick and tired of finding the USB cable every time you need to download the images. Instead of going out and buying a new digital camera which is WiFi compatible, why not be able to plug-in a module that gives your camera that capability. In the same way - if you are going on a world tour and you would like to have your images auto geo-tagged as and when you take your pictures - it would be cool if you could attach a component that gives your camera GPS capability.

The list is endless - you could remove the digital camera module and attach a touch screen module and voila you would have a PDA. Or you could attach a GPRS module and instead of using WiFi hotspots you could be constantly connected via cellphone towers. (The company doesn't seem to have plans of a GPRS module just yet - but I am sure they will release one as soon as the product takes off).

According to the company:

BUG is an open source, web-enabled, modular software + hardware platform.

Bug on the Maker blog

The main module of the Bug is a Linux embedded computer. The first modules that are going to be available are a digital camera, GPS, motion sensor and a touch screen. Going forward - they are actually going to add a teleporter module (hopefully it will teleport you around the universe without leaving your clothes behind).

The company bills its product as an open source device. Not sure if this means that others will have the schematics to build and connect their own devices, or is it only as far as creating software that can talk to the company's devices. The device has a SDK called DragonFly which can be leveraged to write software to work with the BUG. The SDK is in JAVA and the company may possibly provide tools to allow for easy software creation using the Eclipse IDE. The SDK is available right now and one can create applications (not sure how much you can do without the actual device to play with)


A list of open source software that the company uses is available at:

Being an open source project - what this means is that by the time the product hits market shelves, there should be a considerable list of plugins that one could download to their BUG device. This is important because usually when a device ships it comes with a bare minimum set of applications. But once users are given the ability to create apps for the device - it normally means that you will get apps that are actually useful to you. As an example, say you pickup the touch screen, which makes your BUG into a PDA. With the touch screen you may get a simple ToDo list app. Now you might need a GPS navigation device - so you add the GPS module. Some user out there might have looked at the 2 modules and say - hey why not make the ToDo list location aware?! He could write the software and then your ToDo list could automatically pop up items based on your location.

The fact that they have made their platform open to other developers is definitely a very cool thing.

As the store is not yet open - I am not sure what the cost of the device is going to be or its add on modules. One model that the company could use to supplement its income is to have a store front on its site where developers could sell their creations to other BUG users and the company could make a percentage of the sales (a la BugBay). In addition if they add a GPRS module - they could provide the cellular data service and charge a subscription fee for it (constant revenue stream - which company doesn't like that!)

I can't wait to take this product and its accompanying SDK for a spin.


Thursday, December 20, 2007

In depth look at the Dash Express GPS

In a previous post I had written about the totally awesome new GPS device called "Dash Express". The device has me tickled silly with all its cool and innovative features. I have been reading more about the company and the technology that they are using.


So one of the things that I do know is that the Dash Express runs on LINUX. The company site lists numerous open source packages that they use on and for developing the device's software ( - you can even download the packages with all the changes that they may have made to them from this webpage.)


I have listed the packages here with more information about what each package does:

Dash Express - Finally a connected, crowd-sourced GPS

graphic-product-santa-teresa 2113067755_d4bb5a944e_m


I have had a GPS system for a little over a year. It is a MIP c310x and for $150 it does more than adequate a job of guiding me to my destinations. I have looked at the more expensive systems - like the ones from Garmin (Nuvi 360) and TomTom (Go 920) which retail for close to $600. I just found them an overkill. For the extra price you get spoken street names, maybe traffic information (you have to pay a monthly subscription) and maybe a wide screen display. But $450 just for those features - no thank you! I can do with out them.

From the first day I have had my GPS unit, I have wanted some features that I just did not find on any of the GPS units out there.

  1. Ability to download route information from the computer.
    Setting up a route to just one destination is fine using the touch-screen of a PND (Personal Navigation Device). But if you have to travel cross country, or if you wish to have multiple destinations - then the touch screen interface can become a pain. I have always wanted a way to define my route on my computer, where I have access to the Internet and I can perform research on the stops, etc and then have that route uploaded to the PND. There doesn't seem to be even one such PND out there that can accomplish this simple task.
  2. An Internet connected PND
    Many a times, I have found my self in a new neighborhood and I would want to find a certain establishment to visit. For example if I wanted to find a restaurant (maybe an Italian restaurant), current PNDs will show you a list of such locations based on the distance. But without a rating or review - how do you choose which one to go to. With WiFi becoming prevalent and ubiquitous, wouldn't it be nice if you could take your device to a hotspot and look up information about a point of interest (POI)? The PND could give you recommendations that are based not only on the distance but also on reviews. To take it a step further - the device could act like the iPhone - use a WiFi connection when available - otherwise connect via the cellular network to download that information.
  3. Share information about maps, roads and POIs
    Granted TomTom's MapShare can do some of that, but with so much social networking going on - their solution is pretty crippled. An ideal solution wouldn't just allow you to share road closure information, but also POIs, new roads, events, etc. Just about any information that could leverage location should be shareable. (TomTom can download road-closures, but you cannot directly share new road information - it is uploaded to TomTom and probably provided to you as a map update - for a price of course).

Enter Dash Express.

Dash Express seems to be the first PND that seems to have all of the capability that I always dreamed of wanting in my PND. I always wanted to build such a system - now I guess I don't have to smile_sad.

  1. Computer to PND Connectivity:
    The feature is called "Send2Car". Currently Dash Express does not seem to have the capability of defining your route on a mapping application like Google Maps or Virtual Earth, but you can use Send2Car to send addresses from your computer to the device. Even cooler, you can have someone else send you an address while you are on the road - Woof! Woof!
    The Dash - supports GeoRSS and KML (Getting your web content in the car!). So I don't see why it wont be possible to export your route from Google Maps as KML or use another tool to export it as GeoRSS and load the content on the Dash. Even if not possible in the first release - I am sure that the capability will be added very soon to the Dash.
  2. Traffic information:
    The traffic information that Dash provides you isn't the same information that you see in your other PNDs. The traffic information is not just from the traditional sources, Dash also uses information from other Dash users - called the Dash Driver Network. (More on this technology in a later post). And because Dash uses other Dash users to detect traffic changes - it can provide information about local streets in addition to high-ways. This technology is just not available via any of the other PNDs.

  3. An Internet connected device:
    The Dash supports both connecting to the Internet via WiFi and GPRS (cell phone) networks. Which means that while you are at home or near a HotSpot you could take advantage of the higher speed and band-width of WiFi and while you are on the road you could exchange information using the cellphone networks.
    It is this Internet connectivity that allows the Dash to break out of the mold of older PNDs. Which include:
    * Crowd-sourced traffic information from traditional sources as well as the Dash Driver Network.
    * Yahoo local search - and possibly ability to search using other services. (This makes the amount of POIs available to the device unlimited).
    * Send2Car - which allows you to send information from other Internet connected devices (traditional computers, cell-phones, etc) to the Dash.
    * MyDash - a portal for owners of the Dash. I am not clear about what this site provides - but you can possibly customize your Dash with specialized search buttons and maybe other customizations such as skins in the future.
    * AutoUpdate - which allows your Dash to always have the latest software and maps running on it.
    Because the Dash needs to use GPRS, there is a subscription component to owning the Dash. This varies from $9.99 to $12.99 depending on the plan you sign up for. (Compare that to TomTom's Plus Traffic service, which costs € 39.95 for 1 year subscription + costs for use of your mobile phone. - and gives you information only about the traffic as opposed to Dash - which gives you access to all the above features - value, value, value if I may say so)
  4. Open Content Platform:
    Though not touted as a feature on the product page itself - there is a lot of talk of the "open content platform" on the company's blog. This feature might be huge if it allows 3rd parties to either develop plug-ins that can be installed on the device and can then download location based data to the device or if the 3rd parties can publish data in a specific way, so that the Dash can take advantage of it (though one would be able to do that with the GeoRSS or KML formats).


And just like the expensive Garmins and TomToms, the Dash Express sports a wide screen. At a price of $599 (, I think there is almost no reason that one would still want to but one of the other PNDs that are available at the same price point.

What does all this mean: Since the early 1980s when the first PNDs debuted the devices have hardly changed (current position showed on built-in maps and routing). In my opinion the Dash Express is the biggest innovation seen in almost 20 years. Every one of its new features will definitely strike a chord with current and new PND customers. This, I am sure, in the near term will translate to many of the other PND manufactures dropping their prices so as to compete with the better feature set that Dash provides. In the long term many of these features (especially true Internet connectivity) will start appearing on the other PNDs. And as the currently unique features to the Dash start appearing on the other devices - the Dash will start becoming cheaper. I would also think that the subscription costs might get cheaper as more people purchase the device. Another price driver might be the fact that by dropping prices, more people will sign on to the Dash service. And as more people get tied into Dash's network - the more information the Dash will have for it's users, which will possibly keep Dash as one of the best services to stay with. (So the faster that Dash can get more people tied to its service, the harder its competitors will find to steal away those users).

So for all my gushing for the product - are there features I don't like: Yes.

  • The Dash uses Linux: I wish it were a Windows device - because those are typically easier to hack. The device I have runs on Windows PocketPc and the GPS software is called iGO. The device is highly hackable and hence highly customizable. I can turn my Mio into PDA, I can customize the skin to show exactly what information I want on the map. (None of these are easy to do as there are no tools that allow easy access to the settings - never the less it is possible). On the other hand the TomTom that I have - has Linux running - and even though you can get an OpenSource TomTom app on to it, it mediadoesn't seem to be as customizable as my Mio running iGO. Though this is not a huge issue - where there is software - hack-ability will followsmile_wink.
  • The form factor: The Dash is not flat and thin and so wont fit in your pocket. So in it's current avatar - you probably will find it a pain to take it out of your car and walk with it. (It would be nice if the wing section in the back would fold down for storage - v2.o maybe).
  • The price: at almost $600 - is still pretty expensive. It makes the WAF (wife acceptance factor) that much lower.
  • 3D View of map:  The one feature I cannot find anything about and which I think is extremely important in today's GPS navigation systems is a 3D view into the map. None of the screen shots, nor the specifications on the company's website talks about 3D maps. I think that 3D maps make it a lot more easier to follow a route and if it isn't there in this version - then I would most probably wait for a version on which it will be offered.

So will I be pre-ordering the device? Even though I would love to have one to test, my Xmas gifts for this year have already been bought and I typically wait for v2.0 of any device before I go out I buy them. So probably not yet.... but if the device has 3D maps and given that the cool factor is so high for me on this device - I just might.

Finally, here is a video of a presentation the company did at Web2.0 Summit:

And Gizmodo has a video where the device was taken for a spin in a car:

The videos shows you all the cool features I have written about: Send2Car, Search using Yahoo! and mashups using Zillow and CraigsList.

A very cool device indeed!

Tuesday, December 18, 2007

Virtual Cable™ Car Navigation - Why Didn't I Think of That?

Here is an invention that makes me go "Now, why didn't I think of that?". A heads up GPS navigation system for cars.


It is called the Virtual Cable. The driver sees the Virtual Cable - a line representing his path - projected on to the windshield. It looks like its a suspended cable - hence the name "Virtual Cable".

According to the inventor's website "The image is in true 3D and appears to be a natural part of the landscape. The driver uses only peripheral vision to follow the Virtual Cable™."

Virtual Cable™ Car Navigation - Safe, Simple and Intuitive

More about the technology:

The device is only a prototype right now and from the looks of the site - the inventor is trying to line up funding for taking this device to production.

Will be cool to see how the finished product looks and how much more information is displayed on the wind-shield.

Sunday, December 16, 2007

Mobile phone tracking

sc2  sc1

Beta GSM mobile phone tracking system via the GPS-TRACK satellite network

You plug in a cell phone number and it shows you where the phone is on a map.

Mobile phone tracking

According to the website:

Based on repeater triangulation, the system tracks mobile phones using GPS and GSM technology

Approximate margin of error:
10 meters (max.) for mobile phones in Europe and the U.K.
25 meters (max.) for mobile phones in the U.S.A., South America and Canada.
50 meters (max.) for mobile phones elsewhere.
This system will not work in countries without GSM technology networks.

Thumb Calendar

via Thumb Calendar [Adam Sporka's Home Page]


The "Thumb Calendar" by Adam Sporka is something I stumbled upon while searching for a calendar to print and keep in my wallet. And this calendar qualifies for it.... it is simple, small and most of all - innovative. The dates are printed continuously across the face and to read the dates for a particular month - you cover all the other months with your thumb - hence "Thumb Calendar".


Best plugin for publishing code snippets via Windows Live Writer

After testing a couple of different code snippet publishing plugins for Windows Live Writer (WLW), I found that Leo Vildosola's plugin to work best with Google's Blogger.

If you select the embedded option - the code is published properly colored and formatted with indentations and all.

Download from WLW Plugin Gallery

A couple of other useful plugins for developers:

Here is some sample code pasted via Leo's "Insert Code Snippet" plugin

// NOTE: This code snippet is designed for VS.NET 2005 or later.
// Additional reference: System.Security.dll
// using using System.Security.Cryptography;
// using System.IO;
// This is a button click event - to encrypt the DB string to disk:
private void btnEncrypt_Click(object sender, EventArgs e)
    // The DB string that we want to encrypt/decrypt:
    String strConnectionString = $strDBString$;
    // Call the custom method for encrypting the string:

// This is  a button click event - to unencrypt the saved DB string:
private void btnDecrypt_Click(object sender, EventArgs e)
    String strConnectionString = this.DecryptDBString();
    // Do something with the unencrypted DB string ...

// This method will encrypt the provided DB string to disk
private void EncryptDBString(String DBString)
    /**************** Encrypt/Protect Database String ****************/
    // Convert the string to a byte array:
    byte[] arrDBString = System.Text.Encoding.Unicode.GetBytes(DBString);
    // Provide additional protection via entropy with another byte array:
    byte[] arrEntropy = { 4, 5, 7, 9, 4, 5, 7, 9 }; // Save this for unprotecting later
    // Encrypt/protect the DB string:
    byte[] arrEncryptedDBString = ProtectedData.Protect(arrDBString, arrEntropy,

    // Write the encrypted DB string to disk:
    using (FileStream fs = new FileStream($strFileName$, FileMode.OpenOrCreate))
        fs.Write(arrEncryptedDBString, 0, arrEncryptedDBString.Length);

// This method will decrypt the saved encrypted DB string
private String DecryptDBString()
    /**************** Decrypt/Unprotect Database String ****************/
    // Setup the unencrypted DB string to return:
    String strUnencryptedDBString = null;
    // Provide additional protection via entropy with another byte array:
    byte[] arrEntropy = { 4, 5, 7, 9, 4, 5, 7, 9 }; // Save this for protecting later
    // Setup the byte array that will hold the encrypted DB string:
    byte[] arrEncryptedDBString = new byte[0];
    // Read the encrypted DB string from disk:
    if (File.Exists($strFileName$))
        using (FileStream fs = new FileStream($strFileName$, FileMode.Open))
            // Reset the byte array's length based on read length:
            arrEncryptedDBString = new byte[fs.Length];
            // Read the encrypted file into the byte array:
            fs.Read(arrEncryptedDBString, 0, (int) fs.Length);

    if (arrEncryptedDBString.Length > 0)
        // Decrypt/unprotect the DB string:
        byte[] arrUnencryptedDBString = ProtectedData.Unprotect(arrEncryptedDBString,
            arrEntropy, DataProtectionScope.CurrentUser);
        // Convert the byte array to a string:
        strUnencryptedDBString = System.Text.Encoding.Unicode.GetString(arrUnencryptedDBString);
    // Return the unencrypted DB string:
    return strUnencryptedDBString;

XML Serialization/Deserialization in C#

Here is a code snippet that I continuously use; it is used to serialize an object to a string and deserialize an object from a string. (The interesting thing to see here is during serialization the code uses a StringBuilder object which is passed to an XMLWriter which is in turn sent to the XMLSerializer).
public static object Deserialize(string data, Type dataType)  
    using (TextReader rd = new StringReader(data))   
        XmlSerializer sr = new XmlSerializer(dataType);
        return sr.Deserialize(rd);   

public static string Serialize(object item)  
    StringBuilder bld = new StringBuilder();   
    using (XmlWriter xmlWr = XmlWriter.Create(bld))   
          XmlSerializer sr = new XmlSerializer(item.GetType());    
          sr.Serialize(xmlWr, item);    
          return bld.ToString();

Saturday, December 15, 2007

~| 137 |~


from: ~| 137 |~

137"One hundred thirty-seven is the value of a number called the fine-structure constant. This constant, 137, is the way physicists describe the probability that an electron will emit or absorb a photon. Because this is the basic physical mechanism of electricity and magnetism, the fine-structure constant has its own symbol, the Greek letter a, “alpha.”

Now, alpha is nothing more, nothing less than the square of the charge of the electron divided by the speed of light times Planck’s constant. Thus this one little number contains in itself the guts of electromagnetism (the electron charge), relativity (the speed of light), and quantum mechanics (Planck’s constant). All in one number! Not only that, this number isn’t like the gravitational constant or the universal gas constant, full of meters and kilograms and degrees Celsius. Alpha is a pure, dimensionless number — little wonder that people have been fascinated."

The Manycore Shift

Microsoft Parallel Extensions to .NET Framework 3.5: a managed programming model for data parallelism, task parallelism, and coordination on parallel hardware unified by a common work scheduler.

The Manycore Shift White Paper : This paper describes how Microsoft and industry partners are working together to enable businesses, software and hardware vendors, and individuals to take advantage of the “manycore shift”.


MSDN Magazine Article: Parallel Performance: Optimize Managed Code for Multi-Core Machines

MSDN Magazine Article: Parallel LINQ: Running Queries on Multi-Core Processors

Sunday, December 09, 2007

LAS 2.0 data types and corresponding data types in .NET

The LAS2.0's specification defines the data types it supports in table 3.1 on page 4.

The following table shows the corresponding .NET data types as well as the C# built in data type.

LAS 2.0 Moniker Data Type Size (in bytes) .NET Data Type C# Type Range
BOOL Logical 1 Boolean bool true or false
B1 Byte 1 SByte sbyte -128 to 127
UI1 Unsigned Byte 1 Byte byte 0 to 255
I2 Signed Short Integer 2 Int16 short -32768 to 32767
UI2 Unsigned Short Integer 2 UInt16 ushort 0 to 65535
I4 Signed Long Integer 4 Int32 int 2,147,483,648 to 2,147,483,647
UI4 Unsigned Long
4 UInt32 uint 0 to 4,294,967,295
I8 Signed 8 byte integer 8 Int64 long -9,223,372,036,854,775,808 to
UI8 Unsigned 8 byte integer 8 UInt64 ulong 0 to
R4 Real Float 4 Single float  
R8 Real Double 8 Double double  
R10 Real Extended precision Double 10 ?? ??  
STR STR zero (null – binary
0000 0000)
terminated variable
length string
VAR Byte[] byte[] Even though the data is stored as an array of bytes, one can use the string data type and use convertors to convert the string to the byte values. Also remember the values are not the .NET Char type which is 2 bytes in size
BFx bit field x, where x = 1,2,4,8 Byte, UInt16, UInt32, UInt64 byte, ushort, uint, ulong data types are used as bit fields
[n] Array VAR Array Array of any of the types defined above for example UI[4] is uint[4]


  • The BitConvertor class as well as the BinaryReader class can be used to convert bytes to their corresponding .NET data types.
  • To convert a byte array to string one can do the following:
public static byte[] StrToByteArray(string str)
    System.Text.ASCIIEncoding encoding=new System.Text.ASCIIEncoding();  
    return encoding.GetBytes(str);
  • And to do the reverse
byte [] dBytes = ...
string str;
System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();
str = enc.GetString(dBytes);
  • The BitArray class (System.Collections namespace) can be used as a helper class to work with the BFx data type. It can handle arbitrary length bit fields and provides methods that allow you to perform bit arithmetic.
  • An important thing to remember is that bool in .NET is actual 4 bytes long (which corresponds to a WIN BOOL). So if you need to marshal your structure to native code or need to convert the data to bytes - you will need to use the Marshal As attribute to do it as a byte (UI1)

More information:
C# Data Type: 
LAS 2.0 Specification: 
LAS Documents:

Got Tech Posters?

Via Chris Bowen's blog post - Got Tech Posters?

The post lists all the different posters available to .Net programmers. The posters are related to .NET 3.5, Visual Studio 2008 and other MS technologies like BizTalk Server.

Here are my favorites from my list (which are related mainly to VC# and VC++):