Month: March 2007

Categories
Uncategorized

O’Reilly Short Cuts

I’ve now purchased a couple of short cuts from O’Reilly: RJS Templates for Rails and Schematron. At $9.99 a pop, they seem to be pretty good value for money (especially with the current GBP to USD rate). Each one is around 50 pages, which is a concise enough to be a good introduction to a particular topic without going overboard.

They have a couple of (minor) faults. The biggest is that the PDFs don’t look that good in Preview.app, forcing me to install Adobe Reader. I haven’t looked into why it’s so bad yet. The other reason is the lack of chapter breaks. The books feel like one continuous block of text (aka a Terry Pratchett novel).

I did notice one or two typos in the Schematron book, but I’ve reported them and hopefully, the PDF can just be regenerated. Yay ebooks!

As to the topics covered, both RJS and Schematron are subjects which are too small to be covered by a full book (200+ pages) yet deserve more attention than a single web article might give it. They’re ideal for this format.

Overall, I’m pretty pleased with these. I’ll likely be going back for more.

Categories
Uncategorized

Coding Dojo Tonight

Tonight was the latest Coding Dojo. We were picking up the mantle from the previous time. This evening was peculiarly intense, thanks to Piers dropping in.

Despite not completing the task (as per usual!), I learned an enourmous amount from the interaction this evening. It felt really humbling to be amongst people who knew so clearly what they were trying to achieve. Chatting to Piers afterwards made me realise how I tend to be very focussed on solving the problem at hand rather than stepping back and trying to create something beautiful. I need to go back and read TDD and Refactoring…

On another note, I’m really looking forward to the festival dojo. It’s the 10th of May. Come and join us.

Categories
Uncategorized

XQuery Redux

I spent four days last week on a training course, most of which consisted of learning XQuery. I’m a lot happier with it now that I was a couple of months ago. In particular,

  • OxygenXML or Stylus Studio are pretty good IDEs. A little cluttered, but an improvement over vim & Emacs.
  • XQuery 1.0 is now out.
    • It’s a minor shame that the product I’m using doesn’t support it fully yet, but that’s just a matter of time.
  • I’ve come to term with the type system. I’ve worked out where it can help me more than hinder me. I continue to be shocked when I return the wrong kind of element from a function and get a type error. Dunno why, it’s doing the right thing, but it still surprises me.
  • I ♥ XPath. It just rocks in so many ways.
    • Heh, James Clark was the editor. That explains a lot.

Overall, this is good news, especially given the fact that I’m embarking on a large project that’s utterly dependent on XQuery.

On the downside,

  • XML namespaces suck. You can tell this is true, when in a room where 5 developers have been involved with XML and namespaces for over 5 years each, and they still don’t get it.
  • The implementation defined areas still loom quite large.
    • I suspect that this isn’t really a big issue in practice, though. You’re not likely to be swapping out XQuery implementations with any frequency.
  • I still despise the smileys-for-comments.

Anyway, if you’re playing around with XML in any seriousness, it’s probably worth checking out XQuery. It’s surprisingly useful.

Categories
Uncategorized

Pro JavaScript Techniques

I’ve just finished Pro JavaScript Techniques by John Resig (author of jQuery). It lives up to the name. If you’re a beginner with JavaScript, then look elsewhere. But if you’ve done a little bit before, then this is the book for taking you to the next level.

From the very start, it pulls no punches. It dives right in to talking about Object Oriented JavaScript, a major source of confusion for people arriving from conventional, class-based OO languages. But even in the first few pages, there is already mention of things like firebug, JSAN and Unobtrusive JavaScript. It’s not just the language, the environment and development tools are described. And it’s all bang up to date.

I really appreciate the way that (throughout the book), John will show you how to do something, but then a library which does the same thing (but without the bugs you will inevitably introduce). It’s the best of both worlds: giving you the understanding of what’s going on, but also the ability to use that knowledge quickly.

Further on in part 3, the DOM is described in exacting detail. Yet it’s still succint. Walking through the usual suspect (document.getElementById(), document.getElementsByTagName()), he also goes on to talk about using CSS Selectors and XPath (using external libraries). This is a good example of taking you a step further than most of the other documentation I’ve seen.

Whilst all this is going on, a small library of utillity functions is building up from the examples. Many of these functions are used in later examples. This is something to be aware of if you open the book at random. But, the routines are very likely something you will want to reuse in your own work, so I don’t begrudge this at all.

The chapter on events was a real shocker to me. I thought I had a handle on how events worked in JavaScript, until I read the “Event Phases” section. In particular, I didn’t realise the sequence of events when moving a mouse over nested tags. It’s a small matter, but another example of the accuracy of this book.

Further chapters go on to discuss CSS integration, enhancing forms, and Ajax. There are also practical chapters where you build an image gallery (similiar to lightbox), enhance a blog, build an autocomplete for a text field. These culminate in an Ajax wiki. I have to admit, I haven’t tried the code for that yet. But the design decisions seem clearly explained. I’m not 100% sure on the Ruby code I saw, but that’s a minor matter, as it’s not the books primary focus.

