Andy McKay

What Plone can learn from Rails

This was a talk given to the Plone conference in Naples 2007. Rather than just plonk slides online that don't say much here's the talk as a blog post with detail added.

Lennart's and Phillips excellent talk

Before going any further, refer to Philip and Lennart's excellent talks, these cover the areas slightly differently and focus on different things. All going down the same path though.

Why am I doing Rails?

Because it completely suits the model of sites we are building at Blue Fountain, factory automation. In a factory spitting out widgets it's perfect for a relational database, it's not content management.

Comparing apples and oranges

Yes they are different and solve different problems but do share a similar space.

Easy to be envious of Rails

Rails has done well shooting up in terms of hype and use. It's got a large following and crowd and is generally doing very well. It's much more popular than Plone, how did it get there?

Really hit a new audience

It caught all the people do LAMP, Struts, ASP and so on. All those technologies that don't really provide any infrastructure at all for a complicated site, just ability to hook code up to databases. Those are hard tools and a move to Rails make sense to them. We moved to Zope, those people moved to Rails. Zope provided too many barriers and problems to people so they dropped off.

The Gartner Hype Cycle

Just a brief note that I believe Rails is hitting "The trough of disenchantment". It's had the hype and it's coming down into the trough. There's been some FUD about Rails and some problems, but it's solving them and moving on, it's a natural cycle.

For me Plone is coming out to the "The slope of enlightment" and is moving forward. It's had the rough time and the FUD and it's only getting better. This might be a personal statement rather than have any real backing.

Plone: The best is yet to come

It really is. Plone 3 and the future is bright.

A shallow learning curve

Back to Rails, it has a shallow, simple learning curve. Bite off what you want and move onwards and upwards, being more productive. There are new things to learn but most of them can be bitten as you need to.

The Z shaped learning curve

Need we say more, we know it's possible to go badly.

Keep the learning curve shallow

To get the hype, to win developer's hearts, to get the mind's we have to keep the learning curve shallow. Allow people to bite off what they can. Keep moving forward, keep getting productive. With this in mind, here's a few things that can really make a difference...

1. Product refresh is damn helpful

You have to be able to make a change and see it happen instantly. If it doesn't it's too slow. Rails, Django, Jboss they all do it. We have to keep it. It's kind of gone away until Andreas wrote RefreshNG (to confirm this), this should be required and maintained by us. Without it we make it really hard for new people.

2. New terms are confusing

We love making up new terms for everything. We have an overwhelming array of these. Rails has some but it's kept them followable and understandable (mostly). Let's do the same.

I dont know what a portlet is. Or a component, module, block, or snippet. The last system I evaluated had something called "mambots" which, to me, sounded like robotic assistance for breast-feeding.

http://adaptivepath.com/ideas/essays/archives/000365.php. We've already got enough barriers as it is, for example ZODB etc... let's stop throwing more up.

3. Every new technology introduced is a barrier

We've got lots of new technologies in Plone. Mostly kept internal to Plone and not used elsewhere and that starts to create problems for people coming in. Ask the people who do training or write books there's soooo much there. Do we really need it all? Can we ditch DTML in our CSS and just use Python string replacement? We all worry about the Zope 3 learning curve, add in Plone and it's very, very tough.

Rails has things like .rxml and .rjs and quite frankly every time I've seen them used I've thrown them out in favour of Ruby libraries or just straight Javascript. These things don't help although they keep developers happy in writing them.

Keeping things to ourselves (eg Clouseau) is bad. If we've got something new going into Plone would it make sense to try and make it a standard say: if it's going into core it must be used in one or two other places first. It might not last but at least we haven't kept ourselves isolated.

4. Is Zope 2 a barrier?

It's getting to the point where we can say all the wonderful goodness over the last few years is on the one hand making it possible and the other taking it away. Rails appealed to the crowd by doing a few things. It didn't try to do all the things Zope 2 does (application server, database, web server) and that stuck in people's brains. Philip and Paul showed of running Zope 2 with WSGI this is an important step in the right direction.

A quick rummage around the ZMI and things become apparent. Ever had anyone look in *Control Panel* > *Products*. Why do we still have all Script (Python) and External Methods? Cruft and it's time to look at Zope 2 and find a way to get past the ZMI and the all in one mentality.

Fun text on button in moodle

I thought this was really bad in Moodle

Use carefully -- it can make Apache/PHP crash ...[snip]

and then I thought of the ZMI and the terrible messages text and things that can happen in there.</dt>

Can we live without the ZODB?

