Welcome back to the Vancouver.rb Q&A series. Today let’s welcome Vancouverite Sunny Hirai – founder and CEO of MeZine Inc.

Caffeine is multi-threaded so requests do not block each other and you get to focus more on building your application and less time on getting your application to work smoothly. Merb is multi-threaded as long as you don’t use ActiveRecord or other single-threaded libraries.

With Caffeine, you can take any application you’ve built and, with no code changes, drop it into your new project. You could take somebody else’s forum application, for example, and use it in your project. Caffeine handles the differences between user models, database storage, file storage, templating, etc.

To make it work, we had to rethink everything from routing, to the database, to the user model and in many cases the abstractions are in different places than Rails, Merb or other popular frameworks.

Q: Can you tell us a little bit about yourself and your startup (company) MeZine?

Sunny Hirai: I’m the founder and CEO of MeZine Inc., the internet company that developed CityMax, a website builder for small businesses. Technically, we’re not a startup anymore as we’ve been in business since 2000 and we’ve been profitable for a long time but we have a new project that we’re treating like a startup.

Our main property, CityMax, is an everything-for-one-price business website builder that is $20 a month and includes a shopping cart, online form builder, discussion boards, photo albums, eBay integration, PayPal processing, credit card processing, calendar, and dozens of other business features.

I believe we launched one of the first, if not the first, online website builder on the internet.

Currently, we are privately held and employ about thirty people.

Q: How did you get started with Ruby (and Ruby on Rails)? What makes Ruby a great choice for developing web applications?

Sunny Hirai: We needed an application platform that would support our “next big idea” which includes a suite of web services including a site builder, wiki, blog, and social networking.

The platform we chose had to allow us to build a complex application by combining simpler applications in many different ways. It also had to scale easily and almost infinitely.

I was attracted to Ruby on Rails initially but ultimately, Rails did not have the type of scalability nor the ability to combine apps the way we wanted; however, we really liked Ruby and made that the language for our project. I ended up building a new Ruby framework that focused on scalability and application re-use.

I think Ruby’s greatest assets are that it is simple to start but powerful when mastered. This is great for developing in a shared environment because one can build powerful frameworks with meta-programming and other advanced concepts, but the developers who use the framework do not need to know all the advanced features and still be productive right away. Rails, of course, is the primary example of this.

Python was a strong contender but ultimately Ruby’s pure object oriented model won me over Python’s better performance.

Q: Can you tell us some challenges you faced developing using Ruby on Rails and why you have decided to build your own web framework in Ruby?

Sunny Hirai: First of all, let me say that I like Rails. For most web applications, it is a very good or near perfect solution and it’s something I recommend to those who are considering startups.

Unfortunately, it didn’t have ticks in a few important boxes for our project:

• Multi-threading
• Application reuse
• Database clustering
• Scalable storage

Many of these issues can be patched, fudged or hacked onto Rails but when you do that, it tends to add complexity in the wrong places. Because of this, we decided to start from scratch and build a framework that could handle what we needed elegantly.

The Caffeine Framework improves on more than these four issues but they were the impetus for starting.

I just wanted to add that I haven’t been following Rails intimately so I may have some Rails facts wrong and mean no disrespect.

Q: Can you tell us more about the challenge of scaling and how your Caffeine web framework outshines Ruby on Rails or Merb or takes a different route? Any commentary on Merb and how your web framework differs?

Sunny Hirai: With libraries, deployment design and/or thoughtful application design, Rails scales, but the framework doesn’t help you. Merb defers scaling by focusing on performance, which is great, but it also doesn’t help you when you eventually need to scale. Caffeine’s approach is to focus on scaling as a problem to solve in the framework and leave the application designer mostly out of it. In other words, build an application in Caffeine and it will scale.

Caffeine focuses on three areas:

1. Processor Scaling
2. Database Scaling
3. Storage Scaling

Processor Scaling

Applications can scale across servers by putting a load balancer in front of a bunch of servers including Rails, Merb and of course Caffeine; however, Rails cannot handle more than one request at a time because it is not multi-threaded.

The workaround is to run more than one instance of Rails per server.

