Ben Scheirman

These fickle bits...

Menu

Formatting JSON From Terminal

I work with JSON APIs a lot. On a current API I work on, there is an OAuth-esque request signing process that is required to make sure that others cannot forge requests simply by changing parameters arround.

A typical request might look like this:

1
2
3
4
5
6
7
8
9
HTTP 1.1
GET /foo/bars.json

Headers:
    Accept-Encoding = gzip;
    Accept = application/json
    Authorization = "cHOLIOb7bAeqFEmsz3io%2Bxg4sQA%3D";
    Account-Id = 201;
    User-Agent = "...";

The Authorization header is generated by concatenating the HTTP Method, URL, any parameters, and then signed with a key.

Because of this security, it is very difficult to create adhoc requests just to try them out. So instead, we have our iPhone app NSLog the proper curl command for us. Now it’s as simple as copy & paste from the Xcode Console, which gives me a less-than-readable output of the JSON.

Usually for this I just pipe the command into pbcopy to get it on my clipboard, then I visit JSON Lint to make it easy to read.

Doin’ it all from Terminal

I looked at ways of doing this all from the Terminal, and came across this python command:

1
python -mjson.tool

It takes input from stdin and outputs it formatted nicely. Sweet! Now all that’s needed is to make this a bit more easy to remember, so I made a script to do this for me called format_json and put it in my path.

Now, any time I want to see the JSON output of an API, I can simply type:

1
2
$ curl some.server.com/api/devices.json?key=124512312 -H Authorization:"124151231231123123" |
    format_json

And here is the output:

1
2
3
4
5
6
7
8
9
10
11
12
{
  "devices": [
      {
          "device_id": "40f4fc8a5818608dbb9a6c981179222b6f",
          "device_type": "iPhone",
          "id": 24,
          "name": "Ben's iPhone",
          "push_enabled": true,
          "push_token": "a3a36......480c25fdf"
      }
  ]
}

Very handy, indeed.

Houston Tech Fest 2011 Recap

Houston Tech Fest 2011 came and went, and yet again was a great success. I believe it was the biggest one ever, with over 1,300 registrants.

I gave three talks:

You can find the slides & code used in the presentations here on github.

If you attended any of these sessions, I’d really appreciate if you rate them using the links above.

See you next year, Houston Tech Fest!

Appsites Is Now AppKickstand

A few weeks ago I launched Appsites, a free way to quickly host an attractive splash page for iPhone applications.

Instead of competing with another site with the same name for traffic when we could be sharing it, I decided a new name was in order.

I now present to you: AppKickstand.

AppKickstand

For an example of what it looks like with real apps, check out Giggle Touch or Tally Things.

If you have an iPhone app, what are you waiting for? It’s FREE!

Sharing Vim Configuration Between Machines

I do most of my development on my MacBook Pro, however I have a nice 27” iMac at home, and it is refreshing to use it for development when I can. It’s fast and has a huge screen. The only downside is all my custom development configurations are on my MacBook Pro!

There are a number of options you can use to share settings between machines, but I’m a fan of using Dropbox (referral link). Any change I make, on either machine, will get automatically synchronized for me.

Since my Vim configurations were already present on my MacBook Pro, the first step was to copy them over to a Dropbox folder:

1
2
3
4
5
mkdir ~/Dropbox/vim
cp -R ~/.vim ~/Dropbox/vim
cp ~/.vimrc ~/Dropbox/vim
cp ~/.vimrc.local ~/Dropbox/vim
cp ~/.gvimrc ~/Dropbox/vim

The next step was to come up with an installer script that would symlink these files on a new machine. I made sure to move existing vim files to a temporary filename so that I wouldn’t lose anything accidentally.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
set -o errexit

function confirm()
{
    echo -n "$@ "
    read -e answer
    for response in y Y yes YES Yes Sure sure SURE OK ok Ok
    do
        if [ "_$answer" == "_$response" ]
        then
            return 0
        fi
    done

    # Any answer other than the list above is considerred a "no" answer
    return 1
}

function link_file()
{
  echo "symlinking $1"
  ln -s "$PWD/$1" "$HOME/$1"
}

