Archive for the ‘Ruby’ Category

The Benefits of Releasing Software as Open Source

Friday, January 4th, 2008

Just came across this post which talks about automating Facebook interaction to perform a request in a Facebook app.

Their ruby code is here (much of it based originally off mine — which is so cool).

For the longest time I didn’t get open source… why anyone would give away their hard-earned time (in the form of code) to everyone else.

It’s not some hippie thing though. The benefits are:

* expands your “street cred” in the community
* allows other people to enhance what you’ve done, and possibly, contribute back to the project
* fosters even more giving back by growing pie — it’s not a zero-sum game, as many would believe

In my case, I’ve almost always already written the software that becomes open source. Without releasing it, the code would simply rot on the vine. Usually within 2-3 hours (though I’m getting better), I can have the code cleaned up, tests added (if applicable) and released as an open source project.

The original Facebook automation article is here: HOW TO: Automate Facebook Interaction using Ruby and WWW::Mechanize.

More recent open source work: Sexy Temp Passwords (rails plugin), Dynamic File Store (rails plugin), and The Hydra Project.

Amazon S3 Rocks (Usage Report)

Tuesday, January 1st, 2008

Amazon S3 is dirt cheap and infinitely scalable. Every month I’m paranoid this willspike up to hundreds and thousands of dollars, but instead it only steadily rises just $1-2 each month:

Amazon S3 Sample Usage Report

I’m using Amazon S3 for:
* daily/weekly/monthly backups for 10+ sites (ranging from big to tiny)
* serving photo galleries for a site that does ~ 10k daily uniques
*sometimes used to serve static assets like “style.css”, “prototype.js”, etc

It can be especially handy as a rails static asset host:

An asset host is another server, somewhere on the internet, where you store your static files. These can be javascripts scripts, CSS stylesheets, images, static html files and anything else that doesn’t change often. Basically, anything that lives in your public directory.

So, why would you want to use an asset host? It turns out that many browsers limit the number of simultaneous connections to a host. For Internet Explorer, that number is two. If you are serving a lot of small images, or you haven’t bothered to bundle your scripts or stylesheets, this can be a real bottleneck.

Read more about setting up static asset hosts in Rails here.

Thoughts on “Rails is a Ghetto”

Monday, December 31st, 2007

I won’t link to the article, but recently a very popular and well-respected member of the rails community wrote some scathing stuff about some members of the community, pretty much lambasting the entire RoR crowd in one fell swoop.

If this person’s blog had “Enterprise Java Architect” plastered across the top of it (and was not a well-known ruby contributor), then I’d probably be here ripping him to shreds. Actually, I’d probably be here just ignoring that kind of rant…

I’ve blogged before about the ability to take criticism well. Unfounded, meritless attacks are one thing. But if the criticism points out some flaws that are recognizable, I’m more than willing to take a good hard look. Won’t necessarily agree with the critics or feedback all the time, but it’s worth at least getting, to see how other people perceive you / your abilities / etc.

That’s how I would view this attack on some members of the community. He backs much of what he says up with IRC logs. Some of them, if true, are indeed astounding. i.e. the fact that a, how shall we say, major RoR operation had to restart their app server 400 times a day. Who knows if this was an exaggeration, or later turned out to be due to hardware failure (it happens).

On Consulting

It’s this persons right, but he basically called almost all of his consulting clients “morons” or some such. His reasoning was that he had a business degree as well, and obviously a high sense of self-worth & belief in his ideas, etc.

This person should clearly not be doing consulting. He made some pretty major mistakes, i.e.:

1. Not getting a percentage paid up front (i.e. minimum 30% of some X amount)

2. Kept working on projects even though he wasn’t getting paid (similar to #1)

3. Allowed his clients to pay him NET-30 (turned into NET-60)

You have to be pretty firm as a consultant or clients will try and walk all over you. On several occasions, I’ve had the opportunity to glance at client’s bank accounts just to ensure A) they had a viable balance, or B) they indeed were sending me a check via their bank’s check mailing system.

In these cases, I didn’t ask this but the clients offered this to me as an assurance that they were the real deal.

For every 1 paying client, you get 4-5 people who want you to work equity-only, so often the lines are blurry.

Do Most of Us Get it Wrong?

Statistically speaking, most of said rant author’s clients probably will fail. But at least these clients are taking chances by starting “some silly social network.” BTW - has he heard of silly social networks like Bebo who targeted the UK market (even while MySpce dominated here) and is now valued at hundreds of millions?