The problem is that if you send two requests to an instance and the first request is a long running process like a file upload or credit card charge, the second request has to wait and so does the user. To solve this you use Merb or another framework to handle the slow running processes in a multi-threaded fashion and make sure not to use single-threaded libraries like ActiveRecord in it.

The big issue here is that scaling to multiple processors in Rails is not trivial. You need to know what you’re doing and you need to refactor the slow bits of your application to make it responsive.

Caffeine is multi-threaded so requests do not block each other and you get to focus more on building your application and less time on getting your application to work smoothly. Merb is multi-threaded as long as you don’t use ActiveRecord or other single-threaded libraries.

For many applications that deal with just a database and with fast queries, this isn’t a big deal. It’s when you have many slow running processes that handling them differently becomes a chore.

Database Scaling

Worrying about scaling the database is not something the application developer should have to do. He or she should be working on the application itself. This is both more productive and more fun. It takes a lot of training and knowledge to understand how to manage and scale a database and it shouldn’t be a problem that has to be solved over and over again. To get around this Caffeine takes care of database scaling at the framework level.

Caffeine includes database clustering (also known as partitioning) which means that you are not restricted to storing a table in one database. Instead, you split it up across multiple databases. You control how the database is split and you can add and remove clusters from the pool at will.

This is great for scalability.

As a bonus it also opens up more options. When the database can scale you can solve more problems with the database because it is not a scarce resource. For example, we are considering using PostgreSQL’s full text search in our application, an option we would never consider without clustering.

Caffeine’s clustering is designed to “just work.” You build your controllers like you do normally but you can use them with or without clustering.

Ultimately, it turns clustering into a choice rather than a project. Should I flip the clustering switch or shouldn’t I?

Storage Scaling

You shouldn’t have to decide how you are going to store your files for your application and be locked into the decision. I want to be able to store files locally, or in MogileFS, or in a network share or on Amazon S3 and I don’t want to think about storage problems while developing my application. Handling storage should not be a development issue but an implementation issue.

Caffeine takes care of this by abstracting storage. Presently it has plugins for local/network storage and for Amazon S3 but there is no reason it can’t support MogileFS or any other storage solutions.

Like clustering, it is designed to just work.

Caffeine’s storage framework also integrates with the database. You can put an uploaded file right into a record in the database and Caffeine will automatically move the file into a directory related to the record and store the serialized location of the file into the record. When the record is deleted, the file will automatically be deleted from storage.
Can you highlight (or tell us more about) the architecture and building blocks of your web framework?

Developing in Caffeine is agile and fun like Rails but adds two things:

1. Scalability
2. Feature Packaging

We already touched on scalability so let’s talk about feature packaging.

The future in application development is to make the application modular so that you don’t have to keep reinventing common features like message boards, wikis and calendars. I call this feature packaging because you are taking a wholly contained application (a feature) and making it reusable. Unlike a library, a packaged feature includes everything needed to implement a complete feature in an application including the models, views and controllers.

Take Redmine for example. It’s a project manager written in Rails that includes several features like wiki, news manager, document manager and message boards. Those four features have been written hundreds of times over but they were rewritten once again for use in Redmine.

Since the focus of Redmine is project management, why are developers spending time building features that are not specific to project management? They would get farther if they focused on building project management features only and reusing other people’s code for the common bits. But they made the logical choice for now. Feature re-use is too hard in its current state to make it worthwhile.

With Caffeine, you can take any application you’ve built and, with no code changes, drop it into your new project. You could take somebody else’s forum application, for example, and use it in your project. Caffeine handles the differences between user models, database storage, file storage, templating, etc.

To make it work, we had to rethink everything from routing, to the database, to the user model and in many cases the abstractions are in different places than Rails, Merb or other popular frameworks.

Q: Do you have any plans to open source your Caffeine web framework?

Sunny Hirai: Yes, but before we do that, we will put the framework through its paces. This will be sometime after we have launched our product and put it into production.

I’m excited about the potential for open source. It has some great benefits like a larger testing base, contributions, good will and a larger pool of people to hire from since they already know how to use the framework.

Q: Any commentary on Sequel and why it’s a cool data access library?

Sunny Hirai: Sequel is the best ORM out there. I loved it so much that I made it part of Caffeine before Sequel was even out of beta. Amongst other things, it fit a key requirement: multi-threading.

