Environments, Tools and Processes

In today's post, I'm going to go into some details about the development environment and tools I'm using, and touch on some of the processes I'm going to build out. Several of these tie in to best practices that might not completely align with professional best practices, but that I feel have value enough to adhere to even for personal projects. Mostly, though, I'm providing this information in case there are any readers who want to actually play with my code the same way I am.

Operating System: Ubuntu Linux 16.04 LTS

There are several reasons that I prefer to work in Linux in general, and in Ubuntu in particular:

• I prefer Debian-based Linux (or at least the .deb-based package/software management systems) over the others. That's a personal preference, to be sure, but it's a pretty strong one.
• Most of the projects I have in mind are web applications. In general, I prefer to develop code under the same OS and software versions that they are expected to run under, if only to reduce the likelihood of incompatibilities across different systems or installations. To be fair, my hosting provider is not running Ubuntu servers (they selected CentOS instead), but so long as the web-server and Python versions are reasonably close, I expect no significant difficulties.
• Ubuntu has both server- and desktop/workstation installations ready to roll, so setting up a virtual server with their server installation to test with is a snap.
• I've tried other Debian-based Linux variants over the years, and though I have to admit that I like Linux Mint better, particularly with the Cinnamon UI, I've had some... bad experiences with it when trying to upgrade it to newer versions, so I've opted to not use it.

To be fair, there are things that I wish were different in Ubuntu, but it's come the closest to being what I want/need out of the box of all the variant Linux flavors I've tried to date, with the least longer-term concerns. I could spend time (maybe a lot of time) making it exactly what I want, but I'd rather spend my time writing code than tweaking my OS, frankly.

Language: Python 2.7.x

Most of my server-side development is going to be done in Python 2.7.x. For the time being, I'm going to focus on the 2.x version rather than the 3.x version because I'm not confident that Python 3.x is going to be fully ready for prime-time for a while yet. I don't really know that this is the case, but since the default Python installation on Ubuntu 16.04 is in the 2.7.x range, I'm going to assume that 3.x isn't quite ready. Again, to be fair, I've seen a lot of update traffic on my system for Python modules that look like they might be aimed at Python 3.x compatibility. I'm hopeful that's the case, at any rate, but I'll hold off until a 3.x version is the default (or only) installation before I take the plunge. The trade-off there is that I'll have to be prepared to change over to 3.x when it is ready, but as long as the differences between versions are kept in mind, I don't anticipate any significant issues there, particularly since there are tools to help transition from 2.x to 3.x

The current default version of Python on Ubuntu 16.04 LTS is Python 2.7.12, which jives with the current version available on the Python site at the time I wrote this.

I expect that most of the code I'm going to write would run without significant issue under a few earlier versions of Python, but there are some key pieces of the language that I'm planning to use (the abc module in particular) that weren't available until Python 2.6, so that'll be the lowest-version cut-off for my purposes. I'm going to try to take some steps to make sure that that minimum language-version can be worked around without too much pain whenever I'm aware of them, however.

Code-Editor/IDE: Geany

I suspect that if one were to ask, say, a dozen different developers what their preferred code-editor/IDE was, there'd be almost as many different answers as there were developers. There are a lot of options available, even for languages like Python that may not be one of the current sexy languages to work with. I also suspect, given the typical mindset of most developers that I know or have worked with over the years, that there would be a lot of reasons for those preferences, and there's a good possibility that all of those reasons would be good/valid ones.

My criteria for selecting an IDE are pretty straightforward, I think:

• I need to be able to organize my code into projects (or some equivalent structure) so that I can keep their codebases separate — particularly at present, since I'm going to work on both an application and a framework library that I expect to be used by other applications;
• I want to be able to have multiple projects open/accessible for editing (or inter-project interaction) at the same time, without having to include one project's source-tree in another project's structure (using project references or some similar mechanism, probably);
• I want to be able to work with Python, HTML, CSS and JavaScript without having to switch programs; and
• I want to be able to see any file in any project without having to have those files open in the editor;
• I want to have source-control integration available for my projects as part of the IDE;

In a real (professional) scenario, I'd also add:

• I want to have source-control integration available for my projects as part of the IDE;

Having looked at a fair few editors and IDEs, the one that best suits these needs and wants is Eclipse (with the PyDev extension/plug-in), or any of several variants of it, though I was not able to get any of them running nearly as easily as Eclipse itself.

