Showing posts with label blogging. Show all posts
Showing posts with label blogging. Show all posts

Tuesday, 3 March 2026

Ten Years of GitHub Usage

There was a time I shuttled code between the workplace to home, in the most comically retro manner possible - via email. I would be fiddling with some stuff at home, think it would be interesting to use in a workplace project, and send it to my work email account. And at work, if I didn't feel like leaving my code in the workplace and wanted to continue over the weekend, I would send it to my personal email. As the frequency of this increased, it soon became untenable. I actually only really started a GitHub account almost a full two years after starting this blog.

It's been ten years since. I looked at the heatmaps generated from my activity, and there were some interesting patterns. Really took me back. I realize that just going by the number of commits is a poor metric. Almost as poor as the number of lines of code for measuring code quality. But we've all got to start somewhere...

1. 2016 (46 commits)

At this time, I had just set up my GitHub account the previous year. The line chart of my contributions could be charitably described as "tentative".


Looking at the heatmap of my activity, the word that comes to mind is "sporadic". I used it a couple times a month, each time to commit a bunch of stuff.


Looks pitiful, eh? Basically I was just feeling my way around. Getting comfortable with the interface. There were even months where I had no activity whatsoever.

2. 2017 (96 commits)

The second year wasn't that much better, at least in terms of consistency. There were still a couple months where I failed to register any activity.


The line chart shows a marked improvement over the previous year. Though, to be fair, it's hard to do worse.


However, in the months where I did do shit, there was an uptick. Instead of a couple commits here and there, I was starting to register double digits on a semi-regular basis. This was definitely an improvement. Much of this could be attributed to me coding more ambitious projects. Projects that couldn't just be finished in a couple hours, and had to be periodically saved.

3. 2018 (179 commits)

This was the year one could practically see me shifting into third gear. There were no months where I neglected GitHub. More and more months were registering double digit commits. At the highest point at the end of the year, I even registered 50 commits. Compared to what I do consistently today, this is nothing. But it marked a start of something.


The trend line shows that I was still finding my feet, though some months were better than others. I was struggling for consistency as far as GitHub usage was concerned. This was at least partly due to me being busy studying for my ACTA.


Room for improvement? Definitely. But I was still using GitHub pretty much like a layperson. I used it to store code and not much else. I wasn't using GitHub anywhere close to its full potential.

4. 2019 (138 commits)

Things dropped off slightly in 2019. I suspect a lot of it was due to adjusting to my first year of being married and all. (Yeah, way to blame the wife, dude.)


My GitHub contribution was a jagged line. I would be a GitHub hero for a couple of months, then almost a zero the next month.


And in October, I even registered an entire month without a commit. This might have been due to the impending dominion of COVID-19. Suddenly we were all distracted by this potential life-or-death issue.

But for sure, my use of GitHub was still going strong, just not as strong as the previous year.

5. 2020 (286 commits)

This is where it started to get interesting. Some months, my usage climbed sharply, and plummeted just as quickly the next few months.

If you look at the heatmap below, it almost mirrors the line chart - periods of increased activity punctuated by periods of low activity. If there was any consolation, there were less fluctuations than the previous year.


This was because I was retroactively going through all my Readme files, and reformatting them for better readability. Also, now I was actually establishing proper code commits instead of merely updating via copy-pasting directly into repositories. I had GitHub Desktop open on my Lenovo, and open on my MacBook. This led to a whole lot of increased activity.

6. 2021 (227 commits)

This year, activity dropped off slightly, though my usage was arguably more consistent than it had been the previous year. The line chart shows a jagged line, though less jagged than previous years, with a peak near year end.


The heatmap of my activity was looking more spread out.


I was going through school for Data Analytics, and this affected the time I had for code experimentation. I'm proud to say, though, I managed to dedicate at least this much time.

7. 2022 (651 commits)

This was the year my usage really started to take off. For one, I was really seriously beginning to commit code the way GitHub was meant to be used. The lowest number of commits I tracked was 34 in January, and it never fell below that number for the rest of the year. The highest at one point was 76 in March. The line chart still shows a jagged line, but the minimum has risen dramatically.


The heatmap shows an ever wider spread of contributions over the year. A whole lot more heat. Almost three times the previous year's.


I had also begun to manage the contents of the website on GitHub, under a private repository. This was so I could look up previous versions of files and potentially restore them. I really should have done this a lot sooner. The thing was, my Lenovo was beginning to sputter and I really didn't feel comfortable having all my content stored there. Thus, my hand was forced.

That was pretty much how the number of commits jumped that much.

8. 2023 (872 commits)

The number of commits continued to jump. Compared to the peals and valleys registered in previous years for monthly commits, it was a relatively straight, consistent line.


I had begun to use GitHub to store my blogging drafts. Now this may not sound like much, until one considers how I blog. It starts as a skeleton made out of ideas in point form, and slowly I flesh them out bit by bit. Along the way, I may make revisions - rewording and rearranging stuff. I may only have over 70 blogposts a year, but that's multiple commits per blogpost!