Sequel is counter-intuitive if you’ve grown up writing SQL statements, but as soon as you get the approach, you’ll realize how smart it is. I believe we are going to see a rise in the popularity of Sequel as the preferred data access layer for non-Rails apps.

What makes Sequel cool is that it uses chaining to return subsets of a table. Say you had a table “stories.”

my_stories = stories.filter( :user_id => 7 )

my_stories now refers to all records in the “stories” table where “user_id = 7“.

You can filter the filtered dataset further:

my_featured_stories = my_ stories.filter( :active => true, :featured => true )

This improves security and reduces code. You don’t have to write the same where clause over and over again. For example, “WHERE active = true AND user_id = 7” might be the subset you always want to be working with. With Sequel, you can filter the dataset once at the start then use the filtered dataset without worrying that you’ll forget the filters when you do a SELECT or DELETE.

In this way, Sequel is more DRY than ActiveRecord in common usage.

In Caffeine, I wrap Sequel to handle clustering, revision control, etc. I also feel that if you have a filtered dataset where :user_id = 7, then when you insert a new record, it should automatically set and restrict the user_id to 7, which it does.

I also add a modeling scheme that allows custom data types. For example, you can store WebImage and WebFile types and they are automatically serialized/deserialized and the files automatically stored in the storage engine.

Q: Can you tell us a little bit about GoMarkup – your library for creating web markup (HTML) from text? Any commentary on how it compares to BlueCloth and RedCloth (Markdown and Textile)?

Sunny Hirai: GoMarkup differs from BlueCloth and RedCloth in two important ways. It is:

• Configurable
• Portable

GoMarkup is not limited to parsing one markup language. Instead, it takes a configuration file that lets it parse any markup language. Currently I have a configuration for WikiCreole markup but it can parse Markdown and Textile with different configuration files. This also makes adding custom markup code very easy. In a few seconds, I can add a definition for superscript, for example, if there wasn’t one already.

GoMarkup is designed to be portable across languages and, as part of that goal, it is very small (about 12 KB of Ruby without the tests). The goal is to have a version of GoMarkup in all the core web programming languages including Java, PHP, Python, .Net, etc.

As you might have surmised, with configuration and portability, it is possible to eliminate that mess of slightly incompatible markup libraries. I say slightly because it is hard to code a markup parser in different programming languages and have the edge cases handled identically. With GoMarkup, we create one configuration file that works identically in the GoMarkup parsers for each language.

In other words, with GoMarkup, a markup language’s official implementation is automatically documented by its configuration file.

Q: Any tips, tricks or advice for developers getting started with Ruby?

Sunny Hirai: Programming Ruby by Dave Thomas (The Pickaxe Book) is a great start for beginners but for those who want to be break out and be Ruby Experts, there are a few excellent resources, most of which have come around only this year:

• “The Ruby Programming Language” book by David Flanagan and Yukihiro Matsumoto, the creator of Ruby. This is the de facto reference on the language itself.
• “Ruby Metaprogramming” screencasts by Dave Thomas at the Pragmatic Programmer websites. This is the first time that I’ve seen metaprogramming explained in a way that was understandable. This is well worth the $5 per episode.
• “Ruby for Rails” book by David A. Black. Even if you aren’t into Rails, this is one of the best books on advanced Ruby programming concepts.

For daily Ruby reading, I recommend in order from most filtered to least:

• Ruby Inside
• Ruby Flow
• Ruby Corner

Also, it’s useful to be cognizant that you will start Ruby as a productive developer without necessarily knowing the in depth metaprogramming stuff which is hard.

Thanks Sunny Hirai for your time and insight. Questions? Comments? Send them along to the Vancouver.rb forum/mailing list. Thanks!

Welcome back to the Vancouver.rb Q&A series. Today let’s welcome Vancouverite Jim Pick, 38.

dRuby is very nice compared to other techniques, because there is almost no stubbing code required at all. On the other hand, any interface that needs to be public and portable to other languages is probably better handled using something like REST and JSON.

TiddlyWiki is a JavaScript wiki implementation that can run entirely inside a users browser, saving locally instead of to a remote server. I am interested in developing a true distributed wiki implementation that supports a local distributed revision control store and conflict resolution — I think TiddlyWiki is an ideal platform to start that from.