echo "This will remove any existing vim configuration files and simlink them with the files here."
confirm "Are you sure?"
if [ $? -eq 0 ]
then
  for file in ~/.vimrc ~/.vimrc.local ~/.gvimrc
  do
    if [[ -f $file ]]; then
      echo "Moving $file to $file.bak"
      mv $file $file.bak
    fi
  done

  for dir in ~/.vim
  do
    if [[ -d $dir ]]; then
      echo "Moving $dir directory to $dir.bak"
      mv $dir $dir.bak
    fi
  done
fi

echo "symlinking"

for file in .vim .vimrc .vimrc.local .gvimrc
do
  link_file $file
done

echo "Done.  Check that it works.  If so, you can remove the .bak files, if any"

Make sure the script is executable by running:

1
chmod +x setup.sh

Then run this script on any new machine that you want to use Vim on. It will symlink these files from your Dropbox folder to your home folder:

  • .vim/
  • .vimrc
  • .vimrc.local
  • .gvimrc

After it’s done, check that it is working. Remove any .bak files that you don’t need anymore.

And that’s it. You have an automatic Vim configuration synching system between machines. It works great for your shell configuration as well!

Making a UIButton Flip Over

If you’ve used the iPod app on the iPhone, you’ve probably seen an interesting trick when switching from album art to the track listing: the button in the top right corner flips over synchronized with the flip animation of the main view.

I wanted to achieve a similar effect for the iPhone app that I’m building, Deli Radio (app store link).

If you’ve ever struggled with the flip transitions before, you probably know how finicky it can be to get it all working. The best way to set it up is to have a parent view contain both views that you want to swap, and set the animation transition type on that view.

For a button (either in the navigation bar or elsewhere) we’d need to introduce a parent view to achieve this effect. This is how I achieved the effect.

First, I had two images I wanted to use for my UIBarButtonItem.

I wanted this to be easily reusable (since I need to do this in more than one place in this application), so I created a category method on UIButton.

It may look strange that a UIButton class method returns a UIView instance, but we need to have a container view to base the animations off of.

Here is the implementation:

I am using a little-known technique of setting associated objects using objc_setAssociatedObject(...). This uses the runtime to attach state to an existing class without needing to subclass.

Now that you understand how it is all setup, the block body will now make sense:

Usage is really easy. I just created a bar button item with a custom view, and was done.

1
2
3
4
5
6
7
8
9
10
11
12
13
UIImage *firstImage  = [UIImage imageNamed:@"btn-info.png"];
UIImage *secondImage = [UIImage imageNamed:@"btn-images.png"];
UIView *container    = [UIButton flipButtonWithFirstImage:firstImage
                                              secondImage:secondImage
                                          firstTransition:UIViewAnimationTransitionFlipFromRight
                                         secondTransition:UIViewAnimationTransitionFlipFromLeft
                                           animationCurve:UIViewAnimationCurveEaseInOut
                                                 duration:0.8
                                                   target:self
                                                 selector:@selector(flipContent)];

self.navigationItem.rightBarButtonItem = [[[UIBarButtonItem alloc]
  initWithCustomView:container] autorelease];

The effect can be seen below.

Note that the flip effect on the main view is achieved separately, but the 2 strategies share identical values for the animation, so the flip transition types match, as well as the duration & animation curve.

The code for this can be seen in the ChaiOneUI project on Github.

Creating a Glow Effect for UILabel and UIButton

One recent iPhone design mockup called for a glowing effect for a UIButton.

This can be accomplished with images, however I needed a series of buttons to have the same glow effect, and it can easily be accomplished with Core Graphics.

The first step is to include the Core Graphics headers:

1
#import <QuartzCore/QuartzCore.h>

Next, the effect is achieved by using a shadow with no offset (meaning the shadow will be directly underneath the text, not shifted down or to the right). The layer is then given a shadow radius & opacity to allow the shadow to bleed outward. Unsetting masksToBounds will allow the glow to be drawn even outside of the label’s frame. Finally the shadow color is set to either the foreground color or something a bit lighter.

