
import { Callout } from '@/components/Callout';

2 years ago I released an open-source Javascript library. Little did I know it would grow to be extremely popular with **190+ github stars** and **60,000+ downloads**. It was the "unofficial" sdk for the Whatsapp Business API in Javascript.

<img src="/images/content/articles/60k-downloads-lessons-learned-in-open-source-development/monthly downloads.png" className="mx-auto" /> 
<p className="text-center text-sm text-muted-foreground">Monthly downloads</p>

<img src="/images/content/articles/60k-downloads-lessons-learned-in-open-source-development/total downloads.png" className="mx-auto" /> 
<p className="text-center text-sm text-muted-foreground">Total downloads</p>

<img src="/images/content/articles/60k-downloads-lessons-learned-in-open-source-development/github stats.png" className="mx-auto max-w-xs md:max-w-md" /> 
<p className="text-center text-sm text-muted-foreground">Github stats</p>

I archived the repo earlier this year because I became too busy to maintain it. However I'd love to share some lessons I learned along the way about Open-Source Development.

## Lessons learned in open-source development

### 1. Your open-source users are your customers

Treat them like so. *"But they are not paying me so why should I care?"* Because someone desperately relies on your code to run their business. Resolve issues fast. If you're too busy, delegate, delegate. I will admit I failed in this at first. 

The faster you acknowledge and address issues, the more users will prefer & freely share your library.

### 2. High code quality

Semver, tags, releases, CI/CD for testing each PR and releasing new builds, good documentation, API docs, etc. If a user has to ask you how to use a function, you have failed. A user should see all possible ways to consume a function without having to ask you. 

I've often seen this happen in companies: someone asks, "What does X do?" - but the person who knows has either left or is too senior to respond or never bothered to document it. Please don't do this in open source.

### 3. If your product is good enough, you may never need to market it.

I never published an ad. I was surprised to get emails from people in countries I've never been to, saying thank you. I came across blogs written by strangers on how to use the library, and saw Stack Overflow answers linking the library. Facebook later built their own package in Javascript but for some weird reason I cannot explain, people preferred to use my package more. Mine had more downloads and more github stars. 

This is a lesson I'll carry with me even beyond open source development: 

<Callout type="tip">
  If your product solves an important problem well enough, you may never need to spend a cent in marketing.
</Callout>

### 4. You cannot test enough

Don't just import functions & test them. I learned this the hard way. For testing, create a virtual env, build the npm package, install it & then test the functions. Do this in CI/CD to ensure your package never has breaking changes that you never knew about.

### 5. Move first and move fast

But above all, execution matters more than moving first.

### 6. Naming matters

I aptly named my library `whatsapp-cloud-api`. When people googled this, it was the first thing they saw. That helped a lot in getting more downloads.

{/* 1. **Your open-source users are your customers.** Treat them like so. "But they are not paying me so why should I care?" Because someone desperately relies on your code to run their business. Resolve issues fast. If you're too busy, delegate, delegate. I will admit I failed in this at first. The faster you acknowledge and address issues, the more users prefer & freely share your library.
2. **High code quality** - semver, tags, releases, CI/CD for testing each PR and releasing new builds, good documentation, API docs, etc. If a user has to ask you how to use a function, you have failed. A user should see all possible ways to consume a function without having to ask you. I see this in companies: "what does x do?" Someone has left the company or is too high up to answer you. Please don't do this in open source.
3. **If your product is good enough, you may never need to market it.** I never published an ad. I was surprised to get emails from people in countries I've never been to saying thank you. I came across blogs written by strangers on how to use the library, and saw Stack Overflow answers linking the library. Facebook later built their own package in Javascript but for some weird reason I cannot explain, people preferred to use my package more. Mine had more downloads and more github stars. This is a lesson I'll carry with me even beyond open source development: if your product solves a particular problem well enough, you may never need to spend a cent in marketing.
4. **You cannot test enough** - don't just import functions & test them. I learned this the hard way. For testing, create a virtual env, build the npm package, install it & then test the functions. Do this in CI/CD to ensure your package never has breaking changes that you never knew about.
5. **Move first and move fast.**  But above all, execution matters more than moving first.
6. **Naming matters.** I aptly named my library `whatsapp-cloud-api`. When people googled this, it was the first thing they saw. */}

{/* Delegate, delegate, delegate. Have good communication, templates, docs on how to contribute, etc. Lead. You cannot build it alone. */}

