Through many conversations with junior engineers over the years, I've seen the confusion this mismatch creates. Here's what growth actually means when complexity, not scale, is your primary challenge.

About me

I have been writing software professionally for 13 years now, and worked across the stack with different languages and in different domains (Private Equity, Legal Tech, Finance) and while the language, market and domain kept changing, one thing remained constant: it was always B2B.

I’ve built software and software teams and this article is a combination of my experience as an IC and conversations I had as a manager.

The Scale Assumption

"Scale" carries outsized weight in software engineering. It's the word that gets thrown around in architecture reviews, used to justify technical decisions, and cited as the benchmark for engineering excellence.

When junior engineers ask me about growth, they often reference the same sources: blog posts from Google engineers optimizing for billions of requests, Meta's approach to managing 129K-GPU clusters, or Shopify handling 284 million requests per minute on Black Friday. The advice is solid; if you're working at that scale.

The problem is, most of us aren't. In B2B software, you're rarely optimizing for billions of users. Your database isn't collapsing under petabytes of data. When performance issues do arise, the solution is usually straightforward: fix an N+1 query, add a queue and worker, or provision more resources.

The conventional wisdom around engineering growth assumes scale is your primary constraint. But in B2B, complexity is what slows you down.

Managing Scale vs (Business) Complexity

If you've worked in B2B long enough, you've seen this pattern: You build a logical solution to a well-defined problem. Then you take it to customers. They love it, but they need a pre-approval workflow. And a different calculation method for European clients. And an integration with their legacy system. And custom notifications. And exceptions for certain user roles.

Each request makes sense in isolation. But requirements accumulate. What started as a clean, understandable system becomes a maze of conditionals, feature flags, and special cases. Your elegant solution disappears under layers of "if this client, then that behavior."

This is the primary challenge in B2B: building something that is malleable and extensible, all while it remains simple to reason with. You need software that can absorb customer-specific needs without collapsing, code that can handle variation without becoming incomprehensible to the next person who touches it. How do you get better at this?

First, the fundamentals still matter. Clean code, solid abstractions, good tests - these don’t change, whether you're managing scale of complexity. If anything, complexity makes poor engineering fundamentals more painful. You can’t hide bad design behind throwing more hardware at the problem. But beyond the fundamentals, here are some actionables specific to the B2B environment.

Using retros

Most retros ask what went well and what went badly. That's fine for high level feedback, but it doesn't give you much to act on. A more useful question: what slowed us down this sprint? What took longer than you expected? What felt like a grind?

Not just surprise requirements, or missed planning elements – focus on the engineering papercuts, things you can live with, but they slow you down anyways.

This shifts the conversation from general feedback to specific friction points. You start noticing patterns, the same integration keeps breaking, everyone struggles with the same part of the codebase, estimates are always off for a particular type of work.

From these, you can derive engineering projects and your opportunity to rethink, improve the codebase, maybe try a newer pattern or a library.

As an IC, you might not be able to act on everything immediately, but coming to these meetings prepared to answer these questions forces you to think differently about problems. You develop ideas about what could be better and start learning from the patterns you see.

I learned this late, the subtle shift from what went wrong to what was more complicated than it should lead to a different set of answers, but it was useful.

Learn from on-call, don't just firefight

Being on-call gives you a unique view of your product that you don't get anywhere else. You see bugs across different subsystems, notice patterns in what breaks, and understand how customers actually use the software in ways that surprise you.

On-call often reveals where complexity manifests as fragility, edge cases you didn't account for, integrations that break under specific conditions, workflows you didn't know existed.

After you've put out the immediate fire, take time to learn from it. This might seem obvious, but in real life, this gets lost under time pressures.

This is your opportunity to identify which subsystems are fragile, where observability is lacking, and what patterns keep causing issues.

It's a chance to build the internal tooling that would have made debugging faster, or to advocate for hardening parts of the system that break too often.

On-call isn't just about fixing things; it's an opportunity to make the next incident easier to handle.

Question why things are the way they are

My belief is that people grow when they try to make improvements every day instead of waiting for a large refactoring project to come around. This is something engineers can incorporate in their day-to-day work by questioning the friction they encounter.

Your build pipeline takes 8 minutes and everyone's learned to context-switch during builds. There's a pattern in the codebase that feels overly complex for what it does, but it's been there forever. Your tests are flaky, so the team just reruns them. You're copying the same boilerplate across files because that's how things are structured. These things become background noise.

Good engineers don't accept this. They ask: why am I writing code that doesn't make sense? Why does this need to be structured this way? Why are the builds this slow? These questions feel obvious, but they rarely get asked under delivery pressure.

The answers point to real improvements and learnings, profiling builds to find bottlenecks, refactoring confusing code, fixing flaky tests. You don't need permission to ask these questions or to chip away at the problems you find.

Share what you've noticed with your manager and team. If you've done some research or a small proof of concept, bring that too. Often, you'll find others have noticed the same friction. These conversations surface problems that affect everyone and create opportunities for team-wide improvements.

Road to Staff Engineer

As one goes up the ladder as an IC, the nature of work in terms of projects you do go from work assigned to you to work that you find for yourself. The impact of your work shifts from task local to project local to work that impacts your team too.

The underlying theme of the previous three suggestions is to develop higher-order thinking. Retros teach you to identify systemic problems, not just surface-level issues. On-call teaches you to see patterns across the product, not just individual bugs. Questioning friction teaches you to spot improvement opportunities others have normalized. This is how you move from executing tasks to identifying what needs to be done.

At senior and staff levels, a significant part of your value comes from knowing where to focus effort. You recognize which complexity is essential to the business and which is accidental. You know when to refactor and when to ship. You can look at a system and see not just what's broken, but what could be better.

These aren't skills you develop through large projects alone, they come from paying attention every day to what slows you down and why.

Measuring Growth