Q: Can you tell us a little bit about yourself?

Jim Pick: I’ve been programming since I was twelve years old and been active in the free software and Linux communities since around 1997. I currently maintain the Kaffe.org project (a clean room implementation of the Java virtual machine), and I also host some services for the GNU Classpath project (free core Java class libraries) on my server.

I recently quit my regular day job to start work on a new free software project, which I hope to have ready to launch in September. I’ll be blogging about it on my website.

Q: Can you tell us how you got started with Ruby?

Jim Pick: I first started to use Ruby about two years ago when I started working at a Vancouver company called Bycast. They use Ruby extensively to handle the provisioning, configuration and installation of their Linux-based distributed storage product (which is resold by HP and IBM).

Independently, I’ve studied Ruby on Rails, and I put together a few small web applications for internal use at Bycast.

Q: Are there any Ruby (language) features that make Ruby a great choice for coding/hacking?

Jim Pick: I find the syntax to be quite clean, and it’s easy to write readable, approachable code with it.

It has enough flexibility in the language to support the creation of small DSLs (domain-specific languages) when needed — which is useful when used with restraint.

Q: What’s dRuby? Can you tell us more (about your dRuby hacks/projects)? How can you run DRb over SSL?

Jim Pick: dRuby is a simple way to do essentially remote procedure calls (RPC) between Ruby code running in different Ruby instances (even over the network). I used it at Bycast to write a distributed build system, as well as a distributed installer.

A while back, I did an experiment to see if I could get dRuby to work over SSL (following some instructions found on the ‘net). It worked, but I haven’t yet put it into any production code.

I might possibly use this technique for communication between tightly-coupled code written in Ruby. dRuby is very nice compared to other techniques, because there is almost no stubbing code required at all. On the other hand, any interface that needs to be public and portable to other languages is probably better handled using something like REST and JSON.

Q: Any commentary on Cloud computing and Ruby?

Jim Pick: I’m tracking the cloud computing space very closely for my new project. Ruby on Rails definitely has a lot of buzz around it, and there are quite a number of startups building Rails hosting clouds (e.g. Engine Yard, Heroku). There are a lot of ways to put together a Rails stack, and it will be interesting to see which variations of the stack find market success. I’m very interested in Google’s App Engine, which is definitely Rails-inspired, even though only Python is currently supported.

Q: Any thoughts on JavaScript applications, frameworks and the emerging offline support in browsers? (What’s TiddlyWiki?)

Jim Pick: Eventually, I expect to see just about every high level language show up in web browsers via plugins e g. Ruby will be available for Internet Explorer via Microsoft’s Silverlight Dynamic Language Runtime. However, for the next few years, Javascript is the only language that is almost guaranteed to be everywhere on the client side.

The emerging HTML 5 standard provides some standardized support for offline applications. Until then, Google Gears is a nice browser add-on to provide offline support today in the mainstream desktop browsers.

TiddlyWiki is a JavaScript wiki implementation that can run entirely inside a users browser, saving locally instead of to a remote server. I am interested in developing a true distributed wiki implementation that supports a local distributed revision control store and conflict resolution — I think TiddlyWiki is an ideal platform to start that from.

I feel that it is important to understand client side concepts such as offline and sync, as they also are the key to building cloud computing systems that offer high performance and reliability.

Q: Any tips, tricks or advice for developers getting started with Ruby?

Jim Pick: I started by reading the “Pickaxe book” cover-to-cover (over a period of six months and many coffees). I had some background in Perl already, and many other languages, so I found it pretty easy to absorb — although I imagine that some people might find it a bit dry.

I learned Rails by reading “Agile Web Development with Rails” (Second Edition). Rails is particularly difficult to learn, as it changes so much from version to version, and the books take a while to catch up. Also, it demands a lot of expertise in other areas, eg. HTML, SQL, Unix, Javascript, CSS, etc. It is probably not the best thing to tackle if you are just getting started with computers. On the other hand, it’s approach to “convention over configuration” is a real eye-opener compared to some other web frameworks. Thanks for the questions!

