My Secret Life as a Spaghetti Coder

How to avoid becoming a formerly-employed Rails developer standing in line at the OOP Kitchen

Sammy Larbi — Thu, 01 Mar 2012 06:10:48 -0500

Here's a 35 minute recording of the presentation which I gave to houstonrb on February 21, 2012. It is a practice run I did before the live presentation, so you won't get the discussion, but hopefully you'll find it useful anyway.

How to avoid becoming a formerly-employed Rails developer standing in line at the OOP Kitchen from Sammy Larbi on Vimeo.

You can find the slides here: Slides for the Rails OOP presentation

There is also reference to a project whose purpose is to eventually be a full-scale demonstration of the techniques: Project for the Rails OOP presentation

Let me know what you think in the comments below.

Updated to use HTML5 player at Vimeo.

Comments?

Better OO Design in Two Questions

Sammy Larbi — Wed, 22 Feb 2012 08:24:54 -0500

Someone rip this idea apart:

When you write an if statement in one class that's using data from an object of a different class to make a decision, ask yourself:

Would this code be more appropriate in the other object?
Would it be better to introduce a new object, whose purpose it is to do this?

Thoughts appreciated.

Comments?

Future Companies

Sammy Larbi — Wed, 08 Feb 2012 06:51:43 -0500

My take at this concept was too long for twitter, and I was too lazy to pare it down:

In the future, the only companies that sell physical goods* will be the ones that figure out how to mine atoms from raw materials which can be used as "ink" in 3d printers which people use to print their own products from (probably pirated) plans they found on the internet.

* This excludes non-mass-produced art

Thoughts?

Comments?

Rethinking Routing in Rails

Sammy Larbi — Wed, 01 Feb 2012 05:44:32 -0500

You know when you see code like this:

  class CompulsionsController < ApplicationController

      # ... standard actions above here

      def update

        if params[:obsessions].include?(ObsessionsTypes[:murdering_small_animals])

          handle_sociopathic_obsessions 

          redirect_to socio_path and return

        elsif params[:obsessions]

          handle_normal_obsessions

          redirect_to standard_obsessions_path and return

        end

        # normal update for compulsions 

        @compulsion = Compulsions.find(params[:id])

        if(@compulsion.update_attributes(params[:compulsion]))

        # ... remainder of the standard actions below here 

    end

and the phrase "WTF were they thinking?" runs through your mind?

I have a theory about that little "pass a flag in the url to skip over the real action and perform a different one" trick I see so often (and have been guilty of using myself).

It's because you've got this omniscient file that knows everything about where to route requests that's not part of your editing routine, so finding and opening it breaks your train of thought.

It's a pain to open routes.rb when you suddenly realize you need a new route.

That got me thinking: Should controllers route themselves? Would it make more sense for a controller to tell the router how each of it's actions should be reached?

