article

|

I’ve taken the decision to switch my site away from the custom theme called “K” I was building, and for now I’m using the excellent Autonomie by Matthias Pfefferle instead1. Development of K had already slowed to a standstill, and realistically, I’m not going to go back to it anytime soon. It feels a little like a failure, a little like giving up, but I think it’s ultimately the right thing to do.

I made a lot of mistakes while building K, which overcomplicated things, made development more difficult, and ultimately led me into a dead-end. I thought “for simplicity” that I would use the Bootstrap frontend framework, as it would give me a robust foundation to build on. It did, but I had to bend and twist WordPress in increasingly hacky ways to get the output to “play nice.” A large chunk of the K codebase was being taken up by code solely tasked with massaging the output of WordPress to add the right Bootstrap classes or container markup. It felt increasingly fragile and hacky, and it was a bad sign. K would work for my setup, but I couldn’t ensure it would work for everyone.

Bootstrap added other complications: to properly manage my CSS “overrides” I had to create a build system that would compile a whole lot of SASS files together. When I started K, the CSS was stripped down to the bare minimum needed, and came to a few KB. After a while I ended up including the whole Bootstrap framework, just to make the build process easier.

There were no “options” to speak of, so it couldn’t be tailored to suit someone else using the WordPress customiser. I didn’t even want to think about Gutenberg support.

Microformats always felt like whack-a-mole. I’d get them working, then make adjustments somewhere else, and promptly see things break again. I put this on my need to make so many adjustments to the WordPress output – inadvertant issues kept creeping in.

Then there were the visual design choices. K grew out of the simple design I employed when I was writing 1-2 short posts a month, in the traditional format. In that scenario it worked fine. Once I started to use the various post kinds, things became more problematic. Now I was posting several posts per day, most of which weren’t in a traditional blog format. The home page became cluttered; it started to remind me of a badly thought-out notification area, rather than a well designed blog. The archive page was a disaster and I had no good ideas on how to fix it. There were a thousand other little niggles.

None of this is meant as a knock against Bootstrap, or WordPress, or build systems, or any other tool or technology I used to get to this point. K failed because of my decisions, rather than deficiencies in the tools. There were things I liked about K… it used zero JavaScript, and I did my best to stop unnecessary plugin resources from loading. Markup was as minimal as I could make it (within the constraints of what I could remove from WordPress output, microformats, and what Bootstrap needed). It worked well across browsers and devices (thanks Bootstrap!), and the accent colours were fun. I learned a lot about the excellent Post Kinds plugin during the development process. I’m filing it away as a failed experiment, which I’ll learn from and apply the lessons to the IndieWeb WordPress theme I’m still intending to create. One that will hopefully work for more people than just me ?

I put the source code to K on GitHub right back near the start of the project. If you want to take a look, steal any code, rework it into something usable – feel more than welcome to!

1 As a result, a couple of things that were setup specifically for K are broken. I’ll look into fixing those over the next few days. ⤴️

article

|

Note: I found this mini How-To while having a clean-up of my GitHub repositories. I figured it would be worth sharing on my blog. Hopefully it is of use to someone. Warning: bad ASCII art ahead!

The Problem

  1. I have my repository hosted on GitHub
  2. I have an internal Git server used for deployments
  3. I want to keep these synchronised using my normal workflow

Getting Started

Both methods I’ll describe need a “bare” version of the GitHub repository on your internal server. This worked best for me:

cd ~/projects/repo-sync-test/
scp -r .git user@internalserver:/path/to/sync.git

Here, I’m changing to my local working directory, then using scp to copy the .git folder to the internal server over ssh.

More information and examples this can be found in the online Git Book:

4.2 Git on the Server – Getting Git on a Server

Once the internal server version of the repository is ready, we can begin!

The Easy, Safe, But Manual Method:

+---------+ +----------+ /------>
| GitHub  | | internal | -- deploy -->
+---------+ +----------+ \------>
^                     ^
|                     |
|     +---------+     |
\-----|   ME!   | ----/
      +---------+

This one I have used before, and is the least complex. It needs the least setup, but doesn’t sync the two repositories automatically. Essentially we are going to add a second Git Remote to the local copy, and push to both servers in our workflow:

In your own local copy of the repository, checked out from GitHub, add a new remote a bit like this:

git remote add internal user@internalserver:/path/to/sync.git

This guide on help.github.com has a bit more information about adding Remotes.

