I want my logo to be more prominent

by Jess Brown

I try not to rant too much, but I'm going to let a little one loose.

I can't tell you how many times I've heard I think my logo needs to be a little more prominent or I'd like my logo to be more noticible or our logo should be larger.

Why?

When have you gone to a doctor's office and felt better after seeing a logo? When have you gone to a restaurant and been better served or had your appetite satisfied after noticing the logo on the menu? Do you donate to one charity over another because they have a cool logo? If you walk into a bank to get information on a loan, do you want to hear about the bank or about the how they can help you with a loan?

While it may stroke your ego, a large logo won't increase your sales. Left too large, it can actually waste valuable selling space. Logos and brand identity are important, but making your logo larger isn't going to magically increase your brand awareness. People come to your site to find information relevant to them. Can you help them solve a problem, make something more enjoyable, save them money? Your visitor wants to know what you can do for them. Your logo is probably not going to be able to tell them this.

If I roll back the covers on my rant, I think my issue is with more than just a logo's size. It's about clear communication, focused intention, and actionable requests. It's about putting people first and really digging deep on what makes you (or your company ) unique and valuable.

Finishing my thoughts on on logo size

I wanted to see if I was alone in my thinking, so I did this web search:

how big should my logo be on my website

The first article is basically taking my stance and offers a few nice stats on logo sizes:

  • Nordstrom (191 x 24)
  • McDonalds (113 x 98)
  • Starbucks (84 x 84)
  • Wall Street Journal (362 x 30)
  • Nick Jr. (219 x 58)
  • Verizon (118 x66)

These are small

What do you think? Any ideas or rules of thumb for logo size on a website?

Screen Capture Your Whole Website

by Jess Brown

One of my clients recently needed to copyright their website. After speaking with their lawyers, I learned they needed all the source code, images, a list of technologies we didn't create (gems, frameworks, etc) and a screen shot of every page on the site.

The first requirements were easily obtained. I downloaded the github repo for the source code and images. I took the Gemfile and bower.json file and created a list of technologies that we didn't create. But, the screen capture thing was a bit of a quandary. The site has over 500 pages and capturing a full page screen shot(scroll and all) is a tedious task.

Then I remembered reading about a gem called capybara-screenshot and started tinkering with a short little program to take a screen shot of all the pages on the site. This is what I came up with:


require 'pry'
require 'capybara'
require 'capybara/dsl'
require 'capybara-screenshot'

Capybara.default_driver = :selenium
Capybara.app_host = 'http://www.example.com'
Capybara.save_and_open_page_path = "screenshots"

class Screenshot
  include Capybara::DSL

  def initialize(urls)
    @urls = urls
  end

  def crawl_and_snap
    @urls.each do |url|
      snap url
    end
  end

  def snap(path)
    visit path
    Capybara::Screenshot::Saver.new(
                  Capybara, 
                  Capybara.page, 
                  false, 
                  image_name(path)).save
  end

  def image_name(path)
    path.gsub("/", "-")
  end
end

It wasn't that difficult, but I hit several small snags along the way...

Getting Capybara to work outside of rails or rack

I love Capybara and use it in almost every rails app I work on. However, I've never used it outside of rails. At first I just tried to setup a regular _spec file and run it, but I guess because the file wasn't located in features it wasn't expecting to use Capybara. So I found that you can simply use the Capybara::DSL module and get all of the methods we want (visit, find, etc).

Taking the screen shot

Capybara::Screenshot is a simple little tool to use. Normally you'd just call screenshot_and_save_page which I did at first, but it gives you a file name like Screenshot-2014-07-28.png. I wanted the filenames to be equivalent to the web uri (ie /about should be saved as about.png). I didn't see a way to pass a filename to the screenshot_and_save_page method, so after digging in the source, I saw that that method just calls Capybara::Screenshot::Saver.new and then calls save on that. It took 4 arguments. The first two were related to the capybara visit. The third was whether to also save an html file and the fourth the filename. Notice there's also a config you can set for the default directory to save the images.

Web Driver

I wanted to use something other than Selenium so Firefox wasn't running, but I tried webkit and PhantomJS and both worked, but had several issues like missing images and default width of the page (caused my responsive site to hit a breakpoint). And the resulting image with the Selenium driver was super crisp.

Urls to Capture

I didn't really have a problem getting all of the urls we needed to crawl. I use the great sitemap_generator gem to create an xml sitemap for the site, so it was easy to get an output of all the urls for the site.

A couple of other ideas if you don't have a list of all the urls:

1) Use a crawler like wombat or anemone to crawl your site, get a path and then use the Screenshot class to snap it.

2) If you're satisified that google has all of your pages indexed, then you could use the google-search gem to fetch all of the pages in their index, get the urls and pass them to Screenshot. Example:

