We're happy to announce the first partial list of talks selected for the Chicago Code Camp. We hope there's a good mix of various different technologies and that it could spark even more interest in the event.

There are still a good number of time slots undecided for this event. If you want to submit a talk, you can do that until Saturday the 25^th of April. The event will be on May 30^th.

The Code Camp will be a great event. If you haven't registered yet, what are you waiting for?

Many times when I'm writing JavaScript code with Ajax calls I don't have an URL to call and get the data yet. Or sometimes I have an URL that gives me valid data and I need to test the code against invalid data or some other variation that I don't have handy.

WEBrick

In these situations, instead of creating a temporary ASP.NET application, I learned to love using Ruby and the adorable simplicity of WEBrick. Imagine that I needed an URL that simulated latency on the server.

require 'webrick'
include WEBrick

server = HTTPServer.new( :Port => 2000 )

server.mount_proc("/getData"){|req, res|
  res.body = "{result: 'ok', accountId: 123}"
  res['Content-Type'] = "application/json"
  delay = req.query['delay'] || "0"
  sleep(delay.to_i)
}

trap("INT"){ server.shutdown }
server.start

After running the script I can open use the URL http://localhost:2000/getData?delay=5 in my Ajax call and, after a delay of five seconds, the JSON string {result: 'ok', accountId: 123} will be returned. The server will stay there, in a console window, running until I kill it with CTRL+C.

I could add more mount points on that server for as many test URLs as I wish. I find this incredibly practical.

I wish there was something as simple in .NET

Well, I couldn't find anything as easy in .NET. The few offerings I found were not as straight forward. Some of the alternatives are distributed in .msi files, which makes them less convenient, especially for integration testing or JavaScript unit testing (which is my end goal.)

Hello Juicy

Envy sometimes makes you move forward. I played around with sockets and the HTTP protocol and ended up with a library that looks promising. See that same code written using the Juicy.DirtCheapDaemons.Http.HttpServer class, a.k.a. the Juicy Web Server.

using System;
using System.IO;
using System.Threading;
using Juicy.DirtCheapDaemons.Http;

  class Program
  {
    static void Main(string[] args)
    {
      HttpServer server = new HttpServer{ PortNumber = 2000 };
      server.Start();

      server.Mount("/getData", 
        (req, resp) =>
          {
            resp.Output.Write("{result: 'ok', accountId: 123}");
            resp["Content-Type"] = "application/json";
            var delay = int.Parse(req.QueryString["delay"] ?? "0");
            Thread.Sleep(1000 * delay);
          }
      );

      Console.WriteLine("Press enter to stop server");
      Console.ReadLine();
      server.Shutdown();
    }
  }

There are a few things more that can be done with HttpServer.

//mounting virtual path with a lambda (shown in previous example)
server.Mount("/virtual/path", (req, resp) => DoSomethingWith(req, resp));

//mounting virtual path to serve static files
server.Mount("/virtual/path", @"c:\some\directory");

//hiding a virtual path
server.Mount("/virtual/path/subdir", new ResourceNotFoundHandler());

As it is, HttpServer supports only GET requests. The plan is to add more support (for features that make sense in a unit testing scenario) with time.

I obviously don't envision Juicy becoming a full-fledged web server that I can recommend using in a live web site. But I can see it being helpful in the scenarios I've just described and for testing in general.

I'm sold. Where can I get it?

This project is hosted at GitHub: http://github.com/sergiopereira/juicy/tree/master, where you can download the source directly or even clone the repository :

c:\projects>git clone git://github.com/sergiopereira/juicy.git

This is a tip for those working with JavaScript (and possibly other types of files) that is freely available for download. For the n^th time in the last few months I spent an unnecessary amount of time trying to find a problem in my code that wasn't really there.

Windows keeps track of the files you save to your hard disk which came from the Internet. Maybe you have seen this problem when you try to open a CHM file that you downloaded and see that it opens to a blank page. The same type of thing happens with JavaScript files that you download. Let's see what happened to me today.

First I downloaded the latest version of QUnit and saved to my application's directory. I did this the usual way, as shown in the image below.

Then I proceeded to use the downloaded testrunner.js file in my HTML page, via a <script src="testrunner.js"></script> tag. When I tried to open my HTML page, I was not expecting to see the particular error shown below.

I started to look for common problems: Did I save the file in the right place? Did I spell its name right? Did I mispell the function name? Did I miss a dependency? No, no, no, and no. All looked good.