You'll know you're getting better at managing complexity when the gap between your expectations and reality starts to shrink. You estimate two days, it takes two days. You think a feature will be straightforward, and it mostly is. You anticipate where edge cases will appear, and you're right.

You're developing accurate intuition about where complexity hides in B2B systems. That intuition comes from paying attention to what slows you down, to what breaks in production, to what feels harder than it should be. The practices above are how you build it.

🎤Audio

I got Notebook LM to generate a conversation with this article at its core, you can listen to the ideas here - https://drive.google.com/file/d/1HanvXh2z_VfvDbJB6DNdPPfAkvzBilF8/view?usp=sharing

Note: This article was initially published on LinkedIn - https://www.linkedin.com/pulse/beyond-scale-what-growth-means-b2b-anirudh-varma-xs2rc/?trackingId=HDE1JFUmeEhAOQ13IqJrlg%3D%3D

Naturally, I wanted to explore what JetBrains had to offer in AI-assisted programming, especially compared to more popular options like Cursor and Windsurf.

The Experience

Having used Cursor previously, I was eager to see how a JetBrains-native AI solution would stack up.

Spoiler alert: There’s a lot of catching up to do. JetBrains AI Assistant feels about a year behind Cursor in terms of capabilities. To be fair, this may explain why it’s the least expensive of the three options.

The workflow is straightforward—you provide a prompt, and it suggests changes. However, I frequently had to nudge it to account for the right files, particularly my Prisma Schema or dependencies in package.json. Cursor, in comparison, handled these tasks much more efficiently, requiring fewer manual corrections.

Future Developments

JetBrains is developing an agentic AI plugin called Junie, which could significantly improve their AI offerings. However, it’s still in early access and won’t be available for WebStorm initially, making it a non-factor for now.

Unexpected Consequences

One of the biggest reasons I’m dropping the AI Assistant (for now) isn’t just its lackluster performance—it’s how it degrades WebStorm’s core functionality.

I’ve had the TypeScript service silently fail multiple times, with no resolution from restarting it. This forced me to rely on CLI/build commands to catch errors or switch back to Cursor/VS Code just to see basic file errors.

The AI Assistant also introduced noticeable slowdowns. On several occasions, the editor became sluggish, leaving a full restart as the only fix. Disabling the AI Assistant improved performance slightly, but not enough to justify keeping it enabled.

Conclusion

I still love WebStorm and would prefer to use it as my daily driver. However, paying for both the IDE license and AI Assistant only makes sense if the AI features enhance, not degrade the core experience.

I have been a Harry Potter fan since childhood, and to some degree, I credit the series for getting me into reading. 17 years after the release of Harry Potter and the Deathly Hallows, the final installment in the series, I decided to reread all of it after a friend gifted me the collection.

I don't usually reread books, but this one was definitely worth it. All nostalgia aside, I think I was able to better appreciate the writing, world-building, and complexity of characters this time compared to when I first read the books.

Another great aspect of rereading a series like this is that you can spot connections that were missed previously. For example, Albus Dumbledore uses the Deluminator in the first scene of the first book, which only reappears in the seventh book when he leaves it for Ron Weasley. The first book came out in 1997, and the seventh one in 2007—this minor detail is just one of many threads that connect the two books.

Reading the series also helped me build some momentum around reading early in the year.

Three Body Problem - Part 1

