Articles

Having worked on many python/Django projects over the last few years I have come to be very familiar with virtual environments as the easiest way for me to manage multiple project requirements on just one machine. Without them my main python packages folder would be constantly fighting over different versions of Django, PIL and every other library under the sun.

Virtual environments are one of the best ways to create multiple unique development environments on one machine as they keep each projects packages contained with the specific versions required all in one folder.

Once you have multiple virtual environments it starts to get a bit complicated, especially if you have to switch between multiple ones in a day. This is where virtualenvwrapper becomes so useful. virtualenvwrapper adds an extra management layer on top of the virtualenv so that you can navigate to and start the environments with a single command. It also helps to organise your environments by keeping them in one location (previously I kept environments next to the project)

I’m not ...

HTML 5 number pickers are great, since they help restrict users to the input ranges required in certain cases. Some browsers add little up and down arrows to help the user step though numbers. On some browsers the pickers show by default even when the form inputs are not focused, which is a bit ugly. You can use CSS to turn off the number input arrows. Obviously you want to put them back on focus since they are meant to be there by default.

// Webkit:
  // Hide number picker
  input[type=number]::-webkit-inner-spin-button,
  input[type=number]::-webkit-outer-spin-button {
    -webkit-appearance: none;
    margin: 0;
  }

  // Show number picker on focus
  input[type=number]:focus::-webkit-inner-spin-button,
  input[type=number]:focus::-webkit-outer-spin-button,
  input[type=number]:hover::-webkit-inner-spin-button,
  input[type=number]:hover::-webkit-outer-spin-button {
    -webkit-appearance: inner-spin-button;
    margin: 0 2px 0 0 ;
  }

  // Firefox:
  // Hide number picker
  input[type=number] {
    -moz-appearance:textfield;
  }

  // Show number picker on focus
  input[type=number]:focus,
  input[type=number]:hover {
    -moz-appearance:number-input;
  }
  // Note: Example is written in Sass not CSS!
  

Branching is one of the fundamental functions of Git. It allows code to be developed in a safe way (in terms of updating/editing/deleting) and allows more than one developer to work on different features at the same time without interfering with each other.

If we think of Git like a set of train tracks then it becomes easier to understand how it works. Each time you commit code to a branch it’s like making a station along a track. At any point another track can split from the current track and create it’s own set of stations and at any point a track can rejoin with another. Mostly the re-join is seamless and goes without a hitch, but on occasion it may be more complicated and require a human touch just to get things smoothed out. A branch does’t even need to ever rejoin. Now imagine that we have a branch that something goes horribly wrong on, or that we start heading off in one direction, only to find that ...

When you’re building a website one of the most important steps is the building of the templates. Building static templates is almost always quicker than building integrated templates such as WordPress, Django or Rails.

One of the biggest issues with using static templates straight off the file system is that file:// urls can have issues and relative links may have to be different than what they need to be when the site goes live. A local server is what’s needed, but things like MAMP, or LAMP servers can be a pain to setup,esecially if your working on multiple projects. Enter the simple server.

PHP has a basic server. Simple go to your project folder in the terminal and run the following:

php -S 0.0.0.0:8080

This will setup a basic php server on the address and port provided.

With all these simple servers you have to remember that there is no database so you can only do simple functions and serve files, but not do anything more complicated. That's ...

Where to put the javascript?

Unless it’s essential for it to be in the head of the HTML document, place all javascript just before the closing body tag of a page.

What’s essential for the head?

That can vary from project to project but a rule of thumb would be:

• A minimal amount of inlined javascript
• Any javascript that can be loaded async.

What should do in the footer

• jQuery. Nothing essential should be using jQuery.
• Everything else like galleries and slider js, social js etc.

How many js files should there be?

For a normal site there should be 2 js files that are loaded for the whole site. The header.js and the footer.js. That’s it! Call them what you like! There may be more specific files that are loaded for certain pages or sections of a site.

header.js

Contains the header javascript that contains things like Modernizr. This can be created by concatenating (joining together) lots of smaller js files.

footer.js

Contains everything else that is global ...

When you’re working on a project it’s vitally important to make sure that the work you are doing is backed up and saved as often as possible. Not only does this give the freedom to try out ideas easily without risking the sanity of a project, but it also allows you to roll-back unwanted changes and in the worst case recover deleted or overwritten files.

Version control works by making ‘restore points’ in our working history of a project so that we can step back and undo breakages or recover code that wasn’t useful at one point, but now is. It’s a life saver.

Another advantage of version control is the ability to branch a project and try new things, develop new features in parallel to other developers and all without risking losing or breaking the code in a project.

When you compare that to saving files with incremental version names or backing up folders before downloading from an FTP server, then you can see why developers use version control. It ...

Have you ever been on a website when something goes wrong? It’s not always clear what’s gone on, or what you can do to get back on track. What’s a 404 or a 500?! You might know this as a developer or web designer, but does the average Joe?

Error numbers are for developers

As the owner of a website you want to know what went wrong when or if it does and that’s why error numbers were created. But we build websites for users and not developers (except sites like this…), so the error numbers aren’t the key message that needs to be shown.

Guide a user via a good error pages

When a user visits a web page the most important thing is to give them the information that they need quickly and presented in a good way. The problem with a lot of error pages is that they treat users like robots and not as humans.

Disarm

Imagine you go into a hotel where you have a room ...

Git is easy to get along with if you follow a few simple rules of thumb. Things can still go wrong, but they do so, it’s less often and when it does, it’ll usually less of a problem to fix!

1. NEVER work directly on the master branch (this should be the latest working version of your project).
2. Commit files often and when it makes sense. Don’t leave it until there are multiple random things that need committing as if one breaks the site, then you might have to revert all of them.
3. Branch for each feature and fix and always branch off master (except in very few circumstances).
4. Make sure commit messages are simple to understand. If it’s something you need to explain then do a Git commit (without the -m) and a text editor should load where you can explain yourself on multiple lines (similar to markdown).
5. Always merge master into your branch and fix conflicts before merging your branch into master. This means conflicts won’t break  master.
6. Ignore ...

A local settings file is one that is never controlled by version control and only contains settings relevant to the server – local, development or live. Often the local settings file is created by an example settings file that has all the relevant settings ready to fill in. The example settings are always committed to version control so that each developer who works on a project can see what they need to fill in when they clone the project.

One other major advantage of not adding the local settings for a project is that it keeps server settings safer because only people with access to the server can see them, unlike a project repo where even if it’s private, any developer with access can see it, and if it’s an open source project then everyone can!

How do I make an example file?

1. First take your config or settings file and save it with -example on the end of the file name.
2. Go through the file and remove any settings with secret info like ...

Turning any project in to a Version controlled project is really simple and should be one of the first steps in any project workflow. By the time you realise that you need a version controlled file, it’s usually too late – whether you have accidentally overwritten a days worth of work on a file, or you deleted the wrong thing. Since it’s so easy to setup, there’s really no excuse not to. There are a few best practices and tips as well as a few gotchas to note along the way but don’t worry, I’ll be pointing them out.

We could use a GUI for setting up and managing our Git repos, but to make sure that you understand what’s going on behind the scenes we’re going to be using the command line for setting up the git repo this time.

We’re going to assume that you have an existing project that you want to turn into a Git repo. If you don’t then just create an ...