DEV Community: Saunved

What the heck is Prototypal Inheritance? Part 1: Object Prototypes

Saunved — Sat, 02 Jul 2022 10:00:50 +0000

Before you dive in, you should have a decent understanding of Objects and Functions in Javascript.

Prototypes and prototypal inheritance in Javascript can be confusing, especially if you have learned Object Oriented Programming from the perspective of Java or C++.

These posts aim to clear up some of the confusion, and make prototypal inheritance easier to understand.

Let's start!

First off, there are two "kinds" of prototypes in Javascript:

Object prototypes
Function prototypes

Although they both have similarities, it's best to treat them separately. In this article, we will be looking only at Object Prototypes.

Some facts I need you to keep in mind while reading this article:

Any data type in Javascript that is not a primitive is an Object
By extension, functions are technically objects in Javascript, albeit with some extra gimmicks, e.g. you can invoke them. MDN reference
Objects can contain functions as their properties (keys). When functions are part of an object, they are called methods. Methods act on an object.

// For example
const person = {
    name: 'Luke',
    hello(){
        console.log(`Hello, I am ${person.name}`)
    }
}
person.hello(); // Prints 'Hello, I am Luke'

The this keyword is deliberately not used in the above example to avoid confusion.

Alright so...

What is an object prototype?

Let's create an object:

const character = { hearts: 5 }

When you create an object in Javascript, it contains the properties you have defined (in this case character.hearts). However, this object also has some hidden properties, magically obtained from the Javascript Gods.

For example, if you were to do character.toString(), it will print "[object Object]". You didn't define any toString() method inside character. So where the heck did it come from?

Enter the prototype
Follow along with the steps below to explore this interesting phenomenon:

(1) Open your console (in any browser, I am using Firefox) by pressing F12 > then click on "Console"
(2) Type and enter window.Object.prototype. It looks like this:

We can see that this is an object with a bunch of predefined properties and methods.
(3) Type const character = {hearts: 1} and press enter
(4) Type character and press enter. The output looks like this:

(5) Type character.__proto__ and press enter. The output looks like this:

Keep the console open, and continue reading.

Do the objects at steps (2) and (5) look the same to you, despite being a part of different objects?

Well guess what, they are the same. And we can prove it.

Do this:
(1) Enter character.toString(), and observe the output

(2) Now we will redefine the toString() the method defined in window.Object.prototype. Enter this in the console:

window.Object.prototype.toString = () => {console.log('Proved it')}

(3) Now, enter character.toString() again and check the output

You modified a method that was owned by window.Object.prototype and somehow, like spooky action at a distance, your character.toString() method's output changed. Crazy stuff right?

This is a good time to pause and review the steps we performed above.

Time to understand this whole gimmick in depth.

All objects contain a prototype property. This "prototype property" is NOT available at character.prototype. It is, instead, called __proto__ and is available as character.__proto__.

The word "prototype" can be confusing. To make things easier to process, you can think of it as "parent" instead. So when you see character.__proto__, you can think of it as "parent of character".

What do you think will be the parent of character.__proto__?
Well, you can chain these! So you can do: character.__proto__.__proto__. This time, you will get null.

null is the ultimate ancestor of all Objects.

Note: __proto__ is not the standard way to access Object prototypes. The standard way is to do Object.getPrototypeOf(obj), but things are easier to write, explain, and understand when using __proto__. Do not use this in production!

The following diagram should help clear a few things up.

As you can see above:

All Objects in Javascript inherently are nothing, denoted by null
From this nothingness, arises something - the most basic object you can have -- an object with some default properties, e.g. toString(), valueOf(). This primal object can be found at window.Object.prototype and is defined by the browser
When you create your own object (any object at all, even an empty object), it inherits the properties of this basic object.
So if you try to call character.toString(), Javascript checks if the method exists on the object character. If not, it drills down and checks the parent of character, which in this case is the window.Object.prototype object.

According to the Oxford Languages dictionary, the word "prototype" means:

The first model or design of something from which other forms will be developed.

It's a succinct definition that applies well to the above behavior of prototype. It starts off as nothing and can progressively build up.

70 lessons from the last year as a developer and co-founder

Saunved — Fri, 09 Jul 2021 16:01:55 +0000

This time last year, we changed our business model and began partnering with small businesses and startups to create tech solutions for them.

This is an exhaustive list of things I've learned since then. The process of writing and organizing these helped me process the learnings better, and I hope it helps someone out there too.

A few of these things might seem like common sense, but I learned them from experience so they had an impact on my behavior or my understanding of my work and life in general.

Organized by

Life
Business
Tech and UX
Tech for everyone
Tech for developers

Life

Communication is crucial for your survival in any profession. Just talk to people you're working with (or for) about your tasks. Drop them a message once a day at least and keep them in the loop, especially if you're going to be late with something.
Most difficult problems are solved when you periodically step away and do something else for a bit.
Coffee is your friend as long as it doesn't mess with your sleep cycle
Writing your own tasks down on paper and crossing them out is more efficient and rewarding than any online tool.
Walk around the house if you're on a phone call. It helps keep you active.
Spending some time every day looking at trees and plants is very soothing.
Hugging your pets at random intervals during the day is a free dose of happiness.
An 18-minute nap in the afternoon does wonders for productivity
Time tracking (using a tool like Toggl) for personal analysis is very useful. You begin to learn how you spend or waste time and even understand how to estimate time for tasks correctly.

Business

