DEV Community: Shubham Jain

I Built a Collection of 100+ Open-Source SVG Spinners

Shubham Jain — Thu, 17 Oct 2024 05:45:37 +0000

Link: https://magecdn.com/tools/svg-loaders
Github: https://github.com/shubhamjain/svg-spinners

There’s been a lot of great work done with CSS spinners by developers like Afif13 and Vineeth TRV. However, I’m personally not a fan of using CSS for this purpose.

Why?

It complicates component creation.
It clutters your stylesheets.
It makes using spinners as backgrounds or images impossible.
Scaling and changing colors are more cumbersome compared to simply tweaking the fill or stroke color in SVG.

SVG-based loaders offer a far more elegant solution. I’ve taken the time to gather spinners from various repositories and Codepens to create a centralized resource. So far, it's 108 spinners. I plan to keep adding.

All spinners are MIT-Licensed, meaning you can use them commercially without any restrictions or the need for attribution.

Enjoy!

I created a free CDN for social media icons

Shubham Jain — Sat, 28 Sep 2024 07:43:30 +0000

Happy to ship my side project: https://magecdn.com/tools/social.

I built this side-project out of a personal pain.

To include social media icons, you either have to use an icon pack (e.g, font-awesome), or copy individual SVGs.

Icon packs feel like overkill if you only want to use a few icons on your website. And I am not really a fan of hunting SVGs and cluttering my code with it.

Additionally, if you want to use icons in an email, you're out of options, since the majority of email clients don't support SVGs or web fonts.

To solve this, I created a free CDN to deliver icons for most social media platforms (if I am missing any, let me know).

Want to embed an icon? Just copy and paste.

It has icons for 20+ popular social media platforms.
It is fast, reliable, and 100% free—powered by Cloudflare.
No attribution is needed.
Supports: SVG, PNG, and WebP

Give it a try. Happy to hear your thoughts!

I Created a Free Web Tool to Make Beautiful Charts

Shubham Jain — Thu, 04 Apr 2024 07:48:39 +0000

I wanted an easy way to create basic charts from the data I have. Both Google Sheets and Excel involve some steps and the results aren't pretty. They haven't changed much for a long time and look completely off when it comes to modern design aesthetics.

There are some other tools but they either require signup, are too complicated, or require attribution.

So, I built something that's super-quick and super-easy to use, and the results are still pretty.

Here's the link: https://textquery.app/tools/visualize/.

Two beautiful visualizations I built using this tool:

I built it using VueJs, echarts, and TailwindCSS. The website is powered by Astro Framework.

Happy to hear your thoughts!

CSS is Impossible and That's Okay

Shubham Jain — Mon, 19 Feb 2024 07:53:00 +0000

I have been a web developer for more than a decade, and yet, when it comes to CSS, I always feel a bit out of depth. Not only it's enormously complex, its complexity is growing every year.

In the year 2023 itself, there were a dozen new additions to CSS: style queries, scroll-driven animations, and trigonometric functions, to name a few.

I hadn't even completely caught up with the intricacies of Grid Layouting, when subgrid and container queries were shipped. Several of the newly added properties handle cases so specific that I hardly believe I would ever use them (hanging-punctuation and font-palette, for example).

Here's more: there are at least three properties related to hyphenating paragraphs. You might have used the filter property, but did you know that it supports an entirely different class of filters using SVG? Or that you can tweak the image scaling algorithm? Or border-radius support elliptical corners?

The complexity can be gauged by the fact that there were at least 25 units in CSS. And with container queries, six more were added. Now, imagine being aware of all those units, how to use them, and more importantly, the best time to use them.

There was a time when I wanted to catch up with everything CSS had to offer, but soon enough, I realized the enormity of my ambition—and also, how largely unnecessary it would be.

Not Knowing CSS is Okay

CSS is complex for a reason. Its objective is to provide solutions for a wide range of use-cases—from a simple document to dynamic interactive websites. I might never need to bother with how a paragraph is hyphenated, but for news websites, it could be pretty important.

