ROTR

This week, I'm taking some time to step outside of the Schevo box, and take a look at some other boxes. A few things are tools that I've used in the past but want to brush up with. Some are tools that I've read about, but would like to follow a tutorial or two for so I can get a feel for how they work.

I'm not making definite plans to get through all of these this week, but I'm also not going to do things sequentially. For instance, I would like to explore both Eclipse and PyDEV when I work with anything Python related, such as Django.

• Ruby: There seems to be a fair amount of cross-over between Python and Ruby as far as what the languages are capable of.
  • Ruby on Rails: I might as well see what all the hype was about.
  • QtRuby: Learning to use a new programming language in terms of a familiar GUI toolkit seems like a good idea.
  • wxRuby: Another familiar GUI toolkit, with a thin layer of Ruby on top.
• Python: My favorite programming language for five years and running.
  • Django: Like Ruby on Rails, I would like to familiarize myself with this.
  • TurboGears: I've used TurboGears for some production apps. It's been a while since I've used the latest version, so I'd like to brush up.
  • Pylons: I've also used Pylons, but would like to familiarize myself with the newest release.
  • wxPython: I was exposed to this GUI toolkit before any others for Python, and although I haven't used it recently, the project continues to accumulate polish and helpful new features. It may be a candidate for a new widget kit for Schevo.
• Smalltalk, specifically Seaside: I want to either say "I get it!" and train myself to develop with Seaside, or to say "I get it!" and look for or help implement similar features in other languages.
• Java: One of the big elephants in the room. I don't think one must to know Java to succeed, but people are doing useful things with it, so it would behoove me to learn it.
  • GWT: The Google Web Toolkit is one of the reasons I want to learn Java.
• IDEs: I am a GNU Emacs user. I am not a hardcore user. I know my way around its editor, I enjoy the Python and reStructuredText modes, and it's available on many platforms. I'm not dogmatically loyal to it though, so I'd like to see what I'm missing.
  • Eclipse: I've tried a little bit before, but I haven't used it end-to-end to realize everything from the beginning of a new project to the generation of a deployable package.
  • Aptana: From what I gather, this is an add-on for Eclipse that automates some web development tasks.
  • PyDEV: This provides Python support for Eclipse, so naturally, I'd like to use this in my routine this week.

(Edit 2007-12-11: A little late to edit this, but "paster restcontroller" was quickly adopted into Pylons. What a great team they are!)

(Edit 2007-12-11: I no longer work on the SPHYRA project.)

It's a new calendar year, and with it comes the usual sense of renewal and thoughts of "I meant to do that last year, but didn't, so I should try again this year".

One of the things that I had been reading a lot about last year (and the year before, in fact) was REST. Now that I'm working on a fresh start for SPHYRA, now is the time for me to become a RESTafarian. I suppose it's only appropriate since I have dreadlocks that I've been growing and grooming for a little over a year now :)

In my search for useful information for implementing a RESTful web app using Pylons, I found information about RESTful services using Routes that came in handy. What I couldn't find was a template that could be cut-'n-pasted into a new controller module to save some typing.

Here is my first take at such a template. I haven't attached any code to it yet, so it's not guaranteed to be correct. As I attach code to it and/or receive commentary, I'll update this post so that it becomes more correct:

class ItemController(BaseController):

    def index(self, format='html'):
        """GET /: All items in the collection."""

    def create(self):
        """POST /: Create a new item."""

    def new(self, format='html'):
        """GET /new: Form to create a new item."""

    def update(self, id):
        """PUT /id: Update an existing item."""
        # Forms posted to this method should contain a hidden field:
        # <input type="hidden" name="_method" value="PUT" />

    def delete(self, id):
        """DELETE /id: Delete an existing item."""
        # Forms posted to this method should contain a hidden field:
        # <input type="hidden" name="_method" value="DELETE" />

    def show(self, id, format='html'):
        """GET /id: Show a specific item."""

    def edit(self, id, format='html'):
        """GET /id;edit: Form to edit an existing item."""

Perhaps this could be automated with a paster restcontroller thing things command in the next version of Pylons? :)

I finally had the time to fiddle around with ToscaWidgets inside Pylons recently, and came up with a top bar for SPHYRA that is driven by information in a Schevo database.

• The widget class takes care of converting parameters given to the widget to data structures usable by the Genshi template.
• The widget template converts it into a fairly simple navigation bar.
• The controller base class populates a widget using the database and makes it available to every controller.

Notes

Some notes for my own edification, as I learn this from the ground up as it's being developed. (Thanks, Alberto, et al, for doing all the hard work!)

Creating a simple widget class usually involves the following:

from toscawidgets.core import Widget

class MyWidget(Widget):

    # 'params' are the valid keyword arguments that can be passed to
    # __init__ and __call__
    params = [
        'abc',
        ]

    # 'template' is 'templatetype:templatename'
    template = 'genshi:myapp.widgets.templates.mywidget'

    # Set default values for parameters.
    abc = 123

    # When ToscaWidgets prepares a dictionary to be sent to the
    # template specified above, it calls update_params against
    # that dictionary.  Use update_params to modify the parameters
    # set on the widget to a form that is 'massaged' enough for
    # the template to make proper use of.
    def update_params(self, d):
        d['abc'] = d.get('abc', 0) * 2

