Yesterday I had to write some app that reads files located on some remote computer.
As I knew already this ins’t such a good practice, because your code can just hang/freeze for seconds waiting for that UNC path to become available or just checking it’s existence.

Still, I had to provide some quick solution and “hoping for the best” wasn’t good enough.
So, this is what I came up with.

        public static T Limex<T>(Func<T> F, int Timeout, out bool Completed)
        {
            T result = default(T);
            Thread thread = new Thread(() => result = F());
            thread.Start();
            Completed = thread.Join(Timeout);
            if (!Completed) thread.Abort();
            return result;
        }

        // Overloaded method, for cases when we don't
        // need to know if the method was terminated
        public static T Limex<T>(Func<T> F, int Timeout)
        {
            bool Completed;
            return Limex(F, Timeout, out Completed);
        }

The usage is very simple, just pass any method (declared or anonymous) and the desired Timeout in milliseconds to the Limex.

Example :

bool Completed;
string Content = Limex(() => File.ReadAllText(@"\\unc\dir\file.ext")
                       ,100 // milliseconds
                       ,out Completed);

if (Completed)
   // Do something
else
  // Do something else

Comments and suggestions for improvement are welcome and will be gratefully appreciated

    <script type="text/javascript">
        function doSomething(obj) {
            obj.style.color = '#cc0000';
        }
    </script>
    <a href="javascript:doSomething(this)">Link</a>

this keyword in his case was not A object as expected but window.
Having javascript:  in href attribute is like running JavaScript from address bar of your browser. It will run in window context.
Only if my friend was writing his code like this:

   ...
    <a onclick="doSomething(this)">Link</a>

it would work like charm.

But I never use javascript: at all in my markup. Why?
1. If you need text element that is clickable use span, any visual styling like text-decoration or cursor can be achieved using CSS.
2. If you don’t have actual link behind you shouldn’t use A tag. As far as I know it’s not good for SEO.
3. Javascript problems as i described above can arise
I would write the code above like this:

    ...
    <span style="text-decoration:underline;cursor:pointer;"
                 onclick="doSomething(this)">Link</span>

The only reason I know to use A for JavaScript triggers is to achieve hover effect without use of JavaScript.
If you know another reason why you should/shouldn’t use links as JavaScript triggers you’re welcome to comment.
After this post you can get an impression that I don’t like javascript: notation and you will be wrong,  actually there are very usefull tricks I use all the time:
1. Check some JS value on your page. Type javascript:alert(yourvariable) in the address bar and press enter.

You will get :

2. Or let’s say you have function somewhere on the page and you have to see it quick without searching through all your scripts. Or you wan’t to steal see how someone implemented something
Just type  javascript:alert(yourdesiredfunction) and voila:

UPD:
Just googled good page with JS best practices, it has Javascript: pseudoprotocol part that says almost exactly the same as my conclusions.
http://www.javascripttoolbox.com/bestpractices/

What you need then, is a rectangle packer, an algorithm that arranges as many smaller rectangles on a larger rectangle as can possibly fit.

The Nuclex.Support assembly contains several rectangle packing algorithms in the Nuclex.Support.Packing namespace offering various levels of compromises between space efficiency and runtime performance. All of these algorithms have been implemented as classes with a common interface, so, once implemented, you can easily switch forth and back between different algorithms to find the one best suites for your purpose.

Currently, there are three different packing algorithms for you to choose:

	The Simple Packer This packer is optimized for runtime performance. It does sacrifice a bit of space, but the time needed to find a position for a new rectangle is O(1). In english, that means it doesn’t take longer to search for a suitable position, no matter how many rectangles have been added to the packing area.
	The Cygon Packer Named after your humble webmaster, this algorithm is highly efficient in its space usage and offers reasonable performance. It will never exceed O(n) time but generally achieves almost O(1) on average. English translation: Search time is usually constant and guaranteed to never exceed a linear increase (so when you’ve got 99 rectangles already packed and add the 100th one, it guarantees that search time will at most be 1% longer than the time taken for the previous rectangle).
	The Arevalo Packer Named after Javier Arevalo, who posted his implementation of this packer on flipcode back in the golden times. This algorithm offers very good space efficiency and runs in slightly less then O(n) time. Just to be consistent, in english, that means, the time needed to find a suitable place for a new rectangle will only increase linearly.

You can download the C# version of the algorithms from here.

The usage is very simple :

	Point PP;
	var ARP = new ArevaloRectanglePacker(200, 200);

	if(!ARP.TryPack(Width, Height, out PP)) {
		// Do something
	}
	else {
		// Do something else
	}

The SpeedTrace Pro profiler follows and records the program flow of any .NET application on a function/method level for later profiling or tracing analysis, allowing you to identify performance bottlenecks, deadlocks, software design problems as well as resource and data flow problems.

