Ruby, Rails, Merb blog: Snakes, Gems & Coffee

LA Times Travel uses Twitter4R

2008-07-22T18:51:00.005-05:00

LA Times Travel is now using Twitter4R.

You can see they sent messages via the Twitter4R for a few hours today (2008-07-22) on their Twitter timeline before changing the Twitter4R configuration to not sure which library/application they are using (or just waiting to get Alex to approve their application source code).

Please let me know if you see Twitter4R sightings being used by other well known or cutting edge applications.

Serendipity: An original Pradipta's Rolodex member

2008-07-18T08:44:00.005-05:00

Last night I got the Pradipta's Rolodex message.

Rock on Pradipta!:)

Twitter4R Development Releases

2008-06-30T22:04:00.003-05:00

Over the last week or so I have been putting Twitter4R sources in GitHub and getting the on-the-fly GemSpec to work "safely" enough for GitHub servers. Tonight (June 30) I decided I would announce Twitter4R development micro-releases available only via the GitHub gem server. To setup your environment to install the latest development release of Twitter4R, please read HowTo: Install GitHub Development Releases

Official documentation will still exist through the official Rubyforge project site of Twitter4R, but any documentation related to current development tasks, features, bugfixes will now be documented on the Official Twitter4R GitHub Wiki.

If you want to keep an eye on the Git repository, feel free to watch the mbbx6spp/twitter4r GitHub repository.

Rails rocks, X sucks: How Provincial

2008-05-20T14:12:00.015-05:00

I seem to be coming across more and more [Steve] Jobs-clones or simply no-thinking Apple fan boys lately. I don't mind the Apple fans that thought themselves about why they love their stylish new Macbook Pro, I have just had enough of the no-thinking variety of Apple zealots.

This part of the Rails community appears to be a large population unfortunately. Because these fan boys are actually incapable of thinking on their own, they adopt other people's arguments and say things like: "Rails rules, X sucks because so-and-so said this...". Hmmmm. Need I say more?

On the other side I recently came across a Django fan boy who tried to convince his non-technical manager that Rails "cannot scale period". Hmmmm. How original. A blanket statement like this is not only misleading, it is actually in many ways technically incorrect. This is why in middle school we learned how to qualify our arguments. Why is it that supposed college graduates cannot do this in their 20s and 30s? It is one thing to strip out technical jargon for non-technical managers to understand a situation, but it is quite another to over simplify and mislead them because you have your own tech-religion agenda. Be passionate, but admit to yourself and others when passion is getting the better of you.

Why is acknowledging your chosen solution's weakness bad? Doesn't it actually make the solution implementation stronger if you have thought about scenario-based weaknesses?

How about we each try to *qualify* our positions on technology solutions out there, rather than figuratively urinate all over others without any basic respect for them. I encourage criticism, but criticize constructively. Say why. On the flip side, we should also accept constructive criticism too.

The first step to constructive criticism, need not necessarily be candy coating your critique, but having the right intentions behind your critique. For example, if your motivation for giving criticism is to start a flame war (sorry that is probably a very out of date term now), then you will probably get what you want. However, if you really want to help a project get better because you care, then that is the first step.

In addition, the way you word and tone statements (as Twitter's Alex Payne should have learned all too well by now) has a big impact. For example, Alex Payne's statements about Rails and Ruby cost me a contract at a former Rails shop that had a conniving PHP zealot waiting in the wings to jump on anything and take issue with Rails to upper management. Lucky for him, it worked and he had 3 to 4 months of leading a team to miserable failure using Drupal as a "platform". Not necessarily a reflection of PHP (or Drupal for CMS applications since it was far from a CMS application), but a reflection of this calculating pseudo-coder's inability to lead a project. A "technical" manager who thought the kernel version on his Fiesty Ubuntu laptop was 7.0.4. Enough said!:)

Overall, I hope we can start to have intelligent conversations about software stacks rather than "yours sucks ass". Because the latter in the end favors nobody.

PS Merb rulez and Rails suckz!:) If you want to know why read my teaser entry titled Why Merb is delicious, though I plan on writing more soon.

PPS Merb wouldn't be where it is today without Rails.

Why Merb is delicious

2008-05-06T08:49:00.010-05:00

Below are the reasons why Merb is more delicious than other MVC web frameworks I have worked with (including Rails):

On a diet...It is lighter weight than most, but still has enough oomph to implement common features with minimal code
Religion-free...It is ORM, JavaScript/AJAX and testing/speccing library agnostic.
The sum of it's parts...OK that was a lame segway, but parts is a mightily useful feature where a plugin is just total overkill. Just because Java calls something a "component" does not make it the general definition of a component in concept. And now look at the Rails plugin debacle today.
Precious gems...Plugins are created, distributed and installed in the form of beautiful RubyGems as opposed to the Rails plugin catastrophe with Gigabytes of duplicate disk space and lame version/revision control
It's exceptional...Merb actually thought about how to do exception handling in controllers before Rails came up with something and also came up with IMHO a better solution.
Speedy Gonzalez...Compared to especially Rails, Merb performs very nicely indeed.
Loose threads...Merb is thread-safe unlike Rails, so that means one process can handle multiple concurrent file uploads, where Rails cannot right now.

All together I think most people will find Merb to be a much better thought out (conceptually) MVC framework than Rails. Over the next few weeks I'll be talking a lot about Merb and it's delicious APIs, Plugins, etc. as it nears it's 1.0 release.

Comedy of Errors

2008-04-04T10:23:00.001-05:00

Does anyone else find it comical that the Chicago Java Users Group website is written in Rails? And apparently not very well if it is not only sending a HTTP 500 error, but still using the default Rails generated 500.html page. Poor all around.

An IM buddy mentioned it might be JRuby, but I do think it is still very ironic considering the hostility from the Java world regarding Rails in general (whether Ruby on Rails or JRuby on Rails).

I just had to share!:)

Update: Someone fixed it shortly after I reported it to CJUG.

Update: Actually it was only temporarily fixed, it is back to the default 500 Rails error page.

Update: In addition they have exposed their SVN information. See the public entries and from that information you can find their non-password protected source code and check it out if you like.

If anyone from CJUG is reading, you can fix this by reading my blog entry from two months back called Preventing Information Leaks, Part 3. Although it might be useful to read part 1 and part 2 as well. Cheers!

PS I also sent an email to info at cjug.org and received an email delivery error.

Update: I may have read too much into the SVN repository information exposure in this specific case since this is an open source Rails application project (I only just realized), thus the non-password protected repository, but I still stand by the rest!:) It is also not good practice to expose such information from the outset of deploying an web application.

Update (1.5 hours after trying to notify JUG and posting the blog post): The site has been fixed now for over 5 minutes, so good job fixing it CJUG!:)

