Celeste Soueid

HTML Builder

Summary

• Goal: Reduction of tedium in portfolio editing workflow.
• Languages: C#
• Tech Stack: SSH.Net, HTML Agility Pack
• Notable Achievement: Automated rule based index construction and SFTP deployment.
• Status: Completed (still being improved)

Completed Features

• 'Query' based extraction and insertion between HTML files
• Dependency graph resolution for insertion operations
• Automatic deployment of configurable files to remote SFTP server
• Non-trivial command and parameter parsing

Description

HTML Builder was initially built in a single night to facilitate easier modification of the projects on this website, however I enjoyed working on it and ended up expanding it to be a general CLI utility for rule based combining of HTML files into templates.

Conceptually HTML Builder works like a rule based copy-paste operation from specified file(s) into template files. A more in depth explanation of how exactly it works can be found in the readme in the Github repository.

For some necessary context, this website is a single HTML file dynamically hidden and unhidden with Javascript. Thus all the projects and their information exist within a huge, >1000 line file. Since the project headers (the banners on the previous 'page') and the project body (this 'page') are separated, it also involves a lot of searching back and forth through this file. This made any modification incredibly tedious, and adding new projects even more so.

HTML Builder was a response to that, allowing me to strip the project elements out of the index file and into their own separate files within a folder. Practically this means all data related to a project (and only data related to the project) is stored in its own file, and to edit/add a project all I have to do is open/create the file, then run the `build` command from this utility.

Challenges

HTML Builder is pretty simple in terms of functionality, however the significant amount of user interactivity and branching regarding commands means the architecture/syntax was the primary challenge. This was amplified by the 'functional over legible' approach to the project at its inception. Overall, I'm fairly happy with how the command syntax looks, and I'm reasonably happy with the health of the code base though I'd like to add more XML summary based documentation for future workability.

Future considerations

The repository's readme contains a list of future features I've considered adding, though FTP support and automated deployment is the most immediately appealing for my own usage and is likely something I will implement sooner rather than later. Additionally, I'd like to remove comments from the files prior to output, as they're largely unnecessary when serving the page to viewers.

Media