Anyway... then it happened.

I asked for the next piece. Same pattern, right? Apply what we'd learned.

But wait.

It started explaining stuff we'd already solved. Basic things. I scrolled up. Pointed to exactly where we agreed.

[Me]: "Remember? We talked about this."
[AI]: "Oh absolutely! I remember."

Then it ignored everything.

Not amnesia. Amnesia would be honest. This was performance. The AI was cosplaying its earlier self, saying the right words, missing all the actual context.

What You See Isn't What You Get

The transcript you see is not the input it gets. The UI is lying to you.

Here's the thing. You look at that chat window and see a conversation. Fifty messages. History. Context. But that's not what the AI sees.

It gets a summary. A compression. Three paragraphs where you see fifty. Decisions you didn't make about what's "important" and what's "noise."

The UI promises WYSIWYG - what you see is what you get. But with AI chat, what you see is theater. And the actor backstage is reading from a script you didn't write.

So what's actually in that script? Let's look closer.

Context Isn't a Transcript

Even before limits, longer inputs make models miss details. Engineers work around it. You loose control.

Here's the thing: your conversation isn't sitting in memory like a text file. It's being actively crammed into a space that's too small.

Context windows are limited. Even in that, the context "rots". Intelligence goes down as you add more tokens.

Even before you hit the limit, models can get worse at using what you gave them. Chroma calls this “context rot”: as the prompt gets longer.

Src: https://research.trychroma.com/context-rot

So apps summarize. They compress. Sometimes it's just most recent messages. The point is: They decide what matters and throw away the rest. You can't see it.

The AI isn't re-reading your conversation. It's seeing a "compressed JPEG" of what you actually said - a lossy version. Zoom in and you'll find artifacts. Nuances vanish. The context it "remembers" is an approximation, not a record. And when you can't see what's been lost, you can't trust what you're building on next.

The "prompt" is the only input you have for the AI, and weirdly, we are okay giving up control over even that.

Write It Down or Lose It

Memory you can’t inspect isn’t memory. It’s hope.

You can't hope the summarisation algorithm cares about the specific pattern you spent three hours establishing. hope is not a strategy.

What you need is as much control and predictability over tokens going in as possible.

So I stopped treating chat as memory and started treating it as a session. Now I use two kinds of "write it down," and they do different jobs:

The file that doesn't forget - Cross Chat Memory

There's one place the rules live. Not in the thread. AGENTS.md is basically a README for the AI: the tiny set of constraints and conventions that should survive every restart.

In my workflow, the AI has one recurring job: keep this file up to date. Here’s the template you can steal:

# AGENTS.md 

{...Your Instructions...}

### Learnings 
> This section is automatically updated by the AI at the end of each session. 
> Add new patterns, mistakes to avoid, and insights discovered during work. 
- ...

The note that gets you back into flow

Then there’s the handoff. Avoid a "forever thread". Do not keep asking the same thread to do one task after another.

Force yourself to press the "new chat" button. Do the '/new'. And start it with a handoff prompt. Not a summary of everything. Just enough to pick up tomorrow without spending 30 minutes reconstructing state.

And remember, you must review and edit it before you send it, otherwise it's "hope" again.

There are really awesome plugins you can use and just get a '/handoff'. like:
1. Claude Code - https://github.com/kylesnowschwartz/claude-handoff
2. Open Code - https://github.com/joshuadavidthomas/opencode-handoff

AmpCode has a really amazing article about this: https://ampcode.com/news/handoff

Stop trusting implicit memory. Start using explicit memory.

What if I told you, You don't need to learn svelte! Not because svelte is bad, or not worth learning. It's quite the opposite. You don't need to learn it because you already know it! Dan Dan Daaaannn...

You've been working with JavaScript, crafting web marvels and wrangling code like a seasoned pro. You've tamed the wild async functions, navigated the treacherous waters of callbacks, and even had a dance-off with the quirky this keyword. So, why on Earth would you need to learn something new?

What is this?

In this journey we uncover a superpower, hidden deep inside you, buried under mounds of react wrappers and redux sagas. Today, you'll come to realize that Svelte is not some arcane magic potion you need to memorize incantations or syntax for. It's JavaScript, with a sleek makeover and a secret identity.

By the end of this article, you'll find that you don't need to learn Svelte—it's practically déjà vu with a futuristic twist!

Svelte is suprisingly easy to learn, and it's still pretty awesome! So, Let's get to it!

What is Svelte?

Svelte is a UI framework (we don't shy away from that word here, unlike some other "libraries", ahem ahem...), that's compiled, compact and complete!

It's extremely fast, easy to use and also the most admired JS Web framework according to Stack Overflow Survey.

Why Svelte, You Ask?

Compiled

With Svelte, there's no runtime needed. No need to send a few kilobytes of "SvelteJS" runtime on every website you ever built/will build. It's just a compiler with targets to "document.getElementById" instead of machine code.

Concise

Svelte lets you write beautiful syntax, you know it already! It's HTML CSS and JS (it's like the Avengers of web languages, teaming up to form something magnificent). Svelte compiles it down to extremely fast and optimized JS.

It's like having your cake and eating it too, except it's code, and you're making it run faster than a caffeine-infused squirrel.

Complete