The trouble stems from feeling the compulsion to know the whole of CSS. Hardcore enthusiasts like Chris Coyier have probably achieved the feat, but the rest of us need to be content with not knowing a large chunk of the language—a desirable constraint, I would argue.

Because, ultimately, CSS is a toolkit. It's meant to provide tools and solutions for many situations, but not everything is needed at once. You might be proficient with some of the tools, reasonably well with some others, and completely ignorant of the rest. And that's okay!

If you stumble upon the problem that a CSS feature solves, you will likely learn that feature along the way. And even if you don't, it's okay to solve a problem inefficiently, until you stumble upon a better idea in the future. Trust me, you will!

You don't need to use container queries until you feel the pinch of the problem. You don't need to know all the funky ways CSS grid can be utilized. You don't need to feel bad about not knowing how an impressive CSS demo works.

In short, you don't need to be overwhelmed with CSS. Everyone feels a bit lost when it comes to the language—from juniors to seniors, but this is mostly from the expectation of knowing everything.

CSS is hard and in my experience, best learned by practically experiencing problems and deeply understanding the solutions. It's good to be vaguely aware of new additions, but you don't need to start using them right away. Learn them at your own pace; you'll do fine.

“Print” Is the Only Debug Tool You Need

Shubham Jain — Mon, 27 Jun 2022 10:19:40 +0000

This blog post was originally published here

The most basic debugging tool is a print statement. It could be print function, echo, console.log, or alert. Principle is the same: you display (partial) state of the program on the screen, check what stands out, and try to diagnose the issue. “It seems the loop is running more than it should. Let’s see what’s the value of i here”.

No manual is needed to teach it. The idea just comes naturally to programmers.

It works wonderfully for a while. But as programmers get more experienced, they discover better tools called debuggers, which allow programmers to add breakpoints and watchers. With breakpoints, the programmer can pause the execution of program at a specific point and inspect the state with a greater flexibility. In case of watchers, they can keep an eye on the state of a variable.

I have used these tools, too. Over the years, however, I have realized that except for very specific situations, “Print” just works better.

Print is universal: Every language has it. After all, putting something on screen is a pretty fundamental feature of any language. Debuggers can vary across different languages/platforms.
Print doesn’t need specialized tools: print is part of the code. Setting up debugger can often be a hassle, since the debugger and the program are usually different. Sometimes, the integration is seamless, like Chrome DevTools, but with something like node.js, it’s not as easy to make the setup work.
Print doesn’t tie you to a particular tool: Let’s say you’ve the setup working in VS Code. What if you want to switch your editor? You’ll have to figure out to make it work in that editor too. Print, on the other hand, will work everywhere.
Print is faster to use: Compared to creating multiple breakpoints and watchers, and removing them after use, print is definitely easier. Sure breakpoints give you more flexibility in diagnosing the issue, but often most issues aren’t that complicated to warrant them.
Print works on Staging and Production: It’s not easy to work with debug tools when you’re dealing with code running on the server. On the other hand, print statements work there too. Even if you don’t have access to STDOUT, you can write statements to a file or send them to a logging server/service (e.g, Loggly).
Minifying/Compiling code doesn’t break print: If you’re compiling/minified your code, there’s extra complexity in mapping original source do to the compiled one. Let’s say you encounter an issue in the final build. With minified variable and function names, it would be exhausting to find the root cause. However, if your original source includes a print statement, it would be compiled as well and the variables you’re interested in will be displayed.

Print statements are powerful, versatile and flexible. They are rudimentary but every time I have tried to upgrade myself to supposedly better tools, I have come back to printing variables. They are “it just works” version of debugging.

Debuggers have their place. They are useful in places where you don't have the liberty to modify the code or you want to analyse the execution stack better. But in day-to-day work, you'll find print to be a better solution.

What do you think of my HTML5 game?

Shubham Jain — Thu, 31 Mar 2022 12:43:49 +0000

Past two weeks, I have been working on an HTML5 puzzle game: Eight Colors. The rules of the game are pretty simple but it does get a little challenging after the first few levels. It was super-fun to design and implement this game (not so fun though hacking around quirks of iOS Safari 😅)

