Using GDB to inspect a running Ruby process

This job shouldn’t be taking this long!

That’s not a great thing to have to say, is it? However, I bet you’ve said it before and may not have immediately know why.

With liberal use of puts and maybe pry, you can figure out what a problem might be next time you run it, but sometimes you need to figure out what that problem is right now.

As it turns out, and I know this is a shocker, Ruby processes are just regular processes. They can be debugged with gdb.

Having recently had the need to find out why a job of mine was running particularly slowly, I found out about this lovely tool the hard way: frantic googling. I found some very useful functions for gdb in a blog post by Rasmus on Ruby callstacks.

define redirect_stdout
  call rb_eval_string("$_old_stdout, $stdout = $stdout, File.open('/tmp/ruby-debug.' + Process.pid.to_s, 'a'); $stdout.sync = true")
end

define ruby_eval
  call(rb_p(rb_eval_string_protect($arg0,(int*)0)))
end

How to use these:

1. Start up gdb by running gdb /path/to/ruby PID, where /path/to/ruby is the full path to the actual ruby binary and PID is the process ID of the ruby you want to check out.
2. Paste those functions above into the gdb prompt (you might also want to store them in ~/.gdbinit for later).
3. Run redirect_stdout, which will put all the ruby output into a file called /tmp/ruby-debug.PID where PID in this case if the process id of gdb — not terribly important, but a differentiator in case you do this a lot.
4. Run commands via ruby_eval('Kernel.caller') and object_id and things like that. You should be able to get local variables from wherever you broke into the program.

These ruby_eval commands will output into the tempfile that redirect_stdout created, so you’ll need to tail -f that file in a different console. Now, with that small headache over with, you can see exactly where your program is and if there is a stupid loop where you forgot to check a boundary condition, or what thing you’re doing with a regular expression on where you should have just used String#index.

Written by Jon Yurek.

Shoulda Matchers 2.0

Shoulda Matchers has been around for a long time. Unfortunately, it’s starting to suffer from feature bloat so we’re narrowing its focus to keep releases fast and the maintenance burden low.

Removing Deprecated Matchers

The following matchers were deprecated in 1.5 and will be removed in 2.0 . If you’re currently using these methods you should consider testing the code in another way.

assign_to

The assign_to matcher allows you to ensure you have set an instance variable properly. We do not use this because we typically cover those types of assertions implicitly through an integration test. An integration test may be slower than a unit test, but it provides more thorough coverage.

validate_format_of

The validate_format_of matcher allows you to perform the same operation as the allow_value matcher. Please use the allow_value matcher instead.

should validate_format_of(:email).with('user@example.com')
should allow_value('user@example.com').for(:email )

have_sent_email

We recommend email-spec for testing emails in your apps. It has the added benefit of working with your integration suite as well as your unit tests.

respond_with_content_type

The respond_with_content_type matcher is not a matcher we use often. This behavior can be tested using the response object in your controller tests without the need for a matcher.

query_the_database

We do not have a recommended solution for a replacement on this matcher.

Matchers Removed Temporarily

The strong_parameters and delegate matchers will also be removed in 2.0. We ran into some trouble implementing them but hope to re-implement them in a less troublesome way soon.

New Hotness

As part of the move to 2.0, we will also be dropping support for Rails 2 & ruby 1.8. We will continue to support Rails 3.x and ruby 1.9.x and will be adding support for ruby 2.0 soon.

Keeping it tight

We are trying to keep Shoulda Matchers a tight focused gem and make sure the matchers we do support are as robust and thorough as possible. Do you think there are any other matchers we should remove?

Written by Jason Draper.

Introducing The Playbook Online Workshop

We’ve been offering a video version of The Playbook for some time, and now we’re happy to announce the evolution of that concept, the new Playbook Workshop.

This workshop is the real-time, expanded version of The Playbook. We’ll start with the video lessons and then work together on practical examples and your own real ideas. We will go through an example of building an actual application and we’ll explore all of the pieces of the web design and development process, including the tools and team.

The first session of this new workshop runs from April 8th to the 19th, and is available for registration individually for $499, or you can subscribe to Learn Prime, to get access to this workshop, and all our other workshops, books, and screencasts for just $99/month.

Learn more and register today. I hope to see you in the workshop!

Designing for iOS: Blending modes

Let’s say that we have an app that makes use of image assets for icons, custom progress bars, etc. Now we want to allow users to theme the app, and these images need to conform to this new color scheme. The obvious solution is to add 1x and 2x versions of every single possible image asset in the app, right?

No, of course not. Duplication is bad, and duplicating images is just another form of duplication. But we’re clever folks, I’m sure we can find a nice way around this!

We’ll start out with a simple image that we need to tint to our new color scheme. It has an alpha channel, but it’s a flat color and the new color is going to be flat as well.

The smart way to do this would be to redraw the image using a new color using CoreGraphics. Let’s consider the steps needed to make this happen:

1. Create a new image context to draw into.
2. Set the new tint color to be the fill.
3. Get the image size.
4. Draw the source image with the new color while retaining the alpha information.
5. Get the image out of the current context and return it.

Looks pretty straightforward, but retaining the alpha channel will likely be the trickiest part of the exercise. Looking into the UIImage documentation, we know we’re going to want to use -drawInRect:blendMode:alpha: to draw the new image. Looking at the available blending modes leaves us a little… confused:

kCGBlendModeSourceAtop
R = S*Da + D*(1 - Sa)
Available in iOS 2.0 and later.
Declared in CGContext.h.

That’s not actually super helpful. Let’s keep reading, I guess.

