Logging the caller

It’s so useful to automagically log caller line number and so on. Most languages make it possible via hack involving throwing an exception to yield a stack trace. Some languages explicitly provide this info. In Ruby, it’s possible with the caller array.

Here’s how I used it just now:

  1. def logg
  2.   caller_info = caller[0].gsub! /^.+\/(.*)\.rb:(.*):in `(.*)'/, '\\2:\\3:\\2'
  3.   Rails.logger.debug "[#{caller_info}] - #{id}. Thread#{Thread.current.object_id.to_s(36)}"
  4. end

This will output caller_info in the format: [series_feed:fetch:123]. Which is the file:method:line_number. It’s derived, via the initial regex, from the slightly less log-friendly caller string, path/to/series_feed.rb:123:infetch’.

A Bash Logging Utility

With a long-running script, it’s convenient to see checkpoint log messages indicating what stage it’s at and how long it’s taken.

Most scripts simply run date to show the boring long date format: Fri Mar 29 21:07:39 MST 2002. Info overload! You don’t want to know what month it is, whether you’re in the middle of a weekend, or what timezone you’re in! More to the point, you want to know how much time has elapsed, not what time it is now; you want to know the script’s age.

So here’s a little utility to make it easy. Just call “age” and it will output time since the script began in 00:00:00 format.

I also made another function “announce” which you can use to announce the current function is running. With larger bash scripts, I tend to break them into functions with a list of calls at the bottom; so I can quickly bypass unnecessary crunching by commenting out the call. “announce” makes it easy to see which is running. And if you wanted, you could easily automate announcing for each function…making aspect-oriented Bash the place to be.

Advanced Feature Wishlist for Ajax Frameworks

Looking at the best practice/process patterns gave me some ideas for Ajax frameworks. Here’s a few thoughts. I know some frameworks already do some of these things, though most don’t, and none do all of them.

Logging frameworks should provide a sensible default, ie log to a div, but allow for more flexiblity on the logging strategy, as in log4j. For example, it would be nice to hook into a local storage solution like AMASS. I know we can all “spy on users”, but a local storage solution lets you amass lots more data, helps solve some privacy issues, and will survive network problems … could even help restore lots data. I’m obviously thinking more of intranets than public internet apps.

Mock object frameworks should, um ,exist. As I mentioned last week, there’s definitely a good case for a JS mock object library like JMock.

Web Remoting frameworks should:

  • Provide a high-level, technology-free, interface, and then implement it in as many ways necessary to support the greatest amount of browsers possible. Gloves off – IFrames, Images, Stylesheets … whatever works.
  • Make access to 3rd-party domains virtually transparent. e.g. CPaint does this by allowing a proxy option, which points to a proxy running on your server. That aside, calls are same as normal.
  • Support simulation. Let a caller prep the remoting framework with the response it should provide to a given query. Testing in that way, I could see very little reason to ever go back to the real server if you could do this.
  • Support logging. Rather flabbergasted that I couldn’t find a framework that supports logging of remote calls. The new Network Sniffing pattern describes other tricks for logging browser-server traffic, but the JS remoting frameworks ought to take care of it.
  • Support mocking. In addition to prepping with the response, the caller should be able to say “throw an exception if you don’t get this query”. Note that this wouldn’t need to be the responsibility of the remoting framework if there was a general-purpose mocking framework available.

8 New Ajax Patterns (Diagnosis and Testing)

Cool! The Best Practices/Processes Patterns are now complete. They are the final eight Ajax Patterns for now – “final” in the sense of “the list is not yet finalised”. The patterns had been sitting there unattended for about four months now.

More details on the new patterns later, but here’s a quick summary …

First, there’s a new demo – the Ajax Patterns Reader – the best version to try is at http://ajaxify.com/run/reader/logging/realService/. The reader grabs the AjaxPatterns.org content and presents them Ajax-style. You actually queue up patterns in a playlist and click “Next” to “play” them. Yeah, a bit contrived, but it helped illustrate quite a few patterns! If I have time, I’d like to enhance it into a proper reader, and also offer an easy interface to leave feedback, which would be automatically appended to the wiki’s Discussion tab for that pattern.

BTW This further refactoring of the Ajax Patterns Reader illustrates the Scriptaculous GhostTrain tool. If you haven’t seen GhostTrain, have a look – the Javascript will track your activity and build up a test case dynamically (covered in the new System Test pattern). All within the browser. I’ve been in contact with the developers (Thomas and Jon), and discovered it’s still proof-of-concept, but if they can tie it all together, it will be an excellent way to create a system/functional test.

Next, there’s four patterns on diagnosis:

And finally, four patterns on testing:
  • Simulation Service Develop the browser application against “fake” web services that simulate the actual services used in production.
  • Browser-Side Test Create automated tests of browser-side Javascript components.
  • Service Test Build up automated tests of web services, using HTTP clients to interact with the server as the browser normally would.
  • System Test Build automated tests to simulate user behaviour and verify the results.