Let me know what you folks think. Happy to answer any question if you have.

Simplest Way to Include Icons in Your Project: Using Unpkg

Shubham Jain — Tue, 04 May 2021 07:44:44 +0000

The web has come a long way in the past years, but there are still things that aren't straightforward. Using icons is one of them.

Icon fonts, inline SVGs, SVG Symbols—all have their own issues. Inline SVGs are great, for example, but they make the code messy, and can't be cached. Additionally, copy-pasting the SVG itself is pretty time-consuming and a PITA.

Using icons should be simpler. Here's what I always wanted: I see an icon I want to use and I am able to use it right away. No copy-paste; only have to know the name of the icon. No struggling to make the Webpack/Grunt pipeline work. No creating a new SVG file/component for every icon I want to use.

Luckily, I have found a way. Follow along!

svg-loader: Load SVGs from a CDN

svg-loader is a simple library that allows you to inline SVGs hosted on an external source. Here's a more detailed article I wrote about it, but to put it simply, you use it this way:



<script type="text/javascript" src="https://unpkg.com/external-svg-loader@1.0.0/svg-loader.min.js" async></script>

<svg data-src="https://s2.svgbox.net/assets/logo-white.svg" 
    width="50"
    height="50" 
    fill="purple"></svg>

The library will fetch the SVG using XHR and inject it inline. The benefit? You can now customize the fill, inherit the colors, and use states like hover, which wouldn't have been possible with <img> and <object> tags.

The concept isn't new as svg-inject does something similar. However, svg-loader makes this ultra-convenient. You only have to worry about including the script somewhere in the code. Rest everything is handled. And it's framework-agnostic, too (works with React/Vue/Angular...).

svg-loader + unpkg = killer combo

Recently, I discovered that I can use the library and unpkg to quickly include an icon available on Github.

Take, for instance, MDI repository. To my knowledge, it's the most extensive icon repository on Github that has 5k+ icons.

Since the repo has an NPM package, we can browse it on unpkg: https://unpkg.com/@mdi/svg/.

If you click any file and use "View Raw" you'll see that the permalink to any icon is something like this: https://unpkg.com/@mdi/svg@5.9.55/svg/__ICON__.svg.

We can use this to start using the icon in our project. Example:

Hurray! Now, if you need to use the cog icon, you don't have to hunt for the SVG code, or download it, you can just use cog.svg.

Note: The first load can have a slight delay because Unpkg fetches the package and extracts the file, but after the first request, the file is cached and served from Cloudflare CDN.

Q&A About this Approach

There might fair amount of questions about this approach, so I will try to answer the most common of them.

What if there are changes in the repo (like, renaming files)? Won't it break my icons?

No. With unpkg, you'll most likely be using versioned URLs (instead of @latest), which will make sure that the contents remain the same regardless of changes in the repository.

Isn't it inefficient to fire XHR for every icon, instead of bundling them?

No. With HTTP2, the cost of making is incredibly low. For non-blocking resources loaded asynchronously, it's almost irrelevant. Here is me loading 50 icons using the same approach.

Besides, the icons are also cached when loaded first-time, so the subsequent loads are incredibly fast.

What if unpkg goes away?

It won't. It's a project supported officially by Cloudflare and serves 3B+ requests per day.

What if I want to use an icon set that doesn't have an npm package?

You can use jsDeliver that has a similar API and supports raw Github repos as well.

I feel this is a pretty nifty approach for icons. You can use icons from Font Awesome, Octicons, or any of the awesome icon sets hosted on Github.

It's fast, very reliable, and keeps the code clean.

How to Get Better at English: Guide For Developers

Shubham Jain — Mon, 26 Apr 2021 06:43:47 +0000

I saw a post recently where a developer raised very valid points on why English isn't a skill they should be measured with: My English is not perfect. Why would you hire me?

I can empathize with the author but sadly, the reality is different. Like it or not, fluency in English is a vital skill for a programmer.

Most folks, especially in the developed world, are very used to fluent English. Bad grammar sounds off and diverts attention. Even with the best intentions, the listener has to make a conscious effort to ignore it.

