Categories
Open Source PHP Technology Web Development

Professional Development – Part 1 – Using a Wiki for Documentation

This will be the first in a series* of articles on web applications development – not the specifics about programming, but more tips on the infrastructure and processes that can make life easier, more productive, successful and better aligned with best practises. Its based on my experiences of being in development teams and leading development teams.

I see these articles as being useful to a development team thats growing from a 1 or 2 man operation to a larger team and is perhaps using Open Source development tools such as PHP/PERL/Python and perhaps aren’t in a very processes driven environment…

Documentation

Most developers won’t generally document their work as a matter of course – either they simply forget, overlook it or its just not that exciting for them. So 3 things:

  • Illustrate the value of documentation
  • Build it into the development process
  • Make it exciting (oh okay you can never make documentation that exciting – so lets settle for a bit more interesting!)

Illustrating the value – most developers are already sold on documentation being a generally good idea but others aren’t. Some fear that by documenting they loose control over the project or the work that they primarily work on (in fact the reality is that is the opposite…) or they just really don’t see the point. Highlight the facts that it enables team work, improves quality, makes support and changes easier etc. Also that holding all the knowledge up in your head means that you are stuck in your current role as its not easy to bring others in to do what you do so you can be promoted.

Another great benefit is inducting new team members – it allows you to point new team members at the wiki site to help them get up to speed quickly – and you can also use that process to fill in any gaps in the documentation (and get the new start to include their tips and findings as they learn the ropes…

Build it into the development process – obviously you need to have a development process if you haven’t got one but once you have it just becomes part of the steps:

  • Requirements Gathering – document
  • Spec/design – document
  • Build/development – document

So ensure that documents are required for each step in the process – and make time for that documention. The nice thing is that documentation is a lot easier if done throughout the project life cycle rather than all at the end (then it is just really daunting) – as generally what you plan to do is what gets delivered (and if things deviate from the spec during development you can just adjust it)…

Make it more interesting – its more that just that in reality as its picking a documentation tool that supports the above points and works for the team. For me development documentation seems to works well with an internal/Intranet Wiki (something like MediaWiki for example). The main benefits (over office docs for example) it allows easy collaboration, allows for a geographically disbursed team and is generally nicer than using word processing software. It’s made more interesting by feeling very “Web 2.0” (as much as I hate the phrase!) and has some great tracking features – like the recently edited articles page. Once the team have seen the advantages and you bore you colleagues to death with “the W word” then you’ll find that you have a healthy wiki site and documentation, documentation, documentation (with any luck with minimal pain!)

Categorising the Wiki – here are some ideas on some categories that work:

  • Projects – Pages under here relate to discrete projects the team is working on
  • Infrastructure – documentation on the dev, staging and production server environments (eg Server configs, IP addresses, SLA details)
  • Process – Reference guide to the development and other IT processes so the team can refer to them and also make contributions and feedback on what is working.
  • Meeting Notes – Agendas and minutes for meetings – if you get this right then these allow for team communications when needed (rather than at forced meeting dates) and are links to other pages on the Wiki where the full details of a proposal or a project is available.

Blogging

Another option (which has some other positive side effects including marketing) is blogging about development projects – and this is something I am considering for my current team. The Wiki will be for the more technical and internal documentation aspects and the blog for what the project actually does. The added benefit of the blog is that it can do some link / SEO stuff for your projects and raise the profile of the development work that your team is doing to a wider audience. This is particularly useful if you develop an Intranet system for your company – where you are adding new features or enhancements over time.

To make MediaWiki easier to use (for those who aren’t familar with the syntax used on Wikipedia) we enabled a WYSIWYG editor – FCKEditor. There is a whole range of great Wiki software out there if you don’t like the look of MediaWiki – just do a Google or have a look at wikimatrix.

The next articles will more than likely be about:

  • Project Management tools (eg FogBugz) –
  • Development Meetings and Communication
  • Using a Framework (eg Zend Framework)

… watch this space!

*I don’t know how many there will be yet but if they are received well then heck there might be as many as 3 or 4!

Categories
Technology Web Development

Don’t jump into coding – spec it out first…

Joel Spolsky has a great post on his blog at the moment -part of it reads:

“Now, there are various ways to get in trouble. If you don’t like writing functional specifications or doing up-front design, what happens is that you’re burdening the design phase with the development phase. If you ever started a new project by writing code, and you thought you’d “design as you went along,” what you’re doing is driving around with the handbrakes on. Here’s why. Designing a feature by writing a thoughtful spec takes about 1/10th as much time as writing the code for that feature—or less. If you try to code as you design, then you’re interrupting your short spurts of design with long spurts of coding. Now, if you’re the kind of person who designs everything perfectly the first time, that’s fine. But I don’t think you are. I think that your first designs are pretty good, but when you see them, you get ideas for even better designs. And if you already coded up the first draft, bad design, well, that’s coding time wasted. Your product’s design can only get better at 1/10th the speed that my product’s design can.”

I couldn’t agree more with the above, yet so often web systems are developed by coding after just talking to someone about an idea or “go off and do that will you” (that being a sketch on the back of a beer mat). Its refreshing that I am currently writing a specification for a web system (for the first time in what feels like ages)…

Joel on Software is one of the sites I visit on a regular basis – its very informative on software development issues and often very funny – give it a read sometime.

Categories
PHP Web Development

Firebug – a Web Development Inspector/Debugger for Firefox

If there is one tool that has revolutionised how I develop (or more specifially investigate/re-engineer and analyse) web sites and applications its got to be Firebug: http://www.getfirebug.com/

Its great for those situations when you come across a site and think – how did they do that?! Clicking on the firebug utility (a green tick in the bottom right of firefox – once you’ve enabled it) and getting it to inspect the page soon reveals all!

Firebug Screenshot 1

Its also really handy for CSS – borders and spacing are visually displayed:

Firebug - DOM view

Recently I found a great little video on debugging AJAX applications with Firebug and the Zend Debugger which looks really useful. The Zend Debugger is another great PHP development tool which works really well if you have the Zend Studio IDE – when I find some more time I may well blog about that too!

Update – I discovered Yslow today – http://developer.yahoo.com/yslow/ – a plugin for Firebug that gives tips on Web site performance – pretty nifty.

Categories
Ubuntu Web Development

Ubuntu (7.04) on HP Proliant DL385 G2 Server

2 word summary = Works well! -Here’s a picture of one of the boxes I got in for work recently:

HP Proliant DL385 Server

Thought I’d share a few notes…

Firstly these don’t appear to ship with Optical drives as standard as (after talking to my friend who works at HP) most large customers use network based deployment systems to install the OS.

Not an issue though – just get hold of a USB CD or DVD drive to do the install from. Once I got hold of one of those everything just worked. RAID (using very flashy 2.5″ SAS drives), Ethernet everything – so thought I’d document that as when I ordered not much came up on a Google search for this specific model. And is working well after 3 months of use as a LAMP and SVN server.

Currently we are using 2 in my dev team – one for Wiki and SVN and another to host our LAMP Development work on a central box – Apache 2.2, MySQL 5.0 and PHP 5.2 – having a central development box really helps when working together (I will write an article on that in due course!).

The iLO feature on these boxes is quite cool too – for those of you that don’t know iLO (Integrated Lights out) is basically a mini server inside the server that has its own Ethernet network connection – you can use a web based interface to boot, reboot or even install an Operating System – if you have the relevant HP software). Very handy – particularly when the server isn’t in the same area as you!

At 7city we ordered IBM xSeries servers for LAMP use but those generally needed a little bit of fiddling to work on Linux (an X336 required a Kernel parameter so it would shutdown/reboot properly) none of that needed with these HPs – they just work – very impressed.