Making an app or website for someone doesn't guarantee them sales, and convincing them otherwise can lead to very difficult conversations about their business model.
More effort doesn't equal more reward. Pick your work wisely.
Getting your personal, relationship, and business goals to align will take a toll on your mental health. It's best to process this in a healthy way. Talking to someone, writing about it, or simply being aware of what's causing you to feel a certain way helps a lot.
If you can write well in at least one language, you can usually do well in any desk job. If you don't write well, start practicing. If you can't write well, focus on calling people and talking more on the phone. Either way, communicate.
Running a startup means dealing with the fear of failure and doubt every day. That's okay. It can get better as long as you learn from it and communicate with your cofounders.
Lesser-paying contracts can sometimes give way more happiness than higher-paying ones. Who your customer or client is matters a lot.
A good designer can do wonders for your product. Don't hesitate to hire designers even if you are "decent" at design.
Always get written contracts before starting any work. Verbal contracts and handshake contracts leave room for miscommunication.
Always tell the truth about timelines. If something is going to take 8 weeks, don't say you can do it in 4 weeks.
Always take an advance before starting any project. Decide your amount. For large contracts, 10% can be okay. For small contracts, 50% is good, but always take an advance.
Adapt to the client's style of communication instead of forcing them to use a particular app or website. If your client likes email, use email. If they like Whatsapp, use Whatsapp. You'll just speed things up for yourself down the line.
UI is what you interact with. UX is how you feel after you interact with it. The thinking processes involved in both are vastly different. Try NOT to use these terms interchangeably because they mean different things.

Tech and UX

Encourage designers/yourself to make designs for mobile-first (especially for websites). It's always easier to expand from a place of constraint than to contract design from a large space.
Menu buttons should ideally be labeled "Menu" if they contain important links that cannot be found with other actions
Users forget their passwords. Allow them to sign in through magic links too.
Fall into the habit of writing user feedback loops. Basically, if the user does something, open a toast telling them that it's done. A simple "Data updated" toast builds trust with your system.
Fall into the habit of adding loaders wherever network calls are made. It's super annoying to press a button and have nothing happen for 1 second. I have seen plenty of reputed websites that somehow think it's okay to do this.
If an error occurs on a user action, NEVER show it as a disappearing toast. Make it persist on the screen until the user manually clears the error
Don't use words like "Cancel" in a dialog box. Use "Back" instead. "Back" is comforting, it's a casual escape. "Cancel" is ambiguous and brings an alarming feeling, as if the user is doing something wrong.
Always use the combination of "Sign in" and "Register". Never use "Sign in" + "Sign Up" or "log in" + "sign up". It's not easy on the eyes
Have separate forms for registration and signing in, preferably on separate pages instead of in modals (for SEO purposes)
Keep an easily accessible "Feedback" button in your application so users can report bugs and issues
Well-tested user interfaces require fewer updates and are a joy to use even if they don't "look" great
Always make sure your site has a navbar and a footer, otherwise it looks "naked"

Tech for everyone

Never buy hosting from GoDaddy. Use DigitalOcean or Vercel or Vultr
Buy domains from Google or Namecheap.
Web apps are not worth the hype until Apple decides to adopt and support them properly. You will still need an "app" to give an app-like experience with push notifications and other permissions on iOS.
The largest delays in development and testing times are caused by third-party dependencies (e.g. payment gateways, email delivery services, etc.). Make sure you have all the documentation, approvals, and data formats available before the developers start coding anything.
Live streaming is complicated, especially if there is an authentication layer associated with the stream. The most affordable custom live-streaming services I've found are OneStream, LivePush, and Castr.
WordPress is still better than about 95% of the new content management systems out there (for general use cases of course).
Strapi is a decent choice for a custom CMS, but it is by no means bug-free, especially when it comes to nested queries in GraphQL or renaming collections, or developing locally. Look for lighter alternatives before you get here.
When most people say "AI", they usually mean "ML". When most people say "ML", they usually mean dynamic output based on user-input (which is basically a bunch of "if-else" statements).
The concept of a blockchain is great, but 99% of the things you want to use blockchains for don't need a blockchain in the first place.
No-code is a dangerous buzzword. If you want to do anything even slightly different (which is most things when you get into the details), you have to use code.
After spending a copious amount of time convincing myself that NFTs are actually useful, I have concluded that they are worthless and anybody telling you otherwise just wants to make quick money and disappear.

Tech for developers

Bundle your "admin" frontend with your normal user-side code. Creating a separate project means you probably won't maintain it properly.
Brand new frameworks and libraries will fail you by virtue of being less tested or documented. Test them out in a sandbox for your use case first.
Authentication on the web is a rabbit hole. Use cookies set by the server with httpOnly if you're confused.
The Safari browser is the new Internet Explorer (at least for developers) due to poor support for modern CSS and JS features.
The AWS documentation and UX needs a massive revamp. Also, avoid using AWS if you can.
Utility frameworks (like Tailwind) are surprisingly good, but it's okay if you don't like them. Each to his/her own.
The command line is a beautiful gift and you should definitely use it more if you don't already. Try it out for common tasks, stick to it for a few days, you won't feel like giving up the convenience.
It helps to know at least one frontend framework, one backend framework, and one database. You'll be able to associate other "new" things with the existing ones if you need to later on.
You "know" a framework when you deploy at least two projects to production and maintain them for a few months with 100+ monthly active users.
If you don't want to stress out about there being a bug in your production, then, well... don't stress out about it. If there's a bug, it'll be reported eventually, and you will fix it eventually. Worry about it then.
Most new bugs are introduced when fixing old bugs in a hurry. So test thoroughly and save yourself time later on.
Backups. Always. Have. Backups. Especially if you're not quick on your feet. Doesn't matter where you are, who you are. Make it a part of your thinking process. Also, know how to restore those backups. Backups are restored rarely, but also in time-critical situations. So keep the steps written down somewhere you can find them later on.
Serverless doesn't seem to be the future because of database, job scheduling, and management constraints.
Coding slowly allows you to finish tasks faster than coding "fast" which just causes issues to crop up later and consumes more time overall.
The less code you have in your codebase, the easier it will be to debug.
Don't start coding a new module until you have a bird's eye view and the next 3 steps you're going to take and you fully understand the side effects they will have on the existing system.
Note down crucial decisions in a README that is version controlled and update it every time you have discussions. We've tried saving crucial decisions in emails, in Confluence, in ClickUp, on Jira. None of these things work. Keep the decisions with your code. They will always be accessible.
Try to figure out what's different between your development, staging, and production environments to avoid issues with deployments.
Set release cycles for your products. E.g. every alternate Wednesday. Never deploy immediately before a vacation or a weekend.
Replicate the prod database locally to test things out in a "real way"
If you're coding in a hurry, you'll end up sacrificing on security since it's easy to overlook. Make sure you come back to do a security check later
End-to-end encryption is complicated and causes lots of user experience issues, backup and restore issues, and maintenance headaches in general. If you don't need end-to-end encryption, don't use it.
Don't buy SSL certificates unless there's a very good reason to do so. Free Let's Encrypt certificates are enough for most use cases.
All frontend frameworks are pretty much similar in performance. Use what's convenient and what works for you.
Event-based systems are easier to handle than implicit update systems (e.g. computed properties in Vue). Emit and consume events wherever possible to make your system easier to trace, predict, and debug. This is very useful with complex systems where computed or watched properties can end up in infinite loops.
Debouncing is very useful when dealing with scroll effects or multiple simultaneous event updates. It allows the interface to update while delaying the execution of the tasks by a reasonable time.