Update (8 minutes later): Ooooops! It is back to the default Rails 500 error page. Perhaps it is 2 out of three bad FastCGI processes that need to be killed on the server? HTH someone at CJUG, but since I can't look at the system I can't say for sure.

Coding with Explicit Intentions

2008-04-01T10:34:00.007-05:00

Recently I have had the [mis]fortune to be working with PHP for integration purposes for a client. A partner of my client's (in the advertising space) sent us some PHP code to add to our servers for resolving the content type of a file based on its extension. The line of code in the PHP script they sent over that was supposed to determine the file extension was:

  $ext = substr($file,-4);

As you can see they are making a pretty big assumption - that the extension is exactly three letters long. The media files that this script *may* support in the future are: Real Media (.rm), MPEG (.mpeg), Quicktime (.qt), etc. These extensions are not exactly three letters long. Why would someone want to write code that is quite likely to fail and also not communicate more explicitly their intentions?

This partner already doesn't support PHP < 4.0.3, so why not substitute the line above with:

  $ext = ".".pathinfo($file, PATHINFO_EXTENSION);

It is standard, will never fail (unless there is a defect in the PHP version you are using for the standard function pathinfo, but what can you do about that?) and communicates the explicit intent of the original author, thus improving code maintainability.

Anyway, just a pet peeve. This is not by any means the only example I see on a day in day out basis, this just happened to be a great example for me to demonstrate my point. While this example demonstrates a minor one-line demonstration, if developers introduce even only 2-3 of these un-explicit intentioned lines of code a day that do not always do what you might want it to do, then the codebase quickly becomes a mine field.

Waking Up From Hibernation

2008-03-30T21:49:00.003-05:00

Just a quick post to say that I will be waking up from OSS and blog hibernation at the beginning of May. I have a stack of bug fixes to apply to Twitter4R for a pretty large 0.3.1 release (in terms of bug fixes and supporting Rails 2.x compatibility). The next two major features on my Twitter4R v0.4.0 release radar are: (a) supporting Ruby 1.9 and (b) adding the newish "track" feature in some capacity (probably via XMPP instead of the REST API on Twitter.com).

I also have a couple of minor features to add to the metafusion-crypto gem and finally release the first version of metafusion-rails. Then I will probably abandon OSS work explicit to Rails and write numerous Merb plugins/extensions.

The catch up work will likely take 2-3 weeks into May and then hopefully my new venture workload will be significantly smaller to sustain OSS development over the summer months.

Thanks for all your patience!

Preventing Information Leaks, Part 3

2008-02-12T10:44:00.000-06:00

In the third part of the how to prevent information leaks blog post series, we will look for unguarded "hidden" files where we can garnish quite a bit of information.

Make sure you check out part 1 and part 2 on how to prevent information leaks in web applications before continuing.

Seek Unguarded Hidden Files

For web applications that use deployment tools that pull code from code repositories, you can find out quite a bit of information about the code repository (e.g. host, path, usernames, file listings), by finding unguarded hidden files. One obvious example especially in the SVN saturated Rails world is the path /.svn/entries and similar URLs.

You will want to make sure the following URIs are not accessible on your public sites if you use Subversion (SVN):

/.svn/entries
/javascripts/.svn/entries
/stylesheets/.svn/entries
/images/.svn/entries

If you are using a superior SCM for your project like Git you ought to be looking for the following:

/.git/config
/javascripts/.git/config
/stylesheets/.git/config
/images/.git/config

If your project is still in the stone-age using CVS, then check the following:

/CVS/Entries
/javascripts/CVS/Entries
/stylesheets/CVS/Entries
/images/CVS/Entries

Adapt these patterns for your application framework default structures. The above is for Rails or Rails-based frameworks (e.g. Merb).

When I first tried this last week on the Rails top 10 sites, three out of ten of these sites exposed their SVN information (and last week I had only checked SVN, no Git or CVS URIs). Since last week at least one of those sites have fixed the problem!

What information is exposed in these files? Quite a lot of information. Do you want potential hackers knowing:

usernames of committers
code repository listings of files in a directory

All these things are not things you really want the potential hacker knowing. On my travels investigating the top 100 Rails sites I found one top 20 site that exposed enough information from their SVN entries file that I found a prototyping directory that included a "specs.rtf" document, which I was able to download. The document was not very uninteresting (at least not to me), but if they had written more in-depth specifications in the document, it may have served as a nice guide for a potential hacker to garnish enough information about their setup to take over!

Moral of this story? Guard hidden files. I recommend "forbidding" access to all troublesome path regex patterns.

For example, one of the LigHTTPd servers I administer has the following at the top of the configuration file:


$HTTP["url"] =~ ".*/\..*" {
  url.access-deny = ("")
}

For Apache httpd servers I use something like the following in the httpd.conf:


<DirectoryMatch "^.*\..*">
  ErrorDocument 403 /403.html
  Order allow,deny
  Deny from all
  Satisfy All
</DirectoryMatch>

Nginx configuration might look something like:


location ^~ /\..* {
  deny    all;
}

This guards against URLs like: /.svn/entries, .git/config as well as .htpasswd, etc. This means that only some script-kiddie hackers will mistakenly think you are using one SCM system instead of another, but they will never be able to know for sure which SCM you use or any information about your code repository.

Forbidding access to all paths containing "/." somewhere in the URL is generally a good idea (IMHO) as sometimes people change web servers and leave "secret" files in the directory structure, but the new server doesn't know that, for example, .htaccess or .htpasswd is "special", so it will just serve it without thinking.

Preventing Information Leaks, Part 2

2008-02-11T13:04:00.000-06:00

Continuing the series that looks at how to prevent information leakage, today we look at the information leakage from web server HTTP headers.

HTTP Header Leakage

Let's look at the information potential hackers can get from HTTP headers from just a GET / HTTP request. Let us look at http://www.cnn.com:

$ curl -I http://www.cnn.com
HTTP/1.1 200 OK
Date: Thu, 07 Feb 2008 15:22:32 GMT
Server: Apache
Accept-Ranges: bytes
Cache-Control: max-age=60, private
Expires: Thu, 07 Feb 2008 15:23:23 GMT
Vary: Accept-Encoding,User-Agent
Content-Type: text/html
X-Pad: avoid browser bug
Content-Length: 90458

This example is pretty decent. What you want to look for is the Server HTTP header value. In this case it is just "Apache". Now it does identify the web server used, but it doesn't pinpoint the version being used. Now I am going to try a popular Rails website:


HTTP/1.1 200 OK
Date: Thu, 07 Feb 2008 15:25:34 GMT
Server: Apache/2.2.2 (FreeBSD) mod_ssl/2.2.2 OpenSSL/0.9.8b DAV/2 PHP/5.1.4 SVN/1.3.2 mod_vd/2.0 mod_fastcgi/2.4.2 proxy_html/2.5
Last-Modified: Thu, 07 Feb 2008 14:58:58 GMT
ETag: "4da437-36ac-b69b1080"
Accept-Ranges: bytes
Content-Length: 13996
Vary: Accept-Encoding
Content-Type: text/html

