Version Control and Projects
2009-02-03 07:49:19
Its only fairly recently that we have started to use true version control. Prior to this, we had a had anarchy. We had directories for each site, then random directories and archives, some correctly labelled as 'sitename-
It was unmaintainable and something had to change.
Many people are of the opinion that version control is only for when you are working in teams. This is untrue. You gain many benefits by moving over to a version controlled system.
Backups are important. Version control gets you part of the way there, but you still need to backup the repository. Its a lot smaller than dozens of full copies of your site in archives and its can be easily automated.
Some of the advatages we have found:
- You don't have to think about backing up... every checkin is a backup and can be rolled back to as needed.
- You have a comment from overy checkin you do so you can understand what changed when.
- You can hook into the checkin so that you can for example, run basic quality tests or generate documentation automatically from it.
- You can get emailed with a diff of anything that changed in each checkin so you can easily see what other team members are doing.
The way we currently work is as follows.
We have three stages for every project; dev, staging and live.
Dev is version controlled, we only try to checkin complete changes so that at any time we can checkout a version into staging and have a working site. While this means that in the event of a development workstation failure some data may be lost, it does mean that a checkout can be done and expected to mostly work.
Whenever we push a dev snapshot to staging we make a note of the revision that was pushed over. If the dev version is a generic backend like our CMS then we try to keep template config files rather than having working config files with credentials for our servers embedded in them. This means that as long as the config format doesn't change, we can keep a seperate config.php on the development environment, on the staging server and on the live server and have each site running on a seperate database and config on a fresh checkout without much effort.
When we are happy with the staging snapshot, we create a tagged version of the dev snapshot from the same revision as the staging snapshot and use this to push a new copy onto the live server.
There are two schools of thought as to whether you should use an export or a checkout for pushing onto a live server, both have advantages.
Using a checkout, you gain very quick upgrades between versions. The downside is that you then have to protect the subversion metadata from public access on the server.
Using export, there is no metadata to protect, however you can't as easily just roll out changes to the site. On large sites this means a roll out may mean up to a minute of downtime unless you are careful.
You can get around this by duplicating your document root and then exporting over the top of it. Once the export is complete, you switch the document root on the server and start serving from the new version. This only works properly if you don't write much into your document root from within you application. Between the time of the copy and the time the document root is changed, any writes within the document root will be lost. You can solve this by only writing application data outside the document root.
This isn't a perfect setup, far from it, but it is a vast improvement over what we had before. There are some things that we have had to change in our workflow, but these haven't been major changes and the advantages far exceed the disadvatages in our opinion.
Specialist vs Generalist Developers
2009-01-26 16:36:59
People sometimes ask me what makes a good job description. My answer is simple. Not too specific, not overly broad.
I often see adverts worded somewhat similar to the following:
PHP Developer Wanted Must have 8 year experience in PHP, Java, C, ASP, MySQL and AJAX. Must also have Masters degree and have 5 years work history.
Put simply, its not going to happen.
While yes, there may be people out there with the whole skill set you are looking for, its a very wide requirement list and some of the technologies are opposite each other on the skills scales.
Let me show you.
- If you know PHP, its a good bet you are a web developer.
- If you know PHP, its a good bet you also are familiar with HTML and CSS.
- If you know HTML, its a reasonable bet you know at least some Javascript.
- If you use PHP, its a reasonable bet you use a version of the LAMP stack (MySQL, Apache and Linux)
- If you know C (or C++), its a good bet you deal with lower level code (Libraries, kernel modules, applications etc)
- If you know ASP (or other .NET technologies) its a very good bet that you develop on Windows and deploy on Windows based technology.
There isn't much overlap in these areas, LAMP stack developers rarely develop on or for a Windows platform, ASP developers rarely develop on or for a Linux (or other Open Source) platform. So just by looking at two opposing technologies you are already restricting your potential employees to just a handful.
This is fine if you are willing to pay for that expertise, but its a rare company that will be willing to pay what is required to get good developers with this range of skills. Generally, you will end up with a few people that either lie on their applications to make themselves fit the description or know all the technologies but without any real depth to any of them. We frequently see these types of 'out of their depth' developers in some of the community help channels we frequent.
So whats the answer to this conundrum?
Look for the core skillset for the job. If the core tasks are to manage a PHP website, then look for that as a core skill. Even if they will be occasionally required to change something in ASP, don't ask for it. Its far better to outsource the occassional task that is outside your expertise than to compromise on the right candidate due to overly specific job requirements.
The second thing to look out for is flexibility. The best problem solvers enjoy learning. Look for someone that has that core skillset but is also able to learn new technologies. They are adaptable and able to change.
One last thing is that the best developers can output 3 or more times the output of moderate developers. They enjoy programming and will even do their own projects outside of work.
How do you identify these people?
Ask to see what they do outside of work. If its a personal project it probably wont look pretty but it will solve a problem, scratch that annoying itch they had at the time.
It might not even be in software development, it might be another technical subject that is more 'creative'. Woodwork for example.
For example, One personal itch of mine was not being able to get barcodes for my friends book publishing company without paying stupid amounts for them. This Quick and Dirty Barcode Generator is not pretty, but it solves the problem I had at the time. (It generates valid 13 digit ISBN and EAN numbers (since ISBN is a subset of EAN with the 978 prefix)).
What is the optimal screen resolution?
2009-01-26 10:40:31
Measuring a users screen resolution is harder than detecting what browser they are using. Its not sent automatically with every request and has to be detected through the use of javascript. If a user has javascript turned off then you can't easily measure it. (I'm ignoring the fact that plug-in and toolbar providers do have access to some of this information at present)
While you could go through the process of detecting the users screen resolution, and probably should if your users aren't a normal cross-section of the browsing population, its far easier to see what the big websites are doing.
| Website | X Resolution |
|---|---|
| New York Times | 972 pixels |
| CNN | 1002 pixels |
| The Register | 956 pixels |
| BBC | 974 pixels |
| Yahoo | 950 pixels |
| Daily Mail | 964 pixels |
We sampled a random selection of websites, as you can see from the table all of the websites chosen are optimised for 1024 pixels screen width.
Client Expectations
2009-01-20 11:24:34
For a developer, dealing with most clients is hard. The client has a different level of experience and different terms they use on a daily basis.
Its not just that what you describe to them may invoke different emotions and mental pictures, its that their mental model of the whole process differs from your own. Its not as if it only applies to one specifc area of development, it applies to project design and development, UI design and many other areas of IT.
For example, if a customer says that a website is slow, you can't expect them to differentiate between the actual computer being slow (malware perhaps), the rendering being slow (perhaps an unoptimised javascript file or a misbehaving plugin),DNS resolution taking a while, the connection to the internet being generally slow (running bittorrent or similar p2p protocols, maybe), a path issue between their network and the server or the server itself being slow. You have to devine this yourself and even if many of these variables were exposed to the user, few of them would be useful to the majority of them due to lack of knowledge of what they mean. You would end up with many 'rules of thumb' being used out of context, such as the often quoted '200ms latency is the maximum usable'. Its not, and really depends on application.
So as developers we have to manage this 'black box' of a user. We can't see inside to see how it works. We can't take it apart and put it together again in a working state. We have to ask questions, shove pictures and concept drawings at them and hope that there is enough information coming back for us to narrow down how they are seeing our concepts.
Agile Development vs Traditional Development
2009-01-16 10:23:45
Traditionally, software development has always progressed through 4 steps. These steps, the so called 4 Ds process, consist of:
- Discovery
- Design
- Development
- Delivery
Many development companies try to shortcut the areas they don't have as much expertise with, which generally means that the first two steps are abridged or even completely missing. They attempt to make up for this, but going back over and over again thorough many versions at the development stage to try to nail down what the customer actually meant in the first place. They label this 'technique' as agile development.
While this is a perfectly valid method for some small projects, especially where the programmer and tester are one and the same, it seldom copes with anything with any complexity. If your requirements are complex, such as having legal or contractual requirements, then its rare that agile development can work effectively without taking on some of the traditional processes aspects.
Requirements are important. Without requirements how do you know when the system does what you need? How will the programmer know when to stop? When do you stop adding 'just one last feature'? The answer is you can't know any of these things for sure without setting goals, goals are produced from requirements and without discovery, even in an abridged form, you wont have any requirements suitible for setting proper goals.
I am sure many people reading this are either agreeing or disagreeing with me. To the people disagreeing with what I have wrote: if you are managing to make agile development work without any real requirements analysis, then I will be very suprised. Even if you aren't putting it down on paper, you are probably taking much more of the traditional approach into your cycle than you are letting on.
To the people that do agree... congratulations :)
[EDIT: Some people have taken this to mean I am completely against iterative development. I am for any development style that doesn't skimp on trying to understand what the customer means. Internally, TractionThroughAction uses an iterative model, its just our cycles (for our own products) are a lot longer than the generally accepted norms for 'agile' development.]
Use of AJAX
2009-01-16 05:05:20
Scouring powder should not be used on enamel surfaces. Oops, wrong AJAX.
AJAX has the possibility to make user interfaces better. Few people would argue that the GMail interface isn't bad compared to some of the previous generations of webmail clients but I think that you should only use it where there is a need.
There is far too much 'AJAX Wanking' going on; using AJAX just because of the hype and coolness factor without any concept of the UI problems they are adding to the web application.
Breaking the back button in an app like gmail isn't bad. You don't expect to be able to bookmark a particular message and it working next time. It puts the user into an application mindset and bookmarking in applications is a rarity.
However in a normal website, using AJAX to change the content of a page, in what would prior to AJAX have been bookmarkable, is a bad idea if the it means that it breaks normal browser navigation and bookmarks.
I also believe that normal websites should work without JavaScript being required for basic use. Not just from a security and usability aspect, which are important, but from an SEO perspective. If a user needs JavaScript to see your content, so will a search engine. If a search engine can't see if it will affect your pageranking negatively.
Premature Optimisation
2009-01-16 04:53:22
Often I am told by programmers that you should never optimise your code, or at the very least not optimise it initially. This is rubbish.
Optimisation takes many forms, from efficient algorithm selection and well-written code to profiling your code and speeding up any slow bits.
While actual code optimsation shouldn't be looked at too closely in the early stages of writing the program, any decent programmer worth their salt will be aware of what they are putting into the program and how it will impact run time.
I know the original quote was talking about old school programming in the early years of computing but while you can still use it as a guiding principle it isn't the perfect fit that it once was.
Is buying a template for your site really so bad?
2009-01-14 10:59:17
People often tell me that "If I want a real website I should goto a real webdesigner and get a custom one-off design done."
That isn't cheap.
Sure there are a lot of webdesigners out there, but how many have a flair for design *and* can make XHTML compliant code *and* make it work in many browsers? The answer is not many.
I myself, haven't got the flair for design. I am too logical and the best I can do design-wise is outshone by my friend's toddler daughter. So if I can't design, can I code? The answer is an emphatic 'Yes'. Are there many designers out there that can't code? Also a big 'Yes'.
So my solution used to be to get a design concept done up in Photoshop or similar tool and then just use that as a tracing image to build my own template for the site.
Would I still do this?
No way. I have far better things to do than this. So what do I do about designs?
Put simply... I buy them.
I will put my hand up right now and say that over the last 6 months i have done no template design or coding. I have bought most of the templates I have used.
So are they as bad as people say? Nope, almost all validate both for XHTML 1.0 Strict and their CSS works in both Firefox and IE (I can't test Safari easily, since I don't have it installed (yes i know there is also a windows one)) and most look pretty good to boot.
It takes minutes to select a template and buy it. Then only a short time to mark it up for the CMS and drop it into the site.If I did the design stuff, even if its just outsourcing it, myself, then it would have taken hours. That's hours that would be better spent on other things like adding new features or getting new customers.
Generating XML with SimpleXML and namespaces
2009-01-13 17:32:17
This isn't well documented on the php website, so I thought I would explain it here.
If you want to use namespaces in your XML, then you declare the namespace's prefix and uri in your root element, then you add the *SAME* uri as the third option in your addChild() or addAttribute() function call.
<?php
header('Content-type: text/xml');
$xml = new SimpleXMLElement('<?xml version="1.0" encoding="UTF-8" ?><rss version="2.0" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" xmlns:atom="http://www.w3.org/2005/Atom" />');
//main page
$channel = $xml->addChild('channel');
//atom link
$atomlink=$channel->addChild('link','','http://www.w3.org/2005/Atom');
$atomlink->addAttribute('href',$base.'/'.$script.'/rss');
$atomlink->addAttribute('rel',"self");
$atomlink->addAttribute('type',"application/rss+xml");
//snip...
<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><atom:link href="http://www.tractionthroughaction.com/blog/rss" rel="self" type="application/rss+xml"></atom:link>
I hope this helps someone, it took me about 20 minutes of searching before I found it.
Mike
TMI-CMS
2009-01-13 16:00:40
After a long hard slog today, the CMS is almost to the point where we are happy for others to use it. The only thing really very incomplete at present is admin and a couple of add-on modules.
Installation still needs a little more thought, since we currently do a subversion export, encode the PHP for security and then install on the server. There is nothing wrong with this, and a single script that displays a webpage on the server, asks for credentials and then downloads and installs the script automatically might be one solution. Once at that point, it could display options for restoring config and/or importing a sitebackup.
I dislike vendor lock-in. I've been there enough times myself that I just wont do it. While our export XML may be in own own schema, it shouldn't be too complex to decode it even without documentation.