Saturday, October 20, 2007

Building Large Systems at Google

This is a must see Web cast- building Large systems at Google.

1.0 Building Large Systems at Google
2.0 Making Great Decisions
3.0 Developing Applications with Ajax( Next Generation Asp.net)


I would like to have your feedbacks on these webcasts.

Thursday, October 18, 2007

Google Maps: Is the Earth a Sphere or Ellipsoid?

Google Maps sees the Earth as a Spheroid, not an Ellipsoid. This came up through a discussion on the PROJ mailing list and I thought it was interesting to point out how Open Source can even handle projected lat/long systems (such as Google Maps) using a very familiar tool called cs2cs.

Christoper Schmidt wrote about it on his blog and also on his blog he points out the EPSG code to use. The magical number for the Google Mercator Projection (of a lat/long grid based on a sphere) is: 900913

Now onto the fun, showing how we can use Open Source to have our data show within a KML project and Google Maps.

Quoting from Frank's FAQ, he provides an excellent example, we see the following the use of cs2cs:

"cs2cs +proj=latlong +datum=WGS84
+to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
+x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs"

Notice the sphere is being used? a=b

Because we are dealing with a sphere, the Y values will be greatly different from those on an ellipsoid (30 to 100 metres or more).

Quoting Frank again:

"In this case, and many other cases using spherical projections, the desired approach is to actually treat the lat/long locations on the sphere as if they were on WGS84 without any adjustments when using them for converting to other coordinate systems. The solution is to "trick" PROJ.4 into applying no change to the lat/long values when going to (and through) WGS84. This can be accomplished by asking PROJ to use a null grid shift file for switching from your spherical lat/long coordinates to WGS84.


cs2cs +proj=latlong +datum=WGS84
+to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
+x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs


Note the strategic addition of +nadgrids=@null to the spherical projection definition"

As you can see the value of Open Source and the mailing list and Open Source software is that people are sharing knowledge - whether it be via blogs, lists, or some other means of communication. There is a community out there that supports each other. These are actual users facing everyday problems and looking for solutions. The answers do exist, just the question has to be asked, and the community comes together to help.



Why not share experiences?

Hi blog members,
Our count is reached to 31, thats why sharing our day to day experiences in any field of Software Engineering would be very beneficial to all of us and to other blog readers.

I shall soon start writing my experiences over here, hope you too will do the same.

Regards.

Wednesday, October 17, 2007

Software Metrics: function points and lines of code

I have read a lot of papers and books that try to relate funtion points and lines of code.
The final step is always a big table with the lines of code for function point in every language.

Then the thesys is that is possible to derive the "effort" in man/month, given the fp count and the derived program dimension.

I think that there is a big mistake. In my experience to deliver 1M of lines of code I have to develop 1.5M of lines, and as my program get older, I still deliver 1M of LOCS, continuing to produce new lines that replace the old one.

A stronger example: as I develop new lines to correct errors, the User Manual (and the user interface) is always the same!

The real effort is related to LoC that I write, that are more then LoC that I deliver.