Thanks Jim Pick for your time and insight. Have some more questions for Jim Pick? Join us at an upcoming weekly Vancouver.rb Open Ruby Hack Night mondays and talk in person to Jim Pick or other Rubyists in Vancouver or send along your comments, questions to the Vancouver.rb forum/mailing list. Thanks!

Welcome back to the Vancouver.rb Q&A series. Today let’s welcome Victorian and soon Vancouverite Adam Palmblad – the cofounder and dev lead of startup TeamPages.com.

Our photos and uploads are handled with Rick Olson’s attachment_fu. Emails were initially problematic, but between ar_sendmail and some improvements I’ve made to it (maybe open-sourced one day), that problem is solved.

We run Mongrel and Nginx, and I’m happy with that setup, despite knowing some people who are quite happy with LiteSpeed.

On a big development branch we’ve just switched to Rails 2.1 and I’m pretty happy with that – named_scope has been good fun to work with.

Q: Can you tell us a little bit about yourself?

Adam Palmblad: I’m a cofounder and the lead developer at TeamPages, and I’ve been with them since the beginning, 18 months ago.

I’ve been developing websites since high school – first with Perl back when 5.004 was new, and later with PHP. I think I remember a project using both MySQL and PHP 3.

I’ve got a degree in computer science from the University of Victoria.

In my spare time, I love to get outside. I enjoy rockclimbing and mountaineering – one of the things I’m looking forward to, with respect to moving to Vancouver, is being closer to Squamish.

Q: How did you get start with Ruby on Rails? Any commentary what makes Ruby or Ruby on Rails a great choice for developing web applications?

Adam Palmblad: I kind of jumped into Ruby on Rails with TeamPages. Initially, when we were starting TeamPages, we weren’t sure what language to implement it in. Rails was getting a lot of hype back then, and I played around with it a bit, and it felt good. Scaling was a bit of a concern, but we figured we’d be okay. There were blog posts going either way, and scaling is one of those things where you need a working application and users to figure out the hotspots.

I loved how fast it was to get going in it. The Rails Domain Specific Language (DSL) bits were easy to pick up and made a lot of sense. Ruby, once I got used to it, was a lot of fun, and made a lot of sense. Ruby’s definitely replacing Perl as my quick hack language of choice.

Q: Can you tell us a little bit about TeamPages.com?

Adam Palmblad: TeamPages is the brain child of our CEO, Mike Tan. Mike was finishing up school at University of Victoria (UVic) and playing intramural sports. His team had a really tough time getting players to show up, and ended up forfeiting a playoff game because no one on his team knew to show up. Solving that problem is a foundation of our business.

Fast forward a little bit, and we’re a venture backed corporation moving to Vancouver. We’ve been going strong for the past year and a half. Watch for exciting new developments at the end of the summer (August-September).

Q: Inside TeamPages.com – Can you tell us a little bit about the architecture of TeamPages.com and highlight some libraries (gems), plugins or other (open source) building blocks that get used for TeamPages.com?

Adam Palmblad: I have to give a shout out to Engine Yard. I love having a solid IT team on hand to deal with things like that – be it power, equipment failure, network connectivity, poorly configured system software (other hosting companies have done unexpected upgrades causing breakages), even the occasional late night software glitch.

As far as gems go, I don’t think we’re running anything really interesting. Our photos and uploads are handled with Rick Olson’s attachment_fu. Emails were initially problematic, but between ar_sendmail and some improvements I’ve made to it (maybe open-sourced one day), that problem is solved.

We run Mongrel and Nginx, and I’m happy with that setup, despite knowing some people who are quite happy with LiteSpeed.

On a big development branch we’ve just switched to Rails 2.1 and I’m pretty happy with that – named_scope has been good fun to work with.

Q: Can you tell us some challenges you faced while developing TeamPages.com using Ruby on Rails?

Adam Palmblad: My biggest problem is rendering time. I’ve got around that by trying to be really careful with the code, doing more with JavaScript, and cutting down on queries and object initialization with fancier queries.

I kind of like tossing custom stuff into a :select on an active_record find – we have some complex relationships in our data and sometimes that’s the fastest way to do it.

Q: Any tips, tricks or advice for developers getting started with Ruby or Ruby on Rails?