I know this was a long read! Feel free to leave your thoughts on the list, especially if you strongly agree or disagree with something.

How to add Supabase to Nuxt.js

Saunved — Sun, 02 May 2021 11:36:34 +0000

Yesterday, I tried Supabase for the first time. Within about 30 minutes, I had social login and password-based authentication set up. There was almost zero friction during the whole process and I was super impressed, especially after my horrible developer experience with AWS Cognito and Amplify Auth.

This is a quick guide on how you can add Supabase to a Nuxt.js application.

Prerequisites

(1) You have a Nuxt.js application created using npx create-nuxt-app or through another method
(2) You have created a Supabase project and the Supabase key, Supabase URL

How to add Supabase to Nuxt

(1) Install Supabase

yarn add @supabase/supabase-js

(2) Add Supabase to plugins
In the plugins folder

Create a file supabase.client.js

Add the following code snippet (replace the key, url with your own)

import { createClient } from '@supabase/supabase-js'
const SUPABASE_KEY = '<YOUR-KEY>'
export default ({ app }, inject) => {
  const supabaseUrl = '<YOUR-URL>'
  const supabaseKey = SUPABASE_KEY
  const supabase = createClient(supabaseUrl, supabaseKey)

  inject('supabase', supabase)
}

This will inject Supabase to our Nuxt project, and will be available as this.$supabase for us to use

(3) Add the plugins file to nuxt.config.js
In nuxt.config.js, add the following to plugins

// ...
  plugins: [
    '@/plugins/supabase.client.js'
  ],
// ...

You can also use the alternative syntax

// ...
  plugins: [
    { src: '@/plugins/supabase.client.js', ssr: false }
  ],
// ...

(4) Use Supabase on any page

//...
methods: {
  signIn(){
    const { user, error } = await this.$supabase.auth.signIn({
        email: this.email,
        password: this.password
      })
      console.log(user, error)
  }
}
//...

That's it!

I'm really excited to see where @supabase_io goes in the coming weeks and months! I hope it keeps growing and adding more useful features.

isfastnet: a tiny script to find out if your user's internet is fast or slow

Saunved — Sun, 15 Nov 2020 15:01:50 +0000

As web developers, we usually write code on systems with good internet speeds. The bulk of our time is spent with the subconscious assumption that "other people should have similar speeds".

Many browsers offer network throttling to test how your application will perform on slower network speeds and we do test for these, but we don't particularly worry about it unless our use case calls for it.

We are working on a food delivery webapp at my company, and being located in India, with some of the most unreliable cellular data, this is a HUGE problem for us. When we run the application on our devices, things work just fine. But on devices with 3G, and devices with poor connectivity, things get a lot worse. Network calls take more than 5s to complete, and that's a massive nightmare for any user.

So we had a use case. Optimizing for poor internet speeds. The first part of the problem is - can we detect if a user's internet is slow and show them some sort of a message / reduce network calls if that is the case?

Below, I outline two solutions, and finally a tiny package I made using one of the solutions.

You can check out the demo page here and if you want to test it out, you can download the package directly from npm and start using it:
npm link

The Network Information API
Easily the best and most useful solution. An API that can tell you exactly how good your user's internet speed is. The problem?

Partial support on Chromium browsers and no support on Safari and Firefox.

Client-side solutions
As any sane developer would do, I looked up the problem on Stack Overflow. This is one of the most popular questions on the topic: Stack Overflow post

The most upvoted and "marked as correct" answer suggests downloading a large image and checking the total time it takes, and dividing the size of the image by the time taken to determine speed. That does answer the question correctly - but in a real system, it might not be the most pragmatic approach.

If a user's internet is already slow, do you really want to download a large image to check how slow it really is?

The larger problem at hand is that you cannot periodically check if the user's internet is slow because it will hog bandwidth for already slow networks.

In most cases, we just want to know if our user's internet is fast or slow.

A little below on the same question, you can find this answer. It suggests downloading a very tiny image multiple times, generating the average download speed, and determining if the internet is fast or slow.

Now we're talking!

Basically, we can set a "threshold" value. If the image is taking (on average) longer than "threshold" milliseconds to download, then the internet must be slow. Sounds great, and it doesn't hog bandwidth either.

However, if you test this out in Chrome DevTools, you will see that this test takes more than 10 seconds to end on slow networks. That's too much waiting to find out if the internet is actually slow.

To get past this issue, one can write a setTimeout inside the recursive function. This setTimeout should force exit the function if the image wasn't downloaded in threshold*3 ms. The 3 is arbitrary, but it should work for most cases. So I edited the script to make those changes.

You can test out how the script works by copy-pasting this and running it with throttling turned on.



<script src="https://cdn.jsdelivr.net/npm/isfastnet"></script>
<script>
isFastNet((value) => {
    if(value){
         console.log("Internet is fast")
    }
    else{
         console.log("Internet is slow")
    }
}, { 
timesToTest: 5, // optional, number of times to load the image, default is 5
threshold: 200, // optional, threshold in ms after which internet speed is considered slow
image:  "http://www.google.com/images/phd/px.gif", //  optional, url of the tiny image to load
allowEarlyExit: true // optional, if the first request takes greater than threshold*3 ms then the function exits with false
})
</script>

Fast internet on Wifi

Slow internet on throttling

The project is open source and I am looking for contributors. Feel free to open issues or fork the project!
Github / npm link

And do leave a "star" if this helps you :)
The stars have no real value, but they make me happy!

Vue and Nuxt tips for everyone

Saunved — Wed, 04 Nov 2020 09:03:00 +0000

I started playing with Vue in June of this year and got into Nuxt within a few weeks. These are general tips that should help both beginners and slightly more experienced developers. I've tried to link the tips to the relevant part of the Vue / Nuxt docs.
Please feel free to add more tips in the comments!

General Vue tips

1. Pass data using props from parent to child components
One of the first things you'll learn is that parent-child data-binding is not two-way and any changes you make to data inside the child component will either throw a warning (or error if using Vuex the wrong way) and result in some massive confusion. So use props instead.

2. Always emit events to pass events + data from the child to parent components
Child components talk to the parent using events. That's how you can propagate clicks, inputs, as well as data back to the parent if required. Vue docs link

3. Use the .sync modifier for two-way data binding between parent and child
Well, yeah - you can technically have two-way data binding between parent and child components. Good use cases for this would be to open or close modals using just one variable synced between the parent and child. The .sync modifier to your rescue. You can find many instances of this used in Buefy

4. Use v-key to force reload a component's state
Due to how Vue's reactivity works, you might end up in a situation where you want to reload a component so that it shows the latest data available instead of some previous data. There are some awesome articles online about how to do this. One of the best ways, is to use the v-key attribute.

This is especially useful when your data is deeply nested or schema-less and Vue is not "reactive" to it.

<template>
  <div>
    <some-component :data="someData" :key="reloadKey"></some-component>
  </div>
</template>
<script>
export default {
  data(){
    return {
      someData: []
      reloadKey: 0
    }
  },
  methods: {
// Imagine this method is called by some external JS 
// in the callback and now the data needs to be reflected 
// in the component
    someCallback(data){
        this.someData = data;
        this.reloadKey++:
    }
  }
</script>

The article where I learned this from.

5. Use computed properties to access Vuex stores
Instead of writing long and arduous lines of text whenever dealing with Vuex, simply use computed properties to get the data instead.

computed: {
  users(){
    return this.$store.state.users.data;
  },
  projects(){
    return this.$store.state.projects.data;
  }
}

And you can simply use these as this.users or this.projects like you normally would for data.

6. Use vuex-persist or localforage to persist data across browser reloads / closes
vuex-persist lets you keep your Vuex store data on browser reloads (acting as a cache of sorts). It also has a localforage option that lets you persist data to IndexedDB using localforage.

7. Use the built-in transition tag
Vue has really good transition support. Before you try out a custom solution, play with the transition system that Vue gives you out of the box (along with a library like animate.css).

8. Don't create components for every little thing
This is more of an opinion rather than a tip.
Vue's component system is really nice and it's super tempting to create components for every "standalone block" of code you find, but DRY is only useful when you are actually repeating yourself. If the "component" you are making is only going to be present in one place...don't make it a component.

General Nuxt tips

I absolutely love Nuxt. It handles routing out of the box, provides a flexible but effective structure to a project, lets you generate SSR as well as static sites, and comes with a lot of good support from the community.

1. nuxt.config.js is awesome
The nuxt.config.js file can do A LOT of things. Read the docs to understand its uses properly first before trying any configurations independently

2. Understand Nuxt routing
Nuxt routing with pages > route-name.vue is quite easy to understand, but there are ways to extend routes using your own data too. Check out this Nuxt doc page. Psst... the configuration is done in nuxt.config.js!

3. The base template
Nuxt loads all your layouts+pages into a file called app.template.html (look for it in .nuxt > views). You can override this file (e.g. to add Netlify forms which are populated before the build step) by adding an app.html file to the root folder. You can basically copy .nuxt > views > app.template.html, paste it as app.html to the root of your project, and edit it to add anything that you want to load to the project irrespective of the application state. Nuxt doc link

4. Understand the various Nuxt folders

layouts
Layouts are the high-level templates of your pages. You can use this to create unique user experiences, or optimize data fetching by layout. Read this Nuxt doc to understand how Nuxt views are structured.

plugins
The plugins folder allows you to load JS code into the application globally. You can use this to create anything from global axios error handlers to adding persistence to your vuex store to loading any libraries that you require across the application. Nuxt docs link.

middleware
The middleware folder is used to store code that runs before a page is loaded. Use it to add auth guards, redirects, etc. You can add middleware to nuxt.config.js, or to any layout or to any page. Nuxt doc link

store
The “store” folder requires an index.js file to be enabled. It allows you to use vuex stores across your application. You can create a separate js file for each store with each file containing its own mutations, getters, etc. Nuxt doc link

These are some of the most used folders. There are other folders which you can read about in the directory structure.

5. this.$nuxt.$emit is awesome
Sometimes you need to emit an event from (say) a layout or a plugin and listen to it on certain pages. Think of scroll handlers, websocket pings, or error handling from global plugins. The usual parent-child event passing paradigm doesn't apply here. In this case, you can use the event bus that Nuxt injects into Vue during initialization.

Pass events from anywhere to anywhere else using this.$nuxt.$emit('event', data) and listen to these like this.$nuxt.$on('event', this.doSomething)

This article explains more.

So yeah, that's about it. I would love to read more tips in the comments from other Vue/Nuxt developers! Also feel free to correct me if I've made an error somewhere :)

How to add an SSH key to an existing DigitalOcean droplet

Saunved — Wed, 02 Sep 2020 14:10:21 +0000

This is a quick and easy method to add the SSH key of your current machine to an existing droplet.
This tutorial is written for Linux users, but you can map the terminal commands to Windows or MacOS commands easily.

(1) Retrieve and save your current public key to a text file

(a) Generate keypair (OPTIONAL)
In case your RSA keypair is not generated yet or you want to generate new keys, simply enter this and follow the instructions:

ssh-keygen -t rsa

(b) Save SSH key to a separate file
Enter the following commands in your terminal:

cd ~
cat ~/.ssh/id_rsa.pub > key.txt

(2) Upload the SSH key to a file sharing service

curl https://bashupload.com/key.txt --data-binary @key.txt

This will give you a link that you can use to download the key. Copy the link and keep it somewhere safe.

(3) Reset your droplet's password

(a) Reset droplet password

If you don't have your droplet's password (which will be the case if you kept SSH as the default access mechanism) then you can reset it.

Your password will be mailed to you. Keep the email open so you can look at the password and type it in on the next step.

(b) Set a new password
Click on "Console" on the top right to open the droplet's console. Enter "root" in the terminal, and then carefully type in the password specified in the email. The DigitalOcean console does not allow you to copy-paste so this operation is a little annoying.

Follow the instructions in the terminal to set a new UNIX password (and keep this password somewhere safe).

(4) Add SSH key to droplet

(a) Run commands as specific user (OPTIONAL)
If you want to add the SSH key for a specific user, you will have to type in the following to execute commands as that user.

su - <username>

(b) Append SSH key to droplet

You will need the link obtained in Step 2 now.

cd ~/.ssh
wget <link-from-step-2>
cat key.txt >> authorized_keys

Make sure you use >> so the new key is appended to the authorized_keys file.

You can now open your terminal and type in

ssh <user>@<ip>

and you should be able to access your DigitalOcean droplet normally.

I faced this issue because I switched to a new laptop recently and forgot to add the new key using the old laptop. It's even more annoying because I have like 7 droplets running on DigitalOcean and I have to do these steps for all of them. C'est la vie!

lemme-know: a server monitor that lets you know when your websites are down

Saunved — Thu, 11 Jun 2020 14:49:39 +0000

Stuff nobody will read
Installation
Usage
- Run locally
- Receive emails
- Change the frequency of tracking
More information

Introduction

I started freelancing as a web developer last year. When people talk about web development, it is usually a lot about how to gather requirements from clients, how to code, how to make good websites, etc.

But what happens post delivery is not discussed as much, especially if you are a solo developer making relatively low traffic websites.

Well, bad things can happen post-delivery.
Sites go down, SSL certificates expire, domains expire, plugins become outdated, libraries get major updates, or your host obliterates your server during a regular maintenance... Phew!

If you have 1 website, you can open it in a browser to test if it is online. But when you're taking care of 10 websites or you have to keep track of microservices, you quickly run into issues. Plus, how long can you even stay up and test if your site is up?

It's not fun to get calls from clients telling you that their site is down. To solve this "site is down" issue, I made "lemme-know". It's a CLI tool that can run locally as well as in the cloud and uses nodemailer to send emails.

Yes, there are plenty of sophisticated monitoring tools out there, but I wanted something minimal with no frills. No complex dashboards, no visitor tracking, nothing. It's a simple script that sends you an email (or a notification) if your site is down and it's free.

A CLI tool that lets you do this per website, called is-up already exists. lemme-know consumes the is-up API and extends it to monitor multiple sites and send emails if one is down.

Let's dig in!

Installation

Make sure you have the latest stable version of Node.

npm i lemme-know -g

Usage

Your list of websites and email settings are supplied via a json file. Feel free to copy the file below and edit it:

{
    "websites": [
        "https://test.example.com",
        "http://example.com",
        "http://another.example.com"
    ],
    "mail": {
        "host": "smtp.example.com", //could be smtp.gmail.com
        "port": 587,
        "secure": false,
        "auth": {
            "user": "you@example.com", // could be your gmail username
            "pass": "supersecretstuff" // could be your gmail password
        },
        "subject": "Website(s) may be down!",
        "sender": "you@example.com",
        "receiver": "you@example.com, yourdev@example.com"
    }
}

You might have to add an app password to Google to run this on a server. Basically Google generates a different password for your account. Just follow the first step over here if you need to.

Run locally

lemme-know settings.json

You won't receive any emails in this mode. You'll be able to see the status of your websites directly in the terminal like this:

Stay informed via email

lemme-know -e settings.json

The -e flag asks lemme-know to send an email
You can use the "-s" flag to run lemme-know in silent mode
If you are running this on a server, you might want to use "screen" to keep the process running even if you logout of the session. You can refer to this article to learn how you can do that.
If you want to kill the process, just find and use the process ID:

kill -9 <pid>

I suggest using Gmail SMTP. Gmail has a generous email sending limit. You could create a new Gmail account for the sole purpose of doing this if you want. That way you don't compromise on security. You are free to use any service you have available, of course.

If you just want to test if the email part works, you can run the code in test mode instead.

lemme-know --test

This will output a preview URL where you can see the email that would have been sent to you if a site was down.

Important note: I have not tested this on Windows. Feel free to open an issue on Github or open a PR to support Windows.

Change the frequency

By default, lemme-know checks every 30 minutes if a site is down. That should work for most low traffic websites.

However, if you need to up the frequency of checks, you can do:

lemme-know -es settings.json -r 10

The -r flag sets the time in minutes between checks. Now the check will happen every 10 minutes.

More information

This tool is not intended for high traffic websites. It's intended for freelancers or small agencies who are managing low traffic websites.

I also highly suggest that you don't ping websites you don't own. Most good sites have DoS checks in place and your IP will get blacklisted.

If your site has DoS checks in place then whitelist the IP you are running the tool on. You can then increase the frequency too.

What if your monitoring server goes down?

It's probably the first thing you think of after you go through the post. To tackle this problem, we could work on a distributed lemme-know. Basically, you could setup a chain of fallback servers in case the primary monitoring server goes down. If the primary server fails, the 2nd in the chain gets activated. If the 2nd one fails, the third server gets activated, and so on.

The cool part about this is that you can make any of your existing servers run lemme-know in the background. No need to spin up extra servers for this.

What next?

The tool currently works on Linux and I haven't tested it on Windows (or Windows servers for that matter).

There most definitely are bugs lurking around. This is just an alpha version. Feel free to fork the code and make it better.

Enjoyed the article? High five!

Or you could, you know, drop me a star on Github.
Check out the Github repo here.

