How I Learned Ruby

July 28, 2006

Greg Borenstein started an interesting process this morning, inspired by Amy Hoy‘s talk at FOSCON about how to keep the Ruby community healthy in the face of explosive growth. It’s a sort of chain letter, a kick start to the process of collecting stories from developers about how they learned Ruby. He named me in the first round, so I have no choice but to answer …

How I Learned Ruby

What was your technical background before you started learning Ruby/Rails?

Ten years ago I was an operating system and security geek who spent a lot of time twiddling with Linux kernels and GCC. Then I discovered dynamic web sites, and played around with CGI Perl scripts. I jumped on the PHP bandwagon pretty early on, got into Java when servlets were the New Thing, and pretty much stuck with PHP and Java until early 2005.

How long ago did you start?

Early 2005. I’m not sure exactly when I first dabbled in it, but my first real venture into building applications with Rails was in April 2005.

What were the two most useful resources to you in the learning process (not counting The Agile Book or the Pickaxe Book, which we’ll assume everyone knows about)?

The Portland Ruby Brigade, and Google. I had a pretty good understanding of architectural issues from the Java universe, so the hurdles of understanding MVC and ORM were long past … the big issue for me was understanding The Ruby Way, and nothing explains that better than source code (Google) and a community of people who enjoy talking about it (the Portland Ruby Brigade).

I’m going to toss in a third resource, and that’s developing Rails applications with a team. I was fortunate enough to spend several months working with the very talented developers at Planet Argon, and I’ve had the opportunity to work with several other small companies and contractors in the Rails community. There’s nothing quite like pair programming and code review to “keep it real.”

Strangely enough, I don’t own a copy of the Pickaxe Book, and although I ordered a copy of the Agile book, I don’t think I’ve gotten past the first few pages. Go figure.

Tell us the story of how you came to learn Rails:

I had heard of it and dabbled a bit in early 2005, but it wasn’t until I ran into Marcus Estes and the Tables Turned folks that I found a goal to inspire me to build some real apps. For me, having a real project to work on is the best way to learn things, and working with other people who have innovative ideas provided the motivation to dig into the API docs and learn Ruby’s tricks.

What keeps me interested in Rails is how much better it fits my projects than PHP or Java. PHP is great for tiny apps — like building brochure sites that need common headers and footers and maybe a little “special sauce” to make it interactive and interesting. Java is great if you have to deal with existing infrastructure and enterprise systems that are expected to be stable and available for decades. My projects are usually somewhere in the middle, and Rails suits them perfectly.

Three Ruby bloggers to whom you’re passing the baton:

I’m going to chuck this over the fence to Jeremy Voorhis, Geoff Grosenbach, and Aaron Johnson (he said he needed an excuse to start blogging, so here it is!).

FOSCON II, Ahoy!

July 26, 2006

I guess it’s a little late to mention it, but in three hours FOSCON II kicks off at Free Geek, in Portland, Oregon. It’s a veritable Ruby geekfest organized by the Portland Ruby Brigade (PDX.rb) … and I will surely be there to enjoy the revelry and Hot Lips Pizza.

Update:  The event went very well!  Free Geek was packed to the gills with an enthusiastic crowd, and the presentations were educational, funny, and inspiring.  Next year we’re gonna need more space.  I’ll post some writeups over the next few days for those of you who couldn’t make it!

Where’s the Glue?

July 26, 2006

Perhaps I’m out of the loop on this one, but I’ve found an odd gap between edge Rails and the simply_restful plugin. Here’s what’s up:

The Controller


ShoesController < ApplicationController
  ...
  def show
    @shoe = Shoe.find @params[:id]
  end
  ...
end

The Views


app/shoes/show.rhtml
         /show.rxml
         /show.rjs

My Expectation

When I GET /shoes/1.xml I get the XML format via the show.rxml file, and when I GET /shoes/1.html I get the HTML format via the show.rhtml file — afterall, the format is specified in the request, and passed through as @params[:format].

Unfortunately, I don’t have deep knowledge of the internal Rails code (yet!), so I kludged together a quick workaround that automatically determines format-based views.

The Workaround


def render_formatted
  @params[:format] ||= "html"  # Default format
  # build the preferred template path
  template = "#{RAILS_ROOT}/app/views/#{@params[:controller]}/#{@params[:action]}.r#{@params[:format]}"
  if File.exist? template
    render :file => template
  else
    render :text => "'#{@params[:format]}' format not available for '#{@request.path}'", :status => 404
  end
end

In practice, #render_formatted would be called at the end of any given action to provide the appropriate response. Know a better way to do this? Any feedback would be appreciated, especially if I’m missing a vital link in the clue train …

Thanks!

Indirect Fraud

July 24, 2006

Ahh, credit card fraud. How I detest thee.

Fraud is a fact of life for retail businesses, and e-commerce shops are particularly hard hit, particularly those who sell internationally. Direct fraud is certainly the most common: some jerk places an order with someone else’s credit card in an attempt to get their hands on your products. Pretty straight forward.

Indirect transactions, on the other hand, are a bit more troubling.

The Scam

