1v$ Wed Aug 21 10:55:26 GMT 2013
1v$ Wed May 1 15:21:03 GMT 2013
I'll be giving talks at the following events this month:
1v$ Wed May 1 15:01:12 GMT 2013
1v$ Wed Nov 28 7:33:30 GMT 2012
From the 6th of December I'm going to be trying a little experiment. I'm going to run a weekly newsletter filled with links to articles, videos, project and dev news from the world of PHP called PHP Weekly (yes much in the style of Peter Cooper and Gareth Rushgrove).
1v$ Tue Sep 13 15:17:08 GMT 2011
I recently had a reason to try out Hipchat, being a bit of a "chat enthusiast" (I was an IRC network admin for about 7 years and have a been developer on a few web chat and IM systems) I found Hipchat to be one of the nicest (that I've used) of the recent stream of "IRC for the web" products out there (for example 37 Signal's Campfire).
Normally this would have been the end of my quick perusal, until the next time I had reason to the use the service, but I noticed they had not only an API, but also Jabber/XMPP exposure for creating bots. Now my interest was piqued.
I wrote hippybot using the excellent python-jabberbot, a library that utilises the equally brilliant xmpppy to allow the creation of bots in an easy to understand and pythonic way (e.g. inherit from base class, set some connection strings, override event methods if need be, use decorators to extend commands the bot responds to).
How is this different from a regular Jabber bot? I've written some Hipchat-specific customisations into the bot:
- The connection config assumes Hipchat's XMPP server, and various details such as the username and channel names have Hipchat specific [pre/suf]fixes added to them automatically.
- The bot "understands" at-sign mentions (e.g. those popularised by Twitter and supported by Hipchat for directing messages to specific people within rooms, as well as triggering notifications), and commands added by plugins can leverage this.
I've added a simple plugin API to the bot, which consists of either creating a function in a module with a decorator, or a class in a module with as many decorated methods (each a different command to trigger the bot) as you like, and the ability to create aliases for commands and define whether a command is triggered by an at-sign mention or not (e.g. @hippybot do something!).
In the next release I plan to add a simple wrapper to Hipchat's API (already in master), better at-sign mention handling, and some more core plugins.
Feel free to check it out and for an example of the sorts of things you can do with a bot like this just check out some of the things Github's hubot does.
1v$ Fri Jun 17 14:59:17 GMT 2011
I very rarely ask people to spread links about or push my wares, but in this instance I would greatly appreciate sharing "this link":http://goo.gl/S9n7P to anyone you might know who creates/publishes comics of any form (web comics, digital comic books etc.) online.
1v$ Fri Apr 29 0:06:13 GMT 2011
Morgan Robert Mason, born April 26th 12.07am, 10 lbs exactly, mother and baby well (but exhausted).
1v$ Tue Feb 22 17:06:28 GMT 2011
Well, actually "v1.1.0":http://pypi.python.org/pypi/django-form-scaffold/1.1.0 of "django-form-scaffold":http://github.com/1stvamp/django-form-scaffold was released last week, but I've been a bit too busy to blog about it since then.
A quick recap for the uninitiated: _dfs_ is a set of utilities for generating the mark up and Django template code to display all the fields in a Django Form, e.g. the task of displaying each input element, label text and error message is still given to Django, but we display the markup around those elements in the template itself.
The library offers a few variants on the @Form.as_*@ methods, which will output mark up similar to those methods.
New in "v1.1.0":http://pypi.python.org/pypi/django-form-scaffold/1.1.0:
* A README typo fix, spotted by Chris Matthews.
* A management command (@formscaffold@), based on a script submitted by Chris Matthews.
* Some fixes to the way form errors are generated for ModelForms.
To use the new management command just add 'dfs' to your @settings.INSTALLED_APPS@ tuple and the command will become available.
It's used like so:
./manage formscaffold my_app.forms MyCustomForm as_p # or if using buildout bin/django formscaffold my_app.forms MyCustomForm as_p
The above would generate the form using <p/> tags, for the class @MyCustomForm@ located in the module/package @my_app.forms@.
Please note, if your form requires any setup (e.g. values passing to the constructor or the instance) the above won't work, as it just creates a base instance from the class and passes that to the helper, you can still use dfs to do this from a Django app shell though (using @./manage.py shell@).
1v$ Fri Dec 31 9:24:56 GMT 2010
I've been doing it again, despite having revamped this site with a view to keeping it more up to date, I've entered into a _blogmire_.
Other than the fact I'm a lazy lazy lazy lazy lazy man, one of the reasons I don't blog much here but do put lots of things on "Twitter":http://www.twitter.com/1stvamp (and code on "Github":https://www.github.com/1stvamp), is barrier to entry; both of these have an extremely low barrier to getting my data out there (Twitter clients, @vim@ & @git@ on the command line, etc.)
I'm wondering if switching to a static file generator system like "Blogofile":http://www.blogofile.com/ might help me be more productive with the place, reducing my workflow on 1stvamp.org down to a @vim@ → @git@ problem.
1v$ Thu Dec 30 0:19:08 GMT 2010
Seems I forgot to update my Habari instance and the site got buggered by some spam bot over the holidays, apologies while I root around for the last backup.