bgror

Is the Ruby Standard Library a Ghetto? »

Created at: 22.11.2010 22:14, source: Ruby Inside, tagged: Controversy Miscellaneous

In The Ruby Stdlib is a Ghetto, Mike Perham argues that Ruby's "standard library" (all the libraries that come by default with Ruby installs) is old and crufty and suggests some parts that should be removed.

The Problem

In case you're unfamiliar with the term, the ever authoritative Urban Dictionary lists ghetto as, among other things:

an impoverished, neglected, or otherwise disadvantaged residential area of a city, usually troubled by a disproportionately large amount of crime

Anyone's who recently looked up documentation for stdlib-dwelling libraries has probably been a little frustrated. I see rants and raves from time to time on IRC and Twitter and I'm often surprised at how much isn't documented. Frequently, documentation advocates like James Britt will encourage people to start contributing documentation in an attempt to tidy up their own back yard, but the process is, IMHO, reasonably arcane compared to that of other open source projects.

A Solution?

Mike's suggests that we remove most of the substantial libraries, like Net::* (including the popular Net::HTTP), DRb, REXML, RSS, and even WEBrick, and to have them as separate, RubyGems-installable libraries.

I agree. Even forgetting the technical aspects, freeing these libraries from the clutches of the standard library and having defined maintainers (on, say, GitHub) could encourage more developers to engage with them, fork them, provide patches, and so forth, as we see with other popular Ruby libraries.

The sticking point? The "standard library" is called "standard" for good reason. You can install Ruby 1.8.7, 1.9.2, JRuby 1.5, or any mainstream implementation and expect to run require 'drb' successfully out of the box. Taking libraries out of the standard library would change this and, of course, require significant community agreement and discussion, not least from the Japanese Ruby high guard.

I applaud Mike for kicking off the discussion, though. In a year or two's time, we might get to look back at the discussion much as we can now look back at 2008's "No True 'mod_ruby' is Damaging Ruby's Viability On The Web" and breathe a sigh of relief.

MacRuby + Mac App Store == Low Hanging Fruit for Rubyists »

Created at: 21.10.2010 14:05, source: Ruby Inside, tagged: Controversy OS X Specific

At its "Back To Mac" presentation yesterday, Apple unveiled the Mac App Store, an equivalent of the iOS App Store for the Mac. Given the relentless development and improvement of MacRuby and the power it brings Rubyists in developing complete OS X applications, I'm convinced that the time is right for Ruby to make a big splash on the OS X GUI app development front.

When I mentioned the above observation on Twitter, Geoffrey Grosenbach of PeepCode pointed out:

He's right, but things like app stores have a funny way of acting as catalysts for developers to come out of the woodwork and try new things out. Even taking the "evils" of app stores into account (and Apple's performed more than its fair share of evil incantations on iPhone developers), the ease with which you can put apps for sale and take money from customers (if only a 70% share) is appealing. The iPhone App Store almost reinvented casual gaming, for instance, and people I'd never have considered to try and develop a mobile app have been lured into the iPhone fold.

Given all of this, I think that if you want to develop OS X apps without moving away from Ruby, and you want to make proper money for your apps without setting up a Web site, building up traffic, and what not, now's the perfect time to look into MacRuby and Apple's Mac Developer Program. (But if you want to work on open source or sell your own stuff, do that too!)

Will Apple even allow Ruby built apps on to the App Store?

Keeping in mind the now semi-resolved 3.3.1 imbroglio, it's worth maintaining some healthy disdain as to Apple's intentions and future actions until they say something officially.

Someone's leaked the Mac Developer Program terms on to a pastebin site already, and nothing stands out to me as blocking the use of MacRuby for building App Store-deployed apps. Point 2.14 notes that apps must be packaged and submitted with Apple's own packaging tools included in Xcode, but since MacRuby is being developed at Apple, one hopes this will be easily done. Apple even has a guide called Developing Cocoa Applications Using MacRuby that digs into using Xcode.

