Roiy Zysman

GPS and images are a dynamic duo. GPS modules are becoming cheaper and cheaper which means that we would see more gadgets embedded with a GPS as a standard. Cameras and phones are probably the ones that would be on the front line of GPS embedding early adoption. Currently there is the Nokia's N95 cell phone and there might be soon to see camera's with embedded GPS modules (??) and some funny looking , cumbersome integrations .
So having these two modules is a blessing for geotaggers.
What is geotagging you ask? 
Taken from wikipedia
Geotagging, is the process of adding geographical identification metadata to various media such as websites, RSS feeds, or images and is a form of geospatial metadata. This data usually consists of latitude and longitude coordinates, though it can also include altitude, bearing, and place names.

 

And if you're lucky enough to have a GPS that can track export it's data , you can embed the  GPS coordinated into the JPEG images. Which means that on top of storing things like the camera model and time of picture taken , it can also store the specific location where the picture was taken. And to take it even further , there are image loading web services that locate on a map pictures that were embedded with their respective GPS coordinates . Panoramio.com is my favorite, Flickr used to support this by simply putting the latitude and longitude as tags , but it looks like it is no longer supported. Use Panoramio , it does the job.

When I published Yael , which is basically a set of .Net open source image filters class library, I tried testing that on several linux platforms using Mono. back than Mono was somewhere around the 1.2 version and trying to run several gdi related core lib calls crashed down Mono. recently , with the announcement of the completion of Mono's 2.0 api  I've decided to revisit this test. Another aspect that i've tested didn't go so well so I was a bit pessimistic.

We've started utilizing hyper-v for our product system testing. Beforehand the system test environment was composed mostly of around 16 physical machines playing different roles in different topologies. The machines applicative layer was mostly managed by loading up pre built specific role images. Things like different operating systems, different applicative clients (IE6/7/8 Office/2k3/2k7, etc) . Moreover, the  network topology was mostly managed by a VLan switch which was good in the flexibility point of view of moving machines between different networks without plugging out and plugging in different network cables. But once more complicated scenarios were introduced and more people got involved in the system testing effort , it was pretty obvious that the current test lab wouldn’t be able to scale up to the system testing requirements. So after a basic pros and cons analysis and discussion we have decided that we are going to introduce and rely on hyper-v as our virtualization engine but keep the old physical lab as a Plan-B if we would have to prove issues or sightings on a physical environment as well. Around one month down the road, we're very satisfied by the agility the virtual environments is providing us, changing network topologies on the fly , having a library of role specific images and a lot of other time saving advantages that I'll probably share in the future. Having said that , we've collected several good to know DOs and DON'Ts for working with a virtual environment in general and Hyper-V specific.

 
All videos grouped here in this nice RSS

virtualhosting.com blog has a nice essential list of item targeted for Computer Science students , but suitable also for everyone who sold his sole to the hardware and software gods..

 
All videos group here in this nice RSS

Code reviews are generally underrated. From my perspective and experience , if they are being conducted properly and successfully , which means that you don't fall asleep in them, they are the most productive tool to spot out bugs, performance issues, scalability and extensibility traps and bad implementation of a good (or even a bad) design. But, and there is a big but, they can be intimidating and uneasy if the expectations are not set correctly. I always try to explain what are the expectations who will be examined in the code review so that the presenter would have the chance to prepare better for the review.So to make sure your team's code reviewer won't be thought of as the grim, err, code reaper , try to set some expectations first.
Below are my two cents for preparing and setting the expectations for a code review . They are relevant both for the presenter and the reviewer.
Have fun :