Two weeks ago when I was in Las Vegas attending CES (The Consumer Electronics Show) with a good friend of mine from Evident Productions, we came up with idea for a blog series. So over the next month or two I will be blogging about my experiences at the show from a little point of view than many blogs you may find that have talked about CES.

I will be doing this series as a multi-part series that focuses on design, quality and production side of the entire trade show experience rather than focusing on the products that were presented at the show.

That’s about it for now! Hope you’re having a great day where you are!

It’s been a long time since I printed a web page (partially because I’m cheap and don’t like changing ink jet cartridges). However, printing a page doesn’t have to be a pain if the designer took a little extra time and made a “print.css” stylesheet. Print.css when applied correctly can make a web page easy to read and ink efficient.

Let’s take for instance the 26AM blog which you’re reading right now. We’ve created a print.css file that does the following:

• Changes the background to white
• Uses Arial, Helvetica, Sans-Serif fonts
• Removes all menus, the search bar, sidebar, header images
• Adds print friendly titles and headers
• Adds copyright information and the date/time stamp.

The first step is instructing the browser to use Print.css when a person chooses to print the document. We added the following line to our HEAD tag.

<link rel="stylesheet" href="http://www.26am.com/wp-content/themes/26AM/print.css" type="text/css" media="print" />

Of course for your purposes, you’ll want to set the HREF to your newly created print.css file. The second step is filling in the Print.css file. Ours looks like this:

/* 26AM Print Styles */
@media print {
	body {
		font-family: arial;
		font-size: 11pt;
	}
 
	#header {
		display: none;
	}
 
	a, a:visited, a:active {
		color: #09C;
	}
 
	#printheader {
		display: block;
		background: #29ABE2;
		padding: 10px;
		margin: 1em 0 1em;
	}
 
	#printfooter {
	font-size: 10pt;
	color: #666;
	border-top: 1px solid gray;
	margin: 2em 0 0;
	padding: 1em 0;
	}
 
 	.breadcrumb {
		font-size: 9pt;
		margin: 0 0 1em;
	}
 
	img.authoravatar {
		display: none;
	}
 
	a.stbutton,
	h2.pagetitle,
	p.postmetadata,
	.respond,
	#respond,
	#sidebar,
	#footer {
		display: none;
	}
}

You’ll see that the majority of what we’ve done is hide things. You’ll also see that we are revealing things as well. We’ve hidden all the unnecessary information that we mentioned above, but then we revealed the printer friendly formatted information such as date and time stamp. Hope this has helped. If you’re working on a project for a client or for yourself, having a printer friendly version of the website can really show your attention to detail and care for the end user. Leave us a note and let us know if this has helped you.

If you’re a Ruby developer (and especially Rails) we’ve all been told REST > SOAP. REST is lightweight, simple, etc. So of course we’ll use REST! So I dug in and implemented the Outbound Use Cases for creating a fulfillment order, checking the service status, and canceling an order. And for months it worked fine. Then one day something changed. I’m still not quite sure what changed, but I started getting back 400 Bad Request responses from Amazon. That was it. No details, no explanations, no clue as to what went wrong, just 400 Bad Request. So after wasting way too much time trying to figure out what wasn’t working (with very little help from Aamzon), I decided it was time to throw in the towel and switch to SOAP. SOAP is by nature more verbose. So I figured that even if the problem was on my end, with SOAP I’d get back more useful error messages in the responses. I was right.

So you’re going to do SOAP in ruby, the natural, default option is soap4r. I’ve used soap4r before, and in the past it had done exactly what I needed. Unfortunately, the simplicity of soap4r caused me nothing but pain when trying to work with the FWS SOAP API. Amazon wants (needs) an <evn:Header> in your soap envelope containing 3 pieces of information: Access Key, Timestamp, and Signature. I know that soap4r supports adding extra headers, but it’s really clumsy. So after an hour or so of getting it wrong with soap4r, I decided it was time to look for an alternative.

Enter handsoap! Handsoap does less for you, *a lot less*, but that also means it’s way more flexible. Flexibility is what I needed. In less than 2 hours from finding handsoap, I had a working SOAP client for the call I cared the most about (creating an order), with nice tests to go with it! Enough babbling, time for some code samples:

I’ll be repeating some of what is in the handsoap getting started guide, but you’ll appreciate having it all in one place. (Do yourself a favor and still read through the handsoap getting started guide).

First create config/initializers/amazon_fulfillment_service.rb with the service endpoint:

# wsdl: https://fba-outbound.amazonaws.com/doc/2007-08-02/AmazonFBAOutbound.wsdl
AMAZON_FBA_OUTBOUND_SERVICE_ENDPOINT = {
  :uri => 'https://fba-outbound.amazonaws.com',
  :version => 1
}

Next, run the generator to create the stubs:

./script/generate handsoap https://fba-outbound.amazonaws.com/doc/2007-08-02/AmazonFBAOutbound.wsdl


