casperfabricius.com

Paul Graham delivered a brilliant key note at the first day of RailsConf, with jokes and insights coming so fast in succession that it felt like a new chapter in his trademark book; Hackers and Painters. It is impossible to do Graham’s speech justice in a blog, as the softies realized, but I got pretty decent notes, so I’ll give a try anyway.

Graham titled his keynote “Power of the marginal”, and his theme for talk was just this: The advantage of being an outsider, and the amount of great ideas that stems from outsiders. “Using Ruby on Rails is a marginalizing yourself – welcome to my world!” Graham said, hinting his preference for Lisp as a programming language. He pointed out that there, due to the definition, will have to be more outsiders than insiders, and that this is part of the reason that most of the good ideas comes out the marginal. But that’s not entire reason – there are actually several disadvantages to being an insider:

• You will often select the wrong people from your pool of other insiders
• You need to seem serious
• You want to avoid risks
• The task becomes a duty, rather than being pleasurable

You can pass a test either by being good at it or by being good at hacking it, and you can tell how interesting a scientific field is by the overlap between its practitioners and the people who teaches it, where you have, on one end, mathematics, where all the great scientist are also the best teachers, and on the other end you have computer science, where the people who can’t do, teach. Grahams point with this was that you shouldn’t learn things from people who are bad at those things. He also points out that it’s hugely valuable to be able to look like a fool, to make mistakes – something insiders can’t afford to do, because they want to stay insiders – but something outsiders can without a worry – they are already outsiders. Bottom line is that stupid ideas don’t make you stupid – it takes many stupid ideas to come up with a great idea.

Another advantage of being an outsider is you have lots of time. Successful people often answer, to the question on what’s wrong with their life, that they don’t have enough time. Everybody wants a piece of them, and that way they loose a lot of the freedom they had as outsiders. (This point actually made me feel bad for pulling DHH into a photo with me earlier that day, since that’s a perfect example of an outsider taking a bite of an insider.) So being an outsider, you should take advantage your freedom, and be flexible instead of being ruled by plans.

Repeating some his well known views, Graham stated that every programming language should be written together with a large application using it, like C with UNIX, so the language doesn’t turn into a big, unusable science project. Another point was that outsiders are compelled to make things that are cheap, because they have very limited resources. An example of this was Steve Wozniak, who created Apple with Steve Jobs, used a TV as a monitor for the computer, since he couldn’t afford a real computer monitor. The insiders can’t make it as cheap or as small as the outsiders, they have to work on big projects, which will, by their sheer size, impress people. Small things are magical, Graham says, because they can be done fast and seem perfect, and working on small things is a good way to learn.

The biggest disadvantage of being an outsider is that you don’t, as opposed to the insiders, have a big audience. It’s good for moral and motivation to an expectant audience, and luckily, the internet has made it much easier to get such an audience for the outsiders. This way, outsiders can retain most of the advantages of being and outsider, while still having an audience.

Graham ended his talk by underlining the power of marginal: Just try hacking something together. Spend less time worrying and more time building stuff, Graham said, and how does this leave someone like me (that’s me, Casper Fabricius, not Graham being quoted), who are actually spending more time studying and making plans for future than executing and try building stuff? With a feeling of wasting my time and not being willing to take a risk – but I’ll have to take my chances. Graham suggest that you can check if you are on the right track by noticing if people call you unqualified and tells you that you are doing inappropriate stuff. As long as the worst thing the insiders can say about what you are doing is to point out that you are an outsider, you are on the right track.

UPDATE: You can now read Paul Grahams key note transformed into an essay at his website.

Geoffry Grosenbach is cool. And I’ve struggled with the same issues as he has, albeit I’ve been able to build on his work in my own deployment setup. So of course I had to attend his talk on deploying to shared hosts, although most of what he said wasn’t new to me. Geoff’s entertaining and well-designed presentation focused on three areas: How to design a site to run a shared host, how to maintain the site, and how to troubleshoot problems.