In this case we can see what OS Apache is running on and the version of Apache. Not only this, but we see all the enabled modules in Apache and their respective versions. IMHO this is too much information especially considering this site supposedly (at least as far as I know) host the site on a fully controlled environment (either dedicated or VPS with root access). Applications on shared hosts cannot help this much without assistance from the shared hosting company. I have a couple of very small sites that get little traffic on a shared host, so I appreciate this obstacle.

Moral of this story: If you have full control over your environment you should always either change the "Server" HTTP header to something generic (e.g. "Apache" as in the CNN example) or disable it from being returned to the client. This setting is very easy in Apache, LigHTTPd and NGinx. I assume this wouldn't be difficult in LiteSpeed either, but I do not have configuration experience with LiteSpeed.

Apache configuration:

Header unset Server

LigHTTPd configuration:

server.tag = ""

NGiNX configuration:

server_tokens off;

Also make sure there aren't any other headers that give away too much information. Especially look at the X- HTTP headers.

DataMapper vs. ActiveRecord

2008-02-09T12:17:00.000-06:00

Today I came across a thread on ruby-talk where I responded to the age old question of which Ruby ORM (specifically DM vs. AR).

I responded based on my production use of AR, development use of DM and my understanding of Fowler's PoEA of the same names that I have applied in Java and Python countless times.

As some readers of this blog might find this discussion interesting, I am linking to my response to the DataMapper vs. ActiveRecord discussion here.

The executive summary (for the infinitely lazy) is:

It appears that if DataMapper (the Ruby library) is able to sufficiently hide enough database logic in more complex business logic scenarios, then the DM library might be more beneficial to use when using a legacy database schema where you are not able to create primarily isomorphic relationships between class attributes and table columns. Whereas AR would be a slam dunk and simpler to use in isomorphic schema scenarios where you have control over the database schema.

I will be returning to the Preventing Information Leaks series on Monday/Tuesday (it is already written, I just need to publish).

Preventing Information Leaks, Part 1

2008-02-07T10:04:00.001-06:00

Before I start I want to mention that the techniques suggested in this blog post are for readers to use to secure their own web applications.

This does not mean that you can take over the server with these techniques without further hacking, but these steps provide a lot of information about the environment the web application is deployed to or developed using, unless system administrators/engineers or software engineers prevent this information leakage.

Some of these techniques exploit settings that are usually found in Rails when default settings are used, but web applications written in different frameworks may also use these settings, which leak information.

This all just comes down to thinking through the security scenarios. Just like developers need to consider the usage of their applications or APIs or frameworks from the user perspective, those tasked with securing up their applications need to consider how potential hackers might try to access key information to help them hack your systems.

Identifying the framework or "stack"

Let us check if your application smells too much like you are using a particular framework or another. This may or may not be terrible, BUT if you can tell which version of the framework you are using from publicly accessible information on your site, then you are leaking too much information. In fact, some firms/developers advertise very publicly which frameworks or stacks they use, but they usually try not to talk too much about the exact versions they use.

For example, if an application responds with a 200 OK HTTP status for the majority of the following URLs, it is VERY likely it is a Rails application:

/javascripts/application.js
/404.html
/500.html
/422.html

In the case of the last URL, we can identify that the application is written using Rails 2.0. We can also look at the 404 to see if it looks like the default looking 404 file for different versions of Rails. If /422.html doesn't exist we might still be able to tell the difference between Rails 1.1 and 1.2 applications by what /404.html looks like.

Moral of this story: At a minimum always change the default error pages in your Rails application to fit your design. Also consider changing the URLs of the error pages too. Not only does the redesign prevent potential hackers from identifying which version of Rails you might be using it also looks more professional and makes the user experience in case of an error a little more acceptable!
If you are not using Rails, think about what files are created by default by your framework and change things around a little to prevent information leakage.

I will continue this series in subsequent parts. Stay tuned!

Stupid Easy: 7 Deadly [Rails] Sins, Part 3

2008-01-31T09:23:00.000-06:00

This is the third and final part in the Stupid Easy: 7 Deadly [Rails] Sins series. See part 1 and part 2 if you haven't already.

I have left the most heinous sin to the end. If you are a serious sinner in this aspect, there is little hope for you unless you take steps now to rectify your behavior in this aspect.

Stupid Easy Ruby

When in Rome, do as the Romans do

That's right. This is the sin of not knowing how to really code in Ruby. Sure some coders that move to Ruby can write code that does what they want it to do, but often at the severe expense of compromising project code maintainability (e.g. making things very unDRY, etc.) or even introducing significant performance issues by not understanding basics about the Ruby language.

Instead I see people using Java, Perl, PHP, C# or even Python idioms in Ruby instead of understanding the essence of the language of Ruby, which is distinct from each of these languages in different ways.

