Dutch python meeting in Arnhem¶

Dragonfly: speech recognition framework

Last time there was a short lightning talk, now there's the full version. Christo Butcher, the presenter, was troubled with RSI and couldn't really type a lot anymore. So speech recognition to the rescue. He can type most of the day now, but still uses speech recognition a lot as it works well for many purposes. You have a huge vocabulary as a person and one word takes the place of many characters.

Two well-working solutions exist: Dragon NaturallySpeaking and windows speech recognition (vista). Nothing for linux, sadly, as it is just not economically feasible.

Speech recognition is currently very good for human language. So "typing text". There's also "command mode": "search wikipedia for dragonfly. That's something that really makes speech recognition useful.

• Rule: a voice command. A fixed structure. A rule can have nested elements, so it is something like "[today|yesterday] the weather is [good|bad]" if you want, for instance, to write blog entries about the weather.
• Grammar: just a set of rules. A container for rules. Useful for grouping.

In answer to a question: yes, he writes python code by talking to the computer. So he's real happy that python is so readable. He actually wrote most of the dragonfly code by speaking! He promised a demonstration later on.

He mapped many of the internal speech recognition building blocks in a quite straightforward manner to python built-ins or specific classes. Once returned as those built-ins or those classes, you can work with it reasonably comfortably. The core problem, however, is human language. Human language is complex. With loads of exceptions to any rules you can devise.

His personal holy grail is writing computer code by voice. It is actually reasonably easy as code by definition is very structured. Way more structured than human language. It should be ridiculously powerful.

http://code.google.com/p/dragonfly and easy_install dragonfly.

Deployment plenary discussion (Tim Molendijk)

Tim's first go at deployment was a bunch of small scripts. Every update was scary as he frequently lost an hour or so in fixing small mistakes. That ought to be improved. And there ought to be a load of existing solutions. So an email to the Dutch python mailinglist was in order. Most of the emails mentioned "buildout" so he gave it another look. He's pretty enthusiastic about it.

Every web application of reasonable size (in Tim's case django websites) consists of multiple components. Django itself, some custom python packages (so handled just fine with setuptools dependencies), a javascript library, a packer, etc. Buildout handles those setuptools dependencies just fine as it uses setuptools internally. And it has all sort of additions ("recipes") that do extra tasks (like handling backups, cron jobs, etc.).

Many of those extra recipes are released on pypi, so make sure you do some searching there to make sure you're not missing out on lots of automation.

Martijn Faassen thinks the brilliant thing about buildout is its extensibility. Everyone can contribute recipes. Open source power. Everything is on pypi.

I made two comments:

• Buildout/setuptools handles python packages handily. This means logically that you need to, you know, actually release those packages in a neat manner. Updating the version, the changelog, tagging the release, possibly uploading it to pypi, changing the version/changlog to the next development version. Wow. That's a lot of menial boring work. So make sure you actually want to do it often and make sure the menial work doesn't hold you back: let zest.releaser handle those simple tasks for you.
• Easily grab the right version. So pin your versions. And make sure you grab those packages easily. Uploading to pypi works fine; I mentioned tha.taglist that I released just that day. Keep your production and development configuration separated. and rebuildable. Especially your production config. Make sure you can release a new version with a little bugfix without pulling your hair out. Just a version change in the production config.

The lack of hassle is worth the effort you put into this. It saves hair and time. It makes deployment much more enjoyable.

An important note even for one-person projects: after half a year you're somebody else. You won't remember parts of what you've done half a year before. So make it explicit and repeatable. "Explicit is better than implicit".

Also mentioned: fabric for easily running commands remotely on a server.