In 2013, Facebook ignored multiple bug reports of a serious issue from a security researcher. Why? His English was poor and so the reports weren't taken seriously.

Additionally, a plethora of opportunities open up when you're fluent. You can communicate your ideas better. You can reach out to people with confidence. You can get better jobs. You can write posts, guides, and tweets that others will find interesting.

In all, poor English is a potential hurdle for your career. And it's best to take care of it. I used to find this concept shallow but with time, I have made peace with it. Humans, after all, are imperfect and this is just one of many biases that affect us.

Fortunately, getting better at English isn't much different from learning a programming language. It just takes practice.

I wasn't any good at English, too and for a while, I wondered if I'll ever improve. Luckily, the fear was pretty unfounded. I believe that if you're constantly trying to level up, progress is a natural outcome.

Looking back though, there're obvious ways I could've done it faster, and there were important lessons I learned too late.

I mean to write this guide so you don't have to go through the same mistakes. I hope that the things I learned will help developers who are going through the same struggle.

It's Not Just About Grammar

When we talk about English as a skill, our focus is usually on grammar. It took me a while to understand that grammar is only a part of the equation, and that memorizing the rules of English isn't that helpful. English has tons of nuances in everything, which can only be learned by practice and exposure. Few examples:

Sentence A: The new Software doesn’t fulfill our requirements.
Sentence B: The new Software doesn’t have the things we need.

Technically, both sentences are grammatically correct, but "fulfill our requirements" is overly formal and awkward. It's more suited for a business document than an everyday conversation. Sentence B is simpler and closer to what a native speaker would say.

Another example:

Sentence A: I have invariably loved you.
Sentence B: I have always loved you.

If I look up invariably in the dictionary, it'd be defined as "in every case or on every occasion; always." I might conclude that it can be used as a substitute for always.

However, the word usually applies to processes and objects (rarely people). If you use the word in the wrong context, it has the potential to sound very off. Understanding where a word fits takes time and a lot of reading (When in doubt, use the simplest word).

Three Parts of Fluency

Becoming fluent in English means getting better on three fronts:

1) Getting grammar right: Perhaps, the most important part. People are much more forgiving about clumsy sentences but not that much towards getting tenses and verbs wrong.

2) Knowing words and their appropriate usage: Unfortunately, early learners often hold a terrible idea—that vocabulary is about knowing a lot of words. And as I have frequently observed, it creates room for using words poorly. Good vocabulary, as I wrote earlier, is not just about learning fancy words and their meanings, it's also knowing when to use them.

3) Composition: If I had one word to describe good writing, it’ll be “effortless.” Good writing is a breeze to read and causes the fewest interruptions in the reader’s mind. To explain this, look at these two examples:

Macbeth was very ambitious. This led him to wish to become king of Scotland. The witches told him that this wish of his would come true. The king of Scotland at this time was Duncan. Encouraged by his wife, Macbeth murdered Duncan. He was thus enabled to succeed Duncan as king. (55 words.)

Encouraged by his wife, Macbeth achieved his ambition and realized the prediction of the witches by murdering Duncan and becoming king of Scotland in his place. (26 words.)

The first sentence has too many interruptions and gives a feeling of being written by a novice. The latter is not just succinct, it’s far easier to read—it uses fewer pronouns and helps the reader avoid context-switching.

Don't start with a grammar book

Grammar books are a waste of time. I can write decent, but if you asked me what is 2nd or 3rd form of some X verb or asked me to explain past participle, I wouldn't have a clue.

Think about it, when you speak your native language, do you ever think about what verb of what form you'd be using?

Diving into all the theory like these 4x4 tense tables, parts of a sentence, active/passive conversions has the potential to make you confused without any added value. No speaker learns by memorizing the rules. They just become a natural part of them.

This is not to say knowing the rules isn't important. It would help you know the correct usage of certain prepositions, or when to use have/had, will/would, but my beef is with using a grammar book as the starting point.

They are best suited as a reference. Use them when you're in doubt.

This isn't much different from learning a programming language. Setting out to learn the syntax and the API—without writing any code—will inevitably become a boring grind with not much to show for it. Coding consistently will lead to much better results.

