I don't have time to update the HOWTOs associated with this before I end my day at the computer, but I had an ah ha! moment this evening with regard to getting FlexUnit to play nicely with RemoteObject against a PyAMF server.

Changelogs: ah ha moment, refinement and abstraction.

Files: the new test, the new class.

Some observations, where I use terminology loosely:

• ActionScript looks superficially like Java, which is a language that I haven't used a lot, but that I've glanced at enough to notice certain patterns.

• ActionScript is actually more like JavaScript, but has enough static typing to make it easy to follow Java idioms.

• FlexUnit/RemoteObject samples that I've studied seem to define callback functions for asynchronous tests outside of the test case. This is unnecessary, in my opinion, and makes the test case much less readable.

  If you look at the example test above, there are five variable assignments, then a call, that comprise the entirety of the test:

  1. Line 41-42: Trigger an asynchronous operation that will produce a value object that we want to inspect.
  2. Lines 43-48: Define a function to compare the state of that object with our expectations of it.
  3. Lines 49-54: Boilerplate to connect the two together.

To me, this is a clearer way of defining tests. I hope to refine this even further by turning item 3 above into one or two lines of code.

To get to that point, my plan is to develop an API for deleting the database collection (if allowed by the server), create an empty named database, list database names, and delete a named database. That should give me enough code to figure out where the lines of fissure are to reduce that boilerplate.

Does anyone else out there know of more FlexUnit tricks? :)

I'd like to do some test-driven development in Flex right away, but I'm still looking at the options available.

The two main options seem to be ASUnit and FlexUnit.

ASUnit is the older of the two, but I think from what I've read so far I'm going to look at FlexUnit first, and if it does what I'm looking for, I'll just use it.

As far as how to get started writing tests for ActionScript code, I see there is also the corelib that Adobe is opening up, and it contains FlexUnit-based unit tests.

So, what am I looking for?

I'd like to be able to work on SchevoFlex, write tests for both the Python Side and the ActionScript side, run all of the tests at once using nose, and generally keep a fluid test-driven development cycle going... especially since part of the project is making sure we have rock-solid communications between the client and server!

Lazyweb? :)

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.

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...

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.

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