Other points note that you can't install kexts (kernel extensions), have your own licensing system, offer "trials", download other apps from within your own, or use setuid/root privileges, but these affect the behavior of your program rather than its underlying formation.

John E Vincent suggests that point 2.24 "Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected" would reject the use of MacRuby. I disagree. In OS X, Java is a giant collection of frameworks maintained and updated by Apple as part of the OS, whereas you can build fully packaged, standalone OS X .app files with the MacRuby framework tightly packaged inside. I could be wrong, though - what say you?

Where next?

First, you're going to need to test the waters of building OS X GUI-based apps with MacRuby so head to the official site to download and install it. Be aware that you need to be running OS X 10.6 (Snow Leopard) or higher.

Next, read up on how to build a basic app. Choice reads include:

• Apple's Developing Cocoa Applications Using MacRuby guide is a reasonable place to start.
• A more significant and up to date resource is the currently-in-beta MacRuby: The Definitive Guide by Matt Aimonetti.
• Phusion's Creating our very first Mac application with Ruby is a great (and recent) step-by-step walkthrough.

Not a fan of reading? Alex Vollmer and Geoffrey Grosenbach have put together a Meet MacRuby screencast. It costs $12, but you're going to be raking in the millions with your new Mac app on the App Store, right?

Finally, once you're happy with the idea of developing Mac software in Ruby, you'll need to become a member of the Mac Developer Program. This is not the same as the iOS Developer Program and you'll need to pay another $99 per year fee to get into it. What do you get? Private discussion forums, technical support, pre-release software (including OS X builds), and the ability to sign and submit Mac apps to Apple for inclusion in the Mac App Store.

Disclaimer: If Apple comes out and says you have to use Objective C for your Mac App Store apps, don't blame me!

Does Ruby Suffer From An Overabundance Of Choice? »

Created at: 11.08.2010 03:02, source: Ruby Inside, tagged: Controversy

In "So You Want To Be a Ruby Dev" Kevin W Gisi presents a tongue in cheek narrative of a new Ruby developer being guided through the choices they have to make. (It's being discussed on Hacker News too - some good comments there.)

He asks a lot of questions: Which Ruby implementation to use? Which Web framework? Which Gems? Which version of Rails should you use? Which database adapter? And he caps it off with a conclusion of sorts:

Remember when Ruby and Rails was about getting stuff done? Note: New developers, Ruby is still a great place to be - even if there is an overabundance of choice at the moment.

Kevin W Gisi

I like Kevin and I saw merit in his satirical tale (for without any merit something is not satire), but right away my gut felt his conclusion was bogus. I wondered.. is there another problem here or does Ruby really suffer from an overabundance of choice?

If we're talking about the number of tools, implementations, or libraries, no. Abundance is Ruby's strength. It's the TIMTOWTDI (There Is More Than One Way To Do It) philosophy Ruby inherited from Perl, in contrast to Python's preference for only one obvious way to complete an operation. It's Ruby canon that Matz designed Ruby to be a fun programming language for himself but, also, a language flexible enough to adapt to other people's fancies and preferences. Rather than all of us reading from the same hymn sheets, we can bend, bolt onto, and monkey patch Ruby to fit our own personal or team preferences. This approach has its (much discussed) failings, but it's a philosophy nonetheless.

The overabundance is in the options we present

Still, I detected truth in Kevin's narrative. I realized, though, that it's not that Ruby is no longer about "getting stuff done" or that there's an "overabundance of choice" in libraries or tools. The problem is that Ruby's documentation, main advocacy sites, and even most sites for popular Ruby libraries (with one major exception - coming later) try too hard to demonstrate freedom, flexibility and choice from the get go without giving an opinionated, direct instructional approach for newcomers.

Let's take a cheap example (cheap, because the official Ruby site is really good, it could just be even better!) Consider the first thing some budding Rubyists will check out: the official Ruby download page. The first paragraph asks you to read Ruby's license before moving on to Ruby's source code and then Ruby on Windows. Instructions for Linux and OS X (the latter of which is out of date) are way down the page. Compare and contrast with python.org's approach - python.org's not perfect, but the link you want is almost guaranteed to be above the fold.

We need to be more specific in our READMEs and Web sites where we can and think about what a smart newcomer would want to see. We need "Getting Started" or "For Newcomers" pages that tell people exactly what to do without bending over backwards to cover edge cases or show off esoteric features. Tours that don't take diversions. Download X. Type Y. Run code Z. Instructing, rather than showing a smorgasbord of options, from which a new, confused user would choose none. Rather than offer 5 vaguely different alternatives on a "How To Install" page, give the simplest, most generic route, then discuss the alternatives for "advanced users."

Books are great at this sort of direction. Take almost any instructional Ruby book and even if it's out of date or not doing things "the accepted way", it will take a position and stick to it. Novices can follow along and make smarter judgements later. Let's bring that to our own work too, where we can (and I'm certainly aware there are people who do do this already - that's great!). I'll be going through my own libraries and future blog posts to keep an eye out for this and figure out how a newcomer might perceive them. Satish Talim's RubyLearning blog and courses have proven there's a gigantic population of people who consider themselves Ruby "newbies" reading what we write - it would be great if any of them could have a defined route to try out almost any library they stumble across.

Rails gets it right

Rails has been good at the instructional approach over the years. The "type this, type that, start a server, and bam, you've got an app" approach has been instrumental in the boom of Rails' popularity. Things like the "build a blog system in 15 minutes" screencasts were huge hits. Even complete non Rubyists could follow the same moves precisely and get the same results which they could then play around with further. Imagine if every good Ruby library had similar resources? (And if Railscasts has done a video for your library or tool and you're not making it a centerpiece of your site or README, sort that out!)

