AWS Cloud python

What I learned by reading the AWS CLI codebase


I’m a big fan of Amazon, specially the Amazon Web Services. In this post I want to share what I learned by reading the AWS CLI code base. For those of you not familiar with those acronyms, it stands for Amazon Web Services Command Line Interface. AWS CLI allows you to manage your AWS services through a command line interface. You can download the cli at If you are using windows, there is an installer available. If you are using Mac or Linux, you can install it with pip by running this command

pip install awscli

After installing and configuring it, you can use the different services available to manage your resources. For example to list all of my s3 buckets, I can run this command, “aws s3 ls”. See the picture below to see the results.

aws cli

Now that you know more about the aws cli, let’s dive into the code base. The project is hosted at github and you can read the code at It is written in Python. It has unit, functional, and integration tests. It has an extensive set of examples on how to run commands.

The code is integrated with travis ci and it is tested against 4 versions of Python. The code runs against 2.6, 2.7, 3.3, and 3.4 versions. This file also run the installation script and tests scripts.

There is also a CLI Dev Version section on the home page of the project. It gives you enough information to setup your project and start contributing back to the project.

And finally, the project has documentation available. I hope this posts give you a brief introduction to Amazon Web Services Command Line Interface’s code base.

code review Javascript python ruby

Improving your code reviews

codestyleCode reviews are an essential practice in any software development team. It allows you to keep your code consistent. It also allows other developers to become familiar with your code changes. Embracing code reviews helps keep your code base healthy.

To improve your code review process, you can do the following:

  1. Document your code style
  2. Allow more than 1 developer to perform the code review
  3. Keep your code changes small

Document your code style

If you don’t document your code style guideline, it is very difficult to keep your code consistent. Some developers might use 2 spaces to indent, others might use 4 spaces to indent. If you have a code style guideline available to all developers, it is easy to enforce it. In addition to be enforced, it is easy for programmers to follow it. You don’t have to open up different files to see the current style guide. You should go to the official style guide for your team or company.

The Python community has documented their code style guide. They created a code style guide under PEP8. One of those conventions is to use 4 spaces per indentation level.

Google has a Javascript style guide. One of the conventions found in the Javascript guide is to always use the keyword var to define variables. Another convention in that document is to always use semicolons.

The Ruby community has also created a style guide. It is hosted at Github and you can see the source here. In contrast to the Python community, they prefer to indent with 2 spaces. See the following example taken from their style guide:

# bad - four spaces
def some_method

# good
def some_method

As you can see from these examples, there are code styles available to help us start with our own documentation. If your team does not have their own style guide, then you can at least document that you will follow Google’s Javascript style guide for example.

Allow more than 1 developer to do the code review

After you have your style guide in place, it is very easy to perform code reviews. It is very important that more than 1 developer in your team can review code changes. Sometimes the team lead might be busy or not available and you don’t want your team waiting on that person. They can go to another developer to do the code review. I believe this is a big problem with a lot of open source projects. Some of these popular projects have few developers in charge of the code reviews and many times the pull requests are not handle in a timely manner.

Keep your code changes small

It is easier to code review 1 or 2 files than to review 20 files. If you have a large number of files, the code review takes a very long time to complete. It is recommended to keep your code changes small. For example, if you have database, business logic, and HTML changes, you can break those changes into 2 or 3 code reviews.


If your team performs code reviews in a daily basis, your code base will stay consistent and hopefully bug-free. Based on my experience as a software developer, having a code style guideline, rotating the person performing the code review, and keeping your code changes small, will allow your code review process to be fun and enjoyable.

code open source python

My first contribution to the Python language

contributing to python

Python is an object-oriented language created in the early 90’s by Guido van Rossum. It is used by major corporations like Google, Dropbox, Mozilla, Ebay, Paypal and many others. Since Python is an open source language, contributions from the public are encourage and welcomed.

For the last few weeks, I decided to install it on my machines and start reading the documentation. Python’s documentation is well written and easy to follow. The first thing I did was to start reading the PEP files. PEP stands for Python Enhancement Proposals. These documents are text files submitted by the community to enhance the language. One of the most popular PEP is PEP 8 which is the style guide for Python code.

When I started reading PEP 3, there was a broken link. I tested this issue with different browsers and I was always getting a 404 error. So I decided to email the python development group. Within a few hours, I got a response from Victor that indeed PEP 3 had a broken link and he gave me the correct link. I was in the process of creating a new bug and submit a patch but a core developer was able to update the link.


Based on the positive response and support I received from the python contributors, I plan to keep contributing to the python code. If you want to start contributing to Python, go to the developer’s guide to get familiar with the documentation and source code.