The same is true for any language/environment you work within. I know former PHP people that moved to Java and do not have the first clue about basic Java idioms that work well. This isn't just to pick on PHP heads as I imagine this occurs from any language migration path. I have simply seen this sin committed most by former PHP coders moving toward Java, Ruby and Python. However, I will say I see a LOT of former Java (massive static language proponents - Joshua Bloch you are a nonobjective snob) developers that do not understand or appreciate the non-static design mentality and they create large class hierarchies and don't understand what a Mixin is (or they pretend to be "cool" and talk alot of about these idioms, but don't really utilize them in the right way themselves). The Ruby mindset is still different from it's more similar looking cousins: Python and Perl, but moving between Python, Perl and Ruby (in any direction) feels more intuitive (at least in my mind).

Now I should stress that I can no longer code in Java without pulling my hair out because the thought of creating 5 interfaces and a factory for every three class implementations drives me temporarily insane. The SPI design principle allows Java to be fairly flexible (especially for a statically typed language), but at the expense of my personal sanity now that I prefer to think the non-static way (yes, I still appreciate Python's strongly-typed ways). This is why I prefer to use JRuby, Jython or Groovy scripting in Java environments.

There is no magic bullet to stop sinning in this regard if you aren't willing to take a journey to learn and understand Ruby idioms (not just basic *knowledge*). There are no shortcuts, it simply depends on how easily your brain can shift in gears. This doesn't mean people who can't shift gears are "bad" developers, but not well suited to migrating to significantly different environments very often.

Just remember the rules in Ruby aren't the same. Think in terms of sending messages to objects that may or may not respond to the message you send, instead of expected interfaces and you are half way there if you are coming from Java, C++ and similar languages. Think of Java as a big government structure with a complicated tax code and Ruby as minimal government with a simplified tax code without loopholes accessible only to the rich! That means in the Ruby world wild things such as adult services can legally be procured between consenting adults, so bend your brain to think that way when working in Ruby...almost anything is possible especially in the realm of metaprogramming that is not possible in the Java world.

That government is best which governs least.
--Thomas Paine

I personally happen to agree with Thomas Paine's statement (at least in the context of programming), but there are various programming philosophies that different languages cater for, so it comes down to your own preference. Pick the ones you can live with at the time and think in terms of and you will be happier for it.

Obviously in a programming context some people (e.g. Joshua Bloch, who is still a static language snob) will oppose legal procurement of "adult services". They have a moral objection to these activities and thus do not appreciate the beauty of dynamic design. If you have such moral reservations in programming, do everyone a favor and stay in the Java world or at least static languages! This is the beauty of different opinions. Nobody is right in absolute terms, but you need to make the right choice for yourself. It is the zealots who only accept "absolute correctness" that we should be weary of (on any side of the argument, but including Joshua Bloch).

My general philosophy when I had the Java Way ingrained in my brain was that as an API designer I had to protect stupid developers from their own stupidity. Now my philosophy in the Ruby world is that I write APIs for smart developers and if you aren't [Ruby] smart, use at your own risk. Of course, I oppose complication for the sake of appearing to be "smart". But I try to write APIs that allow more advanced Ruby developers to take advantage of language features such as blocks, metaprogramming, etc. as opposed to providing an over-simplified, dumbed-down API that ends up looking ugly to the wiser Ruby developer due to being less DRY than might be possible without restriction.

Ruby Language Pointers

If you haven't acquainted yourself with the pickaxe book you should pay special attention to the following sections: Blocks, Mixins, Inspecting Objects, Inheritance & Messages, Inheritance & Mixins, Classes & Objects Interacting, The Ruby Language.

Then I would look at the source code of the ActiveSupport open source project (part of Rails) for techniques that are very useful. Some of these techniques I have discussed in previous blog posts: Ruby Idiom: Reopening Classes, Ruby Idiom: forwardables, Ruby Idiom: Inject-ing Understanding, Ruby Equality, Ruby Higher Order Messaging.

Stupid Easy: 7 Deadly [Rails] Sins, Part 2

2008-01-22T09:43:00.000-06:00

In the second part of Stupid Easy: 7 Deadly [Rails] Sins, we look at sins four through six and save the most heinous sin for last in the third part of this series.

4. Stupid Easy Views

Everyone has seen spaghetti view code, either in the JSP, PHP, or other similar web templating environments. So why do people honestly think (ok, only the no-thinkers) that when they use Rails that you can't violate MVC because it is built around the MVC "pattern". Don't even get me started on the whole "pattern" thing...

If you see a piece of view code like the following, then you are violating MVC. Yes, even when using Rails:


<% 
if current_user && current_user.admin?
  @somevar = something goes here
  # and do something else here
else
  @somevar = something else goes here
end
%>

This is a small (but very stupid) violation, but a violation none-the-less. I have seen not just logic in view code, but oddly model-specific code (in one case I even saw some attributes of a model being updated at the END of the view template - go figure). Now simply checking the admin flag of the current_user to insert some view specific code, would not be violating MVC.

There are various ways of making sure you don't make this mistake. Some people think using a specialized templating language in place of eRB is the way to go (one of the many potential replacements that I happen to know about is Haml). These specialized template languages basically make it virtually impossible to embed any kind of logic into the view code. Others (pro-thinkers, rather than no-thinkers) don't believe that level of enforcement is necessary and just make a point of highlighting to the team (and then quickly refactoring) any violations in view code to educate all the team members about this sin.

I have even seen some Rake tasks written (ok, I may have written a couple) that flag any views that have specific keywords within the <% %> eRB brackets as potential violators so that we can look through the suspects and make judgments before a release is made (because you never want to release code that violate basic principles you believe in). Another strategy is to only work with developers that you share a very similar development philosophy and know they wouldn't violate this basic rule of thumb in the first place.

In any case, you need to incorporate one of these strategies so you can be sure to be rid of the Stupid Easy View faux pas in Rails projects.

5. Stupid Easy Configuration (and Routes)

In Rails 2.0 there is absolutely ZERO excuse for this (with very nice initializer hooks available), but even pre-2.0 it is hard to justify an config/environment.rb consisting of more than 30 lines (including basic Rails configuration minus comments).

Separation of configuration into separate files that are required by config/environment.rb were my personal preference in pre-2.0.

On the config/routes.rb side, I would often see the default routes still uncommented. In Rails post-1.2 there is really no excuse since almost everyone should be using RESTful routes with RESTful controllers (even if the way Rails generates a ridiculous amount of code, when it could be refactored nicely into a mixin or base class, is pretty dumb) anyway. In fact, default routes are almost always an invitation for troublemakers to hack into your site (especially if they know it is a Rails site). I can't say I have never deployed a Rails 1.2.x site with default routes uncommented, but I certainly haven't in the last year since Rails 1.2's official release.

6. Stupid Easy Library Code

For some reason numerous popular Rails plugins promote the idea of putting generated files into your RAILS_ROOT/lib directory (e.g. acts_as_authentication, restful_authentication, etc.). Instead of being a real plugin they are basically just Rails generators. Now we could debate how generators could be better supported in Rails, but that is really a tangent to the point. Don't be fooled by these popular "plugins" (remember they are really only generators).

If you have significant code in your RAILS_ROOT/lib that has the same focus (e.g. authentication, authorization, credit card processing, etc.), then you really ought to create your own plugin (even if it isn't going to be shared with other projects in the foreseeable future). How you and/or your team defines "significant" is a judgment call, but I personally think any unit of code that works together that is greater than 200 lines of elegant Ruby code is significant (minus empty lines and comments of course). It isn't necessarily a hard or fast rule, but a general rule of thumb, which may have exceptions.

The main purpose of this is twofold from my perspective. When you have a lot of code in your RAILS_ROOT/lib it is a harder to be more disciplined about organization. Whereas with a plugin you know where plugin initialization code goes vs. mixin or other code. Another big benefit (which is related to code organization) is testing/specing. It is much easier to see (or specifically notice) test/spec-coverage shortcomings of plugins than holes in your tests/specs for RAILS_ROOT/lib code.

Benefits of creating plugins include that it is forces you (the developer) to think more about:

Testing/specing your code
code organization from a maintainability perspective
what chunks of code go together (should this be one or two plugins)
the scope of your plugin vs. what needs to be defined or written in your application code
who is responsible for developing this functionality, maybe it is the infrastructure/core/framework development team who needs to be responsible for authentication or authorization code rather than application developers. With plugins you can separate our these responsibilities very easily

In addition, a plugin is much more easily shareable across projects (in a more organized and disciplined way than just copying or even linking files/directories into your RAILS_ROOT/lib directory).

Of course, I also find the way Rails plugins are supported by Rails a hindrance, especially when RubyGems could provide a many facilities to support this in a more elegant way, but that is a topic for another day!:)

There is only one Stupid Easy Deadly [Rails] Sin left, which I will publish in the next two weeks.

Stupid Easy: 7 Deadly [Rails] Sins, Part 1

2008-01-12T10:46:00.000-06:00

Everyone has been talking about Rails for a few of years now as the framework that makes it "stupid easy" to create web applications. The problem I have with this mentality is it creates a "stupid easy" sub-culture within the Rails community that promotes stupid laziness (as opposed to smart laziness).

Over the last 3 Rails contracts, I have worked with supposedly experienced developers that have switched to Rails from OO languages like Java and C++ (as opposed to pretend OO languages like PHP). The results have been VERY disappointing.

The biggest problem I see is that some, even quite experienced developers, have the [stupid] lazy mentality burned into their brains. They want to visit blogs and copy and paste code into their applications without thinking about it. In fact, recently I found a ridiculous real world example of such madness. No thought put into the pasted code AT ALL. I could identify the blog posting on a popular Rails blog that had the EXACT same code. The variables weren't EVEN renamed to be meaningful in the current application. Instead a finance web application had references to customers and invoices in the controller and view code when there were no such entities/models involved in the application. Not only is this a maintenance nightmare, it show how little thought went into the code just to get a small AJAX effect that (a) wasn't difficult to write from scratch (4 lines in total after refactoring from the 11 lines of code used) and (b) was probably not even that necessary from the user experience perspective.

These are the developers I think ought to return to their no-thinking PHP or Java/JEE recipe books and leave the Ruby world alone. Of course, the authors of "recipe" books should also bare some of the blame for encouraging the no-thinking hackers out there to join the Ruby world in the first place. Is that really the type of mindset we wish to harbor in our community?

Look at the PHP and Java universes today for a reference point of where we will end up very soon if we are not careful.

1. Stupid Easy Schemas

One of the deadly sins I saw on my travels through their code was extending the "stupid easy" mentality in the form of not defining schema properly. Sure they *used* Rails' migrations, but they didn't really create a usable schema based on the use stories and cross-story functional requirements.

While you might not want to use database specific features like triggers, stored procedures, or even foreign keys (the latter assumes you are using Rails-based equivalents in place of FKs), you should still make your schema sensible.

For example,


# Migration code
  create_table :countries do |t|
    t.column :code, :string
    t.column :name, :string
  end

# Model code
class Country < ActiveRecord::Base
end

In this example we created a table called countries that has two string fields: code, name. In this case the code is the ISO country code that the application is going to use for almost all country lookups in the database. We knew that pretty much from the beginning because of the nature of our application. (Note: this example is a little contrived as I had to change things so as not to expose too much about the application this is from).

Not only do we know that the Country model will almost always be looked up by its code (from the initial set of use(r) cases/stories we need to implement). The ISO code is also always 3 characters long. We also know that these ISO codes are unique for each country. All these things we knew before we needed to create the schema. This is the important information that is missing from the schema and the model is missing relevant validation.

Before committing this new model and migration for Country the developer writing the code (one of the developers I am thinking of loves to tout how XP/agile and great his code is), should have had the following code on initial checkin (there really is no excuse IMHO):


# migration code
  create_table :countries do |t|
    t.column :code, :string, :limit => 3
    t.column :name, :string # You may even decide to cap the length of the name field too, but this is more of a DBA style thing.
  end
  add_index :countries, :code, :unique => true

# Model code
class Country < ActiveRecord::Base
  validates_length_of :code, :is => 3
  validates_uniqueness_of :code
end

While on my soapbox about this point, another developer I respect said this might be premature optimization. In this specific case, I totally disagree, however, this is a good point to make in general. You don't want to do premature optimization either. This is something we all need to be careful about and to be aware.

This is the point where you need to think for yourself. There is no cheat sheet on these types of thinking points. The [stupid] lazy Rails developers should go back to hacking PHP senselessly or following J2EE/JEE blueprint patterns if they find thinking for themselves to develop their own rules of thumb too much work. Remember [smart] lazy is the way to go.

2. Stupid Easy Models

Another cardinal sin I often see in both client work I have inherited from others or open source projects is dumbing down models. Instead of creating member methods of models that related to *what* they are and do, some Rails coders (usually not very experienced) write this functionality within the controller layer, which leads to drastic controller layer bloat. Which is really ugly. Remember if your code is starting to look ugly, do something about it. The way to fix this is *almost* always to create relevant member methods on the corresponding models that this functionality works on.

One easy example of this might be to add an authenticate method to the User model instead of having extra logic in the ApplicationController. Think CRC instead of procedural.

3. Stupid Easy Controller Methods

This is perhaps the most obviously harmful (from a security perspective) sin. While traveling through the Supid Easy Rails universe of code, I almost always see unprotected controller methods that are used as filters or for utility purposes in some capacity. This is a sin that I myself must confess to, though I haven't done so since the first 3 months of my Rails development around 2005 Q4.

The following is typically what I see around:


# in SparksController
  def check_permissions
    return false unless current_user.has_permission?(:MANAGE_USERS)
    true
  end

The problem with this is that we can do the following (unless using resource routes where default routes are taken out):

GET /sparks/check_permissions?some_var=some_value

And perhaps hack into the web application. In this case we may not be able to do anything too interesting, but there are other scenarios that this could create a very open hole in the web application.

The way to fix this and keep your team's sanity from a maintenance perspective is to protect these filter or utility methods by scoping appropriate with protected or private, which is not difficult at all. However, if you are a true Rubyist you will probably opt to keep your controller utility methods in Acts::As mixins or similar.

'Twas the night before launch...

2008-01-04T19:10:00.000-06:00

Oh fun times! On such fateful nights you know you will find something that will screw things up unless immediately addressed. It must be someone's law already, but if it isn't I call dibs on it and it should thus be called "Potter's Law":).

On a night before launch that I recently experienced, I had a heart stopping moment. The last 5 days of the sprint I had been churning out last minute changes based on usability feedback from the client. In the process, I had neglected to include benchmarking and memory leak testing with the same discipline I prefer. On the night before launch I ran my usual benchmarking scripts. The results were pretty good except on one action. We could have lived with that performance, but the real problem came when I ran tests to detect memory leaks in my Rails application. Let the real fun begin!

Before continuing, I should mention there is only thing I hate more than uber visual tasks (editing/creating graphics, layout tweaking, etc.) and that is debugging memory leaks.

I ran the ab (Apache Bench) utility on a few different types of pages in the staging environment and didn't notice any problems. The Rails application was consistently teetering under 50M RAM. Excellent! Then I tried the second most requested type of page (this was a static site we were rewriting in Rails to create an easy to use domain-specific CMS - so we had live production web statistics) and my heart skipped a beat or three.

Memory usage spiraled out of control. From 49.5M the single mongrel process eventually grew to 250M after a few ab -c2 -n100 .... runs.

I first checked out the view since I knew the controller action code was only 6 lines (how much could go wrong there?).

I tried removing different parts of the view code and rerunning my tests while monitoring the memory usage of the process. Still no change.

So I reluctantly looked in the controller and saw something like the following:


  def show
    @eto = ExchangeTradedOption.find_active(params[:id])

    respond_to do |format|
      format.html # show.rhtml
      format.xml  { render :action => "xml", :layout => false }
      format.csv  { render :action => "csv", :layout => false }
    end
  end

What on earth was in the ExchangeTradedOption.find_active method?


  class << self
    def find_active(id)
      now = Time.now
      find(
        id,
        :include => [:exchange, {:vendor_symbols => [:vendor]}],
        :conditions => [
          %{options.expires_at <= ? AND options.active = 1 AND 
            vendor_symbols.effective_date <= ? AND vendor_symbols.expiration_date >= ?}, 
          now, now, now
        ],
        :order => 'vendor_symbols.effective_date DESC'
      )
    end
  end

Ouch! The problem was that I still needed all vendor symbols and vendors for the view in question and didn't want to make the extra SQL queries for the Vendor on each VendorSymbol as that would have added between 5-10 extra SQL queries per action invocation.

I guessed the nested includes in the find was most likely to be causing the issue. So I refactored as followed:


# Controller action code: ExchangeTradedOptionsController#show
  def show
    @eto = ExchangeTradedOption.find_active(params[:id])
    @vendor_symbols = VendorSymbol.find_active_for(params[:id])

    respond_to do |format|
      format.html # show.rhtml
      format.xml  { render :action => "xml", :layout => false }
      format.csv  { render :action => "csv", :layout => false }
    end
  end

# Model finder code: ExchangeTradedOption.find_active
  class << self
    def find_active(id)
      now = Time.now
      find(
        id,
        :include => [:exchange],
        :conditions => [%{options.expires_at <= ? AND options.active = 1}, now],
      )
    end
  end

# The VendorSymbol.find_active_for method implementation is left as an exercise for the reader
# but it is very, very simple!

# Changed view to refer to @vendor_symbols array instead of @eto.vendor_symbols
# This also helped reduce indirection and prevented Law of Demeter violations in the view code!

Of course, I didn't leave it without verifying! Never just guess that the problem is solved, you should always verify this with tests (either automated or manual).

There were a few solutions, of course. One is the one I provided above. The second solution I thought of trying was removing the vendor_symbols SQL conditions and sorting in Ruby. This seemed a waste of CPU to me and extra lines of code I felt was unnecessary (remember the less code you write the less you need to maintain!). The third solution was to execute an optimized raw SQL query myself. I also didn't like this option as the first one presented about seemed cleaner and more maintainable going forward. The first solution does cause more than one SQL query to be executed each time the action is run, but it is scalable as it remains constant at two queries per invocation. In addition I added one extra instance variable, which is also not ideal, but again this didn't seem to me to be the worst problem at this stage with only two instance variables in the action being set for the view.

The benchmarking results proved my assumptions correct regarding the various solutions.

The moral of the story is find the best solution based on the context rather than attempting to apply a one-query-per-action-invocation rule to the whole application, which might be ideal, but occasionally unrealistic and/or catastrophic.

2008 Predictions

2007-12-30T14:59:00.000-06:00

Since the end of the year is almost upon us close associates of mine have been asking my predictions for the new year. While obliging them here I suspect in 12 months time I will review this blog posting in (most likely) absolute humiliation and horror as most that make predictions do.

Web 2.0 will die in 2008 and Web 3.0 will reach adolescence in comical fashion, but will not receive the same private equity interest of its predecessor.

Carbonless Datacenter will be the IT buzz phrase for a good part of 2008.

SaaS will morph into yet another acronym (hopefully one that makes more sense in terms of capitalization) that will take into account yet another business model twist.

DHH will continue to be perceived by many inside and outside the Ruby/Rails world as an arrogant a$$.

Lastly, I predict that Tony Blair will concede and sincerely apologize for his disastrous 2002 prediction that Weapons of Mass Destruction (WMD) exist in Iraq that has already caused a much higher death toll (that continues to mount) orders of magnitude higher than the unmistakable military fiasco of the Charge of the Light Brigade. Sorry I forgot Mr Blair doesn't have a sincere atom in his body and this is only a tech prediction list.

Don't outsource your thinking process. Think for yourself!

2007-12-06T22:54:00.000-06:00

In the wirlwind of political turmoil and occasional nuance of late with the upcoming primary elections almost upon us, I realized just how offensive the two-party primary elections ought to be to a "free" country. Why isn't everyone else as outraged as I am?

Traversing various circles I see Democrats hashing out their own political differences on foreign policy, social security and the overloaded and antiquated driver's license system to create a unified platform for the general election. As if *ALL* Democrats think the exact same way. Republicans on the other hand are dumb-founded and depressed by the lack of quality mainstream and viable candidate(s), not to mention trying to figure out what on earth their united platform is after a president that has probably done more to harm their party than any other individual in the last 25 years (hey, don't look at me or the Democrats, neither of us voted for him in the first place!:)). Oh, I do enjoy being smug!