Or perhaps Digg, which was built by a php contractor for ~ $2,000 paid for out of Kevin Rose’s retirement savings. This ruby contributor (god bless his contributions, which my apps use daily) would probably have scoffed at Rose’s idea for “yet another” social bookmarking site.

Small sample sizes indeed, not scientifically indicative, but if all of these client ideas are stupid, then sites like Digg, Bebo, etc. would never have broken through.

Extraction of Sunk Labor Cost Value Through 60+ Hour Weeks

The rant author then goes on to post this gem, which I could finally get behind (company name removed so as to not run their name through the mud via hearsay):

Because ******** pays these people a salary that is fixed and considered a sunk cost. If they pay someone 60k/year and that person works 40 hours/week then they are paying them about $29/hour. If they convince this idiot to work 60 hours/week then they are basically paying the moron $19/hour. If they can push them to 80 hour/week then these idiots are actually making $14/hour. You can make $29/hour managing a fast food joint.

The further and harder ******* (or any consulting firm) pushes its employees the more money they make because then they charge the client for each fucking hour. Get it? If they push an employee to 60/week they not only reduce the cost of that employee but also increase the billable hours. Hell, even if they don’t charge for those hours they still make more money just by reducing costs.

Okay, but that could be said of any company that hires someone on salary but then pushes them to work so many more hours each week.

I’ve had occasion to work with people who seem to value hours spent in the office as opposed to actual productivity.

They basically come across as having the Jesus Complex, i.e. “they died in the office for our sins.”

Here were some of the things that were slightly annoying about this mentality:

1. You could, literally, get as much done in 20% of the time (or 5x as much for the day), but if you didn’t work 10 hours that day you still looked like a slacker.

2. Working from home is not allowed. Lord knows, people might *goof off* at home (or run errands) in between checking in code. Because no one ever surfs Google Reader, Digg or their favorite sites in the office.

3. Were not accustomed to using a Changeset viewer to see exactly what everyone is working on each day.

4. Changeset viewers would make it trivial, for example, to see if someone indeed produced many multiples of quality output as someone else.

5. Would spend 20+ hours setting up their favorite version control / ticket system, when Unfuddle and friends would be ready to go in 5 minutes worth of setup.

6. Would create new projects (not optimizations) that could take days to implement (not to mention maintain), when leasing an additional server @ $125 per month would solve the problem equally (if not better) as well.

This is not directed at anyone individually, but rather that kind of mentality that values “looking like you’re working hard” vs. actual quality output.

Under Pressure

I’ve had to deal with a pressure cooker situation before, where this statement from our rant author rang a bell:

I saw them pull passive aggressive shit like picking on a single employee high-school-nerd-vs-jock style until he conforms or quits.

In my case, I got the heat because of my speaking up about the diminishing (then negative) returns of pushing devs in 60, 70+ hour weeks. Then eventually walking out one evening when my feelings on the matter weren’t being heard.

If you’re treated like this, it probably is a good idea to just walk out or somehow or another assert your value. If you’re normally a rockstar but are farting along, checking in crap code, while you see your fellow devs checking Facebook stats every 5 minutes in between GReader sessions, then you know that nobody is really getting much done but is rather just putting in face time…

All in all, that experience was a learning one, and it was more about miscommunication, middlemen / managers, etc. than anything.

Rant Repercussions?

Will this developer’s rant have repercussions beyond the ruby world? Perhaps — this could end up all over Digg, programming.reddit.com, etc.

I say that’s great though. If the RoR community can’t take criticism, then it will never actually evolve or learn to take a good hard look at itself in the mirror.

Getting Mongrels to Start on Boot

Monday, December 17th, 2007

When your servers only reboot at most once every few months (data center maintenance), you don’t have to think about this thorny problem all that often.

But it’s a nice touch to get your Rails deployments almost 100% hands-free.

Checkout How to Start Mongrels on Boot over at shanti.railsblog.com for the 411.

Review: Beginning Ruby

Saturday, December 15th, 2007

Beginning Ruby (by Peter Cooper) is a massive tome (600+ pages!) on the ruby language.

If you want to know just about everything there is to know about ruby, it’s here in Beginning Ruby: From Novice to Professional. Now just reading this book won’t make you a ruby pro, but actually applying each of the things you learn will no doubt put you in a better spot than most “rails jockeys” who are just learning RoR.

