Do you find yourself keeping a Subversion tree for your project similar to this one?

http://myproject.com/svn/
  branches/
    featureful-23/
    fancy-47/
  tags/
  trunk/

Do you find yourself checking out paths like this?

$ svn co http://myproject.com/svn/trunk/ MyProject

And then, do you find yourself switching to a branch in your MyProject directory, like so?

$ svn sw http://myproject.com/svn/branches/featureful-23

Do you ever find it tiring that you have to type that URL so much?

The Python script below might be useful for you then!

(more...)

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.

After reading about what Erlang has been used for, and about several of its pros and cons, I've decided to break out of my Python shell a bit and learn my first new programming language since 2002, when I was first introduced to Python. (Well, I've learned a bit more about things like JavaScript since then, but Python is the only one that I really dove into.)

It's also the first functional language I've learned, which is exciting, and is making me think about things a lot differently than I have before, even though I'm only 127 pages into Joe Armstrong's book.

I also like Emacs, in particular the variant that I use, Aquamacs.

The concept I just now learned about was the existence of escript, which lets you put a hash-bang line at the top of an erlang source file, make it executable, then run it as a script without using a wrapper script.

Out of the box, Emacs doesn't recognize that first line as an indicator that erlang-mode should be used.

Easy to fix. Just add a mode line in a comment as the second line in the file:

#!/usr/bin/env escript
%% -*- mode: erlang -*-

main([In]) ->
    X = list_to_integer(In),
    N = factorial(X),
    io:format("factorial ~w = ~w~n", [X, N]).

factorial(0) ->
    1;
factorial(N) ->
    N * factorial(N - 1).

See the release announcement. :-)

I'd like to personally thank everyone who has shown interest in Schevo, especially those who use it, contribute ideas, post problem reports to the mailing list, write patches, and so forth.

If you haven't checked out Schevo yet, try it. You might like it!

If there's something about it you are curious about, or want to get started using it, join the Schevo mailing list or join #schevo on the FreeNode IRC network and talk to us.

(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? :)

Python by default compiles "non-optimized" bytecode to .pyc files. It has an option you can pass, -O, that compiles "optimized" bytecode to .pyo files.

For those bash users who like to use python for some tasks, but python -O for others, here's a function you can add to your .bashrc file. Change the name as desired; I don't have any o binary on my system so I chose that:

function o {
  PYTHONOPTIMIZE=1 $@
}

Among other things, optimized Python bytecode strips out assert statements, so code that has many such statements in the normal course of operation will benefit from increased performance.

This is not desirable during development; unit tests depending on assert will not work correctly, for one. Also, some packages use assert to mask debug logging in a way that can be completely stripped out in production.

Schevo is one such package. The schevo.trace module provides some lightweight logging facilities that have proven to be invaluable during Schevo v3's development.

By masking all calls to log behind assert statements, we were free to put many logging statements into the code, and keep them there as documentation. Here's an example of a run of the SPHYRA migration script without, then with, optimizing. The best of two runs of each is shown:

$ sync; time schevo db create -xa sphyra dev.db
...
real    0m1.750s
user    0m0.964s
sys     0m0.722s

$ sync; time migrate_sphyra1_sphyra2 sphyrabusiness.db dev.db
...
real    0m44.185s
user    0m38.780s
sys     0m4.406s

$ sync; time o schevo db create -xa sphyra dev.db
...
real    0m1.679s
user    0m0.940s
sys     0m0.711s

$ sync; time o migrate_sphyra1_sphyra2 sphyrabusiness.db dev.db
...
real    0m37.365s
user    0m33.240s
sys     0m3.509s

(Edit 2007-12-11: I no longer work for this company or on this project.)

One of the concepts in SPHYRA is that the main type of data that the user works with is an Item entity, which has only a name and a creation timestamp. (See the schema source for the code behind all this.)

Everything else related to the item is available using the m (many) namespace provided by Schevo. Right now this includes Tag entities, related via TaggedItem entities.

Ultimately, this will also include relationships with other items, things like contact information, notes, journal entries, appointments, invoices, and so forth. What the user sees in the UI as far as what you can do with an item is based on the items tags, which always include one FeaturedTag.

Examples of FeaturedTag would be person, place, thing, job, appointment, or whatever the user's needs and imagination come up with. More on this as it gets implemented...

I wanted to make sure search terms were highlighted when searching for items in SPHYRA, so I set off to find something that would help me do so. I came across Trac's implementation, which uses JavaScript and is based on the one here.

In those cases, the code is used to highlight search terms that were entered by the user in a referring page, such as a Google search result page. What I desired was a way to specify my own words, and only highlight within a certain area.

Here's the first pass of a ToscaWidgets based widget I came up with for doing this.

• Widget subclass
• JavaScript
• CSS
• Currently used by find_item in sphyra.controllers.tag and its corresponding template.

When overriding the default implementations of Create, Delete, and Update transactions for entity classes in a schema, there are hooks that make it easy to change specific behavior.

(This isn't introductory Schevo material, but because Schevo is lacking in comprehensive documentation, I thought I might as well start by taking notes on things that I commonly need to look up, with the hopes that eventually there will be enough information written in various places to put together a decent tutorial and reference.)

(more...)

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.