Personally, the chapter on enhancing forms was of the most practical value to the work I do. It was neat, self-contained and immediately usable.

The final chapter is an exploration of the future of JavaScript. John explores JavaScript 1.6 and 1.7 (available now in Firefox), Web Applications 1.0, Comet) and what neat things they will bring.

There are three useful appendices: A DOM reference, an events reference and a brief browser overview. I can easily see myself going back to the first two a great deal.

What negative points are there? Not many. The index seemed a little sparse. In particular, the functions that are developed along the way aren’t in there.

I have no complaints at all about the quality of the writing. It’s all clear and eminently readable. Unsurprisingly, this applies to the code as well as the prose.

Overall, this books gets a big thumbs up from me. I’ll be coming back to it regularly. And I will be nudging work to get a copy as well.

Categories
Uncategorized

SVK / gettext Issues

Anybody seen this problem?

  % svk co //local/typo typo.new
  Syncing //local/typo(/local/typo) in /local/home/dom/public_html/typo.new to 1201.
  zsh: abort (core dumped)  svk co //local/typo typo.new

Thankfully, I can get a sensible stack trace out of it.

  (gdb) bt
  #0  0x2826febf in kill () from /lib/libc.so.6
  #1  0x2826fe5c in raise () from /lib/libc.so.6
  #2  0x2826eb6c in abort () from /lib/libc.so.6
  #3  0x2860fc0b in libintl_recursive_lock_init () from /usr/local/lib/libintl.so.8
  #4  0x2860fc79 in libintl_recursive_lock_lock () from /usr/local/lib/libintl.so.8
  #5  0x2860b6b3 in _nl_load_domain () from /usr/local/lib/libintl.so.8
  #6  0x2860b617 in _nl_find_domain () from /usr/local/lib/libintl.so.8
  #7  0x2860e940 in libintl_dcigettext () from /usr/local/lib/libintl.so.8
  #8  0x2860b37b in libintl_dcgettext () from /usr/local/lib/libintl.so.8
  #9  0x2860b3a0 in libintl_dgettext () from /usr/local/lib/libintl.so.8
  #10 0x28633353 in not_found () from /usr/local/lib/libsvn_fs_fs-1.so.0
  #11 0x2863468b in open_path () from /usr/local/lib/libsvn_fs_fs-1.so.0
  #12 0x28634701 in get_dag () from /usr/local/lib/libsvn_fs_fs-1.so.0
  #13 0x286349ff in fs_node_id () from /usr/local/lib/libsvn_fs_fs-1.so.0
  #14 0x28634a71 in svn_fs_fs__check_path () from /usr/local/lib/libsvn_fs_fs-1.so.0
  #15 0x28322cc5 in svn_fs_check_path () from /usr/local/lib/libsvn_fs-1.so.0
  #16 0x289785e1 in _wrap_svn_fs_check_path (cv=0x87d8dcc) at svn_fs.c:3847
  #17 0x280f6274 in Perl_pp_entersub () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
  #18 0x280ef259 in Perl_runops_standard () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
  #19 0x2809ec3e in perl_run () from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
  #20 0x08048fe2 in main ()

I’m guessing that this is gettext related, yet I’ve rebuilt both gettext and subversion to no avail. Drat. This is all on FreeBSD, BTW.

Aha! An insight! This works:

  % LC_ALL=C svk co //local/typo typo.new
  Syncing //local/typo(/local/typo) in /local/home/dom/public_html/typo.new to 1201.
  A   typo.new/test
  A   typo.new/test/unit
  …

Weird and annoying. But at least I can work around that now…

Categories
Uncategorized

Regex Readability

Piers describes a foul abuse of programming. I’m totally with him on this one. People should just learn to use regexes—they’re an enormously powerful tool for pulling apart strings. And they’re not difficult. Unless of course, you’re of the “Java is the one true language and I must know nothing else” school of programming. Don’t laugh, there are people like that.

But the second crime, which Piers fails to point out is parsing XML with a regex. There are so many ways in which this will blow up in your face. Really. What about character encodings? Attribute order? Entities? Even unexpected tag order would blow up most XML regexes I’ve seen. Don’t do it, folks, you’re just setting yourself up for a fall.

Update: Dave and Piers both correctly point out in the comments that I misread the original article. Piers does in fact state that parsing XML is “one of the canonical no nos”. Mea Culpa. I still agree with everything he says.

Categories
Uncategorized

TextMate book

Last week, a copy of TextMate: Power Editing for the Mac landed on my desk. TextMate has been a part of my life for about a year now. I can’t be doing without it (“Edit in TextMate” is worth the price of entry alone). I consider myself a reasonably advanced user.

Boy, was I wrong. From the very beginning of the book, I was getting something new off of each page. Not necessarily earth shattering, but a drip, drip, drip of new knowledge about textmate and how it works. By the end of the chapters on Editing, I felt hugely more confident about using the abilities of TextMate to the full.

