flypig.co.uk

Today I made a big step forwards in improving this website. For 14 years the site has run on an MS Access and ASP backend. Yes, that's ASP, not ASP.NET, which wasn't an option when I wrote the code. There were multiple reasons for me choosing ASP, but one of them was that — given the backing of Microsoft — it looked to have better long-term prospects than the open-source underdog PHP. Now I'm in the situation where I want to move the site over to a Linux server (primarily so I can get it TLS-enabled) and so it needs to be re-written in somethig that will run properly on Linux.

In order to minimise my effort, that means re-writing it in PHP. My prediction that ultimately ASP would prevail over PHP didn't quite pan out as I expected. But that's no bad thing. I'm not a fan of PHP particularly, but I'm even less a fan of ASP.

The conversion isn't just a matter of re-writing the ASP in PHP. I also need to convert the database from MS Access to MySQML. For this I've written a simple python script that will do a complete transfer automatically. It's great because I can run it at any time to do the transfer, which is important given the site will continue to get updates (like this one) right until the switch finally happens.

Today's achievement was to finally get the site running using PHP. It's weird to see exactly the same pages popping out of completely different code running on completely different stacks. There remain a bunch of backend changes I still need to make (probably I'm no more than 20% of the way through), but this at least proves that the conversion is not only feasible, but seamlessly so.
 
To my relief, the re-writing of the code from ASP to PHP has been surprisingly straightfoward as well. Some of the key similarities:

1. The structuring is very similar; almost identical. Code is interwoven into HTML, executed on request in a linear way, the resulting text output is the page the requester sees.
2. Database access is using SQL, so no big changes there.
3. Javascript and PHP are both curly-bracket-heavy, dynamically-typed, imperative languages.
4. ASP and PHP both include files in a similar way, which should allow the file structures to remain identical.

In fact, the structure of the two codebases is so similar that it's been practically a line-by-line conversion.
 
There are nevertheless some important differences, some of which you can see in the screenshot above.

1. The most obvious visual difference is that all PHP variables must be prefixd with a $ symbol, whereas javascript variable can just use pretty much any alphanumeric identifier.
2. PHP concatenates strings using the . symbol, whereas Javascript uses the + symbol. This might seem like a minor change, but string concatenation is bread-and-butter site generation functionality, so it comes up a lot.
3. Many Javascript types, including strings, are classes which come with their own bunch of methods. In contrast PHP seems to prefer everything to be passed as function parameters. For example: string.substring(start, end) vs. substr($string, $start, $length).
4. PHP regex literatls are given as strings, whereas in Javascript they have their own special syntax.
5. Javascript has this nice Date class, whereas PHP seems happier relying on integer timestamps.
6. Variable scoping seem to be different. This caused me the biggest pain, since ASP is more liberal, meaning with PHP more effort is needed passing variables around.

In practice, none of these changes are really that bad and I was able to convert my codebase with almost no thought. It just required going through and methodically fixing each of lines in sequence. Most of it could have been automated fairly easily even.

However, as I go through converting the code I'm continually noticing both small and big ways to improve the design. Tighter SQL statements, clearer structuring, streamlining variable usage, better function structure, improved data encapsulation and so on. But in the first instance I'm sticking to this line-by-line conversion. Once it's up and running, I can think about refactoring and refining.

It feels like I'm making good progress on my plan to change the site. I was hoping to get it done by the end of January, and right now that's not looking out-of-the-question.

In Finland I live in a small flat, so spend more time in close proximity to my washing machine than I'd really like. But as the drum spun up to create its highest pitched whine this morning while I was cleaning my teeth, the speed of it impressed me.
 
So I wondered: if it were a vehicle, how fast would it be travelling? It shouldn't be too hard to calculate with the information available. What are the pieces needed? The radius of the drum and the angular velocity should be enough.

For the angular velocity we just need to check out the technical specs from the manual. That was easy as I already carry a copy around with me on my phone to help me figure out which programme to use.
 
Today I was running a 30°C Cotton wash, which spins at 1200 rpm.
$$
1200 {\rm\ rpm} = \frac{1200 \times 2 \pi}{60 {\rm\ s}} = 40 \pi {\rm\ radian} {\rm\ s}^{-1}
$$
There's nothing in the manual about the drum size, so I reverted to a tape measure.
 
So that's a diameter of 47cm, or a radius of 0.235m. That's the inside of the drum of course, but that is the bit the clothes have to deal with.

This gives us a linear velocity of
$$
40 \pi \times 0.235 = 20.5 {\rm\ m}{\rm s}^{-1} = 106.3 {\rm\ kph} = 66.1 {\rm\ mph}.
$$

So if my washing machine were an electric car, it'd be zipping along at nearly the speed limit. That's surprisingly nippy!

 

Fourteen years ago I wrote the code that powers this site. Until that time I'd used only static pages using a pre-generated templating system that were then uploaded to the site via FTP. As the site expanded and web technologies progressed, it was clear I needed to have something more structured, with content stored in a database and pages generated using server-side code. At the time I was trenchantly anti-Microsoft, but I also realised it's unfair to criticise something you don't understand. Microsoft's development technologies were in the ascendant and also seemed to be a better long-term bet than the open source alternatives. So I consciously chose ASP over PHP. Fourteen years later, even though that original ASP code has done pretty well, with the benefit of hindsight I can say with some confidence that I backed the wrong horse.
 
So you could say it's been a somewhat extended evaluation period, but I've finally decided it's time to re-write the site in PHP. This will allow me to migrate to a Linux server, giving me more control and flexibility, but more importantly it'll also allow me to deploy a TLS certificate for the site (it's perfectly possible to deploy a cert on an IIS server of course, but this is a thing with my hosting provider).

To help motivate me, while I'm not usually a fan of New Year's Resolutions, this year I'm making an exception. In 2020 I've decided that this will be my first resolution: to re-write this site's code in PHP. All of the content will remain and if all goes well no-one except me will notice any difference. Maybe astute visitors will notice a padlock.

Since I'm already setting myself up for failure, I figure I may as well stick a few more items on the list too. So, in 2020, here's are some other things I plan to achieve.

2. Reduce my daily waste output to below 300g. In the last four months of 2019 it was 329g a day, 81% of which was recycled. In 2020 I want to reduce this to less than 300g waste per day. I'd prefer to decrease waste than increase recycling. I've no idea how I'll do it yet, and the year has started disastrously already, so we'll see. I'd also like to be carbon neutral, but I've not even calculated my current carbon footprint, so maybe that'd be getting ahead of myself.
3. Scintillon is the Philips Hue app I developed and maintain for Sailfish OS phones. After having used it last year to control the lights in my flat, it's now ready for a bit of refinement. I often find myself having to switch between different pages in the app in order to control my lights the way I want, so I think it'd be a good improvement to support some extra configurability to allow users to design their own interface the way they want. I just need to carve out the time to design and implement it.
4. I'm learning Finnish but it's difficult and I'm slow. So I need to focus. My sister generously gave me a subscription to FinnishPod101 for Christmas and now I just need to commit to using it. My aim is to spend at least 30 minutes a day learning Finnish, topping up my Finnish classes using the site.

I have so many more projects and plans lined up, like my ideas to create a gesture-based programming language or to extend the concept of a Celtic knot to n-dimensional space. But if it's taken me 14 years to write this website, I may have to leave some of those till 2021.