Begins at the beginning

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.

Blogging with Pelican, Travis and Heroku

It's been over a year since I posted anything to by Tumblr blog. While Tumblr was a convenient way to start a blog, I now find it difficult to create content the way I want to. In particular, I want to author posts in reStructuredText or Markdown with high quality support for syntax highlighting of code. Therefore, I have decided to change to a different blogging platform.

My new blog is built using the Pelican static site generator. I consider a static site to be simpler and easier to deploy and manage, being a collection of static files. I chose Pelican as it was implemented using Python (my favourite software development language) is actively developed and appeared to have the features I wanted.

For a site theme, I started with the bootstrap2 theme from Pelican Themes. I then updated the version of the Bootstrap framework and the Font Awesome icon set, tweaked the CSS, fixed some bugs, tweaked the CSS some more, and finally chose to stop personally bikeshedding and move forward. I think it's pretty clear that I'm no web designer. There's still some annoying behaviour from the responsive design on mobile phones that I haven't been able to fix.

Most of my open source projects are hosted on Github, including this blog. Using a version control system allows me to crate branches for drafts I'm still working on. I also get to use my preferred text editor. While hosting on Github allows me to use Travis for continuous integration. Github also has excellent web based editing, so I can create and work on articles even if I don't have my laptop.

To publish, I'm using Travis for continuous deployment to Heroku. Travis makes continuous Heroku deployment reasonably simple. The most difficult part of getting this working was realising I needed to explicitly set the deploy strategy to use Git. Travis will default to using the Anvil deploy strategy, which does not work with my buildpack. I ended up forking the Pelican buildpack as the content directory wasn't being set correctly. This caused pages to fail to be built.

Heroku is very generous to offer each Heroku app enough credits to run a single web dynamo for free. This is easily enough to meet the tiny demand of this static site. Admittedly, Heroku applications running on their free tier will enter a sleep state after an hour of inactivity, the few seconds delay to wake from a sleep state doesn't greatly concern me at the moment.

One feature of Tumblr that I really liked was the ability to post to Twitter when I publish a new article. To meet this requirement, I created a recipe using IFTTT that does the same. It polls the site's news feed for new items, posting the title and link to my Twitter account.

To acknowledge the projects and companies that have enabled this blog, I have created a Powered By section in the side bar of this site, which will remain for the foreseeable future. Thank you Python, Pelican, Bootstrap, Font Awesome, Travis, Heroku and IFTTT. This has been fun.