You can change the remote name of “internal” to whatever you want. You could also rename the remote which points to GitHub (“origin”) to something else, so it’s clearer where it is pushing to:

git remote rename origin github

With your remotes ready, to keep the servers in sync you push to both of them, one after the other:

git push github master
git push internal master
  • Pros: Really simple
  • Cons: It’s a little more typing when pushing changes

The Automated Way:

+---------+            +----------+ /------>
| GitHub  |   ======>  | internal | -- deploy -->
+---------+            +----------+ \------>
^
|
|              +---------+
\------------- |   ME!   |
               +---------+

The previous method is simple and reliable, but it doesn’t really scale that well. Wouldn’t it be nice if the internal server did the extra work?

The main thing to be aware of with this method is that you wouldn’t be able to push directly to your internal server – if you did, then the changes would be overwritten by the process I’ll describe.

Anyway:

One problem I had in setting this up initially, is the local repositories on my PC are cloned from GitHub over SSH, which would require a lot more setup to allow the server to fetch from GitHub without any interaction. So what I did was remove the existing remote, and add a new one pointing to the https link:

(on the internal server)
cd /path/to/repository.git
git remote rm origin
git remote add origin https://github.com/chrismcabz/repo-syncing-test.git
git fetch origin

You might not have to do this, but I did, so best to mention it!

At this point, you can test everything is working OK. Create or modify a file in your local copy, and push it to GitHub. On your internal server, do a git fetch origin to sync the change down to the server repository. Now, if you were to try and do a normal git merge origin at this point, it would fail, because we’re in a “bare” repository. If we were to clone the server repository to another machine, it would reflect the previous commit.

Instead, to see our changes reflected, we can use git reset (I’ve included example output messages):

git reset refs/remotes/origin/master

Unstaged changes after reset:
M LICENSE
M README.md
M testfile1.txt
M testfile2.txt
M testfile3.txt

Now if we were to clone the internal server’s repository, it would be fully up to date with the repository on GitHub. Great! But so far it’s still a manual process, so lets add a cron task to stop the need for human intervention.

In my case, adding a new file to /etc/cron.d/, with the contents below was enough:

*/30 * * * * user cd /path/to/sync.git && git fetch origin && git reset refs/remotes/origin/master > /dev/null

What this does is tell cron that every 30 minutes it should run our command as the user user. Stepping through the command, we’re asking to:

  1. cd to our repository
  2. git fetch from GitHub
  3. git reset like we did in our test above, while sending the messages to /dev/null

That should be all we need to do! Our internal server will keep itself up-to-date with our GitHub repository automatically.

  • Pros: It’s automated; only need to push changes to one server.
  • Cons: If someone mistakenly pushes to the internal server, their changes will be overwritten

Credits

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

article

|

That cool little “Coder for Raspberry Pi” project from Google which I linked to earlier doesn’t just run on Raspberry Pi. You can run it on any old Linux PC (Mac works too, but the instructions are slightly different).

I set it up in less than 2 minutes using these commands (note that I’m running Debian Sid):

sudo useradd -M pi
sudo apt-get install redis-server
cd ~/projects
git clone https://github.com/googlecreativelab/coder.git
cd coder/coder-base
npm install
npm start

Node.js is also a requirement, so if you don’t have that, you’ll need to install that at step 2 as well.

Once everything is up and running, point your browser at https://localhost:8081/. You’ll need to specify a password the first time you run Coder, after which you’ll be able to try the environment out. It’s pretty neat, and the sample clone of Asteroids is quite addictive!

article

|

Skills are much like muscles: if you don’t use them for a while they start to atrophy. They say you never forget how to ride a bike, but there are many skills where you will forget things if you don’t do them frequently. The collection of skills needed to be a developer are no exception to the rule.

I’m somewhat speaking from experience here; my current role and workload has removed me from day-to-day development work for about a full year now. I still need to dive in to the code base every day to research issues or change requests, but actually writing something is quite rare these days. I’m aware of the skills problem, and I’ll describe below how I’m trying to address it, but never the less I’ve been self-concious enough about it I’ve recently found myself resisting taking on development tasks. I know it’ll take me a lot longer to get up to speed and complete as one of the developers who’re working on the application every day, and the time-scales involved are usually very tight. It’s a vicious circle: I’m rusty because I’m not doing development, but I’m avoiding development because I’ve been away from it for too long. In the corporate world it’s very easy to get rail-roaded into a niche – and incredibly hard to get out of it.

