I honestly couldn’t even remember what the project was that made me want to try circuits, but anyway, I went ahead and recreated (roughly) the situation in the post.

Here’s that code: http://circuits.codepad.org/qJvRYhDX

I was hoping that with the newer release, I’d be able to figure it out. But still no luck. Fortunately, James Mills, the author of circuits stepped in to help out. Here’s his solution: http://codepad.org/N9Nsx7qi

I really don’t see how I could have figured it out on my own — even going through the source. Circuits is so different that it takes a solid understanding of how it works on a fundamental level. And while I think it’s an interesting project, I really am not interested in getting that in-depth with it. Well, at least not now.

I apologize to James for the hot-headed post and I’m hoping to keep cicuits on my radar in the future.

But that’s where the praise ends. Long story short, I have no faith in their crew. They don’t know what they’re doing and I would almost guarantee a surprising amount of monthly downtime. Do yourself a flavor and stay away.

Now, I’m looking for a host again. Or maybe not. It’s not exactly worth it at the moment.

So I’ve been working on a new site. It’s been difficult due to a lot of different reasons, but:

0. I’m absolutely staying away from WordPress and PHP.

1. I started writing my own blog engine and I decided about 80% through it that I’d rather use something that already exists and has a userbase and all that. I do, however plan to continue working on it.

2. I looked at a system called blohg which sounded interesting, but I soon realized I’d lose all of my old entries.

3. I settled on Mezzanine, but just haven’t had time to get a theme together and publish the site.

The decision to move away from WordPress is part of an epic rant that I want to save for the publishing of the new site. I was originally hoping to have it launch today, but since I can’t, this is as good a place as any…

Happy 15th anniversary to my humble slice of the internet. :)

I don’t get it. They never end and they’re more or less pointless.

My response to all of them: everything sucks. It’s just that something suck less than others. The rest is just personal preference.

If everything was good and great with computers, we’d all still be programming in Fortran or COBOL or something. Today’s languages aren’t perfect, and in 20 years we’ll all be wondering how we ever did anything in Javascript or Ruby or Python.

Of course Django sucks. Know what sucked more before that? Subway, Webware, and the other frameworks that have been discontinued. When I first started with Python, I tried several times to work with the Myghty framework. Then Pylons came along and I realized how much trying to set up Myghty sucked. Even though the early versions of Pylons used Myghty for templating, it was still better than trying to use just straight Myghty.

I like Django. It’s been great for some projects. I also like Flask — it’s nice and easy and small and fast. But Flask also sucks. I can make quite a mess of Flask projects if I’m not careful. I can also make Flask projects so complicated that they basically mirror Pylons or Django set ups… which sucks.

OK so I don’t think that every single piece of everything sucks. But if there wasn’t some kind of dissatisfaction with our tools, we’d never get better tools. Just remember that everything we’re using now is, ultimately, temporary.

A few weeks (or possibly months) ago I was asked (axed) by Travis Peterson of No Starch Press to review The Linux Command Line. More accurately, he was referred to me by Pat from patorjk.com, who was too busy. No shame in being second choice…right? However, I will be adding this to my, “List of Reasons I became a Supervillain,” essay.

Anyway, I said yes. So here we go with the review. The usual caveats apply: YRMV, YMMV, IANAL, ONHD’T, MMSBATBTTY.

Here’s a link to the book.
Here’s a link to No Starch’s front page.

The Linux Command Line: A Complete Introduction by William E. Shotts, Jr.

To be honest, I wasn’t sure what to expect from a book about the Linux (specifically) command line. I personally really, really, really hate sysadminning. I try to avoid it, any way that I can. Trying to remember a billion different commands and config files and programs, it just is not my idea of fun.

When I read the description of the book, I thought it would be a nice reference book to have for some of those programs I can never remember how to use, like sed, awk, … ls, etc. But the author seems to have a different opinion on what this book is. To quote the introduction, “…it’s really more like a story with a beginning, a middle, and an end.”

I’m still not sure if this is meant to be facetious or not. Jokes don’t always transfer well over to text. But, the book is basically a reference book. Novels and short stories don’t have indexes. There are some more examples than what I remember from similar style books, but overall, it’s pretty similar.

The meat of the book is pretty standard fare. Lists of different programs, how to use them, etc. There’s a decent introduction to Vim in there as well as some explanations on concepts such as compression, signals, and compiling programs, just to name a few. The book ends with shell scripting for Bash and a few programming techniques that a sysadmin should probably know about.

Overall, it’s not a bad book. I kind of understand the author’s desire to set it apart from other books in the same arena by targeting Linux specifically and saying it’s not a reference book. But all-in-all, I don’t see it as that far apart from other books. Nearly anything you pick up on the subject will get the job done. If it happens to be this one, you shouldn’t be disappointed.

The ORM in this case is phpActiveRecord. I had used this in other projects and had a generally positive experience, so I thought it would be a decent fit for this quick little user registration database I had to set up.

Of course, I had neglected to check whether or not phpActiveRecord worked with PostgreSQL. Silly me, when I looked at this page and saw ‘pgsql’ in a DSN, and when I read that PDO is used for the backend — which provides a decent API for the library to use — I assumed that I would be safe.

In short terms, no. In longer terms, fuck no.

There’s an error, apparently in all versions that I could find, in the pgsql adapter. I guess there were some attempts to fix it, but it remains uncommitted to the main branch, despite being a year old.

So good-bye to phpActiveRecord. It was fun, that one time when I used you and you worked correctly. You can now join the wall of shame with lack of PostgresQL support along with WordPress and Drupal. (Yes, I know Drupal core has at least partial support, but modules may not necessarily support pgsql — which could have been avoided with a decent ORM).

The saga continues… sigh…

Fast forward to a few weeks ago when I hear about circuits.web, part of the circuits framework. Event driven, modeled after CherryPy, asynchronous, web-socket support, and loosely coupled — which I need this time.

I’ve spent the better part of three weeks working with circuits.web, and I can say it’s been a resounding disappointment.

First of all, documentation is non-existent. And when I say non-existent, I mean non-existent. The core circuits framework is poorly documented at best. The circuits.web component isn’t documented at all. The closest thing to documentation is a collection of asinine examples that have almost no merit for real life applications, if they even work at all.

Second, I can’t exactly tell if the project is still being worked on. When I first started, I naively looked at the dates on the recent commits to the whole circuits project. The circuits.web portion hasn’t been committed to since August. WebSockets were made a candidate recommendation in December. Nothing in circuit.web’s implementation needs to be changed? That makes me suspicious.

Lastly, the Component architecture seemed like a good idea, but it seems to be thrown together in no logical way. Case in point?

Components handle events. Controllers inherit from Components. Controllers can’t handle events. Or if they can, I couldn’t figure out a way. Who knows why — there’s no documentation.

I was trying to create an Authentication component for an admin controller. There are of course, no examples of this. The authentication examples — that is the ACL, HTTP Auth, and HTTP Auth using /etc/passwd — all use an authentication scheme that is site wide.

What I needed was a way to pick specific actions that would require authorization. I figured out a way by accident, and within 3 seconds found a way around it due to the “channel” member of the Controller.

The channel in circuits.web, I assume, specifies the routing for the dispatcher to find the object. So your Admin Controller object might have a channel of “/admin”. The problem I found, using a Component for forcing authentication, I could bypass the Auth Component by going to, “http://localhost/admin/“. Note the trailing slash.

Change the channel to “/admin/” or “admin” and get a 404 on all admin actions — but the auth component works.

And that’s where I’m at. I should have went with CherryPy on this project, but no, I guess I felt like being disappointed by Python web frameworks again.

Anniversary

This site turned 14 on Dec 4th. I swear I didn’t forget this year. I was going to post on the 5th, but I couldn’t think of anything besides, “The site is 14. Yay.” … and I still can’t think of anything better. So… yay.

Drupal

I no longer have confidence in Drupal. Not that I ever had much, but after spending 6 months working with 5 or 6 Drupal 7 sites, I don’t know why anyone uses it or continues to develop it. There are a few reasons to list, but the long and short of it is the database.

Drupal’s “Field” feature is important and necessary for nearly every project, and I use it quite a bit. On one project, I had at least 30 unique fields for different content types. The problem is that for each field, two database tables are created. Yes, not just one table, but two.

So my project that has 30 unique fields now has 60 extra tables. Sixty. This is in addition to the numerous tables that are created by default and the different modules. This creates unbelievably long queries with so many joins that use so much memory and are so slow. I don’t know where that decision came from, but it feels like it was a bolted on solution. Drupal 7 breaks compatibility with previous versions in almost every regard, so why not just rewrite the storage paradigm?

So which CMS then?

I don’t have an answer. I started toying around with several Django based CMSes, Plone, and other Python solutions. All of them have their drawbacks, but mostly, they are far too elaborate and massive for the type of projects I do.

So I’m going to roll my own. I’m aware of the, “why reinvent the wheel,” argument, but if you’re never fully satisfied with the wheels available, why settle?

Currently, I’m thinking about a Python system with ZODB as a storage engine. But…

Python library developers make me nervous

The way I see it, there are 3 levels of  developers for most languages:

1. The core developer — works on the language and/or standard library
2. The library/extension developer — creates projects to ease pains caused by the stdlib, to speed development along and to add specific functionality not provided by the stdlib. E.g., Django, Pyramid, SQLAlchemy, Zope, etc.
3. The application developer — works on projects that integrate various libraries to create something for end-users. E.g., Me.

I’ve been working with Python since 2005 or 2006 — not a very long time. Yet I’ve picked so many libraries that have been superseded, barely updated, or flat out abandoned. To name a few, Spyced, Aquarium, Webware/WebKit, Pylons, Cheetah Templates, ZSI, PyXML, Glashammer, Google AppEngine, mod_python and who knows how many others.

Over the past 6 months, I’ve really had the Flask and Jinja projects grow on me. So much so that I started working on the aforementioned CMS with them. But over the same period of time, Armin Ronacher – the creator of Flask, Werkzeug and Jinja  – has written some things on Python 3 and WSGI that make me worry that I once again bet on the wrong horse.

This isn’t meant to be a dig at him at all; I love the work that he’s done. I just can’t believe my luck. And it’s not just a Python thing. Javascript, C, Assembly, PHP…I’ve been picking libraries this way since I the days when I was starting a project with WinG just before DirectX started to break.

This is why I do not gamble or own stocks.

Ding Dong, the wicked jQuery plugin site is dead

jQuery is getting a new plugin site due to an “accident” on the existing site. I use “accident” loosely, because it was limping along, gasping for air, on life support, and mostly brain-dead since it’s inception. (Do note that the old plugin site ran Drupal)

The new plugin site will be based on github or something.

The point is I plan to have both of my plugins up there at some point.

And that’s about it

I’ll be back before 6 months… maybe :)

Delayed Event Plugin page

Zipped source and example

Enjoy. I hope it’s useful for other people.

Oh, I should mention… As with the Timer plugin, I have no interest in maintenance or support. So, unless there’s a major security problem or giant leaking of memory, I don’t really care. I didn’t put a lot of thought in to designing an API or anything. You should feel free to modify the code as you see fit.

Django is still a pleasure to work with

I developed a site a little over a year ago using Django (1.2) and just completed some updates. Even after updating this code multiple times, it hasn’t become messy. For content oriented sites, Django rocks. Plain and simple. For things more complex, core Django would probably stand up. For the admin tool, I’m not so sure. I couldn’t see it being good in every situation — if you have to customize it too much, you might be better off writing your own admin interface.

I’ve been managing the database schema with South — which is probably one of the best programs I’ve ever used. Everything just works. I haven’t run in to an issue where an automatic update didn’t work, but then again, this site isn’t the most complicated site.

Lots of people don’t understand Pyramid

I have my own personal gripes with Pyramid. But over the last few months, I’ve seen a lot of posts looking for help understanding the “new” aspects of Pyramid: namely, the repoze/traversal/zope portions of it. The typical response is: ignore the parts you don’t understand. So the Pyramid developers spent all this effort, all this time, to improve their framework, write documentation about how it’s better and how it’s different and how the complaints users have about it are unfounded, to say ignore key parts about it and to even go so far as to write a wrapper to make it more like the old framework.

Forget understanding the framework… I just don’t understand its developers.

Do framework developers not understand framework users?

I found this article a few weeks ago — a run down of a presentation by Russell Keith-Magee at Djangocon. My particular interest was in the following quote:

Microframeworks. How on earth can an april fools joke like Flask get actual traction? Turn into a popular framework? Django is lots and lots smaller than zope, but these new ones are even smaller. What is small? What is micro? Could we adopt some? Can we become more attractive? We should think about this.

It’s simple. Flask is better documented than 95.2187% of all the web frameworks available for Python. On the other hand, Django is documented better than 99% of all of them. When it comes to web programming, there’s no such thing as a silver bullet. Django is > 6MB. Some people think that’s too big. Some people don’t like Django’s ORM and/or template system, and rather than spend effort changing it, would prefer to start with something that doesn’t force these things upon you.

Maybe instead of trying to figure out how it gained traction and how to apply “the marketing” of a project to your own, maybe try to figure out why users like it.

In conclusion, WTF?

Apparently, there is a pretty serious bug with Drupal 7.2. Also, a fix has been found and applied in SVN/CVS/Whatever. But, they are waiting for 7.3 I guess to roll out this fix?