Here’s one for the NERDS 🤓 Or rather, for both computer nerds and for nerds who don’t understand anything about computers, but who get frustrated that they don’t understand and would like to try to understand a little bit at least.

It’s looking like the whole process of setting up my suite of personal websites is going to end up clocking in at approximately one year. If I’m remembering correctly, I began in June or July of last year, at what Germans might refer to as the “Fundaments”. When I’m explaining to my mum, and to other friends who don’t have any concept of the technologies used in building a website, I simply compare it to the construction of a house or indeed a larger commercial building.

I’m not especially knowledgeable about the economics of the construction business, but I suppose that after purchasing the land it begins with digging and building the foundations. The foundations of a website are in a directory (AKA folder) called /var/www. If you’re using Windows, it can be some other place, but really you dooooooooooooon’t want to be using Windows to do this. I do use Windows myself, for most of my other work, and I’m quite virulently anti-Apple, but the development of these sites has been happening on a Linux virtual machine (VM) hosted on my Windows PC. Of course I realise that I’ve freaked out non-technical readers with that sentence. Too bad. To attempt to explain what that means, a virtual machine is just an emulation of a computer which runs “inside” your physical computer. So you could have a Windows or a Linux VM on a Mac, a Windows VM on a Linux machine, and vice versa. It used to be popular to try to set up Mac PCs, so-called Hackintoshes, and that means that it should also theoretically be possible to set up a Mac VM, but from what I understand Apple have been progressively making it more and more difficult to do that over the last few years, because they’re incurable control freaks. And that (in answer to friends who own iPhones, and who don’t understand why I don’t) is the reason that I haven’t owned anything made by Apple for more than ten years.

OK, so you go to /var/www on your Linux system, and you create a directory for the site that you want to work on. And then you need to decide on your server software. What’s that????? OK, I’ll try to explain: the server software is just the way that you prepare the files in your website to be sent to the client’s computer. One possible analogy, which works quite well for me at least, is to think of the server as akin to the kitchen of a restaurant, including the ovens, the cooks and the waiters who bring the content to the user’s screen. Kind of, anyway! Of course these metaphors are only metaphors, and the nuts and bolts aren’t like that at all, but you non-tech people don’t need to care about that. As far as I know (which may not be everything!) there are three widely used names in server software. These are Apache, Nginx and Lighttpd (pronounced “lighty”). I haven’t used the last of those three yet, not because I don’t think it’s any good, but simply because my journey has taken me down the path of using the first two. Apache is the one name that you non-techs might have heard, as I think it’s been around since the start, and possibly comes up in non-tech places from time to time. But I’m in fact primarily using Nginx at this point. This decision was taken on advice from people on forums that Nginx is a very fast and efficient server. Apache, by contrast, is more powerful and becomes necessary when your website turns into a behemoth involving large databases, but for what you gain in power you have to sacrifice by slowing things down a bit. I’m not at that point yet, for sure, and so Nginx is the sweet spot for me.

It took me a couple of months to learn properly how to set up websites with Nginx and/or Apache (you can use them in tandem). It was quite a mad process, because it was mainly conducted in interaction with ChatGPT, which sends you down so many cul-de-sacs before it gets you to the right place. I’m afraid that I’ve rather given up on forums for this purpose, firstly because you never know whether anyone’s going to reply at all, but more importantly because forums can unfortunately be a bit of a hang-out for trolls. Not the kind of angry incoherent trolls that you meet on every single Facebook group, but rather the type of troll who wants to make you feel stupid and who will tend to pick up on an irrelevant detail in your post in order to demonstrate his (ALMOST CERTAINLY “HIS”!!!!) superiority. I have a very good example for you here - scroll down to find the comments of SamuelCalifornia 😡😠 I have actually seen much more impolite comments. It’s quite common to ask a question somewhere, and be told “This is a very bad question”. Bloody hell - the correct response would be to say that you need to clarify a few things in the question, in order to make it easier to answer. I asked a question on StackOverflow, which appears to have been deleted (nice!), where I got a fair bit of abuse. Apart from one guy telling me that my question was awful, another one told me that combining Nginx and Apache was a really bad setup, despite the fact that I had already seen plenty of sources recommending the combination. And that’s why I don’t really bother much with forums any more. The AI may be maddening at times, and may spin off in multiple misunderstandings, but the one thing that it doesn’t do is to become rude, even when you, the user, are getting a bit rude yourself as you vent your frustration at finding yourself down the nth dead-end.

