Goals of site

  • What I would like readers to gain from this is ::
    • Potential Employers to be able to see my software writing ability.
    • The idle and curious to learn about project management and software architectures.
    • Where relevant, access to various HTML widgets I have built and discarded. From the basis of this as a platform, these widgets are content rather than features.
  • What I want from this is ::
    • The ability to remove irrelevant projects + details from my CV for specific jobs. A dynamic website is fundamentally a better platform for demonstrating such things than a static CV.
    • A show case + more experience in PHP5. EDIT: now PHP7
    • A modular platform for various different rendering formats, AJAX and jQuery for example.
    • Testing ground for doing UTF-8 and poly-lingual texts properly. This is the internet. I used not to favour multi-byte char systems on the basis nearly everything I wrote wasn't human readable, or was to be read by mono-lingual English people. Today the entire platform (internal logging through to JS error messages) supports UTF-8, and being able to use typographical glyths is nice. I am in the process of adding extra languages for the entire site.

Design structures and concepts

All the code and effort in this site which you can't see, and is quite difficult to see; is what I am most proud of. This can easily be used as a base for future websites, secondarily to the fact I intend to re-skin it. This can be ported to any web host which supports PHP5 and my other dependences, with minimal effort (would need to build a directory structure and redo a config file.). This can be said of many sites, but I have put some of the features you may not normally need into this platform, in the name of thematic clarity. You are currently reading via the minimal HTML4 skin, which has no JS and virtually no styling. When I have finished adding basic features like page footers, I will fork a more dynamic skin.
2013: The reach skin is built, but I'm now improving this with usability features.

When building this, my first requirement was a stable modular platform, and to offload some words from my over-crowded CV. I now have the extendible rendering platform I have wanted since I started doing HTML in 2000 for my first dissertation.

The platform as a project is documented, the resource you are reading is focused on business rather than technology. As a quick comparison between my site and similar sites, read this. The designers skin is more complicated, and has lower information density.

User-friendly URLs

URLs are how people access websites, they get sent in emails, texts, read out over the phone. Quite a few URLs are really unfriendly, in practical terms, you have to click “next” inside the website to be able to view the resource. Most websites are not private media, but public displays, and so should be made to be shared. I think complex URLs are poor SEO - if they are too complex the search engine is likely to record them wrongly - and it is definitely poor experience when referencing the site.
URLs should be human readable - made out of words - to clarify can you say the URL out loud? Human language is big enough for anything humans can express.
To follow on this idea, it is not the end-users concern or problem how you built the site. They are aware that most URLS end 'HTML' or 'HTM', but what does that mean? Why does the Microsoft site always end 'ASP' not 'PHP' like news sites? Car designers mostly hide irrelevant information, so should web designers.

Separation of content and presentation.

I do not know anyone who argues that there is greater efficiency in merging these two. As is standard, I have flat unadorned data storage and separate rendering tools. In this case, I may swap the renderers to make things look different.

Standards Compliance.

Standards allow different people, tools, organisations to communicate. The standard of English for example. Public standards are good for systems, as they encourage commitment from a large number of people, and are frequently moderated by a large consensus.
Everything I write is tested with tidy, or the w3c standards tools.

Tiny URL support.

In 2002, someone started a webservice called tiny-url, to encode users longer URLs as a shorter redirect request. The short form may be distributed without needing to worry about reformatting. There have been other services since then, but this remains a useful feature for managing URLs.

I have created a similar feature for my longer references. This site name is a fairly descriptive URL, so a little long for tiny-URLs, but supports the feature. This feature is easy to create via mod_rewrite.

