DEV Community: TheAbbie

Interactive Double Pendulum Playground Using SVG

Abhishek Chaudhary — Mon, 25 Oct 2021 06:08:12 +0000

TRY IT: theabbie.github.io/DoublePendulum

SOURCE: github.com/theabbie/DoublePendulum

A double pendulum is a pendulum with another pendulum attached to its end, is a simple physical system that exhibits rich dynamic behavior with a strong sensitivity to initial conditions.

The motion of a double pendulum is governed by a set of coupled ordinary differential equations and is chaotic.

θ1'' =	−g (2 m1 + m2) sin θ1 − m2 g sin(θ1 − 2 θ2) − 2 sin(θ1 − θ2) m2 (θ2'² L2 + θ1'² L1 cos(θ1 − θ2))
	L1 (2 m1 + m2 − m2 cos(2 θ1 − 2 θ2))

θ2'' =	2 sin(θ1 − θ2) (θ1'² L1 (m1 + m2) + g(m1 + m2) cos θ1 + θ2'² L2 m2 cos(θ1 − θ2))
	L2 (2 m1 + m2 − m2 cos(2 θ1 − 2 θ2))

How To Use?

Is Google AMP the Right Choice for Your Website?

Abhishek Chaudhary — Sun, 15 Nov 2020 14:18:00 +0000

Accelerated Mobile Pages, or AMP, is an open-source initiative by Google. In their words, it helps "make the web better for all".

So is this true? Some critics (mostly publishers) say that it will help Google dominate the web. But we can't jump to any conclusions by just considering one perspective.

To help us out, I have divided this article into three sections, so we can consider AMP from three different perspectives.

The first considers the perspective of publishing sites and the people who maintain them. The second considers the perspective of the user. And the final perspective considers Google's take on it, as a search engine.

If you think about AMP from all these angles, you will be able to make the right decision for your website.

Because of this, this article doesn't have a straightforward conclusion as to whether you should or shouldn't use AMP. That's up to you, in the end. This article will just help you to move in the proper direction.

Let's look at our first perspective.

Publishing sites and their maintainers

AMP was launched in 2015, which means it's just 5 years old. So people and sites who have been publishing long before that time might worry that all their articles will suddenly become outdated. But that's not the case. Still, like big companies, they want to resist change.

Their criticism is completely valid from their perspective, as Google AMP has some strict conditions that must be met. For example:

Forget JavaScript (though there are some workarounds). Traditional use of JavaScript is not allowed at all.
If you are creating an AMP version of a page, the AMP version and the canonical page (the original page) should have identical design and functionality.
You can't use external CSS, but instead you have to inline everything. Since that would be inefficient, a customized library is preferable.

This is a minimal AMP page from the Google AMP docs:

<!DOCTYPE html> <html ⚡> <head> <meta charset="utf-8" /> <title>Sample document</title> <link rel="canonical" href="./regular-html-version.html" /> <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1" /> <style amp-custom> h1 { color: red; } </style> <script type="application/ld+json"> { "@context": "http://schema.org", "@type": "NewsArticle", "headline": "Article headline", "image": ["thumbnail1.jpg"], "datePublished": "2015-02-05T08:00:00+08:00" } </script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js" ></script> <script async custom-element="amp-ad" src="https://cdn.ampproject.org/v0/amp-ad-0.1.js" ></script> <style amp-boilerplate> AMP boilerplate CSS / </style> <noscript ><style amp-boilerplate> body { -webkit-animation: none; -moz-animation: none; -ms-animation: none; animation: none; } </style></noscript > <script async src="https://cdn.ampproject.org/v0.js"></script> </head> <body> <h1>Sample document</h1> <p> Some text <amp-img src="sample.jpg" width="300" height="300"></amp-img> </p> <amp-ad width="300" height="250" type="a9" data-aasize="300x250" data-aaxpubname="test123" data-aax_src="302" > </amp-ad> </body> </html>

Apart from the contents of the body tag, the rest is the minimal amount of code you need to be a valid AMP page.

Anything that can slow down the webpage is either not allowed or has a different format. For example, images have to use the <amp-img> tag instead of just the <img> tag. Similarly iframe and video tags have a different format.

You have complete freedom to use CSS inline the way you want to, except for some CSS animations (as it slows down the page).

If your canonical page has lots of dynamic stuff, like signup forms and carousels, then you will have a hard time creating an identical AMP version.

