We’re edging towards halfway of 2022.. And boy. Look how time has gotten passed by.

I must admit I haven’t had the chance to sit down and write up another good tech blog post. A lot is happening in motion since the start of the year 2022 from my recent engagement to my fiancee of 3 and half years; busy with my day job as a contractor for a bank; finally getting my passport renewal done in Canberra (after almost 2 years of nationwide lockdown) as part of my travel plans to Malaysia so I can send my father’s ashes for his final resting place; along with talking plans having my fiancee and me moving together later in the year and preparing my next career technical certifications to take on, etc…

The list could go on.

Nevertheless, still, I’m glad to take the time to write about what I have accomplished recently.

That is…

I’ve decided to migrate my Octopress site to Hexo! 📦🚚

If you’re like me, and you’ve built several Github repositories over time as part of developer learning fun projects, there’s probably a good chance these same repositories will not get maintained on some form of regular basis.

The reasons for this to happen can be wide-ranging - everything from being too busy at work, changing interests for different software frameworks, lifestyle priorities changes, changing career responsibilities etc, etc - there’s too many to list here.

They took the best of our coding life as months or years go by.

As a consequence, your Github repositories do become quickly stale over time.

This ‘staleness’ - come with old dependencies that do not get updated, which at worse, could be leaking software security issues over time.

I have over 50 repositories in my Github profile and there’s no way that I could keep track of knowing which repos have more security holes to address after another, let alone have to fix up security vulnerabilities dependencies one PR at a time on my own… 😨

Thus I need to find a way to auto-manage all these repositories without lifting a finger (much)

Without further ado, I found this useful toolchain from Github marketplace - Snyk.

It’s been some months since 2021 has begun (and we’re not where near safe coming out of the pandemic woods just yet ). I’ve been itching to come and sit down to write my first blog post for the year.

What better way to start out writing ins-and-outs on certain Python web frameworks.

I’ve been working on Python web projects for some time and I’m here to offer my rants/thoughts when working between Django and Flask/Falcon and outline the comparisons between these two.

Let’s start with the ones I’m most familiar with.

NB - Before I begin, this article assumes the reader either has a good understanding or good working knowledge of MVC software patterns as more web frameworks are built around this pattern. If you don’t know what that is, you may want to visit this Wikipedia page as a refresher course, before proceed reading.

// when the giant red button got triggered - 🚨🚨
async function globalWHOAlertSystem(pandemicAlertLevel, globalToiletPaperSupplyChain) {
	let message = document.getElementById("message");
    message.innerHTML = "";
	try {
		do {
			const areWeDoomed = await globalToiletPaperSupplyChain.verifyStockLevel()
			if (areWeDoomed) throw "We are so screwed😱!!"
		}
		while (pandemicAlertLevel > 60000); // it's over 60,000!
	} catch (err) {
		message.innerHTML = err;
    }	
}

Well, the code snippet above pretty much summarises everything we all knew what the year of 2020 has brought us.

All small jokes aside, this year has been an incredibly difficult year for all, especially for the tech community in general.

Countless of tech meetups, tech networking events and tech conferences have either been postponed indefinitely, rescheduled or cancelled altogether around the world.

With every new tool, framework or methodology comes along, developers with their insatiable appetite or thirst for knowledge and power, they will find ways to make dedicated time to learn how they work and how they’re planning to use them as part of the day to day job.

And functional programming (FP) - a newish paradigm has been permeating through the scenes of developer community for some time; everything from Haskell, Elixir, React, AWS Lambdas to Clojure etc.

Or, at least it’s yet to make establish some norms within the community…

But I must digress.

When you work on a codebase, at any certain point of time, they tend to grow in size. Thus the larger the codebase becomes, the more Javascript modules you will get to develop and maintain.

And more often than not, those same Javascript modules are not always clear when you spend time determining the inter or intra-relationships between them.

For eg,

A developer (let’s called him Jake) works on modules, A, B, C, and discovers the following dependencies pattern.

Module A depends on Module B and C,
Module B depends on Module C
Module C doesn't depend on anything.

If you’re anything like me, after you spent considerable time chopping up codes for all types of applications, be it web or mobile app, you’ve already come across with code that shares some similar patterns as the codebase itself has grown over some significant portion of the time.

From these observations, we programmers developed our conversations on design patterns in making scalable software solutions.

In particular with JS, with the influx of JS libraries, frameworks, tools etc, we can build our applications to solve some particular problems in so many different ways. But, no matter how much tooling JS developers are going to be choosing, there’s no better substitute for incorporating useful patterns in your code design where you see fit.

I’ve been doing relational databases for a long time now, especially when you’re dealing with making data-rich web applications.

In fact, every full stack developer will tell and share you their stories and trivialities of working with database intimately every day.

So what better way to work with them is to know plenty of SQL statements such as SELECT, GROUP BY, FROM, WHERE etc, which is paramount without question.

Knowing such basic skills allows you to work with disparate industry-standard relational database technologies such as MySQL, MS SQL, Oracle DB, Postgres, and many more.

But what I discovered, recently of late, there’s a new tool that has been slowly introduced to these relational database technologies crowd all the while.

For the first time, you can now create and generate JSONified results from SQL statements.

As great software engineers we’re aspired to be every day in our daily work, I’ve always used to think how we can build amazing products for our clients to use so it helps to achieve their major goals tenfold. Especially when you have the scalability forethought in mind.

Built to scale as they say in the world of startups and venture capital funding.

That product can be anything from a simple portfolio website for an artists/singer, a basic space invaders game for kids to play online, to building high-grade commercial e-commerce system for thousands, if not millions of online customers to interact and use worldwide, or perhaps build the next Facebook-scaled size social media platform!

These atypical software products we’re so used to building can vary in size. A product can do one or several simple things. Or a product that makes up so many moving parts that are, rightfully so, considered as components that do very complex jobs on its own. Thus the same product is a behemoth size project so you got think how a lone developer is going to meander through the layers of architecture ensuring that all of these components can work with each other in which they primarily function or not.

Thus it brings to my attention on this very important subject matter - using dependency injection as one of your core software design principles.

At some point, when working with your feature branches, you need to do some bit of ‘trimming’ with your stale branches that you no longer need to keep.

These stale branches include:

• branches have been merged to the master branch, both locally and remotely.
• branches that were no longer required as actual features by the client.
• branches that were built for prototype or demo purposes.