Binary Logic

Polymorphic association support added to searchlogic

2010-01-23T21:19:58Z

If you have ever worked with polymorphic associations you know that using them in a search can be a pain in the ass. Rightfully so, because a polymorphic association is ambiguous, in order for ActiveRecord to do its magic with creating joins it needs more information that it can’t get. Such as, are you wanting to search type A or type B? In my projects I’ve been dealing with this by writing my own named scopes with my own joins. Not a big deal. But here’s the problem….

My favorite feature in Searchlogic is named scope delegation. I’ve noticed in a number of projects I’ve seen where programmers copy over named scope logic into related models. Which makes sense, because AR gives you no way of easily accessing related scopes. For example:

Order.named_scope :pending, :conditions => {:state => "pending"}
User.named_scope :pending_orders, :joins => :orders, :conditions => "orders.state = 'pending'"

Most people would look at that and never see anything wrong with it. What is the conditions for a pending order changes?

Order.named_scope :pending, :conditions => "orders.state = 'pending' AND approved = true

Now you have to remember to change this logic in associated models. This is a programming no-no. With searchlogic you don’t even need to touch the User model. You can access the order’s named scope, and it delegates that call:

User.orders_pending

Now when you change what defines an order as pending it will change everywhere in your application. This is great, but where this feature comes to a screeching halt is when you encounter a polymorphic association. This is because AR has no internal support for this either. For example, you can’t do:

Audit.belongs_to :auditable, :polymorphic => true
User.has_many :audits, :as => :auditable

Audit.all(:joins => :user)

Obviously the above won’t work. AR has no idea that there is a relationship with users through the polymorphic auditable relationship. To overcome this you have to write your own join. Again, there is nothing wrong with writing SQL, I don’t want to send the wrong message. The problem is that you are back to square one with my named scope delegation problem above. To solve this I added a way to overcome this. With searchlogic you could do this:

Audit.auditable_user_type_name_like("ben")

Searchlogic will take care of creating the join on the polymorphic relationship and then delegate the call to the User.name_like named_scope. I think it’s pretty nifty.

I hope I explained this well. I figured I would mention the new feature because I’m sure I’m not the only person that has encountered this problem.

Using Geokit with Searchlogic

2010-01-11T08:30:34Z

For those of you that don’t know, geokit is a great little gem that allows you to geocode addresses. It adds in very easy to use options in the ActiveRecord find method. Ex:

# will return all venues within 10 miles of the 10018 zip code
Venue.find(:all, :origin => "10018", :within => 10)

The problem is that you can’t use geokit options in a named scope. Since searchlogic is named scope driven this presented a problem. So I wrote a little module that transfers geokit options from named scopes to the actual arguments of the method:

module GeokitForNamedScopes
  OPTIONS = [:origin, :within, :beyond, :range, :formula, :bounds]

  def find(*args)
    super(*transfer_from_scope_to_args(args))
  end

  def count(*args)
    super(*transfer_from_scope_to_args(args))
  end

  private
    def transfer_from_scope_to_args(args)
      find_options = scope(:find)
      if find_options.is_a?(Hash)
        options = args.extract_options!
        OPTIONS.each do |key|
          options[key] = find_options.delete(key) if find_options.key?(key)
        end
        args << options
      else
        args
      end
    end
end

class ActiveRecord::Base
  class << self
    def acts_as_mappable(*args)
      result = super(*args)
      extend GeokitForNamedScopes

      GeokitForNamedScopes::OPTIONS.each do |key|
        named_scope key, lambda { |value| {key => value} }
      end

      result
    end

    VALID_FIND_OPTIONS += GeokitForNamedScopes::OPTIONS
  end
end

It’s far from perfect. The glaring problem is obviously redefining the VALID_FIND_OPTIONS constant, which throws a warning. But it works and it’s good enough for now. If anyone has any suggestions on how to improve this I’d to hear them. But you should be able to use geokit options in a named_scope with the above code. Ex:

Venue.origin("10017").within(10).all # => will return all venues within 10 miles of 10017

Using this through associations

Geokit doesn’t really support making these calls through associations. But if you read the documentation. You will notice they do support this:

acts_as_mappable :through => :whatever

You can use that feature to bridge the gap

Hopefully this helps some of you.

Great marketing or a great product?

2009-12-08T08:41:13Z

I know this post is kind of out of the norm, but what the hell, I figured I would let it fly. Today I was thinking a lot about business and what makes a company successful. I was thinking specifically about marketing and I came up with an interesting scenario:

Say you had money to invest and you had to pick one of these companies to invest in. Both companies are in new industries that have pretty good potential for growth. Which one would you pick?

A company that clearly has the best product, but has an average or below average marketing strategy.
A company with an average or below average product, but has an outstanding marketing strategy.

The above facts are set in stone. You can’t say you would change their marketing strategy or improve their product. You had to pick one of the companies given the current facts above, with no assumptions as to what can or might happen in the future.

I am also aware that if you were actually investing into a company you would require much more information, and there are a number of factors that would sway your decision. But setting that all aside, and you had to pick one right now given the above information, which one would you pick?

Authlogic: keeping you in the loop

2009-11-21T22:17:43Z

I figured I would post an update keeping everyone in the loop. I created a new branch for authlogic locally and I’ve been making some changes mentioned in this post. Some of the changes I’m making are still somewhat experimental and I’m playing around with the code to see if I like the end result. Figuring out a way to make this ORM agnostic has proven difficult, simply because there is no standard. They all follow a similar pattern, but the method naming conventions and some of the feature implementations are vastly different. I’m also not sure you could even set a standard. Regardless, I do think this is an important feature since there is a lot of movement around alternative storage solutions such as MongoDB, CouchDB, etc.

Splitting out some of the authentication code into “authenticators” has worked out great so far. More importantly, its more or less a blueprint for people to extend Authlogic and provide alternate authentication solutions (openid, facebook connect, oauth, etc.).

The last major change I’ve been making is removing validations in the acts_as_authentic module. Validations add some clutter to authlogic, some might say its a necessary clutter, but I’m leaning towards leaving it out. Validation is such an easy thing to do. ActiveRecord provides very simple methods for doing this, I also feel like its gets in the way for certain edge cases. Authlogic will still provide some nice methods to make your life easier, like validating the format of an email address, the main difference being that you have to explicitly implement this validation. No validations will be automatically added. Lastly, this makes ORM abstraction a little easier.

So that’s that. I’ll keep you updated when I start to push out some code and what not. I’m probably going to label this release as v3, because of the validation changes and some of the other major changes that might break backwards compatibility.

Discontinuing Resourcelogic

2009-10-06T04:33:08Z

Lately I’ve been really going back and forth between using tools like resourcelogic, inherited_resources, resource_controller, etc. And I gave each one of these libraries a more than fair shot. I’ve used all of them extensively, that’s the whole reason I created resourcelogic to begin with. I really liked resource_controller, so much that I decided to take it and kind of make my own version called resourcelogic. I ended up changing it quite a bit, and it worked out well, but it got out of hand. So I’m going to address why I advise against using libraries like this:

Deviating from standards makes it harder to work with other programmers

You have to think that certain things in rails are there for a reason. Rails is a result of thousands of programmer’s ideas, its used by extensively by programming teams large and small, and has tremendous success. There is a reason for that. Chances are, you aren’t going to sit around one day and come up with this idea that takes rails to the next level. I’m not trying to be a Debbie Downer and tell people not to try and improve rails or be innovative. That’s not the message I’m trying to send here. What I’m trying to say is that if you are sitting around and you come up with this crazy idea that deviates quite a bit from the rails standards, it’s probably wrong, even if you think it’s cool. I thought I did that with resourcelogic. I thought I was Mr. Awesome and I came up with this new development style for rails that was better than anything done before. I know that sounds pretty conceited but I was on my high horse. I thought the development style behind resourcelogic was awesome and I was going to share it with the rails community and people were going to eat it up.

So I ran with it, I developed an entire project with it by myself. Probably the most important project I’ve ever developed. I gave all of these libraries a more than fair shot. In the end, it made my project more confusing. The red flag was showing my code to another programmer. I had to explain what was going on and he was still kind of confused. Once he got it, he didn’t like it. This is not good. I didn’t like the thought of having to go through this with every programmer I was going to hire for this project. Which leads me to my next point:

You lose intent

This is probably my biggest complaint: you lose intent. There is a lot of code hidden away, so when you see small controllers with 4 – 5 lines of code providing all of this application specific functionality it kind of makes you wonder what is going on. There is no direct intent saying “this is what I’m doing”. There’s a lot of magic. My controllers looked like this:

create.before { ... }
create.wants.xml { ... }
create.wants.js { ... }
create.after { ... }
index.before { ... }

def my_own_custom_action
...
end

It just felt wrong. There is something refreshing about seeing this:

def create
  @user = User.new(params[:user])
  respond_to do |wants|
    if @user.save
      wants.html { redirect_to users_url }
      wants.js { render :inline => "window.location = '<%= users_url %>';" }
   else
     wants.html { render :action => :new }
     wants.js { ... }
   end
  end
end

Is that more code? Yes. Who said more code is bad when it makes more sense? I can look at the create method and know EXACTLY what is going on. I can add in some weird edge case if I need. I can do whatever the hell I want and I’m not confined to the standards set in resourcelogic. I don’t feel like I’m deviating from a pattern by doing that either. Sure, with resourcelogic you can write your own create method, but then I feel dirty, like I’m not following the pattern my application has defined.

Upgrading rails

What example would you feel more comfortable with if you were upgrading from rails 2 to 3? The one that uses a pattern that deviates from the rails standards, or one that uses the most basic of rails code? I would feel better with the second. That is standard rails code that I know for a 100% fact is going to be supported in Rails 3. Sure, you could up date the library in the first example to work with rails 3, but in my opinion thats a sign the library is messing with code it shouldn’t.

Conclusion

I’m not trying to knock libraries like resource_controller or inherited_resources, hell I wrote my own version called resourcelogic. So I would be knocking myself if I did. I just don’t think they are needed. Rails is simple to begin with. There is nothing wrong with writing out a full controller method. It’s simple, its direct, its clear, and it follows the rails standards. I can pick any programmer from the rails community and not have to say a word and they would understand a standard rails action. While at the same time I could show them a “resource controller” and a lot of people would wonder what the hell is going on. More importantly, edge cases feel clean. If a controller needs to do something a little bit different, that’s fine. I have full control of what is going on. I don’t have to use some weird API with before and after hooks to add in edge cases.

So the bottom line is that I am stopping support for resourcelogic. I will more than likely remove it from github because I don’t want to send people down the wrong path thinking its a good tool to use. For a simple project its probably fine, but in the end it’s just not worth it. All of the time and effort I spent writing resourcelogic and implementing it into my app was kind of a waste. With that time I could have made some major advancements and improvements to my application. But it’s things like this that make you a better programmer, you live and you learn. The lesson I learned is to not deviate from the rails standards too much. Use what they give you, chances are it will work out just fine because there are thousands of other programmers using the same tools to build a large variety of projects.

Apologies to those needing help with my libraries

2009-09-02T05:01:30Z

I wanted to make a post about this. I’ve been extremely busy with my job lately. I’m launching a new company, and as we approach launch date it seems to get more hectic. I’ve got quite a few messages in my github account, email, google groups, etc. I usually try to block out about an hour a day answering emails and performing basic chores with my open source projects, but I literally haven’t had an hour to spare. The time that I do have is spent maintaining my open source projects, so solving individual problems has been put on hold for now. I apologize if I haven’t responded to you. Don’t take it as an insult, I am just very busy right now. If you need help, please use google groups, the people on there are very helpful. By the way, thanks to everyone on google groups, github, Ryan Bates on railscasts, etc, for helping out. You guys really have been a big help, this is why I love open source.

Using Searchlogic to combine named scopes with ‘OR’

2009-08-26T08:21:47Z

A few days ago I released a feature that Ryan Bates requested: combining named scopes with ‘OR’. As you know, when you combine named scopes they join the conditions with ‘AND’. This obviously makes sense, but what if you want to combine conditions with ‘OR’? With this new feature you can do the following:

User.first_name_or_last_name_like("ben")
User.id_lt_or_age_gt(10)

I think this is nice feature on a variety of levels, but what I particularly like is the implementation. It uses method_missing to accomplish this. You can call any scope you want, call scopes provided by searchlogic, call your own scopes, call scopes on associations, etc. As long as it maps to a named scope it will join the conditions with ‘OR’. So you have a little more flexibility when building a query with named scopes:

User.id_gt(10).first_name_or_last_name_like("ben")
# => (id > 10) AND (first_name LIKE '%ben% OR last_name LIKE '%ben%')

More than just named scopes

A lot of people think searchlogic is just a bunch of named scopes, what people don’t realize is that it provides tools around how you use named scopes in general.

The other day I was reviewing an application for a friend who was using searchlogic. I noticed this:

User.named_scope :with_recent_orders, :conditions => ["orders.created_at >= ?", 1.week.ago], :joins => :orders
Order.named_scope :recent, :conditions => ["orders.created_at >= ?", 1.week.ago]

See the duplication there? With more complex named scopes this becomes more obvious, but the scope was so simple I think he missed it. I even catch myself doing this sometimes, then I realize I don’t need to. The named_scope in the User class is pointless. With searchlogic, you can accomplish the same thing by doing:

User.orders_recent

searchlogic dynamically creates the scope for you, pulls over the scope details, and create the necessary join.

The goal of named scopes

In my opinion the simpler the named scope, the better. If you find yourself writing a complicated named scope, take a step back and look at it. I’d be willing to bet you could split that named scope into multiple smaller scopes. For example, instead of calling a named scope ‘Product.popular_expensive’, create 2 named scopes called ‘popular’ and ‘expensive’. Break your scope into small parts and then piece them together when you need them.

Another good idea is to create scope procedures. This allows you to create small named scopes and still get the advantage of calling a single scope. Creating a procedure is as easy as creating a class level method:

class User
  def self.awesome
    name_begins_with("Ben").name_ends_with("Johnson")
  end
end

Even better, used searchlogic’s scope procedure:

User.scope_procedure :awesome, lambda { name_begins_with("Ben").name_ends_with("Johnson") }

I’ll leave it at that. If you are bored one day checkout the searchlogic docs. I think you’ll find some small things like this that could help save you time and DRY up your code.

Heroku rocked my face off

2009-08-26T07:56:58Z

This week my task at hand was to figure out a deployment strategy for an application I’ve been working on. The initial conclusion was that we needed to buy another server. I wasn’t too happy with this because setting up a new server is a pain in the ass. It’s very repetitive, mundane, and boring. I’d much rather be spending time coding or coming up with new ideas instead of maintaining servers.

That being said, I figured I would see what engine yard or heroku had to offer. Maybe it’s time my company starts using these services. It would be easier and cheaper.

Engine Yard Solo

Initially I was interested in engine yard’s solo plan. It seemed nice. It was a little confusing at first, but only took about an hour of playing around with it to really understand how it works. An hour is a small price to pay for something like this. Their stack was nice, not the stack I would choose, but who the hell cares at this point. I’m not going to start splitting hairs over using passenger or thin. The only thing I wasn’t too happy with was the pricing. To run a staging environment on their smallest plan would be around $115 a month. Then a production environment on top of this would be about $300. You’re looking at $415 a month to run a decent application. Is that a lot of money? Not for an important application, but my company also has a lot of small applications. We have blogs, small intranet apps, etc. That could start to add up, to the point where it would be more expensive than my current set up.

Heroku

Then I decided to checkout Heroku. The first thing I noticed is that their basic plan is free. You can host an application on there for free to start, which is AWESOME. I love that they do this, and in my opinion this is going to play a big part in their success. I signed up, followed the instructions they gave me, and had an application running in under 5 minutes. It was unbelievable how easy they made it. Literally, you create an application on Heroku, push your code to their git repository, and it deploys the app for you. I sat there for a minute, in awe, trying to soak it all in. It was awesome, but with all of this magic going on there has to be a catch or limitations. So I started to read the docs to try and understand it. To my surprise, there were a lot of advantages to using their set up, specifically around caching. There were also a few limitations, but nothing that I can’t live without. I won’t ramble on about the details because a lot of the issues are subjective. For example, is using PostgreSQL a limitation to you? What about a read-only filesystem? I’ve always been a MySQL guy, but after doing some research on PostgreSQL I really like it, and am going to make it my default choice for future apps.

Conclusion

If you haven’t tried out heroku then you should. It takes about 10 minutes to try out, it’s free, and it’s well worth the time. Even if you know it’s not an option for you, its still fun to play around with. I have a feeling heroku is going to really take off and become a standard for ruby web applications. There are still some loose ends they need to tie up, but once they do there really is no reason not to use their service.

Also, no, I am not getting paid by Heroku. I wish I was though. I just like to share things on here that make my life easier, and this definitely did.

Authlogic ideas

2009-08-13T20:00:00Z

So I’ve been thinking about Authlogic lately and here are a few ideas I’ve been bouncing around:

Split out authenticating into “authenticators” that extend a class that acts as an interface, which would obviously be provided by Authlogic.
So you would have a cookies authenticator, session authenticator, params authenticator, twitter oauth authenticator, openid authenticator, anything you want. You could basically create an authenticator, register it with authlogic, and then you can do whatever you want in that class. This shouldn’t be a complicated task, more importantly I think it makes it easier to extend authlogic with different authentication methods.
Abstract the interaction with your models.
This is especially hard because there is no standard between the different database libraries. But it would be nice to use Authlogic with DataMapper, MongoMapper, etc. I’m just hoping I can come up with a clean and clever way to do this. The only sure fire way that I can think of is to create adapters for each supported library, which means maintaing duplicate code. That would not be a fun task.
I’m toying with the idea of adding in common application code that you can include in your application.
Such as resetting passwords, registering, logging in and out, grabbing the current user etc. What I don’t like about that is that now I am stepping into your application and making decisions for you. Is this a bad thing? I don’t know, thats for you to decide, but it definitely deviates a little bit from the “rails way”. Your UserSessionsController should look VERY similar to your other RESTful controllers. If you are willing to create those controllers / views, what’s the big deal with creating one for UserSessions? I just feel like it fits better. Here I have an application full of RESTful controllers where the code is pretty similar, then I have this UserSessionsController thats different. I just don’t like that. Also, what if you are using something like resource controller, inherited resources, or resourcelogic? What if you want your controller to use on of those libraries?
The worst part about this idea are the views. Interfaces can be quite a bit different from application to application. How do I provide views that are suitable for every project? In my opinion you can’t. I could give you a million partials, tons of configuration, a lot of helpers, etc. This might add some flexibility, but this seems like a hack. It’s not a clean solution. This is the one thing that I just don’t like about rails engines. I prefer tools that help me create my views. Give me a set of tools so I can go easily create my interface, but don’t go create my interface for me. And I think rails does a pretty good job of this with things like form_for, etc.

The bottom line is that I want to keep Authlogic focused on the business logic behind authentication. You should be able to use Authlogic in a rails app, merb app, sinatra app, etc. All of the interface cruft should probably be in a separate gem or in a template. The thing is, this gem could be written a million different ways depending on your preferences. Maybe I can create a base rails engine that people can fork and modify to their liking. That’s the beauty of git.

To conclude, #1 is probably going to happen, I want to do #2 if I can figure out a good way to do this, #3 is still up in the air and more likely to be in a separate gem / plugin.

That’s it for now, I figured I would try to keep everyone in the loop. Maybe you can help me out or have some ideas of your own.

Introducing Shippinglogic

2009-08-07T23:59:29Z

Today I released the first version of Shippinglogic, which is a ruby library I wrote to make integrating with FedEx, UPS, USPS, etc, very easy.

This is not a project I wanted to do, but I couldn’t find a library that did everything I needed it to. One library had support for creating shipments, but didn’t have support for getting a list of rates. Another had support for getting rates, but didn’t have support for creating shipments. I need both for the application I’m working on. I even decided to modify one of the libraries to suit my needs but the code was really hard to follow and I didn’t feel comfortable using it. Especially since shipping was such an important part of my application.

That’s when I came to the sad realization that I probably need to write my own library. I was really surprised by the lack of choices when it came to shipping API integration. Then I started reading the FedEx documentation and realized why. Documentation on creating a shipment with the FedEx web services was 570 pages long. The amount of bullshit in the documentation astounded me. 99% of developers are probably concerned with maybe 30 pages in that entire document. I felt like I was reading a legal document, not web service documentation.

Sorry for the ranting, but this week has been especially frustrating, imagine reading FedEx documentation all day. Anyways, onto Shippinglogic.

What is Shippinglogic?

My goal with Shippinglogic was to make integrating with the various shipping APIs (FedEx, UPS, USPS, etc) easy and complete. The keyword being complete. Shippinglogic is not an abstraction layer, meaning each classes’ focus is on the web service at hand. It is not trying to conform to an interface. With all of the differences between the various APIs its simply not possible to do this without severely limiting the feature sets for each API. There is no defined shipping standard that all of these companies agreed on, so how do you safely make an abstraction layer for this?

Anyways, I think it turned out pretty well. The syntax is pretty slick, thanks to the proxy class trick I talked about in a previous post.

Here’s a quick example of tracking a package:

fedex = Shippinglogic::FedEx.new(key, password, account, meter)
tracking = fedex.track(:tracking_number => "XXXXXXXXXXXXXXXXX")

# this shows that the tracking object is actually a proxy for the underlying array
tracking.tracking_number
# => "XXXXXXXXXXXXXXXXX"

tracking.tracking_number = "YYYYYYYYYYYYYYY"
# => "YYYYYYYYYYYYYYY"

tracking.class
# => Array

tracking.first
# => #

tracking.first.name
# => "Delivered"

I was pretty thorough with the documentation. Check out the project on github for more examples. Let me know what you think.