4  Tools

Having established the technologies, next is what tools to develop them with.

I prefer to be modest in the amount of base complexity I want in the technology I develop with. I prefer that I can develop my own work process rather than have the tools dictate how I am to do things. As a philosophy, this may seem at odds with designing a product that does dictate a lot of how users can use it. The answer is simple, as they are for different preferences, just like people visiting a site built with the product would not want to deal with the type of complexity and information density present in the management pages.

At the time I started developing the product, MS Expression Web was free, and very basic, so I have used it ever since. I developed a program to process the source files into versions for each page type, zip them up, and upload to the server. Another program unzips the files for a particular site. Very simple, but essential for handling the complexity of developing in unified master files and splitting them up so they can be optimised for each page type.

Typically in Windows, these utility programs would be done with VB, but having been confused in the past when using multiple different programming languages concurrently, like often using the wrong variable assignment syntax, I decided to use JavaScript as I had to use it for pages anyway. The UI strings are in Excel, but invoke VBA routines in it for processing into the UI XML files for the JavaScript upload program.

This arrangement meant that for most of the development time, I could make a change in a file, process it and the others, upload them, and install them for the development site in less than a minute. This meant for new functionality, I could iterably add the storage structure, build the UI, and design the PHP handing the changes to be made, mostly within a day. Rather than fix bugs in batches, for each I can iterate to test each tweak of them. I do not have regression testing, so making changes in such small increments minimises the risk of unwanted side effects getting through.

Certainly, if this was a team effort with different people working of different parts, regression testing would be essential. I would like it, but it would be a monumental effort at this stage with marginal benefit. Fortunately, I have several in-use, but not mission-critical, sites that are constantly updated so I get to know pretty quickly if any bugs get through. Having unified master source files means any corrections to a bug occurring on one page will fix it for all pages that use the same block of code.

I believe that files interpreted at runtime should be as concise as possible. To this end, I type in lines without unnecessary whitespace, and use minimum-length names. Instead, I use copious comments with what each line and name is for. The upload program strips out the comments and line feeds using regexes. I chose this rather than minify programs, as I could not trust them to not mess with the structure, as I have seen some online ones aggressively do so, even changing names.

Such rearrangements can make it difficult to debug as runtime error messages may not refer to the precise source location. It also adds risk from bugs within the minifier programs themselves. By keeping the workflow simple and using my own simple processes, I minimise the chance of introducing bugs I cannot correct.

Testing needs to be done across several browsers, and while testing for Chrome, Edge and Firefox is easy on Windows, Safari was the problem. Fortunately, rather than having to buy an expensive iPhone, the iPod Touch ran Safari and was several times cheaper. It worked well for checking until Apple pulled the plug on iOS support for the model 5, so I had to sell it. Unfortunately, at that time they were downgrading their interest in the iPod, given that everyone was basically using their phones for everything by that time. The newer models were also much more expensive.

However, I think that while it would not be a huge seller, there is a market for solitary web developers – that are not Apple-bound – to have a way of testing sites more cheaply, and a iPod-like device would provide a testing facility for Safari compatibility.

I know Apple has targeted so-called creatives with their hardware, so many have opted for Apple hardware when making hardware purchases for creating media-based applications. However, I was put off being reliant upon single hardware+software source companies when we were just about to purchase eMagic's Logic DAW software to do my spouse's CD with when Apple purchased eMagic and immediately announced they were discontinuing the PC version within months, and proclaiming that users either had to switch to Apple hardware or buy other software.

Fortunately, we had not got around to purchasing a DAW yet, but the two musicians we engaged were caught out. At the time, I was doing technical writing for clients who used Windows, so we went for Cubase instead so we could stay using Windows. The forums there were full of people who had been caught out by Apple, but instead of directing their anger at them, they incessantly complained about why Cubase did not work like Logic. I am not an OS fanatic, as I spend most of my time in programs, but such walling-off practices is what is getting Apple charged by the feds and many states in the US.