If you want to avoid that trouble, you are left with two options: either make your canonical page super simple or discard the canonical page and use just an AMP page.

This is what bothers most publishing sites and the people who manage them: Google will have immense control over the internet, which goes against the concept of net neutrality.

Google says it does not favour AMP pages in search results. However, there are rich cards which are only possible via AMP. So, in a way, Google is indirectly forcing you to use AMP to survive.

AMP also allows only one ad per page, which might affect ad revenue, considering that all your organic traffic will see the AMP version. There is limited support for other ad networks.

You also can't use other analytics providers other than the ones supported.

All these points need to be considered before you make a decision.

But it's not all bad news. Now let's talk about the benefits publishers recieve:

Google shows AMP pages from an AMP cache, which drastically reduces bandwidth usage on the publisher's server. This may or may not be beneficial to you.
Your website will load really fast, because of the severe limitations of AMP. So there is nothing to slow it down. Google also preloads webpages before someone clicks them, so the load time is negligible, apparently.
Your website can appear as rich cards, or carousels if properly configured, which increases the click through rate.

Now the most important thing: AMP implies that your website should be strictly mobile-friendly. And being mobile-friendly is such a necessity these days that websites can't ignore it, AMP or not.

So we've looked at Google AMP from the perspective of publishers. In the end, if you have a web app with a lot of functionality, I wouldn't suggest that you go for AMP. Now, let's move on to the second perspective.

Users

Publishers are the ones who might have trouble implementing AMP on their pages.

As a user, your primary motive is to surf the web. Not many mobile users have great internet speed and a non mobile-friendly and slow website with slow internet speed is the worst combination.

If you are searching for something online, your first priority is getting a result. Not all websites are fast, and even though they may have great content, they will likely suffer if they're slow to load. But Google AMP helps them to be fast and accessible.

A significant portion of any audience these days is made up of mobile users. For example, check out the user distribution of freeCodeCamp based on operating system:

So, the users are the ones who are and should be benefitting from AMP. Google is a user-centered company. Each and every decision it makes will benefit its users.

As a user, if you are searching for something, you have a very little attention span. You have a whole list of results to go through. If a website doesn't load within 5 seconds, you will most likely move on to the next result.

Let's try to compare the performance difference between the AMP and non-AMP versions of one of my freeCodeCamp articles.

This is the non-AMP version on a mobile device:

The non-AMP version works fine on desktop (score of 94) but that's because desktops have faster load times compared to mobile devices. But the non-AMP version is pretty slow on mobile devices.

Now let's test the AMP version:

It's much better than the non-AMP version, especially on mobile. And the desktop score got boosted too (98 this time). This makes it clear that AMP is faster.

But the major performance boost is because Google preloads the results which makes the load time negligible. The load times for the AMP version and Non-AMP version were as follows:

You can see the performance boost you get if you use AMP. And as a user, it's beneficial to you. You don't want to wait for results, you just want to get the answer real quick. And Google tries its best to find the answers for you so that you don't have to search manually.

Google even shows featured snippets for most queries so that you don't even have to open the webpage. Here's an example:

As you can see, Google tries it's very best to answer questions and make your experience faster. AMP is just a way to make it even faster for users who just want to find an answer quickly.

AMP also makes sure a page looks the same across platforms and browsers, thus removing many limitations of web design. So from a user's perspective, AMP is an absolute win.

Now let's move on to the third, and the most important perspective for our purposes.

Google, as a search engine

Before discussing this perspective, let's summarize what Google AMP really does:

Accelerated Mobile Pages or AMP as the name suggests is a way of designing web pages to improve user experience especially on mobile devices. These pages have workarounds for things that can possibly slow down a page.\
\
There are plugins for most dynamic elements like carousels, dynamic lists, forms, and embeds. The content is served from the AMP cache which, combined with preloading, creates a fast loading effect.

There is no one guide for designing a webpage. You have HTML, CSS and your creativity and a blank canvas.

That being said, there are some good artists and some bad artists. If there was a guide to how every page should be, there would be way less variation across pages.

Still, there is the concept of Semantic HTML which helps us organize our web pages.

Semantic HTML is the practice of using meaningful tags for certain parts of a webpage instead of using general <div> and <span> tags for everything. For example, using <h1> for headings, <nav> for navigation, <header> and <footer> for headers and footers, respectively.

So, using <header> is much better than using something like <div class="header">

If every web page was forced to use such conventions, search engines would easily be able to identify what the main content was and display much better results. But, you can't force everyone to use such conventions.

