A similar section gets added at the bottom when the end of the array has been reached. This allows the reader to jump to the next or previous article of the same type as the one being read. This is done using the same technique as is used to generate the lists of articles but it only uses those that fall immediately before or after the current article in the sorted array. This also directs the reader back to the list of articles of that type. Facebook taught me that you've gotta keep users on the site for them sweet, sweet page views (although I'm not sure how I'm going to monatize those...).

Miscellaneous Pages

Some pages of the site are fairly stand-alone. They have all had as many elements as possible abstracted away to remove code duplication and to make it easy to replicate the same behaviours elsewhere but, in general, much of that has not been used elsewhere, nor is there a very automated way of replicating behaviour like exists for the articles and list pages. That said, each has something interesting to discuss.

The Homepage

A homepage of almost any website is a special case. It's meant to provide easy and clear access to the information visitors might actually want without cluttering the page with much of that information directly. As such this is the only page that currently uses the "banner" code, regardless of my having made the code as modular as possible. It otherwise just provides links to things that seem sensible to highlight. Those blocks load in much the same way as the articles where each is an element of an associative array which is looped through. However this is the only place where that particular text block formatting is used.

One kind of neat thing on the homepage is the weather data. This is only useful to folks in Ottawa, but I actually use it directly or indirectly on a daily basis. All of the data is sourced using Darksky.net's API which allows for 1000 free calls per day, enough to update the data every 5 minutes. I have a simple shell script that fetches the data and translates it into another PHP associative array using standard UNIX utilities. It requires the API key as an arguments, but can then easily be run as a cronjob. The basic data is provided in a reasonably compact "widget" and the more complex data is hidden until various parts of the visible blocks are clicked. My Magic Mirror project actually fetches the same data file from the website in order to provide me with my current weather and the forecast information discussed next.

Forecast

The "weather-data.php" file that is generated by the DarkSky script actually has a lot more data than what is displayed on the homepage, so I gave that data it's own page. Even then, darksky provides 50 hourly forecasts and I only use 7 (spaced in 3 hour increments), so as not to be overwhelming. The content is extremely standard and predictable, so I basically just copy and pasted the current weather code and made some small changes for the daily reports, like adding a neat-o phases-of-the-moon widget entirely with CSS.

Resume

The resume actually hails back to an earlier website that I made years ago called johnsdesk.ca. That site was cutesy, gaudy and a horribly skeuomorphic representation of what my desk might actually look like. To my chagrine Archive.org did save just enough of it to make it look even worse than it really was. When it was live, each of the images had an "active" alternative which replaced it and they all lead to pages that were similarly atrocious in their own ways. Remember, I said I was the runner-up to that web development job... It ways basically the "Microsoft Bob" of websites except uglier and even more useless. That said, I mostly kept the fundimental design of the resume page.

I rewrote the functionality of that page and it is now set on a tame grey instead of woodgrain, but the "dosier" concept with the headshot and tabs is still the same. It did actually get me to a second interview, so it can't be too horrible, right? Functionally, the main content used to load with an iframe which made the "paper" scroll independently of the actual webpage; so that's better now. One thing I do want to add to this is a URL argument with a unique id for the coverletter. That way there is default content page for anyone who finds it in the menu, but I could email a link to a potential employer with a coverletter specifically for them. If I get itchy feet this might become a priority, until then it's just a thought.

Currently a URL argument is used to determine which tab of the resume is active (with the absence of one meaning the coverletter). The contents for each tab are pretty much defined independently. Given that it will never exceed more than a few pages and the coverletter is always a special case, it doesn't make a huge amount of sense to bother abstracting away anything other than the stylesheet and tabbed paging.

Easter Eggs

I pointed out earlier in the explanation of the domain name that you can click the domain name or logo in the header to explain the fact that the domain matches my name if searched as a regular expression. I also described in the article discussion that there are a couple of other architectural components that are not prominently exposed, but which can alter the user experience. These are some that are provided by URL arguments:

• I described the "offset=X" argument in the the Table of Contents and Pagination sections as the mechanism used to determine where to start rendering. You can select any section you want and it's mostly going to work, correct something out of bounds or print an error.
• *new* Offsets can now be referenced by the heading. For example to the Easter Eggs heading.
• A similar feature that you wouldn't stumble accross accidentally is the "items=X" argument. This will display an alternate quantity of sections from that offset. Using '*' will show everything.
• Articles also necessarily have a "topic=X" argument which tells the system which article directory to grab content from. Because only articles with a meta.php file will get loaded into the article lists, it is actually possible to find "unpublished" or "hidden" articles if you know their topic identifier. An example of this is the "About Me" article that is linked from the home page, but not otherwise listed.
• There is also a "debug=1" option that is currently understood, but has little utility. It is required for some error messages that I use during development, but otherwise any possible errors that I have written debugging for should pretty much be wiped out by the time it gets to production. There are also errors that don't require the debug argument. For instance, try to define an offset or items argument that is not an integer and it will yell at you.
• If you hit an error page, for example a 404 you get a random fullscreen image from the Horsetheif Canyon, AB gallery. It provides the error and lets you dismiss all of the window-dressing to see just the image (and a little X to get the window-dressing back).
• Support for users in Australia

To Be Continued...

The site is relatively stable, so development has slowed but it is still ongoing. Updates are pushed to the site quickly when written, but you can also view the develpment branch of the site by specifying the 'dev' subdomain (this version of the site has new features, but the content is not updated there). Some things I'm thinking about adding are:

• Accept an offset equal to the section heading text. Determine the offset to that heading automatically. This would allow for easier linking to relevant content that will remain accurate if the index of that section changes.
• Dark Mode. At the moment, the tricky part with this is persistence across pages. I refuse to use cookies, so I would need to implement this into URI requests which means that every single link would need to have an argument appended. Certain links are manually written into pages, so I'd need a function to feed all imported content through a re-write function and pass all static content there as well before writing. Setting up appropriate css classes and overriding their attributes is easy enough, but time consuming.
• Duplicate "items=*" for list pages. Currently this only works for articles (but I don't have enough to hit the page limit yet anyways).
• Add tags to articles so that the reader can find "similar" topics. Add tag filtering to the list.php pages.
• For "offset=" greater than the number of elements in the array, correct to the total number minus the item count (or 0).
• More debugging code! Included the output in a block at the bottom or top rather than in-line
• Add a "lang=" url argument. I'm currently working to improve my French and translating the site might help build that skill. My French is still too bad to confidently add that. I also gave a decent effort to learning Esperanto and might translate things to that if I get really bored. This would require a separate "meta.php" and "content.php" file but other than that it would not be terribly difficult to select which file to load, fallback to English if necessary and suggest alternate languages on pages that provide it. This would probably be done by adding a language box to the left of the footer (similar darkmode), with a pop-up for available languages.
• The initial revision of this site was written almost entirely in JavaScript (Proof) including a lot of wizz-bang flashy stuff. I do as much processing as possible server-side to reduce page sizes and so most of the JS got chopped out, except for this single file and a couple of things in-line). One flashy thing I did kind of like in moderation was weather effects to the home page. Now that there is a dedicated forecast page, I might add those back there. At the time I had effects for cloud, fog, sun, snow and rain.
• Optimize formatting in Firefox Reader View (I don't care about whatever browser you use).
• Create a unified internal linking function. Currently the handling of url arguments, variable sanitization and so on are sloppy and done all over the place. I need to make a function that takes the current page and the target, then have it do all of the sanity checking, cleaning and copying of persistent arguments (theme, and lang). Have shortcuts for links that only modify a single url argument (eg. theme, offset, items)
• Redirect non-existent "topic" to either applicable topic list with an error instead of to 404.
• Make 'tag' persistent into the body of the article and when moving back to that category's list.php page. This way the user will not need to refilter. Also modify the article switcher to suggest only articles with the same tag.
• Add a "break" option for the content arrays and a "manual" option in meta.php. When breaks are set to manual, display all sections until a manual page break is requested. This would allow for more flexible segmentation of articles into sections. A default number is sort of silly. Pagination in general is silly, I just thought it would be fun to engineer.