How to actually get better?

There's no magic bullet here. You learn by practice, which here means reading and writing. But here are a few pointers to help you out:

Read Everything

Become a reading machine. This is the single most important thing to do. And I don't mean just books. Read everything. Read articles, and essays. Grab a respected online magazine and start reading their columns. Follow your favorite community (like, Hacker News or Good subreddits) and see the debates and discussions. See how people communicate. Everything adds to your knowledge of how words can be used, and sentences can be formed.

It’s okay if you don’t understand everything. Initially, I could only understand 20% of what I read. But pushing yourself to do this every day, it only gets better.

Watch Videos and Podcasts

Watch talks, documentaries, live conversations, podcasts, tutorials, they help you understand how people talk in real life. Videos/Podcasts also have an added advantage compared to reading: people communicate as they do every day, which means less fancy words.

Movies and TV shows might not be the best options here, as the screenplay is often not written to mimic real-life conversations.

Google Obsessisively

Confused about something? Google it. Not a mighty new trick, but few people do it. I have resolved hundreds of word and grammar questions by searching for their usage. “have vs had,” “always vs invariably,” “simple vs simplistic.” Usually, you’ll get a good article explaining the correct usage.

Use Grammarly

Much better than grammar books is a tool that'll correct your grammar and help you avoid the most common errors.

I haven’t explored all the available options but it’s safe to say Grammarly is the best choice currently—wide support, detects errors reliably well, and offers a handy explanation in the tooltip.

I would even say that you should get a premium subscription (no affiliate link), which is totally worth it. The suggestions made by the premium subscription will help you sound more natural.

Have people who will correct you

I was fortunate that I had folks around who would correct me if I made a mistake. Getting corrected might seem a little embarrassing (or even annoying) but trust me, it’s the best way to learn. Encouraging people to correct you is a shortcut to finding out your mistakes.

Try to get more specific feedback. Usually, people pinpoint that your English has issues, but not knowing where the problem is can leave you scratching your head. Ask them what specific mistakes you've made. Where can you improve?

Write Regularly

Write. Write. Write. It can just be a small opinion, or journal entry, or a story (if blogging is not your thing). Writing helps you lay down the idea and communicate clearly. Once you have a draft, go to someone whose opinion in writing you can trust and ask them to correct it without restraint. It could be your good friend, a partner, or a mentor. Don’t be disheartened if the mistakes are far more than you imagined, it’s only helping you improve.

Revisit what you wrote earlier. Try to see the mistakes you made in your past write-ups.

Don't Be Clever

This took me the longest to learn. I tried way too hard to be clever. Instead of writing "he ignored the warning signs", I wrote, "he snubbed the warning signs." Instead of sounding smart, I ended up giving the impression that I was an amateur trying to pretend I know more than I do.

Most of the good writing I have seen doesn't use novel words frequently. Write simply!

The biggest mistake you can make is to a) assume you won’t get better, and b) shy away from critical feedback. I made both and it only hampered my progress. The mind is surprisingly efficient at learning if you're constantly pushing yourself.

Good luck!

There's nothing wrong with inline styles

Shubham Jain — Thu, 22 Apr 2021 04:47:28 +0000

A frequent criticism leveled against TailwindCSS is that it's just a fancy way to write inline styles. Usually, people counter by saying you can't create a design system with inline styles or limit the number of options.

However, I would say the idea is not far from the truth—TailwindCSS is just a nicer/shorter way to write inline styles, one that supports media queries and pseudo-elements as well.

The earliest implementation of Tailwind's approach I saw was in AtomicCSS. A framework I laughed off when I first came across it.

Tailwind introduces a way to create a design system over pure inline styles, but overall the underlying ideas are the same. I see no reason why I won't be as productive with AtomicCSS as I am with Tailwind.

Once you let go off the notion that inline styles are inherently bad, you will become more accepting of Tailwind's ideas.

In the ideal world, we will have a frozen set of design components and we will never have to write CSS except on very rare occasions. The components are updated rarely and there's no ambiguity about what belongs where.

