To main heading

Smallsite Design


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 wouldn't 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 don't 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 leave the structure intact, 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.

  • User interface
  • Picking the philosophy
  • Facilities
  • Contact   
  • Categories   Feed   Site map

  • This site doesn't store cookies or other files on your device when visiting public pages.
    External sites: Open in a new tab or window, and might store cookies or other files on your device. Visit them at your own risk.
    Powered by: Smallsite Design©Patanjali Sokaris