Monthly Archives: August 2009

Quinta Jardim da Serra weekend

I’ve just returned from a really nice weekend on this lovely hotel. Bar services could be a little better and it’s not the easiest place to find, but the hotel is just great! Highly recommended if you’re looking for a nice place to say and relax for a couple of days. Here are some pics I’ve taken during my stay there. And now, it’s time to go back to vacations mode.

Facebook Connect JavaScript API

I recently submitted a Facebook development article to ASP.NET Pro magazine.  It was quite the challenge initially to get it started.  But once I got going (I think I’ll blog on this later), I was off and running but there aren’t a lot of examples on the WIKI.  I put a combination of items together in order to figure it all out.

First, the core content I used to extract user’s information was the Facebook JavaScript API, available here:  The core object in Facebook to extract data from its servers is the ApiClient object (  Unfortunately, for most method calls, there isn’t any documentation.  A few things to note:

  • If you google on these methods (like groups_get, friends_get, or photos_getAlbums), you’re likely to come up with something.  Usually, it’s PHP examples, but it’s something you can go off of.
  • You can post in the forums, but in the questions I had, there really wasn’t any movement.
  • If you see the method return FB.PendingResult, this is because it returns data asynch from the server.  In most cases that I saw, it fires a callback with the signature function(results, ex) { }.  This callback can be specified in the parameter list where the SequencerBase parameter is defined.
  • Speaking of SequencerBase, the WIKI has an example of how you can use a SequencerBase class to download all of the user data on one shot simultaneously.

Some other notes/general issues I found are:

I hope this helps, and more content will be coming.

SBS2008 not sending email out on a Dell PE2900

Issue with SBS2008 Sending email out on a Dell PE2900
Mail would receive just fine into the SBS2008 however sending email out would get stuck halfway and never get delivered.
No Return Bounce NO indication of any issues.

Found out that Broadcom NIC was the issue in the Dell PE2900
Even though it had Version 9 drivers Dell claimed that version 12 “Might”
I repeat “MIGHT” work.

Instead of dealing with it not working after new drivers, I disabled Onboard NICs
Purchased a DLINK 1GB Nic Card.

Installed and mail going out correctly now with no issues!
Information Courtesy of Lafayette Jefferson.

In operator vs hasOwnProperty property

In yesterday’s post about the in operator, Bertrand mentioned that it would be interesting to show the differences between the in operator and the hasOwnProperty method defined on the Object “type”. As always, he’s right and I guess that I should write up a small post explaining the difference between these two.

Both of them check if a property belongs to an object, but there’s an important difference between them (besides the fact that in is an operator and hasOwnProperty is a property which references a function): the in operator will check the property name against the properties of the object +  the properties defined on the prototype object; on the other hand, the hasOwnProperty property will only check that name agains the properties of the object.

Here’s a really simple example which tries to show the main differences between these two:

var User = function(name) { = name;
User.prototype.printInfo = function() {
var user = new User("luis");
alert("printInfo" in user); //true :checks prototype

From an usage point of the view, that’s really main difference between the operator and the method. Since hasOwnProperty is a property of object, there are a couple of things you should keep in mind:

  • every object has access to it (because all JavaScript objects end up “inheriting” the Object’s type prototype functions);
  • its use might be “compromised” by a redefinition of that property (which can be done by adding a property to the new object with that name or by changing the prototype’s hasOwnProperty property to a new value – which, btw, could even be a non function value!)

And that’s it for now. Keep tuned for more on JavaScript.

Using anonymous functions to avoid global namespace pollution

I guess that you’ve written code like this in the past:

var user = document.getElementById("name");
var msg = "Hello, " + user.value;

I can tell you that I’ve written several lines of code that resemble the previous snippet in the past. However, you should avoid it whenever possible. The main problem with it is that you’re polluting the global namespace and that is something you shouldn’t do.

In these cases, there’s really a simple strategy for avoiding this unneeded pollution: we can take advantage of anonymous functions! Here’s how I’d write the previous snippet:

(function() {
    var user = document.getElementById("name");
    var msg = "Hello, " + user.value;

The syntax might seem awkward at first, but if you concentrate, you’ll see that it’s really simple. We define an anonymous function and execute it in place. (notice that the statement must end with the braces so that it is interpreted as a function invocation).

And that’s it for today. Keep tuned for more tips on JavaScript.

Protected: “Static” methods

There is no excerpt because this is a protected post.

The semicolon bug

Since I’ve started blogging about JavaScript, I thought that it would be ok to share with you one of the most embarrassing bugs I’ve introduce in a code base. Now, when I look back, I do find it funny, but I can tell you that I didn’t laugh about it at the time. The code is really simple, but I guess it shows why I started putting braces on the opening line…

function doSomething(number) {
    //do some very interesting stuff here
    //return object
        x: number + 1
var a = doSomething(1);

Really innocent, right? Unfortunately, it returns undefined instead of the literal object I was trying to build. Btw, this will only happen when the returned object only has one property. If you had more than one, then you’d be getting a parsing error (in JavaScript, it’s common to use anonymous objects for passing data around and it’s not uncommon to fill only the “used” fields).

I guess that if I had read the spec I would have found that JavaScript will automatically insert the ; after certain statements. Here’s what the 1.3 spec says about this topic:

Certain ECMAScript statements (empty statement, variable statement,expression statement,do-while statement, continue statement, break statement, return statement, and throw statement) must be terminated with semicolons. Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations.

I guess that the moral of the story is that in JavaScript, the C K&R style should be used always.

P.S.: a final note to say that I’ll be receiving Douglas Crockford’s book in the next couple of days. That means I’ll be learning a few more tricks to share with you :)

Using the || initialization trick

Suppose you’ve got a function and you expect it to receive some optional parameters. In these cases, you’d like those optional parameters to be initialized with a predefined value. Can we do that in Javascript? Yes, we can and all we need is to use the || operator. The following snippet should make this point clear:

function changeTextColor(color, elem) {
    elem = elem || document.body; = color;

As you can see, we expect two parameters. The initial check tries to ensure that elem points to a valid HTML element. It’s that simple and there really isn’t much more to say about it. Keep in mind that you shouldn’t get too fancy with this kind of tricks. For instance, I recall that a a colleague of mine which was getting started with JavaScript tried to be  a little too smart and wrote the following code:

elem = ( elem && || document.body;

it seems good, right? The problem is that elem && will return! Was he right in performing the check? Yes, he was, but he did it in the wrong place. If you want to be that clever, then you’d better understand how && and || work. Btw, here’s a revised version of the previous method which checks for the style object before setting its color property:

function changeTextColor(color, elem) {
    elem = elem || document.body;
    if ( { = color;

Keep tuned for more on JavaScript.

« Formation utilisateur SharePoint : Produire, collaborer et gérer les sites »

wygwamVous connaissiez déjà Wygwam sous l’angle de l’expertise technologique ainsi que sur nos implications communautaires.

Aujourd’hui, Wygwam ouvre un tout nouveau pôle FORMATION.

En partenariat mondial avec la société Combined Knowledge ( Wygwam vous délivrera, en Français, les formations SharePoint de Combined Knowledge.

C’est donc l’expérience technologique de Wygwam, combinée avec l’expérience pédagogique de Combined Knowledge que nous teaser-formationvous délivrons dans ces formations exceptionnelles.

Première formation

Pour fêter l’événement, nous avons le plaisir de vous inviter à notre première formation officielle pour utilisateurs finaux « Formation utilisateur SharePoint : Produire, collaborer et gérer les sites »

Elle se déroulera du 21 au 24 septembre prochain à l’hôtel Mercure Lille Métropole à Marcq en Baroeul.

Pour plus d’informations, pour connaître le programme détaillé et découvrir nos conditions « Première », rendez-vous sur notre site.

Pensez Wygwam

Dès à présent, pour vos formations SharePoint, pensez Wygwam !



=== vs ==

There are still lots of guys that don’t know that JavaScript has the === operator. The truth is that you should always use this operator instead of relying on the == operator. Btw, and since we’re talking about comparison operators, there is also a !== operator that should be used when you need to test that two values are different. The main difference between these operators is that the == and != will use type coercion when the operands are of different type (if both operands have the same type, then they both work the same way).

Ok, so what’s wrong with type coercion? The problem is not type coercion per si, but the rules that are used. For instance, take a look at the following snippet:

var option1 = 0 == ''''; //true
var option2 = '''' == ''0''; //false

In my opinion, the results are not intuitive. In fact, there are so many rules that come into play here, that I’ve given up on using this operator (the only times you’ll see me using it is when I haven’t used JS for a while and the old C# habits come into play…but after 1h of JS, everything starts coming back and I go back to my old === and !== operators). If you don’t believe me, then take a look at the following paragraph which was taken from the spec:

If Type(x) is the same as Type(y),then
a. If Type(x) is Undefined,return true.
b. If Type(x) is Null, return true.
c. If Type(x) is Number, then
i. If x is NaN, return false.
ii. If y is NaN, return false.
iii. If x is the same number value as y, return true.
iv. If x is +0 and y is -0, return true.
v. If x is -0 and y is +0, return true.
vi. Return false.
d. If Type(x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions). Otherwise, return false.
e. If Type(x) is Boolean, return true if x and y are both true or both false. Otherwise, return false.
f. Return true if x and y refer to the same object. Otherwise, return false.

If I’m not mistaken, there are at least 10 rules, each with several options. Can anyone blame me for simply not caring about this operator?

Recent Comments