Somewhat unexpectedly, I attended a tutorial on py.test at EuroPython today — which turned out to be very useful.

Below are my raw (i.e. imperfect and likely inadequate) notes from that session.

• minimal, no-API approach; no need for boilerplates
  however, a lot of optional framework-y functionality is provided
• convention over configuration (automatic discovery of test_*.py, def test_*, class Test*)
• py.test overrides AssertionError built-in, then re-runs statement to provide details — avoid assertions with side-effects!
• skip tests only for platform and dependency issues; use @py.test.mark.xfail for “expected to fail”
• funcargs introduced in v1.0 to replace traditional setup methods for fixtures (user & provider, loose coupling); allows for more flexible grouping
• print captured by default, only shown on failure
• internally makes use of its own hook architecture (i.e. many features implemented as plugins)
• yielded tests are deprecated (due to internal ambiguity); recommended to use pytest_generate_tests instead
• interesting plugins: coverage and PyLint integration
• can be used to run non-Python tests (e.g. for JavaScript)
• supports distributed testing (load balancing with multiple CPUs or remote machines, testing on multiple platforms)
• might be renamed (”I wish I’d named it differently”)

Holger Krekel has also published his slides (PDF), which are well worth a look.

Since my last post on the subject, I’ve become much more familiar and comfortable with Git.

While I still don’t consider myself an expert – especially when it comes to truly distributed collaboration – I did manage to pass on some basic knowledge to those around me just getting started.

In the process I came up with a very concise introduction – and even though it’s almost trivial, the following illustration of the basic workflow might be worth sharing (ASCII art ahead):

                                                       repository (remote)
                                                            ^      |
                                                            |      |
                                                           push   pull
                                                            |      |
                                                            |      V
working copy --add--> index (staging area) --commit--> repository (local)
               \                                  /
                \------------commit -a-----------/

Useful Commands:

• status
• log [-p] [--stat]
• diff [-w] [--color-words]
• checkout <treeish> <file> (reverting)
• init
• clone

My configuration is available on GitHub – this might serve as a reference for further exploration (e.g. aliases).

Last night, some of my colleagues and I attended the Bespin meetup.
It was great hearing Ben, Dion and Joe – quite obviously very smart hackers – speak, and later getting a chance to join various discussions with them.

As before, I’ll settle for a few quick notes:

• name
  When asked about about the name (which had confused us), humorously dodged the question multiple times. Not entirely sure why…
• reinventing the wheel
  Bespin makes heavy use of canvas, essentially reinventing the rendering of text and layout (using their Thunderhead toolkit).
  While contentious with regards to accessibility and web standards, this is necessary due to performance reasons.
  (Note: Not JavaScript is the bottleneck here, but the DOM is.)
• offline capability
  Currently Bespin should be considered a “hosted application”, requiring a server-side component.
  Personally, I don’t like the idea of relying on the “cloud” for my primary editor.
  While the Bespin team is planning to use Titanium eventually, Joe said it shouldn’t be too hard to integrate TiddlyWiki’s file-saving code (similar to the XWiki integration), essentially creating a stand-alone HTML application.
• tools integration
  Since Bespin runs in the browser, it might be hard to integrate external tools (e.g. PyLint).
  I’m concerned that this might mean the respective server must support such applications, stripping away another bit of developer independence…
• active community
  There’s already an active community of hackers making use of and contributing to the project.
  (We’re also considering using Bespin as a front-end for TiddlyWeb.)
• Ubiquity as Firefox extension API
  On a slightly unrelated note, it has been suggested that Ubiquity might be integrated into Firefox, which in turn could lead to a pure-JavaScript API for extensions (currently writing Firefox extensions involves a lot of overhead, e.g. creating XML documents). That would of course be most welcome!

I really enjoyed yesterday’s Geek Night on game development.
Instead of writing an elaborate draft that ends up never getting published, I’ve decided to simply post a few quick notes (personal and non-authoritative):
Continue reading this post…

Heavily inspired by Oskar Krawczyk’s WTFramework and Paul Downey’s subsequent enhancements, I’ve re-engineered this bookmarklet to be more extensible and better support multiple frameworks.
Continue reading this post…

GNOME Blog lets me write blog posts from my Ubuntu desktop, rather than going through the less-pleasant WordPress web interface.

Unfortunately, it doesn’t support categories, tags, or editing existing posts.

Update (2009-03-28):

Now testing Charm (via K.Mandla), a command-line blogging client; seems much more powerful than GNOME Blog.

While computer/video games certainly have a number of good things to teach about usability in software and web design, there are also quite a few mind-bogglingly bad examples.

exhibit A: Mario Kart Wii
Continue reading this post…

Lately I have been reading about and toying with Git a lot — and I’m truly fascinated! (In fact, I’m even using it to track the progress of this very posting.)
However, I’m not primarily interested in the distributed part. More important, to me, is the fact that Git gives me a private revision history (local commits). That way I can commit frequently without having to worry about publishing my changes prematurely.^[1]
Continue reading this post…

1. The same is true for other DVCS, like Mercurial — though I have only worked with Git so far. [↩]

Yesterday’s OpenSocial hackathon was the first event of this kind for me — and I’m quite glad that Simon had convinced me to attend.
Continue reading this post…

While reading an article about UsWare vs. ThemWare (via Jermolene), I’ve realized that TiddlyWiki, for me, has turned into ThusWare.
While I started out as a regular user, the more I code for and care about TiddlyWiki, the less I end up actually using it.
That of course carries the risk of losing touch with regular users’ needs, so I’ll need to get back to that original spirit. The first step in doing so will be to re-organize my diverse collection of TiddlyWiki documents — something that I’ve been wanting to do for ages, actually.
I’ll report any findings here, so watch this space!