Continuing with the rereading trend, I picked up the first book (of 3) in the Three-Body series as a refresher before it began streaming on Netflix this year. This turned out to be a great decision again, as I observed details and connections that I had missed previously when reading part 2 (The Dark Forest) and part 3 (Death's End).

The Three-Body Problem books are among the most exhaustive, detailed, and imaginative books I have read, and I don't doubt that if I were to read all of them again, they would be as engaging as they were the first time.

The Last Mughal

https://www.goodreads.com/book/show/124429.The_Last_Mughal

This book by William Dalrymple is a history of the last days of the Mughal Empire in India, but more than that, it's the history of Delhi and its people in the 19th century.

There's a different feeling you experience when you read the history of places you've been to many times, of culture you have experienced firsthand. The Last Mughal does a great job of transporting you to the narrow lanes of 19th-century Delhi. It paints a vivid picture of the different people that lived there, the music they listened to, the food they ate (and that we still get in Delhi), their fights, annoyances, and luxuries.

For me, one of the most fascinating part of the book was reading about different areas (which were not considered part of Delhi then) and mapping them to the mega city and urban center that it has become now.

If you are in Delhi, or have ever lived there, I would definitely recommend reading this.

Tuesday’s with Morrie

https://www.goodreads.com/book/show/6900.Tuesdays_with_Morrie?ref=nav_sb_noss_l_14

As I have called out here, Tuesday’s with Morrie was not a book I would typically pick up but it was a gift and a quick read, this was probably one of the best books I have read.

It’s a memoir written by Mitch Albom, documenting his many conversations with his terminally ill professor, Morrie Schwartz. The book has conversations on all topics that we think about at some point in our lives — money, love, relationships, meaning, death and emotions etc.

Another book I can see myself revisiting in the coming years.

The Psychopath Test

https://www.goodreads.com/book/show/12391521-the-psychopath-test?ref=nav_sb_noss_l_8

Another experimental read, The Psychopath Test follows the authors journey into understanding different kinds of madness.

The book has many interesting stories — like one of a man who scammed his way into the Mental Hospital hoping for nicer amenities and found himself unable to convince the doctors of his sanity for another 20 years.

He talks of the Hare Checklist to identify psychopaths, and its shortcomings and through that, advocates for a more balanced approach in diagnosing/labeling mental illness.

Despite the vague (to me) topic of the book, it was an interesting read and very well written.

The Hard Things about Hard Things

https://www.goodreads.com/book/show/18176747-the-hard-thing-about-hard-things

Written by Ben Horowitz, this is one of the most raw accounts of what it takes to build and run companies. I have been an early employee at 2 early stage startups, and I was able to relate to many problems/circumstances described in the book, founders will probably relate even more.

There are plenty of great reviews and discussions about this book out there, but I would definitely recommend this book to anyone who is planning to startup and build their own company.

Are your lights on?

https://www.goodreads.com/book/show/1044831.Are_Your_Lights_On_?ref=nav_sb_ss_1_19

A book recommendation from Reddit, this is a fun read that tries to help you get better at understanding and identifying real problems.

The author describes a problem as — a difference between things as desired and things as percieved;
Which can be solved by either by reducing desires or increasing perception.

The book talks about challenges faced in identifying problems, things to be aware of when designing solutions, and other questions you can ask to make sure that we solve the right problems for the right people.

The Golden Road

https://www.goodreads.com/book/show/201608148-the-golden-road

The Golden Road is the latest book by William Dalrymple, it talks about ancient India (the sub-continent) and its role as an economic and cultural powerhouse.

It talks about the eastward spread of Buddhism and Hinduism from India to China and South East Asia, the trade of spices and metals between India and the west (Roman Empire and Egypt) and the rise and fall of different kingdoms and cultures in India and its neighbours.

My only complaint with this one was it felt too wordy at times, but a good read none the less.

Essentialism: The Disciplined Pursuit of Less

https://www.goodreads.com/book/show/18077875-essentialism

Essentialism is a book that promotes the lifestyle of an Essentialist—designing your life by actively making choices (sometimes hard ones) rather than living in default mode. It advocates actively cutting out things that don't truly align with your goals and the way you want to live your life.

The one idea that drives everything in this book is that if you don't actively make choices for yourself, the world or someone else will make them for you. This is true in both your work and personal life.

The book provides a framework and many tools to design an essentialist life.

This is one of the better books I have read in the self-help/productivity genre.

Tuesdays with Morrie, a memoir of a sociology professor, was not the kind of book that would typically be on my radar. Gifted by friend, it sat on my book shelf for a few months before I picked it up because I wanted a quick read, and I think I owe them a thanks for sharing this book with me.

Below are some of the highlights from the book —

Over the years, I had taken labour as my companion and pushed everything else to the side.

— Mitch

On Meaning

The way you get meaning into your life is to devote yourself to loving others, devote yourself to your community around you, and devote your- self to creating something that gives you purpose and meaning. — Morrie

On Death

How can you ever be prepared to die?
"Do what the Buddhists do. Every day, have a little bird on your shoulder that asks, 'Is today the day? Am I ready? Am I doing all I need to do? Am I being the person I want to be?' " — Morrie

On Emotions

In order to detach from an emotion, one needs to experience it fully. Whether it's sadness, fear or loneliness, in many cases, our first instinct is to try and suppress it.

But in order to get out of it, you need to let go, experience it fully, then you can say that you know what that emotion exactly is and move away from it. — Morrie

On Ageing

As you grow, you learn more. If you stayed at twenty-two, you'd always be as ignorant as you were at twenty-two. Aging is not just decay, you know. It's growth. It's more than the negative that you're going to die, it's also the positive that you understand you're going to die, and that you live a better life because of it. — Morrie

On The old envying the young

How can I be envious of where you are, when I've been there myself.

On Money

Remember what I said about finding a meaningful yourself to loving others, devote yourself to your community around you, and devote yourself to creating some- thing that gives you purpose and meaning.

"Do the kinds of things that come from the heart. When you do, you won't be dissatisfied, you won't be envious, you won't be longing for somebody else's things.”

On Marriage

Is there some kind of rule to know if a marriage is going to work? - Mitch

"there are a few rules I know to be true about love and marriage: If you don't respect the don't know how to compromise, you're gonna have a lot of trouble. If you can't talk openly about what goes on between you, you're gonna have a lot of trouble. And if you don't have a common set of values in life, you're gonna have a lot of trouble. Your values must be alike. "And the biggest one of those values, Mitch?" …. "Your belief in the importance of your marriage."

On Culture

Here's what I mean by building your own little sub- culture," Morrie said. "I don't mean you disregard every rule of your community. I don't go around naked, for example. I don't run through red lights.

The little things, I can obey. But the big things-how we think, what we value those you must choose yourself. You can't let anyone or any society-determine those for you.

"In the beginning of life, when we are infants, we need others to survive, right? And at the end of life, when you get like me, you need others to survive, right?"

His voice dropped to a whisper. "But here's the secret: in between, we need others as well."

On Death — and accepting it

As long as we can love each other, and remember the feeling of love we had, we can die without ever really going away. All the love you created is still there. All the memories are still there. You live on in the hearts of everyone you have touched and nurtured while you were here....Death ends a life, not a relationship."

This is something that I have personally struggled with and have had multiple conversations about with many people in my team.

One approach that has worked for me, is to structure my work around focused 30 minute blocks - similar to the Pomodoro technique.

The 30-Minute Work Block: Why It Works

The 30-minute block is not arbitrary. It balances deep focus for you and accessibility for your team. During these blocks, mute all notifications. If you're in an open office, a simple "Do Not Disturb" note on your desk or laptop signals to others that you're in deep work mode.

Worried about emergencies? Trust that if something truly requires your urgent attention, your team will find a way to get through.

Implementing the 30-Minute Strategy

1. Schedule Your Blocks: Aim for periods of the day when you’re least likely to be interrupted. In my experience, early mornings or late afternoons often work best.

2. Communicate Your Availability: Let your team know about this strategy. A shared calendar or a simple notification can help manage expectations.

3. Prepare for Transition: If you're nearing the end of a block and aren't done, leave detailed comments or a //TODO in your code. This ensures you can pick up exactly where you left off without missing a beat.

Conclusion

For senior engineers, the challenge isn’t just about managing time; it's about managing attention. The 30-minute work block is designed to respect your need for deep work while acknowledging your role as a leader and a resource for your team.

The Article is published on the SpotDraft blog - Read it here

Update: I ended up talking about this at TIL Conf, 2024, you can find it here - https://www.youtube.com/embed/IneYPMWCLvU?si=Wb6G6yCrVkDekmRK&start=1652

I have been thinking of picking up a new language for sometime now and the choice came down to Go & Rust. As the title indicates, I went with Rust.

Why Rust?

1. The ecosystem: As a frontend/JavaScript developer, I am seeing more and more tools being re-written in Rust for performance benefits, and so hopefully, I would be able to contribute or at least learn from those code bases in the context of my day to day work.
2. Its Different?!: All of my previous experiences have been in application-oriented, managed languages. Rust is similar, but has some interesting concepts like Immutability-by-default, Ownership etc.

What is this post?

This post is supposed to be just a journal of things that I might like, dislike or find interesting enough to document as I learn Rust enough to build a simple CLI app. I am following the Rust Programming Language Book and many snippets here are picked from there.

The Setup: Rust and Sublime Text 3 (MacOS)

Packages Required

• Rust Enhanced: The official Rust package for ST3.
• rust-analyzer: Language Server implementation for Rust.

Setup the Language Server

• Install the LSP Package
• Download the right package from releases.
• Extract the package.
• Rename to rust-analyzer
• Add to $PATH
• Make it executable chmod +x rust-analyzer

Enable the Language Server in Sublime

• Open Command Pallete (Cmd + Shift + P)
• Select LSP: Enable Language Server Globally
• Select rust-analyzer

The Interesting Parts

Match

Rust has an expressive match syntax that can be used to compare values. A match expression is written like -

use std::cmp::Ordering;

fn main(){ let guess = 4; // some sample value, can be input let secret = 5; // another value to compare against.

match guess.cmp(&secret) { Ordering::Less => println!("Under"), Ordering::Equal => println!("Match!!"), Ordering::Greater => println!("Over") } }

Each line in the match block is called an arm. In my opinion this makes the code very easy to read and understand at a glance.

Built-In Error Handling

Some operations, like I/O always require error handling. Rust’s Result type represents either a success (OK) or an error (Err).

The great thing here is that if a function returns a Result, then the caller must handle both success and failure cases.

Consider this code that converts a string to an int -

let guess: u32 = match guess.trim().parse() { Ok(num) => num, Err(_) => { eprintln!("{} is not a legit number, try again;", guess.trim()); return () }, };

Immutable Variables

One major difference in Rust vs the other langugages I mentioned above is that variables in Rust are immutable by default.

In cases where we need to re-assign a value to a variable, we need to explicitly mark that variable as mutable by using the mut keyword.

let a = 5; //This is immutable, a cannot be re-assigned. let mut b = 10; // b can be reassigned.

Shadowing

Rust allows developers to re-declare a variable with the same name in a scope. This is called Shadowing.

Consider the following snippet -

fn main() { let x = 5;

let x = x + 1;

{ let x = x * 2; println!("The value of x in the inner scope is: {}", x); // This will print 12 }

println!("The value of x is: {}", x); // This is still 6. }

Honestly, the first time I saw this, I was pretty confused. Alot of other languages just refuse this kind of re-declaring of variables in scope.

Technically, this variable is still immutable, i.e. this snippet would fail -

fn main() { let x = 5;

x = x + 1; // will fail }

The usecase for shadowing defined in the Rust Book is for running multiple transforms on the same variable without having to declare a bunch of variables names that we don’t care about.

It will interesting to see if this causes any issues on larger Rust codebases.

Arrays

• Arrays in Rust are more like Java than JavaScript. While an array in JavaScript can grow in size after initialization, arrays in Rust are fixed size.
• An array maybe initialized using the type of its elements and the the length like - let x:[char, 5] = ['a','b','c','d','e']
• Rust also provides a shorthand syntax when we want to create an array with the same elements like let x = [3;'a']. This creates an array like ['a','a','a']

Expressions vs Statements

Statements do not return a value. An assignemnt is a statement. Consider the following JavaScript snippet;

const a = (b = 12) console.log(a) // prints 12 console.log(b) // prints 12

Here the variable a gets a value 12, because b=12 returns 12. However, assignments in Rust don’t return a value.

Expressions return a value, Rust is an Expression oriented language.

The block {} created for new scopes is an expression and thus can be assigned to variable like -

let y = { let x = 3; x + 1 };

Here the last line in the block does not end with a semi-colon (;), thats because expressions do not include ending semicolons, if we add a semicolon, then it becomes a statement and hence it does not return a value.

Return Values

In Rust, the by default, the return value of the function is the value returned by the last expression in the function. Using return can be used to exit early, but otherwise its optional.

Conditional Assignemnt

Since if is an expression, conditional assignemnts don’t require additional syntax.

let condition = true; let number = if condition { 5 } else { 6 };

Infinite Loops? There is a keyword for that

Rust has built-in support for infinite loops using the loop keyword. This is the first language where I am seeing this.

Returning with break;

Another first for me, was the ability to return values with the break keyword.

let mut counter = 0;

let result = loop { counter += 1;

if counter == 10 { break counter * 2; } };

println!("The result is {}", result);

• Note that since loop is treated as an expression that yields a value, we can put it on the right side of assignment.
• The break counter * 2 statement not only stops the loop, but assigns the value to the variable result

Source https://doc.rust-lang.org/book/ch03-05-control-flow.html#returning-values-from-loops

Ownership

Just refer - https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

Rules of ownership

• Each value in Rust has a variable that’s called its owner.
• There can only be one owner at a time.
• When the owner goes out of scope, the value will be dropped.

Reassigning ‘objects’

Consider the following JS Code:

const x = { foo: 1 } const y = x y.foo = 2 // this works and sets x.foo = 2

Here JavaScript assigns the reference to the variable x to y. So when some code alters y.foo, it’s actually changing x.foo.

Consider the following rust snippet

let s1 = String::from("hello"); let s2 = s1; println!(s1); // this errors.

In this case, Rust too copies the pointer to where “Hello” is stored, but does not copy the data itself. However, due to how ownership works, and to keep things simple, let s2=s1 actually invalidates s1 and transfers the ownership of Hello to s2. After the re-assignment s1 can no longer be used. This is called move.

As explained here, this is done so that hello only has one owner (s2) and when s2 goes out of scope, Rust can easily free up the memory.

Note: Fixed length data like integers and floats, that is stored on the stack can be re-assiged without invalidating the old variable. Read More Here

Ownership and Functions

Passing data to functions as arguments also transfers the ownership of that data. Assume a regular say_hello function like -

fn say_hello(name: String)->String { String::from("Hello!, ") + &name }

fn main() { let s1 = String::from("foo"); println!("{}", say_hello(s1)); println!("{}". s1); // This would complain about s1 having moved }

Passing variables to a function and then storing its return value back in a different variable will obviously be tedios and not always desirable. To get around this Rust has the concept of References

fn say_hello(name: &String)->String { String::from("Hello!, ") + &name }

fn main() { let s1 = String::from("foo"); println!("{}", say_hello(&s1)); println!("{}". s1); }

The & syntax creates a reference to the value of s1, but it does not own it. Creating references is called borrowing.

Notes

• References, just like variables are mutable by default. In order to change a reference, it needs to be marked with &mut.
• There can only be one mutable reference at a time.

Slices

Refer: https://doc.rust-lang.org/book/ch04-03-slices.html

Last Updated: 15 December 2021.

Sites like YouTube and Google Maps use iframes to embed thier content in your website.

While embedding an iframe is pretty straightforward, customising the document inside the iframe is not that simple.

This post will breifly explain the Cross-Origin access problem that is faced when accesing an iframe document and how you can setup your development environment to overcome this problem.

iframe Security 101

While iframe is a very powerful tool, it essentially means that you are running some arbitary code, loaded from a remote server (which you may or may not control) on your app and exposing your users to it. Naturally, this also means that one has to be very careful about security.

All Browsers implement a Cross-Origin Access Restriction to prevent the host document from accessing the iframe document, unless they have the same origin. This is done to prevent embedded documents access to your sites cookies, localStorage data etc.

What is origin?

Origin of a document is a combination of its protocol (http, https), domain & port.

Accessing an iframe document.

Now, lets say that your host app is at https://your-awesome.app and the iframe loads a document from https://your-awesome.app/embed?id=123.

When the user clicks a button, we want to inject some styles into the document of the iframe.

<iframe src="https://your-awesome.app/embed/123" id="my-frame"></iframe>

// some functionality to inject CSS
<script>
  function injectStyles(styleTag){
     const iframe = document.getElementById("my-frame");
     const embed = iframe.contentDocument;
     embed.head.appendChild(styleTag);
  }
</script>

Since both your app and the iframe have the same origin (https://your-awesome.app), the browser will let you access the contentDocument.

Local development challenges

When developing locally, your app URL mostly looks like localhost:3000, localhost:5000 etc. Now, assuming that embed service will still be loaded from the remote server, the above code will show you an error while looks something like

SecurityError: Blocked a frame with origin "http://www..com" from accessing a cross-origin frame.

This error is very straightforward to understand, when developing locally, your origin is http://localhost:3000 while the iframes origin is still https://your-awesome.app.

The solution to this problem is to somehow serve your local app and the iframe under the same origin, this will involve a couple of things -

1. Serve our local app under local-dev.your-awesome.app

2. Serve the iframe from local-dev.your-awesome.app/embed

Setup local domain

What we want is that when we goto local-dev.your-awesome.app from our browser, it should load our app which is serving at localhost:3000 , for this, we will update the hosts file.

nano /etc/hosts
# add the following line to the end of the hosts file
127.0.0.1 local-dev.your-awesome.app
# Leave an empty line at the end of the file, it is required.

Note: On Windows, the hosts file can found at c:\Windows\System32\Drivers\etc\hosts

Through this one line, we have told our machine that any request to local-dev.your-awesome.app should be sent to our localhost.

Now, when you go to the URL in your browser, it still won’t load our app. This is because our app is being served at port 3000, while the redirect is going to the default port(80). We need to setup a proxy to send requests from / to localhost:3000. To do this, you can use a nifty tool I found called proxrox. Proxrox essentially spins up an Nginx instance with some custom configuration. This is what our proxrox configuration look like -

## .proxrox.yaml
proxy:
  "/":  "http://localhost:3000"

You can start proxrox with the config - proxrox start .proxrox.yaml

When you go to local-dev.your-awesome.app, you should see your app being served.

This magic happens because proxrox configures a proxy_pass in nginx for us which takes all requests going to / and passes it to our app at localhost:3000

Setting up proxrox on Linux

Setting up proxrox on linux takes some more effort due to permissions. Turns out only root processes are allowed to bind to port < 1024. To get around this limitation, you can use authbind.

Authbind is a utility that allows processes to bind to 80/443 or other ports under 1024 without having to gain root access.

sudo apt-get install authbind
# Bind 80 & 443.
sudo touch /etc/authbind/byport/80
sudo touch /etc/authbind/byport/443
sudo chmod 777 /etc/authbind/byport/80
sudo chmod 777 /etc/authbind/byport/443

authbind --deep proxrox start .proxrox.yaml

Setup proxy for iframe document

Now that our app is running at local-dev.your-awesome.app, we just need to get the embeds to serve at /embed. To do this, edit your .proxrox.yaml file again and add the following configuration -

proxy:
  "/":  "http://localhost:3000"
  "/embed": "https://your-awesome.app/embed/"

Save the config and restart proxrox.

Update your frame src attribute -

<iframe src="/embed/123"></iframe>

Since the document and the embedded document both are being served from local-dev.your-awesome.app, you will no longer face the cross origin access error when trying to access the iframe.

This also gives you access to the iframe document, which means that you can insert scripts, styles and even listen to & send messages to the document.

To align or to justify..that is the question

For a very long time, I have been trying to figure out what is the difference between align-items, align-content & justify-content and how they work or more importantly when they work.

TL;DR

• If you have set your flex-direction to row, then justify-content works on the horizontal axis and align-* properties work on the vertical axis.
• If you have set your flex-direction to column, then align-* properties work on the horizontal axis and justify-content works on the vertical axis.

What separates align-items and align-content?

• align-items effect the alignment of items on the current line.
• align-content effects the alignment accross lines of a flex-container. This means that this property has no effect on single-line containers.

The rest of the article is just a brain dump of everything I learned while trying to figure out the above.

Nomenclature

• Flex Container: An element on which the display value is set to flex.
• Flex Items: Direct children of the flex containers are called flex items.

• Main Axis: The axis defined by the flex-direction property.

  — flex-direction:row means that elements inside the flex container are aligned next to each other. Technically, these elements are aligned along the inline-axis (just like inline elements).

  — flex-direction:column means that elements are aligned along the vertical axis i.e. below each other. Technically called the block-axis (just like block elements)

• Cross Axis: The axis perpendicular to the main axis is called the cross axis.

• Single-line Container: Flex containers whose flex-wrap property is set to nowrap. By default every flex container is a single-line container.
• Multi-line Containers: Flex containers whose flex-wrap property is set to wrap

TL;DR with Nomenclature

Now that we know the jargon, we can rewrite the TL;DR as-

• justify-content works on the Main Axis and align-* properties work on the Cross Axis.
• justify-content and align-items are similar in their behviour, the difference being that justify-content works on the the main axis while align-items works on the cross axis.
• align-content works only on multi-line containers and has no effect on single line containers.

Sources

1. w3.org documentation on Flexbox is pretty comprehensive and a good read.
2. MDN Flexbox documentation.

• Components

• Structural Directives like ngIf and ngFor

• Attribute Directives like ngStyle

This post primarily documents creating and using custom Structural Directives and how it differs with respect to the more commonly used attribute directive.

What are structural directives?

As the name suggests, structural directives are responsible for manipulating the DOM structure by adding, removing or changing the elements they are attached to. Perhaps the most common structural directive most Angular developers use the ngIf directive, which is used to show/hide the elements based on a boolean condition.

Beginner tip: The structural directives are prefixed with a * while attribute directives may be used just by adding their selector as an attribute to the element.

Creating your own structural directive.

Lets assume that you have a payment configuration based on which you want to show or hide certain elements for certain users. We will create a directive, which will take an input for a feature flag and then show or hide the element based on the payment configuration.

Creating a structural directive is pretty similar to creating an attribute directive.

@Directive({ selector: '[appRenderIfEnabled]'})
export class RenderFeatureDirective implements OnInit{

    private flag: string;

    @Input()
    set appRenderIfEnabled(flag: string){
        this.flag = flag;
    }

    constructor(
        private templateRef: TemplateRef<any>,
        private viewContainer: ViewContainerRef,
        private configService: ConfigService
    ) {}

    ngOnInit(){
        this.configService.isEnabled(this.flag).subscribe(enabled=>{
            if(enabled){
                this.viewContainer.createEmbeddedView(this.templateRef);
            } else {
                this.viewContainer.clear();
            }
        });
    }
}

As you can see, the directive takes one input, the name of which must match with the selector that you choose (appRenderIfEnabled) in this case. The directive gets the reference to a TemplateRef and a ViewContainer, this is because a directive creates an embedded view inside the given ViewContainer and the TemplateRef is used to access the contents of the template/element the directive is attached to.

Now the custom directive is ready to be used, add it to any component like:

<my-pro-version-component *appRenderIfEnabled="'PRO_PACKAGE_ONLY'">
</my-pro-version-component>

Using additional @Input with your directive.

Till now, our directive is just taking the flag as an input, but what if you want to be able to provide a default value incase of missing configuration?

The key part of having additional inputs in structural directives is that the name of the input property must be prefixed with the selector. In our case, we want a defaultConfig, so the name of the input property would be appRenderIfEnabledDefaultConfig.

@Directive({ selector: '[appRenderIfEnabled]'})
export class RenderFeatureDirective implements OnInit{

    private flag: string;
    private defaultConfig = false;

    @Input()
    set appRenderIfEnabled(flag: string){
        this.flag = flag;
    }

    // must be prefixed with selector
    @Input()
    set appRenderIfEnabledDefaultConfig(conf:boolean){
        this.defaultConfig = conf;
    }

The new input can be simply added using the following syntax:

<my-pro-version-component 
    *appRenderIfEnabled="'PRO_PACKAGE_ONLY';defaultConfig: true">

Useful links -

• Official Documentation for Directives

• Official Documentation for creating Structural Directives

From the documentation —

Most websites will also have some form of news-like items, that are shown based on the date that they were published. Some other sites might have ‘book reviews’ or ‘event dates’ or even completely different content. All of these different types of content are called ContentTypes in Bolt, and you can add as many different ContentTypes as you need. Each ContentType is made up of Fields….

Our project was a dance company site, so we defined the following Content Types —

1. Team Members.
2. Videos
3. Series (Collection of Videos)

In Bolt, all contenttypes are defined in contenttypes.yml. Here is what a sample contenttype looks like —

This is pretty similar to creating a database table with the fields title, description, frameUrl & type. The _recordtemplate\ indicates the twig template to be used when the page for this content type is rendered.

Relations

Your database has relations, so it would be amazing if your contenttypes had relations, right? Bolt supports creating Relationships between your content types and it is pretty straight forward. Here is the Series contenttype —

Now, as I mentioned earlier. Series is a collection of Videos. The key here is relations configuration. The works field maps series to the works contenttype.
Multiple — true means that multiple *works *records can be associated to one series record.

Retrieving and rendering related records in templates

Here is how to list all related records in twig templates.

Here, the record refers to the current series.

You can read more about relationships here — https://docs.bolt.cm/3.4/contenttypes/relationships#

About relations in templates — https://docs.bolt.cm/3.4/contenttypes/relationships#relations-in-templates

This is the first project that I have developed with Bolt CMS and really liked working with it so far, the extension ecosystem looks healthy and the future looks promising.

Some background info on me, professionally I am a backend developer who primarily works with Java. I have worked with Apache Wicket for a long time. For those who don’t know Wicket is a web framework for Java with components at its center. So when I wanted to learn a JavaScript frontend library/framework, I chose React as it was similar to Wicket in terms of creating components and composing them to create views while being lightweight enough that it was easy to learn in isolation.

V1: Just React

To start learning React, I made Snooplay: A media player for Reddit. The first version of Snooplay was very simple, it just used React, no routing & no state management. You can checkout the code for v1 here.

V2: React meets Router & Redux

In order to extend my knowledge to Redux, Middlewares & React Router, I decided to extend Snooplay with the following goals —

• The state for the entire app should be stored & managed via Redux.

• The user should be able to change subreddits by altering the URL. eg: snooplay/r/movies. Routing to be handled by React-Router.

• Create the boiler plate using create-react-app

• All styling should be done via SASS/SCSS and compilation of the same has to be done via Webpack.

Now that we know, what our goals are, lets get started. Here is some information on important packages —

• React: v15.6.1

• Redux: v3.7.2

• React-Redux: v5.0.6 (Package that helps connect react components with redux stores)

• React-Router: v4.1.2

• Redux-thunk: v2.2.0

You can checkout the full package.json file here.

Step 1: Create the app boiler plate.

We will create the structure of the app by using Facebook’s create-react-app (CRA) tool. After your install CRA, go to your terminal and type the following command —

create-react-app <app_name>

create-react-app is a utility that creates a pre-configured project with Webpack & Babel and other tools. This was made to get over the configuration issues that people usually face while wiring up different tools together.

This process can take some time, once it finishes you can cd into the directory and type npm start This would open your browser and you should be able to see the React App.

The entry point for the app is index.js which then renders the <App /> component from app.js .

Step 2: Installing the libraries

Now we need to install our essential libraries i.e. React-Router & Redux.

npm install --save redux react-router

Both React-Router & Redux are very modular libraries. For example, React-Router can also be used in React-Native projects, whereas Redux has no direct connection with React. To make it easy to use these libraries we will install 2 more libs.

• react-router-dom: Contains react components to be used in web projects.

• react-redux: Helps connect our components with redux, thus making it easy to read & change state from React components.

  npm install —save react-router-dom react-redux

Step 3: SCSS Integration

This step was very tricky, with many resources on the web. Some worked with Webpack 1 & not with Webpack 2 while some refused to work at all.

npm install --save-dev css-loader extract-text-webpack-plugin node-sass sass-loader

Before we update our webpack configs, we need to *eject *our project. Eject basically means that we will now take care of the webpack & other config instead of just working with what create-react-app gives us. To eject the project just run the following command —

npm run eject

After this process is completed, you will find a config folder which would contain 2 webpack files, one is _webpack.config.dev.js _& other is *webpack.config.prod.js. *As you might have guessed, the dev file your devlopment profile (used when you do npm start ) and the prod file is your production profile that performs optimizations before creating a deployment bundle (run npm run build )

Now in our webpack.config.dev.js we will configure the extract-text-webpack-plugin to handle the scss files.

3.1) Get the extract — text plugin in the file.

const ExtractTextPlugin = require('extract-text-webpack-plugin');

Also declare the CSS file name -

const cssFilename = 'static/css/[name].[contenthash:8].css';

3.2) Configure rules

In the module.exports object, find the module property. In the rules array you need to find the following section —

// "oneOf" will traverse all following loaders until one will                               // match the requirements. When no loader matches it will fall                               // back to the "file" loader at the end of the loader list.                               oneOf: [
....
]

Here add the config to process scss files using appropriate loaders.

{
test: /\.scss$/,
use: ExtractTextPlugin.extract(['css-loader', 'sass-loader'])                                 },

Note: Several examples on the internet use the loaders syntax, but that is deprecated.

Also, you should comment out the css loader that is pre-configured in the file.

Step 4: Redux & Redux-Thunk

Before going forward here, I would like to mention 2 resources that helped me greatly in understanding Redux & Thunks.

1. Stephen Grider’s Modern React with Redux course on Udemy. Check it out here — https://www.udemy.com/react-redux/

2. Matt Stow’s Dummy’s Guide to Redux & Thunk. Check it out here- https://medium.com/@stowball/a-dummys-guide-to-redux-and-thunk-in-react-d8904a7005d3

An introduction to the various terms you are going to see moving forward in reference to Redux.

• **State: **State refers to the data of the application that we store in Redux. Redux creates this one big JavaScript object to store all the state of the application. State can only be updated by Reducers.

• **Reducers: **Reducers are plain JavaScript functions that are responsible for updating the state of the application. Each reducer is responsible for updating one part of the application state.

• Actions: An action is basically an object that describes an event that would result in a change in state. Each action has type property which helps reducers in deciding if they have to respond to this action or not. Function that return actions are called action creators.

• **Redux-Thunk: **Action creators usually returns a plain JavaScript object. Redux-Thunk allows you to return functions instead of objects. These functions recieve dispatch & getState store functions which allow you to further call actions from inside the function. Example of such action creator —

Example of using Redux-Thunk

Step 5: Creating our store and using Redux.

I would like to outline the process that I used to create my store.

• Design the app state on paper or as a JavaScript object in any text editor.

• Create reducers for each property. At this step all reducers simply returned the state without any other process.

• Bind reducer & properties. This is how the state for Snooplay looks

  //As you can see, each property is assigned a reducer. const rootReducer = combineReducers({ currentPost: ReducerCurrentPost,
  posts: ReducerFetchPosts, subs: ReducerFetchSubreddits,
  currentSub: ReducerCurrentSubreddit, loaderVisible: ReducerLoadingState, notification: ReducerNotification, lastPostId: ReducerLastPost });

• To provide the state to the entire application, you need to wrap your components with Provider component provided by react-redux package.

• Now that we have linked our properties with our reducers, I would like to point out that in our reducer functions, the _state property refers to the value of the property only and not the entire state_. For example, here is my ReducerCurrentPost-

  // here the state is the value of ‘currentPost’ property of the app // state and not the entire state. export default function currentPostReducer(state = null, action) {

  }

• **Actions & Action Creators. **As described earlier the action is simply a JS object with a type field. Any data that has to be sent to the reducer can be sent as the payload property of the action. Here is what the action creator to set the current post look like-

  //This is an action creator, returns an action with a type and //payload. export const setCurrentPost = (post) => { return { type: ACTION_CURRENT_POST, payload: post } }

When this action is dispatched (called) like setCurrentPost(post) redux sends this action to all reducers. The the current post reducer can respond like-

import { ACTION_CURRENT_POST } from './../Constants';

export default function currentPostReducer(state = null, action) {
    switch (action.type) {
    //This reducer checks the current action type
    //Returns the post (payload)
    //This post is updated in the state
      case ACTION_CURRENT_POST: {
        return action.payload
      }
      default: {
        return state;
      }
    }
}

Next, we want our components to update when the associated state is changed. So lets say we have a component which displays the current post. When the reducer updates the current post in the state, we want this component to re-render to show the new post. This is where the connect method from the react-redux library comes into play. It connects the react components with its associated state.

Note: In react world, components which work directly with the store are called Container Components and components which work only on the given props (irrespective of where the props are supplied from) are called Presentation Components.

This is what my PostContainer component looks like. It is directly connected to the store —

import React, { Component } from 'react';
import { connect } from 'react-redux';
import { bindActionCreators } from 'redux';
import { setCurrentPost } from './../../actions/';

class PostContainer extends Component {
    render(){
       return(<h1>{this.props.post.title}</h1>)
   }
}

function mapStateToProps(state){
    return {
      post: state.currentPost
    }
}

function mapDispatchToProps(dispatch){
    return {
      actions:{
        closePlayer: bindActionCreators(setCurrentPost, dispatch)
      }
    }
}

export default connect(mapStateToProps, mapDispatchToProps)PostContainer);

