What I Did

At the start of the year I said I was going to get into blogging in a big way. I also said 2024 was going to be amazing for everybody. I don’t think either of those things quite worked out as planned, but there’s a couple of days left to salvage something!

I did actually do a very large amount of tinkering. I have handwritten (x) lines of codes (need to write a little script to count) split across (x) number of files (ditto – but we’re talking thousands of lines of code across dozens of pages). There are small kernels of applications developed – about 10 – and I’m actively using bits of some of them. There are obviously many more to go. I attempted to document as I went, but always had the tension of actually doing, verses writing about doing. While I was building I was getting a thrill out of coding, and writing about it sucked the wind out of the sails. By the time I grew disinterested in whatever I was coding (or life got in the way), then I *definitely* didn’t want to write about it.

So what may or may not follow is a bit of a grazing plate of things I’ve worked on. A few demos, a few observations, a few ideas for what comes next. We’ll see how we go.

The Base

The approach I’m taking is to build an Everything App. Well, more of an Everything Platform – more like an online operating system for all of the different pieces of functionality and things I want to build. The intention is to be able to standardise my approaches, and re-use as much as possible. Ideally I’d be refactoring as I went, but I’m not doing that so much. I’ve certainly been re-using elements, and made some common tools.

The hope was as I went I’d be able to figure out some good design practices as I uncovered them from first principles. That’s worked to an extent, but in 2025 I’d like to spend some time reading programming books to really start to explore and unpack good practice that has gone before me. Hands on, learning from first principles is a very strong way to learn, but it’s good to have signposts sometimes and to not have to re-invent the wheel each go. It’s also good to check in to make sure what you’re stumbling upon isn’t actually an ‘anti-pattern’, or ‘bad practice’. There are a couple of those traps I’ve almost walked into, or charged into at full pace.

The Building Blocks

Here is my tech stack – which I think allows me to call myself a baby full-stack developer (a network layer is pending, but I’ve done it before):

• Back end:
  • Python – base back-end language that is the foundation for most other elements. I’m PRETTY GOOD at Python, so am very comfortable working in it
    • Flask – a Python web-framework. It’s often described as a lightweight, ‘non-opinionated’ framework (compared to something like Django), which means it’s pretty barebones. It’s up to you to decide what database you want to use, and it doesn’t really come with templates or content features like user or content management. You have to build it all yourself.
      • Jinja2 – Python-based HTML templating engine.
  • SQL (relational database language)
    • SQLite – a simple, file-based SQL database which does not require a separate server process)
      • SQL Alchemy (core) – a Python package which acts as a non-denominational interface layer to SQL databases. Later I’ll likely want to switch to a more complex database – Postgres seems to be the most in-vogue. Back in my days of PHP apps it was MySQL.
• Front end:
  • HTML (yer content, produced on the fly through Jinja)
  • CSS (yer layout. On an earlier run-through I’d started with Bootstrap as a (dated) CSS framework, but I don’t like how much is obfuscated ‘under the hood’.)
  • JavaScript (vanilla – I very much did not want to use a JS framework or tooling. As I was pretty mediocre writing JS going into it, having learned to code with Python, it was important, again, that I wasn’t hiding anything.)

In all cases, I wanted to get as close to the vanilla languages as possible. This whole exercise has been as much of a learning activity as it has been outcome-driven, so I didn’t want to take shortcuts. In the past when I’ve tried different frameworks I’ve found they provide a false sense of progress; it’s all good following the tutorial, but as soon as you want to go off script and change something, or something goes wrong and you need to debug, it’s VERY difficult to figure out how to address it, as you don’t know how it works under the hood. I’ve had far more success building from basics. The other problem is you’re dealing with multiple layers of abstraction – so if you don’t even learn what’s under the hood, and you don’t know what layer your problem is.