This was partly due to my Lenovo being on its last legs. I began the process of writing drafts in GitHub instead of storing them in text files in my Lenovo, and when my Lenovo finally died in the latter half of 2023, my caution was rewarded.


The end result was, there were only three dates in the entire year where I didn't register a single commit. Compared to last year, the number of commits in a single month ranged from 61 to 80. In the heatmap, you can see that almost the entire map is shades of green.

9. 2024 (991 commits)

Now that I was writing drafts in GitHub full-time, that translated to daily commits. I would get an idea, open up GitHub, and commit it. I registered maybe one or two dates the entire year where I didn't commit anything. Most of the time, though, I was supremely consistent. If you look at the graph, the line was even smoother than the previous year's!


Looking at the chart, my usage started out at 70 plus commits per month, then steadily climbed to the high 80s through the course of the year. I remember at that point trying to rein myself in. I didn't want to end up setting a bar I couldn't commit to long term. The heatmap, as in 2024, shows almost total coverage of shades of green, but a lot more is bright green.


In addition to that, some of my projects were a little complex. They required frequent commits. I could push ten commits in an hour on a ReactJS project. This was also the year I started with NodeJS, and as you can probably tell, this also translated to a lot of commits.



10. 2025 (1007 commits)

The trend continued. I was hitting my stride in my usage of GitHub, and the consistency was really starting to show. Commits per month were now in the 80 plus range, until near the end of the year where I decided to give myself a bit of breathing room. Looking at the trend line, it was almost a straight line except for that year-end dip.


In the case of blogpost drafts, sometimes my updates were just little typo corrections and adding a few sentences here and there. Most bloggers will tell you that the incremental nature of writing a blogpost means that potentially a whole bunch of corrections accompany every one. While this was already the case in previous years, I took it up a few notches.


Here, the heatmap shows an entire year with no gaps. There is obviously higher usage during weekends. Of course, one commit could be as small as correcting a single typo, or be as big as including new functions into the code base. Thus, it can't be a complete representation of how hard I work here. But it's a decent indication.

What a decade!

It's interesting to me how my usage of GitHub evolved through the years. From just another online file system to a means of tracking code changes, and from there expanding to tracking all document changes. Even with code, my usage also changed, with more frequent commits due to establishing CI/CD pipelines.

Most of all, I think it shows my growth as a techie. My usage could still be improved, but at this point I think I'm getting close to a sweet spot. What has your usage been like?

With much commitment,
T___T

Sunday, 12 October 2025

TeochewThunder: Year Eleven (Part 2/2)

Things don't look that good from a viewership standpoint this year compared to last year, but then, they rarely do. I've noticed this for years now. I look at the numbers for this current year and shake my head, only to realize that these numbers tend to double after the passing of another year.

The end result is that the current year's viewership always looks inferior to the previous year's. It's not necessarily the case. Just needs time to settle into the internet.

That said, let's get into the weeds of what apparent successes there are.

Huge hits

I talked about COVID-19, didn't I? And apparently, it hit a chord. The Dark Years of COVID-19: A Software Developer's Perspective was the undisputed winner, hands down.

Do techies lean Liberal or Conservative? was the culmination of a few weeks of frustration as I watched Social Media go mad over the movie Superman and Sydney Sweeney's jeans. And also some rumination I've had over DEI.

What great genes jeans!

Full-time Pay, Part-time Job was something I wrote on the spur of the moment, after witnessing Jeremy Tan's epic speech during the eve of the Polling Day 2025. It inspired me to pen this down, and if I'm being honest, it's not one of my more thought-out works. Still, it doesn't matter; the popularity of the topic and Jeremy Tan, carried the day for this blogpost.

Replit Goes Rogue was a recent addition, but its trajectory is on the rise. Despite being posted less than a month, its numbers are really promising.

OK-ish

So many posts fell into this category. Either huge things were expected for them and they failed by just doing decently, or they punched above their weight.