Time away for a developer is exacerbated by the speed in which technology and techniques moves forward in our industry. What was cutting edge a year-ago is old-hat today, and may even be something you’re encouraged not to do any more. If you haven’t been practising and keeping up developments then you may not be aware and get yourself into all sorts of bother.

So what can you do?

Read. Lots.

Subscribe to a load of developer sites and blogs in Feedly, for one source, but a more convenient way I’ve found to stay on top of things is using Flipboard:

  • Follow other developers on Twitter (actually, you don’t have to, but it’s nice to), and create/add them to a list, such as “Developers & News“.
  • Within Flipboard, add your Twitter account if you haven’t already.
  • Still within Flipboard, go to your Twitter stream. Tap your name at the top and select “Your Lists.”
  • Open the relevant list, then tap the subscribe button.

Your list will be added to your Flipboard sources and you’ll have an always-up-to-date magazine of what’s happening. The reason I suggest Flipboard is that it grabs the link in a tweet, pulls in the article, and will try to reformat it into something you can easily flip through. It makes reading on a tablet so much more enjoyable. Some of the links you get will not be relevant, but a large amount of it will be gold. I try to set aside 30 minutes a day to go through at least the headlines. If work is exceptionally busy I’ll aim for twice a week. Saving to a “Read it Later” service like Pocket is useful for storing the most interesting articles.

What about books? Yes, by all means, read plenty of technical books. They’re usually in far more depth than even the best online article. With tablets, eReaders, and eBooks, the days of thick tomes taking up lots of space are behind us, and no longer a major concern (at least for me). There is however, one major issue with books – they take a long time to write, and are often out of date quickly. The technology might have moved on by the time the book is published. Schemes such as the Pragmatic Programmer’s “Beta Book” scheme help a lot here – releasing unfinished versions of the book quickly and often, to iron out problems before publishing. Of course, you also need to be aware of the topic to be able to pick out a book about it!

Be Curious. Experiment.

Reading all the material in the world will not help you anywhere near as much as actually doing something. The absolute best thing you could do would be to develop side projects in your spare time. Admittedly, if you’re busy, time can be at a premium! Probably a good 99% of side projects I start lie unfinished or abandoned, simply for lack of time. So instead, I perform small experiments.

Curious about something? Do something small to see how it works, or “what happens if…”. Personal, recent, examples would be:

  • Looking into static site generators, and as a result, learning about Jekyll, Github pages for hosting… and as a result of trying out Jekyll templates I brushed up on Responsive Web Design, looked into Zepto, and fell in love with Less.
  • Trying out automating development workflows – installed Node.js (which then allowed me to run this), setup some basic Grunt.js tasks, Imagemagick batch processing, and some more Less.
  • Running Linux as my primary OS, and no Windows partition to fall back on – so in at the deep-end if something goes wrong… but it’s helped me brush up on my MySQL and Apache admin skills again, as well as generally working with the command-line again. The other week I fixed someone’s VPS for them via SSH  – something I would have struggled to do only a few weeks ago. In case you’re interested: the disk was filling up due to an out of control virtual host error log, which I had to first diagnose, and then reconfigure logrotate to keep the site in check.

An earlier example, from before I was entirely away from development: I wanted to see what was different in CodeIgniter 2, so I made a very small app. My curiosity then extended into “how does Heroku work?” – so I deployed to Heroku. I couldn’t pay for a database I knew how to work with, so I tried out a little bit of MongoDB. Then it was the Graph API from Facebook… so again, I extended the application, this time with the Facebook SDK.

Little experiments can lead to a lot of learning. I would never claim to be an expert in any of the technologies I mention, but neither am I ignorant.

Shaking it Out

I’d still need a major project to focus on and really shake off the “ring rust,” to get back up to full development potential, but I’m pretty confident it wouldn’t take as long as if I hadn’t been working on the trying to keep my skills as fresh as I can.

article

|

* By “The Right Way”, I mean following the guidance and practices at the PHP: the Right Way website. I make no claims this is the “best” way 🙂

Works n my machine badgeMac OS X is a pretty good web developer OS. It comes as standard with PHP, Ruby and Apache all out of the box, and the underlying UNIX system makes it easy to add in other languages and components to suit your needs. On top of that, some of my favourite development tools are on the Mac, so unless I’m writing .NET code, nearly all my development is on an (ageing) Mac Mini.

