Or, how a non-developer can make sense of the terminology we sometimes spout… It all starts from a simple question:

Is .NET a programming language?

No, .NET isn’t a programming language, it’s a framework.

Framework! Like Ruby on Rails!

Yes like Ruby on Rails. A framework is a load of bits of code that someone has packaged up to help developers create applications. Ruby on Rails, .NET, Django and Cake PHP are all examples of frameworks.

So frameworks are libraries?

Not really. A library tends to be focused on a particular piece of functionality – for example you might have a libraries that lets your code talk to Twitter.. In the world of Ruby, libraries are often packaged up into gems – little bundles of functionality which you can add to your app. In fact that’s a good way of looking at a library – just a bolt-on of focused functionality.

Right. So what was a programming language again?

The programming language is where it all starts. A programming language, like C#, Ruby, PHP or Python, is used to write libraries and frameworks. The language, the libraries and the frameworks combine to allow you to write an application.

You need a lot of stuff to get started then…

Well really the programming language is the bare minimum – you could write an application using just those bare essentials. But bolt on a framework like Ruby on Rails and you get things like easier ways to access the database or do localisation, and add a library to speak to Facebook and Foursquare. This enables your application to get up and running much more quickly because you don’t have to write all of that code again. You’re standing on the shoulders of giants; you’re not reinventing the wheel.

But what about security? How do you know all of these frameworks and libraries are safe to use?

Two reasons. Firstly, many libraries and frameworks, such as Ruby on Rails and the vast majority of Ruby gems are open source. This means you can look at the code yourself and check that it’s not malicious. Additionally, hundreds of other eyes are looking at that same code – in the case on Ruby on Rails some of the world’s best coders will have had a hand in developing the framework. Secondly, in the case of frameworks such as .NET, a multi-billion dollar organisation will have developed a rigorous Q&A process with automated testing and security auditing to make sure it lives up to its billing. If Microsoft can rely on .NET to run its business, chances are you can too. And recently even Microsoft has begun open-sourcing its code, so you can review it by eye if you want – all 1 bajillion lines of it.

Surely there’s no way to be sure unless I’ve written it myself though?

Possibly, but chances are you’re more likely to fall into the same holes as other developers – for example creating a web framework which falls prey to XSS vulnerabilities or other such security issues. A peer-reviewed third party framework will have been there and done that, with thousands of developers and users checking it for security problems every single day. Like I said – standing on the shoulders of giants.

Ok. I’m getting it. Language > Library/Framework > Application. So what’s a platform?

Oh God. Well a platform is at the top end of the scale. You build applications on a platform, but a platform itself will likely have been built using a framework. Sometimes platforms are applications as well – applications which provide developer APIs for example. A good example is Facebook – technically it’s a vast application, but it also provides lots of ways for developers to build on top of it and interact with the Facebook application and its users.

Excellent. So this new language we’re writing with Facebook on top of the C# library – when will that be ready?

You mus- Ahem. Well now you know so much, you can write it yourself. Get back to me when it’s done, there’s a good manager.

NYVJ3JMK8P7M

For today’s web developers, start-ups and forward thinking businesses the notion of ‘web content’ and where it’s seen is changing at an incredible rate. Gone are the days of designing and producing a site suitable just for a desktop PC monitor. In 2011 web content must be developed to be viewed and interacted with across a range of screens of varying sizes, from smartphones to the widest flat-screens – and this post should help us to start considering ‘multi-screen thinking’ and its importance.

In the interest of keeping this post quite snappy I have opted to focus on just three types of web content: home pages, e-commerce pages and promotional content (such as blog posts and news articles) which should give us a range of examples. I also wanted to make the information easy to remember, so let me introduce you to:

The 3 “…ables” of multi-screen thinking when creating web content

1. Viewable

The first ‘multi-screen thinking’ question to ask ourselves when creating web content is: will this be viewable across multiple screens? Even before we have moved away from desktop monitors and laptops, it is important to bare in mind the range of browsers web users are using to arrive at your homepage. According to TopTenREVIEWS the top 3 browsers available currently are Firefox, Chrome and Internet Explorer and it is important to bear in mind that some sites may load slower in certain browsers than others – and if your homepage is not viewable on a certain browser within a few seconds it is likely that user may give up and head somewhere else.

Of course, beyond desktops and laptops, web content needs to be quickly viewable on smaller screens such as smartphones and tablets such as iPad – and the most important information and ‘calls to action’ should ideally be seen as soon as a homepage is loaded.

2. Usable

So if you’re happy that your web content is adequately viewable across all screens (and browsers), the second thing to consider is whether that content is usable too. This is increasingly important with mobile devices in mind. As Internet Retailing reports, 18% of online shopping at Christmas was expected to be done via mobile but only a 23% minority of retailers had sufficient navigable mobile sites or apps in place for this proportion of users.

With more people shopping on mobile, e-commerce sites need to not only ensure that product pages are displaying vital information simply, clearly and concisely – but the checkout process needs to be quick and easy (and must remain safe) for smartphone users as well as traditional internet shoppers. Of course, testing and refining the process on a variety of technologies is key here.

3. Shareable

Aside from simply being viewable and usable across multiple screens, shareability is also a big factor when it comes to web content – and especially content geared towards getting traffic to your site (such as blog posts).