But the real world doesn't work that way. Here's what I have seen happen at companies:

You write the same styles again and again (flex, font-sizes, spacing).
You end up creating tens of container components that do the same thing.
You try to generalize components, only for a new requirement to come in which throws your assumptions out the window.
You create a Card component, but having to fulfill more and more requirements, you have made it so generic that in the end, it's just a white box with box-shadows.
You want to reuse the style of the X component, but realize that your new component is called Y. So, you can't help copying the same styles again.
The stylesheet has grown to more than a megabyte, most of it is composed of the same styling applied repeatedly.
You want to use Modal component, but you see that it gives way too much padding. So, you write more styles to override them.

These problems are quite universal. Unless your team is really small, writing CSS the way people idolize is extremely hard. Often, it never works.

If the problem is so universal, maybe we ought to approach things differently.

Inline styles solve it perfectly. You can use the styles you want without worrying about components. If you see a common component emerging, just extract it. The team won't waste time writing CSS for stupidly simple things, thinking names, and discussing how to modularize the CSS code. The evolution would be organic.

Is it ideal? No, of course. But, seeing the real-world scenarios, it's much better than alternatives.

It's just like refactoring. Time and time again, I have seen programmers who write duct-taped code, and try to clean it up later are much more productive than the ones who spend an entirety discussing the right approach.

https://twitter.com/davidwalshblog/status/1098960128794128384

Even when I am not using TailwindCSS, I approach building the frontend solely using inline CSS. Once I have everything ready, I start to create the CSS classes. Because then, I have a much better idea of how to organize them.

Inline styling is a tool that's needlessly been demonized. It's often much better than alternatives. And that's why TailwindCSS is winning.

I analyzed my six years of food deliveries

Shubham Jain — Sat, 17 Apr 2021 10:25:36 +0000

Before food delivery apps came along, ordering food online was a pain. I started using Swiggy, the Indian food delivery app, in 2016 and because it made it way too easy to get food delivered, my orders just went through the roof. I thought it will be fun to analyze how much and what have I ordered.

There are two sections of this post: a) How I did it? b) The numbers and my analysis. Depending on your interest, you can skip either.

How I did it?

Swiggy doesn't have an API to get your personal data. However, it has a page where it lists your past orders. Trouble is, it will only show five orders at once, and you have to click "Show more orders" to go further back. Naturally, you have to automate it somehow.

Figuring out the source of data

Order Page XHR

I first logged in to the web version of the app since it will be comparatively easier to analyze the requests there. It seems the orders page makes an XHR request to the URL /dapi/order/all?order_id=$$ORDER_ID$$ to fetch the orders where $$ORDER_ID$$ is used for pagination.

Order Page Response

The response is an array of JSON objects with a lot of fields.

We don't need to figure out which parts of response we need to use, because we can store it all and see to that later.

I will use Postgres to store this data because a) it just works and b) has great support for querying JSON. Installing Postgres locally is really simple on Macs via the Postgres app.

Here's the schema I will use:



CREATE TABLE swiggy (
    order_id text PRIMARY KEY,
    data jsonb
);

Why do we just need two columns? Because order_id is enough to uniquely identify every order and in the data column we can dump the whole object. As I said earlier, Postgres makes it really easy to query JSON.

Getting the data

Let's get the data! I will be using bash for this. "BASH???? ARGHHH. WHY???", you may ask. I used to have a similar aversion towards bash, but in the past year, I have realized it makes it really easy to do certain things once you get the hang of it.

It's perfectly fine if you want to use a different approach as the basic ideas would be very much portable. Like, using axios instead of cURL.

First, the basic request. We need to figure out if a simple request for getting orders would work at all. The easiest way to do that is to "Copy as cURL" the request from the developer's console and run it in your terminal.

If it works, that's great! You can start removing the unneeded parameters, like headers, user agent, and tracking cookies. After I did the trimming, the basic request to get orders boiled down to this:



curl -sL "https://www.swiggy.com/dapi/order/all?order_id=$next_order_id" \
     -H "cookie: _session_tid=$SESSION_ID"