My setup now allows me to automatically create the barebones (or maybe let’s just stick with the word “foundations”) of a site by means of a script that creates all the Nginx and/or Apache settings, as well as the other necessary bits and pieces. What other individual bits and pieces are those? Well, that takes me onto the next stage of the process. This blog, like the other one, uses Hugo to generate all the content which you are looking at right now. What is Hugo, then?

Some readers may be familiar with the concept of a content management system (CMS). If you’re not, let’s go with the building analogy again - imagine a magic house which is completely flat-packed, but which turns into a fully functioning structure when you inflate it with air. The engine inside the CMS is what does that. To be precise, the data for the website is stored in a database (think of that as the flat-packed structure), and a computer language like PHP or Ruby is what does the magic to make the house stand up in three dimensions. The CMS which even the least tech-savvy should have heard of is Wordpress. I very quickly excluded Wordpress from the list of platforms that I would end up using for my websites. It has faaaaaaaaaaaar too many limitations. Other lesser known (but better!) CMSes are Joomla and Drupal. I’m likely to be using Joomla at the very end of this process, as I’ll need to create a little shop to sell my design stuff, and my research tells me that Joomla is going to be the best choice for that. Besides the aforementioned, I did actually work for a couple of years in the past on another CMS called ModX, which I believe to have fallen away into total obscurity by now. That was when I was managing websites for the Green Party of England and Wales - a thankless task, I can assure you. It’s not a lot of fun working for an organisation that is run by committees of people with little or no idea of what your job entails. Of course they’re well intentioned, most of them at least, but absolutely useless when it comes to supporting their own workers (ironically enough for a party that is meant to be based on humanist principles). That job didn’t last too long, and life took me down a completely different path for the following decade, but the experience was valuable nonetheless. Although I’ve obviously had a lot of catching up to do, I didn’t have to start completely from scratch. I’ll conclude this paragraph by coming back around to Hugo. Is Hugo a CMS? No, it is not. Its “job” is the same as a CMS, to create a whole interlinked website, but the architecture is different.

There’s no database underpinning the generation of the pages in Hugo, and that’s fundamental to the definition of a CMS. Therefore Hugo (along with a whole load of similar systems whose names do not currently come to mind) is known as a static site generator (SSG). In Hugo you create a new post or page in the form of a markdown (.md) file, and once you’ve finished with that you run Hugo’s rendering algorithm, which then generates the html file in the place that you want it to be. I hope that vaguely makes sense. I can’t think of a kitchen analogy, sorry. Maybe I could say that the markdown file is like the contents of a packet of soup, and the rendering engine is the water. Other analogies will be available, however.

“What’s the advantage?” you may ask, of an SSG versus a CMS. The answer is that with an SSG you’re generating permanent HTML addresses, which will remain in the databases of Google and other search engines. And why is that a good thing? Permanent addresses help with the SEO (search engine optimisation) of your site, and a CMS site won’t give you that.

Learning Hugo took me another couple of months. Starting with a short interaction on the Hugo forum which ended fairly quickly, thanks to yet another wiseguy control freak who objected to the wording of one of my questions. Bloody hell - if you don’t get the wording right it’s normally because you don’t understand things yet. Just try to understand the intention behind the wording, for heaven’s sake, instead of being a nob. Hugo isn’t straightforward to learn, for sure, even if you’re used to using a CMS, because the setup is very different. However, if you have used a CMS, you’re already used to the idea that you need to set up the header, the sidebar, the footer, and whatever other stand-alone elements of the pages in separate parts of the DB, while the content of each individual article, page or post is kept in its own place. The concept is exactly the same in Hugo, but the implementation is rather different, based on a different computer language from most CMSes and so there’s quite a lot of technical shit to learn if you want to do fancy tricks with it.

The best way to learn anything tech-related is of course to figure out how to apply it to your own projects. I had a blog, which I started early on in 2024 on Blogger/Blogspot, in the wake of the Israeli-Palestinian conflict blowing up once again in the media (even though it never went away, of course). Here’s the original blog, on Blogger, and here’s what I created myself, with Hugo. Not difficult to say which of them looks better. As soon as I tried to adapt the Blogger site to my own design, I very quickly hit upon limitations. What’s more, it’s owned by Google, so of course everything on there probably belongs to them. No thank you.

This process of adapting the Middle East film blog was going on mainly between September and November of last year. Along with learning Hugo, I also of course needed to catch up with the last ten/fifteen years of developments in CSS (cascading style sheets). Once again, for the non-tech uninitiated people, CSS is the way that you organise the elements, and paint the canvas of a webpage. HTML (hypertext markup language) is the content. Or rather, if we pursue the restaurant metaphor one last time, HTML is the food, and the CSS is the layout of the tables, the colour of the decorations, the tablecloths and the crockery and cutlery.

