Code / Appnel Solutions 

On Testing

A recent thread on the cgi-app mailing list discussed testing that is really worth noting.

The key statement came from Jason Purdy when he said:

My advice would be to factor your code such that the code is separated into a testable module.

I admit to being slow to developing tests for my work once I did I came to realize that this statement above to be very true. Once writing tests where introduce in to my development process it changed how I wrote the code, not only to make writing tests easier and more thorough, but for the betterment of the code.

I’ve yet to break the habit of writing code and then the tests. (Testing advocates suggest you write tests upfront.) This one has been harder for me because often start from existing code, experimenting and capturing ideas that slowly gets molded into working code. On a few occasions I had a written a piece of code before I realized I was doing it.

I’m strange though and this is not an argument or excuse to follow good form.

[Read more →]

Driving Movable Type Debrief

Steve Ivy gives his commentary and observations since trying out MT 4.1 — while commuting home. (That’s maximizing your time!) I think his comments are fair and quite evenhanded views (Do I sense a trend?) of a tech and blog savvy, but new to MT user. His comments of the documentation and getting started developing are quite sound. So much effort has been put into the user experience and interface of the tool that documentation and developer issues have been neglected. As I’ve mentioned before, getting to know how to make the most of MT requires a lot of detective work to reverse engineer what is happening in the system. This is why I am such a stickler about the the clarity and elegance of the MT API and its underlying code. When documentation fails to deliver in an open source tool the buck stops here at the code.

Movable Type 4.2: The Performance Optimization Release

For those of you who are not paying very very close attention to the MTOS repository and developers list, the details of MT 4.2 have been released and development has begun in earnest.

In summary MT 4.2 will focus on performance optimization and enhancements. MT 4.0 and MT 4.1 added a lot of great functionality and user experience improvements at a break neck speed. In all the wake of all that activity is a lot of unoptimized code. So this release is not is slated to begin addressing those issues and nothing more. (Somehow I think that will change and engineering will slip a few by product management. Just a hunch though.)

Already a new version of MTOS 4.1.1 has been release with a performance logging and monitoring framework in place. This work was closely followed by modularizing the gargantuan MT::App::CMS, a library/module that contained all the functionality of the MT CMS application weighing in at and approaching 1MB in size, in to many smaller modules. (A running log of performance enhancements are here.) Byrne Reese reports significant improvements in the memory usage and response times of early tests.

So far the previously mentioned memory leak problem does not seem to have been addressed which is a real bummer because it affects the largest most high volume installs that need these better performance the most. I could be wrong as I have not tested the latest rom the repository, but I have not seen anything in the commit logs that indicates changes have been made in this regard.

Bummer

Recently the MT 4.1 release notes where amended with a new important advisory for systems using the PublishQueue and/or FastCGI.

Advisories

• Due to a memory leak in Movable Type template parser, large scale web sites are advised not to use Publish Queue in daemon mode or FastCGI for the time being.

This news is a bit old, but worth noting since it will eventually bring a server to its knees. That is a bummer. For most users there is little impact sine run through CGI the leak memory gets cleaned up after each request. This is a problem for optimized and high performance systems like the ones I and other ProNetters build.

I had hoped that a fix/patch was released by now, but it hasn’t to date. I have ti on good word this is actively being worked out. I also know the community has made their offerings and there has been some activity in the public repository to this affect though. In the meanwhile you may want to take precautionary measures such as not using the PublishQueue and, if you are running FastCGI, periodically restarting your web server to clear out the leaked memory.

Open Source Is Not Just a License

Last week during a discussion about implementing a dispatcher in MTOS that Reed Cartwright proposed I made some comments about what direction the code an architecture should go that a number of people seemed to like. I thought I’d repost them here.

IMHO, there are other more important reasons for migrating away from homebrew solutions and to module in CPAN that exist beyond MTOS.

One is effectively leveraging resources. What does MT gain from having its own application framework? (I can ask this same question of JavaScript frameworks and some other things in MT.) How will that differentiate MT from other tools? How does it improve the user experience or get more people using the tool? It doesn’t. Could the engineering resources of Six Apart and this community be put to use on other things where the questions are true or an alternate does not exist? I’m pretty sure the answer to that is yes. So if there is a passionate community of developers that have put a lot of time, effort and field testing in to a library that provides essentially that same functionality, I’m all for it so we can work on the things that really need it.

Another is in better embracing open source. While my first point is more operational, this one is more PR. Releasing MT under the GPL is a good first step, but there is still a certain level of mistrust (I’m not suggesting that its founded or not) nor are open source developers knock[ing] down the MTOS doors to contribute. Drawing in developers from other communities with some of the tools they are already familiar with and using would IMHO contribute to generating more interest and breaking done the walls that I believe many believe surround MT. Conversely taking parts of MT that don’t exist in the Perl/CPAN world (the template engine, registry, Promise, FileMgr ) and breaking them off as their own standalone library would have a similar effect in my experience. Developers are more likely to write MT like apps that borrow from how it works indirectly learning about MT and perhaps contributing back to its development. Doing both of these clearly demonstrate that Six Apart is serious about MT as open source software and that there is something to gain by contributing.

Action

From a comment by Anu Gupta on the Movable Type site:

Communities are about giving as well as taking - so if you’re concerned about the lack of “action” in the forums, hey, roll up your sleeves and help, rather than just whine from the sidelines and post unsubstantiated gripes about the “multitude of woes” that people are experiencing.

If you’ve got real issues, and you’ve paid for a license, then raise a support ticket. If you’re moaning about what’s not present in the OS version, then hell, dive into the code and start fixing stuff, or engage with the community to see what’s possible, or pay someone to develop something.

On The Gulf of Execution and Other Development Principles

Besides object-oriented modularization I’m big on code readability. So the first thing I ideally like to see is readable code because in my experience that flattens out the learning curve and lowers the barrier to entry. The more people doing things and the faster the better the tool/platform/library becomes.

Part and parcel to that is what I’ve now come to learn is essentially called the Gulf of Execution. Take Michael Schwern’s post on LWP::Simple that he made on the Beautiful Code weblog.

Before I had read Michael’s post and the Gulf of Execution principle, in my less refined way, I thought of this as a “layered approach.” It’s simple and fast to get started using something, but you can keep peeling away layers of abstraction as needed to do more advanced and sophisticated things. One simple layer is never sufficient because it fails to heed The Law of Leaky Abstractions.

Of course you can always take any of this too far — balance is another crucial thing I consider. Jon Udell referred to this as being an “extreme anti-extremist.” I try to follow that principle, but in blogging and MT communities that sort of thing doesn’t seem to get you very far sometimes.