Svelte comes with a state management solution (one of the best I've seen till now), and component-scoped styling (no styled components needed). It even has motion primitives for those jazzy animations that make users go "oooh" and "ah."

So, while you were busy npm installing the bare essentials for your projects, Svelte was chilling in the corner, whispering, "I've got this, fam."

It's all Javascript

Love it or hate it, Javascript is a very useful technology, and all the libraries, frameworks, and "meta" frameworks, are nothing but abstractions over JS (mostly leaky ones).

That's where Svelte shines, even though it's another "web framework", It doesn't throw a bunch of alien syntax at you, expecting you to decipher it like an ancient scroll. No, Svelte takes the familiar, battle-tested primitives, syntax, and concepts of JavaScript and weaves them into its fabric.

So, while other frameworks might introduce themselves with an air of mystique, Svelte strides in with a friendly nod, saying, "Hey, it's all JavaScript here. Let's create something amazing together."

But why though...

Okay, Okay, I see you react lovers (I'm one too!), you might not be convinced yet. Here are a few examples to tip you to the right side...

Effects/Reactivity

With react, here's what's needed to make something run every time a dependency changes

function Component() {
    useEffect(() => {
        console.log("Count Changed!", count)
    }, [count])

    return /** jsx **/
}

Not so bad, is it? Now see what it translates to in svelte

<script>
    $: {
        console.log("Count Changed!", count)
    }
</script>

<!-- html -->

That's it! Svelte automatically tracks dependencies, and you only need to label a code block as reactive ($:). It'll run the code any time those dependencies change.

Stores/State Management

While in react, you might go with complex setups like zustand, react-query or redux. Svelte gives you an in-built solution. A fascinating, cutting-edge idea called "pub-sub". Yupp, it's that dumb.

/** store.ts **/
export const counts = writable({
    a: 0,
    b: 0,
})

<script>
    import counts from './store.ts';
    import {onMount} from 'svelte';
</script>

<button on:click={() => $counts.a += 1}>
    Increment A ({$counts.a})
</button>

Here, the component only "subscribes" to count.a, unline what react context allows you to do.

The $ just before the variable name makes the component handle subscribing and unsubscribing to the store for you!

Simple Lifecycle

While React uses some implicit behaviors of useEffect to do component lifecycles, Svelte is extremely explicit and simple

<script>
    // ...imports
    onMount(() => {
        // ... on component mount stuff
        return () => { // cleanup stuff 1 }
    })
</script>
<!-- Component Markup -->
<button>click me!</button>

If you wanna do something only once, just write it in the script tag! Unlike React Components, the bodies of the script tag of a Svelte Component are only executed when it's created.

What if I want Redux actions?

To restrict changes to the store, all you need to do is this:

const _counts = writeable({
    a: 0,
    b: 0,
});

export const counts = {
    subscribe: _counts.subscribe,
    incrementA: () => _counts.update((counts) => {...counts, a: counts.a + 1}),
    ...
};

A store is an object with a subscribe method. You're free to mold it as you please!

Scoped Styles

<script>
// ...
</script>

<div class="container">
    <div class="card">
        <h3>Name</h3>
        <p>Description</p>
    </div>
</div>

<style>
    .container {
        /** .. **/
    }
    .card {
        /** .. **/
    }
</style>

All of these classes are scoped to the component by default, "container" means nothing outside of this component.

You get all this, with 0 dependency and no runtime cost.

But what about the "ecosystem"?

That's the best part, the svelte ecosystem is bigger than React! because it's all of the JS ecosystem.

You see, in the realm of Svelte, there's no need for those wrappers that you might have wrestled with in the past. Say goodbye to deciphering cryptic syntax or quirky APIs just to connect a wrapper to the actual library you want to use. Nope, with Svelte, it's as straightforward as it gets.

It's like a direct line to JavaScript paradise – no middlemen required! 🚀

Let's Look at an example

Imagine you're a developer aiming to add some stunning charts to your web app using the renowned "Chart.js" library.

React: A Web of Wrappers

Step 1: Install the Wrapper

First, you'd need to find a React wrapper for Chart.js, install it, and cross your fingers that it behaves as expected. Also remember to use the 2 version.

// Terminal
npm install react-chartjs-2 chart.js

Step 2: Import the Wrapper

Next, you import the wrapper, wrap your component around it, and pray there are no compatibility issues.

// Component.jsx
import React from 'react';
import { Bar } from 'react-chartjs-2';

const ChartComponent = () => {
  const data = {/* Chart data here */};

  return <Bar data={data} />;
};

export default ChartComponent;

Step 3: Deal with Wrapper Limitations

You realize that the wrapper doesn't quite support the latest Chart.js features, so you resort to direct manipulation to achieve your goals.

(I deleted the code here because it got too long 🤕)

Svelte: The Direct Approach

Step 1: Add the Library

In the world of Svelte, you don't need a special wrapper. You just add the Chart.js library directly.

<!-- Component.svelte -->
<script>
  import { onMount } from 'svelte';
  import Chart from 'chart.js';

  let chartInstance;
  let canvas
  $: {
    const ctx = canvas.getContext('2d');
    chartInstance = new Chart(ctx, {/* Chart config here */});
  }
</script>

<canvas bind:this={canvas}></canvas>

And... Done!

No wrappers, no compatibility struggles – just plain JavaScript, building upon what you already know. Svelte's direct approach feels like a breath of fresh air, reminding us that sometimes, less is truly more.

Sold! Sold! Where do I start?

Ah, the enthusiasm! You're ready to jump into the Svelte universe and flex those JavaScript muscles. Here we go!

Step 1: Embrace The Basics

Good Documentation is a godsend in software, and Svelte's Intro Tutorial is especially good. It's like the "Welcome to Svelte" mat laid out for you.

This is where Svelte gives you the first taste of its most-priced quality, its simplicity.

Step 2: Craft a Mini-Masterpiece

Once you've completed the tutorial and seen how seamlessly Svelte meshes with your JavaScript prowess, it's playtime. Go make a project you've been thinking of building. Don't have one? Here are a few cool ones you can start with:

1. Virtual Recipe Box - So you never lose your favourite recipes

2. Snippets Manager - So you don't ever loose that bash command you keep safely in your bash history (I know you do...)

3. Project Idea Repository - So you don't need this list again!

It's your playground, play around, and you'll realize, how beautiful it is to just use JS and the web platform.

Conclusion

Svelte is like a breath of fresh air among the syntax-heavy, complexity-mongering tools that exist in the JS ecosystem. You don't need to learn svelte, because it has a learning curve so small, that you won't even realize it when you learn it.

You of course won't become an expert in a day, but Svelte enables you to focus on building stuff rather than learning weird quirks of the framework.

So, whether you're a battle-hardened developer or a curious newcomer, consider giving Svelte a spin. It might just inspire you to view web development through a cybernetically enhanced lens.

Alright, let's cut to the chase, my friend! You've just uncovered a goldmine of knowledge, and the fun doesn't stop here.

So, why wait? Dive into the excitement, join our newsletter community, and let's embark on this journey together. Your inbox is about to become the ultimate source of inspiration. Sign up now and stay ahead of the curve!

Traditionally, we always try to stick to the one-project one-repo principle, which works fine, but also has a few issues and needs some manual operations to keep in check. Monorepos give you an alternative to that approach.

What are Monorepos?

A monorepo is a single repository containing multiple distinct projects, with well-defined relationships.

This quote is from monorepo.tools, and describes how nrwl thinks about them! So it's right from the source!

Why though?

So we generally have this approach of polyrepos that we follow, and they are fantastic! They prioritize team autonomy and each team can ship in isolation, without worrying about the other teams! It's incredible, it's magic! Let's not even think about Monorepos!

But wait, the user gets the app as a single version right? So, how is it possible that teams work in isolation and ship features, without actually collaborating? And that's where the poly-repo approach falls short.

Polyrepos are good at isolation, but bad at collaboration.

Monorepos solve this, you have one repo. If you make a change, it's your job to make sure it works across the product. So your teams are divided by features/apps rather than on the basis of the tech they use.

Version Management

Teams often need to maintain older versions to prevent breaking changes in projects where there are multiple repos, worked on in parallel. All these rituals and processes can take the developers' time, and they move away from actually shipping stuff.

Monorepos have 1 version, that's it! If you deploy a new version, it'll work, there's no older version to maintain, at least for internal APIs.

Developer Productivity

In a monorepo, developers can not only confidently contribute to different projects, and use a consistent way of writing, building, and testing applications but also learn from various other projects and verify that their changes are safe.

Atomic Commits & Rollbacks

As devs, we make mistakes, and sometimes it's so bad that we might need to roll back our changes. Well, monorepos allow for Atomic Commits that let you roll back the whole stack in one step instead of cherrypicking commits and hacking around.

Shared Types

This is one of my favorite things about monorepos. If you use something like typescript on the backend or at least swagger to document your API. You can basically generate the API calls and the integration layer. This will not only make your integration layer less error-prone but also make the lives of your devs a lot easier.

So is it a one size fits all?

Sadly, no. Although monorepos are awesome and I honestly think a very good for companies of all sizes (yes especially startups). There are a few things one might need to think about before going to the monorepo route.

Tooling

Monorepos need good tools. You don't want to build without a cache, you don't want to build unnecessarily and you don't want to develop without constraints. It's often worth it to invest in good toolings like nx.dev or turborepo but it's an effort you need to think about.

Learning Curve

Every new technology you bring to your stack will add to the stuff your devs need to learn to work effectively. Although good tooling can make this very easy to handle!

Git

Git was not designed with monorepos in mind. So it might become an issue for very large codebases to manage a monorepo. But this is not an issue for most organs, and at the scale of google where you do face this, some tools help you manage it.

FAQ

Is it just keeping the code together?

No! A monorepo has code co-location, but the projects must have well-defined relationships to be called a monorepo.

Won't it make my app a monolith?

Not at all! Monorepos is just as much about well-defined relationships as they are about single repositories

We are a startup, does it help me?

Yes, monorepos are amazing for startups. Utilizing opensource tooling will help you create the best possible DX for your team and help them ship faster without having to worry about the tedious procedures and rituals that polyrepos entail.

This also helps you do faster refactors, pivots, and stack-wide changes.

What is Nx?

Nx is my tool of choice when it comes to monorepos. It's definitely not the only one, but I like it. It has excellent tooling, remote caching, vs code integrations, code generation, and a lot more!

At its core, it's a build tool that builds all your apps in parallel, adds a layer of caching, and makes sure to avoid unnecessary work. It's also awesome at developer experience and reduces the repetitive work devs do, to a minimum.

Why Nx?

Nx provides you with tools that help you run tasks concurrently, and manage dependencies between projects. But so do almost all monorepo tools. How is it different?

Never Rebuild the Same Code

Nx is really smart about this. It can figure out whether the same computation has run before, and can restore files and the terminal output from its cache.

Remote Caching

Nx allows you to share your nx cache with your teammates and the CI system, thus maximizing efficiency.

Only Run What's Affected

Nothing is faster than not running a task

Nx analyzes your project graph and can diff it against a baseline to determine which projects changed and what tasks need to be re-run. So on every PR, you can rest assured that there will be no unnecessary computation.

Amazing CLI

The nx cli is powerful and mostly runs on metadata. You can run targets in parallel for many projects, use distributed caching, and a lot more.

Doing nx build is enough to build all your projects in parallel.

Plugins

NX not only has an extensive suite of plugins both supported and community-built, but also has excellent libraries and APIs that enable you to write your own plugins.

You can make custom plugins, in the same monorepo, and use it then and there!

IDE / Editor Support

Nx has excellent IDE Support, you can see it for VSCode, Neovim, or Webstorm. Here's an example of what it might look like in VSCode.

Migrations

Migrations are boring, and hard but necessary. NX loves code-gen! They even have nx migrate command, that migrates your monorepo for you.

Interactive Graph

NX Gives you an interactive graph. You can visualize what projects depend on each other and what tasks depend on each other.

Distributed Computation

On CI Pipelines, NX enables you to run stuff in parallel. That's how it speeds up CI pipelines. It even provides templates for most major CI solutions in it's docs to get you started.

The Mental Model

For any piece of software tooling, there are certain mental models developers need to adopt and learn.

In NX, there are a few concepts on which the whole tooling works. These are easy to understand and very powerful. An NX Monorepos is built of projects and associated tasks/targets. Projects depend on each other and these dependencies dictate how tasks are run.

Projects

Projects are modules of code that are decoupled from each other. They can be of 2 types:

1. Apps - In NX, apps are shells around libraries. They are individual applications that combine multiple libraries to do one single thing and do it well. Nx is very flexible in terms of how you can use it.

2. Libraries - Libraries are reusable code that may or may not depend on other libraries. You can choose to divide up your code into libraries however you want.

Projects depend on each other and that's how the whole monorepo dependency graph gets formed. These dependencies dictate how different tasks are run.

Associated Tasks / Targets

In a monorepo there are not just dependencies among packages, but also among their tasks. For example, whenever we build an app, we need to ensure all it's libraries are also built if changed or a "build" task might depend on "lint" task. They are specified in the nx.json file

{
  ...
  "targetDefaults": {
    "build": {
      "dependsOn": ["^build"],
      ...
    },
    ...
  },
  ...
}

With these concepts, NX enables you to do a lot of stuff. It enables building projects faster, caching builds, saving time and more!

Okay, I'm sold! How do I use it?

Monorepos are awesome! And so is NX. I hope you are sold on both of them at this point. This article feels already very long. So, in the interest of my sanity and yours, I've decided to break it up into a series!

In the next post, I'll be demoing a fullstack setup, with 2 frontends, a backend and a few libraries, all powered by NX.

Make sure you subscribe to my newsletter to get notified when it comes out next!

I love learning new technologies and expanding my horizons. This blog will cover what I did, and didn't do and what I want to do next in my tech journey.

Here's to the ones that we got!

Yupp, that's memories from maroon 5, I AM NOT SORRY!! Anyway.. I set a lot of goals for this year, I met some of them! Here are a few:

Learning Rust

Okay, yeah it's the new fad, but it's really not! You know, for the most part, you write in programming languages. But, in some cases, the languages write you. Rust is one of those cases. Exploring and learning Rust was eye-opening. it showed me what the tools we use, can do for us. I learned what DX really is, and how dev tools empower developers.

More than that, it helped me form an opinion on the Dynamic vs Static Typing Debate*. It's still not black and white for me, but I better understand the effect they have. It also helped me expand my thinking from the typical OOPs thinking that most of us develop in college.

I built a few things with it:

• zero2prod-rs - My walk-through of the book Zero 2 Production in Rust

• bm - A virtual machine, assembler, and disassembler

• tqrs - A tqdm-inspired library for rust

NOTE: Most of these are just me playing around with it, it's not production ready, and will, most likely, never be.

An amazing language to learn both in terms of personal growth and future prospects, would 100% recommend it.

Learning more about software architecture

This one is an ongoing one. Software Architecture is just too beautiful to stop learning. This year, I explored a little more about

• Domain Driven Design

• Design Patterns

Learning to write a programming language

It just seems cool, to write your own compiler. That's the job of God! Well, I tried. I'm in nooo way an expert though, just a random guy filled to the brim with curiosity! Here are my attempts if you wanna see them:

Disclaimer though, it's mostly stuff I learned through tutorials. I'll keep learning more to build something from scratch in the future!

• Clox Interpreter - This is from Crafting Interpreters, an amazing read for any developer out there!

• Monkey - This is from Writing Interpreters in Golang, again, amazing stuff, and I finally understood pratt parsing!

Open Source

I love the idea of open-source software. Brilliant engineers, working together to make stuff for everyone! It just puts a smile on my face. So I started contributing on the side this year. This was a fun experience and I got a lot better at reading code!

Experimenting with Functional Programming

I had heard a lot about functional programming, so I started learning Haskell and elm! I've experimented a bit, it really does change your mindset about code and how it should be written. Will keep moving in this journey and keep you updated.

Understanding my tools better

I love the tools I use, especially because I like to tinker. I started using neovim and tmux this year! Here's an article if you wanna know more about neovim.

I also created a dotfiles repo, so I can back up my configurations and even you can use it!

Cheers to the wish you were here, but you're not

Okay, the last reference to memories, promise! Anyway, things don't always go according to plan. Here are things I wished to do, but couldn't

Learning Graphics Programming

It has always fascinated me. I even tried doing some GPU programming in C, C++, and Rust. Learned a little bit of OpenGL and a little bit of WGPU. But, it's not the tech where I'm stuck. It's how I am at visual stuff. I am bad at visual design, and I'll improve it in the future, till then, the terminal it is!

Learning Game Dev

Playing Games is fun, how cool would it be to make them? But unfortunately, I didn't do it this year, fingers are crossed for the next one 🤞.

Learning Music Production

I know it's not "tech", but I wanted to! Anyway, I couldn't get the time to do it this year, will definitely pick this up in 2023.

The Happy Accidents

As I said, things don't always go according to plan, and sometimes, it's a good thing! Here are things I didn't even think of planning, but am grateful I did.

Automation

Yeah, I already knew bash and python and a dozen more scripting/programming languages. But this year, I actually used them for my work. It was awesome! The things that took hours now took minutes.

Understanding what drives me as an Engineer

I like to build stuff! And so does every engineer out there. But, that's how I identified myself until now, but when I retrospect, I understand what excited me to do what I do. I love to use software and my skills to empower people. Using software to empower people to do what they do better, that's exciting! They can be normal users, business people, managers, and developers!

So, moving forward, I'll keep experimenting and building productivity tools, management tools, dev tools, etc. Not exclusively, but it's a new avenue I'd like to explore.

Platforms Engineering

At Procol, I got the opportunity to do some platforms work, managing infra, building internal dev tools and metric trackers, etc. I loved it, it's amazing how helping people do their jobs better 10x-es your impact on the world. I also started learning docker, Kubernetes, and infra as code recently.

Looking forward to exploring it a little more.

Mono-Repos

I learned about monorepos, and what they can do for a team and a product. Every new thing you learn expands your thought process. I learned about nx. Another awesome tool in my toolbelt now!

Writing

I started writing blogs this year, not very regularly but it was liberating. Writing and articulating my ideas help me get a better grasp on them. It's like all those clouds of ideas in your head, just arrange into a nice structure, and you finally know the small details and the big picture! I hope to continue this the next year!

My Brain is for Idea generation, not information storage, we have SSDs

Future Plans

Writing and Showing My Work

I have a hard time showing my work, but this year, I aim to work on that. So for accountability, I'll post 1 blog a week consistently.

P.S. Help me out and let me know about blog ideas you have for me!

Learning more about Platforms

Platforms were fun, would love to explore more about them on the side, after all, learning never goes in vain.

Learning More Rust and Go

I honestly love Rust and Go. They are so different and make you think in different ways! You definitely should give them a try if you are looking for something new to explore!

More Open Source

I contributed to a few projects this year, but I want to dive deeper. Maybe even do some project of my own!

Embracing Serendipity

No matter what I plan, there's always some amount of luck, randomness, or serendipity involved. And I'm happy that it is! The amount of happy accidents I had really excites me for what 2023 has planned for me!

Here's to growing together, moving forward, and learning! Happy New Year 2023!!🎆

Technology comes and goes, and so do text editors and dev tools. But, there are a few that stand the test of time and still remain actively used for more than 30 years. Vim, is one of them. In this era of ram hogging text editors and IDEs that feel like they were designed to run on supercomputers, Vim, a terminal-based text editor, still has 25% of developers as its users.

Tools are important. As devs, we are nothing but craftsmen forging beautiful and useful projects with simple tools at our disposal. As Lincoln said,

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

Abraham Lincoln

It's definitely worth exploring your tools and finding what works for you.

In this article, I'll not only discuss my journey with Vim and why you should use it too, I'll also give you a clear roadmap on how to go from a VSCode user to Vim Wizard and leave people around you in awe when you work.

Why I started Vim?

Vim is cool. Objectively cool. But more than that, it's intriguing how a humble text editor that runs in the terminal competes with the likes of VSCode which huge corporations back.

Other options aren't that performant. It might not be an issue for everyone, but it was for me. VSCode, being made using electron, hogged all my Ram and made my laptop laggy. Vim proved to be very usable on my machine at that time. I started using it and got hooked! I've used it for a year now and it still feels like the best text editor for me!

Why Vim?

There are many things awesome about vim, here are a few

Vim is Fast

As I explained above, vim is fast. It's also small. Unlike other IDEs and text editors, it doesn't take multiple GBs on disk or RAM.

Vim is Fast

No, it isn't a typo. Vim is not only fast, but it also makes you work faster. Like others on the web, I'm not claiming that saving a few keystrokes will bring a boost in productivity. But after using it for a while, vim becomes an extension of your mind, you just think of stuff and do it.

Vim is everywhere

A random Linux machine, an EC2 instance, an on-premise server, coding prep platforms (like leetcode, hackerrank) vim is everywhere. Heck, even the note-taking app I'm using for writing this has a vim mode (yes, I'm using it!).

You can't rely on VSCode or IntelliJ being everywhere but you'll find knowing vim helps you work almost anywhere easily and productively.

Vim is Yours

Although all the editors now are immensely customisable with extensions and themes (thanks to the amazing developers behind them), vim is one step forward (for decades).

Vim provides a complete scripting language to configure your setup. The older, original vim uses Vimscript and the newer (and better IMO) Neovim uses Lua. Lua is a popular scripting language used in many places so you aren't learning a niche thing useful only in one place.

Muscle Memory is better than Your Memory

People forget stuff, a lot! But while using vim, you build a muscle memory that lasts and makes you even more in the zone while working.

How do I learn it?

I hope I've convinced you enough to give vim a try. Let's look at a simple roadmap to learning vim

VimTutor and Learn Vim Extension - VSCode

The vim community has created vimtutor which has simple exercises to introduce vim and build your muscle memory. For VSCode users, this awesome extension called Learn Vim does the same right in your VSCode.

Try going through this 3 or 4 times to get comfortable and then move forward.

Vim Mode in VSCode

Learn Vim actually makes you install an extension called Vim. This extremely useful extension actually brings vim keybindings to your VSCode. Some people just stop here and use vim bindings with VSCode.

Before moving forward, try getting comfortable with using this for a week or two in your work.

Real Vim - Minimal Config

Once you are comfortable, you can get to the real deal. Download neovim. Use a minimal config with it. No fancy plugins for now! Get a basic color-theme, switch on syntax highlight, set up tab stops and auto-indentation.

Start using vim for basic editing tasks.

LunarVim

You could go crazy with vim and make your own config with handpicked plugins and here's an amazing playlist that does just that:

But I won't recommend that. The vim ecosystem, although very awesome, can be overwhelming. Start with something that was handpicked for you. Start with lunarvim.

Here's a sneak peek:

What next?

You are officially now a vim user. You now have the license to act all snobby when someone asks about your dev setup.

Next, start following a few awesome people from the vim community:

• The Primeagen
• TJ DeVries
• Chris@Machine
• And explore more!

Do Not Delete VSCode!

Although you may not use it anymore, keep VSCode around. Around our magical world, is a muggle world. You always need to work in a team. Making an active effort your dev environment accessible to your teammates will go a long way. You will have people who don't know vim, please don't be a jerk and keep VSCode around for them.

So Keep it around! Keep it around for the muggles!

Do you need this?

As much as I want you to join our cult (I mean, club. Ahem!), I'll admit that you don't necessarily need it. A good developer who knows his way around VSCode or WebStorm will be as productive as someone who knows his way around vim. Just make sure you understand your tools and use them to their full potential.

I've seen many people just googling and fixing their configurations without understanding how it works. I once saw a dev manually run prettier from the terminal because he didn't know how to fix issues in the prettier VSCode extension. That'll slow you down.

We spent almost all our time with our tools and they help us do a lot. It's definitely important to understand them, learn them and explore to find what works for you.

Hope this article helped you, share screenshots of your new vim setup in the comments!

You need a website. You know you do. A website doesn't just serve as your portfolio, but it's your own little corner on the internet. A place where you share ideas and document your journey. It's not only beneficial for others, but it's also useful for you too!

But just like doctors tend to be the worst patients, developers are the worst clients.

As devs, we know what's possible on the web (which is basically everything!). So we get into choice overload and never get to building anything.

Since choice overload is a real problem for us, let's Simplify!. Let's reduce our choices just enough to get stuff done. Introducing Hashnode!

This blog is about How I built my personal website using hashnode

Why Hashnode

I was in the same place for a long time, but then I discovered Hashnode (this is the platform you're reading this blog on). That led to kaviisuri.com. Let's see why I chose hashnode:

1. Hashnode allows enough personalisation without giving a choice overload.
2. Hashnode gives a good starting point to get started, so you don't start from a blank page.
3. You own your content! You can even back it up to a GitHub repo if you want.
4. You own the traffic! You can have your own domain.
5. And a lot more features!

I know what you're thinking.

But Isn't Hashnode a Blogging Platform?

Yes. It is. And that's what makes it excellent. Look. An empty website just looks bad. And having a blog is the best thing you can do for improving your skills in communication, tech and other areas. You don't need to go full content creator, just write about your experiences and you'll thank yourself later.

And yes, hashnode is truly a blogging platform, but it's a lot more!

Getting Started

Enough talk! Let's build something! You can just go to hashnode.com and create an account like you normally would.

Hashnode provides you a URL of the form {username}.hashnode.dev, but you can setup your own domain too!

More than Blogging

You of course want other pages on your website. It's a personal website, not just a blog, is it? That's where Hashnode Custom Pages come in.

Hashnode allows you to create custom pages with markdown and html that let you create whatever you want! Let's see an example

My website has an about me page. It has a section about me (duh!) and my work experience (I may switch this to a separate page in the future, share your thoughts in the comments!).

1. To create a page, open your hashnode blog dashboard and go to pages.

2. Click on create new page, and start editing.

3. Write about your self in markdown.
4. Adding Cards can be as simple as adding the following in markdown:

---
> #### SDE Intern @ Procol
> `09/2021 - Present`
>
> Procol is Next generation digital procurement software and they aim to make businesses in India easier. 
> I worked on developing both products and platform tools to make lives of clients and fellow developers easier and boost productivity.
---

This looks like this: Not bad for 30 seconds of work right?

Making it your own with Custom CSS`!

Hashnode lets you write Custom CSS!

1. Go to the appearance tab.
2. Scroll down to Custom CSS Section and turn it on!
3. Click on edit custom stylesheet and write custom CSS for anything you want!

NOTE: Don't forget to click Update after you make any changes in settings

If you want to do a custom header for the website like me, you can go to uigradients.io and get a gradient from there.

Next, open the stylesheet and add In all the sheets (home, articles and pages).

Custom Widgets

Although I haven't used it yet, Hashnode also lets you create custom elements or widgets. You can use this to add reusable embeds in your articles or pages.

Inspiration

My website doesn't use hashnode to its full potential yet! There's a lot more that's possible. You can look for inspiration from the following people:

• https://samina.dev/
• https://blog.greenroots.info/
• https://chilimatic.hashnode.dev/
• https://blog.avneesh.tech/
• https://narmadanannaka.com/

Plus its just CSS, you can go crazy with it!

Conclusion

Look, I know it's not all the crazy animations or the cool ThreeJS effect you recently learned. But, it exists now. You can always iterate and improve your website, but having one and getting started with writing will take a long way.

We often wait for everything to be perfect and everything to be just right before we show it to the world. That's not the right approach here. Get started, share something, create something and improve it day by day.

Thanks for reading this article, I hope I could motivate you to finally create your own website without caring about perfectionism. If you create a website after reading this article, be sure to add it in the comments! I'd love to see what you come up with!

As software engineers, our job is to solve problems. And the reality of the job is, getting stuck sometimes. Please do not think you are less of a software developer or engineer just because you get stuck often. It's part of the job!

This is my 2nd submission for the Hashnode #4article4week challenge.

In this article, I'll outline a few things you can do to be unstuck. No matter what your stack or your problem, this process will be useful in finding the solution.

Google It!

Yeah. It sounds basic, but I can't even count how many people skip this. Just take the error that is popping up or the situation that you are in and Google It! It's half our job! Here are a few tips on how to google it better

Write it down!

Okay, most of the time, you'll just get the answer on google. But if you don't, it's time to get your writing skills out. Just write down the problem you are facing, the probable causes, and the feasible solution you can think of.

Sometimes, just doing this helps you think of a solution. Writing helps you understand the problem better. You solve stuff better if you understand it.

From now on, take time to document your understanding, possible solutions and everything. I know it's a lot of effort, but it's worth doing.

RTFM!

Okay, again a basic one, but Read the F ing Manual!** The excellent engineers behind the tools you use are also kind enough to write documentation. Treat it as the single source of truth. Understand how things work. You might find a solution or a better understanding to think of one.

You Ain't a Snowflake

As much as we want to feel like snowflakes, we aren't. At least in the context of building software. Your project might be different, and the problem might feel different, but chances are someone faced this issue before. So look for people who were where you are right now.

Search on forums, GitHub issues, stack overflow, and maybe even subReddits.

Take a Break!

If you still haven't solved the problem, take a break. Fresh eyes are amazing at giving new perspectives. You don't need someone else for fresh eyes, you can just take a break.

When you'll come back to the desk. Read what you wrote down. You'll get a different perspective. You'll get more ideas. Write them down and start experimenting.

Be Hands-On

I've seen many people do it. I've done it myself. We tend to work on research about a problem and forget to experiment with them. You don't need the perfect solution. Just start implementing one and remember. Git is your best friend in this. Don't mess up your progress because you forgot to commit stuff before your experimentation.

Ask For Help

Once you've done everything you can, and written everything down. Ask For Help. Rephrase your documentation into a consumable summary and ask for help. Reach out to seniors or colleagues and send them the document. This way you don't waste their time as you have the resources upfront.

Ask Online

While you talk to your seniors, put the internet to work. Take the question you asked your colleague. Also, post it on online communities like

• StackOverflow
• GitHub issues of the technology
• SubReddits like r/webdev r/programming and even specific ones to your technology
• Discord servers
• Twitter (reach out to me at @kavii_suri)

Share! Share! Share!

Once you're at this stage and hopefully have found a solution, remember to share. Why? Because the software community thrives on this. Remember how I said someone faced this issue before? Well, be that someone for someone else.

If you can help at least one person, that's worth it! Of course, there are benefits of posting online: personal branding, and networking but in the end, this isn't just about that, it's also about giving back to the community that supports you every day.

Hi, I'm Kavii, an SDE Intern at Procol. I've been freelancing for the last 3 years. You can get to know more about me here.

This story is about how I got my internship by literally crashing their office. No clickbait!

Rat Race

I don't think I need to tell you about how frustrating, and depressing the internship and placement seasons can be. You might do every question correctly. You might be the right candidate for them. But sometimes, as the famous lyrics go,

In the end, it doesn't even matter.

I was in a similar situation at the beginning of my 3rd year. I even did a few tests 100% correctly and didn't get shortlisted. Was there a valid reason? I don't know. I was just depressed and wanted a way to improve.

The Old Friend

Rohan Arora has been my best friend from 2nd class. He was working as a product design intern at Procol at the time (P.S. Rohan is an awesome designer, do check him out). He asked me to give Procol a try, and in typical Rohan fashion, motivated me enough to do it.

I mailed HR. Got an interview because of the cold mail and referral (the 2 most underrated things to get a job). I was extremely excited. For the first time, I could talk to someone. Tell them why I was the right candidate.

The First Round

I was lucky enough to have the first round with Sumit Mendiratta, Co-founder and CTO @ Procol. Sumit has been a guiding light and mentor for me.

We had an awesome conversation about my motivations, what I wanted to do, what I could do at Procol etc. It went well and I got a mail about the next interview, the technical round.

The Technical Interview

I was scared. Look, I'm an engineer. A developer. A tech enthusiast. What I'm not is a competitive programmer. I know my dev, but I hadn't memorised all the DS Algos on my fingertips.

I explained everything to the interviewer, Himanshu Arora, a brilliant senior engineer at Procol. He made an effort to tailor the process to understand the depth of my knowledge rather than checking rote memorisation.

The interview went well, I got an email that I was selected and the next round was just about discussing my stipend and joining date.

I partied.

Dreadful Silence

And then there was silence. Dreadful. A week passed, 2nd week did. I was waiting anxiously. After the 4th week, I got the response. Although they liked me as a candidate. They didn't have space for an intern on the team and were looking for someone more experienced as they were scaling. A valid point. But I was heartbroken. I went back to being frustrated.

The Random Trip

Rohan was going to Gurgaon to work at Procol's office. We discussed and I tagged along. I knew, there was remotely any chance this would help, but I had to try.

Procol's office is at a WeWork. WeWork offices have community spaces where you can work by buying a pass. I bought one and started working on a freelance project. I didn't know what I was hoping for.

LunchTime

It was lunchtime, Rohan came out, and so did Sumit. They talked and Sumit invited me over to talk. I was nervous. He acknowledged my hunger to work. Then we started discussing what I would work on if I was in Procol. I honestly got too excited about the tech and started scribbling in his notebook with his pen 😂.

And an hour later. I had an internship. I got the offer letter the next day and joined a week later. It has been awesome since then!

Working At Procol

Since then, I've been working at procol. It's been almost 11 months now. Working here has been amazing. Procol has an amazing work culture with people who know their stuff and are cool enough to teach it to you. I've not only improved my skills in tech but also in communication and planning thanks to the amazing people working here. If you ask me, the best part about working here is that you get to build real stuff to solve problems are they don't limit you from exploring stuff.

Procol can be called a business revolution, a B2B software, an amazing startup, all of which it is. But as a part of Procol, it also feels like just a group of builders, marketers, business people etc who know their stuff. People who would rather solve problems than pushing around papers.

What's the point?

Look. I'm not saying go crash someone's office without permission because someone on the internet said so. What I am saying is, that randomness is the trend of this story. Randomness and Serendipity drive a lot more of our lives than we care to acknowledge. If we just keep working on ourselves and try to snatch each opportunity we get. Things work out.

I hope I gave you a different perspective on getting hired and your internships and placements. Best of Luck!

So, Now you have your code running on AWS. It's secure and cheap, but you still have to upload your code in zip files. How archaic😱!! Let's fix this in this article using another awesome AWS Service called the CodePipeline. This is gonna be a short one guys.

This article is a sequel to the previous one called How to setup a https server in elastic beanstalk. It's not required to read the previous one, but I would recommend doing so before reading this.

What is Code Pipeline?

It is an AWS Service that provides fully managed, continous devlivery that helps you automate the release pipelines for fast and reliable application and infrastructure. You can automate various phases like

• Build
• Test
• Deploy and this automation will run every time there is a code change.

It supports various source code sources, we'll be using github but there is very little difference in how to use any other service if you need to.

How to Setup CD

Go to code pipeline option in your console and press "Create New Pipeline".

Enter the name and leave everything as default. Click "Next"

In the source stage, select the provider and fill in the details. We'll be using Github (Version 2) here.

If you require a build stage, configure this step. We'll be skipping this stage.

In the deploy stage, select AWS Elastic Beanstalk and fill other details. Click "Next" and review everything.

Conclusion

Once you submit, your pipeline will be active. Now, as soon as you push code to github, it'll reflect in your deployment very soon.

Readme Badges

If you need github readme badges, refer to [this article] (https://medium.com/swlh/aws-ci-cd-dynamic-build-badge-display-on-github-1e9a3b76db5a) for how to set it up. You can also use this npm library for monitoring the status.

Objectives

With this article, I just aim to setup a server with following properties :

• HTTPS - Secure Web Server.
• Auto renewal of SSL certificates (from let's encrypt).
• Elastic beanstalk with single instance mode (no load balancer)
• Automatic Continous Deployment from github. Coming Up in the next Article

Since This might be a lot to take in, I'll write a seperate article on Continous Deployment.

I followed these steps for a project that had minimum requirements and tight budget constraints. I do not recommend this for bigger projects where scale matters a lot.

TLDR;

If you know elastic beanstalk and just want to know how to setup SSL, refer to this source code from vahiwe and copy the .platform and .ebextensions folders into your application. Source of this code is this awesome article by vahiwe.

Do not forget to set DOMAIN_LINK and EMAIL_LINK environment variables for the domain you want ssl certificate for and the email associated with it respectively.

Why bother reading this?

Although you might not face these specific conditions, this article will contain stuff that I didn't understand before this. Sometimes, we treat things like SSL, Nginx etc as black boxes that just do stuff, but The craft of engineering is about understanding the parts and making a better whole.

Setting up AWS Elastic Beanstalk

What is Elastic Beanstalk?

Elastic Beanstalk or EB is an easy to use service from AWS for deploying and scaling web applications. It supports both uploading your code manually and stuff like CD by using AWS Code Deploy. It manages various things like creating new EC2 instances automatically, deploying your code to the server, starting your applications and much much more.

There are no extra charges for EB, you just pay for what you use e.g. EC2 instances, Load Balancers, CodeDeploy Pipelines etc.

How Do I setup one?

Setting up a basic EB project is simple.

Create new EB Environment

In your AWS console, go to elastic beanstalk option and click "Create new Application" Fill everything up and click "Configure More Options" Make sure, the presets selects "Single Instance" and the Load Balancer Option says "This Configuration does not contain a load balancer" Select all other options that you require like Databases, Software Environment Variables etc and Click "Create App" This will create a default environment for you. Congrats, you now have a single instance EB application online. But it doesn't have your app. 😕

Configure your application code for Elastic Beanstalk to support HTTPS

This step will be the quickest to do but the weirdest to understand.

A little Background

Elastic Beanstalk has a lot of features, some of them being providing a way to configure your application environment, do tasks pre and post deployments, customizing AWS resources and much more. Most of it is done through special folders that live in your code base, specifically .ebextensions and .platform (.platform is supported for Amazon Linux 2 (recommended) instances, for Amazon Linux 1, we use just ebextensions)

What is HTTPS (A simplified version) ?

It is the secure version of HTTP which encrypts data that is transfered to increase secureity. HTTPS not only encrypts the data but also helps the browser make sure that the data is going to the place it says it's going to. It identifies that when you send or recieve something from google.com, it goes and comes from google.com.

How all this is done is outside the scope of this article, but all you need to know is that this identification process requires a Certificate Authority to provide a "certificate" that is sent over and identifies your domain. We'll be using a well known and free certificate authority called let's encrypt. These certificate have exipiry dates and need renewal. Let's Encrypt provides a cli that can help us generate these programmatically.

Setting up Nginx

Elastic beanstalk uses nginx as a default reverse proxy for your application, you can configure it and extend it by adding a .conf file to a folder name .platform/nginx/conf.d in your application source. These files are included automatically. A reverse proxy basically maps all incoming requests to suitable servers. You can learn a lot more about nginx on the web. It's a very large and intresting subject to read about.

~/workspace/my-app/
|-- .platform
|   -- nginx
|       -- conf.d
|           -- myconf.conf
|-- other source files

We'll be using this source code from vahiwe and copy the .platform folders. The working of this is explained in this awesome article by vahiwe.

Installing Certbot

We use the .ebextensions folder from the same repo as above. It contains a ssl.config which is a EB config file and allows us to run some commands in the environment programmatically. This file has the following container_commands

container_commands:
  10_downloadepel:
    command: "sudo wget -r --no-parent -A 'epel-release-*.rpm' https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/"
  20_installepel:
    command: "sudo rpm -Uvh dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-*.rpm --force"
  30_enableepl:
    command: "sudo yum-config-manager --enable epel*"
  40_installcertbot:
    command: "sudo yum install -y certbot"
  50_getcert:
    command: "sudo certbot certonly --debug --non-interactive --email ${EMAIL_LINK} --agree-tos --standalone --domains ${DOMAIN_LINK} --keep-until-expiring --pre-hook \"sudo service nginx stop\" --post-hook \"sudo service nginx start\""
  60_link:
    command: "ln -sf /etc/letsencrypt/live/${DOMAIN_LINK} /etc/letsencrypt/live/ebcert"

This installs certbot and all it's dependencies in the AWS environment. It generates a SSL certificate using certbot for the first time using the environment variables DOMAIN_LINK and EMAIL_LINK, these are required variables and should be set from the EB console.

Setting up autorenewal

The file also contains this piece of code that sets up a scheduled job or cron job that renews certbot weekly.

.... (stuff)
files:
  /etc/cron.d/certbot_renew:
    content: "@weekly root certbot renew\n"
    group: root
    mode: "000644"
    owner: root
.... (more stuff)

Conclusion

And, there you have it, your application running on Elastic Beanstalk, with SSL security. You can just drag and drop a zip in Elastic Beantsalk Console for you environment and it'll deploy it.

But what about CD? Well, this article has become too long and has a lot of information. I'll be posting another short one soon with details about how to do CD.