Category: programming

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

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.

Posted on

Cross-training the mind

Back in my high school years, I was an avid mountain biker. Sure, two cycling buddies and I would go riding after school, during weekends, etc, but “avid” more in the sense that we’d thoroughly consume every cycling magazine that would grace the shelves of the school library.

One of the articles I remember very clearly till this day had to do with the way professional cyclist train. One of the vital muscle groups that they aim to strengthen is the abdominal muscles. Apparently (and sensibly), it’s one of those muscle groups that greatly affects the performance of a cyclist, but isn’t actively strengthened in the act cycling. Therefore they would put themselves through a range of off-bike regimes in order to develop those muscles. Cross training, basically.

I can’t help but extrapolate that to the way I engage my programming craft. Given the abundance of introductory tutorials to various programming languages on the Internet, I’d spent many a weekend picking a new language or framework, working through a tutorial, and expose myself to the thinking behind it.

These days, while I code primarily in PHP against an enterprise-y object-oriented MVC framework, I find myself slipping in the occasional functional declaration, or borrowing an enumerator idiom from a different language. Things that I would’ve never done if I simply remained in PHP land.

So onward with my quest for more diverse cross-training, I had a go at Gödel, Escher, Bach: an Eternal Golden Braid. Today, after failing miserably at explaining it to a fellow nerdhead (she’s an econometricist), I figured I’d give it a rest and pick something a little easier – A Beginners Guide to Graph Theory 2e.

Armed with my new Kindle DX (be-earlied birthday present from the wifey), and a stack of PDF’s I’ve acquired over the years, I’m now 10 pages into an introduction about sets and digraphs.

Wish me luck.

Posted on

Symfony2 ContainerAware Callback Validation

Today I had a big win at work.

We’re building an SOA platform for the business, so different bits of data end up sitting on different services, contactable only via a RESTful API.

One of the roadblocks we hit was validating some Service B data entered into Service A. Symfony2’s built in validators do a great job when everything is available on the same box, in the same database, but falls completely flat when it needs to validate outside a service boundary.

So I figured out how to inject a DI container into a Callback validator on Service A, and proceeded to summon some other validator services that would query the existence of a particular resource entity residing on Service B via HTTP.

It’s late now, but I’ll share the code when I get a little more time. Leave a comment if you’re really desperate to find out how it was done.