01 Aug

How pair programming helped me focus more

I am a big advocate of pair programming as I always feel more productive doing tasks in a pair because it tends to be a Get Things Done kind of attitude. Followings are reasons why I believe pair programming can help you more productive at certain stages

  • The purpose of two programmers sitting on a single workstation is not always to get output greater than output of both individuals but to get the critical work done i.e, setting up your first deployment environment, debugging a rare and critical bug, code merge or code reviews etc
  • If pair consists of a senior developer with a junior developer the follow of knowledge from senior to junior developer really help junior developer to learn. This is what I have experienced while working almost a year with Waqas Farooq he be a Geek and I as new-grad
  • Many a time I have experienced that Unforced Errors like unintentionally making changes to another file, environment variables not loading in production are greatly reduced when a pair sit-down on a single workstation
  • Almost everyone uses social media be it Facebook, Twitter, Reddit, Hacker News etc during work to get some comfort and once your dive into it then it become difficult to get out of this comfort zone. But when you sit together with your fellow programmer the follow of work never stop and social media and other hurdles never come in your way you just keep going until you hit the finish line.
  • Concept of pair programming gets redefined under remote working environment as you are no longer sitting together physically but still you can be on a single workstation by the means of online realtime collaboration tools i.e. screen sharing

I hope my experience would help promoting pair programming culture at your workplace.

Happy Pair Programming :)

20 Sep

Let’s debug nginx, unicorn errors

This tutorial is particularly intended for nginx, unicorn and rails environment. But you can replace unicorn with any Rake web server i.e. puma, thin, passenger etc. which runs behind nginx since they all communicate with nginx through sock files and these sock files most of the time become root cause of errors.

Hold a mug of coffee/tea and let’s debug your configurations.

Before digging into configurations make sure your nginx and unicorn are running properly. For nginx run following command and check nginx process is running or not

ps aux | grep nginx

For unicorn

ps aux | grep unicorn

If either of nginx or unicorn not running, make them run and check if this was all you needed.

Lets now go through with errors

502 Bad Gateway

One of the most common problem in unicorn nginx configurations is 502 bad gateway. Followings are possible reasons of 502 bad gateway

Sock file path

Root cause of 502 bad gateway is no communication between nginx and unicorn through a shared socket which means nginx cannot find sock file on which unicorn is listening on, check your nginx configurations

upstream unicorn_server { 
server unix:/path/to/your/unicorn.sock; 

sock file path in upstream block should exactly match listen sock file path in your unicorn conf file

listen '/path/to/your/unicorn.sock', :backlog => 64

If this is different for your configurations, make them same and restart your nginx and unicorn then check error.

Buffer Size

nginx buffer size could be another reason of bad gateway. Open your nginx log with tail and check whether it’s a buffer size issue

tail -f /var/log/nginx/error.log

Reload your home page and see if you get

upstream sent too big header while reading response header from upstream client 

in your nginx log. If Yes then open your nginx conf /etc/nginx/nginx.conf (default path) and add following to in http block

proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;

restart nginx and reload page and check error

Permission Denied

If you are getting following response


then probably it is a sock file permission denied issue. Root cause of this error is when nginx cannot read unicorn’s sock file (i.e. when your unicorn sock file is owned by a user who has root or higher permissions then the nginx user)

This could be either solved by changing permission of the sock file so that nginx can read it or increase the permissions of nginx so that it can read it (but this is a bad way). Best way is to create your sock file inside /tmp directory and point nginx to the sock file inside /tmp directory ( if you are on fedora then sock file should be in /var/run/ )

Restart nginx and unicorn and check

if your on centos then you can be victim of running nginx as httpd_t or unconfined_t follow Nginx + Rails + Unicorn Permission Error: ‘sudo nginx’ vs ‘sudo service nginx start’ for details.

If you still facing same error please comment below with your nginx and unicorn logs. I will surely reply at earliest.

my mug is finished … Happy Deployment 😉