To include a widget in the final HTML, given that c.widget is an instance of a ToscaWidget:

${c.widget}

To create a new widget based on an existing one, just call the widget instance with the parameters you want to override:

c.widget = c.widget(some_param=some_new_value)

Questions and thoughts

Is there a way for the TopBar widget to include an image resource for the logo, and then be configured in such a way that it is used as the default unless overridden by a parameter that contains the URL for a different image?

I'd also like to get my TopBar-specific CSS packaged up with the TopBar widget itself, and simplify it a little more.

I'm sure I'll figure these out in time but if anyone responds to this I'll give them a free cookie. (*)

(*) Cookies not guaranteed to be edible. Cookies may consist of electronic transactions already made in the course of reading this text.

(Edit 2007-12-11: I no longer use EveryDNS or have a need for this project, so this is one for the deadpool!)

Earlier this month, EveryDNS was under a DDoS attack that put it out of service off and on for several consecutive days.

I currently use EveryDNS for primary and secondary DNS service on all of the domains I am responsible for. It's easy to use, was quick and convenient, and took worries away from a group that was accustomed to using BIND for DNS service.

It became clear to me, and to the other decision makers I work with, that the DDoS attack meant that we should look again at how we distribute our DNS service. Another concern I had regardless of the DDoS attack, is that we are working on rolling out a service we sell at a faster pace, and it would be beneficial to have a handle on being able to easily provide authoritative DNS answers about new subdomains.

Whatever we do though, it must be something that doesn't bring back the bad memories of manual BIND configuration file editing, and doesn't bring back the bad memories of numerous BIND security holes over the years.

It must also be something that is easy for sysadmins to manage, preferably using a web browser and a simplified interface similar in nature to EveryDNS's.

Finally, it might as well use Schevo if it's direct and feasible to do so, and serve as a testing ground for the other Python packages I've started using, including Pylons and ToscaWidgets.

All of this culminated into the creation of the dym project. Because the initial experiment to drive a DNS server based on a Schevo database was successful, I continued the project and will be writing about it as I write it.

Questions, comments, code, and curiosity are welcome! :)

Note: This is based on development versions of the SchevoWsgi package.

SchevoWsgi provides an ability to expose one or more databases to a WSGI environment by way of a Paste filter called dbopener.

To use it in Pylons, first edit your development.ini file. Add these two sections below [DEFAULT], where yourapp is the unique name of your application:

[pipeline:main]
pipeline = dbopener yourapp

[filter:dbopener]
use = egg:SchevoWsgi#dbopener
schevo.db.db = %(here)s/dev.db
verbose = true

Change the [app:main] section name to [app:yourapp], to disambiguate it from the pipeline whose name is main.

Now, provided you have a dev.db Schevo database in the same directory as your development.ini file, it will open it when you serve up the development.ini application.

It is useful to expose the open database more easily by referring to self.db in controller code. To enable this, open yourapp/lib/base.py and add this line above the return statement in the BaseController.__call__ method:

self.db = environ['schevo.db.db']

Note: This is based on a development version of the SchevoWsgi package.

I needed a way to get to an in-memory Schevo database that would be created from scratch every time a functional unit test ran in a Pylons application.

So I added a memory:// URI type to SchevoWsgi's dbopener middleware.

To use it in a Pylons application, make sure you already have a development.ini file that is designed to work with Schevo. Then copy it to testing.ini and change the [filter:dbopener] section to use an in-memory database instead:

[filter:dbopener]
use = egg:SchevoWsgi#dbopener
schevo.db.db = memory://yourapp.schema/1
verbose = true

Change the loadapp line in yourapp/tests/__init__.py to read as follows:

loadapp('config:testing.ini', relative_to=conf_dir)

I like to see Apache-style console logs when I'm developing web apps. The http server provided by Paste in recent times lost its transaction logging code for perormance reasons. That code is now in a separate module and is called the "translogger".

To turn on console logging of http requests to a Pylons app, edit your app's development.ini file and add this section below the [DEFAULT] section, replacing yourapp with a name representing your application:

[pipeline:main]
pipeline = logger yourapp

[filter:logger]
use = egg:Paste#translogger
setup_console_handler = true

Then, change the [app:main] heading to say [app:yourapp] instead; otherwise the app will conflict with the pipeline that is already named "main".

For me, it is convenient to be able to just run one command to start a development web server for a Pylons project, or any other project for that matter.

When creating a new Pylons project, you usually must invoke the "paster" script to start the development server:

$ paster serve --reload development.ini

Taking a cue from what RhubarbTart does, here is how I change my development.ini file in a Pylons project so that I can invoke it like this instead:

$ ./development.ini

At the top of the file, add this line:

#!/usr/bin/env paster

At the bottom, add this section:

[exe]
command = serve
reload = true
verbose = true

Make the file executable:

$ chmod +x development.ini