Pensieri di un lunatico minore
So a friend of mine, who is a film director, approached me today to see if I might be able to help with putting together an application to help automate the process of submitted and judging movies for film festivals. Specifically, he works with a lot of shorts (mostly under 15 minutes), and has been dissatisfied with all the existing solutions. Seems like it wouldn’t be too hard to do better than the current status quo, and it would give me something to work on in my copious spare time. If I decide to work on it, I’ll likely blog about it, since I intend to make it open source.
No thoughts
Recently, the Ruby on Rails edge gained a new feature: cookie-based sessions. There’s pros and cons to this, but I’m curious to see how it plays out. It definitely reduces the shared components even further, but I wonder how performance will manage against other back-end stores, such as memcached. The YUI blog has a look at the impact of cookie size on performance that makes me think it might not be bad if you don’t store much of anything in it.
2 thoughts
I have recently started using MindJet’s MindManager to do a lot of exploration of ideas. This has been very useful for me to get a lot of interesting things down. Previously, I had used OmniOutliner for that, but in some ways, that was a bit difficult to visualize a lot of the relationships.
One area I’ve been exploring is using MindManager to develop the skeleton of a document, and as I’m working on that, I decided that I’d try to write a little script to take the structure in MindManager and turn it into a LaTeX document. Since MindManager supports AppleScript I started to look at writing some AppleScript to do it, but quickly remembered that I absolutely hate writing AppleScript. Instead, I thought about the whole Open Scripting Architecture that Apple provides and a bulb went off.
A while back, I remembered reading about rubyosa, which provides a bridge between the underlying object model of OSA and Ruby. This is a substantially nicer alternative to AppleScript, and actually makes for a nice way to develop code. For example, the following snippet will go through all the Topics in the frontmost mind map and display them. It’s trivial, but, a start:
require 'rbosa'
mm = OSA.app('MindJet MindManager')
front_document = mm.documents.first
front.document.central_topic.subtopics.each { |topic|
puts topic.title }
Very simple, but demonstrates how quickly you can get information. Make sure you run the rdoc-osa script to generate documentation for the dictionary. This works pretty well, and I’ll post the script as soon as I finish. One unfortunate thing, which is mentioned in the support forums, is that the notes area of the map—text attached to each topic—is not available via OSA yet. This sucks, because otherwise it would be a great way to start putting thoughts together even better.
7 thoughts
As I was reading Jay Fields’ post about using Rails in an enterprise environment, I am struck most especially by this little tidbit:
Did Rails handle this type of environment out of the box? No. However, Ruby + Rails made it easy to extend Rails where it was necessary. Since I was able to easily extend the framework to my needs, I’m now completely comfortable stating that Rails is “Enterprise Ready”. In fact, out of the box Rails solves about 80% of the problems I have, which is better than most “Enterprise” software I’m usually working with.
This mirrors my experience with supposedly “serious” “enterprise” software. They have a billion knobs on them, and none of them actually do anything you need them to do. Instead, they contribute massive complexity that actually prohibits you from making the changes that are needed to adequately accomplish the task at hand. It also increases, exponentially, the testing requirements to even have some modicum of confidence that the platform does what it should.
I would rather take an easily modifiable, open platform that I can make do what I need in a specific environment. Everyone else can play with the “serious” software, and keep adding on gee-gaws until it collapses in on itself and forms the black hole of productivity, where no good idea can escape.
No thoughts
Again, someone misses the boat and the picture and pretty much can’t find the dock. It’s dangerous to conflate the core platform with all available components. One can always draw a small enough circle to claim that a pet feature is missing. It always will be, if that’s where you get your jollies.
No thoughts
Regardless of what you think of their business model, or people who haunt their site, eBay is by far one of the largest and most visible Internet sites in the world. They handle over 1 billion page views a day, and traffic in massive amounts of money. So it was with great interest that I found this PDF presentaiton which outlines some of their approaches, as well as the history.
What it outlines is quite interesting. One, it emphasis horizontal scaling over everything. Second, and more interesting in a Rails-context, is that they have pulled nearly all business logic out of the database (Oracle). Further, they’ve gone one step more, and actually do a lot of the joins outside the database.
That’s a lot further than I would go normally, but it also depends on the size of the data set. If you have a relatively high intersection rate in the join, then you likely can do it that way with less CPU on the database. If, instead, you have a low intersection rate, then you’d be moving potentially a lot of data that isn’t needed. Only testing will show the true answer.
Just curious.
2 thoughts
There are those in the “analyst community,” who are especially skilled at leading from the rear. This keeps you safe, but also means you’re the last to see what’s going on. While I am no proponent that Ruby or Rails is the panacea that some see, it is changing people’s perceptions of dynamic languages and, in some ways, having a lot of influence on the agile community.
So for those who look for data points in the ether, I bring you two:
As I am want to say: curioser and curioser.
No thoughts
Not sure what to call it, but Nick Siegel’s code to make autotest work with RSpec when using Rails is now a plugin. Yay! Back to the yumminess.
No thoughts
Sometimes, I do wonder whether my interpretation of the English language parallels the commonly-accepted version, and today is just such a time. Earlier, I wrote about some comments James McGovern made, and now Mr. McGovern has responded—unfortunately misrepresenting what I said, and conveniently leaving out bits. Let’s tear it does, as usual.
Read the rest
7 thoughts
Recently, James McGovern wrote about what it would take to make Ruby an Enterprise language, and as easy as it would be to be snarky and comment about certifications and bloated distributions, I thought I would take some of his suggestions that are noteworthy.
Read the rest
8 thoughts
As I’ve started working more and more with RSpec, I have found myself falling into a pattern of language use in my specifications, and that is one that mirrors the general language of RFCs. That language is best spelled out by Scott Bradner in RFC 2119, written in in 1997, but just as applicable today. It has the following definitions (paraphrased):
- MUST—This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.
- MUST NOT—This phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the specification.
- SHOULD—This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
- SHOULD NOT—This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
- MAY—This word, or the adjective “OPTIONAL”, mean that an item is truly optional. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option must be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
Right now, I struggle with my use of the language and the framework, as I do not believe that should and should not have any place in the expression of specifications for a software implementation. Instead, I think that must and must not are the only options that actually are appropriate. These parallel the RSpec use of should and should_not, however the semantic differences bother me. The use of may can be appropriate in the English specification, but the concrete instantiation of the requirements must be exacting.
For example, here is what I have as an idea for the representation of a standard (i.e. RFC that has become an Internet standard) as a ActiveRecord model. This is not the Ruby code, but the structure:
- A new Standard
- must have a governing organization (organization)
- must have a name (name)
- may have a number assigned (number)
- may have an issuance date (issued_on)
- may have revision information (revision)
- may have additional information attached (note)
I need to rip apart the RSpec implementation to see if it makes sense to just add must and must_not_ to the DSL.
These are just some thoughts on how the language of specifications should work. To me, the RFC model and vocabulary has been exceptionally effective for years, and there is no reason to change the semantic structure. I go back and forth as to whether the keywords mentioned above should even be used in ALL CAPS in the English description, as they are in RFCs, or whether it’s simply acceptable to leave them in lower case.
3 thoughts
No, this isn’t some horrid nightmare of an ice-skating competition involving coked-up super-models, it’s some spiffy new technology. Today, I got in my email, an announcement that ZeroC has released a beta version of their Internet Communication Engine with bindings for Ruby. I have written about Ice before, and I’ve used it to build some prototype applications using Python and some C++ (ick).
This is very nice, and I am very excited to try and see how it works. My concern is how it interacts with threading, since Ice has traditionally been very threading-dependent. It seems from first glance, that the Ruby bindings can only be used to build client-side applications, not the server component. This is likely the reason.
No thoughts
The Ruby community is in the middle of a kerfuffle about some growing issues. They boil down to three primary issues:
- The growing issue of multiple disparate VM implementations to replace the creaky and absurdly inefficient current Ruby implementation1
- The announcement that Ruby 2.0 would eliminate continuations
- Another announcement for Ruby 2.0 that abandons green threads)
What this seems to illuminate to me is that Ruby is on the cusp of becoming a victim of its own success. The growing attention that Ruby has been getting, primarily driven by Ruby on Rails has introduced an enormous amount of pressure on Matz and the community in general. This is not necessarily going well.
It is important to understand that the promise of a “new implementation” is quite overdue, and given the current issues, is well deserved in its priority. For some reason, largely a result of the general nature of open-source initiatives, there have been a pleathora of new VM implementations, primarily YARV, JRuby and RubyCLR, all of which are going in slightly different directions. This is not necessarily a bad thing, but I fear that “least common denominator” is becoming the norm.
The first place that this concern comes to the fore is with the announcement by Matz that Ruby 2.0 wouldn’t include continuations. Now, the concept of continuations is somewhat foreign to a lot of people, but the power behind the concept drives some of the most advanced systems in existence, and allows for the creation of entirely new flow-control concepts that are entirely too much like a Rube Goldberg contraption without them. Ruby Goldberg, if you want. I understand that few people use continuations, but the power locked inside them is likely to fuel an enormous number of exploratory ideas that may, in the future, illuminate the way to even more success. Don’t sell your future for a bit today.
Finally, the abandonment of user-mode threading, or “green threads,” presents a different problem. The two issues are, quite honestly, intertwined. Continuations are a way to implement user-level threading, as just another control mechanism. Threading is a complex and there is much disagreement, however, it is my experience that the only form of massive threading that works reliably is non-preemptive threading working at the user-level. Predictability is ensured. Mapping green thread pools to native threads is one way to gain some scaling issue, but threading should be considered because of the usability in implementing a design, not performance.
Overall, I’m not too worried, yet, but I do think that there’s a lot of discontent that may grow if some things are pulled out. A middle road would be to say that the first release of Ruby 2.0 would not contain either feature, and perhaps call it Ruby 1.99, but that it will go back in under some time constraint. Ripping expressive power is not the way to succeed. If you do that, you get Java, and end up having to build a baroque mess.
1 The current implementation is enough to give L. Peter Deutsch cold sweats at night. That doesn’t negate it’s usefulness, but it succeeds in spite of the disappointing implementation because of the elegance of the conceptualization. Maybe someone can figure out how to justify putting it on a real VM.
1 thought
I’ve been contemplating converting my site to Mephisto, mostly because it’s 100x more pleasurable to write code for Ruby on Rails than it is for PHP, but also because I get bored easily, and it’s something to do. I found a guide to doing this, which was very useful.
Except, for some reason, a lot of my comments have missing bodies, URLs or author names, and for some reason, this just doesn’t work with Mephisto correctly. Now, I don’t know how they got that way, but in the interest of expediency, and so that I’d have it to work on on the plane trip today, I modified the conversion program, and made it fill things in. The fun part? I was pulling it from a remote MySQL database (over an SSH tunnel for the session) to my local PostgreSQL database.
You can find the diff here. This gets applied to .../vendor/plugins/mephisto_converts/lib/converters/wordpress.rb, and poof, it’ll recover from the craziness. It’s a hack, but it works.
2 thoughts
Earlier I mentioned the TextMate bundle for the Ruby RSpec behavior driven development library. Since then, I’ve added a few new features:
- Written a language grammar for RSpec, which provides a bit more contextual highlighting, and makes possible some of the other features. This creates the
source.ruby.rspec scope.
- Added some code to make sure the function pop-up works correctly, as you can see in the little screenshot:
- Moved all the snippets into the
source.ruby.rspec scope so they don’t potentially interfere with other snippets/
- Added two new commands. Run All Specifications runs all the specifications in the current file. Run Focused Specification runs only the specification in your current focus, meaning the one your cursor is inside.
The commands return HTML, thanks to the spec command’s built-in formatting, but that formatting may be changing somewhat in the future to provide all sorts of new functionality. Stay tuned.
RSpec v1.2 : You can download the latest bundle from here.
No thoughts
I posted earlier today about BDD, and the RSpec library for Ruby. Since then, I’ve been writing a ton of code for behavioral descriptions1 in my favorite text editor TextMate, and I’m lazy. A few days ago, I saw a screencast of customizing TextMate, and seeing how easy it was, I decided to write an RSpec bundle. All you need to do is unzip it and double-click and TextMate will install it correctly.
RSpec bundle for TextMate v1.0.
Please send me any feedback you have.
1 I’m trying hard not to call them “tests”.
Updated: I’ve posted an improved version.
3 thoughts
Don’t get me wrong, Ruby on Rails has some amazing things in it, but there are some maddening areas as well. What has been annoying me today is the fact that there are implicit assumptions made about the permissions that the user you use in the database has.
It is not too terribly unusual to have several users for an application. For example, the application “foo” might have:
foo—a production role that has no permission to modify the schema, drop/create tables or modify the security itself in the systemfoo_admin—the role that often can modify the schema, roles, etc.foo_audit—a role which may be used specifically for audit purposes, having access to SELECT from an audit trail table, where the others can only INSERT
This kind of separation of duties and inclusion of the idea of least-permission, is critical to making a production application that has real security. Real security is not one layer at the very edge—the M&M model of security1. Instead, you layer multiple defense mechanisms across the application to make sure that should one layer fail, another is there to catch it.
I suspect that a lot of this is residual mental ideas that come from the approach to databases as “just a dumb hash table”. That’s interesting from a programmer perspective, but it’s not the least bit interesting from a real-world perspective. Perhaps some in the community might even consider this “enterprisey”, but it’s just good form.
So, what needs to be done? Well, it’s likely that there needs to be some level of separation of duties ensconced in the configuration and execution of tasks. For example, where now you have a “test” configuration in database.yml, it might be useful to also have a “test_superuser” configuration that is used only for database manipulation.
Now, you might say: “Well, why don’t you just grant the superuser permissions on your development/test environment and change it in production”. A good question. The answer is simple: if I’m doing things from a defense-in-depth perspective to protect data, then my test environment must be as close as possible to production. Otherwise, I’m likely to run into problems that I can’t test. This same issue applies to things like constraints and rules.
Does this invalidate the “Rails way”? Hardly, but it does emphasize that there are other approaches that are not so “pure”, and yet have more practical use in some areas. I’ve already started looking at what it would take to have this kind of separation of duties and not impact users who don’t want it.
1 This refers to the “hard crunchy outside” of the M&M.
1 thought
I’ve been using SketchUp for some time now, mostly playing with various architectural ideas that I’ve had. I’ve not done anything major in it, but I’ve certainly been impressed with the power that it represents in the hands of someone talented. Now, in looking at the latest release, I notice that it’s got a Ruby API built-in, and exposes most of the system so you can script it. Very cool.
1 thought
There has been a recent posting about how one can actually get away without using a Session in Rails and the performance benefits of doing so. There have also been some admonitions that sessions are a crutch to get around the nature of the web. Both of these are true, but inherently short-sighted.
Let me take the crutch argument first. While the web is inherently stateless, both by design and implementation, the humans that use it are not. We remember what we were just looking at, and we know that we expect a continual stream of experience that isn’t restarted each time we click on something. Please understand, that I am not referring to web services in this specific place. Machines are not humans.
Now, there are many ways around the idea of cookie-based sessions. I remember them from the mid-90s when the web was new and Mosaic ruled the roost. People would create huge Rube Goldberg contraptions to pretend that they had state on the client side, rather than the server. Hidden form fields and other nightmares permeated the network. Sessions are a functionally elegant solution to the nature of the underlying protocol. In many ways, HTTP is little more than a high-level UDP and we’re having to build other things on top of it to then build useful applications.
The other issue is that in order to get authentication right, you actually need to do more than just validate a token, or username out of the cookie. You need to do some work to prevent session hijacking. To do that, you have to keep some information about the IP and proxy information for the user that is logging in. Effectively, you have to keep a session, in my mind. While it might be possible to stuff all this information into the cookie as well, it puts the trust on the wrong end of the wire in my mind.
It seems to me that if performance with sessions in Rails drops so quickly, that perhaps it’s time to investigate where the problem is, and not just write it off completely. Also, the people mentioned in the postings haven’t said what kind of session store they are using.
4 thoughts
One of the things I adore about Common Lisp is the conditions and restart that allows for non-linear decision making to be interposed in a linear program flow. It allows the person who originated the real request to make decisions about how to recover from errors. This is amazingly powerful.
Now, Archit Baweja proposes a simple piece of code that gives you some of the semantics of the Lisp system. It’s nowhere near as powerful, but it is a demonstration of how truly new capabilities are possible in dynamic systems. Here’s a quick example from his code, with some more English in it, rather than the wacko line-noise shortcuts.
begin
do_stuff()
rescue MyException
$ERROR_INFO.restart.call(:ID1) if ( ... )
end
Very nice. Clean, and quite capable.
3 thoughts
One of the things I love about PostgreSQL is that you can actually use DDL inside transactions and if something goes wrong, it will unwind correctly. No other database that I know of allows for this. Using them in Rails migrations is a bit more complicated. Until I was reading some of the Rails source code, I only knew how to use them based on classes, but instead you can just wrap the whole thing up:
class CreateTest < ActiveRecord::Migration
def self.up
transaction do
create_table :test do |t|
t.column :name, :string, :limit => 80, :null => false
t.column :description, :string
end
end
end
def self.down
drop_table :test
end
end
No thoughts
As part of my work, I have to be able to validate and generate all sorts of potentially “valid” data for testing. One of the things I work a lot with is Social Security Numbers. Just for other people’s amusement, here’s a little bit of Ruby that grabs the latest high-mark list of issued numbers and parses it out:
ssn_list = Net::HTTP.get URI.parse('http://www.ssa.gov/employer/highgroup.txt')
@areas = []
while ssn_list =~ /(\d{3})\s(\d\d)\*?/
@areas < < [$1.to_i, $2.to_i]
ssn_list = $'
end
Then, you need to magically generate the wacky group numbers, that are not issued in order, so you’ll need to build the order they are issued:
@groups = []
1.step(9, 2) { |i| @groups < < i }
10.step(98, 2) { |i| @groups << i }
2.step(8, 2) { |i| @groups << i }
11.step(99, 2) { |i| @groups << i }
I need to just wrap up the whole generator/validator and publish it on RubyForge or something. They’re not hard to deal with, but it’s annoying.
No thoughts
I don’t think it’s completely fair to say that Ruby on Rails is wedded to MySQL, but I do think it is fair to say that often its approach to solving problems is influenced by the mindset that circulates around the MySQL database world. Foreign keys are one such case. For me, they are a necessary thing to maintain the very basic level of refferential integrity in a relational database. Without them, often, database can become lost or misplaced inside the database when things are moved around.
Having said that, there are definately some issues related to them, as well as the ease-of-development problems that come into play. Over in the caboo.se, atmos looks at the impact of constraints on testing and how Rails does test database management. This is something I’ve run into already, and I solved it the way I’ve always dealt with foreign keys in my development process: they are added last for production use. I actually use standard Ruby schema migrations to deal with the development process, and then at the end as the last step, I add the constraints onto the database layer.
This is definately sub-optimal in my mind, but right now, it’s the only way to handle it. I also have the issue that I’ve not patched up the schema dumper to move some PostgreSQL specific data-types (inet, etc) from development to test, so I have to double run rake migrate, once for development, and another time for test. Minor problem, but I’m about ready to just fix up the dumper so it works right—for me at least, and then release the changes in a plug-in.
Overall, though, I tend to enforce integrity both with the bits and pieces in Rails, but also in the database for the most patently obvious things. It might not deal with certain situations correctly, but it keeps me from shooting myself in the foot on more than a few occasions. Like security, integrity is a layered approach.
2 thoughts
At work, we use salesforce.com for all of our CRM work. Mostly, it’s used for sales-related doo-dads and gee-gawing, but we’ve been starting to use it for case management for customers. This led us smack-dab into the issue of containing the user in our support system, and providing a lot of things that salesforce.com isn’t designed to provide.
Then I stumbled over their AppExchange developer network, which includes their full API and access to all your data. They don’t keep it to themselves, and instead publish it out using SOAP. Not perfect, but workable, and usable. What’s even better, they’ve recently released ActiveSalesforce, which provides basically transparent integration with ActiveRecord in Rails.
You want to know how easy? This easy:
Contact.find_by_email "john@nowhere.com"
What’s even better?
Case.find_by_status("open").contact
Transparent, cross-table navigation across SOAP. Now that’s something slick. They don’t provide a pre-packaged set of ActiveRecord classes, but that’s easy to do. The definition of the one above is:
class Contact < ActiveRecord::Base
establish_connection "activesalesforce"
end
Ta’da. No more locking data away where you can’t get at it. There is one problem, documented on Rubyforge about using classes not named identically to their tables. They seem to do some magic in the wrong order inside, but that should be fixable soon.
No thoughts
The Model View Controller pattern is old. It dates back to the mid/late 1970s and the origins of Smalltalk. As a pattern for GUIs it works, but has all sorts of problems, however it works reasonably well for web-based applications. This, I think, is why DHH adopted it for RoR. But here’s the thing: the coupling is not evenly distributed between the layers, and scaffolding will lie to you something fierce—leading you down a path with good intentions and ending up in a morass of code.
Now, I’m not talking about situations where you’re using scaffolding to deal with trivial examples. I’m speaking of situations where you have complex applications—not just CRUD—that have to deal with the intertwined data in complex ways. If you’ve not come from the MVC world before, and don’t truly grok it before you start, you might think this is what it looks like:
One controller per model. I’m not saying this isn’t the case sometimes, but it might lead some people down the wrong path. Once you begin to undertake non-trivial Rails applications, you need to understand that your MVC architecture starts to look like this:
Note that while views and controllers are still bound together1 in what I call “near coupling,” the models are not. They’re totally separate. For me, this is critical to understand. Until you decouple the model and controller ideas more fully, you are stuck with odd little baroque creations that have all sorts of bleed-through. This is bad. It’s not how Rails, I think, was intended to be.
This means if you have an Account model, you don’t have to have an AccountController. You might have a MembershipController that talks to Accounts, Preferences, Subscriptions and half-a-dozen other things. Ta’da.
So, use scaffolding to “play” with the system. Use some of the tools to get you up and running quick, but understand their limits. You’ll need to replace lots of them. I often find it’s just easier to whip out the Controllers from scratch without any effort and let them deal with the Models that they need to serve the appropriate Views.
1 Personally, I’ve yet to find any love for Components, but that could certainly change in the future.
3 thoughts
One of the things I often need to do with a project is partition the data by some abstract method. Sometimes it’s based on the user who created it, sometimes some outside element, such as a sensor. Doing this traditionally has been a royal pain in the ass. Earlier I mentioned scoped_access and how it might work for doing general access control.
This is just a “rough thought,” but you should be able to extend the general security model (user, roles, rights) with a another pair of objects. What they’re called, I’m not sure yet, but let’s call them a “group” and a “partition”. That means you have something like this:
Tying all these together is a HASBTM relationship that everyone can figure out. So, what is a partition? Well, a partition is simply an extension of using scoped_access (or with_scope), with something silly like this going on:
Event.with_scope(:find => {
:conditions => "sensor_id = 12"}) do
...
end
It’s really that simple, I think. So how do you store them? well, I think realistically, store a single constraint per partition and then combine them at the group level. Storing multiple constraints in a single partition comes with all sorts of increased complexity in my mind that doesn’t really gain you much.
No thoughts
I am asking the Ruby community to please prove me wrong with facts as I really want to give monies to charity and need your help. While I value any additional perspectives that may emerge from this type of questioning, I do ask that you not “read into” my motivation for asking them…
Really. Well, I don’t see why I should have to do your fact-checking for you, nor do I see why I should have to educate you out of your ignorance. Ruby isn’t Fortune 200 focused. It’s focused on solving problems, and the two are diametrically opposed in my experience.
Enterprise Architecture? Bah. Code words for people who live in fantasy land that doesn’t actually have to solve a problem, but just come up with a reason why solving it is really, really hard work. None of this is hard. Quit pretending.
5 thoughts
I hate the title “architect” when it comes to technology, even though it’s in my “title” for work. Hate it because it conjurs images of people who have no clue how to do anything useful, and often spout their opinions from the wrong orafice. Take James McGovern’s latest screed and the dazzling display of ignorance on parade:
6. Ruby is going down a path of creating their own Virtual Machine. It seems to me, that they should simply put Ruby on the Java VM and not waste efforts in reinventing the wheel.
Yes because Java works so well for dynamic languages. That would be why it’s on Sun’s roadmap for the future. If they wanted to pick a VM, Squeak would be a much better fit given the similarities between Smalltalk and Ruby. If you want that attrocity, it’s available.
8. Ruby seems to be missing something that is otherwise fundamental in other languages which is support for Regular Expressions.
Holy crap on a stick. Anyone who typed “ruby regular expressions” into Google would find out this is nothing but an ill-informed lie of the deepest kind. Ruby has regular expressions as a standard type. In addition, there are nicer, more object-oriented approaches available. Did he even bother to do research with Google, or does he just make this stuff up as he goes along?
9. Does anyone agree that the notion of packages / namespaces should be a part of every modern language?
Yes, which is why Ruby has both. Perhaps it doesn’t use them in the lovely ‘com.sun.java.foo.bar.blah.i.am.tired.of.typing.periods’ way that Java does, but then, don’t we all love periods?
10. I also couldn’t find the equivalent of instance variables. Wouldn’t that make reuse at an enterprise-level somewhat problematic?
Did you really just say something that stupid? No really, did you? Is this a dadaist attempt at satire?
11. Shouldn’t the notion of methods being public, private and protected also be a part of every modern language?
Yes, which is why Ruby has it. I use it all the time, and Rails uses it to help control access to Controller methods via the web. Really, Google is this great creation, you should investigate it.
12. Let’s say that Ruby steps up to all of the things I listed above and does so in a rapid manner, wouldn’t that break all applications that used Rails? I believe the answer is that it would cause a trainwreck for any enterprise application that was built on top of it?
Amazingly, Matz stole Guido’s time machine and it was already finished.
13. Does anyone in the community acknowledge that software vendors and even many large enterprises don’t build on top of scripting languages because they don’t want their intellectual property so discoverable?
Does anyone in the Java world acknowledge that Java started with a dancing animation, and therefore the seriousness with which one can take it is asymptotically limited? Seriously, it’s not a scripting language. Bash is a scripting language.
Seriously, I hope this is just a parody gone awry, because if people actually pay this man for this tripe, the industy has sunk to lows hither-to unobtainable without speaking with Gartner. Hell, this guy makes Gartner look competent. Please tell me this is a joke that just got out of hand.
[more from Justin Gehtland]
Update: Mr. McGovern has changed his post, expunging some of his stupidity, leaving some others without any comment on his blog as to the nature of this change. Poor form, if you ask me, but there it is. I’m sure the caches somewhere have copies before the ignorance drips down the memory hole.
6 thoughts
This is inspired by a post by DHH last year, but recently un-earthed by myself. I’m good at that—finding things that everyone else already knows. The gist of the post is that generic solutions, like plugins, generators and such, are of decreasing value as the problem size gets bigger. For example, the tiny Textmate URL plugin is brilliant, as are some other things that extend the base model. Unfortunately, other bits and pieces that people have generously donated to the world are of less and less value as they try and solve bigger and bigger problems.
Let’s take for example role-based access control, or just a freaking login system. There are numerous options in Rails. I looked at all of them. They all suck in one way or another. Not because they don’t work—though that is true of some of them—but because they don’t work the way I need them to work for my situation. They also make all sorts of assumptions that are incompatible with my needs. What I have found useful is gazing at them, pulling out bits and pieces that are nice solutions to specific solutions.
Even more useful, though, is the idea of “recipes.” Take for example the Rails Recipes book that Chad Fowler is writing. Rather than try and give huge solutions to big problems, it solves lots of the little things that you need to piece together to make a system work. I took the login and authorization system in it, extended it, changed it, and made it fit my needs. Why? Because it was simple, clearly explained and I quickly understood how it could work for me.
Does this solution work for everyone? Nope. But sometimes what you need isn’t code, but a “recipe” for how to solve the problem—a roadmap.
1 thought
The Ruby on Rails work I’m doing is all being build against the SVN trunk, known as EdgeRails. Since I’m doing a lot of different things, I took a script from Renald Butler, which you can find here (from the wiki). My updated version changes a few things from the original:
- Builds everything in
/tmp, but won’t overwrite anything there. It cleans up after itself as well.
- If you call it with the word
edge at the end, it will tie you automatically to the SVN repository
- You need to check things out afterwards. I don’t like the idea of leaving it in place, but that’s mostly because my SVN repository is on another machine that I don’t use most of the time.
You can find the script here and it should work on most UNIX-based OSes.
1 thought