Why people should (and shouldn't) hire older software developers was just more comparison between younger and older developers.

How much of the Artificial Intelligence hype is just hot air? I suspect this struck a chord with much of the anti-AI brigade, which has been gathering momentum.

What Iswaran's sentence means for those in positions of authority were some thoughts on authority and responsibility. Not so much tech, more workplace-related.

A vacation!

A Software Developer's Vacation in Malacca. A fun piece, with lots of pictures!

Not My Job, Not My Problem is more of a commentary on the workplace, rather than anything tech.

Finally, The Silencing of Charlie Kirk and what it means for Social Media, was written two days after Charlie Kirk was felled by an assassin's bullet. As to be expected, it caught fire fast and it's probably only in this category because of its late inclusion. Some readers called it "balanced". The funny thing is, in the toxic climate that is the USA's Culture Wars, this piece would be vilified by both sides.

Artificial Intelligence Experts join Meta... but it's not about the money? Really? was me responding to more tech news.

Duds

These were the ones that barely raised a whimper. Mostly technical posts which is a tragedy because, well, this is a tech blog. Sorry, not sorry. This is actually in line with the assignment, so I'm gonna keep doing these, regardless.

JavaScript now has negative indexing... sort of was just a report on a new JavaScript function I discovered. It wasn't even that new. And probably I need to work on my presentation because the views suggested that readers found it boring AF.

Is Repeating The Password Field Really Necessary? More of a UI/UX thing. Maybe not the most interesting blogpost in the world, but I think it needed to be written.

Meta Ditches the Fact-checkers - now, I really expected a hell of a lot more out of this one. Either people aren't interested in seeing me shit on Meta, or they just aren't very interested in Meta, period. On the other hand, as mentioned, Artificial Intelligence Experts join Meta... but it's not about the money? Really? did OK, so I really don't know.

Bailing from Meta.

While we're at it, it appears that at this time of writing, in a bizarre twist, AI experts have left Meta (and all that money) to join some startup. This in no way invalidates my previously implied point that Meta is a deeply problematic company that one would join only if the financial reward was great... the fact that people are not staying in spite of the money, only further reinforces the point.

But this hardly warrants a blogpost all on its own, so... just gonna leave it here.

Thunderation!

Been a pleasure, as always. I love working on this blog, but I also look forward to the annual blogging break. It's where I can get things reset and take stock of the year ahead.

Dialling it up to eleven, yo!
T___T

Friday, 10 October 2025

TeochewThunder: Year Eleven (Part 1/2)

Well, look who turns 11 this year! It's not me (I wish), but it's this blog, of course. This thing here might just be a substitute for the children I'm never planning to have.

Dear God, please no.

In all seriousness though, it occurs to me that the effort taken to maintain this blog and the website has pretty much kept me sane all these years. I read somewhere about journalling with regard to mental health, and it seems that this blog is a great example of journalling. Why's it different from venting on Facebook or X, you might ask?

Well, for one, Social Media posts tend to be a lot shorter and more unfiltered. Which can be a good thing, don't get me wrong, but not necessarily so if you want a more thorough internal audit. Blog posts go through several revisions, as we examine what's going on in our heads, and why, and maybe even how it pertains to the tech space. The final result is a more measured, more self-examined output into the stratosphere. As such, I consider my blogposts of higher quality than a simple vomiting of my initial reactions on Social Media platforms.

That isn't to say I haven't said stupid shit in the past. I absolutely have. But the beauty of time is that as the years go by, I can evolve into less of s shit-talker and more of a shit-thinker. Yikes, that didn't sound better, did it?

Dedication

Also, this is a blog I'm dedicated to.

Dedication is a measure of how consistent you're willing to be in your efforts even without applause or acknowledgement. It's a measure of how much of a shit I give. And I give a lot.

Think about it. In previous years, I could at least justify the effort by the way prospective employers would look at my entire online portfolio. These days, they don't do that anymore (also, I haven't been looking in a while) because even the demos I put out are kids' stuff. I like to think some of it is really well-done, but well-done or not, it's still kids' stuff. Those are just not the things people hire senior developers for, especially not in the age of Artificial Intelligence and Vibe Coding.

So no... there are no longer practical reasons for maintaining this effort. I do these things because I like doing these things.

That's not to say I don't occasionally benefit from a break. And October is my assigned month for that break. Other than this blogpost, there will be no other visible activity. Emphasis on the word visible.

Invisible hands, invisible effort.

You see, as in most software development, the value is largely in the stuff that users don't see. The optimizations. The security fixes. The fine-tuning in the back. That's not to say there's no value in the stuff that's visible, but sometimes I feel like a lot of that is just to placate laypersons who don't know any better.

That's a controversial statement which we should reserve for another day.

To my original point, there is going to be work done. Just not visible work. Mostly prep for year-end, and 2026.

Content

As with last year, I've been making an effort to use less profanities in my writing. Not because I necessarily think the odd (or even frequent) vulgarity is a bad thing, mind you. More because I don't want to develop an over-reliance on anything, not even swearing. I don't want to have to use foul language as a crutch to express myself. It's just poor form. To that end, I am limiting myself to using it only a few times a year in this blog, usually whenever I review a Black Mirror episode. I certainly won't be using them with the same frequency during, say, 2019 to 2022, around the COVID-19 pandemic.

Speaking of which, as the horrors of the past few years fade behind us, I'll hopefully be speaking less about COVID-19 from this year forth. It was a terrible few years, and my emotion-laden rants during that period are evidence of that, but it's time to move on.