Technologies used in this site

  1. PHP5
    1. Why? I have plenty of experience in OO PHP4, which is clumsy; I am attempting to provide evidence for a broader skill-set.
    2. Primary source here
    3. Language spec and design : although there is no proper spec, this is the manual or this discussion
  2. LAMP
    1. Why? In the authors opinion, this is a stupid question. Linux is a cheap high performance, highly configurable server platform. Apache is a cheap high performance, highly configurable web server and MySQL is a cheap high performance dB. What other options are there?
    2. Download via your normal administration or primary source here
    3. Update 2013: aside from nginx obviously...
  3. minimal skin in HTML4
    1. Why? Will almost run on your coffee machine, its pandemic. I wanted a default that would just work. On completion of initial work will probably never be used outside of debugging.
    2. Primary source
  4. Template engines
    1. There isn't enough time to hand type HTML. Not my time, not your time, not that kids time. Certainly not including branding. It is common in software engineering to measure complexity, and every-time software gets too complex, add a layer of abstraction.
    2. See following sections as they get added.
  5. Wiki, Pear Text_Wiki
    1. This is an open source Wiki library, which my host has installed. Please note this isn't a page hosting environment, this is a rendering library. The basic page system built on top of this is plain and reliable.
    2. Primary source here
  6. mod_rewrite
    1. Whilst this does have a performance cost, I still think this is an important feature for ease of use. There are currently two features using this module friendly URLs and Tiny URL.
    2. Language usage
    3. Download via your normal administration or seperately
  7. w3c validators
    1. Not actually part of this site, but to demonstrate I value accessibility and standards.
    2. The w3c CSS site The w3c xHTML site
  8. SMTP support
    1. This is not a webmail client, this is library support for sending “contact me” emails. Its a feature, not a central asset.
    2. Librarified access for the in-page handlers, configured from common site-config.
    3. 2013: In the recent extensions I added switftmailer
  9. Intelligent use of JS, jQuery etc;
    1. Fairly industry standard. I wish to have the JS as attached libraries, not essential features. The platform should run without any JS;
  10. Search
    1. I will import a search class/bundle. Search is best managed by decent search facilities like Google, so this will be referencing external items;
  11. Front end tweaks/hints ~ not part of iceline. A collection of extra features to make the resultant site easier to use.
  12. ... moar!!!! ...

Planned features

I would not feel happy about other parties having copies of this source in its current incomplete form. Where I have no current use of a planned feature, I have saved time and not implemented it;

  • Add more attractive renderers, please see reach-skin ;
  • Add more content;
  • Ensure file_mime is kept up to date;
  • The above three are permanent for this website;
  • DONE Fill-in empty keyword slots in the content (see the tag-cloud for discusion on this );
  • Consider re-factoring PageResource, current goals/ responsibilities are abit muddled;
  • Add more of my planning notes (with better English) to this site;
  • DONE Add support for further resource types, i.e. JSON responses, XML/RSS responses;
  • Implement authenticate as soon as there is need for it;
  • Extend minimal_html4->get_validate to have behaviour dependant on current state;
  • Re-factor minimal_html4->do_get with respect to branching on $request['md'];
  • Prohibit possible message loop in Log->debug (when possible);
  • ValidationFilter->register_formats should be a merge not a blanket overwrite of formats;
  • When you are logged in, apply “your” interface choices;
  • Rebuild and complete the use of CSS in this interface, document all CSS classes;
  • Only use 'db' in the request for certain user profiles;
  • Consider if anything needs to happen for BinaryResource->exec_validate();
  • See if render can be made an object;
  • DONE Contact me mail form (requires the mail object, a page with a form, complete POST handling);
  • 50% DONE Think about the licensing page again;
  • DONE When necessary, implement the “nextpage state machine”. for POSTS;
  • Create debug GUI widgets;
  • HTML5, NOTAFAULT Find out exactly what those error messages mean in “xhtml strict” mode in w3c tools;
  • Think about authoring the content texts for another language. Code support is present;
  • Add format specific file returns for NonexecutableBinary, to allow selection of media formats (i.e. return the best/most recent media option the webclient says it supports by reading the HTTP headers in the GET request);
  • Expand and complete the documentation;
  • Identification;
  • As soon as there is authentication, move some of the things on my local machine to here;

Test cases

To make things cleaner, I have moved this section to the code documentation.