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

When developing a Rails application that deals with a lot of form inputs, you’ve probably come across seeing this often.

Your typical Rails form setup
# Profile form submit

<%= form_tag(@contact) do %>
    <%= label_tag (:name, "Name") %>
    <%= text_field_tag (:name) %>
    <br/>
   <%= label_tag (:email, "Email") %>
    <%= email_field (:email) %>
    <br/>
    <%= label_tag (:address, "Address") %>
    <%= text_area_tag (:address) %>
    <br/>
    .........
    <%= submit_tag("Submit") %>
<% end %>

As per ruby/rails guides, this is the most basic and most common setup for capturing user input data into our system.

We need to find a way to create one-to-one object mapping between the form fields and their respective ActiveRecord model’s members and properties.

And, we couldn’t have done much better without the help of Rails HTML form helpers to create these data-binding mechanisms within our form input fields against our model objects.

There’s been a lot of attention going about amongst developers working within the front-end ecosystem on how to go about making Javascript-based applications impervious to bugs on data-type checking.

If you’ve worked with Javascript for some time, you will discover a number of pain points this de-facto language comes with - not that many developers would care to admit.

For eg,

// here, num is a number
var num = 1;

// now num is string
num = '1';

If you can clearly see what’s wrong with this, then you are in the same boat with countless of developers who simply couldn’t help themselves, pulling their hair out far and wide when you’re completely stuck figuring out where did all the right (and intended) data types disappeared to. As Javascript is a dynamically weak type programming language, you’d be sure to know that landing in this awkward scenario will drive you up several walls when searching high and low for buggy behaviour in several places.

From my previous post, I discussed the importance of knowing simple algorithms every software developer/engineer must grasp as part of their engineering repertoire. In this post, I will be covering topics on common data structures that we normally (or always, should I say) use when implementing our algorithms.

The common ones are the following:

1. Arrays
2. Linked Lists
3. Stacks
4. Queues
5. Hash Tables

##Data Structures

###a) Arrays

If you’ve ever been doing some programming for a while, you may have run into this term a lot by now if you ever worked with or seen lots of loop iterations in many codebases. If you haven’t, then I’d suggest now it’s time to take a refresher course on the for loop constructs. After all, that’s what (and why) arrays are built for :).

Arrays are the most prominent and well-known piece of data structure programmers of different programming disciplines have come across with. They are very simple data structures, and you can place any kinds of data types in them from strings to booleans. And they usually have a finite size of holding items. And the most common type of data operations we’ve seen on arrays are manipulating and traversing data hold of items by referencing its indices.

Add a Custom Excerpt to Your Post

I worked with CSV data some years back and I’m always curious to know how well NodeJS handles CSV filesystem in the backend compare with the likes of Java, .NET, Ruby or PHP environments.

As it turns out, I figured you can do things with it in the smallest possible way, by importing the following modules.

let fs = require('fs');
let fastcsv = require('fast-csv');

We have the fast-csv module to handle the CSV data(especially if it’s fairly large dataset thus the chosen module has to be performant-driven) when reading it from the FileStream input like so.

let readableStreamInput = fs.createReadStream('./some-csv-table.csv');
let csvData = [];

fastcsv
    .fromStream(readableStreamInput, {headers: true})
    .on('data', (data) => {
      let rowData = {};

      Object.keys(data).forEach(current_key => {
         rowData[current_key] = data[current_key]
      });

      csvData.push(rowData);

    }).on('end', () => {
      console.log('csvData', csvData);
      console.log('total rows of table', csvData.length);
    })

Not long ago, I spent a month learning the basics on how algorithms and data structures work and their practical use in our daily programming lives for a recent job application for one of the top software companies down under.

In the first place, I never truly appreciate how and why they are important to learn. After working with some startups, agencies and consulting firms for several years, a lot of things I did in my previous work never once find one or two things that data structures and algorithms would come in handy when solving difficult business problems. The mere thought of having to know them is nothing more but boring computer science fundamentals which bear no relevance in today’s modern computing age where technologies are evolving at rapid pace. With today’s computers’ raw computing power such as CPU, memory and speed took care by technology vendors that make such great advances, we never need to worry about making optimizations in our code.

Generated AI image by Microsoft Bing Image Creator

It’s been some time I wrote any post content on my blog. I thought, now, it would be good time to delve into it and share my today’s trail of thoughts how the year 2017 has fared so far this year.

Especially what it means to be in web development of today (and tomorrow).

Having worked as an engineer in web/software for the recent 5 years or so, I’ve witnessed and observed an amazing churn of events that bring up a plethora of technologies which help us software craftsmen, engineers and designers to drive innovation forward and beyond - by leaps and bounds. Be they come from front-end tech stack, APIs services, back-end, databases, cloud environment etc, etc. Each of these technical aspects has evolved well over time. But - more particularly - it’s the front-end community that’s evolving at an incredible speed of light.