DEV Community: Shuhaid Lambe

Git cherry pick command explained

Shuhaid Lambe — Thu, 09 Jul 2020 10:12:24 +0000

The cherry-pick command allows you to integrate individual commits from any branch into your current branch.

To set some context, here is a quick overview of our git branching structure.

master - This is the main branch i.e. our live/production servers point here
develop - This is the branch where code gets pushed to, for integration testing on our test environments i.e. our testing servers point here
release-x.x.x - These branches are cut for any long running releases or features we are working on as a team. The release branch when ready is merged to the develop branch to be tested in the integrated test environment. Post which the release branch is merged with master when it's ready to be pushed live
hotfix-x.x.x - Arrgh! That nasty little bug sneaked through to live 😑. Create a hotfix branch from master, quash the bug in this hotfix branch. Then merge hotfix branch to develop and master branches to push your hotfix in to your test and live environments.

Cherry pick command

Consider the scenario you have cut a release branch to work on a feature. In the midst of that you need to make a small change to your live environment. Or even worse you have a bug that has sneaked through to your live environment and needs to be fixed asap! It does not make sense to wait and bundle it with your release branch as that is still 2 weeks from completion. In this scenario you will create a hotfix branch from your master branch. Make your changes in the hotfix branch and merge it back to the develop and master branch once you are done.

You might not be ready to merge your release branch with the develop or master branch yet as it might have breaking changes that you do not want to integrate yet. But you only need the hotfix commit in your release branch and that's when the cherry-pick command comes in handy.

git checkout release-x.x.x
git cherry-pick 47rul5
# 47rul5 is the reference for the hotfix commit

Check out links in the further reading section below, to get more in depth understanding on using the git cherry-pick command. It is a useful tool to have in your git commands arsenal.

Create video walkthroughs of your product for free

Shuhaid Lambe — Wed, 30 May 2018 08:15:29 +0000

Recently we started writing our product's user manual and just when we were nearing completion our users started asking for video walkthroughs of the product.

Needless to say, we started questioning ourselves whether we should have done the videos first. The outcome of that discussion is a topic for another day. Fow now, here's how we went about putting our product walkthrough videos together.

Requirements/Constraints

Before we started creating our walkthroughs we posed ourselves the following requirements.

Audio + Video - Keep text and annotations within the video to a minimum. We wanted the voice over to guide the user through the features. Use a text to speech service which will keep the voice over consistent across all our videos.
Ease of creation - Anyone from our (small) team should be able to create/edit these videos.
Maintainability - As we keep adding features to our product or change a functionality. We should be able to change the audio & video content with ease.
Budgetary constraints - We did not have funds allocated to create video walkthroughs. And thus, needed to create this at little or no cost.

Solution

After a couple of days of searching for tools required to create our walkthroughs, we settled on the following tools. It would be great to hear from you if there are (better) alternate tools available to perform the same function.

Audio

Keeping in mind the requirements, we wanted to make sure the audio files are easy to recreate in case of product updates. To create our audio content we settled on Amazon Polly. Amazon Polly is a service that turns text into lifelike speech.

Here is why we went with Amazon Polly:

We were able to create our audio content in Speech Synthesis Markup Language (SSML). Among other things, SSML makes it easy to add a pause in the audio to allow the screen to load or an action to be performed. It also makes the content easy to create / edit and add it to our source control. Our SSML files are now now part of our code documentation.
Under the free tier we got 5 million characters per month. This was more than we needed.
It has plenty of language and accent options. We went with the "Indian English" option as our target base at the moment is primarily Indian.

Using Amazon Polly we created .mp3 audio files for our voice over. Each audio file was kept under 2 minutes. This was done to make it easy to edit a particular section without impacting the full voice over.

Video recording

Next we needed a screen capture tool which highlights the mouse pointer. For this, we used CamStudio. CamStudio is an open source desktop screen recorder. We would listen to the created audio and record our screen using CamStudio. This helped in keeping the video in sync with the voice over as far as possible.

Video editor

To put this audio and video together we used OpenShot. OpenShot is an open source video editing software. Using OpenShot we were able to merge the recorded video and audio and create the final product.

Both the tools mentioned above have a lot of help content available online and are fairly easy to use.

Here is what our output looks like

It would be great to hear your feedback on this process and if you have used other tools which can make this easier.

Photo by Seth Doyle on Unsplash

How to document requirements and not put people to sleep

Shuhaid Lambe — Sun, 05 Nov 2017 12:19:05 +0000

A project requirement document whether functional or technical is a snooze fest for any techie to read through. The start of a project is the most important phase. Well thought through requirements play a large role in the project's success. But this probably remains, the most critical yet boring phase of a software development cycle.

On the other hand, imagine the requirement writers state of mind. Someone who has painstakingly tried to document every scenario that they could possibly imagine. Knowing fully well, there is a good chance something is going to get missed when the implementation hits the road.

Throw in some other challenges:

You are dealing with developments teams spread across geographies. Places where English is not their first language. A lot could get lost in translation in such scenarios, through no fault of anyone.

You have a set of requirement documents which have captured everything needed on day 1. How do you keep this current when changes start coming in thick and fast?

You would like your development teams to have a holistic view of the project even though their focus areas are limited to a set of components from the entire project.

Personally, I have come to believe that using a Mind Map to capture a systems requirements is the best way to alleviate these challenges.

Read someones mind or open your mind to someone

Check out this mind map describing Tennis to a novice Courtesy wikipedia

This map covers the type of shots in the game, scoring mechanism, playing surfaces, key tournaments and key principles. Along with this it covers trivia like the fastest serve and other bits of information. Enough to upgrade someone from a novice to an amateur level understanding of the sport.

The same level of information if covered in a document would be verbose and could loose a high percentage of readers mid-way. Writing information in form of a mind map increases the chances of your readers going through everything you have documented. Moreover, this format also increases the chances of the concept being understood.

Here's how you can start using it for your project.

To start mind mapping, try FreeMind it's free and makes it simple to create and distribute map files.
After you have downloaded and installed FreeMind try documenting a project or module you are working on.
Put the name of your project or the module you are documenting in the first (root) node. From the Format menu option click on Automatic layout. This will ensure your map looks pretty right from the outset. You can edit these layout options as you go along.
Identify your key stake holders and put that as your first set of nodes after your root node. For example for a ticketing system Customer & Customer service team could be the the first set of nodes.
Next up, identify the key use cases for each of these stakeholders. For ex. A customer would need ability to raise a ticket and check status of their tickets. You can add subsequent nodes to these nodes and detail out the fields and rules associated with the node you are working on.
If you need to add an explanation or a note to a particular node, click on the node and navigate to the View menu option and click Note Window.

The beauty here is each node comes with a context as it lies in a certain position within the hierarchy. If while reading your user loses context, they just need to back up within the hierarchy to find context. Making mind maps easy to walk through while explaining a concept or project functionality.

Detailed mind maps can be quite large and can cover every aspect of your project in detail. If you haven't it tried before, its certainly worth a shot. Here are some more usages of mind maps. Check it out.

Hi, I'm Shuhaid Lambe

Shuhaid Lambe — Tue, 21 Mar 2017 13:09:38 +0000

I have been coding for 16 years.

You can find me on Twitter as @shuhaidlambe

I live in Pune, India.

I work for startup Swipez which I co-founded with by college buddy Vivek Iyer

I mostly program in these languages: PHP, Perl, Java

I am currently learning more about SaaS sales.

Nice to meet you.