search = Google::Search::Web.new do |search|
    search.query = "site:www.example.com"
    search.size = :large
  end
urls = search.all.map(&:uri)
Screenshot.new(urls).crawl_and_snap

Example

I blocked out my clients name and downsized it, but you can see how it does a nice job of capturing the whole page.

I was thinking about creating a small gem out of it. What do you think, would it be useful?

Ruby Scripting

by Jess Brown

As a rails developer, I spend a majority of my time in rails. This is fine, because I love rails, but it's nice to write something outside of rails from time to time...in particular, a ruby script.

Stripe Transfer

My client was recently acquired and needed to migrate their stripe account to another stripe account. Stripe will handle transferring customers and cards, but it's up to you to transfer the rest. The client's app was a SaaS app and heavily made use of subscriptions. The account had thousands of subscriptions that needed to be ported over to the new account.

Using the Stripe gem and the api, I was able to transfer them over without much trouble.


require 'stripe'
require 'pry-debugger'

MODE = :live

def old_stripe_key
  # live
  # key = "xxx"
  # test
  key = "xxx"
  key
end

def new_stripe_key
  # live
  # key = "xxx"
  # test
  key = "xxx"
  key
end

def old_customers
  Stripe::Customer.all({limit: 10}, old_stripe_key)
end

def new_customers
  Stripe::Customer.all({ limit: 100 }, new_stripe_key)
end

def migrate(customers)
  puts "The End" && return if customers.data.empty?
  puts customers.data.count
  sync_customers(customers.data)
  migrate(Stripe::Customer.all({ limit: 100, starting_after: customers.data.last.id }, old_stripe_key))
end

def sync_customers(customers)
  customers.each do |customer|
    File.open('sync.log', 'a') { |file| file.write("\n#{customer.id} ") }
    puts customer.id
    subscriptions = customer.subscriptions
    if subscriptions.data.any?
      subscriptions.data.each do |subscription|
        File.open('sync.log', 'a') { |file| file.write("#{subscription.id}") }
        puts subscription.id
        plan_id = subscription.plan.id
        current_period_end = subscription.current_period_end
        if MODE == :test
          new_customer = Stripe::Customer.create(
            { :description => "clone #{customer.id}" },
            new_stripe_key
          )
        else
          new_customer = Stripe::Customer.retrieve(customer.id, new_stripe_key)
        end
        unless new_customer.subscriptions.data.map(&:id).include?(subscription.id)
          new_customer.subscriptions.create(:plan => plan_id, :billing_cycle_anchor => current_period_end, :prorate => false)
          subscription.delete unless MODE == :test
        end
      end
    end
  end
end

def print_active_subscriptions(customers)
  puts "The End" && return if customers.data.empty?
  puts customers.data.count
  active_subscriptions_for(customers.data)
  print_active_subscriptions(Stripe::Customer.all({ limit: 100, starting_after: customers.data.last.id }, customers.api_key))
end

def active_subscriptions_for(customers)
  customers.each do |customer|
    subscriptions = customer.subscriptions
    if subscriptions.data.any?
      subscriptions.data.each do |subscription|
        puts "#{customer.id} #{subscription.id}"
      end
    end
  end
end

As you can see it's a crude but straightforward script. We didn't have a lot of time to implement it so I just hashed it out rather procedurally.

A couple of the challenges were:

1. How to jump back and forth from the old stripe account and new account

Typically you see api gems do something like 

  connection = API::Connection.new(:api_key => 'xxx')
  # Then
  connection.customers.all

But I didn't see how to get this type of instance with the stripe api. However, Stripe has great support and Brian Collins helped me out with how to pass the api_key. It's the last argument in the constructor, which means if you're passing options like in the all method, you have to wrap those options in {}.

2. How to run a test on non-live data

