On being in a leadership position

Andreas Heigl invited me to write an article http://24daysindecember.net where 24 people from the PHP world share thoughts with others in the community.

It was hard to find a topic having the amazing articles were posted already. So I thought to try to help people (Engineers) who moved to a management/leadership position.

So here it is:
On being in a leadership position


Some thoughts about code reviews

I want to tell you about the most important process we have in our team: Peer Code Review.

Code review is not just a process, it's a culture thing. As developers we should be willing to do it. Even if it's not to a peer, you should be reviewing Open Source Project's code, you will learn a lot.

I will write more in depth about how we should be doing code reviews in a future post, but now I'm going to talk about it's purpose, about the why:

  • It raises code quality, enforcing readibility, efficiency (through engineering) and maintanability.
  • It minimizes bugs. More people looking at the same code will minimize bugs pushed to production.
  • It encourages a feedback culture. All code should be reviewed, no matter what, no matter who wrote it. This helps us to grow and to create a constructive feedback culture.
  • It disperses knowledge through the whole team, raising the bus factor. At least two people understand the code.
I found out that code reviews are the most effective technique for team building. It empowers developers to do their best on each iteration and push the team as a whole to the next level.

Let's get back to the purpose of this post, what rules I learned from code reviews:

This is not a rule, but a state of mind:

Don't be an ass.

Having your code reviewed.

  1. Don't take it personally. This is about the code, not you.
  2. Embrace change.
  3. Be proud of your code.
  4. Push small. Small amount of code is easier to review than big full blown modules. Help the reviewer.
  5. Give context and why and what. Tell people why you decided to do something and, more important, explain the context of that decission. The documenation is very important for this. Document your code, explain the purposes of the modules / classes so it's easy for everybody to understand.
  6. Get context from the reviewer, understand the why and the what.
  7. Write good commit messages. Commit messages matter. Part of our job as engineers is to take the time to write good commit messages. It's not for us, it's for the future of the project. Take time and do it the right way. 

If you are the reviewer.

  1. Be respectful and have patience. (go and check the first rule). 
  2. Give recommendations (think of the goal).
  3. Ask questions, don't make demands.
  4. You can make it different... but... there are many ways to do the same thing.
  5. This is not a "Why" session. If you need to ask why, ask for context first. 
  6. Don't make people wait for you. Code reviews are very important, schedule time for code reviews.
  7. Take your time. Block at least one hour of your time to do it. This is important for the team, so take your time and do it the right way. 
  8. Approve the Pull Request! (or not). 

  • http://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/
  • http://chris.beams.io/posts/git-commit/


Cookie Based API login using Guzzle

We've all used curl to consume external services - scraping, APIs, etc. We know that curl is awesome, but there is that feeling that you should be doing this in a more abstract way, or using something not too hardcore.

Yesterday, I had to connect to an external API using cookie based authentication. I initially thought of doing it with curl, but I remembered Guzzle, and wanted to give it a try.

Hello Guzzle
Guzzle is a PHP HTTP client that makes it easy to send HTTP requests and trivial to integrate with web services. 
In pseudocode:
  • create a guzzle client
  • create a cookie 
  • login and update that cookie
  • use that cookie for next requests
Here is an example:

1:  // Create a Client   
2:  $client = new \GuzzleHttp\Client\Client([  
3:    'base_url' => 'http://someserver.com',  
4:    'defaults' => [  
5:      'headers' => [  
6:        'Accept' => 'application/json'  
7:      ]  
8:    ]  
9:  ]);  
11:  // Create a new cookie  
12:  $cookieJar = new \GuzzleHttp\Cookie\CookieJar();  
14:  // Send a post  
15:  $request = $client->createRequest('POST', '/api/login', [  
16:    'cookies' => $cookieJar,  
17:    'body' => [  
18:      'UserName' => 'USERNAME',  
19:      'Password' => 'PASSWORD',  
21:    ]  
22:  ]);  
24:  // ....  
26:  // Reuse the cookie for next requests  
27:  $response = $client->get('/api/user', [  
28:    'cookies' => $cookieJar  
29:  ]);  

You can store the cookie in a shared session so that you don't need to login each time you do a request.


  • Fetching a URL with Cookies using curl: http://docstore.mik.ua/orelly/webprog/pcook/ch11_04.htm


Better commits with GIT - Different email addresses for different respositories

When people start using GIT, usually they signup in a service like github.com or bitbucket.org. To do so, they use their personal or business email accounts and then configure git clients accordingly with this.

The first thing you do when you start using GIT is to configure some basic variables in the GIT global environment. In other words, you setup your name and email address for all the projects you are going to work from now on.

This is how you do it unsing your terminal:

$ git config --global user.name "YOUR NAME"
$ git config --global user.email "YOUR EMAIL ADDRESS"

What does this means? Each time you do a commit, it will be signed with that information because it was configured in the global space.

This is good, right? Well it is, but if you are doing work stuff you should be signing your commits with your job's email, if you are doing personal stuff you should be using your personal information, or at least that's what I think.

To check those settings run this in your terminal:

$ git config --list

It's important to understand that GIT allows you to specify an email address on a per repository basis. Let's see how we do this.

Setting up your identity per repository.

The --global option will make this configuration visible to all the projects by default. You can override this setting project by project (if you are not doing it, you should).

If you use a graphical interface for your GIT repositories as Source Tree you can do it in the Settings -> Advanced Tab window, un-click "Use global user settings" and write down your information.

If you use a terminal, you can do this from your respository folder:

$ git config user.name "YOUR NAME"
$ git config user.email "YOUR EMAIL ADDRESS"

This information is stored in a .gitconfig file in your drive in the project folder. 

So double check this before starting a new project.

$ git config --list
user.name=Diego Sapriza

reviewd by @jorgesierra


Creating animated Gifs from image files in Mac OS X (or Linux)

I was trying to create an animated gif from a bunch of images. My first reaction was to google something like: "create animated gif Mac OS X", but then I realize that I'm using a unix box, so lets do it the "simple" way with ImageMagick.

From its site:
ImageMagick® is a software suite to create, edit, compose, or convert bitmap images. It can read and write images in a variety of formats (over 100) including DPX, EXR, GIF, JPEG, JPEG-2000, PDF, PNG, Postscript, SVG, and TIFF. Use ImageMagick to resize, flip, mirror, rotate, distort, shear and transform images, adjust image colors, apply various special effects, or draw text, lines, polygons, ellipses and Bézier curves.

I used ImageMagick a lot through PHP. Its pretty straightforward and very fast.

Let's install it using brew:

~ brew install imagemagick 

Open your terminal, junp to the directory containing the images and run this command:

~ convert -delay 10 *.JPG animated_output.gif

This will generate animated_output.gif with a delay between frames of 0.10s

This is the result:

Related links: