Imagine this: every time you switch projects, it feels like someone else has been wearing your underwear. Creepy, right? That’s what happens when you don't isolate your project environments. But with version managers, each project gets its own little bubble, free from the weird, uncomfortable overlap. Picture it: Python 3.8 in one corner, Python 3.10 in the other. No mixing, no awkwardness. Just pure, isolated bliss.

Because sometimes you need your own space... like your projects do.

And let’s talk about the drama—dependency drama. You know that feeling when you walk into a party, and your ex is there... with your other ex? Yeah, dependency hell is just like that—awkward, unpredictable, and full of regret. But don’t worry, with version managers, you can avoid that drama altogether. You get to manage the exact versions you need, and no one has to know about that messy breakup with Node.js v14. It’s all smooth sailing from here.

Now, switching between versions should be as easy as changing your pants. No judgment here if you don’t do that often. The point is, with version managers, you can move between projects faster than a spy swapping disguises, and your code will never know the difference. Today you’re all about Python 3.8, tomorrow you’re rocking 3.10—no problem at all.

Speaking of problems, nothing’s worse than being "that guy" in a team—showing up to the dev meeting with everyone else on Python 3.7 while you’re still cruising on 3.5. Avoid the embarrassment. With version managers, you can set up a standardized environment for the whole team, so everyone’s on the same page. It’s like syncing your Spotify playlists but for code. Consistency is key, and trust me, your team will thank you.

Scenario: You’re in a team meeting, and everyone’s code is running on Python 3.7. But, you’re still on Python 3.5. When you try to run the code:

python main.py

You get a syntax error because Python 3.5 doesn’t support f-strings. A quick check confirms your suspicion:

python --version

Output: Python 3.5.10 To avoid this, use pyenv to align with your team. First, install the correct version:

pyenv install 3.7.12

Then set it locally:

pyenv local 3.7.12

Now, you’re in sync with your team and ready to code without hiccups.

Experiment with Confidence

Experimentation? Rollback? Yeah, we all love to live on the edge sometimes—try out that new language feature, maybe flirt with a different framework. But if things go sideways, version managers have got your back. They let you roll back faster than a toddler realizing broccoli isn’t candy: no harm, no foul, and no judgment.

Legacy systems, though—those are like your old, comfy sneakers you just can’t let go of, even though they’re way past their prime. With version managers, you can keep those older versions around for those long-lived, still-useful projects without feeling like you’re stuck in the past. And for the record, sometimes old-school is the best school.

Now, we all know time is money, and who wants to waste it managing versions by hand? Version managers streamline your workflow, reduce conflicts, and let you get back to what really matters—coding like a boss and taking those slightly-too-long coffee breaks. You’ll be so productive, they might actually start paying you in coffee.

Here's an example of managing versions seamlessly on your device:

Instead of manually managing Python versions, which can be time-consuming:

# Manually uninstalling an old version
sudo apt-get remove python3.5

# Installing a new version manually
sudo apt-get install python3.7

With a version manager like pyenv, you can effortlessly switch between global and local versions:

# Install a specific Python version
pyenv install 3.7.12
pyenv install 3.6.10

# Set it globally for all projects
pyenv global 3.7.12

# Or set it locally for a specific project
pyenv local 3.6.10

Now, whether you’re working across multiple projects or just one, pyenv ensures you’re always using the right version. No hassle, no conflicts—just pure, streamlined productivity. And with all that time saved, you can kick back, code like a boss, and take those slightly too-long coffee breaks. Efficiency never tasted so good!

And here’s the kicker: version managers come with whole communities behind them, ready to help you out if you get stuck. Think of them as your trusty sidekick. Whether you’re using pyenv, nvm, rbenv, or the versatile asdf, there’s a whole ecosystem out there to support you. It’s nice to know that when you’re in a jam, you’re not alone. Plus, these tools play nicely with the rest of your tech stack—no awkward introductions needed.

Finally, let’s not forget compatibility testing. No one likes surprises (unless there’s cake involved). Version managers make sure your code works across multiple environments without any nasty shocks when you hit deploy. It’s like doing a dry run before you meet the in-laws—better safe than sorry, right?

So, here’s the deal: version managers aren’t just a convenience—they’re a necessity. They make your life easier, your projects smoother, and your team happier. Plus, they give you that warm, fuzzy feeling that comes with knowing you’re a step ahead of the game.

If you’re not managing your versions, who’s managing you? Go ahead, give version managers a try, and let them add a touch of style and sanity to your coding life.

Additional Resources:

• pyenv: Simple Python Version Management

• nvm: Node Version Manager

• rbenv: Ruby Version Manager

• asdf: Manage multiple runtime versions with a single CLI tool

Understanding Git Basics

At its core, Git is a distributed version control system that excels in managing code changes across multiple contributors and branches. While Git's user-friendly commands make everyday tasks like committing, branching, and merging intuitive, understanding its internals unlocks a deeper level of proficiency and confidence in its usage.

Let's take a look at what a typical Git's folder structure looks like inside our project:

As we can observe Git saves its contents inside the .git folder in our project directory.

The .git folder is a critical component of every Git repository, housing all the necessary information for tracking code changes. Here's a breakdown of its key contents:

• HEAD File: This text file stores the SHA hash of the currently checked-out commit, effectively tracking the current branch.

• refs Folder: Contains references to commits and branches, with subfolders like heads for branch heads and tags for tags.

• objects Folder: Here, Git stores the codebase as a series of snapshots, with two subfolders: pack for compressed snapshots and info for metadata.

• config File: Stores repository configuration settings, including user information and default branch settings.

• hooks Folder: Allows users to add custom scripts to run at specific points in the Git workflow, such as before committing or after checking out.

Deciphering the SHA-1 Hash

I've always found one of the most intriguing aspects of Git to be its reliance on SHA-1 hashes for uniquely identifying commits, trees, and blobs. These 40-character strings might initially seem arbitrary, but they're actually at the heart of Git's architecture. SHA-1 hashes are generated based on the content of an object, ensuring each one is entirely unique. This means that even the slightest change in content results in a completely different SHA-1 hash, thus ensuring data integrity and preventing accidental duplication. The Three Git Object Types

Optimizing Storage with SHA-1 Hashes

Git's use of SHA-1 hashes enables efficient storage optimization. Identical file contents result in the same SHA-1 hash, allowing Git to store them as a single blob, even if they appear in multiple commits or branches. This deduplication mechanism minimizes disk space usage while preserving the integrity of the repository.

Git operates on three main object types: commits, trees, and blobs. A commit represents a snapshot of changes made to files along with metadata such as author, timestamp, and commit message. Each commit points to a tree object, which in turn references the file structure. Finally, blobs contain the actual file contents. Together, these objects form a directed acyclic graph, tracing the history of changes in a Git repository.

What makes git so special and different from other version-control tools out there?

The concept of a "snapshot" is crucial for understanding how the version control system operates. When we commit changes to a file, Git creates snapshots of the entire file rather than just the differences between the new and old versions. This approach, known as the "loose object format," means that even a minor change to file results in a new snapshot being saved to disk. While this may consume more disk space compared to systems like Subversion that save only the delta between versions, it streamlines the commit process and ensures integrity.

To illustrate it better here's an example of a snapshot from my own project that I did before:

In the above screenshot, we can observe that we are using this command git cat-file -p for gaining information about the weird hash strings we see on maybe Github or Bitbucket or any application that you might be using along with git.

The 0ee3f59 bit that we can observe up there in the first line is the value of hash present at the commit currently at my HEAD of the branch(SNAPSHOT of the whole project). The 40-character hash string in the next command is the hash value of the tree that we can observe in the first command's output. We are using that command to gain more information about what contents it is harbouring inside it in a nutshell!

Similarly to inspect a blob we can further use the same command on the hash value of a blob and depending upon the options we are using with git cat-file command we will get the desired results.

Packfiles and efficiency?

Git optimizes disk usage through periodic processes like "git gc" (garbage collection), which creates "Packfiles" and removes redundant snapshots. Packfiles consolidate similar snapshots, reducing disk space usage to levels comparable to other version control systems that use delta compression.

This balance between performance and disk space efficiency is one of Git's strengths, allowing it to outpace other VCS systems in commit speed while keeping disk usage in check. The Packfiles, located under ".git/objects/pack," are generated through the "git gc" command, demonstrating Git's continuous optimization efforts.

Exploring Branches and Tags

In Git, I see branches and tags as valuable pointers to specific commits. Branches are especially handy for branching workflows since they're lightweight and easy to create. Typically, the "master" branch is the go-to starting point for new projects, acting as the mainline branch. On the other hand, tags offer named references to significant commits like release points or milestones, adding clarity and context to the repository's history.

Git Internals in Action

Let's dive into the inner workings of Git by applying it to our project. Through hands-on experimentation, we'll create a sequence of commits and examine the underlying objects, gaining a deeper understanding of how Git handles version history. With each commit, we capture a snapshot of the entire project, showcasing the interconnectedness of commits, trees, and blobs.

Here's what the commit history should look like. Using the command mentioned earlier we can go over each snapshot and see how the files are being tracked and how blobs are created.

Conclusion

By understanding how Git manages version control through commits, trees, and blobs, we can navigate complex workflows with confidence. Embracing Git's decentralized architecture and leveraging its branching features empowers our teams to collaborate effectively and deliver high-quality software iteratively.

More things I'll be covering in future articles -

• Branching Strategies

• Workflows

"Spy game" - what's ringing in your ears? I bet you're imagining something like one of those "Tom Cruise" movies like "Mission Impossible". Well, it's almost exactly like that with a tad bit of retro flavor to it.

"Spy Game" is this cool spy movie from 2001 with Robert Redford and Brad Pitt. Redford plays this CIA guy, Nathan Muir, who's about to retire. His buddy, Brad Pitt's character, Tom Bishop, gets caught in a tight spot in China, and Redford's like, "Nope, not on my watch!" So, he goes on this crazy mission to save him.

What makes this movie awesome is the story. It's all twisty and turny, jumping between the past and the present, showing how these two dudes got into the spy game. Redford nails the role of the experienced agent, and Pitt brings in the younger, wild vibe. The action scenes are top-notch, keeping you on the edge of your seat.

There are some areas where I felt the cinematography by the director Tony Scott could have been better. So, the movie can be described as a narration of episodes that happened previously and the story goes on by developing them in sequential order to bring the audience to the current event that is happening in the movie. The constant switch between the conference room and the life story of Tom(the character played by Pitt), is killing all the "Mojo". For me, the flow is breaking which is dialing down the effects suspense should have on us!

I appreciate this movie as four distinct ones: the three flashbacks and then Muir's machinations at CIA headquarters. The Vietnam story is fine. The Germany story is my absolute favorite because of course that's the one where Robert Redford is teaching Brad Pitt how to be a spy. The Beirut story is pretty solid. And the CIA HQ story is really interesting after the conference call is over and Muir basically runs his own bureaucratic-but-somehow-thrilling operation within CIA corridors.

It's not just about the action. "Spy Game" dives into some deep stuff, like loyalty and sacrifice. It makes you think about the whole spy world and the tough choices these guys have to make. (Makes me wanna be a spy🎃)

If you're into spy flicks, good acting, and plots that keep you guessing, you'll totally dig "Spy Game." It's a wild ride from start to finish!

That memory wasn't particularly happy if you know what I mean. She left memories, those that remained were mostly happy, though I should have known that the happiness came coupled with a fake personality. The point is that even though I thought that I had recovered from that unfortunate event, the harsh reality was that I didn't. The next two years of my life were accompanied by melancholy and depression of a sort that I was unaware of. Despite my melancholy, I grew emotionally and in a way enjoyed being in the shadows.

In a sense, it seems odd that anyone could enjoy melancholy: a disease characterized by sadness and fear that has age-old roots. Melancholy's symptoms, and its consequences, can be extreme. Around this time, I came across a book known as The Anatomy of Melancholy written by Robert Burton. I found the answer to my question, namely.

Why are people drawn to a disease that could kill their minds?

After a lot of research I came to realise that, since ancient Greece, melancholy had been associated with the genius of renowned poets, artists, and philosophers, and during the Renaissance, it became fashionable to depict people in a melancholic pose, dressed in black - my favourite colour. Yet such affectation in my opinion could conceal a potentially dangerous, habit-forming affliction from which I surely suffered(not saying that I am a genius or anything XD).

In the book Anatomy, Burton describes melancholy as like a Siren, luring its victims into an ‘irrevocable gulf’. It can start pleasantly enough: a person might want to spend time in solitary contemplation, wandering alone in the woods or down by the river.

