3 posts tagged with "developer tools"

Why do we have pull requests?​

As software developers, we enjoy that feeling of being immersed in the flow, that wonderful state of being where hours whizz by in an instant, and our mental model stands clear; where we can be hyper-productive as long as we can keep the outside world at bay and remain in blissful uninterrupted solitude.

However, building modern software is also a complex team sport where collaboration and continuous feedback loops with fellow developers are key to personal development and high-quality code.

Code reviews are the most obvious contact point with other developers and a foundational process in working towards becoming a part of, remaining in or working towards building a high-performing team that creates code that is stable and fun to work with.

While one on one code reviews likely offer the most value in terms of learning from each other and making available stable applications to our end users it is unfortunately not always practical to meet face to face. We are frequently working on different schedules in distributed teams or require input from multiple people to weigh in on a design decision all reasons making it unpractical to talk one on one about our code.

Fortunately, the development community has been steadily iterating on the process of reviewing code contributions from developers distributed around the globe. Through many iterations and trial and error of sharing patches via email, IRC, forums, and various other communication channels we are currently positioned to take advantage of the “Pull Request” concept for conducting code reviews.

The concept of a pull request as a mechanism for conducting code reviews is built into all popular modern code management platforms like GitHub, GitLab, Bitbucket and others.

In simple terms, a pull request is simply a request to get input from fellow developers on some code that you would like to contribute back to a project. Depending on the platform in use there are various features for working with pull requests but usually, there is a forum-style feature set used to discuss and reason about source code changes.

What is a pull request?​

Ok, so let’s take a stab at a definition of a pull request.

“A pull request is a form of code review that is facilitated by a code management application that provides communication mechanisms specifically designed for talking about specific source code changes. In other words, it is a technical solution for conducting asynchronous code reviews, typically before accepting code into the code base.”

Before digging a little deeper into the pull request, I want to take a quick detour and encourage you to think about what type of developer you are striving to be and to think about your work in the context of your team. Ideally, you are reading this with the motivation of striving to be the best developer you can be and that includes thinking beyond the code. Hold that thought in the back of your mind as we move on.

Alrighty, so back to pull requests. Recalling that pull requests are a mechanism for discussing code it then follows that a pull request is an opportunity for learning and expanding one’s development skills. The net result is an improvement in the ability to craft quality code.

Things to consider​

I want to now list a train of thought that you may consider following as a starting point for developing your own thinking about pull requests.

So, let’s start with the following: I want to ensure my code is of high quality and I want to try and discover something I did not previously know. I’m therefore seeking to take advantage of collective knowledge embedded in my peers and in those that may be more experienced with the code, language, design patterns, algorithms and so on.

Furthermore, I can empathise with what it feels like to be interrupted and how little time we have for the fun part of our job, that is, the actual problem-solving and writing of coding.

Therefore, I need to ensure that my pull request is easy for others to reason about and work with.

Finally, I want to use this opportunity to ask any specific questions to learn and make it simple to iterate over suggested code changes.

Pull request checklist​

What follows is a mental checklist of points to consider before submitting your next pull request.

• The pull request description provides enough context to what the code is supposed to do through the lens of the end-user.
• I have asked specific questions on areas of uncertainty.
• Where I use a non-obvious approach, I have explained why I avoided the obvious approach.
• I have considered splitting up this pull request if I have more than 250 lines of functional code. Ignoring boilerplate/comments/styling.
• The commits in the PR have been squashed to related code changes.
• The code is technically related (cohesive) and focused on a specific feature.

Following, the above will put you well on the way to getting the most out of your pull request and hopefully make you rethink the notion that a pull request is simply a hurdle to getting code into a project.

In a follow-up article, I want to take a dive into GIT and share some techniques for using GIT to craft pull requests that will delight your teammates.

🍺 Happy Coding! 🤘

Before you write GIT on your CV for your next job interview, make sure you know how to use GIT professionally; read on.

If you are here you know that GIT is likely the most popular version control system used in the known universe. If you are a developer looking to get paid GIT is one of your most important tools for doing a professional job.

Any developer can write code. Professional developers know how to organise code changes so that they can be easily reviewed, patched and reasoned about. GIT like other version control systems is the tool that helps us to work professionally.

Unfortunately, there is a disconnect between using GIT and using GIT Professionally.

Here, then is an insight into the GIT skills I and fellow hiring engineers expect you to possess and test for when we read the words "Skills: GIT" on your CV.

