Showing posts from November, 2018

I Find Bugs too Boring to Write – Deconstruct 2017 – Arlo Belshee

In this talk, Arlo Talks about a safe way to refactor the code, without having many tests.

One at a time -

The premise here is to refactor the code to make it more readable and extract the concepts into abstractions one at a time, without changing the logic in the code.

It turns out that once we have those abstractions separated, the code becomes more readable and its easier to extract out the classes and layers thereafter.

Frequent Commits -

Also, another practice he presses here is to commit regularly (every few seconds) and prefers adding 'suggesting names' or 'honest names' (as he calls) instead of coming up with definitive names upfront to these abstractions. (use of 'mayBe_' or '_Ithink', etc).

This way we take enough time to understand the concept at a deeper level before giving a name. This additional knowledge will help us come up with better names and result in a better level of abstraction.

Checking-in and backtracking -

Also, Checking-in frequently …

Agile Only on Paper

5 Signs That Reveal Your Software Development Process Is Agile Only on Paper and Solutions for Them
Agility comes with practice not putting big words on paper. Using Jira does not make your software development process agile. Saying we do “scrum” is not being agile. Being agile is having an agile mindset and putting it into practice everyday. It is about thinking about the value you deliver to the customer and how to do it better. This post will also unveil these 5 signs and how to solve these issues. The signs and solutions will concern multiple roles like Product Manager, Software engineer etc.

TLDR; If you are writing documents > 5 pages you can improve. There should be a clear definition of Ready for development and Done. Story/Issue should be based on value delivered to the customer not only the technical aspect. Releasing a new version of software once a month and saying we are agile should be a crime. Not caring about the team is not doing agile right. Below are the signs th…

Strategies For Working With Legacy Code

Always keep a log of the work you do on daily basis and where your time is going.
It best helps to reflect on where your time is going and decide what actions are dragging you and take corrective measures. The outcome will help identify the skills gap, process issues, find better tools, etc.

Original Post Strategies For Working With Legacy Code By Rachel Davies

Some More Git: Git Tagging Tutorial

I read a post on which shows how to create git tags using GUI-based git clients. I think that tags are useful to know even when using the git cli. What are tags Tags are specific points in your code history which are useful to re-visit later e.g
you just released a new version of your app. You can tag the commit as v1.0 using git tag v1.0. Anytime you want to reproduce bugs encountered on that version, simply do git checkout v1.0 and investigate. How to use git tag betterCheckout code to the tag The tag is linked to the specific commit and not to a branch. When you checkout the tag, git tells you that you are in "detached HEAD" state. Do not worry, all it means is that you need to create a new branch if you want to retain any changes you make after checking out the tag. Create a new branch exactly at the commit of the tag using git checkout -b BRANCH_NAME TAG_NAME Make your tag more informational! You can add more information using git tag -a TAG_NAME -m 'MESSAGE…

Developer Differences: Makers vs Menders

When you think of a developer what comes to mind? A brogrammer living in San Francisco working 23 hours a day on the next Facebook? If so, you wouldn't be alone. Like so many industries, software development is rife with stereotypes. And one that is particularly pervasive is the idea that all developers, if given the chance, would opt for a complete rewrite of an application. While it's true that there are many software developers who do enjoy starting with a clean slate, there is also a group who loves working on making existing applications better. Rather than starting from scratch and building an 80% solution, these developers are ideal for taking over a project once it's become stable, and nurturing it for a long time. Neither developer is better. Both are needed in the software world. You just need to understand when to use each one. Makers Enjoy Initial Development & MVPs To demonstrate how these developers are different, let's look at the typical product li…
A extension of the TDD was proposed by Kent Beck few weeks ago. Its called TCR (Test && Commit || Revert). This workflow promotes constantly checking in the changes while making sure the build never fails. This is an interesting approach and would like to try out to learn more about this practice. Visit this blog post for deep dive into concept of TCR.
A good resource for sharpening the coding skills.

Martin Fowler – What Does Tech Excellence Look Like? | TW Live Australia 2016

My GIT Cheat Sheet

When we want to know all the changes that happened between two commits, or from date A to Date B. We can get the details by querying the git repository through Terminal.  Here is the command for finding all the files changed between two commits.
git diff --stat <Commit ID 1> <Commit ID 2>
Commit ID 1 is start check in. Commit ID 2 is end check in. The results will show all the files changed between these two commits. Reject local commits and reset the local brnch to the remote/origin/master branch state
git fetch origin
git reset --hard origin/master
Reject local commits and reset the local brnch to the remote/feature branch state
git fetch origin git reset --hard origin/feature/STORY-###-BranchName
If you already started in the Rebase opetion and want to abort the rebase operation then use -

git rebase --abort
git reset --hard origin/master
Creating stash from one Branch and applying to another branch Make change on Branch 1, Stash it from Branch 1. Now check out Branch 2. Go to t…