The Jerk sells a product to The Buyer on a legit site, like eBay or Craigslist. However, The Jerk doesn’t have the product!

So, The Jerk buys the product from your web site. Using fake or stolen credit card info, The Jerk uses The Buyer’s personal information to place the order on your site. You ship the product to The Buyer.

The Result

The Jerk pockets the cash from the first transaction.

The Buyer receives the product, and thinks everything is perfectly legit: he received the product he bought, and paid the expected amount for it.

You’ve been scammed, and you’re in the awkward situation of attempting to reclaim your products from someone who thinks they were legitimately purchased.

Protection

The easiest way to prevent getting involved is to fully check each of your credit card transactions: make sure the information is valid. Use CVV verification. Take the credit card transaction off line to make sure it’s seen by a human before it’s processed. Call the customer when addresses don’t match.

However, there’s only so much credit card verification can do for you: here are two things that can significantly improve your ability to spot bad transactions:

  1. Save the IP address the order came from, and use a geolocation service to find out the approximate location of the customer. Raise a red flag if the billing and shipping address for the order are in Billings, Montana … but the order was placed from Singapore. A limited, but free, geolocation service is provided by IP2Location.com
  2. Include a note at the top of the packing list that says something along the lines of: “If you did not buy this product directly from xxxxxxxx, please call us at xxx-xxx-xxxx to verify the authenticity of your purchase.” Even if everything else checks out, savvy consumers appreciate the ability to inform you of anything suspicious.

According to Aaron Biddar, president of Control Scan, 40% of e-commerce sites comply with MasterCard’s standards for data protection — and he considers that number optimistic. (http://www.ecommercetimes.com/story/51756.html)

Most store owners aren’t aware that there are established standards for protecting customers, but they all know it’s important. Getting hacked or inadvertently leaking customer data is almost always the end of an online shop — not only do customers loose trust, but the business risks having their ability to process credit cards revoked.

With the risks so high, why is compliance so low? Three big reasons:

  • Lack of awareness. The standards are typically not emphasized or included in merchant account contracts, compliance audits are practically unheard of, and standards generally aren’t brought to the attention of business owners until after something has gone wrong.
  • Too many standards. Visa has a standard. MasterCard has a standard. American Express and Discover have standards. There are government privacy and accounting standards (HIPAA, Sarbanes-Oxley). There are even standards that are combinations of different standards.
  • High learning curve. Data security is a highly technical issue. The typical business owner doesn’t understand firewalls, encryption standards, or application security, and neither do their customers. It’s simply not possible to educate everyone about every aspect of security.

Where To Start?

The best first step to securing an e-commerce shop is to put someone in charge of security, preferably someone on staff who has some technical knowledge of how your site works and how it’s hosted. The person should also have a good rapport with staff who interact with your website and customers. It’s important to make this an official role in your business, rather than an afterthought looked after by whomever has a spare moment.

Download, print, and keep handy a copy of the Payment Card Industry Data Security Standard (PCI-DSS) — the closest thing there is to an industry standard, and the most likely to be enforced by Visa and MasterCard. Although the PCI-DSS is fairly technical, it’s important for your security person to understand the essential components and concepts. If they don’t, it’s worth while to contract a third party to help them through the learning curve, and assist with issues specific to your web site. Finding the right person is worth writing another article about — in the meantime, feel free to ask me questions.

Talk with your vendors. The PCI-DSS has requirements that may not be possible to meet — limitations imposed by your e-commerce platform, hosting company, or other third party vendors may make it impossible to know whether or not you can actually meet the criteria of the PCI-DSS. Savvy vendors should be able to offer solutions and advice to help you gain compliance, and those who know nothing about PCI-DSS should become aware of the issues it raises.

What’s Next?

The consortium behind the PCI-DSS is revising the standard in the next few months, based on feedback from vendors. The changes aren’t expected to be particularly radical, and the core principals still apply, so the current PCI-DSS is still a very good guide to protecting customer data.

I’ll post an update when those changes are published.

Are You Experienced?

I’m interested in hearing from people and vendors who have experience helping e-commerce sites become PCI-DSS compliant — I work with a lot of e-commerce shops, and I’m always looking for vendors to refer clients to. Thanks!

Are You Subscribed?

July 14, 2006

Just a quick note — if you use an feed (RSS/Atom) reader for my site, I highly recommend using my FeedBurner feed. It splices in my del.icio.us bookmarks and Flickr photos, and it gives me more information about what people are reading so that I can write better articles.

Unfortunately, I can’t change the default feed on my site to use FeedBurner, so you’ll have to subscribe manually at:

http://feeds.feedburner.com/peat

Easy!

Also, if you’re just interested in my articles, book reviews, and links about e-commerce, take a look at the e-commerce newsletter.

Quote of the Week

July 13, 2006

“English is a brawling, promiscuous drunkard of a language made up of mispronounced and stolen words from other languages, and that’s what makes it such a glory to speak.”

— Cory Doctorow, from “English Mistakes That Aren’t Mistakes”

Update: 12 people found my site this weekend by searching for “brawling, promiscuous drunkard” on Google. Excellent!