A look back

Published on 2021-07-17 13:54

Two weeks ago I spoke with Jessica Rose about my career and that conversation made me look at things that made me happy. Some of them are part of my day job, most of them are from side projects.

The main purpose of this post is figuring out how much I downplay my skills and abilities. There's also a plan to go into detail in separate posts in case where non-disclosure agreement don't apply.

Sloth

Let's start with a side project, codename Sloth. It's named by the animal as it was an expectation that the development will be slow and after three years it's safe to say that the development is slow.

The purpose of this project was to replace Wordpress on my blog because Automattic didn't execute launch of Gutenberg without alienating some people in Wordpress community. It's probably safe to say that I am the only one who took it this far. Since September 2020 my blog runs on Sloth.

It took me so long because of my desire to learn and deployment was for a long time a secondary objective. Let's look at some sub-projects.

Toes extension of HTML

Writing a compiler was one of the things on my technical problems bucket list. Language design not so much. Also making things that would end up in a drawer never to be seen again is not my thing.

Fortunately for me most template languages are similar to JSP. The first version of Toes belong to that family as well but used specific beginning <# and ending tags #>. That was when Sloth was in PHP.

After switching to Python because to my knowledge it supported threads better I encountered ThymeLeaf which makes more sense to me as there's very little context switching between HTML/XML and template language.

Work on Toes started by setting up tags and attributes. From loops, if and working with variables, there was an evolution to things like conditional attributes and inserting content into elements.

<toe:fragment>
  <div toe:content="This will be displayed" ></div>
</toe:fragment>

Markdown compiler

Full-fledged parser and compiler for Toes felt at the beginning as a too big bone to chew on. Markdown as a static text felt more manageable.

First version was a mistake. Regular expressions are usually my strong side. This time it was an encounter with a wall. It taught me to write more comprehensive unit tests and that one can't parse everything with them.

Second iteration has a proper parser which analyzes the whole text and transforms it into a tree structure.

Toes compiler

The first version of Toes compiler is about three years old by now. As mentioned before it was in PHP7. It didn't stick for reasons mentioned above.

Second version followed the regex parser of my Markdown parser. After trying hard to make it work and multiple fails to parser the code properly I made a decision to write a better parser for both.

Current Toes compiler utilizes a proper parser which creates nodes.

Analytics dashboard

Everybody loves gathering data except people who are interested in privacy, lawyers and those who are swamped by it. On this blog there was no plan to use Matomo or Google Analytics because they didn't felt needed.

Nevertheless there's an analytics script when a page loads and sends a request to the API.

In the first stage it was important to see page views and most visited pages. Page views to know if anyone is visiting and most visited pages to satisfy my curiosity.

Third thing to track became a browser and the browser version. Those two are important in case I want to use a feature in my theme that might not be supported.

Latest addition is referrer because one of most visited pages is quite old. It's not implemented visually yet since not enough data was recorded.

Localization

One of the biggest reasons for me to leave Wordpress behind was the lack of localization. Not the localization of Wordpress itself but having several language versions of my blog. There are solutions for Wordpress and after trying several of them I gave up.

After giving it a try myself simple workflow for multilingual blogs is hard. My best shot is to write blog post in one language and then create a post that is automatically linked in another language.

Also generating static files requires a bit more caution because it's easy to get stuck in an infinite loop.

Post editor

With localization comes translation process in an editor. My old process meant copying the whole post and pasting it to VS Code, translating all paragraphs and copying everything back. The issue is my translation skills aren't that good, it's better than word-for-word translation.

So plan was to create a web component, either VanillaJS or in JS framework. Angular is too big for this. React doesn't have a good documentation for non-SPA cases. Vue.js on the other has documented way how to compile everything to web component, unfortunately it didn't feel that it's that advantageous compared to VanillaJS.

The biggest issue was passing data to the component, both with Vue.js and VanillaJS. First solution was to encode it in data:json,. It didn't work out as expected because of multiple quotations encoding.

So the second solution to passing data is dumping JSON to JavaScript and letting setter in the web component deal with it.

Post editor

Libraries, hooks and endpoints

I am a developer and one of my wants is to be able to add code examples and their results on my website. The issue with Wordpress is that I don't have control over included scripts. Ex. Wordpress tends (tended) to include jQuery.

For including libraries there was a need for hooks where to include them. At the moment there are two places, head and footer.

Third thing in related section are endpoints. It's great to be able to consume other people's APIs. As posts get older things change, to keep examples working there's a need to store the data frozen in time. So for that reason there's a special endpoint in the CMS which serves data.

Replacement application

On this project I was the front-end lead. Our task was to replace an old application because the client wanted to change a service provider. Client's people loved it.

The hardest part of my role was to keep in check my Java developer colleagues when they wrote HTML and CSS. Please, don't ever assume that a back-end developer will be good on front-end and vice versa.

Second hardest part was coping with uncertainty of the scope. There are decisions for smaller and bigger applications. One can either make small application overly complicated or has to do refactoring while scaling up. At that time I made a choice to go with a smaller application.

Mock data generator for developers and testers

This task wasn't the one I started but it was one that I finished. The client was (still is) a start up and people moved between teams quickly.

The problem was that testers needed mock data so they could start each test session without weird data. At the time we were split into two agile teams working on one product. My team was working on a new features and there was a decision that mock data will be part of it (my task). A colleague on the other team was working on this task originally.

In the middle of the sprint said colleague was transferred to another team, so I picked up and finished both of our tasks.

Getting into Rust

This is about not giving up. There is a plan for both compilers to be re-written into Rust in the future for performance reason. For now I am learning it so I can work with embedded stuff at a hobby level.

Working with Rust requires quite different mindset compared to languages mentioned so far.