The blend mode constants introduced in OS X v10.5 represent the Porter-Duff blend modes.
The symbols in the equations for these blend modes are: 
R is the premultiplied result
S is the source color, and includes alpha
D is the destination color, and includes alpha
Ra, Sa, and Da are the alpha components of R, S, and D

Ah, ok. So we need to do some translation here. What we’re looking for is a blending mode that will draw the new color (Destination, represented by D) using the alpha components from the source (represented by Sa). Looking through the available options armed with this new knowledge, we find one that looks promising:

kCGBlendModeDestinationIn
R = D*Sa
Available in iOS 2.0 and later.
Declared in CGContext.h.

That looks like it’s using the right components, but there’s only one way to be completely sure. Let’s get ready for some good old fashioned trial and error. First, we’ll go ahead and create a category on UIImage:

// UIImage+Tint.h

@interface UIImage (Tint)

- (UIImage *)tintedImageWithColor:(UIColor *)tintColor;

@end

This feels like a nice interface. We can assume that we will either have the image that needs tinting, or we can simply chain it together with -imageNamed: to grab the image from the bundle. Now for the initial implementation:

// UIImage+Tint.m

#import "UIImage+Tint.h"

@implementation UIImage (Tint)

- (UIImage *)tintedImageWithColor:(UIColor *)tintColor
{
    // It's important to pass in 0.0f to this function to draw the image to the scale of the screen
    UIGraphicsBeginImageContextWithOptions(self.size, NO, 0.0f);
    [tintColor setFill];
    CGRect bounds = CGRectMake(0, 0, self.size.width, self.size.height);
    UIRectFill(bounds);
    [self drawInRect:bounds blendMode:kCGBlendModeDestinationIn alpha:1.0];

    UIImage *tintedImage = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();

    return tintedImage;
}

@end

Plugging this into our app is as simple as [[UIImage imageNamed:@"ralph"] tintedImageWithColor:[UIColor thoughtbotRed]];

That was simple enough. But what if we want to retain a gradient from the image? Let’s say we have a nice grayscale button that should be skinned as well:

All we have to do is pass it through our tint method, and voila!

Oops. Looking back at the blending mode, this won’t work at all. The only things that kCGBlendModeDestinationIn takes into account are the destination color, and the source alpha. We’re losing all of the grayscale info from the source image. Looks like we still have more work to do. Once again, we turn to the documentation, and find kCGBlendModeOverlay:

kCGBlendModeOverlay
Either multiplies or screens the source image samples with the background image samples,
depending on the background color. The result is to overlay the existing image samples
while preserving the highlights and shadows of the background. The background color mixes
with the source image to reflect the lightness or darkness of the background.

Available in iOS 2.0 and later.
Declared in CGContext.h.

That sounds like it should tint our gradient nicely. But we don’t want to change the current behavior. This calls for some refactoring. The new interface becomes:

// UIImage+Tint.h

@interface UIImage (Tint)

- (UIImage *)tintedGradientImageWithColor:(UIColor *)tintColor;
- (UIImage *)tintedImageWithColor:(UIColor *)tintColor;

@end

And the new implementation:

// UIImage+Tint.m

#import "UIImage+Tint.h"

@implementation UIImage (Tint)

#pragma mark - Public methods

- (UIImage *)tintedGradientImageWithColor:(UIColor *)tintColor
{
    return [self tintedImageWithColor:tintColor blendingMode:kCGBlendModeOverlay];
}

- (UIImage *)tintedImageWithColor:(UIColor *)tintColor
{
   return [self tintedImageWithColor:tintColor blendingMode:kCGBlendModeDestinationIn];
}

#pragma mark - Private methods

- (UIImage *)tintedImageWithColor:(UIColor *)tintColor blendingMode:(CGBlendMode)blendMode
{
    UIGraphicsBeginImageContextWithOptions(self.size, NO, 0.0f);
    [tintColor setFill];
    CGRect bounds = CGRectMake(0, 0, self.size.width, self.size.height);
    UIRectFill(bounds);
    [self drawInRect:bounds blendMode:blendMode alpha:1.0f];

    UIImage *tintedImage = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();

    return tintedImage;
}

@end

This gets us closer, but you can see that now we’ve lost our alpha information.

Since kCGBlendModeOverlay doesn’t take the source alpha into account, we need to try to get that back. There’s a very simple way that we can accomplish this. We already know that kCGBlendModeDestinationIn` draws the destination image in the source alpha, so we can conditionally redraw the image using this mode:

// UIImage+Tint.m

- (UIImage *)tintedImageWithColor:(UIColor *)tintColor blendingMode:(CGBlendMode)blendMode
{
    UIGraphicsBeginImageContextWithOptions(self.size, NO, 0.0f);
    [tintColor setFill];
    CGRect bounds = CGRectMake(0, 0, self.size.width, self.size.height);
    UIRectFill(bounds);
    [self drawInRect:bounds blendMode:blendMode alpha:1.0f];

    if (blendMode != kCGBlendModeDestinationIn)
        [self drawInRect:bounds blendMode:kCGBlendModeDestinationIn alpha:1.0];

    UIImage *tintedImage = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();

    return tintedImage;
}

@end

And we finally have the desired image:

This image is perfect to assign to a static variable to allow it to be used app-wide, without having to redraw.

By using CoreGraphics to tint our images for us, we open ourselves up to a much wider range of functionality in our apps, and we get the added benefit of smaller bundle sizes, and reduced asset duplication.

Be sure to check out the many different blending modes available in Apple’s documentation. You can check out the sample app that includes the code used here on GitHub.