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.

Not long ago, I always wanted to write myself a useful tool on Github. And that is to do with finding how do we web-scrape data from any websites or web pages.

And sure enough as soon as I opened up the Github page, and go search for web scrap you get the following:

There are about 8800+ search results about this topic. And it sounds like it’s an expansive topic to know for such a simple software that goes out and extract all the data across any sites you encountered.

So I ask myself this question is - how and where did all this web scraping begin?

Well.

As it turns out, I went ahead to dig up the little history behind it.

In my previous post last year, I mentioned briefly about using ES6 generator/iterators feature as one of the major ways to write asynchronous code in your Javascript/NodeJS applications.

But what are they greatly capable of really, other than just doing that?

I never get my head around with this ES6 feature fully since its inception. So I couldn’t find a lot of other common usages besides its apparent usefulness for handling continuous streams of data that runs asynchronously.

Thus I decided to go and explore a bit out about them, and understand what is their true purpose.

Ever since Facebook officially made ReactJS library open-source for the global dev community back in 2013, there has been no slow-down with its meteoric rise as the next ‘best’ Javascript library that jQuery could never be (or never able to catch on).

It’s a pretty big bold statement for me to say this after reading this article online, explaining the design process of implementing ReactJS when building front-end applications, and comparing its main contrast to jQuery’s application-building approach. The author went on, highlighting the importance of maintaining the separation of concerns between states information and the actual DOM elements that rely on them; and making points on how jQuery may not handle this aspect of good software development practices very well and its other drawbacks.

After working within the front end(FE) space for some time, where the majority of my time was spent on hacking jQuery, the article casts some reflections on how using jQuery was (and still) a great multi-purpose utility tool for web developers for building web user interactivity for a very long time.

As you’re working with NodeJS more and more, you’ll soon find yourself in a position to put in more logging messages than ever before. Especially, when your server encounters a number of, say, error handling exceptions, such that you want to divide your continuous stream of logger messages into the following:

• Critical messages
• Info messages
• Warning errors
• Debugging errors, etc

And our best logging friend is console.log usually comes to the rescue for the all the above-mentioned things. But sometimes, you just wish there’s a better way to preformat and categorise them differently when they get spat out in the terminal screen, as you go.

That’s where Chalk comes in.

There are a lot of URL shortener web services online that marketers and advertisers use to promote their URL content such as Google URL shortener, Bitly and TinyURL etc. They all do one thing in common, ie they take long URLs; have them shortened in length; and when visitors click on the modified links, they will be redirected to actual link content.

Given how good the other URL shortener web service implementations are done, I got myself involved in wanting to find out how I could achieve the same thing by implementing my own simple version of URL shortener service.

For a typical URL shortener service to be useful for people wanting to publish shareable content, it must simply fulfil the following:

With just a little over a week in the new year of 2018, things are about to heat up down under 🔥🔥🔥🔥🔥 (like literally as we’re right in the middle of hottest summer at the time of this writing).

2017 has brought vast changes and major disruptions in the tech ecosystem that we, developers, should no longer afford to ignore what the preceding events have in store for us. It’s gonna be one helluva year for engineers and developers of all ages.

After doing some bits of googling and researching online, several industry watchdogs are keeping their watchful eyes and keen ears on the next upcoming ‘tech appetite’ people could expect to taste in the new year.

• IOT
• Fintech Payments Startup Comeback
• Augmented Reality to go mainstream
• Machine Learning and AI
• Cryptocurrencies and Blockchain
• Mobile App Development