One of the nicest features in this application is the presence of “Callback-API”.
It provides user-extended functionality to allow developers to adapt the tracer to their needs and to write user-specific extensions for dot.NET Framework 2.0, 3.0 or 3.5 applications.

SpeedTrace Pro can make accessible the arguments and return values of a function. This outstanding feature enables you not only to trace function calls but also to obtain the values passed or returned – important data that normal profilers lose during aggregations. You can make use of this data to obtain the relevant information, especially when bugs appear under certain conditions.

The data tracing values of .NET applications may be used to trap bugs easily and to perform data-dependent analyses.

SpeedTrace - .NET Profiler and Tracer

Forget for a second about .NET.
If someone asks you how much is 1.000025 – 0.000025 your answer will probably be “1″ and correct. An easy question, right ?

Now, let’s go back to .NET and check if our calculations are correct.

        static void Main(string[] args)
        {
            double d1 = 1.000025;
            double d2 = 0.000025;
            Console.WriteLine((d1 - d2) == 1);
        }

If you think the result will be “true”… well, it’s not.

Let’s see another example :

        static void Main(string[] args)
        {
            double d1 = 1.000025;
            double d2 = 0.000025;

            // Will result 1
            Console.WriteLine(d1 - d2);

            // Will result 0.99999999999999989
            Console.WriteLine((d1 - d2).ToString ("R"));
        }

For those who might not know, the meaning of ToString(“R”) is Round-trip.

This format is supported only for the Single and Double types. The round-trip specifier guarantees that a numeric value converted to a string will be parsed back into the same numeric value. When a numeric value is formatted using this specifier, it is first tested using the general format, with 15 spaces of precision for a Double and 7 spaces of precision for a Single. If the value is successfully parsed back to the same numeric value, it is formatted using the general format specifier. However, if the value is not successfully parsed back to the same numeric value, then the value is formatted using 17 digits of precision for a Double and 9 digits of precision for a Single.

So, what happened here ? Is it a bug ?
The answer is – NO, IT’S NOT A BUG ( and it’s not happening only on my computer ).

The thing is, that the above is about how .NET rounding a floating point number.
I won’t explain here the math ( there is already a great article explaining it ), and i won’t say don’t use floating point types.

You just need to know that when you are using it – be carefull, especialy in equations and formatting, otherwise your calculations will be wrong and your result not accurate.

If we will look at the .NET String.cs we will see the next line:

        public static readonly String Empty = "";

The above line can tell us that string.Empty is not a constant as we would like to believe but a readonly field.

The question is why, why static readonly and not a constant. The answer is in the same String.cs comments of the Empty field.

        // The Empty constant holds the empty string value.
        //We need to call the String constructor so that the compiler doesn't mark this as a literal.
        //Marking this as a literal would mean that it doesn't show up as a field which we can access
        //from native.

Now, let’s make some test.

            string EmptyValue = string.Empty;

            if (EmptyValue == "")
                // Output : Is Empty : 1
                Console.WriteLine("Is Empty : 1");

            if (EmptyValue.Length == 0)
                // Output : Is Empty : 2
                Console.WriteLine("Is Empty : 2");

            switch (EmptyValue)
            {
                case "":
                    {
                        // Output : Is Empty : 3
                        Console.WriteLine("Is Empty : 3");
                        break;
                    }
                 case string.Empty:
                    {
                        // Compilation error : A constant value is expected
                        Console.WriteLine("A constant value is expected");
                        break;
                    }
            }

            if (EmptyValue.Equals (""))
                // Output : Is Empty : 4
                Console.WriteLine("Is Empty : 4");

            if (string.IsNullOrEmpty(EmptyValue))
                // Output : Is Empty : 5
                Console.WriteLine("Is Empty : 5");

As we can see string.Empty and “” have the same behavior except the “switch” because string.Empty is not a constant.

And of course the most important question – is there a performance differences between the two ? The answer is – Yes, but minor.
Lets see some results :

           // Execution Time : 2144ms
            for (int n = 0; n < 100000000; n++)
            {
                if (TestValue == string.Empty)
                    t = 1; //"For test purposes only..."
            }

            // Execution Time : 2211ms
            for (int i = 0; i < 100000000; i++)
            {
                if (TestValue == "")
                    t = 2; //"For test purposes only..."
            }

We can see from the results that the comparison with string.Empty is a little bit faster but it's negligible.

One of the advantages of using "" is that it's in some cases it can be optimized by the compiler before the JIT. For example if you will run the same iteration while comparing ""==null the whole block will be removed by the optimizer.

So, use what ever you like, you'd probably won't see the difference.

Coming soon…