Supporting HTML tags, components, and IDs to create CSS grids in the CLI

Saunved — Mon, 01 Jun 2020 10:25:16 +0000

A few days ago, I wrote about get-grid: a CLI tool for creating CSS grid layouts. A lot of people liked the idea and I got some good suggestions in the comments and on Github.

This post outlines the updates to the query format of get-grid.

The problem
The solution
The new format

I will try to outline problems with the previous query format and show you how the new changes will solve these. If you want to code along, you can install the development version of get-grid:

npm i get-grid@next -g

The problem

The previous query format looked like this:

get-grid --class "container" --query "header/sidebar-content-content/footer"

and gave us this output:

The "/"s indicate a new row and the "-"s indicate a new column. This creates some interesting problems:

We cannot specify classes with a "-"
We cannot write a query that contains custom HTML tags (e.g. web components) or semantic HTML
We can define a container "class", but not an ID or a custom selector
A default margin, padding, background color is being added which many people will ultimately end up removing

In short, the majority of the problems concern the fact that the query defaults to classes as selectors. This can be solved by removing "-" as the separator for columns and by using a little "emmet" magic.

Thanks to the Github issue by taneltm for the suggestions that led to the improvements.

The solution

Let's get rid of the main blocker: the "-" and replace it with a comma. We now end up with this query:

get-grid --query header/aside,content,content,content/footer

Once that's done, let's use our standard CSS selectors instead of assuming that everything is a class.
So, we can do:

get-grid --query header/aside,.content,.content,.content/footer

You can also use #ids, and classes with a "-" or web components if you wanted to. The query will pick up your code and generate the HTML and CSS correctly.

Let's give it a try, shall we?

get-grid --container "body.desktop-site" --query "header/#sidebar,.content,.content/.footer-left,.footer-middle,.footer-right" -dH

the -d flag requests get-grid to add a default margin, padding
the -H flag request get-grid to add a background color and to name the areas in HTML

This is the code spit out:

<body class="desktop-site">

    <header>header</header>
    <div id="sidebar">#sidebar</div>
    <div class="content">.content</div>
    <div class="footer-left">.footer-left</div>
    <div class="footer-middle">.footer-middle</div>
    <div class="footer-right">.footer-right</div>

</body>

    body.desktop-site{
    display: grid;
    grid-template-rows: 1fr 1fr 1fr ;
    grid-template-columns: repeat(3, 1fr);
    grid-gap: 1em;
    }
    header{
    grid-column: 1 / 4;
    grid-row: 1 / 1;
    padding: 1.5rem;
    background: #eaeaea;
    }
    #sidebar{
    grid-column: 1 / 2;
    grid-row: 2 / 2;
    padding: 1.5rem;
    background: #eaeaea;
    }
    .content{
    grid-column: 2 / 4;
    grid-row: 2 / 2;
    padding: 1.5rem;
    background: #eaeaea;
    }
    .footer-left{
    grid-column: 1 / 2;
    grid-row: 3 / 3;
    padding: 1.5rem;
    background: #eaeaea;
    }
    .footer-middle{
    grid-column: 2 / 3;
    grid-row: 3 / 3;
    padding: 1.5rem;
    background: #eaeaea;
    }
    .footer-right{
    grid-column: 3 / 4;
    grid-row: 3 / 3;
    padding: 1.5rem;
    background: #eaeaea;
    }

And this is what we get when we paste it to HTML:

And yes, the generated HTML respects the selectors and generates code the way emmet would (because the emmet library is being used to generate the HTML!).

The new format

I feel like the query format is slightly more "complete" now. In case you need a quick reference:

/ to indicate a new row
, to indicate a new column ( previously '-' )
selectors must be specified explicitly (i.e ".class" instead of "class"). You can specify IDs and HTML tags the way you would while writing CSS selectors.
The container is specified using --container (or -C) instead of --class. You can specify any valid CSS selector for the container
The default padding/margin and colors are removed. You need to use the -d and -H flags to get those in your CSS

You can read the help provided along with the tool:

get-grid --help

It outlines some other flags that allow you to get only the style, or only the HTML, or print output to the terminal, etc.

How much less code are we writing?
If we look at the query above, it consists of 129 characters. It generates a layout with 1132 characters of code. That's 8.7 times less code to write!

There are some other enhancements that can be made to the query format (such as being able to specify heights and widths for rows and columns). I will be working on this in the coming weeks.

The next stage would be to write a basic test suite and to find out other problems with the query format. Check out the Github repo here. I'd love to work on more enhancements and to fix any existing bugs. Feel free to fork and create pull requests and don't forget to mention if you are working on something!

Do leave a star if the tool helps you :)

A CLI tool for creating CSS Grid layouts

Saunved — Fri, 29 May 2020 10:02:43 +0000

CSS Grid is awesome for creating all sorts of HTML layouts without having to rely on any external libraries. It supports 95.49% of major browsers according to caniuse (my condolences if you need to support IE).

Update!
Quick introduction
Benchmarking | Creating columns and rows dynamically
Getting an upgrade | Hardcoding common layout presets
We need to go deeper | The thing I want you to see the most...Dynamically generating CSS grids

Update

Updated on 1 June
Based on the suggestions and comments to this post as well as this Github issue, get-grid@next is under development. A lot of important fixes have been made to the query format to accommodate for HTML tags, web components and IDs.

Please read the 2nd post of the series here to understand the new format.

These changes primarily affect the query format that is explained in the last section of this post.

Quick introduction

Creating layouts with CSS grid is pretty simple, but it's always good to write less repetitive code (I can hear a collective yes).

I started looking for ways in which I could generate CSS grids quickly.
I found a few generators online. This list on SitePoint covers many of them. I also found articles that gave you the code of some common layouts (like the Holy Grail), that you could copy-paste.

The drag-and-drop grid generators are great, but I was looking for something a little more ...dynamic.
What if you could create a CSS grid layout using the CLI? One that was very easy to read - so easy that you could probably use it to generate layouts dynamically and inject them at runtime?

The applications of this are pretty fun to think of.