Being a foreigner I always found it odd that Americans (generally) seem more willing to outsource their political reasoning to one of two political parties (at least in contrast with my European experiences). I have witnessed the deferral of political reasoning to their parties without thinking on so many occasions I have lost count. If their *party* is anti-war, then they need to be too, no questions asked. Alternatively if they are with the *other party* they need to buy into the whole Cheney-masterminded war on terror doctrine, where we must "take the war to the enemy", whatever that means.

Now back to the technical world (and this transcends borders). I see the same type of decision/reasoning outsourcing. In 1997, Apple coined the slogan "Think Different". Fast forward 10 years and you have an ever growing Apple fan base that doesn't question (at least not Apple or Jobs), it just doesn't "think". I am not saying Apple hasn't done anything good, but all you Apple fan boys (and girls) just think for yourselves once in a while, puh-lease!

To be fair and candid, it is not limited to the Apple fan base. The Linux community (of which I am party) has been a huge propaganda machine for just as long. A friend of mine who is primarily a Windoze user (sorry, I just couldn't resist) suggests that the Linux community has been pushing Linux (or at least certain distributions of it) as "just as usable out of the box as Windows", which he thinks is a sad and pathetic misrepresentation. To be honest, I agree with him. I don't think any Linux distribution is quite as end-user friendly as Windows out of the box and to me Linux is definitely NOT about that. The Ubuntu weekender geeks that desperately try to be the geekiest person in the room should take note (among others). Forget pushing Linux propaganda on others (remember we don't like Jobs-indoctrinated fan boys/girls selling us the Apple way either). Accept Linux for what it is: a more exclusive club that sets the bar higher than the others! Why should we be trying to lower the bar or grade? Let the newbies reach for the higher bar to get started, so we can attract a higher quality user base than the other two options. The BSD community is a great example!

I also feel this way on the Ruby front. I do wish all those nuts-oh "Rails rulz" propagandists would steer clear of all the PHP and Java bashing and Rails hyping. Do you really want all the subpar PHP and Java people (the ones that need hype so they can outsource their decision making to move over) in our world? I personally only want to cherry pick the Java, PHP, Python, etc. developers that actually think for themselves and willingly and enthusiastically step over to the Ruby side.

In summary, if you want someone else to think on your behalf go ahead it is a "free" country in that respect (if you aren't in a free country remember nobody owns your internal thoughts so you may as well abuse that freedom as much as you can:)!). However, you should also realize that it is only the free-thinkers that don't conform to mass expectations and opinions that are the ones changing things (mostly for the better, but feel free to disagree with me and form your own opinion:)).

My .gitconfig

2007-11-10T07:29:00.004-06:00


[user]
  name = Susan Potter # make sure you change this
  email = me@susanpotter.net # make sure you change this
[color]
  diff = auto
  status = auto
  branch = auto
[diff]
  rename = copy
  color = auto
[apply]
  whitespace = strip
[pager]
  color = true
[status]
  color = auto
[alias]
  co = "checkout"
  ci = "commit"
  ciall = "commit -a -v"
  unmerge = "reset --hard ORIG_HEAD"
  lsbr = "branch -a" # list all branches, even remote ones
  mkbr = "branch" # create branch if you specify a branch name after it, e.g. git mkbr upgrading_rails
  # remove branch named after it, e.g. git rmbr upgrading_rails
  rmbr = "branch -d"
  # rename branch from one name to another
  mvbr = "branch -m"
  # 
  track = "branch --track"
  # list all tags, to keep commands consistent, e.g. git lstag
  lstag = "tag -l"
  # create a new tag based on specified commit
  mktag = "tag -a"
  # remove existing tag by name
  rmtag = "tag -d"
  # rename tag from one name to another
  mvtag = "tag -m"
  # create new remote repository for project
  mkrem = "remote add"
  # list remote repositories
  lsrem = "remote"
  # show status, keep same as svn command I used most frequently
  st = "status"
  # another alias for status that some scripts might use
  stat = "status"
  # fetch and rebase from svn repository
  spull = !git svn fetch && git svn rebase
  # push keeping each local commit as atomic.
  spush = !git svn dcommit
  # initialize all submodules
  modinit = "submodule init"
  # update all submodules
  modup = "submodule update"
  # show status of all submodules
  modst = "submodule status"
  # add new submodule, i.e. git modadd module-name url
  modadd = "submodule add"
  # show last 15 log entries
  recentlog = "log -n 15"
  # push local committed changes to rubyforge and origin (usually GitHub)
  osspush = !git push rubyforge master && git push origin master
  # pull changes from rubyforge and origin (usually GitHub)
  osspull = !git pull rubyforge master && git pull origin master
  # sync (pull then push) from rubyforge and origin (usually GitHub)
  osssync = !git osspull && git osspush

Place your .gitconfig file in your home directory, e.g. /home/username
Last updated: 2008-06-28

Twitter4R v0.3.0

2007-11-05T02:18:00.000-06:00

After Twitter.com added a few extra APIs for favoriting statuses in October, I finally got around to adding them to Twitter4R tonight. Since there is new functionality I have released it as version 0.3.0.

To install all you need to do is:

$ sudo gem install twitter4r

The Rubyforge mirrors might still be syncing if you are doing this soon after I post this message.

The changes to the library include:

Added Twitter::Client#authenticate? method that is a lightweight way to verify a Twitter user's credentials
Favorites: allows Twitterers to add statuses to their favorites, list all their current favorites and remove any statuses from the list.

Example code for verifying a user would look like:

gem('twitter4r', '>=0.3.0')
require('twitter')

client = Twitter::Client.new
unless client.authenticate?("macdeveloperthatlovesleopard", "iamasciolists")
  puts "Password does not describe user well!"
end

if client.authenticate?("developerthatdoesnotpretendtobegraphicdesigner", "seriousdevelopernotfakestevejobswannabe")
  puts "Password does describe user well!"
end

Example code for using the favorites API:

gem('twitter4r', '>=0.3.0')
require('twitter')
require('twitter/console')

client = Twitter::Client.from_config('some/path.yml')
statuses = client.favorites
ids = statuses.collect {|s| s.id }
# clean favorites list by deleting
statuses.each {|s| client.favorite(:remove, s) }

# now add back first status id from original favorites list
client.favorite(:add, ids[0])

Enjoy!

The Democratic debate, Ann Coulter and cryptographic utilities for Ruby application developers

2007-10-30T23:11:00.000-05:00

An unlikely trio, but...

After watching the flip flop of Clinton in the Democratic debate, the subsequent carcass ravaging by her competition, UFO spotting by spock (aka Kucinich) and two great stinging one-liners from Joe Biden about the presidential [dis]qualification of candidate 911, I stumbled across the infinitely dim and unimpressive Ann Coutler. She was attempting to justify yet another deliberately outlandish statement she made last week, a desperate bid to remain in the limelight to which she is so addicted.

At this point, I remembered I wrote a RubyGem a few weekends ago that might be able to decrypt these events and make sense of it all (well maybe!?).

A few weekends ago I released metafusion-crypto as a Ruby Gem. I hadn't announced it yet as it got lost in the shuffle of some personal matters that forced me to take five days off work unexpectedly. So here is the belated introduction to that small, humble Gem.

This metafusion sub-project is basically just two utility classes: Metafusion::Crypo::PrivateKey and Metafusion::Crypo::DigitalSignature for application developers that don't want to worry about twiddling bits. To install you only need to do the following:

$ sudo gem install metafusion-crypto

An example of DigitalSignature usage might be:


require 'metafusion/crypto'

priv_key = Metafusion::Crypto.generate_key_pair
# this returns OpenSSL::PKey::RSA object into priv_key

include Metafusion::Crypto
sig = DigitalSignature.from_keys('rsa_key.pub', 'rsa_key')
original_text = "my clear text message"
crypted_text = sig.encrypt(original_text)
plain_text = sig.decrypt(crypted_text)
puts "It worked - let's celebrate!" if original_text == plain_text

An example of PrivateKey usage might be:


include Metafusion::Crypto
pkey = PrivateKey.new('mypassphrase')
original_text = 'Yo yo yo.  What up dog?'
crypted_text = pkey.encrypt(original_text)
plain_text = pkey.decrypt(crypted_text)
puts "Let's roll and celebrate - it worked" if original_text == plain_text

I look forward to application developer's feedback.

I promise to return to the agile anti-pattern "series" soon.

Update: Since two people asked, I have stuck to my tradition of releasing with only 100% C0 code coverage of the project's RSpec examples.

Agile Anti-Patterns, Part 1

2007-10-18T21:16:00.000-05:00

In the last 12 months I had the fortune to work at a client that calls themselves "agile". In fact they use marketing blurbs similar to "on the cutting edge of agile Ruby on Rails development" (I said *similar* because I didn't want to identify them uniquely).

The problem is when I briefly worked on a project for them, the truth was very far from their marketing spiel. At a minimum I can say that this was the case on the particular project I briefly worked on, but more likely to have been much more wide spread in the firm since the consulting manager managed all the client projects from what I could tell.

Why was I fortunate? Well first of all, it was a very brief encounter. I just couldn't bring myself to work in that environment for long (and thus you will not find it on my resume at all - nice try). Perhaps that says something about me too (I know it does - it is a liability, I realize this and plan to work on it, but on the other hand I feel as if I shouldn't have to compromise my professional values to the level of this case). Secondly, like I imagine is the case with most people, I learn more from bad experiences than good experiences.

I would also like to say this is by no means the only company that likely falls into this "let's talk about agile so much we pretend that in itself is being agile" trap. I see 1,000s of job ads or consulting firm spiels saying agile-this, agile-that. Probably only 10-20% of the spiels are decently aligned with reality (of course, I have no way of knowing or measuring this, but it seems like a sensible guess to me;)).

Now, is any agile team perfect? No. At least not in my experience. Maybe there are perfect teams and I am just a loser that has never experienced one, but since I have never met a perfect person ever, I imagine this to be improbable. The reason for my deduction is that since software agility is based on people and relationships NOT just tools, then only a team with perfect members could even dream of producing the perfect dynamic. The thing is, you don't need an agile team to be perfect. That is the premise of each agile practice I follow personally. If you think about it, agile practices assume people at their core are faulty some of the time in some way, because we are mere mortals, not software gods (though at times developers do get a God-complex, which is one of our many faults - I am guilty here too)!

Ooops, tangent, but is serves a point here too. I do not ever wish to imply that following the letter of all the agile practice "rules" will make you truly and *perfectly* agile. I do not even think that is even the point. For me it comes down to Kaizen, which in short means, to iteratively eliminate waste from a process each time you repeat and to break those iterations down into bite size pieces so you can track and measure progress (actually that is a very coarse way to describe Kaizen, which is a word I love so much I tattooed it on my body somewhere - just kidding.....or am I?). Feel free to search the web for a better description (there are a few), but it is a word the more you read about (at least for me) the more you appreciate.

Perhaps we will never be perfect agile developers. Perhaps we will never be perfect business analysts, coders, managers, deployers, system administrators, database administrators, etc. That to me is almost irrelevant. The idea is we just need to strive to simply "do better" each time and have the right attitude.

This was really just the kick off piece (aka rant) for this "series" on anti-patterns relating to agile practices. I'll have concrete examples coming soon in part 2, 3, etc.

Stay tuned.

PS If you are searching for an "agile" development post, don't despair, there are some decently agile places out there. They may not be perfect, but hopefully better than the client project I will discuss.

Coming out....in support of DHH [to some extent]

2007-10-11T21:16:00.000-05:00

Since today is National Coming Out Day in the US I thought I would use it somehow in my blog entry. Yes folks I am "coming out" in support of [some of] DHH's decisions.

Earlier today I noticed a lot of blog chatter regarding Rails and what various people think it *should* or should not be. While I agree with some of these people's sentiments that DHH is an arrogant ass, I also think he has made *some* smart decisions (though on a number of mid/lower-level issues I think he has it totally wrong). Now reread this paragraph until you get the point that I still think he is an arrogant ass with a God complex.

Firstly, let's discuss the "Twitter" issue. Yes, I use Twitter (occasionally), though I see it's biggest impact (for my personal interests) in marketing rather than tweeting every time I use the bathroom (note: I am not part of the look-at-me-NOW-Gawd-damn-it generation - I was a humble 70s baby). In fact, the marketing potential is what drove me to develop Twitter4R in the first place. What I don't like about Twitter is due to their own lack of foresight they desperately tried to blame a framework! An application framework because they couldn't get their act together to do the necessary scalability testing of their whole deployment environment (which includes many things, only one of them is the application framework) before hand. This is the same application framework that got them rolled out into production earlier than they would have with other frameworks. The same framework that allows them NOW to scale to crazy amounts of hits per second! I attempted to follow the dialog between the Twitter developers and Rails Core team, though not too successfully because it occurred through non-interlinked blog posts and comments. However, from what I could gather the Twitter folk seemed to think it should be up to the application framework to create an already baked in way for them to setup replication models. If they were using a PHP framework, they wouldn't have bothered asking since all the DB code is in the view anyway! Why is that the responsibility of the application framework? Now if Rails has somehow prevented them from being able to create ActiveRecord extensions to do this, I might understand, but as far as I can see....this just isn't so.

Secondly, the CDBaby rant. If CDBaby took 2 years to release using Ruby/Rails, then they must have had much bigger problems than Rails itself! Sorry to be blunt, but who takes that long anymore, even in a Java stack?

Ok, now for some leveling. I still think DHH is an ass and an extremely arrogant ass at that. I still think he has ridiculous ideas about trademarking logos (that he didn't even pay for), definitions of what components are, how vendor/* is better than utilizing Ruby Gems in virtualized or dedicated environments (WTF?) and general dependency loading in Rails. Plus, did I mention I think he is an arrogant ass? Not to mention a former PHP programmer...enough said!

Good night.

Twitter4R Announcements

2007-09-23T20:46:00.000-05:00

First off I have been meaning to post an entry letting people know of a recently released Rails application written by Sergio Santos called TwitterNotes that is using the Twitter4R gem.

Thanks Sergio (and anyone else that worked on the project - sorry if I left you off).

Also Sergio emailed yesterday requesting message paging support with a suggested patch (thanks for contributing back - muchas gracias). This evening I released Twitter4R version 0.2.5 that incorporates the necessary code changes for this support.

What does this mean?

Previously you would have only been able to get the last 20 sent/received direct messages from the Twitter4R bindings doing something like the following:


messages = client.messages(:sent)

Now you can request specific pages like so:


messages = client.messages(:sent, :page => 2)

The same is true for the :received case.

To install the Twitter4R RubyGem simply run the following in your terminal/console:

$ sudo gem install twitter4r

Give the Rubyforge mirrors a few hours to sync if you are only getting Twitter4R v0.2.4.

Thanks and enjoy!