where $SESSION_ID is the long parameter visible in the first screenshot.

Once the request works, we can parse the JSON and iterate over the objects using jq.



IFS=$'\n'
for order in $(echo "$all_orders" | jq -c '.data.orders[]' ); do
    echo "$order"
done;

Why do we use IFS=$'\n'? Because by default bash will split tabs and spaces too, and various names in the response (like restaurant, delivery person) can have spaces.

Now, we just need to store it in the DB. And write code to fetch the next orders. In all, the whole script will be like this:



#!/bin/bash

# Your Swiggy Session ID, check screenshot #1 
SESSION_ID="__SESSION_ID__"

while true; do
    all_orders=$(curl -sL "https://www.swiggy.com/dapi/order/all?order_id=$next_order_id" \
    -H "cookie: _session_tid=$SESSION_ID")

    IFS=$'\n'
    for order in $(echo "$all_orders" | jq -c '.data.orders[]' ); do
        # We use $$ to wrap $order because it takes cares spaces in the data
        psql "postgres://shubhamjain@localhost/stats" -c "
            INSERT INTO swiggy (order_id, data) VALUES (
               '$(echo "$order" | jq -r '.order_id')',
                \$\$$order\$\$
            );
        "
    done;

    # Next order id would be order id of the last object in array
    next_order_id=$(echo "$all_orders" | jq '.[-1].order_id')
done;

After running this, you should see something like this:

At some point, it will start failing, which means it has reached the end and you can quit the script then.

Note: None of this is the ideal way to do things. I wasn't interested in programming properly, only hacking together something cool.

Six years in numbers

Cool! Now we have the data. Let's jump to answering questions.

Q.1: How much I have ordered?

A LOT! I knew I was ordering a ton of times, but I never put a number on it. Actually doing that, with this project, I was taken aback realizing the number of orders I have made and the money I have spent.



SELECT COUNT(*), EXTRACT('year' FROM date(data->>'order_time')::timestamp) as year FROM swiggy GROUP BY 2;

Total orders: 915

Year vs. # of orders

How much I have spent?



SELECT
   SUM(CAST(data ->> 'order_total_with_tip' AS DOUBLE PRECISION)),
   EXTRACT('year' 
FROM
   DATE(data ->> 'order_time')::TIMESTAMP) 
FROM
   swiggy 
GROUP BY
   2;

Total spent: ₹1,84,329

Restaurant vs. # of orders

That seems to a lot of money. Enough to buy a decent second-hand car, at least.

Q.2: Where do I order from?

Pareto Principle seems to apply very well here. Most of my orders are for a cafe called Chai Shai. I love ordering from there—it has good snacks and everything is well-packaged.



SELECT
   COUNT(*),
   data ->> 'restaurant_name' 
FROM
   swiggy 
GROUP BY
   2 
ORDER BY
   1 DESC;

Restaurant vs. money spent on orders

Q.3: When do I order?

It seems I order more during the morning and afternoon than in the evening. That can be explained by the fact that I often don't feel that hungry in the evening and I prefer something light for dinner.



SELECT
   COUNT(*),
   EXTRACT('hour' 
FROM
   TO_TIMESTAMP(data ->> 'order_time', 'YYYY-MM-DD hh24:mi:ss')::TIMESTAMP) 
FROM
   swiggy 
GROUP BY
   2;

Hour of the day vs. # of orders

Q.4 What do I order?

It seems I am fond of ordering for a quick bite and desserts than a full meal. Desserts are something I should definitely cut down on.



SELECT
   cuisine,
   COUNT(*) 
FROM
   (
      SELECT
         JSONB_ARRAY_ELEMENTS_TEXT(data -> 'restaurant_cuisine') AS cuisine 
      FROM
         swiggy
   )x 
GROUP BY
   1 
ORDER BY
   2 DESC;

Cuisine vs. # of orders

Conclusion

It was an interesting exercise to understand my habits over the years. There are tons of ways I can dig more into the data but for now, I will stop here. Insight fatigue isn't great either.

I don't think ordering is necessarily bad but it's lazy. Knowing the scale of my habit, I know it would help me to make a little conscious effort to order less.

