Word Wrapper

Many, if not most, programmers leave word wrap off by default when editing code. This is because line-breaks in code can have programmatic implications. Python, for instance, uses line-breaks to indicate the end of a statement. With word wrap enabled, coders may have a difficult time distinguishing between new lines created automatically by word wrap and new lines created intentionally by a carriage return.

That’s all well and fine when you’re working with actual code, but it doesn’t work so well with documentation meant to be written in plain English (or some other traditional language). On one hand, s single long horizontal line of text isn’t very readable — newspapers invented columns for a reason — and horizontal scrolling is a pain. On the other hand, manually inserting line-breaks into text isn’t much better. Adding or removing just one word at the beginning can require deleting and re-typing all of the newlines in a paragraph. And because documentation often lives in the same file as code  (i.e. as comments), most text editors apply the same word-wrapping scheme to both code and documentation.

Some text editors are smart about this and offer ways to automatically re-flow long blocks of text, but it doesn’t seem to be a universal feature in code editors. To help, I’ve put together a simple webpage that uses Javascript to convert long flowing word-wrapped paragraphs to a fixed width text. By default, it uses the industry standard width of 80 characters, but you can change that. You can also use the tool to automatically prepend each line with a characters (e.g. to insert a “#” character to conform to Python’s commenting requirements).

It also doubles as a way to convert fixed width multi-line text back to — e.g. the angle bracket quoted paragraphs in e-mails — back to a traditional word-wrapped single line of text.

You can use the tool here, or check out the source code on Github.

Remove Notes from Powerpoint (PPTX)

PowerPoint lets you add notes to each slide that are not visible when you play your PowerPoint as a slide show. Let’s say you want to remove all of those notes — e.g. so you can distribute the PowerPoint file — and don’t want to manually remove this all by hand.

If you’re using one of the newer versions of PowerPoint on a PC, this is straight-forward enough. You just pull up the Document Inspector and tell it to remove notes, along with other possibly sensitive metadata. Here’s how to do it in PowerPoint 2007 and PowerPoint 2010.

But let’s say you’re using a Mac. As far as I can tell, there’s no way to remove notes in PowerPoint for Mac 2011 (if there’s a way to do it, please let me know in the comments). You may be able to use some VBScript macros, but explaining scripting to someone with little technical experience can be difficult.

Continue reading “Remove Notes from Powerpoint (PPTX)”

Copyright Assert Truthy

I was poking around in the newly open-sourced Etherpad code, and came across this tidbit.

/**
* Copyright 2009 Google Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS-IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

function assertTruthy(x) {
  if (!x) {
    throw new Error("assertTruthy failure: "+x);
  }
}

That’s trunk/etherpad/src/etherpad/testing/testutils.js by the way. So anyhow, as much as I appreciate that is licensed under the Apache License, is “assertTruthy” really creative enough to be worthy of a copyright?

Continue reading “Copyright Assert Truthy”

MySQL Composite Indexing for Django

Posted my first Django snippet! This concerns a quick and dirty hack for getting composite indexing in MySQL. It’s also a simple example of how to use Django’s post_syncdb signal.

Django currently comes with a unique_together meta attribute you can use to specify unique combinations of fields. I think the backends create an index in the database from this. However, I couldn’t find anything for simply creating non-unique attributes, hence the hack you see in the snippet.

I don’t really have the patience to make it work fully for the other backends since I don’t use them currently (aside from SQLite3 for testing), but it’s GoodEnoughForMe.

Saving keystrokes

Happiness comes from small victories. In order to save on unnecessary typing, I’ve made a few shortcuts in Django for my most common “python manage.py” commands.

For example, my test command is longer than most because I use a different settings file for tests to keep the environments separate. So I popped open an editor and created this:

python manage.py test $* –settings=settings_test

Save as something short — like ‘ts’, then make executable

chmod u+x ts

Now instead of typing python manage.py test … , I can simply type ./ts and be done with it. Note that things like ./ts my_app also still work

Last step: update your repository to ignore these files so you don’t accidentally piss off any others you’re working with.

Assumption Testing

I like to write narratives when I’m testing code. Do A. Test some stuff. Do B. Test some stuff.

The problem with these narratives is that an error in part A can result in cascading test failures in B, C, etc. It’s usually not too hard to figure out, but it’s definitely annoying to see one bug fill up your console  with tracebacks from 50 test failures.

One way to deal with this is to compartmentalize your tests, i.e. make A and B separate tests and mock out any references to A in B. It’s easy to overdo this however.  A lot of times, you actually do want to test the interaction between A and B (and C and D and so forth).

What we really want to do is to run the narrative and stop as soon as we hit a failure. However, there doesn’t appear to be a control the flow and order of testing between different tests in Python’s native unittest and doctest modules. That basically leaves writing really long and unwieldy test functions.  Not very maintainable.

So I ended up hacking together an extension of unittest (and doctest, sort of) and named it Antf. The basic idea is that we add functionality for specifying that a test case depends on functionality tested in another test case. If test A depends on test B, then we test B first. If B fails, then the test runner passes over A.

Possible issues are possible namespace issues in keeping track of which test cases have already been looked at and circular assumption references. These don’t seem to be real show-stoppers right now though, so I’ve gone ahead and pasted the code below the fold.

Continue reading “Assumption Testing”