‘A most incomparable delight it is so to melancholy, and build castles in the air’, he comments.

Though seemingly innocent, this behaviour starts to intrude on everything, until the person experiencing it can no longer control it:

'these fantastical and bewitching thoughts so covertly, so feelingly, so urgently, so continually set upon, creep in, insinuate, possess, overcome, distract, and detain them, they cannot, I say, go about their more necessary business, stave off or extricate themselves, but are ever musing, melancholising, and carried along'.

Burton’s language hints at the experience he is describing which is soooo relatable: he heaps verb upon verb, crowding his words in just as the ‘bewitching thoughts’ occupy the sufferer’s mind.

I decided to step back into the dating game after 2 years of resentment and breakups. I liked a few girls but COVID slapped me in the face with a monumental welcome. This kept me at home at the expense of a possible date with another girl. I stayed at home like a sitting duck while I waited for the day when I could showcase my life skills.

“The day stretched out the daylight as if on a rack. Each moment was drawn out until its anatomy collapsed. Time broke down. The day progressed in an endless sequence of dead moments.”- China Miéville, Perdido Street Station

So, around this time, I was having a deep talk with my single friends about our relationship and each of our fuckups, and the day came when I realized I was totally single [ I felt like my mental nuts were being punched :) ]. In the meantime, I was talking almost every now and then with a girl. I knew she was single, so my toxic mind started sending me these weird signals and before I knew it, I was already into her. My friends caught wind of this and you know how it turns out :(. With an endless barrage of taunts coming their way and all the sweet conversations I was having with this girl, my fragile brain exploded with frustration. Boom, the end of phase 1.

No conversation between the two of us for the next two months. My confidence was touching the feet of hell. Life was tough back then, I couldn't even imagine it now, that I had stooped so low to care this much about someone with whom I have only conversed via an online medium. It was the 3rd of August 2021 - Friendship day: Guess what she texted me "HAPPY FRIENDSHIP DAY".

All it takes is a second and your whole life can be turned upside down. - Jodi Picoult

I did not plan to reply to her, but my benevolent heart overruled my abate resolve. I gave her a cold reply...it became warmer as I talked to her, and soon it became too hot to handle :). As I was talking to her after 2 more months, I was literally living on the edge. My life was a mess, so much was going on, & here I was wasting my time on a lost cause. To get my life together, I did the unthinkable; I professed my feelings to her - an ultimatum which I knew was going to end things between us but at least I got my shit together.

What's the lesson here? Don't expect things to always go your way every time. It will only bring you sorrow. Of course, I am not suggesting to stop being optimistic in life, but keep doing reality checks from time to time. While I do not regret giving her the ultimatum, if given a chance to do it all over again, I would like to talk to her just like a friend because I have found out that I was merely attracted to her, not in love. It took me 2-3 months to realize that my meat brain was only playing a ruse on me.

Finally, as a result of covid's spanking of my arse, I've gained newfound emotional maturity and some new perspectives, which have skyrocketed my confidence straight to the heavens. Met new friends, relived those nostalgic memories of college, socialised like never before, got a fake driver's license XD, travelled to places, and started believing in spirituality and whatnot. I think covid did a big favour to me by sucking out that depression that was stubborn as a mule.

It will please some of you to know that I almost titled this article ‘College? placement?? Bitch!’ It will please the rest of you to know that I realized not everyone is gonna be happy reading that so, I begrudgingly decided against it

A little introduction about me:

I am currently a student in my final year of engineering pursuing a B.E in computer engineering & I like chocos :) So, that means it is my placement season (>"<). Now, that should be a good thing because most people wait eagerly for it, as everyone wants a job in their hands ASAP.But I guess god is having different plans for me (-_-).

Talking about campus placements in my college: it is pretty good TBH for a 3 tier college. A lot of companies are visiting & not just for any position, they are giving away amazing profiles & opportunities. So, why am I so sceptical about this? Well, because of this godforsaken pandemic a lot of bad happened SMH. My frustration is absolutely dependent on 1 single factor i.e; POINTER.

That LiL decimal number was so important I couldn't have ever imagined in my life(Although, I was reminded about it several times, but hey who cares about it right?). I got 10 pointers in my 5th and 6th semester, & I was unconditionally chill in my life. For, the first time in my life I felt like someone suddenly lit up a tiny light bulb 💡 in my endless void of failures. Then one day my buddies & I were just swooning over our pointers when one of us had a terrible realisation that besides us most of our batchmates also scored 10 pointers. Finally, after a series of sorrowful realisations, we finally came to a conclusion that we got played while Jesus was vibing in his own zone🥲.

Let me break it down for those slowpokes who still have no idea of what I am talking about. This scenario is for students who all are going to graduate in the year 2022. Till now we are done with a total of six semesters, of which we had given the first 3 semesters in offline mode while 4th sem is kind of hybrid and the rest i.e; 5th and 6th in online mode. So if you notice your 4th-semester result is largely based on your 3rd-semester results(At least in Mumbai University). While for most of the people there 5th and 6th-semester results are greater than 9.5.

Now, when a company comes for placements, they are going to set eligibility criteria based on pointer distribution among students most of the time, & guess what will happen next. BAM! the final pointer is essentially completely based on our sem-1,2,3 results, which sucks.

As a result, I was ineligible for most of the dream companies that were coming for campus placements, only because of my incompetence in early semesters. So, in my POV I consider this whole process as one big scam but then again I really can't be a crybaby about it. This post's main purpose was to take out all that pent up frustration inside me & hopefully it works(fingers crossed). I think companies shouldn't just blindly cut people off, just based on their Academics(pointers), I mean it literally, what are the aptitude tests for then?

Superficial Knowledge breeds arrogance, true knowledge induces humility

So, I was watching some random interview videos of backend development in Nodejs and I came across this term Temporal Dead Zone. My immediate reaction was like "huh, what is this?? looks interesting!". Naturally, I stopped the video & googled this term, turns out it was just a fancy term for something obvious for experienced javascript developers :p.

Let me give some context to all those readers who are scratching their heads like me(Unfortunately, I am also a newbie js developer :)). Whenever a js script is executed whether it is inside your browser or on your server, it doesn't matter where it is, an execution context is created. So, what is this execution context? It is essentially how a js program is compiled and executed. A js program's execution involves 2 phases: The first phase is where our variable environment(variables, method declaration, etc) is initialised(only memory space is reserved in this phase actual assignments of values doesn't happen) & the second phase is known as a thread of execution. In the second phase, the js engine actually does all the assignment of variable values, calls the functions and executes the code inside them using a call stack.

Let's talk about variables in javascript. In js, we can make variable declarations using 3 keywords, i.e; var, let & const. Variables declared using the keyword var are stored in the same memory space of the actual js script execution while in the case of let and const the variables are defined in different memory spaces. Here's a practical example of what I am trying to say:

In the above screenshot, we can clearly observe that variable defined using let is declared in a separate memory space(Script) while var declarations are stored in global memory space. In order to understand why this happens in javascript, y'all should read the concept of Hoisting in JS.

So, basically during the creation phase of the execution context, the variables are hoisted. let and const declarations are hoisted in separate space than var declarations. (Note: Many js developers think that let and const declarations are not hoisted but they are actually hoisted, just in different memory space, hence: not accessible until initialised)

Now, I would define the temporal dead zone as:-

The time since the let or const variable was hoisted till the moment it was initialised.

Yeahhh! that's it. That is all there is to it. Pretty easy huh :). Okay so now I know what it is but what if I choose not to give a shit about it, what can happen at worst?? My dear javascript developers if you don't respect this little concept then you might end up in a lot of misery of code debugging. Let's say you declared a variable using let and const and tried to reference it before even initialising it then boom bam!!! You will observe a nice little red line in your console shouting Reference error.

In the above attachment, we can clearly observe that we are trying to log a before initialising it so, it was throwing a reference error. In this case, if we were to swap lines 1 and 3 then the zone between those lines would essentially be referred to as the temporal dead zone of a. So here's my advice use let and const declarations very carefully but again use them as much as possible for their obvious advantages :).

Adios Amigos!!

References:

Must Watch youtube video: https://www.youtube.com/watch?v=BNC6slYCj50

Really thorough article: https://www.freecodecamp.org/news/what-is-the-temporal-dead-zone/