To simplify extracting information from webpages, Google encourages developers to use Structured Data. This is an organised form of what is present on the webpage. For example the structured data of this article is the following:

{ "@context": "https://schema.org", "@type": "Article", "publisher": { "@type": "Organization", "name": "freeCodeCamp.org", "logo": { "@type": "ImageObject", "url": "https://www.freecodecamp.org/news/content/images/2019/11/fcprimarylarge_24X210.svg", "width": 210, "height": 24 } }, "author": { "@type": "Person", "name": "Abhishek Chaudhary", "image": { "@type": "ImageObject", "url": "https://www.freecodecamp.org/news/content/images/2020/08/image.jpg", "width": 2000, "height": 2000 }, "sameAs": [ "https://theabbie.github.io", "https://www.facebook.com/abhishek.vice.versa", "https://twitter.com/theabbiee" ] }, "headline": "Is Google AMP the right choice for your website?", "url": "https://www.freecodecamp.org/news/p/efcffd53-9fa2-49ba-a144-9c627fde4d86/", "image": { "@type": "ImageObject", "url": "https://images.unsplash.com/photo-1533292362155-d79af6b08b77?ixlib=rb-1.2.1&q=80&fm=jpg&crop=entropy&cs=tinysrgb&w=2000&fit=max&ixid=eyJhcHBfaWQiOjExNzczfQ", "width": 2000, "height": 1333 }, "description": "Accelerated Mobile Pages or AMP is an open-source initiative by google. In there words the motive is to "make the web better for all". Whether it's actually true or not is highly debatable, Some critics (mostly publishers) say that this will make Google dominate the web. But we can't jump", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://www.freecodecamp.org/news/" } }

Google doesn't rely on this alone, as people might misuse it. But it helps Google understand what is present on the page. These can also help in displaying rich results, for example:

The good thing about AMP is that it encourages developers to use structured data. Also, due to the severe limitations, the page has a much cleaner design. This makes the task of search engines much easier.

And almost everyone would agree that cleaner, faster webpages are also important in general.

So how do you decide?

In this article, we saw that AMP is beneficial to both users and Google, and can also be beneficial to publishers if they don't resist change. And everyone is a user at some point.

If you hate slow, non mobile-friendly websites, think about how other users feel, too. A cleaner internet is always better.

That being said, if your only motive is to create a clean and fast webpage, you can do so without AMP too. Just avoid unnecessary components and design efficiently.

This article was an overview of AMP, and its pros and cons. Now you know why it may or may not be useful to you. I hope you make a good decision for your site.

A Brief History of Responsive Web Design

Abhishek Chaudhary — Tue, 27 Oct 2020 12:36:34 +0000

Websites are like a canvas. You have complete freedom to design them the way you want. But unlike a painting, not all people will view your site the way you want.

The internet is huge and old, and devices are getting smaller and more compact. Now you have to adapt your painting for a smaller canvas without losing its beauty.

This is where Responsive Design comes in. Websites can now look just as good on a phone as they do on a big-screen TV. But it wasn't always this way. It took developers years of experimentation to reach this point. And we're still making improvements each day.

This article will dive into the history of responsive web design and see how websites have evolved.

The Early Days of the Internet

Remember the early days of the internet, when any website seemed great? Just getting your own page live on the web was a grand achievement. Even if it were just a Geocities page or an Angelfire page, you'd show it off to your friends. And it was one of the best feelings in the world.

The good news for designers: they knew pretty much exactly how their websites would look. Everyone was accessing the web through desktop computers with only a handful of resolutions and aspect ratios. This meant that designers could place things anywhere on the screen they wanted without worrying too much about other screen sizes.

Back then, it was common to see websites that forced you to use a desktop browser. Re-designing an entire website to work on fringe screen sizes was difficult, and many companies didn't want to invest the effort.

Life Before CSS

For the past 20 years or so, most developers have gotten their start with web development. And that meant learning basic HTML, the basic building blocks of websites.

In the most basic terms, HTML elements are rectangular boxes that stack over each other by default. There wasn't that much you could do with a few boxes containing text and images.

The most basic HTML tags were all we could use. They included h1 to h6 tags, image tags, lists, tables, paragraphs, and many tags for even the most basic stuff (which are now done using CSS).

A basic HTML page would look like this:

<html> <head> <title>FreeCodeCamp</title> </head> <body> <h1>FreeCodeCamp</h1> <img src="logo.jpg" height="150" width="150" align="right"> <p>Text goes here</p> <p>Text goes here</p> </body> </html>

There were no structured or uniform ways of styling HTML elements. But luckily, HTML gave you some customization through special tags.

All these tags even exist today, though some were deprecated in HTML5 because they were too basic. For example, there was a <marquee> tag, a tag for creating sliding text, images, and other HTML elements.

You can achieve the same effect can now through CSS alone. But at that time, developers had to create separate tags for every single functionality. (Fun Fact: Google has an easter egg if you search "marquee tag." You get to see it in action.)

Thus, designers needed a structured way of styling elements. It needed to be flexible and completely customizable.

This led to the creation of Cascading Style Sheets (CSS), a standard way of styling HTML elements.

Cascading style sheets or CSS is a way of styling any HTML element. They have a set of pre-defined properties that can be applied to any HTML element. These styles can be embedded in the same HTML page or used as an external .css file.

It was a major milestone in web design. Now designers had an option to change each HTML element's property and place them wherever they wanted.

When Screens Started Shrinking

Now that designers had complete control over the webpage, they had to make sure it looked good on all screen sizes.

Desktops are still popular today, but most people also use hand-held mobile devices to surf the web. Now designers have less width but a more usable height, as scrolling is very convenient on touch-screen devices compared to desktops.

Websites now had to incorporate Responsive Web Design:

Responsive web design is an approach to web design that makes web pages render well on various devices and windows or screen sizes.

The most common way of dealing with smaller screens is a Sidebar. A sidebar is like a drawer where links and other not-so-important stuff is kept. Designers transfer all secondary stuff to the sidebar so that the webpage looks clean.

This is an overused method, however, and sidebars weren't originally intended for this purpose.

Before this trend, the <frameset> and <frame> tags were trendy, as they allowed designers to embed external web pages.

But unlike the now popular <iframe> tags, these tags were highly unresponsive. They didn't adapt to different screen sizes and tried to maintain their layout even on smaller screens, which looked terrible.

<frameset rows="100"> <frame src="header.html"/> <frameset cols="33%,33%,">Nested frameset <frame src="subframe1.html"/> <frame src="subframe2.html"/> <frame src="subframe3.html"/> </frameset> </frameset>

The output would look completely fine on desktops but broke on mobile devices.

Transition to Responsive Design

The old, huge websites with thousands of pages were faced with a dilemma: to be responsive or not to be.

Any web designer knows that making a transition from a larger to a smaller screen is the worst. Your canvas is getting smaller, whereas the painting remains the same. Either you delete some parts of your painting or make it adapt.

Since there were no guidelines for being responsive back in the day, web designers often used naive ways of putting elements on various parts of the screen.

For example, using <table> tags.

Using a table tag for a layout was a bad practice for various reasons, such as:

Tables are not meant for layouts. They are for showing Tabular data in a compact form.
Table tags, just like frameset tags, are not responsive, and they don't adapt to smaller screen sizes.
The table can't be rendered until all its cells are loaded, whereas using div tags for a layout allows them to load independently.

Case Study of Some Large Websites

Let us see how some large websites dealt with this dilemma. We'll take YouTube, for example.

You have likely seen the desktop version of YouTube. It's full of stuff â€“ a header on top, a sidebar on the left, videos stacked around each other, and a footer. Most of these things are quite unnecessary for mobile users as they can't utilize them properly.

YouTube might have chosen responsive design, but that would mean hiding these extra elements somewhere.

Anyone who has designed a website knows how important website performance is. Each and everything you put on a page slows it down. So, in YouTube's case, it would be a waste to fetch them from the server only to hide them.

And YouTube is old, and so is its design. Modifying an already written code has a high chance of breaking stuff that is already working. So instead, YouTube used what is known as Dynamic Serving.

Dynamic Serving is a method where the server checks whether the device requesting the webpage is a desktop or a mobile. Then it dynamically serves the webpage depending on the type of device.

This method is easy to implement, as designers don't have to deal with different screen sizes. But it's also often discouraged because if not properly configured, it can devastate SEO because of duplicate content issues.

These mobile versions are often served through a different subdomain like m..com to distinguish them.

This method was used by Facebook, Wikipedia, and other huge websites, for similar reasons. Responsive Web Design is an ideal solution that is difficult to implement.

Some other sites decided not to be responsive but to build a mobile app instead. This was a reasonable approach considering that mobile apps were future proof. But installing a mobile app required some level of trust, as they had much greater access than web apps.

Also, the problem with native mobile apps was that they were expensive to make, as they had to be built for multiple platforms with the same design and functionality. The web is a pretty mature platform and thus has greater scope than mobile apps.

Responsive Web Design Strategy

These were the problems faced by sites that already existed. For new websites, Responsive design became a must to compete with other websites.

Google also recently introduced mobile-first indexing, which means that it prefers mobile-friendly websites searching for mobile devices, creating one more reason to adapt.

Mobile-first approach

Suppose you have a suitcase with some stuff in it. Would it be easier to transfer things from a smaller suitcase to a larger one or larger to a smaller one?

In the mobile-first approach, the website is made to be compatible with mobile-first, and then see how things change when transitioning to a larger screen.

One misconception around this approach is that people think that it's mobile-only. But that's not correct. Mobile-first doesn't mean designing only for mobile. It is just a safe and easy approach to start with.

Since the available space on a mobile screen is much smaller than a desktop, it has to be used for central content.

Also, mobile users frequently switch pages, so it is important to grab their attention immediately. Since fewer elements on the page and focus are put more on content, this results in a cleaner web page.

The Future of Web Design

The web is growing at an incredible rate. People are shifting their businesses online, and competition is stiffer than before.

There is also a discussion as to whether businesses actually need a mobile app anymore. With the growth of Progressive Web Apps (PWAs) and various web APIs, the web is much more powerful than before. And most native features like notifications, location, caching, and offline compatibility are now possible with PWAs.

A progressive web application is a type of application software delivered through the web, built using common web technologies, including HTML, CSS, and JavaScript.

Making a PWA is straightforward but beyond the scope and the central idea of this article. Let us focus more on what we are getting with PWAs.

You might have noticed the "Add to Home Screen" button in the chrome browser above. For normal websites, it's nothing more than a shortcut icon on the home screen. But if the website is a PWA, you can do a lot of really cool stuff.

You don't need to install a web app to function as a PWA, but that makes it feel more like a native app. Also, a PWA can run as a standalone web app without the chrome address bar on top. This again gives it a more app-like feel.

PWAs work on Desktops too, which makes them a perfect candidate for any new app. They can run on any platform with a web browser, they are safe, and they have all the basic native features.

Still, many features not already installed or available can pose a security threat, as opening a website is considered much safer than installing an app. Therefore, some highly native features still require a native app.

To be clear: PWAs are not a replacement for native apps. Native apps will continue to exist. PWAs are just a simpler way to achieve those features without actually building a mobile app.

Predicting the Future of the Web

As we've seen, technology continues to improve, and the internet continues to become more accessible as the number of users grows exponentially.

The shift of web design trends leans more towards performance and user experience. And will continue to do so.

We are also heading towards Web 3.0:

Web 3.0 is the next generation of Internet technology that heavily relies on machine learning and artificial intelligence (AI). It aims to create more open, connected, and intelligent websites and web applications, focusing on using a machine-based understanding of data.

What this means is that everything will be connected and machines will use the internet too. It'll be similar to how web crawlers crawl websites and understand the context of the page.

A good, clean, minimal web design focusing on content will help machines understand things better. The internet is an open place with lots of innovation. We might be heading towards a web controlled by the mind!

Conclusion

We started from the beginning of the internet've seen how once-popular technologies became obsolete. We are still in progress toward a better internet.

We are no longer in the era where developers don't worry about users. The user experience is a priority nowadays; whether it's performance or design, a user should feel satisfied with any application.

And unlike the old days, we are not limited to any one tool. We are free to use our own creativity, and it is up to us how we transform our creations into something valuable.

The web is a wonderful place, and there are many great websites to get inspired by. Let's keep our fingers crossed and keep moving forward.

Generic Static Site Generator

Abhishek Chaudhary — Tue, 25 Aug 2020 03:19:30 +0000

By Abhishek Chaudhary

Published 2020-08-24

This is a Generic Static Site Generator, It is written in JavaScript, It can be used to create static websites.It is an organised and completely customisable Static Site Generator, It treats webpages as objects which can be evaluated.This can be used to created all kinds of websites.

Generic Static Site Generator Github

Generic Static Site Generator NPM

Generic SSG

Generic Static Site Generator Gitter

Generic Static Site Generator openbase

Generic Static Site Generator WNW

Generic Static Site Generator Yarn

Generic Static Site Generator indie hackers

Generic Static Site Generator DevPost

CryptoCRIT

Abhishek Chaudhary — Wed, 05 Aug 2020 14:22:54 +0000

What Is CryptoCRIT
Tasks

What Is CryptoCRIT

CryptoCRIT is an open-source Cryptocurrency project which facilitates a Cryptocurrency wallet for making payments. The associated Cryptocurrency is called CritCoin.

This system will be used in Fr. Conceicao Rodrigues Institute of Technology

CryptoCRIT

Quick Info
Name	CryptoCRIT
Technologies Used	Blockchain RSA Encryption
College	Fr. Conceicao Rodrigues Institute of Technology
Team	Gabriel Rajendran Aditya Unnikrishnan Abhishek Chaudhary Tushar Gupta

Tasks

[ ] Backend
[ ] Frontend
[ ] Logic
[ ] Working
[ ] Production

Getting Started

Installation

To use CryptoCRIT in your project, run:

npm i cryptocrit

Abhishek Chaudhary (TheAbbie) Height, Weight, Age, Girlfriend, Family, Biography & More

Abhishek Chaudhary — Tue, 21 Apr 2020 09:10:03 +0000

Abhishek Chaudhary

Bio

Real Name

Abhishek Chaudhary

Nickname

TheAbbie

Profession

Web Developer, Filmmaker, Podcaster

Famous for

Brazen Epiphany (2019)

TheAbbie Podcasts

Physical Stats & More

Height

In Centimetres- 175 cm

In metres- 1.75 m

In Feet Inches- 5'9"

Weight

In kilograms- 50 kg

In pounds- 110.2 lbs

Body measurements

chest- 38 Inches

waist- 30 Inches

biceps- 12 Inches

Eye colour

Black

Hair Colour

Black

Personal Life

Date of birth

11 January 2002

Age (as in 2020)

18 Years

Birthplace

Navi Mumbai, Maharashtra, India

Zodiac sign/Sun sign

Capricorn

Nationality

Indian

Hometown

Navi Mumbai, Maharashtra, India

College

Fr. Conceicao Rodrigues Institute Of technology

Educational Qualification

B.E. In Computer science

Debut

Brazen Epiphany (2019)

Brazen Epiphany

Family

Father - Santosh Choudhary

Mother - Ruby Choudhary

Brother - Yogesh Choudhary

Religion

Hinduism

Food Habit

Non-vegetarian

Hobbies

Reading, Watching movies, Listening music, Programming

Favorite things

actors

Aamir Khan, Irrfan Khan

actress

Shraddha Kapoor

movies

Andhadhun

direcors

Rajkumar Hirani, Anand Gandhi

Singer

Sonu Nigam, Mohit Chauhan, Arijit singh

Girls, Affairs and more

Marital status

Unmarried

Affairs/Girlfriends

Single

Wife/Spouse

N/A

Some Lesser known Facts about Abhishek Chaudhary

Does Abhishek Chaudhary smoke?: No
Does Abhishek Chaudhary drink alcohol?: No
Abhishek Chaudhary is a computer engineer and a filmmaker and one of the directors of 2019 short film Brazen Epiphany.
He graduated from Fr. Conceicao Rodrigues Institute Of technology with a degree of B.E. in Computer science.
He is famous as TheAbbie.
He is a Bihari an his father works as Bank manager.
He is the founder of TheAbbie Podcasts , the top podcast in India as of 2020.

List of all Social media accounts

Abhishek Chaudhary — Wed, 12 Feb 2020 01:30:58 +0000

I have so many Social media Accounts, how many do you have?

https://theabbie.github.io/

Don't click me

Abhishek Chaudhary — Thu, 30 Jan 2020 14:15:19 +0000

If you are reading this, most probably you clicked some link saying Don't click me, and most probably you clicked it.

Am I judging you?
Not at all

There are mistakes we all do in life, they are forgivable, but this is not

Please don't click on clickbaits in future

Perks of being introvert

Abhishek Chaudhary — Sat, 25 Jan 2020 05:11:20 +0000

I am an introvert
I don't feel like socializing anymore
I have friends but I prefer being alone
I fo talk but not talking makes me feel comfortable
Is it good?
Depends, You can't live alone forever
You need people to survive
Then, Why are some people introvert?

THINK ABOUT IT

Who Are We?

Abhishek Chaudhary — Sat, 25 Jan 2020 04:05:19 +0000

We are just a bunch of atoms with some sense of our surroundings which we call intelligence, still feeling amazing?