Ruby

I just received this message from Brian McConnell. Brian is an O’Reilly author and blogger, and generally a smart guy. I didn’t know he was working in Rails–I’ve always thought of him as a Pythonista. Anyway, if you’re interested in this project ... [More] , let him know. Description follows… > I am writing to invite you to join, and hopefully contribute to, a > project that has the potential to revolutionize communication. > That’s a tall claim, but this is a simple idea that solves a tough > problem. I have been working on this problem for many years, since > 1998 including early work, and have developed a system that will > enable publishers to marshall their own readers to translate their > websites, blogs or any other texts into many languages. Let me > first describe how this works. > > The prototype system we have developed (in RoR if you’re curious) > monitors a participating website’s RSS feed for new articles. When > it finds new content, it runs it through machine translators to > obtain rough, or gisted, translations to about ten languages. It > creates a wiki page for each translation. The publisher encourages > his/her readers to go the wiki to edit and improve the > translations, or start translations to any other language. The > translations are output via RSS and static HTML. The key insight I > had was to realize that any website with a decent sized audience is > bound to have bilingual readers without even knowing it, some of > whom will be happy to translate posts to their respective > languages. This will also have a network effect because as a site > becomes visible in other languages, it will draw in more readers, > many of whom will speak other languages. It’s a simple technique > but it could have far reaching uses as the language barrier is > really the last frontier left in communication. > > Over the holidays, I thought seriously about developing this as a > business, but decided to give this away. This is an example of a > problem where open source is a superior solution. We have developed > a pretty good prototype in Ruby, as well as detailed specs that > describe how the system operates. The problem is that human > language is tricky, what works well for European languages might > not work so well for others. I decided to put this out there as a > reference design and starting point, so that others can take the > concept and adapt it to their needs, whether by embedding this > within a content management or blogging system, or by adapting it > to deal with other languages. The only centralized element of the > system is a statistics interface that keeps track of the documents > processed system wide (for counting and search engine optimization). > > I am putting this invite out via the O’Reilly lists because many of > you are developers, and because many of you are bilingual. I am > looking for people to contribute to the project as developers or > translators, as well as evangelists (to get the idea in front of > popular content management systems). My goal for this project is > ambitious. I want this to be a ubiquitous feature, as worldwide as > the worldwide web, even if users are not aware of the project > itself (from their viewpoint, they’ll just see “[Translations]” > links wherever they go). > > See the project’s website > for more information, including some detailed specs for our hosted > service. The test system will be live soon, at which time we’ll > also publish our source so that developers can adapt it to their > needs. > > If you’d like to learn more, or have specific questions, I can be > reached at brian ||AT|| mcconnell ||DOT|| net. [Less]

RubyForge has been growing fast. As the primary resource for project hosting in Ruby, it’s been expanding with the language. One thing that is interesting about it as a service is that it is more-or-less maintained by just one person (Tom ... [More] Copeland) with the help of a few other folks and some RubyCentral funding. A few months I joined the RubyForge team to try to lighten Tom’s load a bit, and have been monitoring the support forum since then. I think a whole lot of folks don’t even realize we have one while some others have mistakenly assumed it was a general Ruby forum. This post is meant to explain a little bit about what the forum is for and how you can use it to get the help you need. RubyForge offers a lot of services. We offer mailing lists, wikis, CVS/SVN hosting, project web space, file downloads, gem hosting, forums, tracking systems, and other things. Odds are if you’re involved in an open source project in Ruby, you’re using some sort of resource we host, and odds are equally good that you’ve run into to trouble with one or more of them. So the forum is a good starting place if you’ve got questions. It’s also a good place to make informal suggestions for ways to improve RubyForge to get some feedback. How the forum works. I am the only one actively monitoring the RubyForge forum. A lot of times, I’ll be the first and last person you’ll talk to on the forum. We’ve got a test project set up, and I also keep track of the latest known issues with our services, so I can usually replicate problems you are having if necessary, or point you in the right direction otherwise. Usually if your request requires administrative help, I’ll send you over to the appropriate tracker for your request. I don’t mind at all if you stop by to ask questions on the forum first, because the ultimate goal is to make it as easy as possible for Tom to deal with whatever support requests come his way. Clarifying questions or discussion often help make this easier. If your request is straightforward, you of course do not need to post to the forum. Heading straight to the bug / feature / support trackers is fine. Sometimes, you’ll be able to find a quick answer in our FAQ as well. What are good questions to ask on the forum? Pretty much anything about RubyForge or the services we offer makes a good topic for the forum. It is more of a support forum than a discussion forum, but if you have a good idea and want to hear what we think about it, it’s a fine place to discuss those. If you think you may be running into a RubyForge bug, please check the bug trackers before posting on the forum. That’d be a good place to add a comment with whatever additional info you can provide. Also, it’s fine to post on the forum if you think something should work and doesn’t. I usually can validate these things pretty quickly, and give you the necessary feedback to get you on your way. Sometimes when things are more complicated, I forward questions along to Tom. What should I avoid posting to the forum? Pretty much anything not directly related to RubyForge. It’s very hard for us to free up cycles to help folks with specific projects or administrative tasks such as learning ssh or svn. We almost always will just link you to the appropriate mailing list or webpage, so it’s likely that google will be faster than us for that type of thing. In case any folks on this blog have not yet found the RubyTalk mailing list or the Ruby on Rails mailing list, these are two excellent resources for asking general questions. Your posts make a difference! One benefit of a small team is that usually we can directly address any issue that arises, which often results in bug fixes, feature additions, the creation of new documentation, and other things. Of course, it especially helps when people provide these things to us, but we try to accommodate as much as possible. Since I’ve been monitoring the forum, I’ve seen a few cool contributions that range from minor doc patches and bug reports to better localization support for Esperanto. Since most of our services are open source, we’ll usually accept patches which fix or improve things. So, if you have a problem with RubyForge, come and tell us. But if you’ve also got the ambition to fix some of those problems, we’ll happily accept your contributions as well! [Less]