In the second edition of Code Complete (that's an affiliate link), Steve McConnell writes about using the Principle of Proximity (page 352) as a way to think about organizing code.

Keep related actions together.

From that point of view, it certainly would be easier to follow along when you're questioning "how do I get to this action?" Further, I think it would help solve the "pass a flag to an action to perform a different one" problem I illustrated in the code snippet above.

It was on my mind over the weekend, so I put together this little experiment to see what controllers routing themselves in Rails would look like. In that repository is a one-controller Rails project which specifies routes to itself using a gem you'll find in vendor/gems/route.

One major drawback to doing routing in this style has to do with nested routes: should a controller that's part of a nested route know who it's parents are? Should a higher-in-the-nest controller know about its child routes? And if you choose one or the other, how would you specify it? What if there are conflicting routes -- who wins out?

It leads to a lot of questions for which I have no immediate answers.

Anyway, what do you think? Would this help solve the problem of recycled routes? Is that even a problem?

What are the drawbacks of such an approach? Do you see any merits?

Comments?

APIs have the signup process backwards

Sammy Larbi — Fri, 27 Jan 2012 06:01:16 -0500

Most online developer API services that I've used are set up as if the customer is also the software developer.

That should change.

As the software developer, I don't want to be the owner of my customer's accounts, and I don't want to worry about trying to figure out how to transfer ownership (if your service allows it, that is). Because of that, theres a lot of waste that goes on: wastes of my time, which wastes my customer's or my company's money.

I'm saying "customer" here, but you might substitute that with "the person who really needs / cares about the account," because that person, in my estimation, is rarely the software developer. Unless I'm developing an app for myself, I only care about that API because someone else needs me to. And even when I'm developing for myself, I hope it gets to a point where I need to hire someone to care about it on my behalf, so I can focus on more important things.

The typical signup process for me goes like this:

Me: If I already have an account, sign out.
Me: Sign up for the service. Find what I need to integrate with the API. Note the steps I perform.
Customer: Signs up for the service, with me providing the steps they'll need to take.
Me: Ask my customer to give me the info I need, or grant me access if that option is available.
Customer: "I can't figure it out, here's my login info, find it please."
Me: I find the info, and tell the customer to reset their password. I doubt they ever do.

You're offering the service, yet there's no "you" in that process.

Here's the process I'd like to see:

You: Tell me I can easily transfer the account (or project or access keys) before I bother to sign up
Me: Sign up for an account for myself.
Me: Get everything working.
Me and You: If I know my customer already has an account, provide a place for me to enter my customer's email address. If you offer more than one thing I'll need access to, let me indicate what I need for this project.

You: Send detailed instructions of to grant access to my needs.

You: If my customer does not have an account, you send them detailed instructions for how to sign up and what they'll need to know to get value from your service.
- Customer: signs up for their account, indicating they are actually working with me.
You: Hook up our accounts, with me transferring ownership of that "project" to my customer.

There's a lot less of me and my customer in that process, and a lot more of you. It's certainly more complex, but it's simpler for the people who matter: your users.

Remember, the software developer is often the one who makes recommendations as to which products to use. Make it easier for me, and I'll be more likely to choose your service over a competing one.

post scriptum side note: I used Lucid Chart to do the flow charts. I really like it, but given how rarely I've wanted to diagram online, I don't see myself becoming a paid subscriber. What do you use?

Comments?

Three passive-aggressive ways to feel like you're getting back at typecasers

Sammy Larbi — Wed, 21 Dec 2011 08:49:56 -0500

Type Casing is the act of using case statements in a program to determine what to do with an object based on what type of object it is. It's an OO fail, often hoping to implement Multiple Dispatch. (See also Case Statements Considered Harmful)

Here are three passive-aggressive ways to feel like you're getting back at typecasers.

The first tactic turns your object into an everything, so it's whatever the typecaser was looking for. I've called it OmniObject.

module OmniObject

  def is_a?(*)

    true

  end

  def kind_of?(*)

    true

  end

  def nil?

    true

  end

end

foo = "hello, world!"

foo.extend OmniObject

puts "Is foo a Fixnum? #{foo.is_a?(Fixnum) ? 'yes' : 'no'}"

puts "Is foo a Kernel? #{foo.is_a?(Kernel) ? 'yes' : 'no'}"

puts "Is foo a NilClass? #{foo.kind_of?(NilClass) ? 'yes' : 'no'}"

puts "foo.nil? => #{foo.nil?}"

The next one makes your object unable to decide what it is, turning it into a FickleTeenager. If he has to check more than once, the typecaser is going to have a tough time with a kid who can't make up his mind.

module FickleTeenager

  def is_a?(*)

    sorta

  end

  def kind_of?(*)

    sorta

  end

  def nil?

    sorta

  end

  def sorta

    truish

  end

  def truish

    rand < 0.5

  end

end

foo = "hello, world!"

foo.extend FickleTeenager

3.times{ puts "Is foo a String? #{foo.kind_of?(String) ? 'yes' : 'no'}"}

Finally, we have the AntisocialPrivacyAdvocate. When the typecaser asks him what he is, he tells them like it is: It's none of your damn business!

class WhatBusinessOfItIsYoursError < StandardError; end;

module AntisocialPrivacyAdvocate

  def is_a?(*)

    raise  WhatBusinessOfItIsYoursError

  end

  def kind_of?(*)

    is_a?

  end

  def nil?

    is_a?(NilClass)

  end

end

foo = "hello, world!"

foo.extend AntisocialPrivacyAdvocate

result = foo.kind_of?(String) rescue "#{$!} OMG, How Rude!"

puts result

Comments?

How do you get two secure sites to cooperate and operate seamlessly for the end user?

Sammy Larbi — Fri, 09 Dec 2011 06:13:19 -0500

Suppose you have some awesome analytics tool that provides great value to a bank's customer, but they need to interact with it through the bank's website, and you need to host the tool.

You already have the data you need for the analytics to work, and the only missing piece you're left to consider is "how do I know to whom to show which data?"

The data is private, so you need to ensure you're not showing it to someone who's not authorized to see it.

Photo by pbkwee

Some more constraints:

You don't want to generate thousands of usernames and passwords that would create more burden for the users (and force them to log in twice)
You can't hook into the bank's user system. (nor would you want to, since they'd still have to log in twice)
You want this to be reasonably simple for the bank to implement whatever they need to do to make it work on their end.

To show it on their site, you decide to create a template-less app that they'll embed in an iframe.

So what authorization mechanism do you use to know who should see which data?

One idea I had was to simply restrict which IP addresses (to those of the bank) the app would respond to. Then they could just request a page via HTTP and serve up our response. But in order to get that to work, there's too much that needs to be done: we have to coordinate all URLs with whatever the bank decides they should be, and they have to figure out whether to GET, POST, PUT, etc. back to us.

The next idea was to have a single page that is restricted by IP address (to those of the bank), where they will make an HTTP request to receive a token that expires after some length of time (or at the bank's request, if they hit another URL to invalidate the token). The bank includes the token in the iframe src URL which lets you know whose data to show.

But I'm really interested in hearing your thoughts. How would you do it? Is there a standard way of doing this already?

Comments?

Ruby random numbers

Sammy Larbi — Wed, 15 Feb 2012 05:58:21 -0500

Update: Ruby 1.9.3 adds the ability to use ranges as arguments to rand, which produces more obvious code. So if you're using it, instead of using "magic offsets" like I did in the original post (as Joni Orponen mentions in the comments below), it would be better to use rand(1..6) to simulate a die roll.

So to summarize: if you need a percentage between 0 and 1, just call rand. If you need an integer between 0 and x (not including x), you can still call rand(x). Finally, if you need a number in a specific range, just call rand(x..y) where x is the lower bound of the range, and y is the higher end.

(And recall that if you want a non-inclusive range, you can use 3 periods, like rand(1...100) to get numbers from 1 to 99. Although if you're typing the number out, it's certainly better to use 1..99, if you had used a variable in the higher part of the range, the 3rd period is preferable to 1..(x-1), in my opinion.)

The original post follows:

Another quick note today... I surprisingly have yet to need a random number in Ruby up to this point (or forgot if I did), so I went through a little hassle trying to find out how. Turns out, you can simply use rand(int). So, if you needed a random integer to simulate a roll of a six-sided die, you'd use: 1 + rand(6). A roll in craps could be simulated with 2 + rand(6) + rand(6).

Finally, if you just need a random float, just call rand with no arguments. After that, you can modify the range as you normally would in anything else (i.e., using addition and multiplication).

I guess I used some crappy search terms, because I couldn't find this via google, and I didn't see it skimming the usual suspects in the Ruby docs.

Comments?