Useful Tools
Creating software is a time consuming business, and it’s important to always be on the lookout for ways to reduce the amount of time spent on less important tasks. The process of actually building software (creating the finished distributable binary) is one such area that can be optimised. Opening up your IDE and hitting “compile” might not seem particularly time consuming, but it’s only one part of the build process.
To get you started, here’s a short list of tasks that can be automated:
- Compiling the executables and dependent libraries
- Packing media
- Creating an installer
- Uploading files to an FTP site
- Checking out files from a repository to be built
- Sending an email about a finished build to other developers
- Creating the application documentation / Converting it to HTML
- Testing the software
The benefits of using an automated build system include:
- Saves time – Run a build and leave the computer to do the work whilst you take care of other tasks.
- Documents the build process – If a build requires several steps before being completed, a build file will document this process for you. This is useful if templates need to be generated or options need to be set before a build is ready.
- Improves quality – As well as automating the creation of a binary package, tests can be automated. This saves a lot of time on the development end, as tests can be constantly run so you’ll quickly find out if the software’s behaviour has changed.
Simple Automation – Batch Files
The simplest way to automate many of these tasks is to use batch files. A batch file is a list of tasks to be run, usually in the form of a list of applications with some command line parameters. Using a few simple commands it’s possible to run many tasks in succession without any user input, leaving you to do more important things. Microsoft.com has a is a simple guide to batch files which is a good place to start.
As useful as batch files are, there is only so much they can accomplish, and there may come a time when something more complex is required for your project. Thankfully there are many build systems available
Build Tools
There are plenty of build systems available, and several of them are targeted at certain platforms or languages. It may take a while to become comfortable with a platform, but the savings are worth it.
- GNU make – A standard system used by many Linux projects. It consists of a plain text file that lists targets and dependencies, and features many advanced features such as automatically determining which files require rebuilding.
- Apache Ant – Ant is designed as a replacement for make, and uses XML files to describe the build process instead of text files. It’s written in JAVA, and is completely portable.
- nAnt – nAnt is a .NET based version of Ant, and although it is not exclusively for .NET developers it has many features that make it useful for building .NET apps.
- A-A-P – A-A-P is a portable build tool that uses text-based “recipes” to compile and distribute software, but it can also be used for other tasks such as publishing websites and generating files from templates.
- Visual Build Professional – VBP is a commercial build tool that takes a more visual approach to creating build scripts. It integrates well into many Microsoft IDEs, but also supports other languages such as Delphi and Java.
- BlitzBuild – A free build tool aimed at BlitzPlus and Blitz3D developers.
Breaking the Task Down
Most build scripts will contain more than a single command, so it is useful to break the build script into different groups or “targets” that can be executed individually. This is particularly useful if building of data files is included, as it can be used for art or music to be built independently of the main application. Many build platforms also allow targets to be called from other targets, which effectively breaks a build script into a set of functions that can be executed in any order.
Common targets include compilation, installation and cleanup, but the choice is entirely up to the developer. It may also prove beneficial to include a separate target for generating debug versions of the application which can be distributed as a troubleshooting option.
Related posts:
Subversion is an open-source version control system. That doesn’t sound particularly interesting, and at face value it isn’t, but you only need it to save your skin once to realise how useful it can be.
Version control is a method of storing different revisions of the same file, usually source code or documents. This allows developers to see when changes to a file have been made, which can be useful for isolating bugs, and can also be used to “roll-back” a file to a time before a bug was introduced.
Along with these features, version control allows developers to merge two versions of a file, which is very useful for projects with more than one person.
This article covers the following:
- What software you need
- Creating a new repository
- How to set up a Subversion server
- Adding password protection to a Subversion repository
- Laying out your repository and importing files
- Checking out and checking in
- Using tags and branches
What you’ll need
Subversion – The primary download is source code, but there are binary versions available for different operating systems, including Windows, Mac OS and most common flavours of Linux.
If you intend to use Subversion mostly from the command line, you might want to add the Subversion binaries directory to your Windows PATH variable.
Optional Downloads
TortoiseSVN – If you’re using Subversion with Windows, I highly recommend installing TortoiseSVN. It integrates with the Windows explorer shell, so you can see an icon if a file has been changed. You can and also check in items, commit changes and perform other common operations with a few clicks of the mouse instead of using the command line.
Pages: 1 2 3
Related posts:
I use the “Sociable” WordPress plugin to add social bookmarking links to the bottom of every post. There are a tonne of social bookmarking sites around, so I’ve kept things light to avoid the icon overload that can be seen on some blogs. I’ve made two updates over the last few days, one was adding devbump and the other was adding CSS image rollovers.
If you’re not sure about adding a few bookmarking buttons, you might want to check out the traffic increase at webloghits.com. That’s the kind of increase that is worth a few minutes of your time.
Adding devbump.com
There are a lot of digg style sites out there, but devbump caught my eye because it’s aimed squarely at game developers. Submitting your posts to places that are actually interested in the subject is always more useful, so devbump was a natural choice.
To add new sites to sociable, open up “sociable.php” and find the following line:
$sociable_builtin_known_sites = Array(
Once you’d found it, add the following after the “Del.irio.us” definition:
'devbump' => Array(
'favicon' => 'devbump.png',
'url' => 'http://devbump.com/submit.php?url=PERMALINK&title=TITLE',
),
You’ll have rebuild the list of available sites by logging in to your blog, and selecting “Restore Built-in Defaults” from the sociable page (Options -> Sociable). “devbump” should now be available to use on your site.
Adding CSS image rollovers
Now for the fun part. I used some code from Present Tense (Hacking the Sociable WordPress Plugin for Image Rollovers), but it didn’t quite hit the spot so I did quite a lot of tweaking to get things looking nice. I’ve stuck it all in a zip at the end of this post.
Before you skip ahead to the freebies, there are a few important things to note.
Tweaked “sociable.php” — I made two main tweaks to sociable.php. One was because some sites have “.” characters in their name, so it wouldn’t work with CSS class names. The other tweak was to change the way that the HTML was generated. Instead of standard images, it’s a list.
Internet Explorer — Naturally IE messes things up a little bit, so you might have to experiment a little bit to get things looking the way you want them. Removing the CSS tooltip may help.
16 x 16 Images — I like to have text next to my images, so each one has a different width. If you open “sociable.css”, you’ll see I’ve defined each networking site with a pair of definitions:
.sociable li.delicious a { width: 69px; background-image: url(images/delicious-hover.gif)}
.sociable li.delicious a:hover { background-position: 0 -16px;}
If you’re using 16 x 16 images, you can move the width statement into the “.sociable li” definition.
Adding New Rollovers
To add a new image, you need to add a class with the name of the site, and then set its image. It’s really just a matter of copying an existing class definition and changing the names. I’ll add new sites as time goes on, but at the moment I’ve only defined: del.icio.us, digg, devbump, Reddit and Furl.
Free Stuff!
Everyone likes free stuff, so I’ve zipped up all of the files I modified for your downloading pleasure. There are still a few bugs to iron out, so I’ll be modifying this post as and when things change.
To install the changes, just copy the files into your “wp-content/plugins/sociable” directory — you’ll need to have sociable already installed (download here).
Related posts:
I’ve looked at a lot of bug trackers over the years, and I even had a crack at writing my own as part of my final year university project. It was certainly an experience, and it taught me the value of “eating your own dog food”.
There are hundreds of bug trackers in the wild, and they range in quality and functionality. Some are in-depth packages that really ease the process and were clearly designed with developers in mind. Others are not so good.
With so much choice available, it’s good to look at the pros and cons of various systems. It’s also important to make a list of your requirements, and as indies we often have a different set of criteria from larger companies.
Why Bother?
There are plenty of reasons to use a dedicated issue tracker:
- Organisation — Problems with the software are recorded in a central place, so you don’t have to worry about losing that post-it note with an issue’s details scrawled on it.
- Transparency — Although it can seem counter-intuitive, letting your potential customers see your bug database can have a positive effect because it lets them see that you’re actively fixing problems. It also lets them know that there’s a place they can send problems, and that they’ll be dealt with efficiently and not swept under the rug.
- Distributed Teams — If there are several developers involved with a project, having a central system where tasks are assigned is a Good Thing. It saves multiple people solving the same problem, and helps to share the workload.
- Documenting the Process — You know what was fixed, when it was fixed and who fixed it. In some systems, you can also find out where the problem occurred in the source code and use this information to improve the quality of code.
- Feedback and Support – Some systems also allow users to submit feature requests as well as support queries. Again, this helps with keeping things organised and preventing things from getting lost.
Do Indies Have Different Requirements?
Everyone has their own set of requirements, but as a general rule indie developers will not have the same requirements as a larger company. For a start, we’ll want it to be as cheap as possible! Thankfully there are a lot of open-source projects available that will run on most web servers.
My List of Requirements
I’ve put together my own list of requirements for an issue tracker. They’re by no means a definitive list, but they’re a good starting point for your own list.
Minimum Requirements:
- Easy to Use — Not everyone is technically minded, and I want the system to be accessible by as many people as possible.
- Support for Multiple Projects — I want something that can manage several projects, as it will be a central place for all my work.
- Access Levels For Projects, Issues And Fields — Although transparency is good, I still want a certain level of privacy with issues. The ability to set projects as private is important, as they might be WIP or not ready to be announced.
- Anonymous Viewing — I don’t want people to have to register just to view the list of bugs.
Nice Extras:
- Templates — I’d like the bug database to fit in with the rest of the site. If templates aren’t available, it should at least have a clean interface.
- Web Service API — An API is nice so that applications can submit their bug reports. This can be kludged if not available, but it’s nice if it’s built in.
- Project Overviews — I’d like to see overviews of projects, either with graphs or just a configurable list.
- Subversion Integration — As mentioned in my previous post, I use Subversion to track changes in my projects. I’d like a bug tracker that integrates with SVN so I can see what files were changed to fix an issue.
What Solutions Are Available?
Here are some of the better solutions I’ve looked at. I can’t really do them justice in a few paragraphs, and most issue trackers have the same core features so I’ve tried to pick out some of their more interesting aspects.
Eventum is an issue tracker from the MySQL team. Features include support for multiple projects, web-based and command line interfaces, and full CVS integration (Subversion integration is available at the Eventum Wiki). It also features XML-RPC and SOAP web services, as well as an IRC Bot which looks useful for distributed teams.
Mantis is an open-source, PHP/MySQL based bug tracker. It’s simple and lightweight, but is designed to be easily extendable for people who want a little bit more. If you’re not after anything complex, Mantis is a good place to start.
A very slick looking, open-source issue tracker. It supports attachments for issues, as well as multiple products, editions and milestones. You can also set it up to email you whenever an issue is posted. It’s very customisable, and you can alter the built in help as well as alter the appearance using themes.
A feature packed, highly extendable piece of kit. The search features in particular are worth noting, as searches can be saved, shared and subscribed to. It can be extended to integrate with source control, and it features XML-RPC, SOAP and REST web service interfaces.
A comprehensive bug tracker, tailored toward making the workflow as smooth as possible. Issues are always assigned to a single person, and this person becomes responsible for fixing the problem (or delegating it). The interface is very clean and clearly tailored towards ease of use.
One particularly nice feature is its ability to add customer emails directly to the system. For example, a customer email to “support@example.com” can be automatically entered into the system and become a new case. This case can then be assigned appropriately. The customer also receives an email with their case number, allowing them to see exactly what’s going on.
OnTime features a web-based interface, as well as Windows and Visual Studio clients. It can be integrated with several source control systems, including Subversion and Perforce. You can also define and use your own workflow, such as XP or Scrum.
There’s Plenty More…
Most of the issue trackers listed have demos that you can play around with to get a feel for the software, and I recommend trying a few out before settling down. I’ve tried several of the ones listed, and I’ve still found it hard to pick one. Although any system is better than none, it’s still important to choose one that “feels” right.
I’m always interested to see what other developers use for issue tracking, whether it’s a pen and paper, an Access database or something more complex. Feel free to let me know what you’re using, and why.
Related posts:
As I’ve previously mentioned, software development is divided into two very distinct parts. The fun part that everyone loves, and the tedious bits that suck away your energy.
You can think of it like an iceberg. There’s the top that everyone sees, where penguins frolic and hold parties. Then there’s the sub-surface part. A dark and dreary place that people try to ignore. You can thank that part for the sinking of the titanic.
Today I’ll be talking about the 90% you wish wasn’t there. Sorry about that.
It’s not all boring!
OK, so maybe it is, but if you’re a programmer you’ll know there’s a certain satisfaction you can only get by automating some part of the development process. As Steve McConnell puts it in “Code Complete“, if a programmer can do a job comfortably in five hours, or spend four hours and 45 minutes writing a tool to do it in 15 minutes, they’ll choose to write the tool every time.
My tools directory is littered with quick, one off scripts I’ve written to get a job done, or other small applications I’ve downloaded. Today we’ll be taking a brief look at my setup.
The IDE
The language I use most frequently is Blitz Plus, so my development environment is tuned to making me more productive in it. My IDE of choice is Protean, which became a free product earlier this year.
The main reason I chose Protean was the excellent code completion support, as well as the project support. These two features alone have probably saved me hours worth of work. The standard Blitz IDE is a little clumsy for larger projects, and it was quite a hindrance.
I keep the Windows taskbar auto-minimised on the left of the screen. This helps when I have several windows open, and also maximises the amount of space the IDE gets. It’s not a huge gain, but every little helps.
I also like the colour green.
Plenty O’Tools
My tools directory contains dozens of applications, ranging in size and complexity. There are far too many to list in detail here, so I’ll stick to the ones I use most often.
- PHP – I use PHP for a lot of “glue” scripts, because it’s quite easy to knock up a simple script to do something useful. My original build scripts were written in PHP, but I’m slowly migrating them to BlitzBuild. I’ve used PHP for all kinds of things, from generating code distributions to parsing source files for variables. I considered using Python for these tasks, but I felt more comfortable using PHP. It’s not just for websites!
- pngcrush – A simple tool to compress png files a little further. Not really essential, but I’m still stuck in “this has to fit on a floppy” world so every saved byte counts.
- ResHacker - Blitz doesn’t add much information to executables, so I use ResHacker to add a fancy exe icon, as well as resource information. It can be used from the command line, so it’s part of my post-build script.
- Subversion – I run a Subversion server on another machine, and it’s saved my bacon on several occasions. I use TortoiseSVN for the front end, because it makes life so much simpler.
- xsltproc - I’ve recently started using DocBook for documentation, and I use xsltproc to convert it into something pretty. I prefer running it on Linux, as it seems to run much faster.
- Kate – I use this for editing DocBook XML files, and it supports code completion and code folding. I sometimes dabble with XXE for DocBook work, but I find it to be overkill for most of the documents I work on.
Putting It All Together
As powerful as these tools are on their own, they really shine when joined together in a build script. At the moment, my Blitz projects have three batch files: “pre-build”, “post-build” and “build-resources”. The pre-build script is for auto-generating source files, and the post-build script takes care of adding resources to the exe and compressing it. The resource builder compresses sounds and graphics, processes any extra files (such as XML files that need converting) and creates all of the data files.
In the future, I want to move all of this into a single BlitzBuild script, as I feel the three batch files are a weak link in the build chain. I’d much rather run a single command and have the whole process work automatically, than run different batch files. I also want to add support for different configurations. This will allow for quick builds that don’t create resources, as well as special debug builds that add extra information to the exe.
What tools do you use in your development process? Do you have any novel uses for existing tools? What single application saves you the most development time?
Related posts:
