DEV Community: Harsh Joshi

Pasting images in claude-code now works!

Harsh Joshi — Fri, 15 Aug 2025 08:45:00 +0000

The Problem

Claude Code users cannot paste screenshots or images directly into the terminal using standard keyboard shortcuts (⌘V/Ctrl+V). Current workarounds require saving files and drag-dropping, breaking the keyboard-centric workflow.

The Solution
https://www.producthunt.com/products/claude-utils

New MCP Testing Framework

Harsh Joshi — Fri, 13 Jun 2025 08:52:54 +0000

Check out this MCP Server Testing framework which lets you test MCP Servers on CLI, CICD, and anywhere you code as a test suite

https://www.npmjs.com/package/mcp-jest

Introducing MCP Server Boilerplate: Build Extensible Python MCP Servers for LLMS and Agents

Harsh Joshi — Sun, 20 Apr 2025 20:38:17 +0000

MCP Server Boilerplate (Python) 🚀

I'm excited to share MCP Server Boilerplate, a production-ready, extensible template for building Model Context Protocol (MCP) servers in Python. This project is designed to help you rapidly create, extend, and deploy MCP servers that expose tools, prompts, and resources to LLMs and agentic clients.

✨ Features

Multi-Transport Support: STDIO, SSE, HTTP, and more
Modular Tools/Prompts/Resources: Add new features by creating a class and registering it
Type-Safe Input Validation: Uses Pydantic for schemas
Security Best Practices: Directory sandboxing, input validation, error handling
Extensible & Maintainable: Clean separation of concerns, base classes, and registries
Production-Ready: Logging, environment management, Docker support
Comprehensive Documentation: For users and contributors

🛠️ Getting Started

Install dependencies:
pip install -r requirements.txt
Configure environment: Copy .env.example to .env and fill in required values.
Run the server: python main.py --transport=stdio

Why MCP?

Model Context Protocol (MCP) is a new standard for exposing tools, prompts, and resources to LLMs and agentic clients. This boilerplate is the recommended starting point for all new Python MCP server projects.

Check it out, star the repo, and let me know what you build!

Concurrency Model in Javascript

Harsh Joshi — Mon, 18 Jul 2022 18:58:00 +0000

Also find this article on Scaler Topics

The idea of concurrency in a language which runs on a single thread is an interesting one. For those of you who don’t already know, concurrency is simply doing multiple things at the same time. Just like you are doing different stuff in different tabs while you’re also reading this.
Imagine you were bound to do only one thing at a time. No Netflix while you eat! Sure that might help you focus but in your day to day life, but you might feel less productive.
Your resources are getting under utilised. Not just that, you see your contemporaries who are able to multiple things at at the same time. The outline of this article is precisely this. Instead of you, it is javascript we are going to talk about.

💡 Since you are here reading about event loop in JS, this article assumes that you are well aware of the fundamental principles of Javascript. You could start looking at “Link” to read about the fundamentals.

Javascript started as a single threaded synchronous language. A programming language which is supposed to run on a single thread means that this will be able to do only one thing at a time. Doing one thing at a time will require it to follow some order of execution. It is thus called synchronous.

In case of synchronous Javascript code will be executed line by line.
Here’s an example:

let a = 5;
let b = 10;
let c = b/a;

print(c)

Each line is executed one by one. Synchronous code is also called as blocking. This is because line 2 can’t be executed until line 1 is not done executing. You might not realise the “blocking” in this example because operations are usually quick.

let a = 5, b = 10;
let result = thisCalculationTakesTwoMinutes(a,b)
let c = 15, d = 30;
let result2 = d/c;
print(result2)

In the above example, line 2 involves a calculation which takes two minutes to complete. While this call is happening you can’t really go to line 3, even if the computing capacity of your machine has capability to do more at that time.

💡 This is where the concept of concurrency becomes important in Javascript. Given that the language is single threaded unlike other languages like Java which can use multiple threads to achieve concurrency, this curious case of concurrency in JS becomes further interesting.

With the advent of concurrency, javascript took “your child can do more” very seriously. Before we come to talk about concurrency in detail, let us try to define some fundamental concepts that are closely associated.

Single Threaded:
Javascript is a single threaded language. This means all applications ever written using Javascript will use only one thread to run. This idea of single thread is unpopular among the likes of languages like Java, and Python which use Multithreading. (Doing multiple things with more than one thread at once). Single threaded also means that the order of execution is always one at a time.

Non Blocking:

To put it simply, non blocking means that the execution of the program will not be blocked because of some code which takes unusually long to execute. If line one has a slow operation, it should not block line two from executing. Didn’t we just want that?