You may have noticed that the posts are getting even shorter than they used to. This is not an accident; rather it is the natural evolution of this blog. I wasn't verbally verbose before (at least I hope not) but reading other blogposts and tuning out halfway has made me realize that the lack of attention span on the internet is a very real thing. As a result, I'm going to curb any impulse I may have, to belabor whatever points I may be making.

What else? Yeah I changed the TeochewThunder logo. Talked about that already, didn't I? Hope you like it. If you don't, too fucking bad, baby. It's staying.

Surprise!

This is a tech blog, so I talked a whole lot about tech this year, as always. In particular, I talked about Artificial Intelligence. I suspect that this will be happening with alarming regularity, especially with the frequency with which laypersons feel the need to chime in. Someone's got to show 'em their place! Just kidding... kinda.

As for web tutorials, there's been a nice mix that includes NodeJS and NextJS. and D3. Along with the almost obligatory HTML, CSS, JavaScript sprinkled with the occasional PHP, of course. I started learning NodeJS, as usual, for the heck of it. It increased my understanding of what I was doing with ReactJS and NextJS, so there was value in it.

I've continued to generate images from AI, but the pendulum has swung back somewhat and once again I've begun to see value in using stock photos.

Next

Highs, lows, hits and misses

Tuesday, 23 September 2025

Web Tutorial: NodeJS Text Replacement Blogging Tool

