Forem: Tony

One Simple Way To Improve Your Dev.to Experience

Tony — Tue, 16 Feb 2021 11:56:37 +0000

A couple of weeks ago, I was almost giving up on Dev.to. I would open the app, scroll through the suggested posts, and sigh in dismay. I couldn't help but think aloud: My Dev.to feed sucks!

My feed was filled with posts of beginner articles in React, JS, etc. I'm not against beginner articles, but when you have read several of these, you can get bored pretty easily with suggestions to read more of the same.

However, something didn't make sense: I knew that there were people writing posts on advanced/intermediate topics. Why was I then only being shown the beginner topics? Sometimes I was lucky enough to stumble upon such an article, and I'd light up as my interest in the app got renewed. But these were just once-in-a-blue-moon occurrences.

How I Came Across The Solution By Accident

One evening, I opened the Dev.to app, and I immediately noticed how bright it was, in contrast to my other apps. For some reason, the app did not automatically activate dark mode after sunset. I went exploring in the app settings, and voila! Not only did I find the option to activate dark mode, but also an option to customize my feed.

Hidden deep in the settings, is a section that asks you your experience level:

You can access this via this link. Just scroll to the bottom.

By default, no value was selected, and out of curiosity, I updated this to option 5 (Expert), just to see what would happen. I went back to my feed and forgot all about it.

I didn't notice until much later that my feed had greatly improved. I suddenly wanted to read and save every article on my feed. It only hit me later that the above change had somehow refreshed my feed experience (I guess the cache took a while to update).

There you have it! If your Dev.to feed sucks, don't despair. Just change your experience level and you will start seeing better content in no time.

Cheers!

PS - it still sucks that there is no auto dark mode to match the device preferences 😩. Dev.to, please do something about it! 😃

My Year in Review: 2020

Tony — Tue, 19 Jan 2021 06:15:20 +0000

In early 2020, I came across Ire Aderinokun's post, 2019 Year in Review, and I couldn't help but be in awe of her accomplishments. That year, she had spoken at 4 conferences in multiple locations such as Paris and San Fransisco, traveled to 6 countries, interviewed by the BBC, among several other achievements.

I was greatly motivated and challenged to achieve my 2020 goals and record them at the year's end. I wrote this just before 2020 ended but I have been holding back on publishing it. Well, here goes...

Work Projects

I work at Africa's Talking, a company that provides an API for sending SMS, building USSD apps, and more to 40,000+ devs. You can think of it as the "Twilio of Africa". This year, albeit with the COVID-19 situation and everything going on, we were able to roll out a lot of amazing products/features. A couple of projects I worked on include:

a) Product Requests

I was privileged to solve one of the key challenges we had at work: the creation of a new tool to help customers request a product (e.g. an SMS Sender ID or USSD Service Code) effortlessly and quickly. Previously, to request such a product, you had to send an email to the team stating that you wanted this particular product. The team would then reply, requesting you to send your details, such as your name, contact information, a signed letter authorizing the request, and so much more. Simply put, there would be a lot of back and forth in emails between a customer and the team before a product went live.

To counter this, we created a feature on the dashboard called Product Requests where users could request the product on their own, upload any documents e.g. signed letters, fill out their information, etc. We also added in a couple of cool features such as a progress bar to show you how far your request was from being completed, a real-time chat feature where users could chat 1-on-1 with the team, and so much more.

We launched the Beta version in Kenya only, and I have to say, it felt really good to see more than a hundred product requests raised through this and the number of emails substantially going down. We are looking forward to rolling this out to more countries in 2021.

b) Africa's Talking Marketplace

The Africa's Talking Marketplace is a one-stop-shop platform for users who want a ready-made no-code solution to their problem that makes use of the Africa's Talking API. All products in the Marketplace are created by our customers.

An exciting part about working on this product was using a purely vanilla Typescript implementation, i.e. no React, Vue, Angular, jQuery, etc. I wrote more about this on my blog. You can also view the actual Marketplace here. Impressively, the product received thousands of page visits after we launched 🎉

Speaking

One of my 2020 goals was to start speaking at conferences. The problem was, I didn't know how to. Luckily, I met Wayne Rambo, a Software Engineer at Nike, who gave me tons of advice on this. He then introduced me to his friend, Hung Truong, an iOS Engineer at Amazon, who shared with me the basics of conference speaking such as Call For Papers (CFPs) and more. Finally, I spoke to my work colleague, Anthony Kiplimo, about my desire to speak at conferences and he made sure to tag me along in the events he would speak at.