A better way to use SVGs

Shubham Jain — Sun, 04 Apr 2021 09:31:43 +0000

It's 2021, and we are still not settled on the best way to SVGs. Inline SVGs offer all the benefits—being able to directly modify fill color, use CSS variables, and modify the inner SVG elements—but have the obvious downside that they make the code messy.

Storing them externally is a better option, but the only reliable way to use them is the <img> tag, which comes with severe limitations.



<!-- Can't modify the fill color if you want -->
<img src="/path/to/img.svg" />

To solve this, I have created a library that offers all the benefits of inline SVGs, while still storing them externally. It's called svg-loader.

Check, for example, this logo of my project in SVG.



<img src="https://s2.svgbox.net/assets/logo-white.svg" />

Preview

Since the fill color is not defined, it will default to black and there's not much you can do about changing that. There are a few hacks around this using the filter property, but they are complex and not easy to modify.

In comes, svg-loader. You just have to drop the script in and the external SVGs will be fetched and injected inside the element. Like, this:



<script type="text/javascript" src="https://unpkg.com/external-svg-loader@1.0.0/svg-loader.min.js" async></script>

<div style="display:flex;">
    <div style="background:black;">
        <svg data-src="https://s2.svgbox.net/assets/logo-white.svg" fill="yellow"></svg>
    </div>
    <div style="background:purple;">
        <svg data-src="https://s2.svgbox.net/assets/logo-white.svg" fill="white"></svg>
    </div>
    <div style="background:green;">
        <svg data-src="https://s2.svgbox.net/assets/logo-white.svg" fill="white"></svg>
    </div>
</div>

Preview

View on JS Fiddle

The library is very light <2KB (post-compression). The loads are lightning fast and also comes with a way to cache the file for longer. So, the image isn't fetched repeatedly. And pretty much works anywhere.

Compatible with React, Vue, Angular

svg-loader is framework agnostic and works with most front-end frameworks. You just need to include the library somewhere and everything else will be handled:



import React from 'react'
import ReactDOM from 'react-dom'

import 'external-svg-loader';

class App extends React.Component {
  render () {
    return (
      <svg
        data-src="https://s2.svgbox.net/materialui.svg?ic=mail"
        fill="currentColor"
        width="50px"
        height="50px"
        style={{
          color: 'red'
        }}
      />
    )
  }
}

ReactDOM.render(
  <App />,
  document.getElementById('container')
);

View on Codesandbox

Note: The resources need to be compatible with the CORS policy since XHR is used to fetch them.

Thoughts? Questions? Feel free to reply here.

Simpler Way To Conditionally Add Properties to Javascript Object

Shubham Jain — Sun, 07 Feb 2021 06:20:23 +0000

Ever had a situation where you wanted to conditionally add an attribute to a javascript object and you had to use let instead of const and add an if condition just because of that? I am talking about this:



let userProps = {
   username: "rad-coder" 
}

if (userIsBanned) {
    userProps.banned = true
}

return userProps

In the above code, if there was no conditional attribute, userProps wouldn't have been needed. If there are multiple attributes like that, that means more if conditions and code.

Simpler Alternative

Instead of using the if statement, you can use the spread operator. The idea is simple: the spread operator merges the properties of the target object with the object it's being applied on and if the source object is null, it adds no properties.



const x = { ...{ a: 2 } } // => x = { a : 2 }
const y = { ...null } // => y = {}

Now, we can use the same idea to simplify our code:



return {
   username: "rad-coder",
   ...(userIsBanned && {banned: true})
}

And if there are multiple conditions:



return {

   username: "rad-coder",

   ...(userIsBanned && {banned: true}),

   ...(userIsOrganic && {organic: true}),

   ...(userIsPaid && {paid: true}),

}

"Code is Harder to Read!"

I know some folks would say that this just makes code harder to read and is needlessly clever. And maybe that's right.

I personally find it a nifty trick to avoid writing more code than that's needed, but some developers might not feel that way, which makes its usefulness subjective.

So, use it if only you think it's a good choice.