XMLHttp

XMLHttp is the future of web application development. It allows threaded communication between the client and the server without ever leaving the page. If more advanced JavaScript features are standardized this might mean that a web application will act and feel very much like a regular windows application. Up until now, one of the major differences between a windows application and a web application was statelessness. However, with XMLHttp this is reduced much further because a state will no longer be rountrip from the server, it will be when the user enters a page does several thousand things and leaves the page (when they leave the page the state is lost) however during those thousand events all the state will be maintainted — this can be done using XMLHttp.

So what is XMLHttp exactly?

XMLHttp allows XML formatted (ideally) data to be passed to a server-side page using client side script. The response from that input can then be read back using a client side script and some actions performed based on that output. Consider this scenario, let’s say you are writing a address verification system. Your boss thinks that the user shouldn’t have to pick the state because just typing in the zip code should automatically select the appropriate state. In the olden days in order to do this you would have to do a Postback on the server and check the zipcode against your database to resolve the state. With XMLHttp once the user types in the zipcode the zipcode is passed to the server to resolve the state. When the result is found the dropdown box for the state is changed to the appropriate state — without ever leaving the page.

Next time I will post some sample XMLHttp code and discuss this further.

The trailing slash

Sometimes a simple change as adding a slash may improve the performance of your web-applications. Consider this: the link www.codescrub.com is slower than www.codescrub.com/ (the only difference being the trailing slash).

They will both work but the latter is faster. When this link: www.codescrub.com is followed the web-server returns a 301 (Moved Permanently) pointing to www.codescrub.com/ that’s one extra round trip to and from the server per link. If you have a site that’s running without the trailing slash and you have 10K+ visitors you will certainly start to feel the consequence.

Old bugs are harder to catch

About three years ago I worked on an application that in-part had to blend in with several other applications. Among many features one of them was to automatically generate something known as deadlines. The actual details are far to complicated to explain in details here, so I will use a simpler example.

Assume that you have four types of documents each have their own specific way of computing deadline. One of them follows a rule like:

  1. The deadline for document A is the fourth work day of the month
  2. unless the fifth of the month is a Friday and that friday is a workday.

  3. If however the month for which we are computing the deadline for is August then the deadline is 3rd Friday unless it’s happens to be a holiday; in that case then it’s the first available workday since the 3rd Friday of the month.

As you can see the rule is not straight forward and involves several fine details that if programmed incorrectly will cause other systems to fail, since it feeds data to them. One such bug caused this app to fail yesterday and finally we found what the problem was. In order to see the bug I will first present to you a pseudo-code of the intial program:

if(!FifthIsFriday(CurrentMonth, CurrentYear)) {
	if(CurrentMonth.GetMonth() != "AUG") {
		Deadline = FindFourthWorkDay(CurrentMonth, CurrentYear);
	}
	else {
		Deadline = ThirdFriday(CurrentMonth, CurrentYear);
		if(IsHoliday(Deadline)) {
			Deadline = FindNextWorkDay(Deadline);
		}
	}
}
else { // Fifth is a friday
	if(IsHoliday(DateValue(CurrentMonth+'/'+5+'/'+CurrentYear)) {
		Deadline = FindNextWorkDay(DateValue(CurrentMonth+'/5/'+CurrentYear));
	}
	else {
		Deadline = DateValue(CurrentMonth+'/'+5+'/'+CurrentYear);
	}
}

/*
Output deadline
*/

Now the corrected code.

if(CurrentMonth.GetMonth() != "AUG") {
	Deadline = FindFourthWork(CurrentMonth, CurrentYear);
}
else {
	if(!FifthIsFriday(CurrentMonth, CurrentYear)) {
		Deadline = ThirdFriday(CurrentMonth, CurrentYear);
		if(IsHoliday(Deadline)) {
			Deadline = FindNextWorkDay(Deadline);
		}
	}
	else { // Fifth is a friday
		if(IsHoliday(DateValue(CurrentMonth+'/'+5+'/'+CurrentYear)) {
			Deadline = FindNextWorkDay(DateValue(CurrentMonth+'/5/'+CurrentYear));
		}
		else {
			Deadline = DateValue(CurrentMonth+'/'+5+'/'+CurrentYear);
		}
	}
}
/*
Output deadline
*/

As you can see both are very alike. The only difference between the two was the first checked weather Fifth was a work day and if it was it would try to schedule that as the deadline regardless of the month. However, the second code checked weather
it was August first before doing FifthIsFriday.

The worst part of testing / writing a calendar related program specially one that deals non-deterministic time (this program
could output the deadlines for 2030) is very difficult to write because date intrinsicly propose so many test cases.
This bug was not caught for the past three years because the past three years none of the Augusts had fifth as friday. However this year, the 5th of August happened to be a friday and the program was computing incorrectly.

I then thought to myself how would I have caught this bug even before causing such a problem? And the only conclusion I could come to was EXTREMELY detailed requirements; but we already knew that!

MySQL version information

You can use this simple command to find the MySQL version you are running:

select Version() as Version;

Hope that helps.

Keep your system updated

Signup for download notifications e-mail and receive an e-mail every week listing the new updates that are available. You can pick which updates you want to subscribe to including: Windows, Office, Development tools among others. Simple and great!

More Gmail Account

Here are some more Gmail accounts. I have tons more to give out!

Enjoy!

ValueType Boxing

In .NET an interesting phehomenon occurs known as “boxing”. Let me illustrate the problem and then we will look at the possible solutions:

using System;
using System.Collections;

class Test {
	struct BankAccount { /* A simple BankAccount structure */
		public float Balance; /* Balance in the account */
		public BankAccount(float _Balance) { /* overloaded-contructor */
			Balance = _Balance;
		}
		/* A method to charge the account */
		public void ChargeAccount(float Fee) {
			Balance-=Fee;
		}
	}

	public static void Main() {
		ArrayList Accounts = new ArrayList(); /* An array */

		Accounts.Add(new BankAccount(100));
		Accounts.Add(new BankAccount(200));
		Accounts.Add(new BankAccount(300));

		/* Line: 21 */
		/* Go through each account and ChargeAccount 5.0 */
		foreach(BankAccount Account in Accounts) {
			Account.ChargeAccount((float)5.0);
			Console.WriteLine("Boxed: " + Account.Balance);
		}

		/* Go through each account and print the balance */
		foreach(BankAccount Account in Accounts) {
			Console.WriteLine("Un-boxed: " + Account.Balance);
		}
	}
}

The program outputs the following:

Boxed: 95
Boxed: 195
Boxed: 295
Un-boxed: 100
Un-boxed: 200
Un-boxed: 300

Although you would most likely expect (or at least want) to get the following output:

Boxed: 95
Boxed: 195
Boxed: 295
Un-boxed: 95
Un-boxed: 195
Un-boxed: 295

So what happened? If you look at line 21, we assumed that Account was a reference copy to Accounts which it isn’t. Account actually
is a value-type (copied) value for each Accounts. And that’s why when you do a Account.ChargeAccount the copied Account is charged and
therefore you see the change only in the first foreach loop. In the second foreach loop you once again start referring to the original
Accounts values which was 100,200,300 respectively.

To solve the problem you have to reference the actual object when doing ChargeAccount, something similar to this:

using System;
using System.Collections;

class Test {
	struct BankAccount {
		public float Balance;
		public BankAccount(float _Balance) {
			Balance = _Balance;
		}
		public void ChargeAccount(float Fee) {
			Balance-=Fee;
		}
	}

	public static void Main() {
		BankAccount[] Accounts = new BankAccount[3];
		Accounts[0] = new BankAccount(100);
		Accounts[1] = new BankAccount(200);
		Accounts[2] = new BankAccount(300);

		for(int i=0;i<accounts.Length;++i) {
			Accounts[i].ChargeAccount((float)5.0);
			Console.WriteLine("Boxed: " + Accounts[i].Balance);
		}

		for(int i=0;i<accounts.Length;++i) {
			Console.WriteLine("Un-Boxed: " + Accounts[i].Balance);
		}
	}
}

Notice however, this requires you to give a size of the array prior to using the array. This might be an inconvenience and there is a way to solve that problem also. We’ll look into that next time.

What’s special about 6500 Kelvin?

So you have taken a great shot and you, with all excitement and enthusiasm, send it out for print; suddenly disaster strikes. The color on the print doesn’t look anything like what it does on your monitor. There is a color cast (most like magenta or green) it’s most likely over staturated, basically it sucks! So what happened?

This is where 6500 Kelvin (or 6500K) comes in. The idea is simple. They are different levels of warmth. For instance, 5500K is warmer than 6500K. When I say warm I mean it’s more redish (red is warm think of fire). Another way to look at it is 6500K is cooler than 5500K (cooler because 6500K is more bluish).

The reason therefore the print looks aweful is probably because you have the wrong kelvin scale setup on your monitor (some monitors don’t have this feature and in that case it’s much harder to calibrate your monitor [2]). The sRGB standard is to use a white-point at 6500K with a gamma of 2.2 for Windows, or 1.8 for Macs.

The idea is to set your monitor at 6500K and verify the white point. What that means is after you set your monitor 6500K make sure the white area of a screen really is white. How can you do this? Well it’s simple set your desktop to white rgb(255,255,255) and see [1] if the desktop appears white. If it appears blue, something is wrong. If it appear redish, then something is wrong. It should appear white.

The second thing that needs to be done is to change the brightness control of your monitor until you can see 26 (A-Z) shades of gray in the following image:

You should see 26 shades of gray in this image

For instance, if you cannot see any difference between X, Y and Z then you have to increase the brightness of your monitor while making sure you can still the difference between A,B and C.

Although this will not give you PERFECT [2] results it will be much better. To get a better result you have to also set the gamma level which can be found using this applet. How you set the gamma depends on the software you use. If you are using Adobe Photoshop for instance you have to set the gamma using the Adobe Gamma tool.

Notes:
[1] We are depending on our eye here, which really isn’t a reliable source.
[2] If you want perfect results you have to use a hardware-based monitor calibration tool.

What makes a good photograph?

In my opinion three things that make a good photograph are:

  1. Exposure
  2. Sharpness
  3. Composition

Most photographers will argue that composition is the main element that make a good photograph. But I don’t think that’s true, imagine a picture if you will that in your opinion has perfect compisition but lacks good exposure, would that photograph work? No. Partly because you can’t really compose if you don’t have proper exposure. It’s like saying you want a highly responsive car without a good engine. That’s not possible, in order for a car to be responsive the engine has to be built well. However the flip-side is not true, a car may not responsive even with a GREAT engine. Which means that you can have a perfect exposure but lack of composition will understate it’s posibilities.

The second thing is sharpness. A sharp picture automatically attracts attention given that the right area of the image is sharp. A photograph often fails, because the wrong area of an image is very sharp. Sharpness also includes “how much of an image is sharp” (DOF) an image will fail if too many things are sharp (specially in portrait photography) or if too few things are sharp in either case the photograph will fail.

Also there seems to be a great deal of confusion with the relationship between sharpness and exposure. Essentially it boils down to this, you cannot have a sharp image without fairly good exposure. The reason is if the image is under-exposed which means not enough light went through the lens; and in order for an image to be sharp the lens has to receive a fair amount of light. With an over-exposed image sharpness is really not affected as much, because over-exposure means more than enough light went in. Unless the image is extremely overexposed you should be fine with some levels/curves adjustment in Photoshop (try multiply/darken layer blend-mode).

Finally when you have both sharpness and exposure you enter into composition. And with good composition you can take a good photograph and turn it into a great photograph. With some simplification composition means to take elements in the surrounding and using them somehow within a photograph. These elements include: camera angle, camera position (height/distance), trees, skies etc.

Uncertaintly Principal and Software Engineering

Uncertainty Principal is a principle of quantum mechanics postulated by Nobel laureate Werner Heisenberg in the 1920s which states that it is not possible to determine both the position and the momentum of a particle at the same instant. The reason he argued, was that the act of “observing” the particle changes its behavior with respect to what is being measured. He was one of the first scientists to bring in probability into the predictable science of physics.

Prior to Heisenberg’s theory most physicists (including Albert Einstein) believed that one day physics and computing would be powerful enough that given an input we would be able to predict the future exactly because we would know how each and every element in the universe would react and therefore be able to model time and space with infinite precision. But with the advent of Heisenberg’s principal and modern quantum physics (which is almost always a function of probability) physics is no where near predictable.

But what does all this have to do with software engineering? Professor Hadar Ziv and Debra Richardson from UCI published a paper arguing that software engineering is inherently uncertain. The reason they argued was the three sources of uncertainty within all softwares:

  1. Uncertainty in the problem domain: The first source of uncertainty is the problem domain. The authors argue that since most softwares models “real world” and real world is full of uncertainties. The software that models the real world therefore will inevitably contain those uncertainties.
  2. The second source of uncertainty was that in addition to problem domain uncertainties, softwares themselves introduce uncertainties. The authors use concurrent softwares as an example to argue their point.
  3. Their third argument is that softwares are tools that depend greatly on human participation; and human behavior is another area where great amount of uncertainties can be introduced (read my entry on Can UIs produce bugs)

Uncertainty Principle in Software Engineering is a great publication for anyone interested in the topic of testing, validation or software engineering in general. You can download a copy from here or visit their site where the download is also available.

Page 5 of 18« First...«34567»...Last »