## How to get the library

If you use node.js, you can <a href="https://www.npmjs.com/package/whatsapp-cloud-api" target="_blank" rel="noopener noreferrer">install the npm package</a> as follows:

```sh
npm i whatsapp-cloud-api
```


Lessons learned from building an Open-Source Javascript library from scratch.

60,000+ Downloads: Lessons Learned in Open-Source Development


import mainImg from "@/../public/images/content/articles/2-quick-tips-when-working-with-js-console-output/main.png";
import { Callout } from '@/components/Callout';

<img src={mainImg.src} />

*Originally published on* <a href="https://dev.to/tawn33y/2-quick-tips-when-working-with-js-console-output-4hjo" target="_blank" rel="noopener noreferrer">Dev.to</a>*.*

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

## 1) Displaying data
If you are displaying arrays or objects, use `console.table` rather than `console.log`:

```js
// 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:

<img src="/images/content/articles/2-quick-tips-when-working-with-js-console-output/displaying data.png" className="mx-auto" /> 

## 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:

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

<Callout type="note">
The `copy` command is only available on Chrome & not on the node.js env.
</Callout>

---

Have fun coding! 🎉


2 quick tips you can use when working with the output from the JS console.

2 Quick Tips when working with JS console output


import mainImg from "@/../public/images/content/articles/a-free-utility-for-easy-routing-in-ussd-applications/main.png";

<img src={mainImg.src} />

*Originally published on* <a href="https://dev.to/tawn33y/a-free-utility-for-easy-routing-in-ussd-applications-3b6j" target="_blank" rel="noopener noreferrer">Dev.to</a>*.*

> 
> TL;DR Use the ussd-router utility to manage USSD routing headaches. <a href="https://www.npmjs.com/package/ussd-router" target="_blank" rel="noopener noreferrer">Install on npm</a> or <a href="https://github.com/tawn33y/ussd-router/blob/master/src/index.ts" target="_blank" rel="noopener noreferrer">view the source code</a>.

## Case Study: The headache in building USSD apps
Imagine you are building a USSD application as follows:

<img src="/images/content/articles/a-free-utility-for-easy-routing-in-ussd-applications/main.png" className="mx-auto" />

Perhaps, you would write code as follows:
```js
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:

```js
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.

```js
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:

```js
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:

```js
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 <a href="https://www.npmjs.com/package/ussd-router" target="_blank" rel="noopener noreferrer">install the npm package</a> as follows:

```sh
npm i ussd-router
```

If you don't use node.js, you can view the <a href="https://github.com/tawn33y/ussd-router/blob/master/src/index.ts" target="_blank" rel="noopener noreferrer">source code</a>, and transpile the algorithm into the programming language of your choice.

Cheers!

### Want to get started on building USSD apps today? 

Visit <a href="http://africastalking.com/" target="_blank" rel="noopener noreferrer">https://africastalking.com/</a>.


How to use the ussd-router utility to manage USSD routing headaches.

A free utility for easy routing in USSD applications


import mainImg from "@/../public/images/content/articles/heres-a-reason-why-your-website-is-not-secure/main.png";
import { Callout } from '@/components/Callout';

<img src={mainImg.src} />

*Originally published on* <a href="https://dev.to/tawn33y/here-s-a-reason-why-your-website-is-not-secure-1no1" target="_blank" rel="noopener noreferrer">Dev.to</a>*.*

## You are most probably safe from common attacks

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:
    

```html
<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 intended). You're susceptible to *clickjacking attacks*.

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

```plaintext
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 URL *similar* to your domain name, e.g. <a href="http://faceebook.com" target="_blank" rel="noopener noreferrer">*faceebook.com*</a>

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

## How to protect yourself from clickjacking

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.

<Callout type="tip">
  Disable the loading of your website in an iframe by setting the `x-frame-options` header in your config files to DENY:

  ```apache
  x-frame-options: DENY
  ```
</Callout>

Protect yourself from Clickjacking attacks today.

You can learn more here:

<a href="https://keycdn.com/blog/x-frame-options" target="_blank" rel="noopener noreferrer">https://keycdn.com/blog/x-frame-options</a>


How to protect yourself from clickjacking attacks.

Writings

60,000+ Downloads: Lessons Learned in Open-Source Development

2 Quick Tips when working with JS console output

A free utility for easy routing in USSD applications

Here's a reason why your website is not secure