Adam Palmblad: Just dive in. That’s basically what I did. Started with an example app, and then played around with a domain I had some experience with. Early on, I found the PeepCode Screencasts really helpful. I’ve got “Agile Development with Rails”, but I’ve never finished it. I’ve hacked around a bit, and played with different plugins, read some of the source code.

I found the local Victoria Ruby User Group helpful as well. Especially starting out, they recommended a lot of gems, blogs, and all-round good stuff. Why’s guide is a classic, although apparently not for everyone.

I still keep a browser tab open to www.gotapi.com as well – face it, the Rails API docs aren’t that great, especially for searching, and gotapi just makes it easy to search the Rails API, the Ruby standard libraries, DOM methods, Prototype, and JavaScript.

Thanks Adam Palmblad for your time and insight and welcome to Vancouver. TeamPages.com is hiring! See the Joint Vancouver Job & Gigs Board (running on Ruby on Rails and Passenger) for postings.

Questions? Comments? Send them along to the Vancouver.rb Forum/Mailing List. Thanks!

Let’s follow the example of the Seattle Ruby Brigade (Seattle.rb) and let’s start a weekly Vancouver Open Ruby Hack Night every Monday.

Interested? Let us know on the Vancouver.rb mailing list/forum and join us for the 1st Open Ruby Hack Night at Waves Coffee at the Hastings and Richards corner (offering free wireless) in downtown Vancouver one block from the Harbour Centre.

When: Monday, June 9th, 2008 – 7pm – Whenever (9ish)
Where: Waves Coffee, 492 West Hastings St.

Comments? Suggestions? Send them along to the Vancouver.rb forum/mailing list. Thanks!

The Planet Vancouver.rb (planet.vanrb.com) publishes Ruby/Rails stories from in and around Vancouver for easy reading or subscription in a single “river of news”. Latest stories include:

• JRuby 1.1 Goodness – Important, Why? – by Tim Bray
• Typo by Geoffrey Meredith
• Ruby and other Gems by Avi Bryant
• Presentation Tip: Haml Rocks! by Eric Promislow
• Be Less Stupid and Ugly – Using git with vlad by Joe Bowser

Interested in getting your blog included? Send a blurb about your blog highlighting some Ruby/Rails stories to the Vancouver.rb Forum/Mailing List. Thanks!

Welcome back to the Vancouver.rb Q&A series. Today let’s welcome Vancouverite Brock Whitten.

Rails is awesome. I try my very best not to say things like Merb is “better” than Rails but it is. Let’s keep in mind that part of the reason it’s great is because it is a lot like Rails and Merb was able to learn from the mistakes Rails learned the hard way. The most obvious advantage that Merb has is for writing APIs. If you were to build an API with Rails you are loading this entire (kitchen sink) framework for something very simple. Think alone of all those view helpers you won’t be using yet they are being loaded for every instance of Mongrel. This is like driving a motor home to the cornerstone to buy milk. Merb on the other hand is broken into chunks (merb-core, merb-more, plugins) so you only load what you need. This makes Merb multiple times faster than Rails.

Q: Can you tell us a little bit about yourself? How did you get started with Ruby on Rails? What makes Ruby on Rails a great choice for developing web applications/sites?

Brock Whitten: By day I’m a Rails Developer for the Vancouver animation studio, Bardel Entertainment(seen Viva Pinata?). My job there is focused on building tools that help our animators build cartoons better and faster. By night, If I’m not sharing a pint or watching a film with one of my chums, I am at home working on one of my many side projects (almost all Merb related).

Actually I fell in love with Ruby on Rails while studying PHP at BCIT. As soon as I graduated, I bought every Ruby book I could get my hands on and have not looked back. I’m very happy as a Ruby/Rails developer.

Rails is a great way to build web apps because it allows you to focus your efforts on creativity rather than mundane tasks. It saddens me to see how many people have lost touch with this point.

Q: Can you tell us some challenges you’ve faced developing using Ruby on Rails?

Brock Whitten: I was still fairly novice programmer when I got onto Rails, and Rails itself was still young and working out its kinks. This was frustrating for me at times because I could see the framework was in need of plugins, documentation bloggers and speakers but I was not mature enough as a developer to contribute on this level. Ironic enough, now that I am capable, Rails is solid and the community is thriving.