You can create a basic grid with 90% of the code pre-written in your command line itself
Writing media queries will be a breeze
(And if we are day-dreaming)... You could write a natural language processor that plugs into the underlying code. So someone could say, "Create a header that spans the full width. Now add a sidebar below that by making it a quarter width. Fill the rest of the row with the content..." and the words would be transpiled to a command that generates the code.

But I am getting a little too ahead of myself here.

Let's start off simple and understand how the CLI works. To create the CLI, I am using commander.js.

If you want to code-along, you can install the package from npm using

npm i -g get-grid

The most basic command you can try is:

get-grid

The tool copies the grid to your clipboard, but in case this doesn't work, just use the --output flag.

get-grid --output

And you can just do

get-grid --help

for some quick help

Level 1 - benchmarking

I started off simple:
The user should be able to specify the number of rows and columns they want, along with the parent container class.

So, to create a 2-column, 2-row layout, one would simply do:

get-grid -c2 -r2 --class grid-holder

And voila! The generator spits out this code:

<div class="grid-holder">
    <div>1</div>
    <div>2</div>
    <div>3</div>
    <div>4</div>
</div>

.grid-holder{
display: grid;
grid-template-columns: repeat(2, 1fr);
grid-template-rows: repeat(2, 1fr);
grid-gap: 1em;
}

Some properties are set by default as you will notice.
It's pretty basic, pretty rudimentary. It's still faster than typing it out by hand though, and it's faster than drag-and-drop too.

Time to turn it up a notch.
For the next level, I wanted to be able to type out the layout I wanted in the simplest way possible.

Level 2 - getting an upgrade

Creating common layouts quickly is very handy. I hard-coded a few common layouts and plugged them into a switch case. It's nothing innovative or great, but it generates the common layouts nonetheless.

So you can just do:

get-grid --template holy-grail

and you get this code:

<div class="grid-container">
        <header>
          Header
        </header>

        <aside class="sidebar-left">
          Left Sidebar
        </aside>

        <article>
          Article
        </article>

        <aside class="sidebar-right">
          Right Sidebar
        </aside>

        <footer>
          Footer
        </footer>
</div>

.grid-container {
        display: grid;
        grid-template-columns: 150px auto 150px;
        grid-template-rows: repeat(3, 100px);
        grid-gap: 1em;
      }

      header,
      aside,
      article,
      footer {
        background: #eaeaea;
        padding: 1em;
      }

      header, footer {
        grid-column: 1 / 4;
      }

Which gives us this layout:

I have taken this layout directly from Codepen.
I haven't created many pre-defined layouts, but I am thinking of interesting ways in which one can create presets and name them for use later on.

As the screenshot suggests, the tool was supposed to be called "grid-this", but I like "get-grid" better.

This was still not the "dynamic-ness" that I was looking for. I wanted to be able to specify how the layout looked (via the CLI) and the code would be generated dynamically.

Level 3 - We need to go deeper

Update
The query format has been changed slightly to take care of IDs and semantic HTML as well as web components. You can check the 2nd post of this series to understand the changes here.

For this step, I had to devise a query notation of sorts; one that was concise; did not take a lot of time to think up, and could be taught quickly.

Here's what I came up with:

header/sidebar-content-content-content/footer

The "/" indicates a new row and the "-" indicates a new column. If an entire row is taken up by the same area, there is no need to specify it again.

So, what do we get out of this?

get-grid --query header/sidebar-content-content/footer

The code being spit out:

        <div class="grid-container">
            <div class="header">header</div>
            <div class="sidebar">sidebar</div>
            <div class="content">content</div>
            <div class="footer">footer</div>
        </div>

        .grid-container{
            display: grid;
            grid-template-rows: 1fr 1fr 1fr ;
            grid-template-columns: repeat(3, 1fr);
            grid-gap: 8px;
            }

         .header{
                padding: 1rem;
                grid-column: 1 / 4;
                grid-row: 1 / 1;
                border: 1px solid #444;
                background: #eee;
              }

          .sidebar{
                padding: 1rem;
                grid-column: 1 / 2;
                grid-row: 2 / 2;
                border: 1px solid #444;
                background: #eee;
                }

           .content{
                padding: 1rem;
                grid-column: 2 / 4;
                grid-row: 2 / 2;
                border: 1px solid #444;
                background: #eee;
             }

            .footer{
                padding: 1rem;
                grid-column: 1 / 4;
                grid-row: 3 / 3;
                border: 1px solid #444;
                background: #eee;
                }

If you paste it to an HTML file, you get:

And this really is dynamically generating this layout. The code is parsing your query (twice) and generating the grid-column and grid-row properties. The query reads like a natural language, so creating simple layouts dynamically should be possible in theory.

So using this query:

get-grid --query
header/sidebar1-content-content-content-sidebar2/
footer1-footer1-footer2-footer2-footer3-footer3

We can get this:

It works, and it's simple, and it's dynamic! Yay!
But let's not get ahead of ourselves. This is a prototype, something I cooked up in a few hours (and I am still fixing bugs while writing this article). It has A LOT of things missing (some that I might not even be aware of).

I have a few ideas for how certain things could be improved. I will try to explain them in a Q&A format:

1) How to specify a custom height for a row?
For specifying height, the query could contain a ":" operator. Hypothetically speaking, it could be something like this:
header:60px/sidebar-content-content-content:auto/footer:200px

2) What if only a specific row or column repeats? What if a class spans across rows (rather than columns)?
To handle repeats, we could use a variation of "-" along with a "*" and "#" operator.

We could do header/sidebar-content-3/footer to repeat the entire row thrice, increasing the row-height to 3fr (the "-3" is not detected as a class since CSS classes cannot start with a number).
And header/sidebar-content*3/footer to repeat ONLY the "content" column thrice (keeping the row height 1fr)
Or header/widgeta#2-content#3/widgetb/footer to keep the widgeta height to 2fr but increasing the content height to 3fr. "widgetb" will then fill up the 1fr space.
We can also change the grid-auto-flow property by setting a flag.

