Reflections

After getting my Ipad2 (Thanks to Thoughtworks!), I wanted a Wi-Fi connection since the Ipad2 had Wi-Fi but no 3G. Wi-Fi routers cost anything from Rs.1500 to Rs.10,000. Question was: How do I convert my laptop to a Wi-Fi router? Connectify is the answer. Link: http://www.connectify.me/ The basic (lite) version is free and can easily used for providing Wi-Fi connection to the Ipad2.

  Reviews I liked were http://reviews.cnet.com/8301-19512_7-20115364-233/iphone-4s-first-take/ – More or less, the official version copied from Apple. http://www.youtube.com/watch?v=cP-SSg_zZ1M – Watch for the question (joke) at the end. IPhone has good Processing power Camera and HD video Siri (Voice recognition) Can I use Ipod Touch instead of an IPhone. If you are thinking of calling somebody, IPod can be used for that as well. ( http://lifehacker.com/378511/turn-your-ipod-touch-into-an-iphone ) Are there other differences between Ipod Touch and I Phone? Well, both have identical features except… IPod touch does not have Email Maps In built Camera Microphone Blue tooth External link : http://reviews.cnet.com/8301-19512_7-10115117-233.html http://www.themobileindian.com/news/1307_iPhone-or-Samsung-Galaxy-S2 - Comparison between Iphone 4 with Samsung Galaxy 2.

Found out we are losing time due to aborted runs. People are looking at different ways to avoid the run getting aborted. I feel it is mostly due to environment failures. Having a good environment should provent 70% of the failures. On another note, I would like to have an email sent to all of us in NFT whenever a run is triggered or when it is completed/aborted. I have two solutions for that which depends on following info (ie whenever a run is triggered or completed/aborted, VSTS writes into the loadtest database). 1. A trigger on the database . Basically fired on “insert or update”. And this sends an email to  us. 2. Wrote a script in Auto It which queries the database and finds out if a new run was introduced or not. This would require the script to know about the latest run id (which will be fed as input parameter) Had a discussion with our architect and he felt the first option was better. I felt the same too.

The last time I had mentioned about the pipeline which made sure the IIS paths are correct. Now we will go to the next step and look at the stages for this particular pipeline. The pipeline has 4 stages. TOC_Copy_JasCasStubFile TOC_Compare_JasCasStubSize TOC_Copy_Physical_Path_of_Stubs TOC_Compare_Physical_Path_of_Stubs We will look at each stage in detail in part 3 of this blog series.

I was just wondering if we could combine all our soak tests into one. One ground rule we can follow during performance testing is “how it is done in production”?. In this particular project, all the streams are deployed and used simultaneously in production. Well, I have raised the question to our client. Once I propose the solution (how to implement it), hoping the client would accept it. This would bring in huge savings in testing time. To the reader: Did you also have a good idea and ask the client to accept it? If so, what is the approach u followed?

I have seen so many cool blogs that I thought my blog needed an overhaul. The templates provided by Google were not cool enough. I googled for best blogger templates and I found the following links. http://besttheme.net/ In this, I liked the Faith Blogger template. Let me apply it and see what happens!

  Context: One of the steps before we run our performance test involved going to stub server and make sure that the physical path of all the important services are pointing to, is correct. It was taking too much time because we had to remote login to the server and look at the IIS for the physical path and compare it with actual path provided in the wiki. So what was done? I have created the following pipeline called “CheckJasCasStubSize”. And all you have to do is click on the play button. This pipeline also checks the size of the file and does a file comparison as well.

Sometimes people have a screenshot and they painstakingly go over the numbers. Manually reading the numbers and typing it out in notepad. Then use the calculator in windows to find the sum, average etc. I found this recently in my team, where some of us were actually looking at the VSTS tables while the run was going on, typing out the numbers (eg: cpu, memory etc) into notepad and finding the average using excel. Well, not anymore! Here is the solution using image recognition software. Solution : Use an image recognition software like  "JOCR" (thanks to Sreedhar D) uploaded to "\\nftparing box\D\SOFT\ImageRecognition.exe". When the software is run, it asks for the area to capture. Drag a screen area around the table (or the screenshot) u want to capture. The output would be a set of numbers. Copy paste into Excel and click on the "Average" button in Excel. And you are done!

  The problem We always had scrollbars (vertical as well as horizontal) when we connect to remote desktop (eg: nftRunbox01). This meant we had to scroll up and down many times to work on rotheram environments.  Full screen was an option, but we wanted to see the taskbar as well as the messages from skype (Paul). I remember my colleagues would not allow pairing unless the scroll bar issue was fixed. :)  We ended up editing rdp files and what we tried to do was... desktopwidth:i:1437 desktopheight:i:865 session bpp:i:24 winposstr:s:0,1,0,20,1437,865 We changed the winposstr values so that horizontal and vertical scroll bars disappear. This was a trial and error method and consumed a lot of time (10 to 15 mts). I looked at a few open source projects and found a project on sourceforge which solved the problem. I was still looking for a way (easier) to solve the scroll bar issue. Solution Just add the following line to your .rdp file. smart sizing:i:1 Old RDP File desktopw...

The very first version of Microsoft Word for Windows was considered a "death march" project. It took forever. It kept slipping. The whole team was working ridiculous hours, the project was delayed again, and again, and again, and the stress was incredible. When the dang thing finally shipped, years late, Microsoft sent the whole team off to Cancun for a vacation, then sat down for some serious soul-searching. What they realized was that the project managers had been so insistent on keeping to the "schedule" that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote "return 12;" and waited for the bug report to come in about how his function is not always correct. The schedul...