Yet another series attempt I think my NubyGems series has gone over pretty well, so I figured I’d try my luck with something else. This new series, digging deep, will be targeted towards the more experienced developer, or at least folks who want to ... [More] know a little more about some deeper concepts in Ruby. I’m going to do what I can to make these as clear as possible, but I’m relying on input from gurus and skeptics to help improve these posts and make them a good resource for folks. So this post will focus on a recent topic on RubyTalk, the merit of using Mixins as a suitable replacement for multiple inheritance. Overview If you haven’t worked with multiple inheritence before, or aren’t familiar with object oriented programming, this article isn’t going to be super helpful. However, as a quick review, the core concept of multiple inheritance is that an object can have more than one parent class. For example, perhaps you have a Student class, and you want to say Joe is a student, but he’s also a musician and a rubyist. Single inheritence would not let you have this kind of structure without awkward hackery, so multiple inheritence would make life easier. Though I’m sure there are folks out there who can explain why Java’s interfaces help simplify things in some cases, this sort of thing is a notorious source of annoyance in Java. A lot of times single inheritance just doesn’t do the trick. So often when folks hear that Ruby is single inheritance, they get sort of nervous. On the gripping hand, there are plenty of languages in which incorrect use of MI can really bite you. C and Perl would be common culprits, and I have to be honest, a ten foot pole isn’t long enough to keep me away from object oriented Perl 5. Ruby I suppose is lucky enough to be able to happily steal good ideas and throw away the bad ones. With this in mind, I think the Mix-in idea really fits the language. But isn’t a Module just a container / a crippled Class ? A short definition of a Module would likely be ‘a ruby class that cannot be instantiated and does not live within the class hierarchy’. It wouldn’t be 100% complete, but it’s enough to work with. This at first sounds inconsequential. But the semantic power that such a construct provides is rather vast. David Black mentioned that he likes the idea of having both a noun like construct as well as an adjective like construct available for modeling. That’s is a pretty good way to put it. This object is an Array. It is Enumerable. If you look closely, you’ll see the distinction. The relationship is not really an ‘is a’ for the latter, but more describes some behavior the object has. It’s noun vs. adjective, when it all boils down. For a quick example of modules in action, have a look at this use of Comparable. To get all your usual comparision operators(<,==,>,<=,>=,!=) in ruby, you just need to implement one method, the comparison operator(or spaceship). >> class A >> attr_accessor :data >> def <=>(other) >> data <=> other.data >> end >> include Comparable >> end => A >> a = A.new => # >> a.data = 78 => 78 >> b = A.new => # >> b.data = 10 => 10 >> a < b => false >> a > b => true >> b.data = 78 => 78 >> a > b => false >> a == b => true Since Fixnums are Comparable, i can just delegate on down to get the right behavior. By including the Comparable module into my class, I get all those methods for free as promised. This should be sufficient to show that we can avoid that interface problem. But it’s not going to tell you much about how mixins might save some headaches that MI introduce, so let’s get on to that, and luckily, this gives me an excuse to play with OmniGraffle. But isn’t that just MI under a different name? It might be tempting to just box off the idea of mix-ins as a direct comparison to multiple inheritance, but that’d be a misconception. The core difference between multiple inheritance and single inheritance is the former turns your hierarchy into a digraph where the latter preserves a tree structure. Since Ruby is single inheritance, the use of mix-ins prevents the issues associated with a more loosely arranged network of paths. Python 2.3 has a very good implementation of multiple inheritance, and this is mostly due to the fact that if a cycle forms in the graph, it is considered illegal. (Which helps make method resolution sane). Please refer to this paper if you’re interested in the details, as they’re a little beyond the scope of this article. However, this might be best explained graphically. I’m not a particularly graphical person, so bear with me :) So the graphs on the left are meant to represent a situation where the leftmost path from D to A is the ‘main path’, and the other paths represent orthogonal concerns. (Think of them of doing things similar to Ruby’s Comparable or Enumerable). On the right hand side, you see the same idea, but the overlapping orbs represent modules ‘mixed in’ to D. One of these clearly has a single linear path back to the root. The other would depend on how your language implemented its method resolution. Hopefully you can look at this and abstract the idea that no matter what, even when we mix modules into other modules, the results are a single component with no hierarchy attached to it. In this way, introducing new modules is much less likely to cause conflicts than introducing new parent classes, considering that it is rare in complex systems to know the entire topology well enough to avoid problems. I’m pretty sure this is the biggest case for the mix-in model, and it’s tough to find many situations in which its capabilities fall short of multiple inheritance. I see the point, but I still don’t get how to use these things in my modeling Basically, if you’re already familiar with modeling multiple inheritance in a sane way, the leap to mix-ins will be relatively small. However, if you’re new to the concept, it might take a little extra leap. Going back to David’s analogy, classes are our Noun component and modules our adjective. Perhaps we have a Record construct and we want to be able to add tags to these records( a la folksonomy ). This is an ideal time to say an object with the ability to be tagged is Taggable, which is a nice adjective, and makes a nice module. The following example is from Ruport’s source, and shows an actual use of modules: module Ruport::Data module Taggable def tag(tag_name) tags << tag_name unless has_tag? tag_name end def delete_tag(tag_name) tags.delete tag_name end def has_tag?(tag_name) tags.include? tag_name end def tags @ruport_tags ||= [] end def tags=(tags_list) @ruport_tags = tags_list end end end Nothing really surprising or fancy. However, both our Records and Tables are taggable, and they're not related to each other directly. This is what modules let us do, and it sure can be handy. The light at the end of the tunnel Hopefully this will bring folks who haven't been really thinking much about what modules are for closer to understanding how they work. Also, it might provide some insight for folks who are missing multiple inheritance, or for people who have been looking for a construct like this but didn't quite find it yet. I hope this explanation has been helpful, but if you have questions, please do ask them. Also, if you have some suggestions on how to make this more clear or notice any mistakes, let me know as well. Hopefully future articles in this series will help expose some of the deeper concepts within Ruby to those who are interested! [Less]

