Have you fallen prey to misconfiguring Nginx?

Ever googled for Nginx configuration? For example, how to redirect

Ever googled for Nginx configuration? For example, how to redirect http://www.example.com to http://example.com? I have, and guess what, most of the top results are wrong or inefficient. All of these are documented in a Pitfalls page on the Nginx wiki. I’m just going to point out the parts of my config I’ve optimized recently with great help from the Nginx wiki.

Redirect from www to non-www

Nginx wiki recommends using return, but the version in Ubuntu 10.04 doesn’t seem to support it, so I use this:

rewrite ^ //nigelb.me$request_uri? permanent;

Static files

Set the Expires and Cache-Control headers with the expires header. Another thing I do is turn off access log for static files.

location ~ ^/(img|js|css)/ {         expires 30d;         access_log off; }

Running PHP with Nginx

Most PHP applications only have an index.php file that needs to be executed, everything else is usually an include.

location ~ index.php$ {         include fastcgi_params;         fastcgi_pass    unix:/tmp/php.socket; }

Remember to place your root directive outside any location block. Then, you can add another route for static files, just so that Nginx can serve them instead of that request going to PHP.

location ^~ /pub/ { }

By no means are these meant to be authoritative, and newer versions of Nginx lets you use try_files instead of some of what I’ve done.

TL;DR: Use the Nginx Wiki. RTFM.

Update: Lyz pointed out that the default config file that come with the CentOS packages on the Nginx website put root inside the location block instead of outside. She’s just helped me verify that and I verified the same problem with the Ubuntu packages from the Nginx website.

Please nitpick

Please don’t rubber-stamp my reviews. Nitpick. Nitpick a lot.

When working with Open Source, some of the best learnings come from code reviews. When I first started coding on projects with strict code reviews Launchpad), I was uncomfortable getting nitpicked. I (wrongly) thought the goal was to have a code review that has absolutely no nitpicks (crazy right?). Whenever someone had a nitpick with my code, I felt like I couldn’t code properly. That’s when I read this excellent mail from Jeroen Vermeulen to the launchpad-dev team:

A rubber-stamp approval can save you minutes or more in the short term, but it does nothing for your longer-term development. A rubber-stamp approval leaves you without proof that the reviewer has read and understood the branch. A rubber-stamp approval sets no performance bar, no communicable standard for reviewers to live up to. A rubber-stamp approval does not tell you whether your branch was excellent, so-so, or too hard to read. A rubber-stamp approval buys you time that you could use towards the self-improvement you’re missing out on, but fails to tell you where you need it most. A rubber-stamp approval deprives you of a chance to harmonize your part of the codebase with our best practices. So I don’t like getting rubber-stamped any more than I like to rubber-stamp others. Good reviews take time, and that’s not time I put in for the sheer fun of it.

It changed my world. I’ve had epic nitpicky code reviews after that. Its even changing how I do my code reviews; I’m warming up to be more nitpicky. Lesson learnt – code reviews are one of the strongest takeaways from open source. So, if you’re reviewing code, please nitpick. Don’t rubber stamp. The professional development of the person whose code you’re reviewing depends on it!

PS: For acceptable levels of nitpick 😉

User Days Poll

User Days were created to be sets of classes offered during a one day period to teach the beginning or intermediate Ubuntu user the basics in order to get them started using Ubuntu. User Days were born out of a discussion at the Ubuntu Developers Summit in November 2009 regarding Ubuntu Open Week not being targeted enough at users. User Days is hosted over the weekend for many hours at a strech so everyone will be able to participate at some point. Open week, however, is hosted during the week at the fixed time-range.

This, however, is now changing. From this cycle on, Ubuntu Open Week will be targeted at users. As the organizers of User Days for the past 4 cycles, we’ve been wondering what the community thinks about this – Should we continue User Days or should we not. Please mark your opinion in a quick poll that I’ve created.

Launchpad bug titles are everywhere!

A while back, I wrote about smart autolinkifying in bugs. Last week, at the urging of Brian Murray, I built on top of the work that I’d already done. This time, it grabs all the bug links and sends to the linkchecker and, in addition to the set of invalid bugs, it also returns a set of valid bugs with bug titles! The after effect is a ‘bug 1245’ link in the body of Launchpad like in bug tracker, merge proposals, etc, where bug 1245 is a valid bug number will have its ‘title’ attribute set to the bug title.

Valid bugs have the 'title' attribute set as bug title and it shows up as a tooltip

Some new improvements to Launchpad

I’ve been hacking on Launchpad for a while now and I’d like to announce some of the new things I’ve added. The first 2 are in production now. The last two, however, will need a few more days to get into production.

Smart autolinkifying in bugs

As evident from the screenshot, it greys out the bug if the bug does not exit (or is private). I wrote in detail about fixing this earlier.

Invalid bugs are greyed out

UTC offset along with timezone

We now go the extra mile and display the UTC offset as well to help in some play plan out meetings, etc.

Timezone also shows UTC offset

Edit sprite for attachments

Long time frustration of mine. The edit URL for attachments is in a portlet on the right side, not easy to spot. Once this fix rolls out, however, it will be much more friendlier.

Edit sprite for attachments

Better blueprints validation

Earlier, I’d just get a ‘… is already registered by another blueprint’, this fix, once rolled out, helps ease out and find that blueprint.

Blueprint validation

To repeat again, the last two fixes are not in production as of me writing this post. Perhaps by next week or the week after, it should be.