This is where most of the chatter ended up at. I'm not smart enough to solve this but people out there can. In the last few years SQL Alchemy and other tools have really come along and provided a huge amount of good code for us to build off. Rumour has it Jim said that the ZODB in Zope 3 is optional. That would be great.

So much work by so many people has gone into solving the whole ZODB thing. Currently you have two choices, love it and use it or don't use Plone. Trying to bend a RDBMs in there is not possible without pain or lots of knowledge. Continually justifying the ZODB to enterprise customers is a pain. Continually justifying to new developers is a pain. It's a barrier that slows the adoption down. I do like the ZODB I use it a heck of a lot. Plone with an RDBMs will still be Plone, it won't be any different, you won't be writing SQL much. But you will walk into a client and not have to justify it again and again.

Rails uses SQL and using something that everyone knew and could grok instantly gave them a huge leg up.

5. TTW got us here and must continue

Rails doesn't have through the web development, so this might be a little off course. But Rails is aimed at a different market than us. Through the web development is fast, easy and accessible for new people. They love it. It's the ZODB persistence of code, the restricted python and other things that are the problem.

ZODB persistence, Restricted Python sucks

If we remove these items so that through the web means just editing file system stuff through the web AND can easily be turned on and off (eg. Django's admin interface) we might just have something that meets all the worlds.

6. Trying to separate presentation is good

It is hard, it is a struggle and it's something I got wrong in the past. I used to believe that allowing people to write Python write in a template is the only way to go. I was wrong. You can see this in lots of Rails code, Rails preaches not doing this but it happens and it sucks. Learn from Rails and fight the good fight, keep as much Python out of templates as you can.

7. Community is a huge difference

Rails has a very big community. But what I've seen of it has not been as nice and helpful as Plone and this experience has been shared by others. Keep it friendly guys, it's the secret weapon over most other projects and over every single closed source CMS.

No matter how fun Rails is I will always miss #plone

Geoff Davis.

8. Avoid making Plone do everything

Rails doesn't try and do much at all so again slightly off topic. But the rise of Django, Turbo Gears, Pylons and Rails helps Plone. It stops us trying to do everything in Plone, we shouldn't be. Know when to say no. Plone is now a framework, but it is going to become a product, it has to.

9. Keep unit tests easy to write

Rails creates them for you (via rake) and runs them for you quickly and easily. I really like the fixtures in Rails, they are so damn helpful. Haven't spotted anything like that in Plone yet.

10. Scaffold code generation

Most people I asked mentioned this as a huge win. The scaffold generation creates a convention that is easy to follow. Going and grabbing someone else's code is easy to track down where things are. You can look at the URL and go find the controller or model that is relevant in no time. It might be hell when you get there but at least you can easier than Plone. Philip mentioned this as something he would like to see happen in Plone, I agree.

11. Marketing really does help

Seen those Rails "20 minutes build a whole site" demo? Really they do scaffold and end up with nothing useful in terms of HTML. If I die without writing another HTML form I will be a happy man. So Rails ends up with a bunch of projects for creating forms for you. Once you've gotten past that 20 minute quick hit, it is pretty easy to look at the scaffold HTML and move on, bite the next bit.

Yet I (and many others) came into Rails thinking it would do it all magically for me and it didn't. We've got to explain to people that Plone can be extremely fast and productive and market it. If we could get Sean Kelly to sit down and just do screencasts all the time we would be doing great, help the foundation fund this effort.

12. More through one command

Although I've sworn at rake a few times when it did the wrong thing, having one command to go and do everything is nice. It could be zopectl or paster or whatever as long as it is all in one place.

13. Maintenance

Can be easy to find code in Rails due to scaffold as noted. Does this make Rails easier to maintain, probably. However let's point out that Rails has been around for less than Plone and does generally a simpler job.

14. We need a 37 signals

37 Signals get's lots of attention and press. Lots of people use backpack and other things. They've done well at selling themselves and selling Rails. The Plone world is full of lots of brilliant people and companies - on par with any other company out there. But none of the Plone companies get recognition outside of the Plone community. That's a shame.

If we could get a company getting that recognition and getting people into Plone without them knowing it's Plone until they have chance to build any prejudices, we can get a win. This will increase the buzz and energy about Plone as they realise it can do lots of useful things.

What Rails can learn from Plone

In the end I think this would be a good talk, Plone has done a lot of things well.

And by the way if you are thinking of using Rails...

Don't* ... use *Django* instead. Or *Grok*. Long live Python.