I mention these three people because I'm particularly grateful to them. Without them, I never would have been able to speak at the 4 events/conferences I spoke at this year, such as:

Build for SDG Challenge 2020: a Facebook/Andela immersive program where participants innovate in industry-led projects or SDGs.

Africa Digital Skills Conference: an Africa-wide conference to teach digital skills.

DSC KU: Developer Students Club, Kenyatta University

DSC Moi University: Developer Students Club, Moi University

Events

Apart from speaking at events, I also attended several events. Although a pandemic, the COVID-19 brought along one advantage: virtual events; events that I otherwise would never have had the opportunity to attend. My top favorites were:

React Summit: to say that this was fun is an understatement 😃

Tony

@tawn33y

I just saw @VladimirNovick use his mind to interact with a web page and fly a drone 🤯
#ReactSummit

11:29 AM - 20 Apr 2020

Tony

@tawn33y

I had tons of fun at #ReactSummit 🎉
Thank you @ReactAmsterdam, all the speakers, and everyone involved!

11:33 AM - 20 Apr 2020

ByteConf React 2020: I think I attended this event just to hear Kent C Dodds speak 😃

Tony

@tawn33y

#ByteConf is finally here!! 🎉

Link: youtube.com/watch?v=MEeZLM…

16:39 PM - 01 May 2020

Github Universe: I still think that Github's Dark Mode unveiling is the coolest dark-mode launch ever! 💯

GitHub

@github

echo "hello, darkness" #GitHubUniverse #Keynote githubuniverse.com

17:31 PM - 08 Dec 2020

Learning

This year, I mainly learned 4 new tools: GraphQL, Tailwind CSS, Figma, and Kubernetes (I'm still a beginner though!).

Other Achievements

GADS 2020: I was privileged to be a mentor at Google Africa Developers Scholarship 2020, a learning program offering free Pluralsight access to 30,000+ learners.
Code Hub: my telegram channel surpassed 500 members 🥳️
YouTube tutorial: my first YouTube tutorial garnered 800+ views 🎉
Blog post: I received the highest number of views on any of my blog posts ever, after one of my blog posts got 600+ visitors in less than 24 hours 🙌
Open Source: I only worked on one open-source initiative this year, url-to-markdown: a fast way to convert a Medium blog article into markdown. I created this since heckyesmarkdown.com was not working at the time, but I have since taken it down.

Personal - hiking

I was more serious about hiking this year and hiked several places such as Mt. Longonot (~13kms), Ngong Hills (~16kms), Karura Forest (~16kms), and more. Here's to more hiking in 2021! 🥳️

What about 2021?

I can't wait to see what 2021 brings. One thing I certainly would like to work on this year is building more open-source projects, something I wasn't able to do last year. For now, I'm just thankful to God for everything I achieved in 2020. See you soon!

2 Quick Tips when working with JS console output

Tony — Wed, 23 Sep 2020 07:54:44 +0000

Here are 2 quick tips you can use when working with the output from JS console:

1) Displaying data

If you are displaying arrays or objects, use console.table rather than console.log:

// try running this:

console.table([
    { firstName: 'John', lastName: 'Doe', age: 2 },
    { firstName: 'William', lastName: 'Shakespeare', age: 3 },
]);

This will display the data in a nice tabular view as shown below:

2) Copying data

If you are working with Google Chrome & need to copy data from the console output, instead of manually highlighting & copying the data, you can run this:

const data = [2, 3, 4];
copy(data);

This will copy the data to your clipboard.

NOTE: the copy command is only available on Chrome & not on the node.js env.

Have fun coding! 🎉

2 Lessons learned from developing the AT Marketplace

Tony — Mon, 13 Jul 2020 23:00:10 +0000

One of my babies just went live! 🎉😃

The AT Marketplace is a tool that showcases great applications or services that have been created by businesses or developers using Africa’s Talking APIs. You can view it here.

I had lots of fun working on this - for the first time in a long while, I opted out of using React/Vue/Angular/jQuery, and instead, just wrote vanilla Typescript. I couldn't help but have nostalgic feelings as I remembered the good ol' days when I was starting out as a developer and all I knew was jQuery or simple Javascript.

Of course, I could not have done this alone. The many code and UI reviews by my colleagues Calvin, Raj and Matt were quite fundamental in achieving the final output, and echo deeply of the priceless value of teamwork in projects.