I have benefited greatly from the Ruby community and thus have always felt a debt to it. I have been waiting for the right opportunity to give back and Merb has opened that door. Currently Merb has many of the same needs as Rails did a couple of years ago and I will be contributing as much as I can to this community.

Q: Off the Rails – Can you tell us a little bit about Merb? How did you get started? Any insight on how Merb compares with Rails and how it’s better or worse?

Brock Whitten: Rails has received a lot of criticism lately, mostly regarding speed and scalability. I think this is because people are using Rails for things they shouldn’t. Can you blame them? Rails is awesome. I try my very best not to say things like Merb is “better” than Rails but it is. Let’s keep in mind that part of the reason it’s great is because it is a lot like Rails and Merb was able to learn from the mistakes Rails learned the hard way. The transition to Merb is very natural, Rails developers should have much of a problem. The most obvious advantage that Merb has is for writing APIs. If you were to build an API with Rails you are loading this entire (kitchen sink) framework for something very simple. Think alone of all those view helpers you won’t be using yet they are being loaded for every instance of Mongrel. This is like driving a motor home to the cornerstone to buy milk. Merb on the other hand is broken into chunks (merb-core, merb-more, plugins) so you only load what you need. This makes Merb multiple times faster than Rails. The trade off is polish, Rails has really evolved into a solid system. Expect some craziness with Merb, for a while at least.

Q: What’s PmpknPi? Tell us more about PmpknPi? What are your future plans?

Brock Whitten: For the right people PmpknPi is going to be a godsend. It is a very lean, fast, RESTful API for blogging (caching optional kind of fast). This is a blog engine for Ruby developers, not for your clients. The system assumes you are competent. It is very straight forward and is easy to modify. It intentionally does not have a user model or tempting, or a plugin system. Simply edit the settings.yml file and away you go. Comments have a voting mechanism (digg/reddit style) that does not require your users registering which I think should be standard on all blogs. Oh and did I mention the JavaScript is completely unobtrusive and degradable. I just tagged the 0.1 release. Give it a go and don’t be afraid to fork the git repo at GitHub or Gitorious. Who knows? perhaps I’ll pull some of your changes.

Future plans are to add asset uploading with thumbnailing and a tagging system (that’s 4 models total!). That’s it. I plan to always keep it very basic. I’m hoping people will customize it to their liking and then write a tutorial on how to apply those changes such as adding your twitter feeds or adding multiple users using the merbful_authentication plugin.

It should also be noted that PmpknPi will be used for merbman.com which is days away from launch. I will mostly be me writing about my experiences with writing Pmpknpi and talking about Merb.

Q: What’s Git? What has been your experience using Git for PmpknPi? Any pros or cons versus subversion? Any comments on (free) Git hosting services?

Brock Whitten: Well you don’t have to go far to see the excitement around Git. I am hosting PmpknPi in two Git repositories (GitHub and Gitorious) and one Subversion repository at Google Code. Git has made this super easy. Subversion can do most of what Git can do. The big difference for me is that with Git I actually use the tools. I find myself creating, merging and using branches all the time where as with subversion I tread lightly around those tools. Git is also setup in away that allows for people to fork and contribute to your project with ease. As for free Git hosting, Gitorious is fantastic. It seems to be constantly improving in both features and speed. Only downfall is you can currently only do open repositories. For private ones you will have to go to GitHub which is the ‘golden standard’ of Git hosting. It is currently beta-by-invite but I have some invites kicking around so I’m open to anyone emailing me for one if they feel they will use it.

Q: Any commentary on jQuery? How is it better or worse than the “classic” standard Rails JavaScript library Prototype? How does jQuery fit into the Rails or Merb universe?

Brock Whitten: I wanted to see the Prototype/Scriptaculus extracted from Rails 2.0 to level the playing field for other JavaScript libraries such as Moo-tools and JQuery to make its way onto Rails. Seriously, it’s time we separate our JavaScript from our content! Dan Webb has been telling it right for some time now but he is still ignored by the Rails community. It should be noted that you can program unobtrusively with Prototype but Rails/Prototype persuades us to do otherwise. That’s why I have switched to JQuery for both my Rails and Merb projects.

Q: Can you tell us a bit about your upcoming Open Web Vancouver “Off the Rails” talk? What’s it all about?