Asynchronous: Asynchronous means that two or more tasks can happen in parallel. This might sound contradicting to what you read above, but it’s true. In Javascript you can actually do many things at once. We will dive deeper into in the lines to come.

How does code execute in Javascript?

To maintain the order of what’s currently running, Javascript uses a stack while executing the code. You might already be aware that the executions happen inside execution contexts. If not, think of executions contexts as javascript objects that contain the execution of code. Functions have local executions contexts which are generated when the functions are called and everything else is run on the global execution context.

The execution context of the code currently being executed will be on top of the stack. Once it is done execution the execution context is popped out of the stack. This data structure is famously known as the call stack.

Let’s understand with an example:

let sayHello = (name) ⇒ { console.log(`Hello ${name}` }
let sayBye = (name) ⇒{ console.log(`Bye ${name}` } 
let communicate() = (thingToSay) = {console.log(`${thingsToSay`)}

console.log(”Communication Started”)
sayHello("Harsh")
communicate("This is how code is executed in JS")
sayBye("Harsh")
console.log(”Communication Over”)

“Doing things” in Javascript is achieved using a call stack and JS Engine. While JS Engine executes the code, the call stack maintains the order of execution. To begin with, think of call stack as an ordinary stack (the data structure) which holds some objects. The top of the stack is the object representing call in current execution, which upon completion/termination will be popped out and the control will be passed to the next call/ execution context.

Though this is not related here but you should note that sayHello, sayBye and communicate are functions expressions and hence initialisation for them will differ from function declaration.

Here’s what shall happen during execution of the above code.

A global execution context is created and immediately put on the call stack which was earlier empty. Once the context is in the call stack the JS engine begins executing the code.
When the control reaches line 4, it logs “Communication Started” on the console.
On reaching line 4, the control finds a function invocation which creates a local execution context, immediately the execution context of sayHello is put on top of the call stack.
JS Engine will only execute the code within the context of the top element of the stack and hence the code inside sayHello begins executing and “Hello Harsh” is printed on the console.
Since there is no code to further execute The context of sayHello is popped out of the stack and the control moves to the next line.
The control finds another function invocation and the process from 3 to 5 happens for the communicate function. As a result “This is how code is executed in JS” is printed on the console.
When control reaches next line, similar process follows and “Bye Harsh” is printed on the console.
Now, the control is back with the global execution context which was only half done executing. The control starts executing from where it left off and “Communication Over” is logged
Since there is no code left in the global execution context, that is always popped out of the call stack and call stack is empty.

But where is Concurrency?

Concurrency is the ability to do multiple things at once. It comes with asynchronicity which is the soul of the present day Javascript. It bring along another special data structure called a callback queue. Let’s try to understand with a classic example of setTimeout.

Yes, setTimeout introduces most of the developers to the soul(asynchronicity) of Javascript. Whether it has any other use is a debate for another day.

setTimeOut accepts two parameters, a callback function and time in mili seconds.

Back to an example:

console.log("Start")
setTimeOut(function delayThis(){console.log(”This will be delayed”)}, 5000)
console.log("End")

What do you think will be the out of the above lines of code?

Whenever setTimeOut is called, the call stack now contains setTimeOut and waits for the delay to happen before moving on the next line
When setTimeout is called, the function call goes to the top of the call stack but is immediately popped. The next line gets executed immediately (without waiting for the delay)

Let’s try to understand the order of execution here. When the code begins executing, the first thing that is logged on the console is “Start”. This is pretty obvious.

When the control comes to second line, setTimeout is called and a callback function is registered for future execution.

💡 If you don’t already know, a callback function is a function which is passed to another function as parameter. Since functions are first class citizens in Javascript they can be passed or returned from another function. You can read more about it on this “blog url”

The control does not wait for the delay to happen. Essentially delay does not mean “a delay in the program” rather it means “a delay in execution of the callback function”. Both are very different things.

Next up the control immediately moves to the third line and the execution context associated with calling of setTimeout is destroyed. When this happens, the callback function is still in the memory just not in that execution context. When it was being registered the callback function is moved to a different memory unit. When the callback is ready for execution (10 seconds have elapsed) for execution, it is moved backed to a data structure, just like all functions calls are moved to call stack for execution.

💡 Note: Not all callbacks have same priority. Some callbacks use a special queue known as the micro task queue/Job queue which has higher priority order than callback queue. It introduces more interesting concepts like starvation in a queue. Job Queue/microtask queue is out of scope of this article but you can read more about it here [URL]

Here’s a more practical example:

console.log("Start")
asyncNetworkCall()
console.log("End")

💡 Assume that the asyncNetworkCall is implemented as an asynchronous function. Which means while the network call is still in function, the control is able to move to line 3 and log something to the console.

Event Loop

Before we start talking about Event Loop. Let’s go back to the building blocks again. There is some javascript code hanging out with your favourite code editor. We know by this point that JS Engine and the call stack are the primary things responsible for running the javascript code. In order for the code to be executed it has to be brought on the call stack for JS Engine to execute it.

Now recall the callback function in the example above. Last we heard of it was when it was in some fancy new memory unit called the callback queue. After 10 seconds have passed, it has to be executed. Event loop is such a mechanism which handles this. This means it manages the lifecycle of a callback function from the callback queue to the call stack.

💡 Whenever you read about event loop next, think of it as a mechanism than anything else.

But How does it work?

Let’s begin with stating the universal truth - “A call stack will have to be empty for event loop to bring anything in it”.

Whenever the call stack is empty, the first entered unit in the callback queue is brought to the call stack by the event loop which was observing both call stack and callback queue.

💡 Did You Notice?
setTimeout of a ‘n’ seconds does not guarantee execution exactly when ‘n’ seconds have passed, rather it guarantees a minimum delay of ‘n’.
This is because after a defined limit, the callback function moves to the callback queue (stating ready for execution) where the event loop is supposed to pick it for actual execution.

A very interesting piece of information about event loop is an event loop does not block. Operations that might potentially require waiting are performed using callbacks and events.

💡 Event loop Visualisation.

Summary:

JS is single threaded. It has only one call stack.
Execution of code in javascript is always. line by line
Code in javascript is executed by JS Engine which uses the call stack to determine the order of execution
Event loop is a mechanism through which the ‘calls waiting for execution’ in the callback queue/job queue can be put on the call stack.
For any event from callback queue/job queue to come to call stack, the call stack will have to be empty.

Fun Experiment: Bringing lazy execution to JS!

Harsh Joshi — Mon, 17 Jan 2022 09:53:04 +0000

Bringing lazy execution to higher order functions in JS!

How to Use

Install the package
npm i lazy-hofs
Add to your project
require("lazy-hofs");

lazySome()

let arr = [1, 2, 3, 4, 5, 6];
let ref = arr.lazySome((it) => {
  return it === 9;
});
arr.push(9);
let result = ref.lazyEvaluate();
console.log(result);

lazyMap()

let arr = [1, 2, 3, 4, 5, 6];
let ref = arr.lazyMap((it) => {
  return it * 9;
});
arr.push(9);
let result = ref.lazyEvaluate();
console.log(result);

lazyFilter()

let arr = [1, 2, 3, 4, 5, 6];
let ref = arr.lazyFilter((it) => {
  return it % 2 === 0;
});
arr.push(9);
let result = ref.lazyEvaluate();
console.log(result);

lazyReduce()

let arr = [1, 2, 3, 4, 5, 6];
let ref = arr.lazyReduce((it, acc) => {
  return (acc += it);
}, 0);
arr.push(9);
let result = ref.lazyEvaluate();
console.log(result);

Join me here: https://npmjs.com/package/lazy-hofs
Contributions welcome!

The UI revolution on Android: Jetpack Compose

Harsh Joshi — Tue, 02 Nov 2021 17:47:20 +0000

It is a product led world. Products today are design led. Design further is experience led.

As much as a product is an experience, It is also a relationship and an expression.

Jetpack compose is a new way of expression in the world of native android apps.

You must already have experienced the depth of such a relationship when you took your phone to washrooms, scrolled to sleep with Instagram or checked Whatsapp notifications as the first thing in the morning.

Today's product is not just "How it works" but is also (perhaps more) an expression of "How it feels".

The essence of a product as a relationship and expression is far more than just a mere usage.

Jetpack Compose is here to make this process fast, accelerated and efficient.

What is Jetpack Compose?

Google developer docs define Jetpack compose as "Android’s modern toolkit for building native UI."

So far so good. Looks like Android team has done something new to better UI development for native android applications.

The docs further go on to say, "It simplifies and accelerates UI development on Android. Quickly brings your app to life with less code, powerful tools, and intuitive Kotlin APIs.".

In the past, UI on native android was expressed using a combination XML layout + Java / Kotlin files. Many would argue that in the world of React it was a boring way of doing UI.

Jetpack Compose enables you to write your UI in Kotlin.

Woaahh, that's big news for people having adapted to writing native android apps in Kotlin. But does this affect you if you are writing native android apps in Java? Perhaps not!

As many say, the right time to move to Kotlin was a year ago but if you haven't already, the right time is now. I will write more on what I think about Kotlin in a separate blog.

But why Jetpack Compose?

Android Developer Docs answer this question in a very elaborative way here.

Intuitively, it seems like an upgrade. One might argue on its need in the mobile world but this is much power given in a much needed space.

All Kotlin and no XML makes Jack's app development fast, efficient and wise.

Write less code - It's all Kotlin and no XML now. With jetpack compose it is possible to write UI with 'dramatically less code'
It's Declarative - If you are coming from the world of react, you might know what a delight declarative UI is. Declarative API simply means all you need to do is describe your UI. Read more here.

Design challenges it Addresses:

Jetpack compose is a well thought of upgrade. It addresses some key design challenges of the native android world.

One of which is "Separation of Concerns".

Here is an example-

You have a View Model written in Kotlin. This view Model interacts with the XML layout file. The degree of coupling between these two tends to be high. (If you don't already know, you can know about coupling here

Tighter the coupling, more the dependency. If these two are so intimately connected, why the separation of Kotlin and XML? What if you could write the layout in Kotlin rather than XML?

If you think wisely, this is not violation of "Separation of Concerns" rather it tries to manage the 'separation' for you. And how you ask? Through something called a "Composable Function". We already have used many many functions to separate the concerns in the past. This is not different.

Here's how it looks like:

@Composable
fun NameOfFunction(){
    Text(text = "Hello Compose")
        Button(text = "Say Hello", onClick = {
            // handle a click event here
        })
}

Read this well written piece to understand Composables in more depth.

The other one - Source of Truth.

Imagine having an app that has a dropdown. The dropdown lets you choose between options pizza, burger, and orange slice. You chose pizza and a major network call followed which somehow failed. What is the truth of your selection now? Is it the dropdown which still shows pizza as selected choice but in reality there is no choice. I know it is confusing.

Jetpack compose solves it by introducing "State". State is the single source of truth now. You do something on UI, the state changes and so does the truth.
You can pass state to composable functions just like props in react. It observes for changes in the state and updates itself accordingly. The onus of updating the state is not on it anymore.

Read this great piece on state and single source of truth to know more about it. Although this blogs takes react into account to explain the concept of SSOT, it will help you get more clarity

Who's already using Compose?

From Twitter to Play Store to Pinterest app, many have chosen Compose. This space will help you discover more on who's using compose?

Resources you can utilise to learn more about Jetpack Compose

I know this blog did not do the best job to explain everything about Jetpack compose but it didn't intend to. I hope it introduced you (If you hadn't already heard) and got you excited about it.
Jetpack Compose looks very promising and would set a new benchmark in the world of native apps.

You can utilise some great resources on the internet to learn more about Compose. I am mentioning a few good ones that I came across here:

"Why Adopt Compose" by Google Developers
Understanding Compose - Android Dev Summit, 2019
Understanding Jetpack Compose (II Parts) - Android team on Medium
Getting started with Jetpack Compose on Section.io

Your startup & the conspiracy of numbers

Harsh Joshi — Thu, 09 Sep 2021 16:20:12 +0000

Measuring Success in a startup ecosystem has its own caveats. Ever since I have gotten a little familiar with it, every day brings a new perspective. It's a jargony world of OKRs and KPIs,
This blog aims to establish the role of overlooked principles, factors, and anomalies resulting in deviation and uncertainty in such measurements. It tries to set the perspective of intuitive bias in decision-making, pre-planning, and reinforcement learning. It goes on to talk about Simpson's paradox, North Star Metrics, and much more.

Numbers are weird. This morning I decided to count all numbers till infinity, could not reach one!
This Saturday, it randomly hits you to pull up the NPS numbers for the startup you are building. You come to realize that one of your competitor’s NPS score has moved up 3 points from 73 to 76 while your NPS has reduced by a point from 75 to 74 for this quarter. The numbers don’t concern you as much as the PR around this news does. You don’t have the highest NPS score in the industry anymore. You pick coffee to tea today and decide to investigate the cause.

You are building a startup that promises to bring a revolution. You offer work-stress relief services to businesses for their employees. You now want to understand the reason behind this marginal dip in your NPS score. On going through the data, you realize a causal relationship. Out of 600 users who availed of your service, 500 of them reported positive results immediately while the remaining had less/no significant effect on their stress levels. On the contrary, your competitor surprisingly had the same number(600) of users for this quarter too, out of which 520 users reported immediate positive results.

On a normal day, you would accept these figures as the right metrics and solely work on improving your service but today’s a little different. It’s Elon Musk saying no to cryptocurrencies and Kunal Shah not tweeting anything for more than 3 days. You decide to stay put.

After a day of long brainstorming discussions with your team, you narrow it down to one conditional variable, “The level of stress”. Out of 600 users who availed of your service, 250 had severe levels of stress. (They acknowledged this information in the service request flow). Out of these 250 users, your product could bring down the stress levels of 155 users. On the other hand, your competitor had 100 cases of highly stressed users and it could successfully settle stress levels of 40 users.

Quite absurd it may sound, but as it turns out your service was better for low-stressed users too. Out of 350 less stressed users, 345 of them got rid of their stress using your service but out of 500 low stressed users, your competitor could successfully handle the stress of 480 users.

Look closely, while the total numbers are stating something, the individual numbers are telling a different story altogether. Yes, high stressed and low stressed are the only categories of users.

How could this be true? It indeed is, and this is called the Simpson’s paradox. Simpson’s paradox occurs when the same set of data can show opposite trends, depending on how it is aggregated. This often occurs when aggregated data hides a conditional variable, also known as the lurking variable.

In other words, the relationship observed within a population (i.e. a group of individuals), could be reversed within all subgroups that make up the population. Simpson’s paradox comes in two parts:

The fallacy of Division: What is true of the whole is not always true of the parts
The fallacy of Composition: What is true of the parts is not always true of the whole
What exactly happened in the story above was there was a significant difference between the number of highly stressed users availing both the services. The lurking variable here was “level of stress at the time of availing the service”.

This story had some insights to take. But this isn’t the only one where numbers can outplay you. Simpson’s paradox is just an example of how important it is to manage numbers that deal with key success attributes for your startup. Statistics is vital for any business. While most of it can be simply right, fair, and straightforward, there are some anomalies and paradoxes.

But wait, what did all this have to do with NPS score? NPS score is calculated based on the difference between promoters and detractors, both of which are your own users. So why did the NPS go down if both high and low stressed patients had better servicing rates than your competitor?

Are these two even related? Looks like I will have to believe in you to solve this one :)

When you are building a startup, one of the most crucial things is a clear set of objectives. Investor Sean Ellis coined the term North Star metrics to give a singular goal of growth across teams. You might even come across this conspiracy of numbers while evaluating your performance towards north star metrics. For SaaS startups, the north star metrics should be the most important metrics for measuring product success and the very notion of a conspiracy in this measurement is daunting. There should be thoughts to examine how such conspiracies can live in all dimensions of your north star metrics. From a SaaS point of view, If you define the metrics as the number of users signing up every month for a service that renews every month, you might be misdirected by the numbers. This metric shows the total users who signed up since the very start. Among this aggregated data there might be many clusters. Instead of it, you might want to keep in account the number of returning users every month which gives better objectives and saves subtle misdirection. (or does it?) This dimension is called the breadth in north star metrics. There are more dimensions to it. Frequency specifies the number of monthly purchases/subscriptions/orders per user which might/might not be a good metric instead of total orders placed this month.

The reason why I am not sure is because of something called the “Pareto Principle". You might also know it as the 80/20 rule. It asserts that 80% of outcomes (or outputs) result from 20% of all causes (or inputs) for any given event. This accounts for notions like 20% of health crops make 80% of total grains. Now when you consider the total number of orders placed in a month, this might be a case of one large purchase. You might not agree with me here, but it most certainly is about the objectives you choose. You understand what you are building better than anyone else and you might want to capture a few things as they come.

Typically, the right measure of product for a SaaS would be frequency instead of total purchases. To add to it, another dimension called “depth” which means total items per order comes into the picture.

While the above three dimensions talk about users’ interaction with the product. The fourth one, called "Efficiency" talks about your offering. For a SaaS, it might be the percent of orders delivered in time.

I think we got a little deviated here, but it was important to understand how and when the numbers can conspire. A large attribution of it goes to our own psychological biases, but we are made that way. Most of the large-scale businesses set multiple north star metrics. While it might suit/complement your business needs and goals it also can lead to confusion as to what the real objective is. However, having sub metrics over multiple north star metrics might be helpful.

To be continued...

Next up:

Decision Factors in choosing the right metrics
Simpson’s paradox in NPS and Production Adoption Rate
Metamathematics and Anomalies
The startup paradox
The Game theory challenge to startups.

Approaches to Serverless Deployment

Harsh Joshi — Sat, 21 Aug 2021 06:56:02 +0000

Serverless is the go to paradigm for many young startups today. I have been experiencing the quirks, caveats and corners of it ever since I started working on it.
This blog aims to establish "Deployment in Serverless" as a business strategy over a development paradigm.
In this incrementally evolving piece, I will talk about serverless deployment strategies, business influences, decision factors and a lot more.

Yes, Serverless is cool. It is one less thing to do, but there’s certainly more to it. When you are not occupied with tedious, time consuming server development, operations, and maintenance, you can take some time out to click some heads in your favorite multiplayer first-person shooter game or even learn making Pepperoni Pasta.

Especially when you are building a startup, you want to be efficient in solving bigger problems at hand. There are many other factors teams consider before moving to the serverless paradigm. Once you have taken the call, you are presented with multiple strategies for deployment.

This blog helps you explore more about approaches and suggests to you the paradigm that might fit your strategies. This blog will consider Google cloud platform for most of the examples and explanations but the deployment strategies more or less remain similar among all the major cloud vendors.

Serverless computing is a method of providing back end services on an as-used basis. A serverless provider allows users to write and deploy code without the hassle of worrying about the underlying infrastructure. Precisely back end as a managed service sums up the essence of serverless paradigm. You write code as functions, ship it to a third party. The third party is responsible for managing the entire infrastructure which hosts your code. You are given a window through which you and the rest of the world can interact with the code. While the management is done by the third party, it must be realized that you are the one in control of your code.

Serverless computing allows developers to purchase back end services on a flexible ‘pay-as-you-go’ basis, meaning that developers only have to pay for the services they use. This is like switching from a cell phone data plan with a monthly fixed limit, to one that only charges for each byte of data that actually gets used.

One of the most commonly used serverless entities are the cloud functions. Google Cloud defines cloud functions as a serverless execution environment for building and connecting with cloud services. Cloud functions expose you to write simple single purpose functions that are attached to events emitted from Cloud infrastructure and services the code executes in a fully managed environment.

To put things into perspective once you have the service architecture up and running you will need to package your updated code and give it to a provider. This way the management completely becomes the responsibility of the third-party vendor, this also means that the third-party cloud vendor is responsible for updating the code and making it accessible to all the future requests that come. However you are in charge of having a mechanism to push the updated code from your source repositories to the cloud vendor. Each function is associated with its own environment and the update won't affect any code during execution. The old functions generally die after the completion and the update will seem to be instantaneous .

GCP Says, “Google Cloud Functions is a serverless execution environment for building and connecting cloud services. With Cloud Functions you write simple, single-purpose functions that are attached to events emitted from your cloud infrastructure and services. Your function is triggered when an event being watched is fired. Your code executes in a fully managed environment”

That’s comforting right? Or is it alarming. It is a topic for future reveals when we talk about observability in managed services.

It is quite obvious that to use the serverless architecture you need to handle your deployments in a different way, most likely you might consider having a continuous integration and continuous delivery pipeline. The delivery pipeline usually begins after the development is completed but it is as important. Most of the cloud vendors today give you access to entities like cloud functions directly from the console, which might not be a good idea. Using serverless architecture you are already dependent on the third party vendors for managing resources, and using the console to create cloud functions without having a copy of the source code might be a bad idea.

Deployment Options: Deployments work by shipping your function's source code to a place in cloud storage. There are a number of ways the deployments can be done. Typically cloud Functions run with container orchestration. In simple words, each cloud function has its own environment. Read more here.

Typically, deployment can be availed using the following techniques:

Ship from local machine
Deploy from source control
Deploy from Cloud Console
Deploy with the Cloud Functions API Google Cloud comes up with something called Functions Framework to run and debug your functions locally for supported runtime. It makes testing and debugging easier.

Choosing the right strategy: The right strategy can depend on your business, wallet, urgency, design and a lot of other factors. Generally, deployment from source control is the way to go for many.

This is largely because this strategy provides benefits on VCS, feature based development, continuous integration, development coherence and automated deployment. The source code already stored as commits can use tags on each commit and these tags can be used to deploy the code. While most teams prefer to work in coherence, yet prefer independent control over code modules, small scale projects typically do not define a strategic deployment strategy.

These tags act as a trigger to the building engines of cloud providers. Good strategies include a mechanism to only build the difference on code rather than the entire unit. One good example to understand this is a GCP managed python cloud function built entirely only when there are more modules needed by the environment for that function to work. This can be observed using the time taken to deploy in both cases.

To be continued! Next on this:

Managing Cloud Functions
Cloud Functions and Security
Deploying Pipeline

Can you make JS more powerful?

Harsh Joshi — Wed, 18 Aug 2021 18:44:52 +0000

“ Do you know the most powerful thing about Javascript? Spoiler Alert, It is not asynchronicity, first-class citizen principles, not even my favorite, closures. While all of these make javascript a delight, what makes javascript powerful is not focusing on attaining power. Javascript is not power-hungry by design.”

Javascript in its vanilla form does not intend to provide you with capabilities touching skies and jumping oceans. That is where the amazing dev community along with packages breaks into the scene, bringing in powers from dark dimensions, Human Batteries, Arc Reactor, and who knows where else.

Yes, I exaggerated. Now that I have your attention, let’s dive deep into the perspective this blog aims to set. The core parts of javascript, widely popular and used, are not its own. That still does not take away the joy of working with it and It is still technically javascript.

This blog tries to answer its own title with a big Yes. It sets to establish "building for public "patterns while talking about javascript, modules, and publishing to npm. If you are still reading this blog, I assume you are familiar with what npm is. The exciting part of working in javascript (like many other languages) is the ability to share your work with others in a manner that they might use your work in their projects. Let’s begin with going over the basics of publishing your own module to npm, and then how to make use of that in a project.

Pilot: Getting hands dirty!

Writing a npm module from Harsh Joshi

That might have been fairly easy. If you see something not right there, it's only because you figured it out ;)

A fun way to get started is by thinking small and smart. Before you begin writing your own modules, a good read would be how modules work in javascript, especially post ES6. You can find one here.

Episode 2: The Code Isomer Conundrum

Code isomers are two or more pieces of code that do the same work but differ in the way they are written. (Yes, I just made that up but it doesn't make it any less relevant)

This is the most fundamental example of it. When writing code that delivers much bigger the style developers use takes the shape of patterns. When writing modules that are intended for public use, a well-defined pattern reduces the headache of the person consuming that module. These patterns are categorically closer to the purpose of being used by anyone, anywhere and anytime than the language hence I call them "building for public patterns".

Have you ever come across a cool npm package, the intention of which gave you a tickle, but the implementation could not? When you installed the package you could not really understand what does what, there was no documentation readily available and you ultimately had to drop it? Yes, it does not happen when Facebook releases react.js or any organization releases a big package. But out there are many developers working on pretty cool stuff, some of which unfortunately fails to abide by the rather misty de facto standards of releasing to the public. These misty de facto standards are what we introduce here as building for public patterns.
There are two schools of thought on how to write code in any language. The first school of thought is that it should be written in a manner that is easily understood by the person who wrote it. The second school of thought is that it should be written in a fashion that is easily understood by the person who reads it.

The first school of thought is more often linked to the phrase "write self-documenting code" and is often referred to as "write-what-you-know" or "write-what-you-need". Regardless, it is a very common factor in programming, and it is often a necessity to write code this way when a project is small and the time of writing the code outweighs the time of reading it.

The second school of thought is a little closer to what we just introduced as "building for public patterns" and is often linked to the phrase "write clean code" and also called "write-what-you-need-to-know". It is also common to write code to be read by others. A programmer who is writing code that will be read by other programmers will write the code in a manner that is easily understood by the one who reads it. This is especially true when the code is in a highly complex area of the program.

"Building for public" patterns somewhere introduce a new school of thought that is closer to the person consuming the code and not does not care much about how the actual code is written. In javascript, the concept of modules post ES6 pretty much standardizes this notion. However, much is still left on the developer to abide by. This includes naming the handlers, exporting, shaping the module, and much more. It also goes on further to include optimizing the size of the module, adding more weight to the "consumer-first" approach of publishing your work.

Let's assume you are sick of the native console API and you have promised yourself that you won't use console.log() again. You decide to write your own function which uses an API you build to send logs to your phone.

const unConsoleLog = (data) => {
    fetch(API_URL, {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'token': 'XXXX-XXX-XXX-XXXXX',
            },
            body: JSON.stringify(data),
        })
        .then(response => response.json())
        .then(data => {
            console.log('Success:', data);
        })
        .catch((error) => {
            console.error('Error:', error);
        });
}

The idea becomes so exciting that you now want to make it accessible for public use. You decide to release this as an npm module.

Can you think of the best possible way to release this to the public using "Building for Public"?

to be completed...

Next on "Can you make JS more powerful?"

Consumer First principles in "Building for public" patterns.
Encapsulation in JS and life before ES6
"For and by the public" with open-source
Making javascript powerful with your first module. (.js)

If being inaccessible was a crime, would you be arrested?

Harsh Joshi — Sat, 14 Aug 2021 17:07:52 +0000

Sure, you had the right color scheme, a consistent theme and a UX backed by some thrilling research on where to place a UI element, or even used SSR-like principles for other fronts of user experience but will your web app be able to befriend a screen reader? Being accessible is somehow left out of the comprehension of many designers and developers in the webspace. Although naturally, the concepts this blog sets to address are meant for web-based projects, application development should round the circle even better. A few of these will strike you the tallest if you have, maybe, some experience in app development.
Find out and answer, "If being inaccessible was a crime, would you be arrested?"

Accessible websites are crucial to the health of the internet. The more accessible a site is, the more people can reach it, use it, and enjoy it. The more people can reach, use, and enjoy a site, the more likely it is to be successful. The more successful the site is, the more likely it is to become a successful business.

But is that all accessibility means?

The problem is that, if you are not aware of how to design your website in such a way that it becomes accessible for all, you might end up providing an inadequate experience to some users. Today’s world is “experience first”. Many designers, developers, and web admins just are able to capture the essence of the experience for the general public. To add to it, there are many web design and development tools which abstract these for you. But the question is whether this is “captured” to an extent that the application running on the web is equally accessible to all?

Sure, you had the right color scheme, a consistent theme and a UX backed by some thrilling research on where to place a UI element, or even used SSR-like principles for other fronts of user experience but will your web app be able to befriend a screen reader for a user who has visual challenges?

The fundamental questions you can ask yourself to begin evaluation of accessibility in your application could be, "Will the app provide a smooth experience using a screen reader?", "Can someone navigate the application using keyboard only?". There are many other amazing ways people use the web.

Here is an example - Some HTML elements have semantic meaning but no dedicated functionality. These include aside, footer, header, etc. This semantics serves the screen reader.

Did you know that elements can be described using the ARIA spec or a simple tabindex can help a user tab to an element? Another interesting concept is focus management which provides a necessary clue about the currently active item to the user. To learn more about such examples, and the foundation of web accessibility, this resource by Jon Kuperman might be a good starting point.

The matter, in many cases, is that being accessible is somehow left out of the comprehension of many designers and developers in the webspace. Although naturally, the concepts this blog sets to address are meant for web-based projects, application development should round the circle even better. A few of them will strike you the tallest if you have, maybe, some experience in app development.

Do you dream of that fancy loader for your website? Yes, it has got animations, colors that flicker in and out. Or do you have the next idea for an animated 404 page?

MDN says, "Content that flickers, flashes, or blinks can trigger photosensitive epilepsy. Web technologies that use video, animated gifs, animated png, animated SVGs, Canvas, and CSS or JavaScript animations are all capable of content that can induce seizures or other incapacitating physical reactions".

What is Accessibility anyway?

Accessibility is the responsibility of everyone involved in the development process. It is the responsibility of the designer, the developer, and the webmaster to make sure that the product is accessible. It is a moral and ethical issue as well as a legal one. Addressing accessibility in your processes and making it inclusive from the beginning serves more than one purpose.

The Web is for everyone. Why shouldn't it be designed to be accessible to people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity, and many others?

Accessibility is a combination of design, development, and strategy. A well-designed site can be easily made accessible, and an inaccessible site can be made accessible. It is a matter of the right processes and the right attitude. Accessibility is a commitment to a set of standards and guidelines that will ensure your content is visible to users with disabilities.

To make your site accessible, you need to ensure that all the information you present can be accessed and used by anyone, regardless of any disability. You may need to include alternative text for images, provide text alternatives for audio and video content, and ensure that your site works with assistive technologies such as screen readers.

Accessibility (Accessible Design) is a set of principles and practices that help make web content accessible to everyone including people with disabilities. It is also known as inclusive design.

Which Standards?

World Wide Web Consortium (W3C) aims to lead the Web to its full potential by developing standards and guidelines that ensure the long-term growth of the Web. Accessibility is one of the core values of the W3C. The W3C's Web Accessibility Initiative (WAI) is the largest international industry consortium focused on improving the accessibility of the Web for people with disabilities.

The WAI guides developers of websites and software, information architects, site designers, and others to make the Web accessible to people with disabilities. The WAI also provides education, outreach, testing tools, and resources to help developers make their products and services accessible to a wide range of people with disabilities

There are several levels of conformance to accessibility guidelines. The most basic level is called "Level A". Level A conformance requires that your site can be used with a keyboard only. Achieving this level of conformance requires that all of the functionality of your site can be accessed with the keyboard and the page is readable. For example, if the user is required to click a link to access a page, the link must be keyboard accessible. The user must be able to navigate to the link and activate it using the keyboard.

The next level is called "Level AA". Level AA conformance is a significant extension of Level A. Level AA conformance requires that all of the functionality of the site and any of the content can be used with the keyboard. This includes any images or buttons on the page. In addition, the page must be readable when using a screen reader. The page must also provide a way to navigate to any links on the page. This ensures that the page can be easily navigated using a screen reader.

The third level is called "Level AAA". Level AAA conformance is the most stringent level of conformance. Level AAA requires that all of the functionality of the site can be used with the keyboard. This includes any images or buttons on the page. In addition, the page must be readable when using a screen reader. The page must also provide a way to navigate to any links on the page.

But how do I evaluate my app?

There are a lot of free tools available over the internet which run some automated tests on your web app and return an accessibility score. While this can be step zero to get started on evaluation but adherence and compliance to different levels of standardized accessibility levels ensure that your app does well on accessibility.