On this week’s show: The Northeners are joined by the Headscape duo Craig and Dave. We talk about why you should care about .NET MVC and answer your questions about managing your code and friendly URLs.
Vote for our SXSW Panels!
It’s that time of year again and we’re asking our beloved listeners to vote for one or both of our SXSW panels.
Any votes would be greatly appriciated!
Expanding your development skills with Creative Tech Projects
This post by Smashing Magazine tries to pursued you into doing something different every once in a while and points out that even if you’re a web developer, your next project doesn’t have to be a website! You can learn a lot by doing something outside your normal comfort zone, and there’s some great examples of different things you could play with, such as:
- Write your own desktop application, using Air for example
- Extend Firefox
- Create interfaces for your favourite gadget, such as your iPhone or Wii
- Play with Hardware, such as the WiiMote, Arduino kits or Lego Mindstorms
One of the things I love about working in this industry is the sheer amount of cool stuff available for us to play with. Admittedly, it can often be hard to find the time, or even justify spending time playing with cool stuff when client work is stacking up, but who knows, you might find that people out there would pay you good money to build things using the skills you acquire!
5 Advanced Photoshop techniques for web designers
Yes, this is a ‘top 5’ type post, but it’s quite a good one so I thought I’d tell you about it. This article on the Think Vitamin blog gives you a decent rundown of 5 popular visual effects in modern web design, and tells you how to replicate them.
There’s tons of screenshots and explanations of how to make awesome buttons, navigation menus, inset typography, faded shadows and depth. It’s a post to bookmark for those times when you have a spare few minutes to mess about in Photoshop and try new things.
Digg’s move to GIT
This is the first of a two part article detailing how the developers at Digg are making the move from Subversion to Git. I realise that source control doesn’t get discussed much on this show, but it’s something that every designer and developer should be using if they’re not already.
I’m not wanting to start a SVN vs GIT argument here, but I’m very interested in seeing how big established teams work in regards to source control and this is quite a candid account from the Digg team about the scaling issues they experienced as the development team expanded and SVN struggled under the load, and how they’re starting to use GIT to solve some of these problems, highlighting both the good and bad points of the new system.
Everyone will have their own source control preference, but if you’re part of a large team and have source control issues (don’t we all) then give this a read.
Feature: Why .NET MVC? (and why should we care?)
Having previously written about the highs and, perhaps more importantly, lows of working as a .NET developer. This article will continue the trip into Microsoft World, only this time it’s to the land of MVC.
Managing your code
Question from Jamie…
I have recently started developing my own system for building web applications with. I have found that as projects have ticked by i have ended up with a large assortment of code of different versions and functionality. How do the backend development guys at headscape manage this code mountain beyond the project by project SVN style management?
Headscape has a strong design and consultancy background, however the development side of things has also been done internally since
the beginning. In fact the design and Tech teams are of equivalent size and we have a large number of legacy and currently running projects
at any one time. Source control and code management is therefore vitally important.
As a development team we rely heavily on three main methods of knowledge transfer over time, projects and team members. This includes
the standard approach of code commenting, a source control system and an internal wiki for snippets, interesting decisions, rationales,
product roadmaps etc. The wiki, in the context of code, provides a space for longer descriptions and reasoning behind technical design and
As many of you may be aware a large number of Headscape projects utilise our in-house CMS. This acts as the base for our common code and
contains multiple projects – A common code repository (the equivalent of our ‘System’ namespace), a CMS class library project and
a base CMS Web project. When a new CMS project comes in we create a new project in source control, with the most recent labelled stable
version of the CMS code as the initial check in. Changes on this development are then logged only within the context of the project.
Throughout key stages of development and during project washup changes and enhancements that can be generalised from this project will fed
back in to the main project after review with at least one other member of the tech team. As some projects can be very bespoke we do not
currently utilise branching within our Source Control repository for the purpose of each project.
Daniel Farrell writes:
My university has a ridiculous URL naming scheme!
I can see what they are trying to achieve: human readable and logical ordering of pages. But by nesting on such a microscopic scale, they produce the opposite result. The pages are no longer memorable, and not even easy to read because you need a huge screen wide screen to see the whole URL.
Furthermore, because ‘software’ is a service provided by the ICT department is must be nested underneath it. This reflects the management structure of the department not necessarily the way a user thinks! For example, why couldn’t the URL be, /softwareshop/adobe?
What are your thoughts on human readable URLs and how would you tackle the problem of making such a huge site easy to use? Should I have more sympathy for the web team or do they need a good kick up the arse!
There are a number of reasons that large organisations use long and often convoluted URL schemes. One possibility is that different parts of the site could be hosted on different servers and managed by different people. There may be different systems running different sub sections such as a shop which generates its own URL structure under an already long base path.
Firstly, it doesn’t always matter. Unless it’s a URL you want people to remember, the majority of web users don’t really care what ends up in their URL bar once they start navigating a site. It makes no difference to a bookmark and can be shortened easily enough by any number of URL shortening services such as tinyurl or bit.ly.
So when does it matter? It matters when you want users to easily find something that could be tedious to find by navigating a site. A good example is TV or poster adverts where people need to remember the URL for a period of time or a subsite that isn’t linked to from the main site. (administration logins for example)
A good example of a website that manages this well is the BBC site. This is a huge site with many smaller subsites. It’s important for them to advertise concice and memorable URLs so many of their subsites are directly below the site root. One solution could be for the university to setup a series of shortcuts that redirect to the full URL.
Some tips for constructing easy to remember URLs
- Keep sections concise. “personalcomputersupportandmobileservices” is bad, “ict” is good.
- Try and use words that are easy to spell.
- Avoid numbers and hyphens
- If possible and necessary, create a couple of versions that are equivilent and redirect to the correct version (ie. Wikipedia’s redirection)