For me, coming to Ruby via Rails made things a bit harder than they should’ve been. Had I been sane at the time, I would’ve read a good chunk of a book like Beginning Ruby first, before attempting to jump into Rails. But alas, many of us learned the fundamentals (and beauty) of Ruby only after being bit by the rails bug.

Just a few of the things that are covered in Beginning Ruby:
* ruby language basics (types, classes, inheritance, modules, etc)
* creating and releasing ruby gems
* parsing / working with xml
* working with URIs and files
* compressing files
* basic encryption/hashing
* … and of course some of the basics of Rails.

If you still don’t have an introductory book on Ruby, you can grab Beginning Ruby at Amazon.com and also directly from the publisher’s website (Apress).

It’s More Fun to be an Anarchist

Friday, September 28th, 2007

… but less fun defending yourself against charges of language bigotry.

Oh sweet, someone reads my blog!

Peaceful Dialog
Hippie

Starbucks-window Breaking Anarchist (even in the name of good fun)
Starbucks Anarchist

The analogy isn’t perfect, but taken to extremes this is what we’d have in the real world.

Do you care about winning converts?

No? Okay, that’s cool.

Do you want to have to defend yourself for being a Ruby (or Rails) Guy?

Let’s say you’re the Gandhi of fair trade protest. You organize massive swaths of people that come together and hope to make a difference on the issue, based on the merits of your argument and the justness of your cause. You believe that if you gathered enough people, lobbying power, etc. that you could honestly make a difference in this arena.

Then along comes a rival faction, wearing ski-masks, who at every junction when you’re about to have the spotlight, throw bricks through Starbucks windows and cause a huge ruckus doing their anarchist thing.

They totally steal all the attention away from your peaceful cause. Nay, they have hijacked your cause and now you can’t get a fair break from the media or general population.

You’re with fair trade? (Oh, one of those nut jobs …)

The Fear / Annoyance

I’m at a conference or industry event. I introduce myself and say that I’m a Rails developer.

Fellow Dev:  Ohhhh... You're with those asshats.
Me: 'Scuse meh?
Fellow Dev:  Yes, the language bigots.
Me: Oh, that's not me.
Fellow Dev:  Well okay, but that crew you roll with sure can be
   a bunch of arrogant assholes.  That's why I use Python.
Me: Well then...

I forsee this happening in the future, sadly.

74 Quality Ruby on Rails Resources and Tutorials

Monday, May 7th, 2007

SoftwareDeveloper.com has a great roundup of RoR tutorials, links, etc:

Ruby on Rails is quickly becoming one of the most popular modern programming language framework combinations. Specifically, Ruby is a programming language that has been around for a few years and Rails is a framework for Ruby that is a bit newer and is just about the hottest thing in application and web development right now. Rails’ seamless integration into web servers and databases and its elegant framework make it the ideal candidate for every programmer wishing to develop the latest and greatest web application.

74 Quality Ruby on Rails Resources and Tutorials(hat tip: Rich McIver)

Rails Fragment Caching Gone Wild

Tuesday, February 6th, 2007

Ruby on Rails
One of the killer features of Ruby on Rails is its caching abilities, specifically fragment caching.

Rails fragment caching allows you to cache any piece of html or RoR-generated JavaScript.

Things like generating Tag Clouds are ideal for fragment caching — they generate a lot of SQL queries and you don’t need them to change that often.

RoR also offers page and action caching, but I haven’t found these to be as useful.

If you’re working with RoR on apps where you need to display different page elements depending on whether or not a user is logged in, then page/action caching does not help you so much. (though there some plugins to help you get around this problem)

Sproutit

At Sprout, we just deployed Mailroom 2.0. We’ve made a ton of improvements, but as part of that each Show Conversation request (made via Ajax, and cached on the client-side) was producing a ton of queries on the backend.

We’re doing a lot of stuff in that action — collecting messages and notes for the Conversation, checking hotlists, etc.

And it’s also the most-used system call in the application. The whole point of Mailroom is that you want to spend less time as a team managing your email, while still keeping that small company, good support vibe with your customers and clients.

That means the Show Conversation method needs to be fast. Blazing fast, hopefully. (which, under some scenarios, especially for power users, it hasn’t been 100% of the time — not that it can ever be 100%, but 95%+ would be nice =)

Fragment Cache Results

By implementing rails’ fragment caching for that action, I’ve got that action down to 3 SQL queries (and change):