I will share two core concepts used in the app, that I most certainly did not know as a newbie:

1) Immutability

Immutability means unable to change: once you initialize a value, you should never change its state, e.g. if the name of a person is John, you should never ever rename that name to Mary or something else.

I'm an astute lover of immutability and I apply it anytime I code, but I will be honest: I have never grasped its other side till most recently. For example, on the Marketplace, I first set it up to display all listings, then react to events: if a user searched for a listing, I would loop through the currently displayed listings and hide all the ones that did not match the search query. I would apply the same principle when a user selected a filter (e.g. Kenya, SMS).

const filteredListings = filterListings(); // some logic to search or filter

filteredListings
    .map(({ id }) => {
        document.getElementById(`listing_${id}`).style.display = 'none';
    });

This changed as I grasped the other side of immutability when playing around with Kubernetes: once you build an image and you need to do some changes, you never edit the existing image; rather, you always build a new image and then deploy this newer image. I achieved this in the Marketplace by separating data logic from the UI. Now, if you search for a listing on the page, there is no looping to hide/show listings; rather, a new UI is built afresh using the new data and then this new UI is inserted into the DOM to replace the existing one. This is so subtle and happens so fast that there is no screen freezing/loading.

import { createMutableState } from 'mutablestate.js';

export const App = () => {
    const listings = createMutableState([]);

    const handleSearch = (query: string): void => {
        // some logic to search

        listings.set(filteredListings);
    };

    listings.onChange(() => {
        // regenerate html

        document.getElementById('app').innerHTML = html;
    });
};

The library used above is a small library I created a while back. You can check it out here.

The effect was instant: the code became a lot cleaner and easier to read and test. Search and filter functions do just that: they search/filter the data, and are never concerned with updating the UI. Also, this helps the app adhere to one of the golden rules: never trust data attributes parsed from HTML.

Was this paradigm shift beneficial? I'll let you be the judge: for Marketplace, it reduced the amount of code by about 72% - e.g. there is only one 'document.getElementById' compared to about 20 or so before.

Unfortunately or fortunately, nowadays this is done for developers inside frameworks such as React that many of us don't really know how it happens. e.g. for React, we just know the theory: updates are done on the virtual DOM, a diff is calculated between this and the actual DOM, and then the diff is used to update the actual DOM.

But I have to say: getting my hands dirty gave me a fresh perspective on the differences of MV*, how to build your own useState and useEffect, among several other things. Understanding the inner workings also helped me gain a lot more respect for React as a framework.

2) Optimistic updates

There are several use-cases of this but I will focus on one example: you might have seen this in your phone applications: when you open Whatsapp, you never see a loading image; rather you see old messages, which are then updated as new messages start streaming in.

For Marketplace, when you first load the page, data is retrieved from the API and then cached. If you refresh the page or view one of the listings, data is fetched from the cache instead of the API so that the page loads much faster and you don't see a loading icon; then in the background, an API call is made to check if there are any changes to the data, and if there are, the UI is updated accordingly.

Last Word

I hope you learnt a thing or two from our experiences. If you are a dev newbie, I challenge you not to just use React or Vue or [insert framework here]. Teach yourself how to write apps in your free time using plain JS: it will really help you grow as a developer.

Till next time, stay safe! 👋

A free utility for easy routing in USSD applications

Tony — Mon, 20 Apr 2020 10:16:59 +0000

TL;DR Use the ussd-router utility to manage USSD routing headaches. Install on npm or view the source code.

Case Study: The headache in building USSD apps

Imagine you are building a USSD application as follows:

Perhaps, you would write code as follows:

import express from 'express';
import bodyParser from 'body-parser';

const app = express();
const port = 3000;

app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: false }));

app.post('/webhook/ussd', (req, res) => {
  const { body: { text } } = req;

  const footer = '\n0: Back 00: Home';
  let msg = '';

  if (text === '') {
    msg += '1: Buy data bundles';
    msg += '\n2: Buy calls and sms bundles';

  } else if (text === '1') {
    msg += '1: Daily bundles';
    msg += '\n2: Weekly bundles';
    msg += footer;

  } else if (text === '1*1') {
    msg += '1. Buy for my number';
    msg += '\n2. Buy for other number';
    msg += footer;

  } else if (text === 1*1*1) {
    // more logic
  }

  res.send(msg);
});