So whats happening here?

Here we create a Component that has to render some details about the current post of the application.

• mapStateToProps is responsible for taking the entire application state and then getting out the relevant pieces needed to render the current component. These pieces are then provided to the components as props
  In the above example the currentPost property of the application state is accessed using the standard props mechanism.

• mapDispatchToProps is used to call actions from inside the component. In the above example, I use the setCurrentPostaction to close the player. you can call the setCurrentPost action by calling this.props.actions.closePlayer(null) .

• In the end we use connectto wire all these together. Now whenever the currentPost property is updated in the state, PostContainer will be updated to reflect this change.

Note: if you are wondering why to use mapDispatchToProps — Readthis StackOverflow answer

After this you can setup React-Router. There are many great examples/guides on how to do this. Just note that do not follow a react-router v3 guide if you are working with v4 as v4 is a complete re-write.

React Router setup was a breeze, one thing that bugged me was navigating to paths programmatically. To do this in v4, I have used the withRouter Component from react-router-dom package. This is what it looks like —

import React, { Component } from 'react';
import { withRouter } from 'react-router-dom'

class SubmitLink extends Component {

    handleClick = () => {
      if (this.props.onClick()) {
        this.props.history.push(this.props.navigateTo());
      }
    }

    render() {
      return (
       <a onClick={this.handleClick} className="button">   {this.props.label}</a>)
      }
    }
}