Org Load
Member Load
Conversation Load
(there will be a few more under certain circumstances, i.e. of there is a note applied to the conversation)

When watching the rails log, this is then what I see next:

Fragment read: .00078

YEAH buddy!

.00078 seconds = 1,282 requests per second without breaking a sweat!

Of course, the real bottleneck, once this is implemented, gets moved up the chain, to the Org/Member/Conv loads. The only way to reduce those is to use something like memcached or to tweak Postgresql.

If you’re a Mailroom user, stay tuned in the next few days as hopefully some of these performance improvements will hit the streets!

A Few Thoughts After a Major Ruby/Rails Deployment

Thursday, January 25th, 2007

Programmers seem to be obsessed with programming language speed.

I’ve ranted before abaout Joel and his Wasabi project, for bashing Ruby.

Last night / this morning we were pushing out a major release of Mailroom.

Some of the maintenance scripts we had to run to catch up the database are/were taking an incredibly long time.

We were pushing two boxes to loads of 4.0 - 6.0. When we started MR’s receiver, we were seeing loads of 8-10. For the non-techies, that means that something like “800%” of the CPU was being used, or something like that. Basically, you don’t ever really want it that high.

But anyway.. the point is that a majority of the processing juice seemed to be going to the DB. I would guesstimate 80-90% of the cpu juice on that server was being used for the DB, not Ruby. That was really the limiting factor, it seemed, not Ruby code.

So why do coders get their panties all in a bunch about programming language speed, but not so much when it comes to database speed?

I guess because we really only have a few options in the Database game, so the DB wars are restricted to “MySQL vs PostgreSQL” or maybe throw Oracle in their if you can afford the $30k licenses.

Whereas programming language wars let you explain why you think VBScript, Wasabi, Lisp, Java, Smalltalk, Ruby, Python, Perl, PHP, etc. is better than X language.

That’s everyone’s favorite Slashdot (now Digg) thread right there.

Now, I know this totally depends on the application… but it’s true for ours. And I’ve seen it be true for many that I’ve worked on in the past:

If 90% of your application’s process is spent in the DB, how much does a 50% increase in speed in your programming language (or VM) get you, in terms of overall application performance? …

… 5%! Nothing to get too excited about, eh?

The Programmer Hierarchy

Tuesday, December 26th, 2006

Found this via del.icio.us/popular:

Programmer Hierarchy

Not to take it too seriously, but my personal take on being a Ruby programmer, well, more of a Ruby + Rails programmer, is not so much about it being a superior language or considering myself superior to developers of any other languages, but rather that I’ve just found a “secret” (not so much lately) way of getting things done faster.

If suddenly a new framework for Erlang, VBScript, or heck, Blub, appeared that would make development incredibly efficient on that platform, many Rubyists would definitely take a look (that’s how 99% of us came to Ruby in the first place).

Mythical (but possible) blog post:

Hey — have you checked out the new VBScript on Rollerblades framework? I know it’s hard to believe, but I get about 10x as much done!

When All Else is Commoditized, Optimize for Time

I remember when a professor back in school first introduced the appeal of commoditization of complimentary services to your own. IBM and Linux is the quintessential example. Why would IBM want to commoditize the OS market (by investing heavily in Linux), when they already make a few of their own?

IBM Linux

Now it seems normal, with Sun GPLing Java, but a few years ago many analysts were scratching their heads as to why IBM would want to invest $1 billion in Linux and open source.

Because now IBM can sell consulting services @ $250 per hour, while the cost of their OS and server software (used to deploy production systems), remains virtually nil. A $1 bln investment is pretty cheap for a rock-solid OS, especially when you’ve got $20 billion a quarter in revenues.

If you have any doubts about this, talk to a small business owner who’s buying SQL Server and Windows 2003 Server licenses because they decided to build out their platform on MS. (I had the pleasure of doing this recently - business owners are not happy about paying more for a licensing fee than the actual hardware!)

With servers and bandwidth being incredibly inexpensive these days, while OSes, database software and web framworks remain free (that is, if you use the right one *wink*), the only thing left to optimize for is developer time.*

* I do have a vested interest here. But I challenge you to try out an inexpensive Indian outsourcing firm (commoditized developer time) and report back your results. I haven’t heard too many success stories yet.


You are currently browsing the Shanti's Dispatches weblog archives for the 'Ruby' category.

Shanti A. Braford blogs here.

If you really want to know, just read this.



  

Powered by FeedBlitz