Writing content for the web can be tricky and tedious, because it involves converting text to HTML. And when delivering a web tutorial (such as the one I'm doing now) this increases tenfold due to special characters which could be mistaken for genuine HTML. Because web tutorials for the web frequently involve HTML, amirite? At first I was OK with doing text replacements on Sublime Text, but even with programmable macros and such, it rapidly became a repetitive chore.

So when I was exploring NodeJS, I came up with this absolutely genius idea. How about I create an interface to process my text and spit it out in blog-friendly format? I also needed this thing to be configurable in case my requirements evolved. Nothing I couldn't achieve with vanilla JavaScript. Except I didn't want to be making code changes every time my requirements changed. No, I needed the replacements to be read from a CSV file which I could change any given time.

Plus, doing it this way gives me the opportunity to introduce the core module fs and the installed module csv-parser.

Thus, I started my new blogging tool project. For this, I ran the following commands.
npm install --save express
npm install --save express-handlebars
npm install --save csv-parser


This is the code that includes Express as middleware and the setup for the port...

app.js
var express = require("express");

var app = express();

app.set("port", process.env.PORT || 3000);


...and the code that uses Handlebars as a templating engine.

app.js
var express = require("express");

var app = express();

var handlebars = require("express-handlebars").create({defaultLayout: "main"});
app.engine("handlebars", handlebars.engine);

app.set("view engine", "handlebars");

app.set("port", process.env.PORT || 3000);


Here, we ensure that form bodies can be parsed using Express to parse JSON. And also, we tell Express to use the assets directory for static links.

app.js
var express = require("express");

var app = express();

var handlebars = require("express-handlebars").create({defaultLayout: "main"});
app.engine("handlebars", handlebars.engine);

app.set("view engine", "handlebars");
app.set("port", process.env.PORT || 3000);

app.use(express.json());
app.use(express.urlencoded({ extended: true }));

app.use(express.static("assets"));


We then implement routes to handle 404s and general errors...

app.js
var express = require("express");

var app = express();

var handlebars = require("express-handlebars").create({defaultLayout: "main"});
app.engine("handlebars", handlebars.engine);

app.set("view engine", "handlebars");
app.set("port", process.env.PORT || 3000);

app.use(express.json());
app.use(express.urlencoded({ extended: true }));

app.use(express.static("assets"));

app.use((req, res, next)=> {
  res.status(404);
  res.render("404");
});

app.use((err, req, res, next)=> {
  res.status(500);
  res.render("500", { errorMessage: err.code });
});


Here's the route for form processing. We'll call it process and set it to POST. Leave empty for now.

app.js
var express = require("express");

var app = express();

var handlebars = require("express-handlebars").create({defaultLayout: "main"});
app.engine("handlebars", handlebars.engine);

app.set("view engine", "handlebars");
app.set("port", process.env.PORT || 3000);

app.use(express.json());
app.use(express.urlencoded({ extended: true }));

app.use(express.static("assets"));

app.post("/process", async (req, res)=> {

});

app.use((req, res, next)=> {
  res.status(404);
  res.render("404");
});

app.use((err, req, res, next)=> {
  res.status(500);
  res.render("500", { errorMessage: err.code });
});


And finally, for routes, we have home, a GET route. Inside it, we will render the form view with some data.

app.js
var express = require("express");

var app = express();

var handlebars = require("express-handlebars").create({defaultLayout: "main"});
app.engine("handlebars", handlebars.engine);

app.set("view engine", "handlebars");
app.set("port", process.env.PORT || 3000);

app.use(express.json());
app.use(express.urlencoded({ extended: true }));

app.use(express.static("assets"));

app.get("/", (req, res)=> {
  res.render("form", { textContent: "", btnCLass: "", message: "Paste your text in the box provided, then hit the PROCESS button." });
});


app.post("/process", async (req, res)=> {

});

app.use((req, res, next)=> {
  res.status(404);
  res.render("404");
});

app.use((err, req, res, next)=> {
  res.status(500);
  res.render("500", { errorMessage: err.code });
});



These are the files I have for rendering pages, in the views directory. Firstly, the layout file main.handlebars, which we specified in app.js.

views/layout/main.handlebars
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>T___T's Text Replacement Tool for Blogging</title>

    <link rel="stylesheet" type="text/css" href="css/styles.css">
  </head>
  <body>
    <h1>TEXT REPLACE TOOL</h1>
    <div class="content">
      {{{ body }}}  
    </div>    
  </body>
</html>


The rest are pretty standard. The 404 view is next.

views/404.handlebars
<h1>404</h1>

<p>Not found!</p>


And for 500.

views/500.handlebars
<h1>500</h1>

<p>There was an error.</p>
<p><b>{{ errorMessage }}</b></p>


And this! The form view. We have a form that submits a POST to the process route.

views/form.handlebars
<form action="/process" method="POST">

</form>


Then a textarea tag with names and id txtTextToProcess. In it, we will display the data textContent.

views/form.handlebars
<form action="/process" method="POST">
  <textarea id="txtTextToProcess" name="txtTextToProcess" required>{{ textContent }}</textarea>
</form>


We then follow up by displaying the data message.

views/form.handlebars
<form action="/process" method="POST">
  <textarea id="txtTextToProcess" name="txtTextToProcess" required>{{ textContent }}</textarea>

  <br />
  {{ message }}
  <br />

</form>


And finally the SUBMIT button, which will be styled using the CSS class btnClass.

views/form.handlebars
<form action="/process" method="POST">
  <textarea id="txtTextToProcess" name="txtTextToProcess" required>{{ textContent }}</textarea>

  <br />
  {{ message }}
  <br />
  <button class="{{ btnClass }}">PROCESS</button>
</form>


This is the CSS file for the app, and honestly there's not much here because it's going to be substance over style. Meaning, ugly. It's in the assets directory, which we earlier specified in app.js that Express should use for remote file linking. The really important thing here is hidden, which will hide whatever it's applied to. The rest is just... fluff. And not even particularly pretty fluff.

assets/css/styles.css
.content
{
  width: 90%;
  height: 500px;
  margin: 10px auto 0 auto;
}

textarea
{
  width: 90%;
  height: 300px;
  margin: 10px auto 0 auto;
}

button
{
  width: 10em;
  height: 1.5em;
  display: inline-block;
  float: right;
}

.hidden
{
  display: none;
}


There, you should be able to see this, at least, when you run "node app.js" in the CLI.


This is the CSV file I'm using. You'll see all the replacements. The first few are straightforward enough - "<" being replaced by "lt" and ">" being replaced by "gt".

assets/csv/inputs.csv
find,replace
"<","<"
">",">"


The next couple are a bit more advanced. We want to replace tabs with two HTML spaces. And new lines with HTML break. In these cases, we have to escape the special characters.

assets/csv/inputs.csv
find,replace
"<","<"
">",">"
"\t","  "
"\r\n","<br />"


Here, I specify some shorthand that I use in my blogging. When I have, for example, "c---" followed by a br tag (because after carrying out the previous replacements, all new lines would be HTML breaks) I want it to be replaced with a div tag styled using the CSS classes post_box and code. Note that the class attribute value here would be encased in double quotes... and each literal double quote has to be escaped using another double quote.

assets/csv/inputs.csv
find,replace
"<","<"
">",">"
"\t","  "
"\r\n","<br />"
"c---<br />","<div class=""post_box code"">"
"r---<br />","<div class=""post_box result"">"
"i---<br />","<div class=""post_box info"">"
"s---<br />","<div class=""signature"">"


Lastly, all occurences of "e---" and a br tag need to be replaced by a closing div tag.

assets/csv/inputs.csv
find,replace
"<","<"
">",">"
"\t","  "
"\r\n","<br />"
"c---<br />","<div class=""post_box code"">"
"r---<br />","<div class=""post_box result"">"
"i---<br />","<div class=""post_box info"">"
"s---<br />","<div class=""signature"">"
"<br />e---","</div>"


Now we start to prepare the code for processing data, in the POST route. We declare processedText, and set it to the value of the textarea that was sent in the POST, txtTextToProcess.

app.js
app.post("/process", async (req, res)=> {
  let processedText = req.body.txtTextToProcess;
});


At the end of this, you want to render form but with processedText as your textContent. You want the button to be invisible, so set btnClass to hidden, and the message property should be just a string indicating success.

app.js
app.post("/process", async (req, res)=> {
  let processedText = req.body.txtTextToProcess;

  res.render("form", { textContent: processedText, btnClass: "hidden", message: "Text processed." });
});


But of course, we will be working on processedText. For this, we call the asynchronous function loadChanges(), using await to pause execution until it's done running.

app.js
app.post("/process", async (req, res)=> {
  let processedText = req.body.txtTextToProcess;
  await loadChanges();

  res.render("form", { textContent: processedText, btnClass: "hidden", message: "Text processed." });
});


Here, we declare the global array changes. Then we create the asynchronous function loadChanges().

app.js
const fs = require("fs");
const csv = require("csv-parser");

let changes = [];

async function loadChanges() {

}


app.get("/", (req, res)=> {
  res.render("form", { textContent: "", btnCLass: "", message: "Paste your text in the box provided, then hit the PROCESS button." });
});

app.post("/process", async (req, res)=> {
  let processedText = req.body.txtTextToProcess;
  await loadChanges();

  res.render("form", { textContent: processedText, btnClass: "hidden", message: "Text processed." });
});


Here, we have a Try-catch block. We'll try reading the CSV file, and then do some logging if it fails.

app.js
let changes = [];

async function loadChanges() {
  try {

  } catch (err) {
    throw new Error("Error reading CSV.");
    console.error("Error reading CSV:", err);
    }
}


The main action here is to run the asynchronous function loadFile(), which we will create, and pass in the file path as an argument. The returned value should be assigned to the changes array.

app.js
let changes = [];

async function loadChanges() {
  try {
    changes = await loadFile("assets/csv/inputs.csv");
  } catch (err) {
      throw new Error("Error reading CSV.");
      console.error("Error reading CSV:", err);
    }
}


loadFile() is another async function. It has a parameter, filePath. It returns a Promise object.

app.js
let changes = [];

async function loadFile(filePath) {
  return new Promise((resolve, reject) => {

  });
}


async function loadChanges() {
  try {
    changes = await loadFile("assets/csv/inputs.csv");
  } catch (err) {
    throw new Error("Error reading CSV.");
    console.error("Error reading CSV:", err);
  }
}

We will first declare the array results.

app.js
async function loadFile(filePath) {
  return new Promise((resolve, reject) => {
    const results = [];

  });
}


We then call the createReadStream() method of fs, passing in filePath as an argument. The result will be run through the pipe() method, which connects the resultant stream of data to something else.

app.js
async function loadFile(filePath) {
  return new Promise((resolve, reject) => {
    const results = [];

    fs.createReadStream(filePath)
    .pipe()
  });
}


In this case, the connection is to csv(). csv() is a CSV parser, simply put, and running pipe() with csv() as an argument means that we're reading the file stream as a CSV.

app.js
async function loadFile(filePath) {
  return new Promise((resolve, reject) => {
    const results = [];

    fs.createReadStream(filePath)
    .pipe(csv())
  });
}


Now we have a callback for each row that fs is processing. We basically push row into the results array.

app.js
async function loadFile(filePath) {
  return new Promise((resolve, reject) => {
    const results = [];

    fs.createReadStream(filePath)
    .pipe(csv())
    .on("data", (row) => {
      results.push(row);
    })
  });
}


But before that, since some of the characters in the find column need to be unescaped, we run the values through the unescapeSpecialChars() function.

app.js
async function loadFile(filePath) {
  return new Promise((resolve, reject) => {
    const results = [];

    fs.createReadStream(filePath)
    .pipe(csv())
    .on("data", (row) => {
      row.find = unescapeSpecialChars(row.find);
      results.push(row);
    })
  });
}


Then we handle errors and resolutions.

app.js
async function loadFile(filePath) {
  return new Promise((resolve, reject) => {
    const results = [];

    fs.createReadStream(filePath)
    .pipe(csv())
    .on("data", (row) => {
      row.find = unescapeSpecialChars(row.find);
      results.push(row);
    })
    .on("end", () => resolve(results))
    .on("error", (err) => reject(err));

  });
}


This is the unescapeSpecialChars() function. Nothing special here. We just accept a string parameter and return the result after replacing the characters we're looking for, with their unescaped equivalents. We need to do this because the characters were formatted a certain way to fit into the CSV.

app.js
async function loadChanges() {
  try {
    changes = await loadFile("assets/csv/inputs.csv");
  } catch (err) {
    throw new Error("Error reading CSV.");
    console.error("Error reading CSV:", err);
  }
}

function unescapeSpecialChars(str) {
   return str
  .replace(/\\t/g, "\t")
  .replace(/\\r\\n/g, "\r\n")
  .replace(/\\n/g, "\n")
  .replace(/\\r/g, "\r");
}  

app.get("/", (req, res)=> {
  res.render("form", { textContent: "", btnCLass: "", message: "Paste your text in the box provided, then hit the PROCESS button." });
});


Let's test this! Add some HTML in the textbox.


Click the PROCESS button, and you'll see the "<" and ">" symbols have been replaced.


Now let's test new lines and tabs.


See the new lines replaced by br tags and tabs replaced by HTML spaces.


For our final trick, we add this shorthand.

And we can see that this has been replaced by the appropraite opening and closing div tags!



That's it...

And of course, from this point on, all I need to do is copy the text and paste it as HTML.

This little beauty has been inestimably useful. I can't even begin to imagine blog maintenance without it now.


Good luck out there. <br /> a leg!
T___T

Sunday, 31 August 2025

Web Tutorial: The new TeochewThunder SVG logo

Now that the logo for TeochewThunder has been changed, for this month's web tutorial, we will be examining the process behind the new SVG logo. This is basically a XML file that your web browser will display as an image. Today, not only am I going to show you how to produce it, I will show you the little hacks I employed along the way.

And the beauty of this is, you just need a text editor. The file will be saved with a .svg extension, and you can open it in your web browser.

We begin with the svg tag. The version and xmlns attributes are important here, for this to be rendered correctly by the browser.

logo2.svg
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">

</svg>  


We set width and height of the SVG.

logo2.svg
<svg version="1.1" width="210px" height="130px" xmlns="http://www.w3.org/2000/svg">

</svg>  


Now, we could just get right to drawing the SVG, but let's exercise some developer prudence. Let's create a grid of lines to aid us visually. These are a series of horizontal lines that run through the SVG, each spaced 10 pixels apart.

logo2.svg
<svg version="1.1" width="210px" height="130px" xmlns="http://www.w3.org/2000/svg">
  <line x1="0" x2="210" y1="10" y2="10" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="20" y2="20" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="30" y2="30" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="40" y2="40" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="50" y2="50" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="60" y2="60" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="70" y2="70" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="80" y2="80" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="90" y2="90" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="100" y2="100" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="110" y2="110" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="120" y2="120" stroke="grey" stroke-width="1"/>

</svg>  


This is being viewed at 300% scale.


Now for vertical lines.

logo2.svg
<svg version="1.1" width="210px" height="130px" xmlns="http://www.w3.org/2000/svg">
  <line x1="0" x2="210" y1="10" y2="10" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="20" y2="20" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="30" y2="30" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="40" y2="40" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="50" y2="50" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="60" y2="60" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="70" y2="70" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="80" y2="80" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="90" y2="90" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="100" y2="100" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="110" y2="110" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="120" y2="120" stroke="grey" stroke-width="1"/>

  <line x1="10" x2="10" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="20" x2="20" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="30" x2="30" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="40" x2="40" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="50" x2="50" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="60" x2="60" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="70" x2="70" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="80" x2="80" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="90" x2="90" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="100" x2="100" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="110" x2="110" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="120" x2="120" y1="0" y2="150" stroke="grey" stroke-width="1"/>
  <line x1="130" x2="130" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="140" x2="140" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="150" x2="150" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="160" x2="160" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="170" x2="170" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="180" x2="180" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="190" x2="190" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="200" x2="200" y1="0" y2="130" stroke="grey" stroke-width="1"/>

</svg>


Now we have a nice grid! Effectively what we have here are 10 pixel squares.


Start a path tag with an empty d attribute and set the fill attribute to the infamous TeochewThunder orange!
logo2.svg
<svg version="1.1" width="210px" height="130px" xmlns="http://www.w3.org/2000/svg">
  <line x1="0" x2="210" y1="10" y2="10" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="20" y2="20" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="30" y2="30" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="40" y2="40" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="50" y2="50" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="60" y2="60" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="70" y2="70" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="80" y2="80" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="90" y2="90" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="100" y2="100" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="110" y2="110" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="120" y2="120" stroke="grey" stroke-width="1"/>

  <line x1="10" x2="10" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="20" x2="20" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="30" x2="30" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="40" x2="40" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="50" x2="50" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="60" x2="60" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="70" x2="70" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="80" x2="80" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="90" x2="90" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="100" x2="100" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="110" x2="110" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="120" x2="120" y1="0" y2="150" stroke="grey" stroke-width="1"/>
  <line x1="130" x2="130" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="140" x2="140" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="150" x2="150" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="160" x2="160" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="170" x2="170" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="180" x2="180" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="190" x2="190" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="200" x2="200" y1="0" y2="130" stroke="grey" stroke-width="1"/>

  <path d="" fill="rgb(255, 150, 0)"
  />

</svg>


Now that we have a grid to work off, it should be easier. We start at (0, 0). Use "M" to move the cursor to (100, 0) - which is 10 squares to the right and 1 square down. Then use "l" to move 90 pixels back (9 squares) and no squares vertically. Then use "l" again to move 40 pixels (4 squares down. Add a "Z" to signify a return to the origin, and you'll get this triangle!

logo2.svg
<path d="M 100 10
  l -90 0
  l 0 40 Z
"
  fill="rgb(255, 150, 0)"
/>



The first "T" is taking shape, and we are moving right to the underlined part.

logo2.svg
<path d="M 100 10
  l -90 0
  l 0 40
  l 30 0
  l 0 70
  l 120 0
Z"
  fill="rgb(255, 150, 0)"
/>



Now we're taking care of the jagged part of the "lightning bolt". For this, we move the line to the right and up, then horizontally left, then right and up again.

logo2.svg
<path d="M 100 10
  l -90 0
  l 0 40
  l 30 0
  l 0 70
  l 120 0
  l 15 -50
  l -10 0
  l 5 -20
Z"
  fill="rgb(255, 150, 0)"
/>



A few horizontal and vertical strokes later, we're almost done with the horizontal crosspiece of the second "T", and on course to complete the first "T".

logo2.svg
<path d="M 100 10
  l -90 0
  l 0 40
  l 30 0
  l 0 70
  l 120 0
  l 15 -50
  l -10 0
  l 5 -20
  l 30 0
  l 0 -40
  l -90 0
  l 0 40
Z"
  fill="rgb(255, 150, 0)"
/>



This is where you do a little bit of trial and error, mirroring the slanting of the "lightning bolt", but in reverse.

logo2.svg
<path d="M 100 10
  l -90 0
  l 0 40
  l 30 0
  l 0 70
  l 120 0
  l 15 -50
  l -10 0
  l 5 -20
  l 30 0
  l 0 -40
  l -90 0
  l 0 40
  l 30 0
  l -5 40
  l 15 0
  l 0 20
Z"
  fill="rgb(255, 150, 0)"
/>



That's actually the hardest part - the rest is all horizontal and vertical strokes.

logo2.svg
<path d="M 100 10
  l -90 0
  l 0 40
  l 30 0
  l 0 70
  l 120 0
  l 15 -50
  l -10 0
  l 5 -20
  l 30 0
  l 0 -40
  l -90 0
  l 0 40
  l 30 0
  l -5 40
  l 15 0
  l 0 20
  l -80 0
  l 0 -60
  l 30 0
Z"
  fill="rgb(255, 150, 0)"
/>



What we do now is remove all the grid lines...
<svg version="1.1" width="210px" height="130px" xmlns="http://www.w3.org/2000/svg">
  <!---
  <line x1="0" x2="210" y1="10" y2="10" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="20" y2="20" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="30" y2="30" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="40" y2="40" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="50" y2="50" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="60" y2="60" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="70" y2="70" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="80" y2="80" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="90" y2="90" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="100" y2="100" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="110" y2="110" stroke="grey" stroke-width="1"/>
  <line x1="0" x2="210" y1="120" y2="120" stroke="grey" stroke-width="1"/>

  <line x1="10" x2="10" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="20" x2="20" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="30" x2="30" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="40" x2="40" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="50" x2="50" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="60" x2="60" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="70" x2="70" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="80" x2="80" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="90" x2="90" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="100" x2="100" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="110" x2="110" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="120" x2="120" y1="0" y2="150" stroke="grey" stroke-width="1"/>
  <line x1="130" x2="130" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="140" x2="140" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="150" x2="150" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="160" x2="160" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="170" x2="170" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="180" x2="180" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="190" x2="190" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  <line x1="200" x2="200" y1="0" y2="130" stroke="grey" stroke-width="1"/>
  -->

  <path d="M 100 10
    l -90 0
    l 0 40
    l 30 0
    l 0 70
    l 120 0
    l 15 -50
    l -10 0
    l 5 -20
    l 30 0
    l 0 -40
    l -90 0
    l 0 40
    l 30 0
    l -5 40
    l 15 0
    l 0 20
    l -80 0
    l 0 -60
    l 30 0Z"
    fill="rgb(255, 150, 0)"
  />
</svg>


And here's your (or rather, my) SVG in its final glory!


Now let's test this with HTML. Create this file wth a black background (or any color, really, other than orange).

tt_logo.html
<!DOCTYPE html>
<html>
  <head>
    <title>New T___T Logo</title>
  </head>

  <body style="background-color:black">

  </body>
</html>


And add in the SVG file that we created, but in different sizes, for testing.

tt_logo.html
<!DOCTYPE html>
<html>
  <head>
    <title>New T___T Logo</title>
  </head>

  <body style="background-color:black">
    <img src="logo2.svg" />
    <img src="logo2.svg" width="300" />
    <img src="logo2.svg" width="100" />

  </body>
</html>


Here, you can see the "S" part of SVG - "scalable", that is. No matter how big or small it is the logo remains crisp and sharp!


Final words

I like this new logo, and I thought the process of making it could be a good learning experience. The original will always have a place in my heart due to the lighthearted moments it was inspired from. But perhaps it's time for this blog to grow up, just a bit.

Ta___Ta for now!
T___T