Brock Whitten: I’m very excited about being the person who gets to speak about Merb at the Open Web conference. The plan is to give a quick rundown of Merb and where it fits into the ‘framework’ landscape. I will then demonstrate some code (perhaps whip up a quick blog from scratch). I will certainly leave some time to answer questions. Be warned, there is a very good chance you will leave my talk wanting to port many of your projects to Merb.

Q: Any commentary on Zed Shaw’s “Rails is a Ghetto” essay/rant?

Brock Whitten: I like Zed a lot. I think he is very genuine and cares greatly about his work. That doesn’t mean that I agree with everything he says but none of that matters. What matters is Zed is willing to let it be known when something is not right even if that may come at a high cost to him. That’s the kind of person I want in my community.

Thanks Brock Whitten. For more join us at the upcoming Open Web Vancouver 2008 conference at Canada Place on April 14+15th.

Questions? Comments? Send them along to the Vancouver.rb Forum/Mailing List. Thanks!

In a new monthly series I will spotlight Ruby projects from Vancouver.rb members starting off with a little Ruby gem – Slide Show (S9) – by yours truly

What’s Slide Show (S9)?

Slide Show (S9) is a free web alternative to PowerPoint and KeyNote in Ruby that lets you create slide shows and author slides in plain text using a wiki-style markup language that’s easy-to-write and easy-to-read.

New in v0.2 are “loss-free” vector grahpics gradient themes. See some samples online using the “classic” sixteen web colors plus nine gradient styles such as “Diagonal”, “Radial Off Center”, “Top Bottom” and more. Try the “Radial Repeat” theme for some free psychodelia. (Note: Built-in SVG browser support required – e.g. use Firefox or Opera). Or try the Microformats slide show live on your very own desktop.

Find out more at the Slide Show (S9) project site. Questions? Comments? Send them along to the Free Web Slide Show Alternatives (S5, S9 And Friends) Forum/Mailing List. Thanks!

Interested in getting your Ruby project spotlighted in the new Vancouver.rb series? Send a blurb to the Vancouver.rb Forum/Mailing List and tell us about your Ruby project to get it all started.

You are invited to join us for RubyCamp 2008 in Vancouver on Saturday, January 26th.

RubyCamp is a free one-day gathering for Rubyists and Railers.

When and Where:

WorkSpace in downtown Vancouver, B.C., Canada
January 26th, 2008 from 9:00 to 5:00

Who Should Come:

Anyone who’s interested in Ruby and Rails, whether you’re just interested in learning what this Ruby thing is all about or you know Ruby inside out.

The Conference Track:

A conference-style track with “classic” talks on Ruby or Rails topics. We’re looking for a few more speakers, send in your talk proposal!

The Hackathon Track:

An informal un-conference track focusing on hacking some Ruby code, showing off a cool feature you just added to your Rails application or demonstrating a new addition to Rails 2.0. If you’re interested in working on some code or showing off something, get started by promoting your ideas and get some buzz going.

See you all at RubyCamp in Vancouver. For more info, see the RubyCamp Event Site.

Mike Cantelon writes in that the Vancouver PHP User Group organizes Vancouver’s 1st Two-Day Open Web Conference 2008 at Canada Place at the Vancouver Convention & Expo Centre from Monday April 14th to Tuesday April 15th in 2008.

The organizers invite you to send in your talk proposal on open web technologies including – of course – Ruby on Rails and other Ruby gems.

Deadline for talk proposals is Dec 31st 2007. Registration opens Dec 22nd 2007 at $100 early bird pricing. After January 31st 2008 registration jumps to $150.

The slide deck from Paul Prescod’s short talk on “Ruby from a Pythonic Point of View” from the VanPyZ “Language Futures” Event resides now online.

Talk slides include:

• (Arguably) Nice Ruby Syntax
• Map/filter/reduce chaining
• What is a block?
• Blocks in Ruby are kind of like…
• Simple blocks versus lambda
• Ruby: bigger block
• Python multiple lambda
• Blocks and for-loops
• Smalltalk does blocks better!
• Ugly Rubyisms

Any comments or thoughts? Send them to the Vancouver Ruby/Rails Developer Forum/Mailing list.