In light of recent events, there's been some confusion about the polyfill.io service and polyfill.js. This article aims to clarify the differences and address some concerns.

The Polyfill.io Incident​

News recently surfaced about the polyfill.io service injecting malicious code into JavaScript assets fetched from their domain. This article provides a detailed account of the incident.

Understanding Polyfills​

According to MDN, a polyfill is a code snippet, typically JavaScript on the web, that provides modern functionality on older browsers lacking native support. For instance, if you want to use the latest JavaScript APIs like array filter or map—supported by Chrome but not IE7—you'd need a polyfill to ensure seamless functionality.

The Role of CDNs​

A Content Delivery Network (CDN) is a system of interconnected servers that accelerate webpage loading for data-heavy applications. Commonly used static assets like jQuery, AngularJS, React, and Bootstrap.css reside on CDNs. Web applications can directly use these assets, saving on network and storage costs while enhancing application performance.

When a user in Location X visits your web application, the static files needed are downloaded from the nearest CDN to Location X, reducing latency and improving performance.

The Case for External Services​

This blog post provides an excellent discussion on using polyfill as a service. The main argument is that shipping polyfills for every feature can lead to unnecessary downloads for users with modern browsers. This can negatively impact performance and user experience. An external service can help by shipping only the relevant polyfills based on the requesting browser's user agent.

Angular's polyfill.js​

Angular's build system generates optimized, production-ready code files, including a file named polyfill.js. There's been confusion about whether this polyfill.js is related to the polyfill.io incident. The answer is a resounding NO.

Angular's polyfill.js is a file generated by the Angular build system for polyfilling required functionalities. It doesn't use any of the polyfill.io services to generate this build file, unless you're using the service in your source code.

8 Years ago…

AngularJS was very popular library and talk of the town.

The Software product had a requirement of providing a search solution with display of tabular data / pagination etc. with some UI animation.

It was decided by the tech lead and the management to go with AngularJS and there could be various reasons for it, possibly:

• AngularJS was popular framework
• Going forward all the new features in this software product had to be developed using AngularJS
• It is always exciting to work on a new technology irrespective of figuring out if it actually is needed.

This feature was released and praised, but over the years, there have been no instances of this library being used for any other features, reasons:

• Continued usage of the legacy framework, it being the obvious choice
• The rising popularity of Angular2 over AngularJS causing lack of time and interest.
• Lack of resources / technical skills in AngularJS

So, this huge product had AngularJS as a low hanging fruit, used only for one single feature.

However, security fixes to AngularJS library were patched whenever available.

Transition from AngularJS to Vanilla JavaScript​

Fast forward to today, and our feature remains, but the landscape has shifted. AngularJS is officially deprecated and so we had to reevaluate our choice.

• AngularJS library is deprecated.
• Security concerns from customers
• In this entire product, AngularJS is just used for this one feature.

We chose to use Vanilla JavaScript for various reasons, though the specifics are not relevant here.

When I began working on this feature, it became clear that Vanilla JavaScript could effortlessly provide the same functionality.

Over-Engineering and Unnecessary Complexity in the Original Code​

After careful evaluation of the code, it appeared that this feature was over-engineered.