SQL Alchemy is a really good example of that. There are two ‘modes’ – Core, and ORM (Object Relational Management.) ORM is a higher level abstraction, intended to give you advanced features. However, in the past I’ve had real difficulty learning SQL, and so mixing generic SQL, with the Pythonic syntax of core SQL Alchemy, and then the abstracted ORM layer on that just makes it a jumbled mess. It also makes it super difficult to follow instructions and answers on blogs and Stack Exchange, because they all use different syntax, and it’s rarely clear to a beginner at what level they’re operating (and thus how to adapt to your own situation.)

Whenever possible, I’m going to use the lowest level language possible, avoid frameworks, and build up my knowledge from scratch. I might use frameworks later, but I’m much more likely to invent my own (which I’ve been doing to a not insignificant extent).

The one exception is anything to do with security. I am PETRIFIED, virtually to the point of inaction, about cybersecurity and introducing vulnerabilities to my applications. It’s the reason everything I do is local, to date. I’ve done some adjacent work with cybersecurity teams on identity management, and I follow a lot of infosec practitioners and circles online. I think paranoia is a very healthy step for cybersecurity, and it will be one of the big challenges to tackle in 2025. I want to understand what’s happening with my security, but I also want to delegate this as much to experts as anything else. Patching and staying up-to-date with releases will be the main tool there, but it’s not something I’m really across now and have the luxury of not having to just yet. But you have to leave the safety of the nest at some point.

The other toolset worth mentioning are my coding environments:

• Editor:
  • PyCharm – an excellent IDE, with fantastic highlighting, suggestions, syntax and such. I’m probably only using 15% of its capabilities, but it’s very intuitive. I’m using the free Community edition, but my hope is that one day I’ll have *enough* of an income coming through this sort of work to justify subscribing to the Professional edition. Unlike the Professional edition, the Community edition doesn’t have explicit support for Flask, or HTML/CSS/JS, but it’s enough to get by.
  • MS VisualStudio – in the early days I was using Atom to edit JS files, though that got discontinued by Facebook. I switched to VisualStudio, which I’m sure could do Python and most of the low-level functionality I’m using Python for, but I’m very mistrustful of Microsoft, and don’t want to put all my eggs in one giant behemoth’s basket. I don’t think that’s healthy for programming in general (and see the enshittification of virtually everything big and medium tech does), so there’s a little act of resistance in not relying on it fully. In the first few months of the year I was writing a lot of JS code in it to take advantage of syntax highlighting and debugging, but as I’ve got more confident with JS I’ve been coding directly (and copying and pasting from my own work) in PyCharm WITHOUT JS support, which kinda feels like progress. Training wheels off, trapeze without the net etc.

***

That was the starting point. It’s been a year. Let’s look at some of those pieces in more depth, and what I’ve built out of it.

First thing’s first – my platform is built with the Python framework Flask. This was the fourth or fifth time I’ve built a local Flask app, having learned it by following Miguel Arteta’s incredibly brilliant Flask Megatutorial. I’ve always got the first couple of pages open when I set something up, basically copying and pasting a cookie cutter starting point. I don’t find all the elements of Flask *totally* intuitive (some of it was unfamiliarity with servers, some of it was design choices), but as I’ve gone on I’ve been able to figure out a lot more about the inner workings (which has also helped with understanding browser-side server interactions). I’ve managed to do a lot of insecure things with Flask! I can get a new, barebone Flask app up in about 15 minutes based on Miguel’s instructions, and ignoring most of the security pieces.

It looks something like:

• Create virtual environment (managed with PyCharm)
• Set a couple of environment variables so that I can launch the thing, and theoretically, for encryption (though I’m not really doing that yet)
• Specify a SQLite database to be created
• Create a space for

For a database I’ve gone with SQLite. Unfortunately, SQLite has a few major limitations that I was not immediately aware of, mostly to do with modifying tables (columns, names, types, constraints etc.) after they’ve been created. This problem was compounded by my use of SQL Alchemy. More on that to follow.

***

So there we are. A description heavy update, fairly dry and technical, but I wanted to get something up. Eventually I’d like to be sharing screenshots and demos, it’s just about developing the right workflows and habits.

2024! Wild.