Eclipse is something of a beast, though: It's on the heavy side, and while it would be my first choice in situations where I'm expecting to need to work on multiple projects concurrently, especially if they are significantly interdependent, it feels like overkill for what I'm doing here. It also would not be my first choice for stand-alone projects, one-off code, or for projects where source-control integration isn't as high a priority.

My go-to editor for those kinds of simpler worlds is Geany, which is a much lighter-weight editor, supports all of the languages and file-formats that I'm concerned with, and can manage stand-alone projects fairly well, particularly with any of several alternate project-manager plug-ins active. The current version of Geany in the Ubuntu 16.04 LTS repositories as I write this is 1.27, and the project plug-in that seems to work best for me at present is GProject (a glob-based project-file viewer).

It would also appear that MonoDevelop has Python syntax support, though I haven't yet gone to the effort of trying it to see how well it works, and it appears that it's only an option on Linux versions.

Web-server: Apache 2.4.x

My choice of Apache is more because I have more experience with it than with any other web-server I have ready access to. It's still a pretty solid choice, I suspect — judging by at least some reporting I could find, it still accounts for just over half of all detectable web-servers in the wild.

I also know that it supports at least two Python web-application modules that I'm planning to use/support: mod_python and mod_wsgi.

Another potential option, though it might be limited to WSGI-based applications is nginx. I do plan on exploring nginx in more detail at some point here, but for now it's just not my primary option or focus.

Build-Process Tools

Without a dedicated source-control system (more on that later), a formal Continuous Integration process doesn't really make much sense, but parts of the automated build process that is key in CI are, I think important enough to keep, even at the level of personal projects. Specifically, I think that even a bare-bones build-process should:

• Run automated tests and stop if any tests fail;
• Generate notifications if the tests fail;
• Package the build(s) in some fashion so that it's ready to be deployed;
• Generate notifications if a build fails for reasons other than test-failures; and
• Deploy to an environment where the current build can be executed.

There are, I think, a ridiculous number of build-processes available these days. I suspect that most of them, even the ones that aren't specifically aimed at facilitating a CI process, can be used (perhaps with some custom scripting or integration) to achieve all of the build-tasks that I'll be concerned with.

For now, though, I'm going to stick with GNU Make. The GNU version of make is fairly straightforward to use, I think, and can be extended with additional scripts and external programs quickly and easily. I know it can be used to allow one project's Makefile to call another project's Makefile using a recursive call in a target, and the ability to define target-specific variables will provide a mechanism for handling builds for different environments, though I don't expect I'll need that. Since it also has access to any other tools or programs available on the machine where a make is being executed, there are any number of hooks for notifications, from sending emails to generating notifications in systems like Slack.

Other Considerations

In a formal dev-team or -shop environment, there are other bits and pieces of the development and build-cycles that I think are critical that... well, frankly, just aren't so critical for my purposes at this time. The most important one, to my thinking, is a robust source-control process.

I know Git is newer, more popular, and the sexy choice these days, but this comic (from XKCD) I think, touches on some of my reservations about it.

I generally prefer Subversion if I'm managing the source-control system myself. It may not be as new, as efficient, etc., etc., and it certainly doesn't reconcile movement of code from one place to another as well (a feature that I think is Really Cool®™), but when push comes to shove, I know how to deal with svn issues when they arise. Additionally, I know that there's several GUI options for it that I understand, both free-standing and integrated into various IDEs. That's important to me, because I'd rather be writing code than memorizing a slew of commands to manage the code I'm writing.

Ultimately, so long as any version-control system does what it's designed to do, and doesn't become unmanageable doing it, they are all more-or-less interchangeable as far as I'm concerned.

However, in this case, I'm going to forego setting up a formal version-control system for the code presented here. If I weren't the only person developing this code, I wouldn't even consider not having something like SVN or Git in play, but since I am, and I've got ample space on my Dropbox account (and I'll be able to share code from there in a read-only fashion), I'll stick with that. I can still roll back to previous versions of files, though I'll lose any formal commit (and commit-comment) capabilities, but in this case, that's OK. I may come to a point where I need it later, but I'll cross that bridge when (if) I come to it.

That pretty much covers the hardware and software — Next up, I'm going to go over some of the coding-standards that I'll be following in the process of developing the code here.