• I discovered unused or infrequently used library files, bootstrap files, and a templating engine library.
• I believe these libraries were added with the assumption that they would be useful for developing new features in the future. However, this turned out not to be the case.
• Naturally, no one wanted to work with this code again, so all the core library files were left untouched.
• There were clear violations of the DRY (Don't Repeat Yourself) and KISS (Keep It Simple, Stupid) design principles, indicating areas for improvement.

Enter the era of simplification.​

Opting for vanilla JavaScript, we embarked on a journey to streamline our codebase and embrace the principles of DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid), and YAGNI (You Ain't Gonna Need It).

The entire exercise of removing AngularJs involved the following steps:

• Reviewing and understanding the entire feature
• Reading the AngularJS code and identifying areas for improvement
• Rewriting the entire feature using vanilla JavaScript
• Ensuring the transformation does not affect the user, as only the underlying technology is being changed, not the user experience.

The Transformation: From Excessive to Efficient Coding​

What began as an experiment turned into a revelation. With over 16K lines of unnecessary clutter stripped away, and under 1K lines of focused, purposeful addition, we emerged with a leaner, more efficient feature.

The journey wasn't without its challenges, but it was immensely rewarding. We honed our skills, boosted our confidence, and left behind a codebase that is not just functional, but elegant and maintainable.

• Increased my confidence in working independently on a feature.
• Enhanced my ability to read any framework code and convert it to vanilla JavaScript.
• Deepened my understanding of vanilla JavaScript.
• Refactored the code, making it more readable and maintainable.

As we continue to evolve, let's remember the value of simplicity, the power of pragmatism, and the importance of continuous improvement.

In this blog post, I am thrilled to share the story behind my proudest Pull Request (PR) yet. PR#458 wasn't just another contribution but a significant milestone in my journey as a software developer. It was a challenging task that pushed me to my limits, and in overcoming those challenges, I learned valuable lessons that have shaped my approach to coding.

By the Numbers​

Before we delve into the story, let's take a moment to appreciate the sheer scale of this Pull Request. It comprised nearly 10 individual commits, introduced close to 2,800 new lines of code, and astonishingly, resulted in the deletion or modification of over 314,400 lines across almost 1,000 files.

History​

The project I worked on has a rich history spanning almost two decades, evolving from a Windows application to a browser-based web app with a diverse tech stack. This enterprise application has made careers of many software engineers, which means this codebase had been touched by many software engineers. With wide tech stack such as CPP, Java and Dojo framework on the UI, over the years, it accumulated tech debt, and my role primarily focused on UI enhancements and refactoring.

The need for a change​

The accumulation of tech debt prompted a thorough review of the codebase to identify areas for improvement:

• Removal of unused assets and code snippets.
• Refactoring of legacy code to improve readability and maintainability.
• Elimination of support for outdated browsers.
• Streamlining of build scripts to remove unnecessary generated files.

Motivational Quotes​

I came across a tweet from Elon Musk that resonated deeply with me: "Far better to delete code than add it." This philosophy encapsulates the essence of efficient software development. While striving for 100% optimized and performant code from day one may seem ideal, the reality is that codebases evolve over time, accumulating unnecessary complexities and redundancies.

Another quote I hold dear is, "Always leave the code better than you found it," attributed to Ward Cunningham. This mindset drove me to embark on a journey of code refactoring and deletion, particularly in a legacy codebase spanning two decades.

Given that we were at the onset of a new release cycle, it presented the perfect opportunity to implement these changes. In the process, I identified several areas ripe for improvement:

• Eliminating unused styles and assets meticulously, even if they were part of the codebase for years.
• Letting go of support for outdated browsers, such as IE6, as their usage dwindled over time.
• Since our project utilized the Dojo framework, it came with its own set of theme files. I painstakingly sifted through these files, pinpointing and eliminating any redundant styles that were no longer in use.
• Streamlining build scripts to remove unnecessary auto-generated files, optimizing the build process.

These actions required patience and thorough unit testing at every stage to ensure they didn't impact existing functionality adversely. By adhering to these principles and embracing the challenge of improving legacy code, I not only enhanced the codebase's quality but also cultivated a mindset of continuous improvement in software development.

We diligently conducted unit tests at every stage to ensure that our changes didn't inadvertently impact any existing functionality.

In the end, this comprehensive cleanup effort not only improved the overall quality of our codebase but also positioned us for smoother development cycles in the future.

The Result​

The PR was not only about code changes but also about personal growth:

• Increased confidence in tackling a codebase spanning two decades.
• Improved code readability and maintainability.
• Timely refactoring to prevent future tech debt.
• Opened doors for new opportunities and stretch assignments.

Room for improvement​

While I'm incredibly proud of this PR, reflecting on it, there are areas where I could have refined my approach:

• Learning Opportunity: This PR provided me with a valuable opportunity to delve deep into the codebase, uncovering insights and learning valuable lessons along the way. It's crucial to leverage such opportunities for continuous growth and improvement.

• Confidence Boost: Deleting code can be daunting, especially when it seems to be functioning correctly. However, this experience reinforced my confidence in making impactful changes to enhance the codebase's quality and performance.

• Enhanced Readability and Maintainability: By eliminating unused code and improving overall code cleanliness, we not only optimized performance but also made future development efforts more efficient. Why burden ourselves with code that serves no purpose? Additionally, utilizing version control tools like Git and GitHub ensures that we can always reference previous versions if needed.

• Doors to New Opportunities: Although this PR focused on code cleanup rather than adding new features, it opened doors to exciting opportunities. It demonstrated my commitment to maintaining code quality and readiness to tackle tech debt, qualities that are highly valued in any development team.

In hindsight, I could have further optimized my approach:

• Breaking down the tasks into smaller, more focused PRs could have facilitated smoother integration and minimized the risk of unintended side effects. This iterative approach would have allowed for more granular testing and validation over multiple production builds, ensuring a seamless transition.

Conclusion​

In conclusion, working on PR#458 was an enriching experience:

• Deepened my understanding of the codebase.
• Boosted my confidence in refactoring and deletion.
• Enhanced the overall quality of the codebase.
• Presented new opportunities for professional growth and learning.
• Overall, PR#458 represents not just a code contribution but a journey of growth, learning, and improvement.

Working on legacy code has its own advantages and in this post I want to talk about how I enjoy and appreciate working on code that is dated as old as 15+ years.

You do not always get to start a project from scratch. Any software product usually evolves over time and ensuring that all the future developments are robust requires considerable efforts.

With technology, digitization and access of internet, things are moving ahead at rapid pace. I feel that User experience (UX) is the most valuable skill that everyone should possess.

A group of individuals with common interest plan to meet to share their knowledge and network. This is my definition of a Meetup. I have read several blogs about meetup's but never attended any. I did not plan anything nor did I know about this meetup until a day before. It was just on the spur of the moment. I am glad, I attended this meetup and hence sharing my experience through this blog post.

I have no clue what made me register on the meetup.com website. It was Friday evening, I was about to wrap up my daily office work. I pointed my browser to meetup.com and registered. The website popped at me a meetup that was happening on Saturday 05th of Oct 2019 from 10.00 AM to 12.00 PM. The host were sharing their experience about React with Typescript == React on Steroids. Interesting. I wanted to learn about it. Unfortunately, RSVP were closed. "I could always watch about such topic on YouTube", I thought.

Surprisingly, someone in the comment had mentioned that no need of RSVP, everyone is welcome. I did not have any excuse but attend.

Smartphone's and in turn social media plays a very important role in our life, without which we would be stranded. Right? To a certain extent it is the truth. We use social media because we want to be connected. But we forget the toll it takes on our life through its continuous usage. In this post, I go through my journey from a social media addict to being a social media ghost.

First, a little background. I had an important feature delivery in the coming week but due to personal work, had to take two days off on a short notice. This meant, I had to complete my current development tasks. "No Problemo !", I thought. My inspiration for working overnight comes form the movie, "The Social Network". I have mentioned about how amazing the soundtrack of the movie is, umpteen times, here on this blog. This essay is my retrospection per se on working overnight.

Work commitments of an important feature delivery and family never go in hand. You will spend more time working compared to the time spent with family or honing your hobbies, the universal accepted law for the software professional by the software professional, always holds true.

Writing code is fun, interesting and fulfilling. However, debugging is an equally important skill. Solving an issue sometimes may give you a taste of hell especially when you are not aware where to look for the root cause. At first, a defect may look simple, but figuring out what to debug and where to hunt demands for attention. Today was a fine morning, after sipping my coffee and afresh, I was sure I would destroy the task at hand point blank. Fate was not on my side and I hit a roadblock. I spent almost 2hrs trying to figure what could possibly go wrong, most of the time starring at the screen clueless. I needed a different perspective.

Computer science is the most sought for specialization in Engineering colleges, at least that's what I've heard. When I entered my first year of college, I barely knew that Computer science means theoretical study of computers. Even though we had the best of the syllabus, I could hardly relate the theoretical knowledge with the practical world. Despite of having practical hands-on sessions on almost every subject which I think constituted 20% to 30% of the time we spent in the entire course, I found it difficult to understand the concepts. This was around 12 years back.

Assuming that the current curriculum consists of theoretical knowledge, how can one outperform in college? After having a decade of experience, I try to explore and answer the question, "what advice would I give myself if I were back in college?"