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.

First of all - Happy New Year of 2019 to all! 👑🎉🎊

To kick off the year with a big bang, let’s start with today’s post.

From my previous post little over ago or so, I discussed the importance of knowing data structures such as arrays, stacks, queues etc every good software developer/engineer must grasp. In this post, I will be covering topics on the other not-so-common data structures that we normally (or always, should I say) use when implementing our algorithms.
They are follows:

1. Trees
2. Graphs
3. Heaps
4. Trie

Not so long ago, that I encountered an interesting application refactoring challenge in one of the legacy web apps.

And when I’m talking about legacy web apps, I’m usually referring to server-side rendering web applications.

In this legacy web app, I have the grand opportunity to design and refactor web UI controls to be heavily built in React alongside with leveraging client-side routing such as React Router.

But due to the sheer size of its monolithic complexity behind such web forms, the time required to completely revamp the UI interface could not be accomplished within our client’s timeline budget of delivery. We need to ship some parts of the system that’s already remade in React in the first phase, but the rest of the legacy systems would have to hop aboard with the rest of the React app with it.

Thus the solution to serve the other legacy system menus and app access within React is simply to make use <iframe> tag.

Earlier in 2018, I posted about several major tech trends that developers will need to get their eyes and ears checked for, and one of them is about blockchain.

I went ahead to follow this blog post to quickly learn and build blockchain in record speed using Python!

After playing around their sample code, I decided to give myself a crack of this - to write blockchain implementation in NodeJS.

Before I continue writing the rest of the post, I just want to reaffirm my point that I don’t know a lot about them upfront and their useful practicalities in real life scenarios.

I’m sure there’s plenty of online blogs and forums out there will be ongoing discussions amongst blockchain enthusiasts, exploits and the like on how the technology can ‘revolutionalise’ the way people do online transaction.

I will cover some of those in my future post one day perhaps.

But today, I simply want to cover the basics of writing blockchain for anybody that is interested to know and how it what works under the hood.

When building and writing up your React applications, you would typically be designing components that make up your UI screens for users to interact. Your components could be ranging from menu navigation tabs, tables displaying data, to paginated items, image gallery etc, etc..

You know.

The usual UI suspects full-stack web developers normally face.

For eg, let’s say if you were to up build a form that comes with some drop-down fields, your React code would look like this.

React App
import React, { Component, Fragment } from "react";

export default class FormApp extends Component {
  state = {
     dropdown_shirt: null
  }
  searchMe = e => {
    // Magic is going to happen here.
  };

 pickMe = e => {
   //state your name!
   this.setState({[e.target.name]: e.target.value}
 }

  render() {
    return (
      <Fragment>
        <h1>Welcome to my Awesome React App</h1>
        <form className="form-container">
          <label htmlFor="dropdown_shirt">Shirts</label>
          <select name="dropdown_shirt" onChange={this.pickMe}>
            <option value="polo_tees">Polo Tees</option>
            <option value="sleeveless">Sleeveless</option>
            <option value="v_necks">V Necks</option>
          </select>
          <button onClick={this.searchMe}>Find me some tees!</button>
        </form>

        {/* The table data will be rendered here when searching */}
      </Fragment>
    );
  }
}

There are times I find that even though Visual Studio Code (VSC) does its own incredible job of searching and locating files in the search bar, it doesn’t truly give me any relevant context how some source code matches were written not just in one domain of abstraction, but also is used in other several layers of application abstraction anywhere in a typical full-stack web application.

For instance, it could be something about certain software design pattern that’s currently implemented in one area of the module but you want to affirm whether that same design pattern could be also used in other parts of the application as well.

But where can you begin to figure out where and how heavily the design patterns are used and their overall prevalence within an application, if editor tools such as VSC can’t give you the straight answers?

Well.

Here’s how.

Since the news broke out, there’s been a lot of discomfort and anxiety experienced by all developers in the wider community - particularly for the open source communities.

People have been sending their massive tweets with about dumping Github for an alternate open source online code storage systems out there such as Gitlab or
Bitbucket, left and right, as part of their voiced frustrations and concerns of Microsoft’s Github acquisition and its future of software development.

And, rightly so, they should be entitled to experience that fear as much as I was some weeks back.