const NavigableSubmitLink = withRouter(SubmitLink);

export default NavigableSubmitLink;

This component first calls the onClick property, if that function returns true, then it calls the navigateTo function which returns the new path that it has to go to after computation. Using withRouter gives us access to updated match, location, and history props.

Ending Notes —

• The real documentation is in the issues: In the Java world, we have Java Docs & where they don’t help StackOverflow steps in. But in the JS world, most problems I ran into were solved somewhere in GitHub issues. So if you run into problems, don’t skip the GitHub issues.

• In the Udemy course linked above, they use react-promise middleware, but here I use react-thunk middleware even for Ajax calls. That’s just a personal preference because I prefer less magic in my code :)

That’s the end of this article, I have tried to explain all the problems I faced and how I overcome them. If you want to more detailed explanations of React, Redux & Redux-Thunk, look at the resources I have linked above.

In our “code world” everything is about teams. But what happens when you are the team, the idea man, the programmer,the front-end designer & even the graphics guy.

TLDR; when you are the team, IT SUCKS!!

Recently, working on my biggest project till date, I realized the pitfalls of working alone. There are many of them, I’ll just write up a few.

Some times, while writing code our mind concentrates so much on the present problem that its easier to forget the bigger picture.

When working on client’s project, we have a clearer view — the client’s view, but when you are the idea man, things are different, to-do lists are not that helpful, having someone who shares your idea he keeps you informed about the current state of affairs.

Front-end, back-end, graphics do ‘em all and one of them is bound to suck.

Gone are the days of master of all trades, now is the time for specialist at one…. or maybe two but not three. I started programming in Java, got my first job at 19 as a front-end developer doing HTML/CSS & then got back to Java. While at my last project, I was responsible for the Front-End and the Back-End and believe me, some pieces of code sucks, and I know that.

The most important of them all

Your code buddy keeps you upbeat

When working for long hours, you are bound to burn out, and anyone who has written more than “Hello World”, understands the fact that one can come across very frustrating situations. Having a code buddy who understands this thing helps you to keep upbeat about the prospect of finishing what you important.