Stripe gives you a great testing environment, but for our scenario (we would have customers in both accounts with identical ID's) we couldn't mimic the live setup(you cannot specify ID's when creating customers). So while in test mode, what I chose to do was just clone the customer instead of finding them in the new account. And by passing in the old customer id to the description, I could easily locate the new customer to compare subscriptions.

if MODE == :test
  new_customer = Stripe::Customer.create(
      { :description => "clone #{customer.id}" },
      new_stripe_key
    )
else
  new_customer = Stripe::Customer.retrieve(customer.id, new_stripe_key)
end

3. Setting up the subscription

First off, we had to recreate our plans with the same id in the new account. Typically this won't be a problem to manually do, because you'll likely only have a handful of plans. Just make sure to get the exact id and price (unless you're changing prices). Next we want to make sure the customer doesn't see a change in their billing. If they were billed on the 7th of last month, then their next billing should be the 7th. Also Stripe will automatically prorate a subscription, so you don't want that to happen (because their already paid for the whole period on their last billing). The solution was pretty easy:

  new_customer.subscriptions.create(
                        :plan => plan_id, 
                        :billing_cycle_anchor => current_period_end, 
                        :prorate => false)

Set prorate to false and the billing_cycle_anchor to the date of current_period_end of the old subscription, and the plan to the plan_id of the old subscription.

Summary

It seemed to work well. When we first ran the script on the live data, we only did a few:

pry> customers = old_customers.data[13..14]
pry> sync_customers customers

That's when we discovered we had a setting in Stripe of notify the customer if a subscription was canceled. Oops! Glad we caught that before running it on thousands of customers.

Also you can see that there are two methods at the end to print out all of the active subscriptions. We used this in a before and after snapshot to make sure our numbers added up.

The script could probably be written a little more ruby like but for a quick job, it worked out OK.

What do you think? How would you have done it?

Stripe HowTo

Fear and Intimidation

by Jess Brown

This week I started working on a new project. Like all projects, especially existing ones, it can be a little overwhelming in the beginning.

The emotional side of the brain...

Some projects I'm even intimidated. This new project was one that I was particularly impressed with. It was using a lot of newer technologies I had not used (luckily I was mostly aware enough to know 'of' them). It had tons of models, used all kinds of services, a new database I actually hadn't heard of, multiple API's I had never used, etc, etc.

When I get on projects like this, thoughts creep in to my head, "the previous developers are way more advanced that I am...what if I can't make it work, my client will think I'm not qualified when it takes me forever to figure things out." The list goes on.

The logical side??

However, when I think back to projects that have come up like this in the past, I look back and remember how much fun they were to "figure out". I see how much I learned and developed as a programmer. I say to myself, "you know, I always figure things out"...there's never been a time when I just gave up and couldn't complete a job.

Also I'm not sure why I do this (and I'm hope I'm not the only one), but I put too much pressure on myself and expect to be able to just look at github repo and know exactly how it all works. I'm supposed to within a few hours of tinkering, figure out what took other developers years to build. Why do we do that? If start a new book, I don't expect to know what happens at the end. It takes time to become familiar with the business logic, the stories, flow, the methods the previous developers used, etc. The tests and code should tell a story, but you have to read the story to understand it and make contributions to it.

So I conclude...

A programmer's job is to solve problems and figure things out. That doesn't mean you're not going to feel overwhelmed and intimidated at times. If you don't, you're probably not challenging yourself enough. I encourage you like I encourage myself, embrace the challenge, be thankful for the opportunity to level up and remember, you're a hacker, you'll figure it out!

Expectations

by Jess Brown

Expectations are tricky. Maybe because they're relative and hard to guess for other people.

Recently my family and I headed off for our annual summer vacation. You'll probably agree with me that check in times for rentals are getting absurd. Check ins used to be around 1-2p, but then moved to 3, then 4 and this year our check in was at 5p! The day is nearly over.

However, many times, especially when dealing with private owners, you can request and get an early check in time. We'd done this the previous year with the same owner and were told our condo should be ready around 3p. Well, we arrived around 3:30 and the room wasn't ready. "Should be ready shortly, we'll send you a text." Shouldn't be long we expect, so we decided to head to the grocery and get some things we needed for the week. We got back around 4:30. Still no text. We call again. "Nope, still not ready, we'll send you a text." By this time, my 3 and 7 year old boys are going crazy after being up since 6a, driving in the car for 7hrs and expecting to be in the pool way before this. Our groceries are wasting away and we're hanging out in a parking deck for our vacation. 5:10p still no text (10 minutes after the check in time).

I was getting cranky myself and I began thinking about expectations. If we'd only known we couldn't get into the room until after 5, we could have planned to do something entertaining or just arrived later. Everything would have been cool and no one would be at the end of their rope.

Expecting one thing and getting something else sucks. It especially sucks when this happens repeatedly.

I think about this a lot in business. A business always wants to please it's customers, so they typically over promise and under deliver. A previous boss was an exception to this. He would tell customers if an order was placed by 1p it would be shipped the same day, but he told his staff that orders placed by 4p should be shipped the same day. His motto was under promise and over deliver.

That's what I strive for in consulting. It's so easy and enticing to tell a customer you'll have their work done for them by next week when in reality it's going to be longer. It's really difficult to get it right and I've messed it up plenty. For one, it's really hard to know when you'll have the time to work on something. Development work is never turnkey. There are always customizations and different a implementation for every business scenario. Secondly, you don't want to seem slow and want to please the customer, so you see the shortest possible path from start to finish.

But, I always go back to my vacation and think, if they'd just told us it'd be a little after 5 until we could get in, we would have been much happier because we got what we expected.

Over the last couple of years, I've gotten better about under promising and over delivering. I'm sure I still miss my client's expectations at times, but I hope to continue to improve the experience daily.

Navigation