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

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!

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.

So I’m writing my first serious bit of PHP in aaaages. This last few months, I’ve either been adapting existing systems to fit the bill, or I’ve been writing ASP (all while learnng Ruby on Rails).

I feel like I’ve been out of the game. Before I fell out of writing my own PHP every day, I was using the CakePHP framework. CakePHP is a wonderful framework. It greatly speeds up development and makes things so much easier.

Unfortunately, frameworks are only of use to the developer or your customer has someone who knows what they’re doing to set up everything for them. When you’re building a product for those who aren’t so technically minded, giving them something like CakePHP/Rails/Django, etc, to install – before they can use the product – is a big no-no1.

So anyway, I’m writing this new product. It’s not terribly exciting, nor should it be particularly difficult… but what looked a piece of cake on paper is going slower than I would like. I need to get my head around the fact I don’t have a framework or existing application doing 90% of the grunt-work for me. All those framework-specific shortcuts and existing functions I’ve grown used to don’t work any more so I need to do things manually2. Joyful.

On the plus side, this is probably the coding equivalent of getting back into shape for a World Championship fight, after getting slower and fatter from being too comfortable – a la Rocky in Rocky III.

Frameworks are a wonderful thing for speeding up development in large projects where you have control over your environment. Just remember not to rely on them too much.

  1. This isn’t to knock the work of the developers of frameworks like CakePHP and Rails, et al – not at all. I think they’re doing great, great work, which makes the lives of countless developers worldwide just that little bit easier.
  2. Another thing keeping me from top-speed is an insistence I’ve put on myself to follow best coding-practices all the way, and most importantly, document everything as I go. I usually write something then document it later once everything else is finished.

Today I fired up TextMate to do my first bit of serious PHP coding since my stroke. I’ve been almost entirely XHTML/CSS since getting out of hospital last August, with a little light coding (ASP mostly) since then.

Probably the closest I’ve got to writing any real PHP in 8 months has been learning the basics of WordPress themes from Blog Design Solutions… To be honest, I’ve not had the same drive or determination to “Just Code It” as I once did.

I’ve been reading 37 Signals’ excellent book, Getting Real today. I’m about three quarters of the way through. I doubt I’ve ever said this about a “tech” book before, but it’s a real “page-turner”; Getting Real pulls you in and is real hard to put down once you get started. All the praise you may have heard about this book is justly deserved—it’s essential reading for developers… hell, it should probably be essential reading for anyone who has to work on just about any type of product or in a team.

While I’ve been reading Getting Real, I’ve been feeling like I want to write code again; I want to write something simple, elegant and real. I want to stop thinking about some of the ideas I’ve had over the last few month – no years – and actually do something. So I set-up a development site and database for one such idea, opened TextMate and created a new project.

It hit me like a slap in the face; I’ve forgotten how to do this. It’s like I’m back on square one… like someone sucked most of my programming ability out of my head. I can remember lots of stuff about various PHP functions, syntax and a million myriad details, but actually doing anything with any of it is another matter. I started thinking about the initial, basic class/data structure I would need and it was like the lights were on but nobody was home.

Looking on the bright-side: if I do have to relearn myslef this stuff, it means I’ll be able to do it with a clean slate and Be Real from the very outset…

I’ve had my iBook for about 48 hours now, and I’m beginning to find my way. OS X (or is it OSX?) is a completely new experience to me, but I think I’m taking to it rather well. I’m still getting used to the difference between shutting an application and quitting an application, but that’ll come in time! For what it’s worth, I wanted to jot down my initial experiences and reactions with the switch. I won’t go into too much detail just yet – I’ll save that for later articles.

  • File browsing is more intuitive, especially after I switched to column view in Finder.
  • A lot more emphasis is placed on using keyboard commands than in Windows…
  • …Which is just as well, as the trackpad is a bit pants.
  • Software installation is a breeze. It’s so simple and logical. Drop the application into the applications folder and away you go!
  • I’m still not sold on the Dock, but I haven’t done any tweaking yet (other than the size of it)
  • Everything just looks better. From the icons to the text to the GUI widgets… it’s just better!

So far, I haven’t done anything to set up the machine for local development/testing. I plan to do this later this week, after I’ve done a bit more reading – I want to set up SVN and Ruby/Rails, both of which I’ve never set up before (or even used before, in the case of Ruby/Rails!). Another thing that I haven’t done yet, is transferred any old files onto the iBook. That’s tonight’s job.