app.listen(port, () => {
  console.log('Server running...');
});

The important part is in the if-else flow, which allows you to add several screens to the USSD application:

This works flawlessly! But what happens when a user decides to navigate to the previous screen by pressing ‘0’ or to the home screen by pressing ‘00’?

You guessed it. This introduces an unsavory chain of if-else statements:

const footer = '\n0: Back 00: Home';
let msg = '';

if (rawText === '' || rawText === '1*00' || rawText === '1*0' || rawText === '1*1*00') {
  msg += '1: Buy data bundles';
  msg += '\n2: Buy calls and sms bundles';

} else if (rawText === '1' || rawText === '1*1*0') {
  msg += '1: Daily bundles';
  msg += '\n2: Weekly bundles';
  msg += footer;

} else if (rawText === '1*1' || rawText === '1*1*1*0') {
  msg += '1: Buy for my number';
  msg += '\n2: Buy for other number';
  msg += footer;
}

Ugh. That’s one huge spaghetti of code.

Mind you, I didn’t even explore all the paths a user could take while navigating. In fact, as the user navigates deeper and deeper and decides to navigate to the previous/home screen, it may get too complicated for you to even handle the logic.

The solution

As illustrated, you may decide to handle the routing on your own, but that will add unnecessary boilerplate to your code.

Or you could use the ussd-router library.

The ussd-router library will help you remove the boilerplate needed to handle navigation in your application to the previous/home screen, and let you rest easy as you concentrate on your business logic.

import { ussdRouter } from 'ussd-router';

const text1 = ussdRouter('544*1*2'); // '544*1*2'
const text2 = ussdRouter('544*1*2*00*3'); // '544*1*3'
const text3 = ussdRouter('544*1*2*0*1*2'); // '1*2'
const text4 = ussdRouter('544*1*2*0*1*2*00*3'); // '1*3'

Thus, you can update your code as follows:

import { ussdRouter } from 'ussd-router';

app.post('/webhook/ussd', (req, res) => {
  const { body: { text: rawText } } = req;

  const text = ussdRouter(rawText);
  let msg = '';

  if (text === '') {
    // do something
  } else if (text === '1') {
    // do something else
  }
});

And you never again have to worry about handling navigation in your USSD application.

What if I want to use a different keyword to go to the home/previous screen?

By default 0 is the keyword used to go to the home screen, while 00 is used to go to the previous screen.

If you want to change this, simply update this as follows:

const text1 = ussdRouter(rawText, '98', '99');

Here, 98 is the keyword that will be used to go to the home screen, while 99 will be used to go to the previous screen.

Getting the library

If you use node.js, you can install the npm package as follows:

npm i ussd-router

If you don’t use node.js, you can view the source code, and transpile the algorithm into the programming language of your choice.

Cheers!

Want to get started on building USSD apps today? Visit https://africastalking.com/

Here’s a reason why your website is not secure

Tony — Thu, 09 Apr 2020 18:18:51 +0000

If you are a website developer, you have most probably protected yourself from common attacks such as XSS, SQL, CSRF, etc.

But are you safe from a Clickjacking attack?

Try this:

1) Create a blank html file

2) Add the following code:

<style>body { margin:0; }</style>

<iframe src=”http://your-site.com" width=”100%” height=”100%” style=”border: 0"></iframe>

Then open the html file in your browser. If your browser loads your website, congratulations (pun)! You’re susceptible to clickjacking attacks :)

But if your browser displays the following error (or similar) in your console:

Refused to display ‘https://your-site.com' in a frame because it set ‘X-Frame-Options’ to ‘sameorigin’.

then you are [relatively] safe.

What is Clickjacking?

Clickjacking is an attack where an attacker uses an iframe to load your site and tricks a user to click on a button/link. The attacker then hijacks the clicks meant for the original server.

The above code opens your website in such a way that no one can tell the difference between your real website and the iframed version, especially if an attacker uses a [false] url similar to your domain name, e.g. faceebook.com

Most sites like Facebook, Github, Whatsapp, etc have blocked iframes page loading, i.e. you cannot load any of these pages via an iframe. YouTube only allows embedded videos.

Whether you are using Nginx, Apache server, etc., you should disable the loading of your website in an iframe by setting the x-frame-options header in your config files to DENY, e.g.

x-frame-options: DENY

Protect yourself from Clickjacking attacks today.

You can learn more here:

https://keycdn.com/blog/x-frame-options