1
2
3
4
5
6
UIColor *color = button.currentTitleColor;
button.titleLabel.layer.shadowColor = [color CGColor];
button.titleLabel.layer.shadowRadius = 4.0f;
button.titleLabel.layer.shadowOpacity = .9;
button.titleLabel.layer.shadowOffset = CGSizeZero;
button.titleLabel.layer.masksToBounds = NO;

This effect works on plain UILabel or the titleLabel property of a UIButton. You can see the results of the effect here:

Don’t go overboard with this. It’s a subtle effect, but looks great when used effectively.

Introducing App Sites

I’ve not been that great about marketing Giggle Touch. It’s a cool app, kids like it, but most people don’t know about it.

The biggest reason was probably that I never set up a proper website for it. Doing a search would only yield a blog post that said it was “coming soon.”

That’s all changed now. I’d like to introduce App Sites.

App Sites

The premise is simple: standup a website for an iPhone app in minutes.

Check it out here: http://appsites.heroku.com.

You can see the site in action by visiting the Giggle Touch page.

It’s free (for now) and gives you the ability to add features, a description, a link back to the app, and a screenshot.

Planned upcoming features include:

  • Custom domains
  • Multiple screenshots
  • Videos
  • Coming soon (if the app hasn’t launched yet)
  • More analytics

If you have an iPhone app, I encourage you to create a page. Let me know what you think!

Firebug-Style Visual Debugging for iOS

Using a crazy helpful library called DC Introspect you’re able to easily take an app running in the Simulator:

And get visual frame debugging information like this:

You can also click & drag your mouse to get pixel information, surrounding frames, print out detailed frame information in the console, and even move frames around all while the app is running.

Using it is incredibly simple:

  • Make sure you have DEBUG defined in your Preprocessor Macros:

1
    #import "DCIntrospect.h"
1
2
3
4
5
6
7
// in applicationDidFinishLaunching:

[self.window makeKeyAndVisible];

#ifdef TARGET_IPHONE_SIMULATOR
    [[DCIntrospect sharedIntrospector] start];
#endif

Once that is done, the library will be loaded and you can use it. When the simulator launches, just press Spacebar to activate the tool.

Here are some keyboard shortcuts:

  • o – Outline all views
  • ? – Prints out a help view
  • f – Flash on drawRect: calls
  • c – Toggle showing coordinates
  • 4 6 8 2 – Nudge the selected view left, right, up, down
  • 0 – Recenter view where it was originally
  • 9 7 3 1 – Modify Width & Height of selected view

You can also click & drag with the mouse to get detailed information about frames & mouse position.

I am amazed at how awesome this library is. I’ll be using it in my default toolbox from now on.

Vim - Could Not Invoke JSLint

If you’re running MacVim with Janus and have upgraded to Lion, you may have noticed a little error when you open JavaScript files:

Error detected while processing function 87_JSLint: Line 33: could not invoke JSLint!

It seems many are having this issue. There are 2 things to check:

  1. Make sure you have Node in your path. Confirm this by typing which node and make sure it resolves a binary somewhere on your system.
  2. Open up your ~/.vimrc.local and add this command:
1
2
" Use Node.js for JavaScript interpretation
let $JS_CMD='node'

Kudos to eventualbuddha for figuring this out.

Is Rails Exempt?

If you’ve been following the Ruby community recently, you’d notice that there’s are people calling our Rails (and Rails developers) for treating Rails as if it is somehow exempt from long-standing software principles.

Roy Osherove, a fairly well-known .NET developer and author of The Art of Unit Testing, ventured into Ruby-land recently and commented on twitter about how Rails’s definition of unit & integration is quite different from his.

I have to agree with Roy. Those in the TDD camp in .NET understood the difference and were (from my experience) fairly cognizent of isolating concerns and not mixing the 2 concepts. Some even go as far as to isolate integration tests into their own assembly, providing a physical separation further guaranteeing that a unit test project won’t touch web services or the database.

It’s easy to assume from the outside that the Rails is just testing nirvana and that everyone does it and it’s so easy. Unfortunately it’s just not the truth. Rails (and Ruby) make testing really easy but that means it’s even easier to do the wrong thing as well.

Legacy Rails Apps