GIT basics if you are getting paid.​

Know how to use the GIT from the command line.​

Graphical GIT tools can be great, especially for GIT beginners, but also for professionals when resolving merge conflicts. There are plenty of fantastic dedicated git tools around such "Tower", "Source Tree" and "GitKraken"; IDEs like VSCode even ship with inbuilt GIT support with a nice integrated GUI.

Despite the attractiveness of these tools, there will be a point where you will need to drop down to the raw power afforded by the GIT command line tool. Therefore, there is an expectation that a professional GIT user has the knowledge to use GIT from the command line. Anecdotally, it has been my observation that as developers develop their GIT skills they transition away from GUI tools for all GIT tasks except the resolution of "merge" conflicts.

Use the stash to your advantage​

• Named stashes
• Pop, Clean, List

Merge vs Rebase, clean histories.​

• Know the difference between "merge" and "rebase".
• Ours & Theirs
• Cherry Pick, Patches, Checkouts

Re-Organise commits so your teammates love you.​

• Use GIT to organise and create nice pull requests.
• Squash, Rewrite
• Re-organise with hunks.

Keep the peace, and resolve merge conflicts.​

• When do merge conflicts happen? Three-way merges?
• Have a merge/diff tool.

GIT Warrior​

• GIT autocompletion
• GIT aliases
• Shell Tweaks
• VIM & GIT, the Dream Team

Git Guru & Beyond​

• Porcelain Commands.
• GIT Hooks
• GIT Internals.

While not necessary, you should be capable at a pinch of using GIT from the command line to find help and resolve problems. This will inevitably be required as even the best GUI GIT Clients fall far short of the capabilities afforded by the GIT CLI.

I have noticed that developers that spend a little bit of time using GIT on the command line tend to stop using a dedicated GIT GUI. Mainly because common git operations are faster to execute from a terminal inside the IDE.

Using MFA enabled AWS accounts & CLI​

TD;LR​

Simplify your life when using MFA-enabled accounts with AWS profiles by installing this command-line tool.

Install awsmfa from npm or fork the project on GitHub.

Managing MFA credentials​

Enforcing multi-factor authentication (MFA) on AWS accounts is a security best practice that can provide some usability hurdles for engineers that rely on the SDK and AWS command line tools to get work done.

The typical workflow for working with MFA-enabled accounts is to request a temporary session using the AWS STS service. The STS service will then return a session token which includes temporary credentials as well as a session token. Depending on the use case these data can then be used either in a profile definition, environment variables or as arguments to call AWS Apis that require MFA.

However, it is a complete BITCH of a process.

To strike a balance between security best practices and ease of use it is best to take advantage of some tooling.

There are various tools available to ease this process including awsmfa.

Why, build yet another tool?​

Now, I know that there are several tools available in a range of languages that address the issue of working with MFA-enabled AWS accounts.

However, I specifically needed a tool that we could install using NPM. Furthermore, I wanted flexibility for automation, and my final requirement was the ability to have an interactive mode for humans.

Making up the above wishlist, was my excuse to satisfy my curiosity about the effort required to build a CLI command with Typescript, that could be installed using NPM.

Besides, I love coding and this little project was a fun Friday night accompanied by the awesome Charlotte de Witte.

What problem does it solve?​

The catalyst for the project was the inability to authenticate using an MFA-enabled account when running a project inside of the "Serverless Offline" framework.

I also needed a tool that would work with multiple AWS Accounts, supported a flow reliant on Assuming Roles, that I could further control with Bash and provided the flexibility to prompt for input of an MFA Token. Good Times!

After, a night's mad coding and a morning of debugging I'm happy to share "awsmfa" with you.

The command line tool will authenticate with a profile of your choosing (defaults to "default"), prompt for your MFA token and writes the temporary session back to your "credentials" file under a name of your choosing (defaults to "mfa").

Using a "named" profile has proven to be the most reliable mechanism for authenticating where you are using multiple programming languages, containers, virtual machines and run times.

For more information and installation check awsmfa on npm.js

Happy Coding!

Marcel 😎👍

one more thing ...​

Based on completing this mini project I also made available a boiler plate template that you can use to quickly boot strap a project for building your own NODE CLI command with typescript. That sounds like an Upcoming YouTube Video.

• Command Line Project Template using Typescript
• File Focus VSCode Extension