When I first got my hands on CoffeeScript, I fell in love. It abstracted away a ton of boilerplate JavaScript code and handled a large number of common JavaScript "idioms." Naturally, I began to replace all of my JavaScript usage with CoffeeScript—and life was good.

Annoyingly trivial example

if (str && str.slice(-1) === '?') {  
    // Handle the question
}

becomes

if str?[-1..] is '?'  
    # Handle the question

The Falling Out

CoffeeScript made my JavaScript life simple for a time, and it was good. I wasn't undertaking any major JavaScript projects, so my CoffeeScript usage was replacing very basic JavaScript. Fast-forward a year or so: my employer saddles me with a rather large application that I ended up building using AngularJS and CoffeeScript. As the controllers and services began to grow, product requirements morphed and designs changes, I found myself longing for help with refactoring. I did a lot of jumping around between files to refresh my memory on inputs to functions, and refactoring resulted in some unsavory regular expressions.

This is when I came to appreciate TypeScript. I would have cut down on the number of tests, saved myself time debugging stupid errors, made refactoring much simpler and <insert 7,000 other reasons for choosing to leverage static type checking> had I started this project in TypeScript.

The Takeaway

I'm sure this sounds like a love song to static typing (of which I am generally a huge fan), but I do find that static typing will save you a lot of headaches at the cost of writing some slightly more verbose code. I miss a number of the nice shortcuts CoffeeScript provides now that I have picked up TypeScript, but saving myself a few keystrokes now is not worth having to go through the hoops when a projects gets enormous. That's not to say I have ditched CoffeeScript though; it still has a place in my tool belt. I still default to CoffeeScript on small, quick scripts where the gains from static typing would be questionable at best.

Now don't get me started on Ruby...

Let's assume you have the following entity:

<?php

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(
 *     uniqueConstraints={
 *         @ORM\UniqueConstraint(columns={"email"})
 *     }
 * )
 */
class User  
{
    /**
     * @var int
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    public $id;

    /**
     * @var string
     * @ORM\Column(type="string", nullable=false)
     */
    public $name;

    /**
     * @var string
     * @ORM\Column(type="string", nullable=false)
     */
    public $email;
}

and we try to create a new user:

$user = new User;
$user->name = 'Nick';
$user->email = 'dronepilot@example.com';

$em->persist($user);

try {  
    $em->flush();
} catch (Doctrine\DBAL\Exception\UniqueConstraintViolationException $e) {
    echo 'That email address has already been taken.';
    exit;
}

Now whenever a user tries to create an account with the same email address, they will trip our try/catch block instead. There's a problem with this approach though: what happens when you have multiple unique constraints and you want to know which one failed? Unfortunately this doesn't have a "simple" answer. Maybe the exception has some clue. Let's take a look at the exception's message:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'dronepilot@example.com' for key 'UNIQ_2DA17977E7927C74'  

Hmm... that doesn't really help. How can we improve this? Maybe if we give the constraint column a name, we'll have something to look for later. Assuming we have made the following changes to our entity:

<?php

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(
 *     uniqueConstraints={
 *         @ORM\UniqueConstraint(name="unique_email", columns={"email"}),
 *         @ORM\UniqueConstraint(name="unique_username", columns={"username"})
 *     }
 * )
 */
class User  
{
    /**
     * @var int
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    public $id;

    /**
     * @var string
     * @ORM\Column(type="string")
     */
    public $name;

    /**
     * @var string
     * @ORM\Column(type="string")
     */
    public $email;

    /**
     * @var string
     * @ORM\Column(type="string")
     */
    public $username;
}

we should now get en exception message that looks like:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'dronepilot@example.com' for key 'unique_email'  

Writing a regular expression to parse out the relevent column should be pretty trivial at this point:

preg_match('#\'unique_([^\']+)\'$#i', $e->getMessage(), $matches);  

The solution isn't ideal, but it works. Note that you cannot use the unique property on the @Column annotation with this as it does not allow you to specify a column name.

$baseFont:    Helvetica, Arial, sans-serif;
$readingFont: 'Helvetica Neue', $baseFont;

Probably not news to many people, but it helped me.

Most notably, there was a distinct lack of Markdown syntax support. You’d figure with Markdown being all the rave these days, someone would have made an extension for this. The only thing I could find was this extension. To my surprise, the extension didn’t work.

To get things running around here, I quickly threw together a Markdown extension for Mediawiki: Markdown.

It’s a little rough around the edges, and there are a few usability issues. Feel free to use it though.

Bonus I also made a HideSubpageParents plugin. Enjoy!