There can be multi-screen issues as simple as formatting, with text size and lengths of articles – but aspects of good shareable posts which really get people “liking” on Facebook or re-tweeting on Twitter, such as data graphs, images and infographics need to transfer well to smaller screens (and across 3G and 4G networks). This is the first step to ensuring prospective sharers are seeing the kinds of things they like to pass to their friends and followers as soon as possible, and on any of their devices. Good fresh content should be seen by as many people as possible, and new tech users are really the last group you want to frustrate by not considering mobile devices when producing content to be shared.

The source code which makes up the software we develop is our most valuable asset. As such, it needs to be treated with love and care. While backing up assets like this is important, with something such as source code – which is changed by multiple developers – you also want something to analyse and manage the changes which these assets go through.

Item number one on Joel Spolsky’s “Joel Test” is: “Do you use Source Control?”. Any software company who do not use source control are not taking appropriate care with their own code and potentially their customer code – and that’s foolhardy at best. At Go Tripod, we use the Git version control system which has gained a lot of traction over the past year or so. Subversion (SVN) used to be the cool kid in this arena, but Git has firmly placed itself at number one on the popularity contest.

Github’s been key to this, because it’s provided a really easy way of working with Git thanks to its excellent guides and documentation. Both myself and Jon have our own modest Github accounts, and while I’ve used Google Code in the past I really want to try and keep with Github as I move forward. Why? Because I think Github promotes healthy projects.

Look at any project on Github and you’ll see two little icons – one to keep watch on a project, to check when there’s any activity, and a second one to fork it. I believe that forking a project is the single strongest part of Github. It enables two things – firstly, for contributors to get involved without having to submit patches or anything like that – all contributions and merges can be done by the project owner by simply pulling in a contributor’s changes.

Secondly, if a project goes dormant, it’s trivial for someone else to fork it and essentially take it over. The most active fork of a project is likely to attract the most attention, so for valuable projects, we could see the end of stale, unmaintained work.

However, forking on Github does have weaknesses. In the above scenario, where a fork ends up becoming the predominant development version of a project, Github doesn’t have any way of transferring ownership of a repo from one person to another. This would make sense – the original developer doesn’t want to maintain a project then it’d really be better to allocate it to another developer rather than that developer having to fork. And in some ways forking can dilute a project, with many users adding their own tweaks and enhancements which never then get pulled back into the master. This is a shame, though ultimately I’m not sure how much of an issue it is.

Anyway, we love Github, warts and all. Look out for some more interesting Labs projects hitting our Go Tripod Github account soon.

The Magic Number: Why data is important three times over in our multichannel world – a #JUMPchallenge post

This guest post by Luke Richards is part of the #JUMPchallenge, a blogging competition designed to raise awareness of how to join up online and offline marketing, launched to support Econsultancy’s JUMP event.

Data and tracking has become more important to web developers and digital marketers as online business has become increasingly competitive.  However, as companies start to look at their performance across multiple channels – i.e. incorporating mobile and social media, as well as search engine optimisation, onsite usability and offline techniques – intriguing developments have been made into collecting data seamlessly across channels and then using this information in the best possible way.

Read more…

Very occasionally, people will start asking me in detail what I do for a living. When “I write software” or “I make websites” doesn’t satisfy them, I go into a bit more detail about the different aspects of my job. One thing that happens quite regularly if I don’t go into enough detail, is that I’ll tell someone how long it took to write something, or how much it cost, and they’ll raise their eyebrows.

“How can it cost so much?! It’s just a website!”

I can see their point. Most websites contain common elements – login, lists, articles, shopping carts, and so on – so you’d think that once you’ve written one, you’ll have the bits and pieces you need to make more. And taken individually, each of these parts are fairly straightforward – a list of products contains some pretty basic HTML, surely? And HTML is just a text file?

And again, that’s a fair point. The real time isn’t taken in writing these bits and pieces, it’s taken in understanding how the customer wants them to be written and how they need to fit together in a certain situation. For example, a shopping cart quickly becomes more complex when the customer adds on a few more features:

• Integrates with Google Checkout
• Customers can save carts for later ordering
• Customers can reload past orders into a few cart

But it’s not just the cart, it’s viewing products too – what if certain customers see custom trade prices? Or products can be assigned to multiple categories and the customer wants to see how many products are in each category next to the category name? All of these things are minor when taking in isolation, but together they are a thousand tiny cuts which bleed development time.

As well as a collection of features, a specification for a website will also discuss requirements in language which is specific to the company you’re quoting for. Rather than “cart” you might have “basket”. Or you could have “assessors”, “reviewers”, “investigators”, or any other number of terms which a company uses internally and when referencing all of the features they want on their site. Eric Evans talks about the “domain” of a problem when discussing software – not only do you have to appreciate what kind of features are necessary but you have to understand the domain in which they’re going to be used, in order to create a solution which fits together correctly.

So software is a whole big bag of questions and clarifications and solutions. From a developer’s point of view, it’s not just a case of taking some standard components and piecing them together – though that does happen occasionally. Instead every step of the development process is about solving problems, by understanding what the customer wants and by understanding the problem domain. Every day of development sees a developer tackle a new bit of work that needs resolving in a novel way, and that’s why making software isn’t just a case of shoving some parts together and hoping that it works, but a process, an evolution of the initial ideas.

When clients come to us and ask for software, they’ll pitch it by saying “make us a website”. But we know that what they really mean is “look, understand, and solve our problem”. And that’s what we do.