Open the file created (probably app/models/amazon_fba_outbound_service.rb)

You’ll want to add your AWSAccessKeyId to the header for all calls:

def on_create_document(doc)
  # register namespaces for the request
  doc.alias 'aws', 'http://fba-outbound.amazonaws.com/doc/2007-08-02/'
  header = doc.find("Header")
  header.add "aws:AWSAccessKeyId", FWS_CONFIG[:access_key_id] do |s|
    s.set_attr "env:mustUnderstand", "0"
    s.set_attr "env:actor", "http://schemas.xmlsoap.org/soap/actor/next"
    s.set_attr "xmlns:aws", "http://security.amazonaws.com/doc/2007-01-01/"
  end
end

Next let’s look at the simplest of calls: get_service_status

def get_service_status
  response = invoke('aws:GetServiceStatus') do |message|
    build_headers(message.document, 'GetServiceStatus')
  end
  response.http_response.status
end

Returning response.http_response.status makes the method easy to test (just look for 200). The interesting part of that call is the build_headers method. We need to add the Timestamp and Signature to the Header on a per-call basis. Here’s that method:

def build_headers(doc, action, timestamp = nil)
  @timestamp ||= Time.now.utc.strftime("%Y-%m-%dT%H:%M:%S") + '.000Z'
  @signature = FwsHelper.aws_encoded(action + @timestamp)
  header = doc.find("Header")
  # Add signature
  header.add "aws:Signature", @signature do |s|
    s.set_attr "env:mustUnderstand", "0"
    s.set_attr "env:actor", "http://schemas.xmlsoap.org/soap/actor/next"
    s.set_attr "xmlns:aws", "http://security.amazonaws.com/doc/2007-01-01/"
  end
  # Add timestamp
  header.add "aws:Timestamp", @timestamp do |s|
    s.set_attr "env:mustUnderstand", "0"
    s.set_attr "env:actor", "http://schemas.xmlsoap.org/soap/actor/next"
    s.set_attr "xmlns:aws", "http://security.amazonaws.com/doc/2007-01-01/"
  end
end

The signature is built by concatenating the action + timestamp, then creating an HMAC-SHA1 digest of it. Here’s my

FwsHelper.aws_encoded

method:

require 'base64'
require 'digest/sha1'
 
class FwsHelper
 
  def self.aws_encoded(string)
    digest   = OpenSSL::Digest::Digest.new('sha1')
    b64_hmac = Base64.encode64(OpenSSL::HMAC.digest(digest, FWS_CONFIG[:secret_access_key], string)).strip
  end
 
end

That should be enough code to get you moving. If I missed something, or you’d like more elaboration on something, tell us about it in the comments and I’ll update the post.

• Showcasing our clients and the work we’ve performed for them
• Providing information about our services
• A simple quotation form
• Updated blog design to display our thoughts and musings
• Twitter feed in a more organized fashion
• Prettier more functional design.

Here’s what we came up with so far. Look for it soon live on our site!

With that you’ll need to also create a new attribute for your products. Do this by going to:

1. Catalog -> Attributes -> Manage Attributes
2. Add New Attribute
3. Set your attribute code to: “condition”
4. Set the “Catalog Input Type for Store Owner” to “Dropdown”
5. Next, set “Values Required” to “Yes”
6. Leave the rest, as is on this page
7. Go to the Manage Label/Options page
8. Label your titles as “Condition”
9. Choose “Add Options”
10. Place the value of “New” in all fields and select “Is Default”
11. Save Attribute and return to editing your products. Be sure to set all products to the condition of “New”

This is a key step in getting Magento to work with Google Base. If you don’t map the condition, you will come across the error “Google Base – Expected response code 200, got 400″

Drop me a line if this helps! This was tested on Magento ver. 1.3.2.3.

In Safari for Windows you have a choice. You can use native Windows ClearType rendering for fontsor you can use OSX anti-aliasing. Turning it on and off is simple:

Take your pick, it’s easy! Just go to Safari Preferences, choose the “Appearance” menu and set Font smoothing to whatever you fancy! It’s that easy!

Software list:

• Apple OS X
• Windows Vista
• Adobe CS4 Master Collection
• Textmate
• Ultra Edit
• Adium/Pidgin
• Skype
• Smart FTP
• Fetch
• Putty
• GIT

Hardware list:

• Mac Pro (Quad Core with 8GB of RAM)
• Macbook Pro (Dual Core with 4GB of RAM)
• HP Workstation (Quad Core with 4GB of RAM)
• HP Elitebook (Dual Core with 4GB of RAM)
• Mac Mini (Coming soon to the family)
• 3 VPS Servers (Slice)
• 1 Grid Server (MediaTemple)
• Amazon WS, S3, EC2
• HP, Viewsonic, Dell and Asus Monitors
• Wacom Tablets

There you have it. That’s our weapon list.

Your friends at 26AM,
David and Josh