It's easy to forget that when we write about Ruby, the jargon and "do what you like" approach we frequently celebrate can seem alien to even the most intelligent newcomers who may well be used to more structured, directed "do X, then Y, just because" environments. We should provide hard and fast answers for those people, even if we run the risk of being a little wrong from time to time, without jeopardizing the richness of the number of tools, libraries, or implementations that exist.

Update 1: And I'm acutely aware now that Ruby Inside itself is not living up to the ideals professed here. I intend to resolve that. I only came up with this right now ;-)

Update 2: To be fair to Kevin, it seems he shares most of these opinions and that, perhaps, this line of thinking was his ultimate intention, judging by his tweets since he wrote the article.

The Rails Envy Podcast Becomes.. The Ruby Show »

Created at: 26.01.2010 02:33, source: Ruby Inside, tagged: Controversy News

If you try to keep up with the Ruby community you're probably familiar with the Rails Envy podcast, even if you aren't subscribed. Well, it's just relaunched as.. The Ruby Show, hosted by Jason Seifer and Dan Benjamin. They plan to cover the latest Ruby related news on a weekly basis in a similar style to Rails Envy. New episodes come out each Wednesday.

The latest episode of The Ruby Show includes bits on Cramp, the Rails 3 Bug Mash, Friendly, Rails 3 Generators, ActiveModel, and more.

The Background: Rails Envy was a weekly podcast by Gregg Pollack and Jason Seifer and featured Ruby and Rails news interspersed with comedy bits. The podcast did really well, getting about 7000 subscribers within two years, but for some reason, Gregg and Jason stopped working together and Gregg went off to found Ruby 5, a new bite-sized Ruby news podcast delivering 5 minute episodes once or twice a week.

Dan Benjamin Enters Stage Left: Undeterred by the split, Jason kept the Rails Envy brand and brought podcasting genius Dan "voice for radio" Benjamin on board to co-host. To my surprise, the podcast got even better and has made for entertaining listening, even when Dan did an entire episode on his own.

Go Check It Out: Podcasts aren't for everyone, but Dan and Jason are doing a great job, so at least check out an episode or two from time to time. You're usually guaranteed a laugh.

And before anyone asks, no, that picture isn't of them. Well, the heads are, but I superimposed them on to other people using Photoshop. Why? Because this is timely news and Jason didn't provide a picture quick enough ;-)