Even today, most web content can fairly be called either bloggy or wikish.
Tweets, Facebook posts, Reddit news items, discussion forums, and (gasp) even traditional news sites qualify as bloggy: Each piece is timely and static; there is one clear date of publication, and you only edit to correct egregious errors.
On the opposite end of the data-shelf-life spectrum is a timeless (no single publication date), dynamic wiki page. Obvious wikish sites include pretty much anything whose name contains "iki", "pedia", or both. Less obvious: the vast majority of company websites are in this camp, whether they use wiki software or not. The content is intended to be authoritative and evolving, part of the great pedia that is the web.
Savvy web users know these two worlds are generally kept separate. Software websites refer folks to "their wiki" for documentation. Corporate sites refer users to "their blog" for the latest news. They may be under the domain, but the blog and wiki are clearly different neighborhoods. Is this segregation wise?
There are several reasons for the split, some old, some new, some complex, some confused. Some folks think "wiki" always means "anyone can edit". Some think blogs are just for opinion pieces. Many more fall into segregation by habitually approaching their web challenges piecemeal: we need a blog; what's the best tool for blogs?
More thoughtful web creators will point out real challenges to blending the two. To mix individual and collective creations, you need elegant management. To mix one-off announcements and thoughtful edits you need elegant interface. To organize timely and timeless data, you need elegant organization.
All true, but suppose we meet those challenges. What would the payoff be?
Well for starters, a unified site means a single signin account; separate signins are a nuisance, a barrier to entry, and a source of data confusion. It also means a single search, so you don't have to look multiple places any time you can't remember where a bit of information was entered. It means a better user experience for visitors, who don't feel like they have to learn their way around multiple realms. It means simpler, easier-to-manage references from blog to wiki and vice versa. It means simple data reuse – duplication is the bane of data managers everywhere.
The payoff, in sum, is integration. Better integration means better visitor experience, better creator/maintainer experience, and, ultimately, better data.
Ethan McCutchen is a creator of Wagn, a tool for team-driven websites. Learn more at Wagn.org
bloggy or wikish
Wagn 1.10 introduces some significant interface changes.
Most notable is the new menu, which opens as a dropdown from a gear icon in the upper right corner. This new menu reduces visual noise considerably and replaces the functionality of the old header, the old footer, and several submenus. It also helps separate out the "wagneer" functionality (under "advanced") in order to keep things simpler for casual users.
Also cleaned up: forms. By getting rid of details other than the fields being edited, we were able to make forms far less noisy. Name and type fields now align vertically with content fields, and old edit submenus are obviated.
As part of the cleanup, CSS is considerably simplified, and behavior on mobile devices is incrementally improved. Both will receive considerably more attention in upcoming releases as we roll out new support for skins and mobile-friendliness.
If you've been following Wagn, you know how excited we are about Wagn 2.0: how it will complete our transition from a nifty app to a powerful platform... how it will be easy to discover, use, and extend...
That said,Wagn 1.9 takes some big steps.
One key step is that we've considerably increased the number of cards that can be renamed without creating problems by giving them an additional "codename" identifier to be used when referenced in the code. This is important for Wagn because we give so much power to Wagneers, who are essentially coding by manipulating card content. Our new, more robust approach allows for powerful relationships between code and content, so that we can continue to give Wagneers more and more new capacities.
1.9 is also slimmer. By moving data into cards, we've gone from having seven core data tables to having just four. (We'll be down to three in 1.10). This has considerably simplified our codebase without sacrificing any functionality.
Perhaps most importantly, it gets us much closer to the 2.0 apis (both REST and pack) that we think will make Wagn the platform of the future.
See the Release card for tickets and update details.
Warning: this is going to get geeky. It's an exploration of current and future server optimization for hosts supporting multiple Wagn websites. Noone who does simple wagn installation should have to worry about such things.
The new pack/modules system is pushing us to reconsider our hosting architecture. Without packs it was relatively easy for multiple Wagn sites to share rails processes. On our old servers, all sites shared all the same code but used different databases (or, technically, different PostgreSQL schemas). With packs, each site can use different chunks of code, so the old way won't work anymore. Moreover, the new Cloudstore deployment framework, which gives us dramatically simplified installation, maintenance, migration, and scaling, has pushed us to have greater independence of each site's data and management.
In this article I'm going to describe a bit of what we've done so far in our own hosting set up and invite the Wagn community into a discussion of where we should go. If you're reading this because you want to speed up your own hosting setup, be sure to see the Wagn in production card, which outlines some concrete steps you can take to make your Wagn site run faster.
This discussion will center around a conventional Apache2/Passenger stack. There are many choices for hosting rails sites, and to be clear, we did not come to our current arrangement by testing them all. In fact, it is quite likely that there are some potential performance gains to be had by using the likes of nginx or thin. Our rationale for using Apache2/Passenger at this point is that:
- Apache2 is currently the webserver supported by Cloudstore, which, as mentioned, buys a tons for the Wagn community.
- Apache2/Passenger is a dominant rails hosting setup that we need to support strongly
- The performance challenges within Wagn are greater than those in the server setup, so it makes sense to prioritize server simplicity until those challenges are addressed.
A little background for those who see the word "spawning" and think of salmon.
When someone loads a webpage, the request is handled by a "process" on a webserver that is sometimes called a "listener" or a "handler". When there aren't enough such processes to handle the requests coming in, the server "spawns" a new one. Spawning can take a long time when starting from scratch. It entails loading up all of Ruby on Rails, all of Wagn, and all the packs. On our current production server, for example, it takes about 5 seconds to load our full environment, and that's before the server has starting to consider the specifics of the request. Obviously, we don't want folks to wait over 5 seconds for webpages.
The other option is, of course, not loading from scratch. It is much preferable that your spawning be largely "pre-loaded". Doing this well is key to optimizing our site performance.
Our current setup is very inefficient in this regard whenever a site has not been visited in a while. Basically, extra processes for any given site can spawned very quickly after the first one is spawned, but processes for separate Wagn sites make no use of the fact that they share tons of code with other Wagn sites. So Wagn site A doesn't make any use of the loading of Wagn site B.
This is happening because Passenger's default spawn method loads an entire application as one beast. When a request comes for a website with no current processes, it reloads Rails, Wagn, and the site's packs, even if Rails and Wagn are currently in use for several other sites. Since each website can have different packs and different environments, they are treated as if they weren't related at all.
We're currently trying to use Passenger's "smart" spawning, which will mean the Rails framework can be pre-spawned for all the Wagn sites. Rails has a lot of code – much more than Wagn – so this should be a big gain. With luck, we'll have this working within the week.
In the long term we could do even better and make sure that everything but the packs themselves are pre-spawned. This would mean some rearchitecting of our code load order to make sure packs and site-specific data are loaded entirely separately from the core. And it may well mean developing an Apache module (mod_wagn) to handle the nuances.
If you're using a webserver besides Apache, please note that this could be an area that needs some work. That's because Wagn uses an apache module called "xsendfile" to give the file-handling responsibilities back to Apache after it has checked permissions. This frees up Wagn to move on to the next request. It should be possible to do something analogous in other webservers, but this is not a case that we've developed for. If you are willing to give this some attention, we will try to support you in the endeavor!
Once we've plucked all this low-hanging fruit, we'll likely be back to optimizing Wagn's internals. It's clear that there are many opportunities in there, but we'll need to do more profiling/benchmarking before it's obvious where to pluck next. Here are some hunches.
Our nested permissions-checking has tended to thwart simple page caching, so to date we have focused on honing our card cache. As we grow, we will want to dig deeper and find more and more opportunities for speed. For example, when a page nests no restricted cards, we should be able to cache the whole thing. The challenge moving forward is to figure out how all that should work! For example, Gerry Gleason has proposed that Wagn inclusions might be handled as nested Rack requests.
As our Rules system matures, there will be caching opportunities there, and I suspect the views system will only offer more. Trickier, potentially, is WQL caching, but that may grow more important as more and more sites feature more and more dynamically queried content.
Finally, some of this may be pushed to the Wagneering level. One could imagine Snapshot cards that allow wagneers to take manual snapshots of a result and save it as card content, for example.
Wagn 1.0 was a pioneering web app. Wagn 2.0 will be a pioneering web app and web platform.
The current release (Wagn 1.8) gets us considerably closer. To name a few highlights:
- uses Rails 3 - the latest and greatest.
- supports Ruby 1.9 (1.8.7 still works)
- new file and image handling is more secure, flexible, and re-usable
- new settings editor is much crisper and easier to understand
- Almost 50 tickets resolved: new features, bug fixes, performance enhancements, etc.
This release includes more resolved tickets and more commits than any prior Wagn release, and yet the codebase is actually smaller than ever.