In order to catch up, I’ve been following Jonas Schmedtman’s courses on Udemy, starting with this one. I’m currently in the final few lectures of his second course on some more advanced CSS concepts. Find that one here. I have to comment that the advanced course is a bit top-heavy, in the sense that a lot of the content in the second half has already been taught in the previous course, but in my case that came more as a source of relief than of resentment. I’ve enjoyed the learning journey, and of course I know that this journey will never end, but my energy has definitely been flagging in the last few weeks. And so it’s quite satisfying to know that I can pretty much breeze through the second half of the advanced course. I’m sure that there are plenty more advanced CSS concepts which I still need to learn, but really… it’s more than enough for now. Next up, I’ll have to finish ploughing through Jonas’ JavaScript course, and at some point in the future I’ll have a go at learning a bit of React. Restaurant analogies for that another time. My Covid headache prevents me thinking of that. I’ll be excited to learn to use React, but I really will need a bit of a rest first.

Before moving onto updating the reader on where I am right now in the process, I do unfortunately need to make a comment on Jonas’ advanced course which doesn’t have anything at all with the quality of his teaching, which is very good indeed - no complaints about that. Obviously I don’t know Jonas personally, but the impression that I get of him from the many hours that I’ve now spent listening to him is that he’s a pretty sweet guy. He seems to love what he does, and seems like someone who wouldn’t hurt a fly. However, he does something really unfortunate in this course. While talking the students through a couple of the design projects, and thinking out loud about how to fix certain problems, he comes up with temporary fixes to the issues. And then….. it’s not Jonas’ fault that he was born in Germany….. but this is bad….. he says three times “this isn’t the final solution” 🥴😬 Three times is at least the number of times that I’ve noticed it. And it’s hard not to, when you hear it in a German accent. Even if it’s not a German accent, I believe that it sounds bad to anyone with the faintest historical sensitivities. Now, I just want to clarify that the German word for that is completely different. They called it “die Endlösung”, and so Jonas is (I hope!!!) completely unaware of the connotation of that term when he says it in English, but really…… someone should gently tell him. A severe edit is required.

Not to say that Jonas’ courses are not otherwise great, and I’m really really sure that he would be pretty upset to know that anyone might think he wouldn’t be mortified at the notion that he endorses the policies of the Third Reich.

Bringing things right up to date, users will notice that the design of this blog is essentially the same as the Middle East Film Festival. I just moved the CSS across, altered the header and the colours, plus of course removed elements from the sidebar and elsewhere which were specific to the other site. As stated in my welcome message, I may yet make changes to the design of this blog, but I think I have enough on my plate for the time being. I guess I had this blog more or less ready to go by mid-February. That’s what the date of the first post suggests, at least, but of course it is possible that I was still making stylistic changes after that date. I can’t precisely remember any more, but let’s say that by the end of Feb I had moved onto creating the landing page for the whole suite of my sites. I’m pretty proud of it, even though I do believe that there may still be a few glitches with it in some browsers. I hope not too many, but I might have to come back to it at some point. The rotating links and wonky titles were created with the inspiration of one of Jonas’ projects, so I want to give him a bit of credit there. I really love the effect. That’s not me blowing my own trumpet, honestly. I just love it! And all the friends that I’ve shown it to so far have agreed about that. There is a little bit of Javascript involved. It was necessary to ensure that the animations would work consistently on iPhones. But that’s only at the very basic functional level, and it’s pretty much pure CSS. Not bad. It’s come on a lot since I first tried to learn it twenty-odd years ago.

The completion of the landing page takes us up to approximately two weeks ago. In the last two weeks I’ve started thinking about the remaining sites in the project. Initially, in the desire to get everything set up as fast as possible, I thought that I could somehow quickly adapt the design of the two blogs, but it didn’t take very long to realise that that idea wasn’t going to fly. Especially for a site dedicated to my epoxy designs, as well as highlighting my web design skills, it has to look a bit more fancy than that. And so, if you are reading this at approximately the time of publishing, you will find something that looks pretty different, on your PC at least. Adapting the design to phones and tablets will take a couple of weeks, I think, because I do also want to move on as soon as possible to creating an attractive desktop version for the teaching site. It doesn’t need to look as fancy as a design-related site, I suppose. The fonts will be much more classical, and the layout much more functional, but OK…. let’s see…. the fun of the design process is watching the way things change as you go along. The same principles apply for the proofreading site, which will follow the teaching, but of course a site relating to podcasting could look quite a lot different again. That design process is as yet only in the back of my head, but I’m looking forward to foregrounding it and getting past 90% done with all this. I deserve it.