LinLog

Well, I finally did it - I shelled out for a license of Komodo IDE.  I've been using Komodo Edit on and off since about 2007, but had never needed the extra features of the IDE to justify the $300 price tag.  But last week ActiveState had a one-week $100 off sale, so I decided to try it out again and ended up deciding to make the purchase.

Part of what motivated me to give Komodo IDE another shot after getting along fine with Komodo Edit for so many years (aside from the price, of course) is my new-ish job.  It turns out that Eclipse is fairly popular among the Pictometry engineers, despite the fact that they're a pretty smart bunch (I'm not a fan of Eclipse).  Thus many of them take integrated debugging for granted, so on a few occasions I've been told to debug an issue by "just stepping through the code."  And to be fair, there have been a few bugs I've worked on where integrated debugging genuinely would have been useful.  Perhaps this is due to the fact that our internal back-end framework is significantly more Java-like than most code-bases I've worked on (but that's another post entirely).

Of course, that's not all there is to Komodo IDE.  There are plenty of other nifty features, such as the regex testing tool, structure browser, integrated source control, and a number of other things.  So when you put them all together, it's a pretty good value, especially at the sale price of $195.  And with the cool new stuff in Komodo 8.5, I have to say I've pretty much lost interest in trying out new editors.  The ActiveState team did a really nice job on the latest version.

A year or two ago, I decided to update my skill set a little and brush up on my Python. In particular, I wanted to do a little web development in Python, which I hadn't done in nearly five years. Since I wanted to start with something fairly basic, I decided to go with the Flask micro-framework. I ended up using that to build Lnto, which I've mentioned before and I swear will get its own page someday.

One big problem with this project was was that my hosting is kind of bare-bones. Don't get me wrong - the service is fine. I use ICDSoft, whom I've been with for several years. I have no complaints about the service I've received - in fact I'm quite happy with it. However, it's mostly focused on PHP and MySQL and there's no shell access. But on the other hand, I'm paying less than $5 a month with only a one-year commitment, so I don't have much to complain about.

Anyway, the problem with running Flask apps, or pretty much anything other than PHP, is that they have no documentation for that whatsoever. There's a FAQ, but it says absolutely nothing about Python other than that they "support" it. As far as I can tell, that just means that they have a Python interpreter installed and Apache CGI handler is configured to run *.py files. There's certainly no mention of running things using WSGI, which seems to be the recommended method for running most Python frameworks.

Another problem is actually installing the Flask libraries. The documentation for, well, pretty much every Python framework or app out there tells you the best way to install it is with pip or easy_install. But, of course, you need shell access to run those, assuming they're even installed on the server. (And I did check - they're not installed.)

Fortunately, getting around these problems was relatively easy using using virtualenv, which I'd nearly forgotten existe). This creates a virtual Python environment which is isolated from the rest of the system. A side-benefit of this is that virtualenv creates a copy of pip in your virtual environment.

You can use virtualenv directly from the source distribution. This was required in my scenario, since I lack any shell access, let alone root privileges. I simply extracted the virtualenv source archive, uploaded it to my host, and ran the following command (I used PHPsh, a web-based shell emulator, but copying them into a PHP script would have worked just as well):
python /path/to/virtualenv-1.11.4/virtualenv.py /path/to/myapp/venv

This create a virutal environment in the /path/to/venv directory. You can then install packages into that environment using the "activate" script to configure the shell, like this:
. /path/to/venv/bin/activate && pip install Flask

That was easy. I now have a Python environment with Flask installed. All I need do at this point is configure my application code to use it. That's accomplished with a few lines to initialized the virtualen environment and start up Flask as a CGI app:
activate_this = '/path/to/venv/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))
from myapp import app
from wsgiref.handlers import CGIHandler
CGIHandler().run(app)

I just re-ran that entire process using the latest version of virtualenv and it's actually quite painless.

And as a side-note, the reason I did that was because I noticed the other day that Lnto had suddenly stopped working - the server was just returning 500 errors. Which was odd because I hadn't changed anything with the app or the database in weeks. However, the answer was found on the virtualenv PyPi page:

Python bugfix releases 2.6.8, 2.7.3, 3.1.5 and 3.2.3 include a change that will cause "import random" to fail with "cannot import name urandom" on any virtualenv created on a Unix host with an earlier release of Python 2.6/2.7/3.1/3.2, if the underlying system Python is upgraded.

When I created that virtualenv environment, the server was running Python 2.6. But when I checked yesterday, the Python version was 2.7. So apparently ICDSoft upgraded their servers at some point. No big deal - just recreated the environment and I was good to go!

I must be getting old or something.  I finally went and did it - I implemented a WYSIWYG post editor for LnBlog (that's the software that runs the blog you're reading right now).

I've been holding out on doing that for years.  Well, for the most part.  At one point I did implement two different WYSIWYG plugins, but I never actually used them myself.  They were just sort of there for anybody else who might be interested in running LnBlog.  I, on the other hand, maintained my markup purity by writing posts in a plain textarea using either my own bastardized version of BBCode or good, old-fashioned HTML.  That way I could be sure that the markup in my blog was valid and semantically correct and all was well in the world.

If that sounds a little naive, I should probably mention that I came to that conclusion some time in 2005.  I had only been doing web development for a few months and only on a handful of one-man projects.  So I really didn't know what I was talking about.

Now it's 2014.  I've been doing end-to-end LAMP development as my full-time, "I get paid for this shit" job for almost seven years.  I've worked for a couple of very old and very large UGC sites.  I now have a totally different appreciation for just how difficult it is to maintain good markup and how high it generally does and should rank on the priority scale.

In other words, I just don't care anymore.

Don't get me wrong - I certainly try not to write bad markup when I can avoid it.  I still wince at carelessly unterminated tags, or multiple uses of the same ID attribute on the same page.  But if the markup is generally clean, that's good enough for me these days.  I don't get all verklempt if it doesn't validate and I'm not especially concerned if it isn't strictly semantic.

I mean, let's face it - writing good markup is hard enough when you're just building a static page.  But if you're talking about user-generated content, forget it.  Trying to enforce correct markup while giving the user sufficient flexibility and keeping the interface user-friendly is just more trouble than it's worth.  You inevitably end up just recreating HTML, but with an attempt at idiot-proofing that end up limiting the user's flexibility in an unacceptable way.  And since all the user really cares about is what a post looks like in the browser, you end up either needing an option to fall back to raw HTML for those edge-cases your idiot-proof system can't handle, which completely defeats the point of building it in the first place, or just having to tell the user, " Sorry, I can't let you do that."

"But Pete," you might argue, "you're a web developer.  You know how to write valid, semantic HTML.  So that argument doesn't really apply here."  And you'd be right.  Except there's one other issue - writing HTML is a pain in the butt when you're trying to write English.  That is, when I'm writing a blog post, I want to be concentrating on the content or the post, not the markup.  In fact, I don't really want to think about the markup at all if I can help it.  It's just a distraction from the real task at hand.

Hence the idea to add a WYSIWYG editor.  My bastardized BBCode implementation was a bit of a pain, I didn't want to fix it (because all BBCode implementations are a pain to use), and I didn't want to write straight HTML.  So my solution was simply to resurrect my old TinyMCE plugin and update it for the latest version.  Turned out to be pretty easy, too.  TinyMCE even has a public CDN now, so I didn't even have to host my own copy.

So there you have it - another blow stricken against tech purity.  And you know what?  I'm happier for it.  I've found that "purity" in software is tends not to be a helpful concept.  As often as not, it seems to be a cause or excuse for not actually accomplishing anything.  These days I tend to lean toward the side of "actually getting shit done."