1. Download some free Patterns from Squid Fingers

Squidfinger’s pattern library is a famous site for designers. We started by downloading a pattern and unzipping it somewhere on our harddrive. With over 150 patterns, you can spend a fair amount of time finding just the right one.

2. Defining the pattern for Photoshop

After you’ve got the Pattern downloaded and unzipped, just open up the file in Photoshop. We’re using CS5.5 and CS4, any further back than that, you’ll have to do a little Googling around. Once you’ve got it opened head up to the Edit menu and choose Define Pattern… Enter some nifty name that’ll help you remember the pattern name.

3. Using the Pattern

Now that the pattern is defined, we’re gonna put it into motion. Create a new blank layer. Then choose your fill/paintbucket tool. From the options menu at top switch from Foreground to Pattern. You’ll notice the box next to this drop down showing a thumbnail of some pattern. Click the pattern and find your newly defined pattern. Now simply use the fill or paintbucket tool to fill up your layer.

4. Fitting it into your context

We put our new layer that we filled with the pattern on top of another layer that had a solid color. We then went to the pattern layer and used a Multiply Blend Mode. This gave us the color we wanted. With a little bit of Opacity adjustment, we were happy with the final result. Here’s a screenshot of what we came up with. Leave us a comment and show us what you come up with.

1. Standard WordPress Site
2. Buddypress native functionality
3. Sitewide bbPress

I had to look through quite a few posts in the various forums out there as well as some of my own trial and error. I started with a standard WordPress 3.3 installation. The next thing I did was install and activate BuddyPress 1.5.2. I installed leaving all the default check boxes checked and opting to use the BuddyPress Default theme. After a basic click around on the front-end of the site to make sure nothing obvious had broken, I headed over to the “Forums” tab inside the BuddyPress Menu. Which at this point looked like this: (/wp-admin/admin.php?page=bb-forums-setup)

Next thing I did was click the “Install Site Wide Forums” link on the right. This just popped the plugin page for bbPress 2.02 I installed and activated using all the standard recommended settings for bbPress. Following activation I headed to the “Settings > Forums” menu and proceeded to change one slug.

After saving the settings, I headed over to www.mywebsite.com/f/ to checkout my forum installation. I went ahead and posted my first topic into a forum I’d created and found it all working as expected. I went back to the admin and checked out the BuddyPress > Forums tab once again and found it looking just like it did before I installed bbPress. This threw me! I was expecting a “bbPress is installed and working” message or something to indicate that I’d installed it. This might be a good future change for the BuddyPress or bbPress dev teams to consider in the future.

The next thing I wanted to test was the activity stream to make sure my posts would in fact show up in the stream.

This is what I found, my post in the stream working perfectly!

Some Notes:

So what I documented here was on a fresh clean install of WordPress. I followed the same methods on an existing site and actually had some trouble. I was able to fix the problem by installing the group forums after bbPress, then going back and uninstalling the group forums. Something somewhere in there was needed and the install uninstall seemed to fix it. Hope this helps!

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