3) What happens if an area is empty?
If we wanted to have a blank area where widgetb is, we could use a "." operator, by doing header/widgeta#2-content#3/./footer

4) What happens if you want to write classes with a "-"?
I tried using an operator other than "-" for separating the columns, but it drastically reduces readability and becomes much less intuitive in a reading. To get around this issue, we could use an escape character like "\" to specify -'s that are not a part of the query itself.

I have not thought of all the possible cases and the above ideas are hypothetical. I will be working on these as the days pass. In the meanwhile, you can check out the GitHub repo. Do drop me a star if this tool helps you :)

Looking forward to comments, ideas, suggestions, and criticism!

The better web developer

Saunved — Thu, 16 Apr 2020 14:33:54 +0000

When I first got into web development in 2017, the epitome of being a good developer (for me) was understanding jQuery and being able to use it efficiently. Little did I know that jQuery was almost "dead" back then, as this article shows.

After dabbling in WordPress for a while, I wanted more control over the inner workings of the website. I wanted to make good, dynamic websites. I was taken towards the framework road - and to be precise - down the Angular path. I didn't quite understand WHY a framework was needed back then.
"I can just do it with jQuery, no?" was a question I asked a lot.

The first "burnt" experience I had with jQuery was when I had to make a webpage with multiple forms that updated asynchronously and whose updates changed multiple parts of the DOM.

After a week of struggling with the code (and managing 20-25 element IDs and their linking in jQuery), I turned to my co-developer and said, "Let's use Angular please."

That was my first, important lesson towards becoming a better developer.

#1 Knowing something doesn't mean that it's the solution

The migration to Angular took a few hours and the form updates were effortless. We never needed jQuery. What we really needed was two-way binding.

The lesson hadn't quite sunk in though. Now that I understood the basics of Angular, I wanted to use it everywhere. jQuery wasn't really required, so what? Angular was the one-stop-shop. It could do everything!

My love of frameworks and the "magic" that they could do would be questioned soon. We had made a single page application with Angular. It had two forms and some lists that came on and off the page based on some conditions. The use-case was not really complex. We made the frontend using Angular but looking back at that project, I can see an important lesson in it.

#2 Vanilla JS is good enough for a LOT of things

Sure, Angular handled the 2-way binding and made form handling easier. But there were just two forms which weren't even dynamic. Just because Angular was available and we knew it, didn't mean that we had to use it. It may have sped up the process, but we could have tried a vanilla JS approach and it would have worked fine.

Over the past few months, I have spent a lot of time making tiny projects and learning from experience. Here are a few other lessons that are helping me become a better developer:

#3 Never underestimate the power of good naming

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

Writing

var ch

as

var clickHandler

can save you minutes, if not hours of going back and forth to understand your own code in the future. Keeping a habit of reviewing your code and assuming that you can improve it often helps in actually improving it.

#4 Learn Vanilla JS properly before diving into frameworks

More often than not, it helps to imagine how vanilla JS could play out instead of just jumping into a React, Angular or Vue project. Especially if you are just starting out - don't jump into a framework. Learn Vanilla JS first - it's very powerful all by itself, and even if you have made the wrong decision picking it for a project, it will help you appreciate why we need frameworks!

#5 Cut your veggies for later

It's a good idea to have a system in place. For example:

If you know you're going to keep spinning up servers for MEAN projects, save an OS image on the cloud with all your pre-configured settings
It helps to create code snippets and store them in a folder called "snippets" (very creative, I know). This can include stuff like database initialization, complex database queries, HTML templates, login, signup flows, CRUD operations, common CSS rules, etc.

I used to keep opening old projects and copy-pasting from them. Whenever you have to do that, just make a file in your "snippets" folder, name it appropriately and look there the next time!
This is just the DRY principle put in use across projects.

#6 Reading open source code helps. A lot

Many times we tend to get locked into our own world and our own code. It's cool to open some libraries we use and check out how the code has been written and organized. That can spark ideas, and even make us better coders in the long run.
For example, the often-used "_" before function or variable names in projects used to bother me immensely until I read up on what it meant.

We learn new things every day. For example, I learned this recently: The 300ms problem, where on small devices, the screen waits for 300ms before passing the event to the click handler. This was to wait and check if the event was a double-tap to zoom!

Although the article above says that the problem was solved, I could still see this 300ms wait behavior on button clicks when I resized my browser to less than 364px! The meta tag didn't help either, so I had to go with the html-manipulation trick from the same article. I'm still not sure why 364px was the barrier for this bug (and I'd love to have a discussion on it if you guys can reproduce the error).

I'd love to hear about something new that you guys have learned recently. Feel free to leave a comment below!

DEV Community: Saunved

What the heck is Prototypal Inheritance? Part 1: Object Prototypes

What is an object prototype?

70 lessons from the last year as a developer and co-founder

Life

Business

Tech and UX

Tech for everyone

Tech for developers

How to add Supabase to Nuxt.js

Prerequisites

How to add Supabase to Nuxt

isfastnet: a tiny script to find out if your user's internet is fast or slow

Vue and Nuxt tips for everyone

General Vue tips

General Nuxt tips

How to add an SSH key to an existing DigitalOcean droplet

(1) Retrieve and save your current public key to a text file

(2) Upload the SSH key to a file sharing service

(3) Reset your droplet's password

(4) Add SSH key to droplet

lemme-know: a server monitor that lets you know when your websites are down

Table of contents

Introduction

Installation

Usage

Run locally

Stay informed via email

Change the frequency

More information

What if your monitoring server goes down?

What next?

Supporting HTML tags, components, and IDs to create CSS grids in the CLI

Table of contents

The problem

The solution

The new format

A CLI tool for creating CSS Grid layouts

Table of contents

Update

Quick introduction

Level 1 - benchmarking

Level 2 - getting an upgrade

Level 3 - We need to go deeper

The better web developer

#1 Knowing something doesn't mean that it's the solution

#2 Vanilla JS is good enough for a LOT of things

#3 Never underestimate the power of good naming

#4 Learn Vanilla JS properly before diving into frameworks

#5 Cut your veggies for later

#6 Reading open source code helps. A lot