Now that Rails is (gasp) over 7 years old you’re starting to see some real legacy Rails applications out in the wild.

Avdi Grimm has a good post on the topic of how many of the Rails apps he comes to work on are in poor shape, technically.

Here are a few examples, just to give you an idea of what I’m talking about:

“Design Patterns are a Java thing. In Ruby you just write code.”

“The warnings Ruby produces are dumb; just disable them.”

“Sure they aren’t technically Unit Tests, but isolating objects turned out to be kind of hard and besides nobody else is doing it.”

“Stuff like the Law of Demeter isn’t really as important in Ruby code”

“That’s only a problem in large projects” (implying that this project will never become large).

I’ve certainly been guilty of some of this. Rails makes it easy to do things that can turn out to be problematic. As with anything, you have to be disciplined to notice the warning signs and act accordingly.

When testing is painful, you’re likely making mistakes. Some common pain-points that I’ve experienced are:

  • No tests – the app is hard to test because the design is poor. Classes are too tightly coupled and don’t have clear delineation of responsibilities.
  • Tests break for unrelated reasons – the tests are covering too much behavior, so when a single behavior changes, many tests break.
  • Tests break when implementation changes – the tests are probably utilizing too much mocking & stubbing. The tests are coupled heavily to a particular implementation.
  • Unclear what the problem is when a test breaks – Tests are probably too coarse-grained and may contain too many assertions per test.

These are just a sampling of what I’ve personally observed.

So why do many Rails developers ignore these concepts?

Pragmatism at work

Many rails tutorials (and the default Rails template) treats model tests as unit tests. Since Rails models are by default based on Active Record, they have data access baked into their core. Doing proper unit testing means you’re testing a logical unit. If your test involves a model operation that requires a database round-trip, that’s technically an integration test. But does it really matter?

Most Rails developers will tell you no. Consider this spec:

1
2
3
4
5
describe Post do
  it "should be initially unpublished" do
    Post.new.published.should == false
  end
end

This is a unit test. It tests a single piece of functionality and will fail for just one reason.

Now, here’s another example:

1
2
3
it "should fetch published articles" do
  # ?
end
1
2
3
4
5
6
# post.rb
class Post < ActiveRecord::Base
  def self.published
    where("published_at <= ?", Time.now)
  end
end

How should you implement this spec?

If you were trying to avoid hitting the database you might intercept the where call and assert the parameters passed to it. But surely this isn’t the only way you could implement this method giving the same behavior. You might use scopes or another where call might actually be added later that doesn’t affect the outcome of this method in any way that this test is concerned about.

1
2
3
4
5
6
7
it "should fetch published articles" do
  3.times { Factory.create :article }
  future_post = Factory.create :article, :published_at => 2.days.from_now
  posts = Post.published
  posts.size.should == 3
  post.should_not include future_post
end

This test hits the database (numerous times, in fact) but it’s testing exactly the behavior we need. We aren’t testing implementation, we’re testing that the behavior works as intended. If we somehow muck with the query, breaking it, this test will fail. If we change the implementation to use some other query means (scopes or whatever) this test will still pass.

Is it so bad that the test hits the database?

There are drawbacks of course:

  • The test requires a database, thus you have to migrate
  • The database_cleaner gem will have to be present to clean out the database before each run
  • These database statements make the test suite a LOT slower, so large test suites will eventually suffer.
  • The tests could fail if the database isn’t present (or migrated), or if the query is incorrect. But this isn’t likely to happen since we’re using a tested framework (ActiveRecord).

Ultimately this isn’t really a unit test at all. It’s an integration test. So is spec/models/post_spec.rb the wrong place for this stuff?

The question eventually comes down to this: What is more valuable? A fast, isolated test suite? Or a test suite that breaks for the right reasons?

Don’t throw out good practices just because it’s Ruby

I think it’s important to be cognizant of software paradigms and use them where they make sense. It’s also important to recognize when practices are being ignored because “celebrities” aren’t touting them.

It is still valuable, however, to keep a fresh eye on old assumptions. Don’t always take things as gospel just because that’s the way they have always been. One of the things I love about the Ruby community is how willing people are to rock the boat & try something new.