article

|

I received an email from a developer the other day, who had forked the repository for my “IIS Express Here” shell extension on GitHub [editors note – no longer available]. He had noticed there was no license information available in the project, so asked if I could either add a license, or give him written permission to adapt my code and share it to others (as is the spirit of GitHub and OSS).

To be honest, this wasn’t something I’d thought about before, and was a bit of an oversight on my part. I’d not really considered the need to add explicit licenses to my repositories. After all, the code is out there anyway – it’s open to use on GitHub, and I’ve often shared it on this blog… if someone wanted to copy the code, they could, right?

Unfortunately, this creates a grey-area, which some are naturally uncomfortable with. Can I use this code in something else? Can I modify it at all? Do I have to pay royalties if I do?

But licensing is hard, isn’t it? All the different types, with different caveats, liabilities, and legal mumbo-jumbo… well, yes, it can be hard. The good folks at GitHub have a solution: ChooseALicense.com is attempting to demystify open source licenses so you can pick the right one for your project. More than this, when you create a new repository on GitHub, the site will ask if you want to add a template license during the initialisation process:

repo_licenses

Coming back to the developer who emailed me – I mailed him back to let him know that IIS Express Here is now licensed under the MIT license. This fits best with how I see the code and projects I share on this blog (unless noted otherwise) – free for anyone else to use, but with no warranty, so if something goes wrong then I’m not liable and it’s not my responsibility to fix it. I haven’t got around to updating all of my repos with licenses, as I’m evaluating each one in turn, based on my goals and even whether the project is going to archived.

ChooseALicense.com

note

|

The beauty of web development is that, ultimately, the code behind it is simple. Yes, web apps have taken leaps and bounds over the last few years, and are capable of so much more than ever before, but lets face it – we’re not exactly writing DNA sequencers. Yet.

It frustrates me when I find someone has made life difficult for themselves or the person who will inherit their code, by using the wrong tool for the job. I’m not claiming to be a saint here either – I often look back at some of my own code and shudder (it helps keep me right in the future!).

Consider the following snippet, from the View (presentation) file of an MVC app I inherited:

<?php
echo "<h1>$category</h1>";
echo "<h3>$company ($name)</h3>";
echo "<p>";
echo "$address<br />";
echo "$town<br />";
echo "$city<br />";
echo "$post_code<br />";
echo "$phone<br />";
echo "$email<br />";
echo "</p>";
echo "<br />";
echo "<br />";
?>

PHP needs to be used to output the data passed from the Controller, yes, but there’s no need for it to be outputting the HTML too. Let HTML itself worry about that!

<h1><?= $category ?></h1>
<div>
<h3><?= $company ?> (<span><?= $name ?></span>)</h3>
<address>
<span><?= $address ?></span>
<span><?= $town ?></span>
<span><?= $city ?></span>
<span><?= $post_code ?></span>
<span><?= $phone ?> </span>
<span><?= $email ?></span>
</address>
</div>

I don’t know about you, but the HTML-based version above is easier to follow and spot coding errors. No doubt someone will point out there’s more HTML tags/bytes in this example than the first, but that is because I coded it with semantics and microformats in mind; add in the right classes and you suddenly have a hCard.

Possibly more importantly in my mind, the HTML example is easier to follow for someone who isn’t PHP literate, like many front-end designers I know.

I’m picking on this example as it’s the most recent I’ve come across, and the first to come hand. It’s not the first example I’ve come across, it won’t be the last, and it’s certainly not the worst!

Pure, simple HTML can be a wondrous thing. Lets try not to spoil it by abusing it with our fancy server-side languages. K.I.S.S!

note

|

I loves me some jQuery – without it I probably wouldn’t write any JavaScript at all (seriously, I hate the stuff). Anyway, today I needed to add some “open in new window” links to an internal application using jQuery. Being the Standardista I am, I wanted to make it a)Accessible, and b) Unobtrusive . If the user has JavaScript disabled (it happens, even on “controlled”, intranet environments), the link should just go to the new page anyway — new window be damned.

My first attempt (below) didn’t work as expected. The following code takes all <a> tags with a class of “newwindow” and applies an onclick event to open a new window.

$(function(){
$('a.newwindow').click(function(){
var w = window.open($(this).href(), 'newWindow', '');
return false;
});
});

Nothing would happen with the above, because of the return false;. Removing return false; would open a new window, but also send the opening window to the new page. In the end, the following worked the way I wanted:

$(function(){
$('a.newwindow').click(function(){
var w = newWindow($(this).href(), 'newWindow', '');
return false;
});
});
function newWindow(url, wName, opts){
w = window.open(url, wName, opts);
return true;
}

Basically the “heavy lifting” was moved to a seperate function. It’s slightly longer to type, but not exactly finger-breaking stuff. No doubt some bright-spark could tell me an even betterway (feel free!), but this’ll do for now.