The book is split into three main sections: Editing, Automations and Languages. Editing is well, editing. Do it hard, do it fast. The Automations section takes you to the next level, and lets you customize TextMate to your own unique workflow. From the simple snippet to the do-anything command, it really shows you how to take control.

What I particularly love about TextMate is that unlike vim or Emacs, it doesn’t have an extension language. Instead, you get to use Ruby, or Perl, or /bin/sh. You could use PHP if you prefer. In many ways it feels far more “Unixy” than either vi or Emacs. In fact, it’s much more like sam.

The final section, Languages, should rarely be needed. TextMate comes with builtin support plenty of languages (and many more are available). But when you need it, you really need it. James Gray manages to walk through the process of adding a simple language (JSON) in a very effective manner, showing you what’s possible in a succinct manner.

In fact, succinctness is present throughout this book. The text is clear and informative, never taking too long to explain, but not leaving you confused either. And at 200 pages, it’s nice slim tome. You could get through it in a couple of hours, but don’t worry—you’ll be coming back to it.

If you edit text on the Mac, do yourself a favour and get this book.

Categories
Uncategorized

Geekvertising

I’ve fairly recently gotten turned on to my local library. They have graphic novels. Lots of graphic novels. Yum. This is good, because it helps limit my expenditure on such things. So I’ve been going through them at a rate of knots.

When I’m reading, I tend to use business cards as bookmarks. $WORK purchased several hundred of them for me a while back. I have no idea why, as I only get to go see clients about twice a year. But they do make good bookmarks.

I was amused, however, to hear from a friend of my partner that her partner in turn had borrowed a book from the library and my card had dropped out of it. Now that’s geek advertising!

Categories
Uncategorized

TextMate tip

I had an interesting little run-in with TextMate today. I’ve just been turned on (finally) to the lovely TODO bundle. However, it was producing very spurious results and taking a long time to do so.

Tracking it down wasn’t too hard, as it turned out. Just a few print statements in the TODO bundle did the trick. But the answer surprised me.

It turns out that when you have a project open in TextMate, it keeps a TM_PROJECT_DIRECTORY environment variable pointed at the directory you’ve got open in there. With just one folder open in that project, it’s got the same value as the folder. The TODO bundle searches everything in $TM_PROJECT_DIRECTORY. Nice and simple.

But, when you have two directories open in the project then $TM_PROJECT_DIRECTORY gets set to the highest common directory. In my case I had /Users/dom/work/project1 and /Users/dom/work/project2 open in the same TextMate project, so $TM_PROJECT_DIRECTORY was being set to /Users/dom/work. Now there’s a lot of stuff in there. No wonder it was taking a long time.

So, be warned. Stick to single folders in a project if you want to use the TODO bundle.

Categories
Uncategorized

Experiments in metaprogramming

I’m having a go at metaprogramming in ruby. It started out simply enough. I wanted a module which had some custom assert methods in. Here’s the test:

  def test_matches
    assert_stderr_matches(/foo/) do
      warn "foo"
    end
  end

And here are the custom assert methods.

  module AssertStderr
    def assert_stderr_matches(regex, message=nil)
      old_stderr = $stderr
      $stderr = StringIO.new
      yield
      assert_match(regex, $stderr.string, message)
    ensure
      $stderr = old_stderr
    end

    def assert_stderr_empty(message=nil)
      # More-or-less identical.
    end
  end

Two methods, the bulk of which is similar. Yuck. Refactoring time.

  module AssertStderr
    def assert_stderr_matches(regex, message=nil, &block)
      assert_match(regex, capturing_stderr(block), message)
    end

    def assert_stderr_empty(message=nil, &block)
      assert_equal("", capturing_stderr(block))
    end

    def capturing_stderr(block)
      old_stderr = $stderr
      $stderr = StringIO.new
      block.call
      return $stderr.string
    ensure
      $stderr = old_stderr
    end
  end

That’s better, but it set me wondering how far I could go down this route. What about creating an assert_stderr builder? This is what I’ve come up with so far.

  def self.assert_builder(what, &check_block)
    define_method("assert_stderr_#{what}") do |*args|
      begin
        old_stderr = $stderr
        $stderr = StringIO.new
        yield
        check_block.call($stderr.string, *args)
      ensure
        $stderr = old_stderr
      end
    end
  end

  assert_builder :matches do |stderr,regex,message|
    assert_match(regex, stderr, message)
  end

  assert_builder :empty do |stderr,message|
    assert_equal("", stderr, message)
  end

It looks reasonable, but it doesn’t work. It’s meant to create a method which takes a block and executes it. However, careful debugging (read: p) shows that the yield is actually calling the check_block parameter instead of the block that’s provided when the assert_stderr_matches method is called. At this point, I have no idea why this is happening. I’m very confused.

It doesn’t help that you can’t really google for “ruby blocks that take blocks” and get a sensible answer.

Maybe I just need to nose around the Rails source long enough. There are examples of most forms of Ruby magic hanging around in there…