Technology Musings

May 24, 2011

Platforms / Database Scaling with PostgreSQL

JB

I've been digging around on various database scaling options for PostgreSQL.  Here's some interesting links I've stumbled upon:

 

 

May 23, 2011

Platforms / Getting EC2 Instances to Talk to Each Other

JB

I am getting started with EC2, and I noticed a problem - I was unable to get my instances to talk to each other - specifically, mounting an NFS drive.  After searching through my forums, I found my answer - I was using a custom Security Group.

In the default security group, instances within that security group can talk freely to each other.  What is surprising is that the default mode for a custom security group is to prevent all communication between the instances.  Therefore, you have to add permissions for the security group to be able to receive incoming traffic from the security group itself.  In the "host" line, rather than put an IP address, you can put in a security group ID (i.e. sg-abc123), and then specify 0-65535 for the port range.

Then, viola!  It works!

May 18, 2011

Platforms / Blocks in Objective C

JB

Blocks is a new feature of Objective C that was announced roughly at the same time as Apple announced Grand Central Dispatch.  I haven't had the time to look into it thoroughly, so I'm sticking my bookmarks here for future reference:

May 11, 2011

Platforms / Using Indexes on LIKE queries on PostgreSQL

JB

Apparently, under some configurations (I think they are compile settings dealing with the locale), PostgreSQL will not, by default, use an index for LIKE queries.  First of all, note that PostgreSQL will NEVER use an index for an ILIKE query (case-insensitive like).  For that, you should use a functional index using the LOWER function.  It will also not use an index if the LIKE starts with a wildcard.  But, for queries that *end* in a wildcard, if you set it up right, you can get PostgreSQL to use an index.

Anyway, apparently the problem is that PostgreSQL doesn't know what locale it is in, and therefore doesn't know how to order the characters.  Therefore, you have to give it some help.  After your index column, you need to add text_pattern_ops.  So, for my own table, I did the following:

create index entity_lower_name_idx on entities(lower(name) text_pattern_ops)

And viola!  Postgres is now using the index.  Since this is a functional index, it indexes queries like

select * from entities where lower(name) like 'hello%'

Hope that helps someone!  I received the information here and here.

May 05, 2011

Platforms / Making Reusable iPhone Widgets with Interface Builder

JB

One annoying thing about Interface Builder, at least for the iPhone, is that there is not a direct way of making reusable widgets that are both made *in* Interface Builder and *for* Interface Builder.  I came up, though, with a set of instructions and helpers that make the process fairly painless.  The class is called IBView, and should be used as the parent class for your reusable widget.

Here's how to create the widget:

  1. Create a class for your new widget, called MyWidget.  Inherit from the IBView class (code provided below).  Create all of the IBOutlets you want for your widget.
  2. Create a view with the same name as your widget class in Interface Builder.  If your widget was named "MyWidget.m" then your interface should be called "MyWidget.xib".  DO NOT set the class of this view or any subview to be of the MyWidget (or whatever class you are create) type.  DO NOT do it.
  3. Set the "File's Owner" of your interface in Interface Builder to be the name of the class that you are creating - MyWidget in this case.
  4. Set up any connections you want between your IB view and File's Owner (i.e. your widget).

Now, your widget is created.  You can now use the view in any IB panel by doing putting in a generic UIView, and setting the class name to your new class (MyWidget in this case).

Important caveat - one consequence of creating the view in Interface Builder is that there will be an extra view between the main view represented by your class and the rest of the elements of your class.  Basically, your custom view acts as a generic view, and then *loads in* your Interface Builder file as a subview, meaning that the toplevel view in Interface Builder will sit under your MyWidget view.  This is usually unimportant if you are just using IBOutlet stuff, but if you do advanced view management, it would be important to know that a view sits between you and the rest of your sub-widgets.

Okay, here is the code for IBView.m - just very simple code, with a tiny bit of Objective-C magic thrown in:

#import "IBView.h"

@implementation IBView

-(void) loadViewsFromBundle {
NSString *class_name = NSStringFromClass([self class]);
NSLog(@"Loading bundle: %@", class_name);
UIView *mainSubView = [[[NSBundle mainBundle] loadNibNamed:class_name owner:self options:nil] lastObject];
[self addSubview:mainSubView];
}

-(id) initWithCoder:(NSCoder *)coder {
self = [super initWithCoder:coder];
if(self) {
[self loadViewsFromBundle];
}
return self;
}

- (id)initWithFrame:(CGRect)frame {
self = [super initWithFrame:frame];
if (self) {
[self loadViewsFromBundle];
// Initialization code.
}
return self;
}

@end

And IBView.h is super-simple:

#import <UIKit/UIKit.h>
@interface IBView : UIView {
}
@end

And that's all there is to it!