That's when I remembered that the file might have been flagged by Windows. I opened its properties dialog and, sure enough, there it was, the infuriating Unblock button.

Ah, that's easy. I just clicked it and refreshed my page. Wah-wah! Problem persists. I tried typing the .js url in the address bar and saw this 401 error message from IIS, not 404.

That told me that there was still something messed up with file access. I checked the file's permissions, comparing to an older .js file in the application. The new one did not grant access to local users, so I added Read access to local users.

Now it works. Depending on how your IIS and/or ASP.NET security is configured, you may not need this last step (e.g. if the process identity already has admin rights, in which case I salute you, brave friend.) The system at hand was a Win2008-x64 installation with the default IIS/ASP.NET settings.

This problem seems to happen to me every other week and I still did not develop the reflex to take care of it right when I download the file. On the other hand, I'm getting better at remembering about it when I see stuff like "function not defined" in an error message.

I'm pretty sure by now you have heard at least once that eval is evil. Some nuggets from Eric Lippert's post:

if you are considering using eval then there is probably a better way

People, eval starts a compiler.

I'm also pretty sure I don't need to tell you that anytime you have an explicit eval() in your code, there's a good chance it's there because you're not taking JavaScript seriously yet.

//mandatory square brackets notation example
//------------------------------------------
var myObject = new MyObject();
var prop1 = eval( 'myObject.' + somePropertyName ); // BAD!
var prop2 = myObject[ somePropertyName ]; // Better

That's not the end of all eval()

At this point some people might be feeling relieved: "Phew! That was easier than it sounded. Getting rid of eval is a piece of cake." Well, I'm not going to say it's significantly harder than that, but we're not done prunning eval() from our code just yet.

You see, eval() is like that coward opponent that sneaks in the dark to attack you from behind. Let's find some of eval's favorite hiding places.

There's a time when you need a timer

Two very popular JavaScript functions used to create timers are setTimeout() and setInterval(). Here's how you still find code being written to use them.

function doSomething(someValue){
	//...
}

setTimeout("doSomething('3 seconds elapsed. Time is up.');", 3000);

As it turns out, this is just another occurrence of eval() revealing how incompetent we can still be in this programming language. Here's a better way to write that code.

setTimeout( function(){ 
                doSomething('3 seconds elapsed. Time is up.');
            }, 
            3000);

Thank God I didn't know functions had constructors

The other secret place that eval() likes to hang out is in the Function constructor. Fortunately this isn't exactly a popular way of creating functions. I'll say it: I didn't even know about this constructor until less than a couple of years ago.

So, in case you don't know what I'm talking about here, I'll show you how to use the function constructor just to imemdiately tell you to not do it.

var sum = new Function('op1', 'op2', 'return op1 + op2;');
var result = sum(10, 20); // ==> 30

The above code is roughly equivalent to the explicit eval() usage below.

eval("var sum = function (op1, op2) { return op1 + op2; }");
var result = sum(10, 20); // ==> 30

We don't come up with the need to use the function constructor often, but I'll admit that when we do, it's usually hard to replace it with another way that doesn't use eval().

Next Tuesday, March 24^th I'll give a JavaScript talk at the Rockford .NET user group.

This talk will be basically the same one I gave for the LCNUG back in December.

The few opportunities I had to give this talk were highly rewarding. It's priceless to see developers realizing how mistakenly they had been using JavaScript, and finally being able to understand why "that bug" was happening in their pages.

So, if you live in the area and think there must be something about JavaScript that you're just not getting, please try to stop by and ask your questions.

JavaScript - Beyond the Curly Braces

One of the greatest problems with JavaScript is its superficial syntax resemblance of C-style languages. We call it the curse of the curly braces.

That is also a very large source of frustration for developers trying to learn JavaScript beyond the basics. Thinking that JavaScript is somehow related to Java or even "It's almost like C# but a little simpler" is an unfortunate and common occurrence that can only lead to trouble.

In this session we will analyze some of the fundamental differences between JavaScript and C#/Java. We will highlight the pitfalls that can trap us and the appropriate workarounds for them.

Time permitting and if there's interest we will take a look at Idiomatic JavaScript, which will help us understand how JavaScript is being written these days. Learning about this will also help you when trying to read the source code or even the documentation and samples for popular JavaScript libraries like jQuery, Prototype, YUI, etc.