Posted by Lance Ivy
Sun, 07 Sep 2008 03:33:00 GMT
Wired has an article about a proof of concept Facebook botnet. They also have Facebook’s response, which is pathetic and naive:
Facebook downplayed the attack, saying that any developer that could figure out how to make a successful application would make money other ways.
Seriously? Are you saying that botnets are run by unsuccessful developers? Try again. Are you saying that DDoS can’t be profitable? One word: blackmail.
But Facebook spokesman Barry Schnitt disputes the economics of the attack.
“As a practical matter, it is not that easy to get an application with millions of users,” Schnitt said. “Why wouldn’t you get venture capital or make money with ad rather than use it to take down a website?”
The researchers chose to point the hidden attack at their own server, of course—but were surprised that more than 1,000 Facebook users installed the application, even though they only mentioned it to friends.
That led to a peak of 300 requests per hour and on its peak day, the traffic went above 6 Mbits per second.
They weren’t even trying to make it popular. Sigh. Optimism will only get you so far, Barry.
I can’t fault them for trying to downplay and stall and spin, though—this one’ll be tricky to fix. Anyone remember the Samy MySpace worm?
no comments
Posted by Lance Ivy
Wed, 03 Sep 2008 20:46:00 GMT
Long long ago on a project far far away, I was anticipating an edge case that required me to actually merge database records together, along with all their associations. So I took a day and wrote this plugin. It has never seen production use in my projects, but I always refer back to it because I took the time to figure out database-powered plugin tests. And because it has a set of test models (and fixtures) that try and encompass every major combination of ActiveRecord associations (e.g. has_one/belongs_to in addition to has_many/belongs_to).
It’s been gathering dust in my personal SVN repo.
That’s not how it’s supposed to work.
Now it’s on github.
Posted in Ruby on Rails, Open Source, Releases | no comments
Posted by Lance Ivy
Thu, 28 Aug 2008 23:08:00 GMT
Dear gentle reader,
You may, at one point, have wondered how to shield innocent Internet users from the vagaries of widget response times. You may have glimpsed Nginx’s proxy_read_timeout configuration and thought it an appropriate way to moderate lag spikes.
You may have been wrong.
I was.
At UserVoice, we were fielding complaints that our widget was slowing down pages, but our rendering times were low thanks to heavy caching. Well after installing New Relic’s RPM, we were quickly able to identify the problem—long Mongrel queue lengths. Given an upcoming hosting transition, and given some complications with further caching improvements, we thought the most expedient short-term fix would be setting a proxy_read_timeout on widgets. The theory: even if we’re slow, it’s not your problem.
But it’s still our problem.
See, nginx worked dutifully and beautifully. Whenever a widget response took too long, it returned a status code that let the client continue browsing. And then it would hand the next request back to the Mongrels … but they weren’t done with the last request, so the new one was just … added to the queue.
Imagine working in an environment where, as soon as you were bogged down, your boss started giving you work faster. You wouldn’t be happy. Neither was Mongrel.
I’m sorry, Mongrel. I’ll do better next time.
no comments
Posted by Lance Ivy
Tue, 26 Aug 2008 03:00:00 GMT
Starting fresh projects is my favorite time to try new things. On this last project, it was RSpec. After looking at specs someone else wrote and playing around a bit, I’ve decided on what I like the most.
It’s the describe block.
Organization matters to me because it’s how I find my way around. It’s the principle of chunking, which is basically memory’s equivalent of keeping the code DRY. If I know how things should be organized, I can forget the details about how each instance is actually organized and reduce the burden on my memory.
Given how much tests can grow, organization is key to getting around later on. Here’s my basic approach to organizing tests for, say, an ActiveRecord model:
describe User do
describe "associations" do
end
describe "validations" do
end
describe "the foo method" do
end
end
It’s nothing spectacular—I generally have tests to make sure associations are set up properly, so those get chunked. And I always try throwing bad data at the validations to make sure those are set up properly, so those get chunked.
And, of course, a big bonus to chunking like this is that you can set up before blocks in each scope to DRY up your assertion preparations (e.g. mocking/stubbing/what-have-you so you can isolate a method).
Anyone else have favorite describe blocks?
2 comments
Posted by Lance Ivy
Thu, 21 Aug 2008 16:25:00 GMT
I’m planning a serious of Rails posts covering some conventions that I’ve come to really to appreciate in the applications I develop. I’m going to make this first one easy on myself—let’s talk about organization!
How Rails Organizes
The way Rails organizes application code was deeply satisfying for me, coming from my home-brew PHP background. The app/ folder with app/controllers, app/models, and app/views really helped me embrace the MVC paradigm. Love it!
But when I start adding email, I get a little twitchy—Rails files the ActionMailer classes under app/models, and the email views under app/views. I get this. I understand this. It still makes me a little twitchy.
Then I start adding observers, which also go in app/models even though they’re really not models. But they’re related to the models, so that’s got to count for something, right? Eh.
And how about sweepers? Do they really even have a home? Their heritage is so confused.
But do you know one of the worst parts of all of this? Having user.rb and user_mailer.rb and user_observer.rb breaks my shell’s tab-completion! Noez!
How I Organize
This is simple—embrace config.load_paths and widen your app/ directory. I like to create app/emails, app/observers, and especially app/sweepers. This really helps me find code faster, because when I’m navigating my folders looking for an observer, the first thing in my mind is “category: observer”, not “something related to models”. So navigating to app/observers is much more intuitive.
How does this happen? Again, simple.
config/environment.rb
Rails::Initializer.run do |config|
...
%w(observers sweepers emails).each do |dir|
config.load_paths << "#{RAILS_ROOT}/app/#{dir}"
end
...
end
Then just start moving your code in there. Rails will find it.
We’re Not Done With Mailers
You’ll want to do one more thing to organize your mailers. Without this step, you’ll have only cleaned up your app/models directory, and you’ll still have templates scattered in app/views.
First, create an application mailer (just like the application controller):
class ApplicationMailer < ActionMailer::Base
self.template_root = File.join(RAILS_ROOT, 'app', 'emails', 'views')
end
Now make all your mailers inherit from ApplicationMailer, and move your email template into app/emails/views (e.g. your mailer is app/emails/user_mailer.rb and your templates are in app/emails/views/user_mailer/).
And for a bonus? You now have a place to add custom helpers and email setup methods to really streamline email setup for your application.
Posted in Ruby on Rails, Conventions | 3 comments
Posted by Lance Ivy
Fri, 01 Aug 2008 07:30:00 GMT
I’m hanging out my shingle.
Developing this small, focused page was very fun for me. My plan was to develop an online “business card” and not go overboard. I wanted it to stay small and lightweight (no database even), so I picked Sinatra instead of Rails. Nice!
The next step was designing. I like to think I’ve picked up some design mojo through osmosis the last year. The truth though is that my design muscles had atrophied a bit, but after learning a few new GIMP tricks and a few iterations of trial-and-error, I was happy.
Until I sat on it for a couple weeks.
Then I realized what I’d done—designed a boring page for some faceless consulting company. But that’s not me! As a solo freelance Rails developer, part of my value is a personal touch. Why hide that? So I went back to the drawing board, and a few iterations later was happy again.
But … ask me again in two weeks.
2 comments
Subscribe