Category: developer

Posted on

HTTP logs in RESTful SOA

The RESTful SOA system that we’re building is turning out to be a bit of a beast. We’re approaching a point where there are lots of inter-service chatter going on, and because there are so many independent moving parts in play, it is hard to keep track of where things are ‘crapping’ up.

This is where apache/nginx server logs and HTTP status codes have come into their own.

While performance takes a big hit when inter-service communication is done over HTTP, it comes with some advantages. The HTTP gap we’ve wedged in between services has allowed us to debug and interact with services individually. It has also given us a far more visibility on how our services are responding to each other, and to user requests.

With our services, we’ve worked very hard to adhere closely with standard HTTP status codes – e.g. 403 Unauthorized, 404 Resource not found, 400 Bad Request, etc.

In the past week, it seems our diligence has started to pay off because we’ve been able to quickly diagnose issues by simply tail-ing the HTTP logs files, watching the URL requests and tracking the status codes. This has helped us narrow the scope of concern very quickly and zero in on the source of a problem.

Posted on

Vocalizing compliments

Here’s something that I’ve been learning and experimenting with since I started working in and amongst a team of software developers. While the principle isn’t limited to software development teams, it comes up quite obviously because of the measurable nature of the work that we do.

Take every opportunity to celebrate and compliment good work.

Opportunities to diss incompetance are a dime a dozen. Instances where good work peeks it’s little head out and waves timidly are few and far between. Times when one genuinely identifies and appreciates good work are even rarer. (Pretentious shoe polishers need not apply)

The compliment needn’t be overcomplicated or elaborate. Just make a statement about what you appreciate. Some examples:

“Dude, that component you put works really well.”
“Jimmy, really love the docs you wrote on that library.”
“Hey Bill, you gotta see what Steve just did. It’s freakin’ cool.”

With software, no one wins for being vague and kind: a defect is a defect, and git commit messages never lie. But a seized opportunity to praise good work is a beautiful thing.

Posted on

Deploying a webapp? subdomain it

I’ve been migrating domains from an old server to a new one that we’ve just acquired. Some were really straightforward standalone CMS setups, so a tar xcf and an scp followed by a mysqldump and a mysql < database.sql sufficed.

But there were ones that had multiple webapps running off the same domain. I had a Piwik installation on http://example.com/analytics, then a random dokuwiki setup running at http://example.com/wiki. While it’s all too easy to simply create a subfolder and dump the files in, a setup like this makes incremental migration very difficult. When you cut over the DNS records for the domain from an old IP to a new IP, everything needs to work at the first try.

A better way is to have each webapp run in a seperate subdomain. Instead of http://example.com/analytics, set it up at http://analytics.example.com/. Instead of http://example.com/wiki, set it up as http://wiki.example.com/. Sure it’s a few extra steps when setting up, but  decoupling your webapps is good practice.

When it’s time to move one of the webapps to its own server, or migrate your domain incrementally, you can simply copy over all the files for that one webapp, repopulate the database tables, do a test run using your HOSTS file, then flip the switch at your DNS server when you’re ready. The big win? Everything else on http://example.com/ continues to hum along swimmingly.

Posted on

My TDD addiction

After over two months of deliberately attempting to adhere to the practice of Test-driven development (TDD), I started working on a sizable chunk of untested code. Here are some of my reflections on the contrast between tested and untested code.

TDD is an arduous process. When you’re coding up a solution, not only do you need to figure out what code needs to do, you are also forced to componentize the solution in a way that is unit testable, if only to make the test writing easier. This is especially annoying when you’re working on procedural functionality that doesn’t decompose naturally. This forced decomposition has its benefits, though, as it “encourages” one to produce simpler and more understandable code.

One of the other luxuries afforded by having tests is how easy it is to hand over code from one developer to the next. The test suite provides a very quick and comprehensive way to verify that existing functionality is not broken without the new developer having to be across the board with the codebase. Speaking of verifying functionality, the scaffolding provided by our test suite has allowed us to execute and complete major code refactorings in very little time.

But back to my experience with the untested piece of code. I couldn’t help feeling a sense of trepidation as I worked my way through. Maybe it was because it was unfamiliar territory for me. Perhaps it was because there was no way of me verifying that I hadn’t stuffed anything up without first fully understanding what it does.

But one thing is for sure, the last two odd months have made me very dependent on tests. Addicted even; which makes me wonder if that is a good thing.

Posted on

Taming Symfony 2 projects with VIM

Over the last few days of Symfony 2 training, my vim-ing has endured a severe whipping from the likes of NetBeans and other full-fledged IDE’s. It didn’t help that the trainer was doing all his code examples in NetBeans. I shuddered everytime we did a namespace or use statement. Symfony 2 takes full advantage of the PHP 5.3 namespace feature, so with all the classes organized hierarchically, the average class ends up being about 5 levels deep.

So last night, I thought I’d try out NetBeans to see if I could use it. To my delight, there was also a plugin called jVi that allows me to use vim keybindings. After 10 minutes of messing around, I just couldn’t do it.

Traversing the project tree required reaching for the mouse. jVi refused to work because of some bug in NetBeans 7.1, and the line-number fonts were hardcoded ugly. Finally, as I was doing a lot of my work on a virtual machine over a samba share, NetBeans was struggling to index all the files for auto-completion and class/method name lookups.

Fine, I thought, surely there must be something I could use in vim.

After poking around a little, I discovered exuberant-ctags + FuzzyFinder + SuperTab.

Broadly speaking, this is how it works.

1. You run something like ctags --recurse --h *.php in the root of your project. ctags scans all your *.php files and generates a file in the root of your project tree called tags.

2. When you use the :FufTag command in vim (provided by FuzzyFinder), it uses the generated tags to find a class or method definitions that match your query.

3. When you type ctrl-] (also by FuzzyFinder) with your text cursor on a class or method name, you’re able to jump straight the definition of that class or method.

4. Finally, with SuperTab enabled, you can hit tab while you’re coding, and it will pull up auto-complete options based on the tags file generated by ctags.

Can’t wait to try it out at work today.