Posted by Scott Laird
Fri, 21 Jul 2006 17:03:12 GMT
I just committed the last big chunk of code for Typo 4.0.0: improved spam filtering. We now know about Akismet, and will use them for spam filtering if you enter an Akismet key on Typo’s setttings page. Incoming comments (and trackbacks) that fail the spam check aren’t published unless the blog owner approves them via the handy new ‘feedback’ page.
I really want to get Typo 4.0.0 out before Monday, so please pound on this and let me know how it goes.
Tags spam, typo | 2 comments
Posted by Scott Laird
Tue, 11 Jul 2006 18:00:21 GMT
One of the dirty little secrets of Typo development is that this blog has been running the same Typo snapshot for almost 9 months. I’ve added a lot of code to Typo, but I haven’t been eating my own dogfood. There are several reasons for this, but the biggest was my threaded comment patch from early last year. It wasn’t merged into the trunk, and over time my blog and the Typo trunk diverged to the point where it wasn’t really practical to merge them anymore.
I finally gave up today and ditched my threaded comment code. I’ll rewrite it for Typo 4.1.
The migration to the current Typo trunk was reasonably painless, but it took most of an hour. I have more content then most users, and I’m running on slower hardware, so an hour is probably the worst-case scenario.
Now that I’m on the trunk, it’ll be a lot easier for me to test out spam filtering techniques here before committing them for general consumption.
Let me know if you see anything broken.
Tags blog, typo | 3 comments
Posted by Scott Laird
Mon, 10 Jul 2006 16:56:07 GMT
We made a lot of progress this weekend on Typo. We’re down to 9 open tickets, and several of those aren’t really code issues–things like “set up a Typo blog on http://typosphere.org” (which is mostly done, actually). There are a few bugs left, and one or two minor development points, but at this point the thing we really need most is some testing. If you use Typo, then I’d love it if you could either test the latest trunk or the latest .gem release (sudo gem install typo; typo install /some/path) and file bugs.
Tags installer, ruby, rubyonrails, typo | 13 comments
Posted by Scott Laird
Sat, 08 Jul 2006 19:02:00 GMT
I think I just killed The Great Typo Memory Leak of 2006 (not to be confused with last year’s great memory leak).
I think this was the leak that has been causing so many problems for Typo users on shared hosting systems lately. I’d been putting off debugging it, because there really aren’t any good tools for Ruby memory leak tracing, and there’s enough magic in Rails that makes it hard to even fully understand the control flow in your rails app, much less when memory is being allocated and freed.
Since Typo 4.0 is nearly ready for release, I was running out of time to fix it. Fortunately, during some benchmarking this morning I discovered something useful:
- With the cache disabled, my Typo processes stay around 30 MB.
- With the cache enabled, my Typo processes grew to 70 MB within a couple hundred hits to the same URL.
Since the cache-hit path is about 1/100th as long as the cache-miss path, it’s a lot easier to debug. And since we’re using our own reimplementation of Rails’s Action Cache, I have a decent understanding of the caching code. As it turns out, though, I think the normal action cache would have had the same problem.
The problem was that we have multiple before and after filters, and at least one of them saves state in the before filter and expects the after filter to free it. But suppose our filter order looks like this:
stateful_before_filter
action_cache_before_filter
render a page
action_cache_after_filter
stateful_after_filter
The problem is that the action cache’s before filter will cancel the rest of the render chain if it gets a cache hit. So stateful_after_filter will never be called. So, whatever stateful_before_filter saved (by shoving it into a class variable, for instance) is now with us forever.
In general, you should be able to fix this by adjusting the order that you apply your filters. The first call to around_filter goes on the outside and all further calls are nested inside it. However, Typo currently applies a couple filters in a superclass controller, so there’s no easy way to move the caches_action call into the superclass. So, as a workaround, I changed the call to around_filter in caches_action_with_params to be prepend_around_filter instead of around_filter. Now my Typo processes stay around 32 MB even after thousands of cached hits.
Longer-term, I want to clean up our controller hierarchy, because I don’t fully understand why we need multiple layers of stacked controller classes when 95% of Typo is in one controller. But for now the memory leak is fixed and we’re back on track for Typo 4.0 in the next week or so.
There’s a lesson here to other Rails users–be careful nesting filters when you’re using the action cache (or any filter that can terminate the request), because you can’t depend on the after_filter being called. If you save things in the before_filter, expect leaks unless you’re very careful with your filter nesting order.
Tags filters, ruby, rubyonrails, typo | 6 comments
Posted by Scott Laird
Thu, 06 Jul 2006 16:39:16 GMT
I did a bunch of Typo bug triage this morning, and road to Typo 4.0 finally looks clear. We currently have 8 open Typo 4.0 tickets, and none of them look very difficult. I’m still waiting for more feedback on the Typo Installer, and that’s really the biggest issue keeping Typo 4.0 from being released now. I expect that it’ll take a week or so before I’m comfortable enough with the installer to release it to the general public.
If there’s something that you really want to see in Typo 4.0 that isn’t already in the tree, then this is probably your last chance to speak up.
Tags ruby, rubyonrails, typo | 1 comment
Posted by Scott Laird
Thu, 06 Jul 2006 03:42:55 GMT
Hot on the heels of this morning’s Typo 3.99.0 release comes Typo 3.99.1. Somehow, 3.99.0 worked much better on my laptop then it’d work anywhere else in the world. Oops. Give the new version a try if you want to test out the new installer.
Tags ruby, rubyonrails, typo | no comments
Posted by Scott Laird
Wed, 05 Jul 2006 15:57:20 GMT
I just uploaded a gem for Typo 3.99.0 to Rubyforge. Once it propagates, people should be able to test the new Typo installer by running two simple commands:
$ gem install typo
$ typo install /tmp/typo
This is a test release; please don’t overwrite your existing, working Typo build with the new Typo installer.
I’d love to get some feedback from people about the installer, though. If you have a chance, give it a shot and let me know if it works. It should pull in Rails 1.1.4 and Mongrel all on its own, and then freeze the Rails gems into vendor/. I had to write my own Rails freeze code, because rake rails:freeze:gems won’t let you specify which Rails release you’re freezing, and I’d like to allow people to continue to install Typo even on systems that have Rails 1.2.x installed. I could have just bundled all of Rails into the Typo gem, but that’d be an abuse of the packaging system. As it is, it should all ‘just work’.
I still have a few things that I need to do before the installer is complete:
- Actually write the Apache HTTP proxy instructions (for 1.3 and 2.x)
- Add lighttpd proxy directions.
- Figure out how to best have Typo restart on reboot.
- Handle the ”missing swig” problem better.
- Figure out of the installer will work on Windows.
We also have a couple issues remaining before Typo itself is ready to be called 4.0.0, but we’re getting pretty close. If a few people could test this pre-release for us, then we should be able to get 4.0 out within a week or two.
Update: Expect 3.99.1 in a few hours. There are a couple substantial installer bugs when running from the .gem file. They aren’t dangerous, but they’ll keep it from working in many situations.
Tags ruby, rubyonrails, typo | 8 comments | no trackbacks
Posted by Scott Laird
Mon, 03 Jul 2006 16:21:04 GMT
If I’ve learned anything from Typo, it’s that Rails apps are a serious pain for first-time users to install. Here’s what it takes to get Typo (or any open-source Rails app) up and running on a random Unix box today:
- You need a working database, like MySQL or PostgreSQL.
- You need to know how to create at least two databases for Typo.
- You need Ruby 1.8.4
- You need rubygems installed.
- You need Rails 1.1.x
- You need Ruby drivers for your DB.
- You need Ruby FCGI drivers installed
- You need a web server with FCGI installed
- You need to download Typo and figure out how to install it without a useful README.
- You need to configure your web server to run Typo’s FCGI dispatcher.
- You need to get all of the permissions right, especially if your web server runs under a different user ID then you normally use.
Sometimes I’m amazed that Typo has as many users as it does. I’ve been promising to do something about this for months, and it’s finally getting close to working. Here’s what you’ll need to do to get Typo running once I’ve released the installer:
$ gem install typo
(installs Typo, Rails, mongrel, sqlite3-ruby, and whatever else we need, as defined by the Gem spec)
$ typo install /var/www/my_typo_site
Typo Installer
Checking for existing Typo install in /var/www/my_typo_site
Reading files from /usr/lib/ruby/gems/1.8/gems/typo-4.0.0
Copying 755 new files into /var/www/my_typo_site
copying /CHANGELOG
copying /MAINTAINERS
copying /MIT-LICENSE
...
Creating default database configuration file
Creating initial Typo SQLite database
Migrating Typo's database to newest release
Running tests. This may take a minute or two
All tests pass. Congratulations.
Starting Typo on port 4936
Typo is now running on http://scott17.local:4936
Use 'typo start /var/www/my_typo_site' to restart Typo after boot.
Look in /var/www/my_typo_site/installer/apache.conf.example to see how to integrate Typo with Apache.
The installer sets up a complete Typo installation from a Ruby Gem in a directory of your choice, and then take care of creating a SQLite database for you. Instead of FastCGI, it uses Mongrel, because it’s easier to do HTTP proxying then FastCGI 95% of the time. The same installer knows how to upgrade an existing Typo install–just run typo install on the same directory again, and it’ll shut down mongrel, back up your database, upgrade all of the files that need changed, run migrations, retest the installation, and then restart Mongrel.
This isn’t the ideal install for everyone, but it should be good enough for most people, and there’s really nothing preventing people from hand-installing Typo. There’s certainly nothing preventing people from using Capistrano or any other heavier-weight management system, but that’s overkill for most personal blogs.
Right now, the installer works for me, but it’s not quite ready for wider use. I still need to add Rails freezing support, as well as a bit of subversion support, and I need to clean up the code a bit more. Once that’s done, I’ll check it all into the Typo trunk and then I’ll start building Typo 3.99.x GEMs for people to test. Once we’re reasonably confident that the installer and the current trunk work for people, I’ll go ahead and release Typo 4.0.0.
Once Typo 4.0 is out, I’ll see what I can to do extract the Typo installer into a generic installer for lightweight Rails apps. I doubt that Typo is the only project that could use something like this.
Tags ruby, rubyonrails, typo | 8 comments
Posted by Scott Laird
Sun, 02 Jul 2006 00:40:00 GMT
I just released version 1.0.3 of the Rails Schema Generator. This is a minor release; I added a db/schema_version file. This is needed for the Typo installer, which should appear reasonably shortly.
Tags ruby, rubyonrails, schemagenerator, typo | no comments
Posted by Scott Laird
Sat, 01 Jul 2006 21:26:23 GMT
I’ve been trying to get Typo working with SQLite 3 on my Mac off and on for MONTHS with no success. The root problem was simple:
a = Article.new
a.title = 'Testing'
a.save => true
a.id => 0
Somehow, the ID wasn’t being updated whenever new ActiveRecord objects were created. They’d end up in the DB just fine, but the new ID wasn’t visible from Ruby. Since this is a really basic feature of any ORM, I was really amazed that it didn’t work. A bit of research shows that SQLite and Rails work fine for most users, but I’m not alone with this problem–there are a few reports of similar problems on the Rails wiki.
For the fun of it, I installed SQLite on one of my Linux boxes, and everything worked fine there. So I tried installing a newer SQLite via DarwinPorts, with no improvement. I spent a couple hours uninstalling and reinstalling things, and nothing changed anything. Digging deeper, the bug was clearly deep inside of sqlite3-ruby–it was telling Rails that the ID number for the latest insert was 0.
I finally figured out the problem here at Gnomedex today while watching to the Gillmor Gang record their latest podcast. It’s simple:
The SQLite bindings for Ruby require SWIG. If SWIG isn’t installed, then they’ll still work, sort of, but they fail to fetch the ID from SQLite.
So, to fix the problem, I just ran port install swig, then gem uninstall sqlite3-ruby and gem install sqlite3-ruby.
There’s probably a endian problem in the non-SWIG SQLite Ruby code, but it’s easier (and probably faster) to just install SWIG.
Tags macosx, ruby, rubyonrails, sqlite, typo | 3 comments
Posted by Scott Laird
Sat, 24 Jun 2006 18:53:54 GMT
Don’t get your hopes up too high, but I’ve finally had a bit of time to work on Typo again. Hopefully this will continue, and I’ll be able to fix the current round of bugs and finish the Typo installer that I’ve been promising for months. Once that’s done we’ll finally release 4.0.
I’m a little uncertain how involved I’ll be with Typo after 4.0 ships. On one hand, I have a few things I’d love to add. On the other hand, I’m really a terrible maintainer–I’m much better at adding new features then applying waves of bugfixes week in and week out.
So we’ll see how it goes. There’s a lot of admin work that I’d really like to do, and spam blocking is getting more and more important. And there are some microformat things that I’ve been itching to do for months.
Tags rubyonrails, typo | 2 comments | no trackbacks
Posted by Scott Laird
Wed, 21 Jun 2006 12:48:00 GMT
This is just a quick test–does the open-source version of KABLOG work with the E61 and Typo?
Answer: mostly. It posted okay, but died in the middle, presumably because I received a phone call and the GPRS service was disconnected during the call. I can’t add keywords (hence no tags in Typo) and I can’t disable trackbacks (which are too spammy to be useful anymore). But I’m able to post, which is a step in the right direction.
Does anyone have any suggestions on blog editing software for the Nokia E61, or any Series 60 third edition phone?
Tags nokiae61, typo | 2 comments
Posted by Scott Laird
Wed, 01 Mar 2006 14:54:22 GMT
We’ve been talking about releasing a new stable version of Typo since October, with no real success. Frankly, I’ve only spent a few hours per month on Typo since I started working for Google in late November, and that’s not enough to get a major release out. Fortunately, most of the weirdness in my personal schedule seems to be over, now that I’m done commuting back and forth between Seattle and Silicon Valley once or twice per month. I still don’t have as much free time as I used to (Google keeps me busy), but I’m not spending every minute preparing to travel and dealing with the consequences of life on the road.
So, now that I’m back on a normal schedule, it’s time to get serious about releasing a stable version of the current Typo trunk. I’d like to release Typo 4.0.0 before April 1st. Frankly, 95% of the features that we want for Typo 4.0 are already in the tree, so mostly we just need bug fixing and testing. There are a few features that need some finishing work, and one feature that still needs to be implemented, but late March should be workable, if people can pitch in and help a bit.
As I see it, here are the areas that we really need to work on:
- Trackbacks (they’re still utterly broken)
- Podcasting (cleanup and testing)
- Notifications
- Threaded comment support (optional)
- Migration cleanups
- Merge one or two theme contest themes.
- Bugs, bugs, bugs
I should probably explain the “threaded comments” bit–months and months ago, I wrote some threaded comment code for Typo. Tobi didn’t want it in Typo, so he (correctly) refused to merge it. I’m still using my threaded comment code here, maintaining it in parallel with the Typo trunk. The problem is that there’s no easy way to merge the old threaded comment code with Piers’s big STI patchset, so I’m stuck running an older version of Typo here. I can’t upgrade without either losing all of the threading information that I’ve accumulated or spending some time adding minimal threaded comment support to Typo. I’ve discussed my Big Plan for comments in Typo, but I don’t think I’ll have time to implement everything in the next month; instead I want to concentrate on getting something released, and then we’ll spend some more time enhancing comments for Typo 4.1.
There’s one big thing that I need from people if we’re going to be able to make this schedule: help getting back on top of all of the bugs in Typo’s Trac. We were trying to keep the number of open tickets below 50 for most of last year, but now we’re up to 165, and that’s too many for me to easily manage. So, I need to start applying patches and closing them. If there’s a patch that’s ready to apply, or a simple ticket that doesn’t need more then 5 minutes worth of work, can you please leave a comment here? Thanks.
Finally, to answer the inevitable question: where is Typo 3.0, you ask? Months ago, we decided to skip version 3.0, to avoid confusion with Typo3. So we’re going from Typo 2.x to Typo 4.x. That’s it.
Tags ruby, rubyonrails, typo, typo4 | 20 comments
Posted by Scott Laird
Sun, 22 Jan 2006 16:41:47 GMT
I just committed my time-limited Rails cache to the Typo trunk. This is an outgrowth of my improved action cache, and fixes most of the caching problems identified in the Rails caching presentation that I gave a few months back.
I haven’t benchmarked it yet, and I’m sure that it’ll need a bit of tuning, but it solves so many architectural issues for Typo that I went ahead and committed it anyway.
It’s currently implemented as a Rails plugin; I’ll probably bundle it up as a stand-alone plugin once I’m happy with the way it works with Typo.
Tags cache, rubyonrails, typo | 1 comment | no trackbacks
Posted by Scott Laird
Fri, 20 Jan 2006 17:25:02 GMT
I’m finally getting back into Typo hacking after too long away. I tried to apply a few patches last weekend, but I was traveling and my network access was too spotty. So, I spent my time adding a bit of new functionality. Since then, I’ve been debating whether to commit it to Typo or not. I decided I’d write about it here and see which way the comments go.
The code in question is a time-limited cache for Rails. I’d like to be able to say “cache this page, but only for three hours. After three hours, re-render the page.” This sort of thing comes up in Typo all the time. The most obvious example is the sidebar–some of the sidebar components display information with a short lifetime, and it’d be dumb to keep pages in the cache for weeks when they include sidebar data that’s only good for hours. This isn’t really a problem on busy sites, because the current cache sweeper usually resorts to sweeping the entire cache every time a new article is posted, but it’s a pain on slower sites.
There are certainly other ways to fix the sidebar problem (AJAX sidebars are the obvious example), but the same basic pattern comes up all over Typo. A few examples:
Users keep requesting the ability to create articles with a publication date in the future. The article won’t appear on the site until after the publication date. This is common CMS feature, and apparently other blog engines have it as well, but it really doesn’t mesh with Typo’s current cache, because there’s no way to say “sweep the cache at 7:30 today” short of adding a cron job for every article that’s posted this way.
We have a bunch of aggregation classes that suck data off of other sites, like Flickr, Upcoming.org, and so on. These usually end up as sidebars, but we need to cache the back-end data somewhere. An expiring fragment cache would work perfectly for this.
On really busy sites, we could use something like this to avoid rebuilding comment pages on every comment–we could drop the sweep-on-new-comment code and swap for expire-after-5-minutes. If you’re getting more then 1 comment every 5 minutes, this would be a win. If you’re getting a comment every few seconds (think Slashdot or Curt Hibb’s “hammer my comments” post), this would be a major win.
To accomplish this, I added two new features. First, I added a set of “meta-fragment cache” methods, building on Rails’ existing fragment cache. The fragment cache stores (key, value) pairs, while the meta-fragment code stores (key, value, metadata_hash) triples. This is simply implemented as two fragment cache entries, one for the data and one for the serialized metadata hash.
Then, on top of that, I re-implemented my caches_action_with_params code. This is a variant of Rails’ native action cache with a number of cleanups and bugfixes.
When all is said and done, you’re left with a controller that looks something like this:
class ArticleController < ApplicationController
caches_action_with_params :read
def read
response.lifetime = 3600
...
end
end
That’s it–the read action will now be cached with a 1 hour lifespan. After an hour, the cached version will expire. If response.lifetime isn’t set, then the page won’t expire on its own, and it’ll need to be swept as usual.
So here’s the big question–should this go into Typo? I can see good arguments on each side.
Pro:
- It solves a lot of cache-with-parameter problems that we’ve had.
- Switching to some variant of the action cache means that switching between production and development mode doesn’t leave cache problem. This is a major cause of bug reports from new users.
- It’ll let us implement future posting easily.
- It’ll make it easy for sidebars to stay current.
- It’ll let us move the aggregation backends behind the sidebars to a more reasonable architecture. For example, we’ll be able to use the
Flickr class for the Flickr sidebar instead of (mis-)parsing their RSS feed.
- It’ll make us less dependent on web server configuration and weird rewrite rules.
Con:
- It’s slower then the page cache. I haven’t benchmarked my new code yet, but the last time I checked, on my box I could handle almost 2400 page cache requests per second, while the action cache was good for *10* hits per second. That exposed a couple major Typo performance bugs; I suspect that retesting with the new code would give us 100-200 hits/second, which is pretty busy for a blog. Still, this may be an issue for shared hosting providers.
- The action cache serves cached pages via Rails, while the page cache serves the same pages directly from the webserver without invoking Rails at all. Because of this, I suspect that a lot of sites will want to increase the number of FastCGI Typo processes that they run. With the page cache, running with one FCGI process was usually okay; with the action cache, it might be better to use a second process.
Those are the only two major problems that I see. Basically, if we switch to using the action cache (in any form), we’re going to be harder on big hosting companies like TextDrive and Planet Argon, and they’ve been very supportive of Typo in the past.
Does anyone feel strongly about this one way or another?
Tags caching, ruby, rubyonrails, typo | 11 comments
