Articles tagged with Resources

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 ...

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 ...

There are a few ways of writing css. For consistency we will adopt only one naming convention. This is lowercase and hyphen separated. It is the most readable and fits well with other CSS methodologies that are covered below.

Yes

.hyphen-separated {...}

No

.camelCase {...}
.underscore_separated {...}
.alllowercase {...}
.ALLUPPERCASE {...}

Specificity

Keep your selectors short and with as low a specificity as possible. A maximum of three classes in your selectors is recommended. Why? Two reasons:

• Selectors with a high specificity can be time consuming to override
• long selectors can bloat your css.

Yes

.my-thing { … }
.my-main-thing .my-thing { … }
.my-main-thing .my-space .my-thing { … }

No

.my-main-thing .my-sub-thing .my-space .my-thing { … }

Do not include one or mote #ID’s in your selectors…EVER. It’s too specific. Use #ID with javascript … but not styles.

So you like namespacing with #ID’s? Cool…namespacing is good, just do it with a class instead.

Yes

.my-thing { … }

No

#my-thing { … }

!important is ok in a very small number of circumstances. One example is error messages which always display the same way – red and bold. We don’t have a ...