Why Tablet PC is not a good Idea

at least not when you have small kids at home...

I love my x60 Tablet (Lenovo's ThinkPad) and as Photography is one of my main hobbies I work on it quite a lot in its Tablet state.

Now, I have 3 kids at home - they all love to paint.

So when they saw me playing with the wonderful application - ArtRage, they have automatically joined the party.

This was fine with me - why not giving my little baby to draw with the WACOM pen instead of soiling gouache all over the place?

Until today the little one saw her big brother using the Tablet, and because the WACOM pen was taken - she just picked up a Mechanical pencil from somewhere and...

OUCH... a Scratch.

Lesson learned: Buy a tablet for each kid so yours will be safe!

Lesson learned (for not that rich people): KISS - Keep It Shut, Stupid!

See what Silverlight can do... or is it ???

I just read Jason Langridge's WebLog about Microsoft's new Windows Mobile site.

It is an interesting UI concept, and my first thought was that I need to send it to some guys in our R&D group to show them what can be done with Silverslight.

I have an email already open with the link Pasted, when I decided to check which Silverlight version were they using.

What Have I found - this site is ADOBE FLASH based...

Beware of Obsolete

Short time before moving to Production with our application after upgrading it to .Net 2.0 - we have discover a major problem:

"Invalid Handle Exception" was thrown multiple times under Load Test.
It was thrown from SqlConnection.Open()

When looked in Reflector I saw the responsible for this exception was GetLastWin32Error method which is called somewhere in the call stack.

I have tried to understand why does it happen - and came to conclusion that this exception is originally thrown from other place in the system - and this GetLastWin32Error just catch it  - Also it shouldn't:

"Multiple threads do not overwrite each
other's last-error code" (from MSDN)

 

So now I looked for the real source, I made a search on all our source code to find where we use Handles. Finally I have found a usage of System.Threading.WaitHandle.

I looked at MSDN and Voila, this WaitHandle.Handle is Obsolete...

just changed it to SafeWaitHandle and the problem disappeared!!!

 

Lesson Learned - Always remove Obsolete methods and classes.
They are obsolete for a reason...

My Flickr

Originally uploaded by Yonatan Leonov

So yes - I have a flickr user and I have upload some interesting pictures over there - You are invited...

Team Build - Failure Email Alert - Make it Actually work for you

Long time no see. Yes I know it's my responsibility, and I don't even have a good excuse. So I hope you'll forgive me anyway - and let's go on.

Background

We have started at last to use Team Foundation instead of the "Die in Peace" Visual Source Safe. And as part of the move I decided to construct a CI (continuous integration) Build. I have followed "Continuous Integration Using Team Foundation Build" from MSDN, and I had a CI build in no time.

I even register myself to the Build Complete event, and created an Outlook rule to play a wav file (where I have recorded myself shouting "The build has failed, the build has failed"). But my roommate has made me shut it off.

Eventually you need to notify the developers of failing builds, and if shouting on the speakers doesn't works, I decided to forward the Email notification to all R&D Group List.

The Problem

But then I have started to get complaints from everyone on those emails. The developers tell me - "Why did I get this Email? I haven't even perform any check-in. So I couldn't be the one who caused the build to fail".

"They are right" I tell myself. If I keep sending those mails as suggested here, everyone will put a rule to send my email right into the garbage can. So what to do?

My Solution

The idea is to send failure emails only to the developers who performed a check-in. It is not a perfect solution - I know, It would be better to send the Email only to the spesific user who actually caused the failure - but at least it's a start.

Implementation

I have used Howard van Rooijen's Team Foundation Server Notification Web Services project template and implemented new functionality at the
Build Completion Endpoint. I check CompletionStatus, and if it "FAILED" I loop through Build's Changesets (as I learned here), collecting the users names. I construct a mail message based on TFS Mail template and just filled it with the correct data. The most important part, of course: I send this mail only to the users I have collected from the Changesets.

I hope to be able to upload the code soon.

Future Improvements

I plan to add some intelligence which will read the Build's log, and try to analyse who is the truly responsible for the failure.

Let me know what you think...

Inferring... or just guessing!?

Yes, Yes, another bug...

We add support for multiple languages to out Web Application, and a lady from the QA asked me solve the following bug:

When inserting Hebrew (or any language other than english) characters to a TextBox and saving to the Database, you get Question Marks ("????????") instead of Hebrew characters.

But is it fun enough? No?

So lets add that
it doesn't happens everytime...

First, I have checked the Database field: [Name] [nvarchar] (50)
It was NVarChar, which is ok.

Then I have looked at the Stored Procedure : @deals ntext
It declared a parameter of the type - nText.
This is fine, because actually this parameter gets an xml string of the whole Dataset, which can become big.

Next, I have checked the SqlCommand's Parameter in the code:

StringWriter writer = new StringWriter();
newDeal.WriteXml( writer , XmlWriteMode.DiffGram );

sqlCmd.Parameters.Add ( "@deals" , writer.ToString() );

You can see that the code uses the overload which doesn't declare the SqlDbType.
So lets check it on Run-Time.

Usually, the SqlDbType was nVarChar, but when the bug occured it was VarChar !!!

But why is it has been set to VarChar?

After a lot of thinking and experiments, I finally got it:

when the value used in the "Add" statement is a string, the framework use nVarChar as its default SqlDbType.

But...

if the string is
longer than 4000 characters (which is the size limit of nVarChar on SQL Server) the framework uses VarVChar instead.

Yes...

Without checking if
you have any unicode characters in the string.
I won't call it "Inferring"
(microsoft term) - I'll call it "guessing"

Of course, after you know the problem, solving is not an issue.
Just declare the Parameter type explicitly!

And, by the way, after you know the problem you can easily find the Microsoft's document which tell you what you didn't know:

"String - NVarChar. This implicit conversion will fail if the string is greater than the maximum size of an NVarChar, which is 4000 characters. For strings greater than 4000 characters, explicitly set the SqlDbType."



See you soon

Jon.

Cruel Bug and the IIS Default Document

Last week, one guy from our QA department called me with a bug he found in one of our Web forms. After a short debugging I have discovered that one of the Session variables has been overwritten by with the wrong data – after been filled with the right data.
The code which causes the problem was not in the requested Web Form. Actually, it was on our "Default Document" - Default.aspx (which we declared in IIS).
But why is this default page been loaded? Who called it?And why does the browser gets the right page and not the default page if it does been called?
The next step was to put a breakpoint on the unwanted code, and watch for the "Call Stack" to see who called this code. This is a dead end. No user code calls this page.
But wait, maybe the application is being redirected to this page by "Response.Redirect" or by "Server.Transfer"?But the answer (after checking all the call to those two functions) is – No.
"Application_BeginRequest" in "Global.asax" is our next station.This is a good place to out a breakpoint, and it works this time too.
My breakpoint is being hit twice, once for the requested page, and again for the Default document page.
So, now I know that the unwanted code runs because the browser requested it.But when looking on the source of the page received by the user's browser, I can't find any redirection to the default page…
And then I got it.
One of the images tags in the html source was:

It was without any file name because there wasn't any image for this item in the DB, and the programmer hasn't checked for empty strings in this field.The browser requests this path from IIS, which in turn translate it to a request for the default document page. This, of course, explains why the browser doesn't show the default document. It asks for it as in image…I have just removed this image from the page to see if it solves the problem…
NO. It still happens.
I have read the html source again and again, searching for another mistake like that…YES!!! I got it!

The browser take the empty string of the "src" attribute as a request to the current path, which IIS answer with the default document again!
Conclusion:
Never leave any unspecified "src" attribute. You'll end with the browser requests the default document of the current directry.
p.s.
After I have finished to write this blog, I have found this blog.
I wish I have read it before meeting this bug...