Now, while all that stuff comes as standard on OS X, lately it seems Apple has made it harder to get to. The versions shipped with OS X also tend to be a little behind the latest releases. As a result, most Devs I know use something like MAMP to make the server-side of their environment as easy as running an app. Personally, while I think MAMP works, and is a good time-saver (and I’ve been using it for the last year or so), but I like to get into the nitty-gritty of the system and get things running “native”. So last night I fired up the terminal and got PHP set up on my Mac with the latest version, and following the Right Way Guidelines. As a result I have PHP 5.4, Composer, the PHP Coding Standards Fixer, and MySQL all setup quite slickly (i.e. to my preferences).

The whole process was pretty easy, but does involve the command line. If this makes you uncomfortable, then it might be best to skip the rest of this post.

This all worked on my Mac, but I make no guarantees about it working on yours, and I’m not responsible if you break something.

If you find any glaring problems with this guide then leave a comment/get in touch, and I’ll make any required edits.

Step 1: Setup Your PATH

Edit the hidden .bash_profile file in your home directory. If you use Sublime Text 2 you can use the following command:

subl ~/.bash_profile

TextMate has a similar mate command, or you can use vi(m)/nano/emacs/whatever.

It’s possible you already have a line defining your PATH variable. It’ll look something like export PATH=<something>. I’ve found it most useful to change the PATH so /usr/local/bin is at the start, making sure anything you install there is used over the system defaults in /bin. Add this as a line below your existing PATH definition (or just add it in, if you don’t have an existing line):

export PATH=/usr/local/bin:${PATH}

Step 2: Install Brew

Strictly speaking, Brew (aka Homebrew) isn’t required, but I used it to install MySQL later, and it does make it stupid easy to install stuff into OS X. I think you should install it. The best instructions are found on the Homebrew home page, so go have a read there. There are a few pre-requisites, but nothing too difficult.

Step 3: Install PHP-OSX

Now we’re beginning to get somewhere! PHP-OSX is the latest versions of PHP compiled for OSX by Liip. Installation is a real doddle, from the command line:

curl -s http://php-osx.liip.ch/install.sh | bash -s 5.4

Follow the prompts given, including entering your password. After a few moments everything will have installed. For convenience I created a symbolic link to the newly installed PHP binary in /usr/local/bin:

ln -s /usr/local/php5/bin/php /usr/local/bin/php

Step 4: Install Composer

Now we have PHP installed, it’s time to look at the nice-to-haves, like a good package/dependency manager. Composer is relatively new on the block, and allows others to download your code and automatically grab any dependencies by running a simple command.

You can install Composer in your project, or you can install it globally. I prefer globally. As with PHP, installation is simple, from the command line:

curl -s http://getcomposer.org/composer.phar -o /usr/local/bin/composer
chmod +x /usr/local/bin/composer

Step 5: Install PHP Coding Standards Fixer

Another nice-to-have, this little tool will try to find and fix parts of your code where it does not conform to one of the PHP Coding Style Guides. Installation is almost identical to Composer:

curl http://cs.sensiolabs.org/get/php-cs-fixer.phar -o /usr/local/bin/php-cs-fixer
chmod +x /usr/local/bin/php-cs-fixer

Step 6: Install MySQL

If you installed Brew in step 2, then you’re good to go with this little command:

brew install mysql

It’ll take a few minutes, but you shouldn’t need to intervene at all. Once done you will need to run two more command to setup the MySQL tables:

unset TMPDIR
mysql_install_db --verbose --user=`whoami` --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp

If you didn’t install Brew, then you will need to install MySQL through some other means, such as packages on the MySQL website. I can’t help you with that, I’m afraid.

For managing MySQL, I use the excellent Sequel Pro, which is a successor to the venerable CocoaSQL.

As a next step you should look into changing the root password of your MySQL setup. This is a local dev environment, and likely only used locally by yourself, but it’s the proper thing to do.

Errata

  • Pear doesn’t seem to work, which is slightly annoying, but (to me) no real biggie. I didn’t test this with the built-in version of PHP, so I don’t know whether it worked beforehand. I’ll post an update once I figure it out.
  • I’d like to make bash script smart enough to stop MySQL when the PHP web server stops, but my early attempts haven’t managed to get this working (most likely due to the Ctrl-C used to stop the web server also stopping the script).
  • Throughout this process we’re running scripts directly from the web. This is pretty risky behaviour, especially with unknown/untrusted sources. You should always take a look at the raw script before running it, so you don’t get hit by something malicious.
note

|

Did you know you can use custom PHP extensions on Heroku? Neither did I, cos I can’t find it in the documentation. But you can:

https://gist.github.com/1288447

I came across this while searching for a way or workaround to use the MongoDB PECL extension on Heroku (don’t get me started on that…).

If you can’t be bothered checking the link, the summary is this:

  1. Create a folder in your app called ‘ext’ or similar.
  2. Copy your extension into this folder.
  3. Create a php.ini file with the following contents:
    extension_dir = "/app/www/ext/"
extension=mongo.so
  4. Deploy
note

|

the CodeIgniter logoMost of my small personal projects tend to get built with CodeIgniter (CI), which is a simple to use, fast, lightweight PHP5 MVC framework.

the Facebook logoFor a while now I’ve had an itch to build something fun against the Facebook API so I can start learning how Open Graph works, and as a primer to building a “proper” Facebook integrated application. I also realised I hadn’t actually tried using CodeIgniter 2.x since it was released (quite some time ago). With an abundance of free time this weekend it seemed like the perfect time to get hacking!

Before I could build anything I would need to know one thing: just how do you connect a CodeIgniter app to Facebook?

Continue reading →

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.

note

|

Elastic layouts have been getting a bit of talk over the last few months. John, Roger and Patrick have all talked about them. I use an elastic layout in the new design.

What is an Elastic Layout?

Traditionally, web designers talk about either “fluid” or “fixed” layouts. Fluid layouts change width with the size of the browser window, while fixed layouts are set to a specific width. There are arguments for and against each type. Where elastic layouts fit in, is to try and combine the best of both worlds.

The Theory.

Text sized in em units is scalable in browsers (theoretically). So what if we were to specify the widths of our page elements in ems? Our page elements should scale inline with the size of our text.

The Reality.

Using em units to size page elements does work pretty much as expected. However, there are a few things we need to do to avoid some problems.

Global Reset for Less Hair-Pulling

If you let the browser apply its default font-size, margin, padding and line-height, you’ll be in for a very rough ride. Make things easy – apply the global reset:

*{ font-size: 100%; line-height: 1; margin: 0; padding: 0;} /* Global Reset */

This resizes the text on everything to 100% of the default size (16px by default), sets the height of a line to the size of the text, and removes any default margins or padding. By doing this, we remove a lot of the guess work. I use a percentage value because I’ve found that this makes scaling text a little less error prone in browsers. 1em is now equal to 100% or 16px.

Browsers are Crap at Maths.

All the major browsers suffer from rounding errors to some degree. I must admit that it’s been a while since I checked on this, but both Opera and Safari used to render text sized in ems and percentages wrong – 10px would render as 9px, for example. To get around this, the fix was to size text slightly larger than 100% on the top level element. 100.01% was found to be the magic number. So our global reset becomes:

*{ font-size: 100.01%; line-height: 1; margin: 0; padding: 0;} /* Global Reset */

Make the Maths Easier.

I was never very good at maths (much like the browsers), so working things out in multiples/fractions of 16px wasn’t appealing. It’s also harder to visualise how big 16px is, compared to, say, 10px. So to make things easier to work out and visualise, we reduce our base font size down to 10px (using percentages, this is 62.5%). We can apply this to the html element and it will inherit down the line:

html{ font-size: 62.5%; } /*Resize text to 10px */

1em is now equal to 10px. Much better!

Make Everything an EM.

Well, almost. I’ve found that some browsers (the Gecko ones, mostly), will not render a 0.1em thick border, when 1em = 10px. Any border you want to be equivalent to 1px by default, just make it 1px – it might not scale but it will render. Other than this small caveat, the rest should be sized in em units: margins, paddings, widths, font-sizes… Doing so will make everything proportional to the text size, stopping things looking crowded at larger sizes.

Remember – EM Sizes Compound!

By that, I mean that if you apply a font size of 1.2em to the body tag in our example, then for all elements contained in the body, 1em now equals 12px. So a 3em h1 would be 36px high, not 30px like you might have expected. It’s something you need to be on the lookout for.

A Note About Background Images

Elastic design is geared towards using repeating background images. Unless it’s something like the “Latest Little Thing” icon on the homepage, using non-repeating images will land you with holes in your design where the container is wider than the image. A great example of using repeating background images in elastic layouts is the Elastic Lawn CSS Zen Garden entry.

Give it a Try

With all this talk about maths, compounds, et al, I’ve probably put you off elastic layouts. Don’t be afraid to try them. Once you get in the swing of things, it soon becomes second nature. Practice does make perfect, so all I can say is have a go!