Design
First of all, Geoff suggested that only really small sites should be deployed to a shared host. By small, it is not as much disk space, as how much memory and how many CPU cycles the site requires running smoothly. You are restricted on all these three factors on most shared hosts, but you also have the benefit of running on multiple servers – usually the database server will quite powerful, you will have a separate mail server, etc.

Another important thing in designing the application is caching. Geoff explained, that by using the caches_page macro, an html file will automatically be created upon the first hit, and after that; the web server will simply serve that static page without even invoking Ruby, Rails, FastCGI or anything else. The html file is stored in a directory structure that corresponds to the mapping of the action, so if you have for instance the action /da-DK/blogs/show/1, it will store that particular blog for that particular language. So that sounds like quite a big possibility to improve on speed. In order to expire the cached pages, a cache_sweeper needs to be implemented.

Maintaince
Geoff underlined that you need to make sure you don’t have too many zombie FastCGI processes running on your shared host, since you are restricted on number of processes. Maybe Mongrel will be the holy grail giving a nice, reliable way to run sites on a shared host, Geoff said, and this was somewhat confirmed by the “Deploying Rails” presentation by Ezra Zygmuntowicz the following day, stating that the future of Rails deployment definately belongs to Mongrel.

For monitoring our Rails applications, Geoff suggested Montastic.com or dwatch, which he has written a great tutorial on using.

Troubleshooting
Finally, Geoff gave some advice on how to debug and fix your problems when your site is not working on the server. The hash-bang (or is it she-bang?) lines has to actually point to place Ruby exists on the server, and it is a good idea to set export RAILS_ENV="production" in the ~/.bashrc or ~/.bash_profile to indicate that this the production site, instead of hardcoding it in environment.rb or relying on the shared host to set it.

./script/about, ./script/server –e production and ./script/console production are all good indicators of whether or not the actual site are running on the shared host, but also, the various logs produced can be good indicators of where the problem is, especially apache_log, production.log and fast_cgi.log.

Conclusion
Deploying Rails can be frustrating, and deploying it to a shared host with no control and lots restrictions can be a nightmare, so, as Geoff started out by saying, his talk was not a tutorial or a lesson, it was therapy.

But really the morale here is: Don’t use shared hosts for Rails, and if you do, make sure it’s only very small applications, or only for test purposes. As Ezra said at his talk on deployment: “Rails is a pig”. Once you want people to actually use your site, you should go with a Virtual Private Server (VPS) – or of course a dedicated setup if you can afford it – since you will get a certain amount of memory guaranteed, and you will have less users pr. machine. Ezra adds that you always go for a VPS host that uses XEN, since this platform uses almost no resources on its own.

Kiran Dandekar made an entertaining point out of demonstrating the variety of information that has be made available about him in different contexts like business, community, family or alumni. The problem is, he stated, that identities and identity attributes are site centric on the web, so you have to start from scratch entering this information on every site and even identifying yourself, as opposed to when you – for example – board in the airport, and all the airline need to verify your identity is your driver’s license. The driver’s license is not issued by the airline, but nevertheless is accepted to identify you, because the issuer of the identity is trusted.

Kiran and his coworkers at Verisign want to make this possible on the web – enter OpenID: An open, extensible, perpetual and not least user managed authentication service that anyone can use, and anyone can use. Ideally, everyone should have just one single ID – a domain – and password to identify themselves everywhere on the web. Why a domain? Because domains are the only truly global unique identifier today – a username is too narrow a scope. Kiran underlined that OpenID focus solely on authentication (or identity, as they called it), and that authorization and access control are still left to completely to the site.

OpenID also provides a profile, so each person only has to enter her data once, and are then able to decide which pieces of personal information each site should be allowed to access. The information is provided through attributes, and the concept is that you can do a “challenge”, e.g. ask “Is user 21 or older?” and get back true or false without ever learning the users birthdate.

OpenID is supposed to be fairly easy to use with Rails, as both gems and plugins has been created to work with it, so since all sites need user authentication anyway, it might be worth a shot. Examples of real sites using OpenID include LiveJournal, Wikimedia, ClaimID and several others.