Code

If you have been reading my blog lately, you know that I’m implementing some data structures and algorithms in JavaScript. So far, I have blogged about simple sorting algorithms, the stack data structure and the queue data structure. This week I have also implemented a doubly linked list. I started writing a post about that last implementation, but I didn’t like where it was going, so instead of writing about it, I have pushed everything to a public Git repository. ...

Davy Brion made a comment on my JavaScript stack/queue implementation on Twitter last night: Any reason why you don’t immediately set elements to [] at declaration in your stack/queue example? var elements; this.push = function(element) { if (typeof(elements) === 'undefined') { elements = []; } elements.push(element); } Yes, I made an overoptimization, and a bad one. In this implementation, you save a few bytes in memory if you initialize the stack, but don’t push elements. This might have made some sense 15 years ago, but today a few bytes are very negligible compared to the cost of evaluating the elements reference on every push call. ...

The second assignment in my ‘implementing data structures and algorithms in JavaScript’ quest consists of two popular data structures: the stack and the queue. The stack A stack is a last in, first out (LIFO) abstract data type and data structure. A stack can have any abstract data type as an element, but is characterized by only three fundamental operations: push, pop and stack top. Implementing this turned out to be pretty easy. A native JavaScript array already exposes methods to push and pop elements. In the dataStructures namespace, I defined a stack object. The stack object contains a private array which is initialized as soon as the first element is pushed into the stack. The public push and pop functions expose the corresponding functions of the private array. The stackTop function returns the last element added to the stack, but doesn’t remove it from the internal array. ...

About three years ago I graduated and got my degree in Applied Computer Science. Although it says Computer Science, we hardly ever focused on data structures and algorithms. Obviously, I now see that as a shortcoming. So I plan to make up for that by reading up on some of the basics. While at it, I might be blogging on some of the topics. I am going to start by implementing some of the simple sorting algorithms in JavaScript. ...

Because I blogged about anonymous types last month, I thought following method would also make an interesting post. private static bool IsAnonymousType(Type type) { Debug.Assert(type != null, "Type should not be null"); // HACK: The only way to detect anonymous types right now. return Attribute.IsDefined(type, typeof(CompilerGeneratedAttribute), false) && type.IsGenericType && type.Name.Contains("AnonymousType") && (type.Name.StartsWith("<>", StringComparison.OrdinalIgnoreCase) || type.Name.StartsWith("VB$", StringComparison.OrdinalIgnoreCase)) && (type.Attributes & TypeAttributes.NotPublic) == TypeAttributes.NotPublic; } For a type to be anonymous: ...

A Real Developer is a side-project I built over the weekend poking around with WebMatrix. It got a little out of hand. After publishing, I showed it to a few popular tweeps, and they were kind enough to mention it. 24 hours after the launch it has gotten over 3.5k unique visitors, 39k page views (see what I did there?) and over 240 submissions. Being mentioned by Scott Hanselman and Rey Bango helps. ...

After publishing yesterday’s post on anonymous type equality, I received an interesting comment. The comment stated that even if the sequence of the property assignment were the same, the equality comparison would still return false, because the types generated by the C# compiler are reference types, making their references being tested for equality and not their data. This is very true, unless the Equals() method is overridden. And this is exactly what the compiler does for us when we define anonymous types. In the Equals() method the equality of each property is evaluated by using a generic EqualityComparer. ...

Let’s say you instantiate two variables (a and b) using anonymous types. They both have the same two properties (x and y) with equal values. var a = new { x = 1, y = 2 }; var b = new { y = 2, x = 1 }; Do you think they are equal? Console.WriteLine(a.Equals(b)); //Prints false :O They are not. Not something I expected! If we look at the IL the C# compiler produced, it starts making sense though. ...

Hold it, don’t shoot me. I know this would be an awful practice, but it is an interesting C# compiler quirk nonetheless. Keywords are predefined reserved identifiers that have special meanings to the compiler. They cannot be used as identifiers in your program unless they include @ as a prefix. For example, @if is a legal identifier but if is not because it is a keyword. static void Main(string[] args) { var @if = "oh my.."; Console.WriteLine(@if); } ========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

The problem with using stateful connections on an imperfect place as the internet is that connections might drop. The server or an intermediary can drop the connection due to an idle timeout. Even a temporary problem at the server or a local network hiccup might kill your connection. If you aren’t prepared to handle these scenarios, you will not be able to fully rely on WebSockets. A simple solution The simplest solution is checking every few seconds whether the WebSocket is still opened. This might suffice in a good amount of scenarios, but a lot of other scenarios require more stable connectivity. ...