Experiments at work

Hello readers. So back with another easy yet unexplored feature of npm/yarn packages. We as frontend developers / SDK developers, have to deal with more than one repositories where we actually code contribute. Most SDK developers would know this already or they use the not-so-well documented 'npm link' command . /**  *  @disclaimer  * Please read this post fully before executing any command. My scenario might not be the same as yours.  * This article below uses a repo from my current workplace as an example which is open-source and does not violate the Cisco Confidentiality Policies */ To make this article easier to understand, some representations, Host - Package that needs another local package as part of its node modules. Let's assume the path to this package is  ~/Documents/Repos/demo-app Adhoc - Local package that is added into another package as a dependency. Let's assume the path to this package is  ~/Documents/Repos/semver-monorepo What is npm link? This is a co

I, recently got a scenario at work where the feature had to be tested out in iOS.  It has to be noted that iOS Safari, as well as Chrome, uses the Webkit Engine on iOS. Rumours are that Google is building its own iOS javascript engine but it might not be available for public usage any sooner. That said, I tested out the feature on an iOS Safari browser. Whether or not the feature worked, developers can never resist taking a look at the logs while testing, to ensure the flow. That's where my curiosity lay too.  Prerequisites MacBook device iOS device Cable that connects the above two devices Steps to follow Step 1 - On your iOS device: Open the Settings app on iOS Go to Safari Inside Safari, navigate to  Advanced Here, enable  Web Inspector Now open your Safari browser on iOS and have your Web app loaded for debugging Step 2 - Connect your iOS device with your MacOS device using the cable Step 3 - On your MacOS device Open the Safari browser on your MacOS device If you do not see

Once again, another git magic that might be of help to some of you. This research came up when I accidentally added a couple of unwanted files and wanted to remove them from a commit. We all know that to update an existing commit, we shall follow this git magic to amend commits . However, how do we drop changes to a particular file in a commit? While that is easy, it is also tricky. This blog post covers scenarios and respective commands that help you understand what should be done. /**  *  @disclaimer  * Please read this post fully before executing any command. My scenario might not be the same as yours. */ There are two scenarios to be handled here, Remove a newly added file Remove changes to an existing file Let's look at them separately, Remove a newly added file This is the scenario where an unwanted file added to the commit. This file might be some config.json that got generated while doing a research on a new testing tool or a bundling tool. Such scenarios are easier. 1. Re

Back after a while with another git magic. We already have seen how to get rid of the top most commit in this article ->  Git magic - Make commits disappear First of all, it's one of the not so recommended way of doing it and more than that, it can only get rid of sequential commits from latest. I recently happened to get into a scenario where I had to drop a commit in the history by keeping the latest ones. As part of that exploration, presenting you this article. /**  *  @disclaimer  * Please read this post fully before executing any command. My scenario might not be same as yours. */ To my greatest surprise, I didn't know a git rebase could do this. Please continue to read to know how. The steps are simple, Count until the commit line you need to drop using git log Do an interactive rebase and you're done.  Let me explain step by step. 1. Look at the commit log & count commits This is the first step. First let's list the commits using the following command,  

As always, let's start with a story why I have written this one down. I have been using git for almost 5 years now and in one of my work places I had to work on the same project but different features in parallel.  Switching between branches back and forth was a costly operation given that I didn't discover commit amend until recently. Even though I'd have discovered commit amend, I'd still have did this. Still did what? I can sense that question deep from your throats. So, whenever I am in a situation to work on multiple features or a feature and a bug fix, I'd have two clones of my repo each with different branches, Whenever a feature is merged or the fixes are merged, I'll delete the clone in my machine and branch in my origin (Gitlab / Github etc.,) Recently when I started writing these git articles, my manager suggested me to learn about Git Worktree and it'll be useful. And when I got free and good understanding of git commit, rebase and stuff, I decid

I have already written on getting started with TDD . Let me extend it further and mention in theory what are all the phases involved in a TDD. Before jumping into this article, I hope you read the getting started with TDD article.   There might be more steps involved in TDD. However we're just going to discuss the phases of TDD and what do we do in each phase. /**  * @disclaimer  * I'm just preaching what I have learnt & practice   * Some parts of it could be wrong  * Please feel free to leave comments if am wrong  * And I would be happy to stand corrected */ The three phases of TDD are the, Red phase Green phase Blue phase Red phase This is the very first phase in TDD where we write a test for it to fail.  Green phase This is the second phase and immediate next phase to red phase where we write code for the test that we just wrote in the red phase to pass.  Blue phase This is the third and final phase of a test where you refactor the test to simplify it down further. Thes