Avid readers of this blog (of which I’m sure there are many, I mean, there are 14 whole posts on here at the time of writing!) will remember that back in 2019 I started solving the Project Euler Problems, I set myself the task of solving 1 problem a week, writing a bit about it, and posting it every Sunday at 3PM without fail.
- First of all, I want to make sure my code works, so automatic compilers for the languages that need compilation. These will also need to be tailored to the platform I happen to be running them on, especially given that back in 2019 I only had a clunky old laptop running Ubuntu. I now still have that same laptop, but also a much newer, smaller, Windows laptop, and now a MacBook from my new job. On the plus side this does now give me all 3 of Linux, MacOS and Windows!
- I wonder if there’s a way to get these running on Android/iOS as well! Maybe save that for another day.
- A tool to turn Markdown posts into nicely-formatted blog posts suitable for WordPress.
- A way to automate their publishing for 3PM each Sunday – this is actually the easy part, just write them ahead of time and set their publish dates accordingly. Then again, who’s to say I won’t decide to alter this?
- A tool to upload my code files into Gists (as well as maintaining the whole thing as a Git repo anyway).
- This one is quite troublesome because at the time of writing my way of making sure a Gist for a given problem and language doesn’t already exist is a bit hit-and-miss.
- A WordPress block to pull down all the Gists relating to the problem being viewed.
- This has the same issue, however, as my Gist-uploading tool above. When I was going through the posts to add the project euler 2019 tag, problem 1 believed I’d only written it in C++ and Java!
- A way to manage and maintain all of this, including making updates where necessary.
- Additional feature: It would be nice to include a D3-based scatter plot of how long each language takes to solve each problem given different input values. This in itself is a huge data collection project, meaning I need to store the language, values, results, time taken and machine specs in a CSV for each problem. The latest version of the design for this can be seen on VizHub, and treat yourself to a screenshot below! This may give some insights beyond just “which languages are faster?” such as “does a particular language work better on a certain machine?”, “how do various language cope with higher inputs?” And so on.
So where to even begin with all this? Well, luckily, I’m writing this partway through getting my system built up, so I already have something of an idea of what to do. One thing I have noticed copied across multiple files (most of this automation is being done in Python) is a duplication of the dictionary containing the language names and file extensions. It would be good to get a comprehensive list of the ones I’ll be working on in a separate file wouldn’t it? Luckily I have found this Gist from Peter Pisarczyk (in turned forked from Aymen Mouelhi) which contains what appears to be just about every programming language ever. I haven’t gone through the whole list but I reckon it’s a fairly safe bet that I haven’t even heard of more than half of them!
This then results in the following
languages.json file – I never knew there were this many file extensions in the known universe!:
At each step I’ll be looking to see what our basic folder structure looks like, so at the moment:
project-euler ├get_working_language_extensions.py └working_language_extensions.json
Now as an example, let’s look at what I want each problem folder to look like:
project-euler ├problem_x │├problem_x_timings.csv // To store the info of how long each problem took to solve, also store the input value, language, and machine specs │├problem_x.c │├problem_x.cpp │├problem_x.java │├problem_x.js │├problem_x.md // To be converted into the relevant blog post │├problem_x.php │├problem_x.py │├problem_x.rs │└problem_x.ts ├get_working_language_extensions.py └working_language_extensions.json
And for completeness and to allow me to make my next post in this series but still chronologically after this (albeit not by much), without leaving this one looking a bit short, here is the full file list (for now at least!) Along with a brief explanation, there will of course be full posts explaining these in due course!
project-euler ├problem_x │├problem_x_timings.csv // To store the info of how long each problem took to solve, also store the input value, language, and machine specs │├problem_x.c │├problem_x.cpp │├problem_x.java │├problem_x.js │├problem_x.md // To be converted into the relevant blog post │├problem_x.php │├problem_x.py │├problem_x.rs │└problem_x.ts ├.gitignore // (obviously!) ├c_functions.c // Functions to be imported into C scripts, not sure yet but this may need to be .h, once I dive properly into C I'll find out! ├cpp_functions.cpp // Functions to be imported into C# scripts ├env_info.json // gitignored as it's machine specific ├file_operations.py // All file-related operations ├file_templates.py // Templates for files in each language, hopefully to prepopulate imports, boilerplate, etc. in each folder ├get_env.py // Run this to creat env_info.json above ├github_config.py // Generated tokens for working with my Gists ├github_credentials.json // gitignored as these are the API keys for github_config to use! ├java_functions.java ├js_functions.js ├languages.json // Renamed from working_language_extensions.json in the code block above ├languages.py // Renamed from get_working_language_extensions.py in the code block above ├mkdirs.py // Create all the directories for each problem, may merge this into file_operations.py ├php_functions.php ├problem_descriptions.json // I created this to allow the chart I'm designing to pull down a subtitle, may change how I do this ├publish_to_wordpress.py ├publish.py // A lot of duplicate code between these two, but the idea is that this automates creating the blog posts ├pyfuncs.py ├README.md ├rust_functions.rs ├ts_functions.ts ├updategists.py // Functions for working with Gists ├wp_config.py // Much like github_config.py but for WordPress └wp_credentials.json // Again, like github_credentials, gitignored as these are keys