This week, like last week, I've been revamping an old project and learning some new tools. This time it's been TwoSlug receiving my attention.
TwoSlug is a fun little web tool to generate random two word phrases, or slug lines, using a randomly chosen verb and noun. Words are chosen from Princeton University's WordNet database. It was originally written almost year ago, in a single evening, and hosted on GitHub. Unfortunately it's been limited to a simple, static, HTML page until now.
Aside from the obligatory themeing, I've added two major new features to TwoSlug. The first is an API for requesting your own random slug lines. With an HTTP GET request you can ask for any combination of verbs, nouns, adjectives and adverbs. The API will return you random slug line in JSON format.
The second feature is word definitions using DuckDuckGo's excellent Instant Answer API. Definitions are displayed as pop ups on each word. The words themselves are links to the original definition source. The team at DuckDuckGo are extremely generous to offer their API with very restrictions.
This week's project was implementing my own reStructuredText Viewer and editor for reStructuredText documents. In the past I have used the Online reStructuredText editor for quickly previewing and editing README files before being publishing on the Python Package Index. While I have been happy with the online editor, it recently had some stability issues. When I tried to deploy my own instance I was surprised to find a dependency on Redis.
Not wanting to deploy an instance of Redis as well as a web application, I decided it was a good opportunity to learn something about docutils. It's the basis for the Sphinx documentation generator, I tool I use regularity. My viewer is a web application built using the Flask web framework. The application acts as a docutils publisher, accepting reStructuredText documents and return rendered HTML. As with other little web applications I've, the viewer is deployed on Heroku. The source code is available from GitHub.
So feel free to give my reStructuredText Viewer a try. But please be kind to the aesthetics, web design is not my strong suite.
My Begins project is approaching its first beta release. It's actually been used in operations for a while now, which has produced a steady flow of bug reports and new feature requests. With a significant milestone for the project approaching, its fun to reflect of how it got to this point.
The genesis for Begins was me toying with syntactic sugar for Python's main. I was intrigued with the lack of a protocol over main, like there is behind len to reversed. In fact, I was so interested in the question I attempted more sugar for Python's main, this time with an actual implementation.
That first implementation was based on Python's atexit module and made it into the list of projects as project main. I didn't do much with it until Julython and J(an)ulython this year. Julython is a fabulously fun event designed to help motivate participants to return to those long stagnating projects, like Begins.
For Julython main was renamed Begins. It moved away from atexit to stack inspection. (Parts of the interpreter may be shutdown when the functions registered with atext are called) And created an extensive unit test suite with nearly 100% coverage.
However, I didn't really feel comfortable publishing Begins on PyPI when it was just a pretty way to begin a program. This felt a little to minimalist to feature in a Python package. As it turns out I had also been interested in sugar for Python's argparse. So I decided to add some command line handling to Begins.
After the 0.1 release I showed Begins to one of my friends. He works on a large project with a wide selection of plugins. All of which need to inject command support into the central application if present. I didn't really expect Begins to grow much from that first release. However, they were able to convince me to add sub-commands and configuration file support. Since then they've been a steady source of feature requests.
While using Begins myself I've come across some new pain points for me. That includes converting command line arguments to their desired types. I added the begin.convert decorator while creating documentation examples. A future release will significantly improve its utility.
So a little project that was once too insignificant to publish on PyPI, and then wasn't expected to grow much beyond its first release, has steadily expanded in scope and functionality beyond expectations. This really shouldn't surprise me. Scope creep is a force in every software project. It is however novel for me to observe and experience it outside of the break neck pace of professional work.