I’ve written before about how cool it is to see the JRuby and rubinius guys working together (Nick Sieger also posted a piece about it). (It can be mind-bending to follow a discussion across multiple irc channels though.) I’m even more encouraged ... [More] to see that Kevin Tew (the Cardinal hacker) and SASADA Koichi (the YARV hacker) have joined the fray. In his recent post about tail call optimization for YARV on JRuby, Ola Bini wrote: This work goes forward very fast, and it’s funny to see progress happen this quickly. Yesterday SASADA Koichi visited the #jruby and #rubinius IRC channels, and we had some very interesting discussions on further collaboration. The future looks bright indeed, and this weekend I’ll probably have time enough to take a first crack at a YARV compiler for JRuby. What’s going to happen next? Maybe one of the big-name Perl folks will start answering questions on ruby-talk — naah, that’ll never happen. [Less]

(correction): fixed Upton Sinclair quote it is ’salary’ not ‘job’ (thanks for the correction) Even with all the buzz, it is still a tough sell. If you’ve suggested Rails as an alternative to (Java|.NET) at work, you’ve probably experienced some ... [More] reactionary pushback. Convincing a set of established “Enterprisy” engineers that Rails is worth paying attention to it is like convincing a Texas oil baron that he should purchase a Subcompact hybrid vehicle and become a Vegan. Why is convincing a highly paid (Java|.NET) programmer to look at Rails that difficult? I’ll steal a quote from Al Gore’s Inconvenient Truth that he, in turn, stole from Upton Sinclair: “It is difficult to get a man to understand something when his salary depends on not understanding it.” - Upton Sinclair (1878 - 1968) In an effort to convince, you may have sent people to some of the good Ruby on Rails blogs. This might have escalated the resistance. Asking your fellow enterprise developers to read DHH’s loudthinking.com, is like asking (the other) O’Reilly to sit down with Colbert - Mr. Enterprise isn’t going to appreciate the message because he’ll be focused on the ridicule. Rails, rightly so, is positioned as the challenger, and it makes good use of hyperbolic ridicule to gain converts. This works for most of us, but I’ve also seen it push some entrenched Java developers further away. Common Responses So, you are in “The Big Planning” meeting, and your boss says something like, “There is no time to finish this project, we’re going to have to tell the customer we won’t meet the deadline.” You wearily offer up the suggestion: “We might be able to deliver something on time if we used Rails to implement the web application”. And, an entire room full of Java programmers is now trying to tell you every reason from here to the North Pole why your suggestion is naïve. Here are some of the common responses: Freedom (Too Much) - “Our developers are not disciplined enough to use a scripting language.” Rigor / Formality - “Our systems are serious and require a much more rigorous approach.” Performance - Our systems need to perform, and Ruby (specifically Ruby on Rails) doesn’t perform to our standards. Flexibility (Not Enough) - (Rails) We can’t afford to follow the database standards that Rails would impose on us Let’s take each one individually…read on… Myth #1: Too Much Freedom “My developers are not disciplined enough for a scripting language, we need the structure that a platform like .NET provides.” Answer: If your developers really do lack discipline, then they should probably not be programming in something as complex as .NET. Or, Java, let’s take Java as an alternative, Java is a powerful language, but it is a language based on choice: you can create a web application using one of 30 web frameworks, you can deal with persistence using Hibernate, iBatis, or just direct JDBC. And, if you are using the Spring Framework, you are really defining your own custom architecture as you go. If you need this level of flexibility, use Java, but, IMO, you have to be a bit more disciplined to create a good architecture in Java than you would to follow the bright lights in a Rails application. The real answer to Myth #1: “If your developers are not very disciplined, you can’t afford to not be using a tool like Ruby on Rails. If your developers are disciplined enough to learn Struts Spring Hibernate WebSphere, then I’m surprised you can’t expect them to learn ActiveRecord. Who are these people? I don’t believe you, what’s the real reason?” > Myth #2: Rails isn’t “Rigorous”. Scripting languages do not provide an adequate level of “structure”. “Our systems are serious and require a much more rigorous approach.” Answer: Myth #2 is born of a belief that systems built-atop scripting languages can be difficult to maintain, and this Myth is closely related to Myth #1. The problem with this myth is that it has absolutely nothing to do with scripting languages and everything to do with a universal industry truth - Bad Code is Difficult to Maintain Regardless of the Language. Anyone who’s had an encounter with bad Perl code in the past is going to appeal to this myth, but the real truth is that, again, it is less a specific problem with Ruby and more a fear of the unknown. I’ve seen .NET systems designed with all the rigorous process-driven, test-first, pattern-inspired magic you will find, but they were still a quagmire of logic. The other reason someone might offer this up is because they are frightened of not having compile-time type safety (or just frightened of not having a compiler at all). Compile-time type-safety isn’t so bad when we’re talking about the Solid Rocket Booster or a FIX gateway for the London Stock Exchange. But, with enough testing, this argument doesn’t make sense for something like a Web UI. The real answer to Myth #2: “Right! Let’s go back to the customer and tell them that even though we could deliver something on time, we’re not going to because it’s not a rigorous technical solution and that our developers are not disciplined enough to program in Ruby on Rails. What makes Ruby less ’serious’ than Java? You guys could still draw UML diagrams of model objects to your heart’s content, and, if you really need me to, I could generate just as many gantt charts and word documents about the code we write in Ruby.” Myth #3: Performance “It just ain’t fast enough…” Answer: What isn’t fast enough? Rails? Well optimize your deployment, figure out what a materialized view is. Think about the database a little bit, are you querying a table with 10 million rows? and do you know what an index is? Have you thought about database partitioning? Start using memcache, get faster hardware, use 40 instances of Mongrel. Don’t just stand there, fix it. You’d do the same for your .NET application. Myth #3 usually translates to, “I just don’t want to use Rails, and someone told me it isn’t fast enough.” In my experience Rails scales as long as you apply some brain power to your performance problems. If you just expect Rails to scale without taking any steps to achieve scaleability then you’ve really just staged a show trial for Rails. This myth is offered from people who want to Rails to break a leg out of the gate. If this is your reason, don’t tell me you didn’t have to go through a dog and pony show to optimize every other platform in your production network. Performance optimization is a black art regardless of the language or platform. Compared to Java: From the perspective of real cost, the cost of scaling a Ruby application is on par with a similar Java application. It takes about the same hardware to scale a big J2EE application as it would take to scale a large Ruby on Rails deployment. We’re talking about a few commodity servers running Mongrel with lots of memory. IMO, it might be a lttle easier to setup Apache mod_proxy mongrel Capistrano memcached, than it is to go through the motions of installing JBoss or Tomcat and then dealing with the lack of OS integration that most Java servers suffer from. In other words, if you are creating an application and attempting to scale horizontally, you’ll probably end up paying just about the same $$ to scale a well designed Java app or a Ruby app (assuming your container is free). You may end up buying an extra one or two servers for your Ruby application, but you are going to make up the cost in development. The real answer to Myth #3: “So, we’re not going to meet our deadline because you feel that Ruby on Rails just ‘isn’t fast enough’ in an abstract sense. You haven’t used it yet, we haven’t tested an application, or sized a real production deployment. No one has done an apples to apples comparison, all we’re going on now is your belief that Ruby doesn’t scale? Before you go on, let’s agree to at least study the issue, and the next time we talk let’s discuss specific numbers.” Myth #4: Flexibility “We can’t afford to follow the database naming conventions ActiveRecord demands” Answer: You don’t have to use the ActiveRecord naming conventions. (I’ve heard this more than a few times, “we can’t use rails because of our database…”) Sure, it is marginally easier if your database tables follow the naming conventions, but let me assure you Rails can work with almost any database no matter how strange. To prove this I’ll use a Siebel database as an example. A Siebel database is definitely not designed for ActiveRecord. Every table has a MS_IDENT column which is the primary key….then every table has a ROW_ID column which happens to be the application specific identifier. Column names of the foreign keys do not match the names of the tables they references. Foreign keys don’t really reference the real primary key, they reference the application specific id which isn’t just a simple autoincrementing integer. There are hundreds of tables, and, my favorite, no define FK constraints. Did I mention that all of the table and column names are somewhat cryptic. It took a little bit of effort, a module and some before_create methods, but if I can get a Siebel database to work with Rails, you can use ActiveRecord with anything. Compared to Java: …turn the tables on this one. EJB3 annotations in Java has the same “default naming assumption” behavior. If you don’t supply column names and table names, EJB3 will just assume them from the names of the columns and tables. If someone rules out Rails because of database naming conventions force them to hold Java (or .NET) to the same standard. Also, anyone who has been using Hibernate will tell you that Hibernate certainly has problems with oddly conceived databases - I’ve spent days trying to work with 3-way mapping tables in Hibernate only to find out that there’s some really mysterious bug with @MapKey. The real answer to Myth#4: “You are mistaken. If you read more than the first 40-pages of the “Agile Web Development…” book, you would know this.” Conclusion: When Reason Fails to Persuade… Sneak it into the organization if your arguments fail. Eventually someone will notice, and there’s a good chance you’ll get in trouble. But, there’s always a chance that your transgression will go unnoticed and your boss can go on happily believing that he is using a “Real Platform”. J But do us all a favor, if you are going to employ Rails behind hostile territory don’t turn into to one of those O’Reilly Radar-reading cool kids who is constantly throwing around references to Paul Graham and talking about how cool Web 2.0 is. Take your time, know your enemy, and work slowly. Use the language of your corporate masters Wrong: “Ruby is a revolution, dude, it’s going to change the way you think about coding. Rails will run circles around your fancy SpringMVC or ASP.NET applications. Coding Rails is fun!” Right: “Mr. Supervisor, sir, may I speak freely?”…..”I think we could leverage Ruby as a competitive advantage. For our next low-risk web application I propose that we engage in a feasibility study to assess the impact of a lightweight rapid application development framework. There is a real possibility that Ruby could encourage the productivity increase which will allow us to finish Q3 well under budget. It would be a great addition to our Enterprise’s ‘knowledge portfolio’.” [Less]