Binary Logic

Searchlogic v2 officially released

2009-06-15T06:17:15Z

Tonight I went ahead and officially released searchlogic v2. If you didn’t read my last post, v2 is a complete rewrite of the library. It takes a new approach. It went from ~2300 lines of code to ~400 lines of code. It’s simpler, easier to use, much more light weight, faster, and more importantly, easier to maintain, understand, and improve upon.

I’m not going to ramble about the changes, because you can read my previous post or you can check out the read me on github.

Using github not rubyforge

I have decided to start using github to host my gems, if you want to start using v2 as a gem you need to install the binarylogic-searchlogic gem from the github source. (checkout the read me for easy installation instructions).

Thank you

Sorry for such a quick post. I figured this was an important announcement.

Thank you for being patient with v1, I know there were some people having issues. This should address all of them.

As always, I did my best with the readme and the rdocumentation. If you really want to see what v2 is all about I suggest you take a glance at those, they should be comprehensive.

I hope you enjoy v2, I’m really excited to release it. I have already integrated it into the app that I am working on, and I love it. It works great and all of my tests pass.

Searchlogic v2 beta released

2009-06-09T04:11:27Z

Searchlogic v2 beta was released today, it is a complete rewrite of the library, no code was reused. Right now its in a separate branch under the Searchlogic project, and will be merged when it is taken out of beta status. Let me explain how it’s different.

So, the project I’m working on now required something from Searchlogic v1 that it couldn’t provide. That is, searching with existing named scopes. I could do this, but it wasn’t as elegant as it was with the built in conditions (Ex: username_like, etc.).

The idea behind Searchlogic v2

So this got me thinking, how can I get Searchlogic v1 to use existing named scopes? That’s when it hit me, why not use named scopes for everything?I think we can all agree named scopes are the heart of searching and breaking up common search logic in your models. Instead of having all of this crazy logic write SQL and chain it together, as in v1, why not have Searchlogic dynamically create these common named scopes for you and then just leverage those? That’s exactly what v2 does. Instead of going into detail about v2, check out the current README. It explains everything v2 has to offer up to this point.

The best part about this approach is that it fits nicely into your application. All that it is doing is creating named scopes. More importantly, if you need some condition that Searchlogic doesn’t offer, no problem, just create your own named scope. This is what you should be doing anyways.

To bring it all home, let me show a simple search form that uses v2. Assume we have

User(name:string, age:integer)
Order(user_id:integer, total:float)

User.has_many  rders
User.named_scope :four_year_olds, :conditions => {:age => 4}
User.named_scope :name_sounds_like, lamda { |value| {:conditions => ["name SOUNDS LIKE ?", value]} }

Your search form could look like this:

- form_for @search do |f|
  = f.text_field :name_like
  = f.select :age_greater_than, (1..100)
  = f.text_field  rders_total_less_than
  = f.text_field :name_sounds_like
  = f.check_box :four_year_olds
  = f.submit

Notice the use of custom named scopes. Also the other conditions are also named scopes that searchlogic dynamically defines as you need them.

The best part of v2

V1: ~2300 lines of code
V2: ~350 lines of code

As you might have saw in this post Searchlogic v1 was too big for me to handle. The issues people were having would take way too long to solve and I just didn’t like the code. The library really wasn’t advancing and it was just an annoyance. It was regretably the first library I ever wrote, and as such there are a lot of things I would do differently, which should be evident in v2.

That being said, v2 is lean, makes sense, and just feels right. I’m really looking forward to maintaing the library and seeing where it goes. I hope everyone enjoys it. Let me know what you think. There are just a couple of things left to do before I officially release it.

Applications using v1

Lastly, because this is such a big change, backwards compatibility will be broken. Before I officially release the library I will write a document explaining the differences and how to transition. In the mean time, your gem declarations in your application should look like this, so that your app doesn’t break when the new version is released:

 config.gem "searchlogic", :version => "~> 1.6.6"
# the ~ will let you advance minor and tiny versions, but not major versions.

Ruby tips from me, your idol

2009-04-19T19:16:50Z

I feel like I’ve been in the ruby community for a while now and I’ve learned a lot along the way. Taking a step back and looking at what I did right and wrong was interesting. Most of the “wrong” I had to learn the hard way, and it would have been nice to have someone tell me: “Ben, you’re dumb, stop doing that, and go put on your helmet”. So I decided to go ahead and throw together a few tips and share them on my blog. Whether you agree or disagree, hopefully this saves you some time, or at least gets you thinking about some things. Afterall, I am your idol, so you are probably going to agree with me.

1. Find that perfect balance between being OCD and using your time wisely

You can ask anyone I’ve worked with. I am the king of being OCD with my code. I want everything to be perfect and I don’t care how hard it is or how much time it takes. This is by far my biggest weakness and has caused me to waste a lot of time. So I decided to come up with a question I ask myself: Will this change benefit me immeadiately? When I am being OCD the answer is “no”, when I am being productive the answer is “yes”.

Perfect example: neco.com was my first rails project. As a result it used a lot of the old rails practices. It wasn’t RESTful, etc. I really like REST so I decided to go ahead and convert the entire application. I figured if I really grinded it out this would take me a few days. Wrong, it took me about a week and a half, and I was working at least 12 hours a day. Has this benefited me at all? Nope. In fact, our API has some unique requirements and we built an entirely separate application for this. Bottom line, a week and a half wasted. Legacy code is not bad code unless it is restricting you or wasting a lot of your time. neco.com was just fine the way it was. Make the change when you need it, don’t make the change because you are being OCD.

2. Don’t go against the grain in Rails or invent your own standards

I can not tell you how much time I’ve wasted trying to add in some cool feature into rails. I would dig into the rails internals, override methods, do all kinds of tricky stuff. I thought I was awesome. A month later rails comes out with some cool new feature, I update rails and everything explodes. Yes, maybe this cool new feature of yours would make your code cleaner, leaner, and possibly easier to understand, but it’s not worth it. You also lose the advantage of having other programmers easily understand your work, because you are not following standards.

Figure out a way to solve your problem unobtrusively or using the tools rails provides. In the long run, your app will feel much cleaner, it will be easier to understand by other programmers, and you can update rails easily. If you find your self messing around with private methods in rails, 99% of the time that should be a red flag to stop what you are doing.

3. Keep your documentation with your code

This one is more for library design. It’s very tempting to use a wiki, post documentation on your blog, etc., because it seems more user friendly for both parties. Believe it or not, a lot of people find rdoc confusing, and the old rdoc template (before darkfish) was not fun to use. In my opinion this has changed. Thanks to sites like Github, people can now easily fork your project and fix a documentation flaw, which kind of renders a wiki useless for documentation, and rdoc has been updated with a new template format (darkfish) that makes reading documentation MUCH easier. I actually prefer hanna. It’s a very nice theme, I used it for the authlogic documentation.

That being said, you are human, and if the documentation is not with your code you are going to forget to update it from time to time. I made this mistake with my own blog and a lot of my tutorials quickly became out of date. Because of this I’m sure I wasted a lot of people’s time trying to figure out what they were doing wrong. When the documentation is next to the code its hard not to update it when you make changes. If you don’t know how to use rdoc take 5 minutes to learn it. It is better for everyone involved. There is no denying that documentation is a pain in the ass, so the best thing you can do is make it as easy as possible on yourself. If someone doesn’t want to read through your documentation because they don’t understand rdoc, oh well. They are programmers and should take the time to learn something that important in ruby.

4. Think about what you are reading

Just because someone throws something up on their blog doesn’t mean they are right, my blog included. There are a million ways to solve problems in programming. Many times I have been caught by this. I will read something on a blog from someone that is a very good programmer and just go do it. Later it blows up on me because it actually was not a good tip. Had I of thought about what was going on from a big picture perspective, I could have saved myself a lot of time. Instead I put so much trust into this guy that no matter what he says he must be right.

If you start doing this, you will instantly become a better programmer. Think about what you are doing, try to understand it, come up with a better solution, etc. This just adds more tools to your nerdy tool belt, which ultimately makes you a better programmer.

5. Get involved

Unless you are going to work for Initech where there are a 1000 programmers, no one cares about your resume, what college you went to, your GPA, etc. In my experience, this industry focuses on small elite teams. Part of what’s great about ruby is the ability to get more done quicker with less resources. This is the trend. That being said, employers are more interested in what you can do vs your qualifications. Even in today’s crappy economy there are still companies looking for ruby programmers. I recently just got done hiring for my own company. Guess what I looked for more than anything else? Open source involvement and a blog. To me this shows confidence in what you are doing and that you want to show off your abilities. I can openly see how good of a programmer you are, etc. When I got resumes I did not look at what college they went to, what companies they’ve worked for, I looked for their own website, a github account, etc.

All that you need to do to set yourself apart from the competition is put up a blog and have some open source involvement. My only regret is that I wish I would have done it sooner. If you haven’t done anything, at least start with a blog. If you have an interesting post, put the link on rubyflow. That’s it, you are on the radar. Which leads me to my next point…

6. Avoid mephisto

If you’ve seen my blog before you will notice that it has changed. I recently switched from mephisto to wordpress. I’m not going to ramble about this because there is no point. I am just sharing my experience and trying to save people some time and headaches. Maybe I have a little chip on my shoulder because mephisto has wasted a lot of my time, but that’s the point of this post. I believe new people have taken over the project so it will be interested to see where it goes. The older versions of mephisto were very bad to say the least. I had to set up a number of blogs using them, including my own site. I can not tell you how much of a pain in the ass they are. If you want to customize them, feature wise, you are SOL. Don’t bother modifying the source because you will not know what the hell is going on. It literally blew my mind that I was looking at a rails app developed by someone on the rails core. So far I have been very impressed with wordpress. Styling it and extending it has been very easy, and there has been a plugin for just about anything I need to do. Also, it takes up a fraction of the resources on my server.

7. Stay in the loop, RSS is your friend

You should be using RSS, if you are not, you are going to fall behind very quick. Subscribe to important blogs, read the new posts that come in, or at least quickly scan them. Ruby and rails is a very fast paced industry. I feel bad for the people writing books for rails because they quickly become outdated, some become outdated before they even have a chance to get published. That being said, you should spend at least 10 minutes every morning reading through RSS posts. That 10 minutes could introduce you to a new feature that could save you hours. If you don’t know where to start, start by subscriing to Rails Envy. They basically gather all of the important things that happen on a weekly basis and fill you in. If you commute to work, download their podcast and listen to it on the way to work. If you are trying to become a better ruby programmer, there is no reason why you should not do this.

8. Have balance in your life

Take some time for yourself to get outside and away from computers. I find that I am much more productive when I have a good balance in my life. I enjoy work more, my work is better, I am more creative, etc. I’ve been on both sides of the fence and I would venture to say that I probably would have been more productive during those 80 hour work weeks if I had taken some time away from the computer. If programming is your livelihood you should give this some serious thought. The last thing you want to do is establish a career in something that you no longer enjoy because you burned yourself out.

Need some help: Searchlogic 2.0

2009-04-17T20:09:54Z

Searchlogic was the first gem I built. I learned A LOT along the way and I continued to learn after releasing it. As such, there are some things I would do differently now. I would say the #1 lesson I learned is don’t release a complicated gem as your first gem. For example, my first gem should have been Settingslogic. What makes Searchlogic complicated is NOT idea behind it, its the integration with ActiveRecord, and the influence ActiveRecord had on the library design. I’m not sure if you’ve ever peaked in the ActiveRecord internals, but it’s by far one of the most complicated libraries I’ve ever had to deal with. I feel like I know my way around ruby pretty well, and there are still some things in ActiveRecord that kick my ass. I’m sure ActiveRecord is in the same boat as Searchlogic, if DHH or the rails team had to start from scratch, I’m sure there are some things they would do differently. Writing an ORM library is no easy task, and ActiveRecord is an excellent solution. Probably much better than anything I could do myself.

That being said, just like any library, there are new bugs and problems people find when they use them in unique situations. This is fine and expected, the problem is that solving these problems and writing tests for them takes a lot more time than it should because it is complicated. Between my other open source projects and my job I simply do not have time to keep up with all of them. So I have 2 choices:

Stop supporting the library and let someone else take it over
Rewrite the library so it is easily maintainable

I am choosing #2. For 2 reasons:

I have some very important projects using this library, as I’m sure you do. So I am personally invested into this library.
Authlogic

Why Authlogic? Because I feel VERY good about the design behind Authlogic. Not to sound conceited, but the design behind it is really clean. It’s extremely easy to maintain and understand. As such, I don’t have to spend that much time on it. Most of the time I spend on it is adding new features that people need, not fixing bugs. Which is a lot of fun. I rarely get problems reported with Authlogic. So instead of writing tests and fixing bugs I am advancing the library. I want to have the same feeling with searchlogic, and I’m just not right now.

A call for help

That being said, I want to see if anyone wants to help out. I have some really good ideas about how to do this and keep it clean and simple. Because of this, I think it could be done in a relatively short amount of time. More importantly, it could be a fun project and a good experience for both of us.

The idea behind Searchlogic 2.0

If you are interested, here is the big change that I want to make. I initially want to write the library as a stand alone class, with no ORM integration. I just want to build a simple library the people can use to create search objects, etc. Then you could take this object and boil it down to whatever format you want, including ActiveRecord find options. So essentially you would have an ActiveRecord adapter. This is the key to keeping the library simple, it doesn’t have to rely on ActiveRecord and it’s not influenced by some of the poor design decisions behind it. For example:

search = Searchlogic.new
search.where.name_like = "sweet deal"
search.page = 2
search.per_page = 10

search.to_ar_find_options
# =>  {:conditions => ["name like ?", "%sweet deal%"],  ffset => 10, :limit => 10}
search.where.to_ar_conditions
# => ["name like ?", "%sweet deal%"]

search.to_sql
# => "where name like '%sweet deal%' limit 10 offset 10"

search.to_dm_find_options
# DataMapper find options

See where I’m going with this? It’s strictly influenced by what we think is useful when searching data. It’s not influenced by SQL, ActiveRecord, or anything. It’s completely stand alone. I think this is a MUCH cleaner approach. It completely separates Searchlogic from ActiveRecord, so its a stand alone library. I don’t have to worry about “ActiveRecord changed this…”, or “ActiveRecord added this…”, etc.

I want to keep searchlogic clean and simple with no dependencies. I think this project would be a lot of fun, but the fact is that I do not have time to sit down and write a new library like this and still fulfill my responsibilities at my job. Gotsta pay them bills.

Authlogic generators? All of the cool kids are doing it.

2009-04-17T07:30:03Z

Lately I’ve been getting a lot of pressure to add a generator to Authlogic. One of the big things I “tout” about Authlogic is the fact that is does not need generators, not anymore than any other RESTful controller you create. Authlogic can pull this off because it’s intuitive, it works just like every other model you have in your application. Unless you want to customize how it works, there’s no learning curve. If you know how to set up a RESTful controller for an ORM model, then you know how to set up a RESTful controller for an Authlogic model.

In my opinion generators are meant to be a starting point for repetitive tasks that have no sustainable pattern. By repetitive, I mean repetitive in a single application. Ex: multiple controllers, multiple models, etc. 95% of applications are going to create 1 Authlogic model and 1 controller for that model. If they are creating more than one, it is mostly likely for a highly unique situation where a generator would be of no use. Which leads me to my question:

Why not just create your own personalized base application or template that you can start from when you need to start a new application?

This is exactly why rails templates were created. They were created for this exact problem. A generator is never going to please everyone, and if it does, it would have a million options and be extremely complicated. Also, I don’t know about you, but I am extremely picky about my code. Even if my code and someone else’s code does the exact same thing, I want my code formatted a certain way. This is a big reason why I dislike restful_authentication. All of this code, that I do not like, gets inserted into my application. It just feels dirty. I’d much rather build my own authentication solution into a base app, that I like, and use that in my next application.

I just haven’t been convinced that creating a generator for Authlogic is a good use of my time. If you can convince me otherwise I’ll gladly do it. It’s not that I don’t want to spend the time, its that I truly feel a base app or a rails template is a better solution.

What do you think?

Resourcelogic, what do you think?

2009-04-02T22:32:00Z

I recently released the beta to a library I have been working on: Resourcelogic.

I’m really excited to release this because it’s my favorite “personal” library. I’ve been waiting to release it because I wanted to give it a thorough test drive on an app I am developing. I can say, without a doubt, that because of this library, the app is the cleanest app I’ve written to date. I love it.

The reason I am writing this post is because I want to see what you think. Before I officially announce it, clean up the documentation, add in my tests, and take it out of beta, I wanted to get some feedback on it. So if you have a minute, take a look at it and let me know what you think.

Oh, and I’d like to give a lot of credit to James Golick. This project spawned out of his resource_controller plugin, which is an excellent plugin.

Authlogic 2.0 with some OpenID goodness

2009-04-18T00:09:27Z

This post is somewhat of a 2 part announcement:

The release of Authlogic 2.0
The release of Authlogic OpenId 1.0 with a live example

I apologize for this post being a little delayed, this week was unusually busy for me and I wanted to wait until I had time to write an article giving these 2 things their due diligence. So let’s get right to it.

Authlogic 2.0

I won’t bore you with ALL of the changes I made to v2.0, almost all of them are internal and a result of me being OCD, so I’ll try to fill you in quickly. The only change you might have to make when migrating is how acts_as_authentic accepts configuration. Instead of accept a hash, it now accepts a block. Ex:

acts_as_authentic do |c|
  c.my_value = my_option
end

If you want a more detailed list of changes you can check out the github commit history or the CHANGELOG.

That being said, I basically rewrote the entire library. I literally created a new folder for Authlogic 2.0 and went from there; pulled over any reusable code, etc. Why would I do this? Because the focus of v2.0 was around the public API. So much that I rewrote the library to use its own API. If you are curious, take a look at the Authlogic::Session and Authlogic::ActsAsAuthentic submodules. Any of those files could be easily pulled out into their library and be plugged into Authlogic. So if you are wanting some examples of how to extend Authlogic just glance at those sub modules. If you are super geek, I would love to hear your thoughts on the internal design of Authlogic. I feel very good about it and if you can punch some holes in the design I would be pretty impressed, more importantly I think its a good opportunity for both of us to learn something.

OpenID so easy you might think its from New Jersey

Now here is why Authlogic 2.0 is great. Because of 2.0 I was able to write a really nice OpenID “add on” for Authlogic. Check it out on github or see the live example. I’m not going to go into the set up and installation, because its all in the docs. Instead I’ll tell you the basic design behind it and how it works.

To really authenticate with OpenID you need to do 2 things:

Verify their OpenID when the user registering or updating their profile.
Verify their OpenID when they are logging in.

As you probably saw in my older OpenID tutorial, one of the downfalls what that it didn’t accomplish #1. It just authenticated when the user tried to log in. With Authlogic 2.0 this is no longer the case. I feel like it’s a very solid OpenID solution.

The best part is that its dead simple, it really doesn’t get any easier than this. Just to prove my point, here is the basic setup process:

Add a field to your database to store the user’s openid_identifier
Install the authlogic-oid gem
Install and setup the openid_authentication plugin by the rails team.
Save your Authlogic::Session::Base and ActiveRecord::Base objects with a block whenever you want to verify their OpenID.

So instead of this:

if @user_session.save
  redirect_back_or_default account_url
else
  render :action => :new
end

Do this:

@user_session.save do |result|
  if result
    redirect_back_or_default account_url
  else
    render :action => :new
  end
end

Why? Because the AuthlogicOpenid add on takes care of redirecting the user to their OpenID provider. When it redirects it needs to skip that entire block of code to avoid a DoubleRender error.

The Authlogic challenge

Now there there is an established and well defined public API I encourage you to write your own add ons. There are 3 that I am going to need in the near future, and I feel would be extremely beneficial to other authlogic users:

AuthlogicImap – authentication via IMAP. Meaning users could provide an email address and password and Authlogic would try to authenticate with their IMAP server. This is a GREAT solution for intranet authentication. In fact, I plan to implement this in my company as soon as I can. This way they will have one password for everything: email, intranet apps, etc.
AuthlogicFacebook – I don’t think this requires a lot of explanation, but the goal of this would be to authenticate with Facebook’s authentication solution: Facebook Connect. I really think if a single sign on solution becomes popular, this is the one, because of the sheer volume of users on Facebook it’s impossible to ignore.
AuthlogicLdap – Allow users to authenticate via LDAP.

So if you are wanting to write an add on for Authlogic, I encourage you to do one of the above, because I feel those would be the most widely used. But if you want to write something else, go for it.

What do you get?

To get this moving along, I am offering incentives. I know it kind of goes against the basic principles of open source, but what the hell, I figured I would try to spice it up a little bit.

If you write an Authlogic add-on that is approved by me I will personally sign a mouse pad and send it right to your house, or work if you want to show it off to your colleagues. Even better, have it “accidentally” sent to your girlfriend’s house and guarantee yourself some action that night.

Alright, enough of that, here is what you really get:

Officially announce it on my blog and link to it wherever relevant (Authlogic docs, wiki, etc.).
Authlogic commit rights, if you want them.
Employee discount at neco.com (one of my companies).
$25 itunes gift card. (only if you write one of the above 3)

I know #3 is kind of lame, but hey, if you like going to events I can get you tickets to just about anything at a steal.

So that’s my speech, let me know what you think.

The future of Authlogic: add ons

2009-04-17T18:41:37Z

It’s funny to say this, because Authlogic has only been out for about 4 months, but I feel like it’s a pretty solid, lean, and mature library. I feel this way because of the community around Authlogic. At lot of people have contributed bug fixes, feature additions, performance enhancements, etc. It’s been a really fun experience and shown me first hand how great open source can be on the other side of the fence.

That being said, feature-wise, it’s starting to plateau. At this stage it is tempting to start adding extraneous features that bloat the library. Obviously, no one likes a big bloated, complicated library, so I’ve been pretty picky with the features added. There is a very fine line that separates features that belong in an optional module and features that belong in the core that are toggled via a configuration option. Instead of slowing the growth of Authlogic by being Mr. anti-bloat, it would make more sense to provide a venue for extension, otherwise called a public API. I know that’s a pretty fundamental idea, but that’s what this post is all about. The last few releases of Authlogic have focused hard on the public API. Authlogic uses it’s own API internally and I have also used it in a few projects of mine. It has worked out great. So far, I have not encountered any limitations and I am confident it’s ready for prime time.

Getting the ball rolling

So I thought I would get the ball rolling with a few “add on” gems for authlogic. Here is the list I have so far, in the order of priority. I wanted to reach out to you and see if you have any suggestions.

authlogic_openid (code is already written)
authlogic_ldap (code is already written)
authlogic_facebook_connect
authlogic_captcha
authlogic_authorization (still somewhat on the fence with this)

What do you think? Am I missing anything obvious? Do you have any other “add on” gems you’d like to see added?

I plan to release the first gem in the next couple of weeks.

P.S. – the picture contains an oxymoron, it’s a tough one to figure out

Searchlogic 1.5.7 – Complex searching no longer a problem

2009-04-17T03:34:38Z

Searchlogic 1.5.7 is by far my favorite release because it takes Searchlogic to a whole new level. It solves a problem I thought it would never solve. Before I explain the new features, let me give you a quick run down on my perspective of Searchlogic:

Fillin’ a brotha in

A lot of people think Searchlogic is a “console” searching utility. Meaning you can pop into your console and execute some simple searches quickly and easily, and it is, but by accident. My goal with Searchlogic has always been freeing your application of searching clutter. If you’ve ever done an app with searching you know there is a lot of “cruft” that goes along with it: nasty controller actions, excessive named_scopes, etc. Searchlogic rids you of this by representing an entire search’s criteria with a hash: conditions, ordering, pagination, the whole package. Why is this nice? Because GET and POST parameters are a hash. What’s nice about that? Because an HTML form’s sole purpose is to send GET and POST parameters to a URI. This means you can build a form that represents your entire search. Adding a condition to your search is as easy as adding a field to your form. This ultimately makes your controller dead simple, frees it of any search clutter, and rids your models of excessive named_scopes. Here is what your controller action should look like with Searchlogic:

@search = User.new_search(params[:search])
@users = @search.all

Complex searching in tha house

This is great for simple searching, but how do you represent complex searches this way? Let’s take this query:

select * from users where id > 5 AND
  (email LIKE 'ben%' or email LIKE '%binarylogic.com') AND
  first_name LIKE '%ben%'

Before, Searchlogic couldn’t handle this. It did not support grouping (parenthesis) and it did not allow you to mix and match “AND” and “OR”, you had to pick one or the other. Why? Because I never intended for Searchlogic to replace complex searching. If you need to perform a complex search there is nothing wrong with using Searchlogic in conjunction with some named_scopes. SQL is not bad, but what is bad is that all of that searching cruft starts seeping back into your project. All of a sudden your controller is not clean, your form has to stray away from using the form builder, and your model gets cluttered with named scopes that you are only using for one section in your application. Searchlogic fails to meet its goal of keeping your application free of “search clutter” and a tear runs down your cheek.

Slap a prefix on it!

Solving the problem of mixing “AND” and “OR” was easier than I thought. The only major change I had to make was making the conditions order relevant. The order you set your conditions is the same order they will appear in your SQL statement. Before, the conditions were stored in a hash, where order was not preserved. Now you can slap an “and_” or “or_” prefix in front of your conditions:

search = User.new_search
search.conditions.name_like = "Ben"
search.conditions.or_email_like = "a@a.com"
search.conditions.and_id_gt = 5
# => name LIKE '%Ben%' OR email like '%a@a.com%' AND id > 5

The last condition “and_id_gt” could also be written as “id_gt”, because, by default, we are joining with “AND”. Not specifying a prefix uses whatever you are joining your conditions with by default, specifying a prefix will always use that join. If you want your conditions to be joined by “OR” by default just do:

search.any = true

You best wrap it with some parenthesis

What about grouping conditions with parenthesis? No problem. Take the above query:

search = User.new_search
search.conditions.id_gt = 5
search.conditions.group do |group|
  group.email_begins_with = "ben"
  group.or_email_ends_with = "binarylogic.com"
end
search.conditions.first_name_contains = "ben"
search.all

What about a hash?

search = User.new_search(:conditions => [
  {:id_gt => 5},
  {:group => [
    {:email_begins_with => "ben"},
    {:or_email_ends_with => "binarylogic.com"}
  ]},
  {:first_name_contains => "ben"}
])

What about a form?

- form_for @search do |search|
  - search.fields_for "conditions" do |conditions_array|
    - conditions_array.fields_for "[]", search.object.conditions do |conditions|
      = conditions.text_field :id_gt
      - conditions.fields_for "group" do |group_array|
        - group_array.fields_for "[]" do |group|
          = group.text_field :email_begins_with
          = group.text_field  r_email_ends_with
      = conditions.text_field :first_name_contains

You will notice the hash and the form are implementing arrays, thats because hashes do not preserve the order. In our case above, order is important to us. What does preserve the order? An array. So if order is relevant to you, then you need to structure your conditions into an array. There is no other choice with this, because forms can either submit a hash or an array of parameters.

I know what you are thinking: “the above looks a little confusing and messy”. I agree with you, to a point. The word “messy” is a relative term. In our case, we have no other choice, this is the 100% correct way to do this. That being said, this is clean, because there is no other cleaner option. Sorry to be a debbie downer here, but this is how forms work, there is nothing I can do about that. Regardless, the above is still cleaner than having a nasty controller action or adding a bunch of named_scopes into you model. Your search logic is nice and DRY, in one spot: the view.

99 problems, but complex searching aint one

I think this is pretty nifty, now you have the tools to construct any type of search in your form. I’ve been getting a lot of emails asking me about this, and I had to be a debbie downer and tell them to use named scopes. Now you can ditch the named scopes and keep your search logic nice and DRY in your form, where it probably belongs.

The last thing I want to say is that there is a time and a place for a named scope, by no means am I discouraging them, because they are by far one of the nicest features in ActiveRecord. But something about creating a complex named scope or a bunch of small named scopes for a single action in one of my controllers felt dirty. It felt like clutter. I knew I would never use those named scopes anywhere else, and they were solely for that search form. After a while all of these named scopes start overlapping and start sharing search logic. If you’re extremely picky like me, your don’t feel like your code is DRY. So how far do you go to break down a named scope? Breaking them down too much defeats their purpose, but not breaking them down enough seems to create redundant search logic. Searchlogic solved my problem with this, now all of my view specific search logic is where it should be, in my view.

Tutorial: Easily migrate from restful_authentication to Authlogic

2009-04-17T03:35:03Z

I’ve been getting a lot of emails asking the best way to migrate from restful_authentication. Where it gets complicated is in the password encryption methods. Authlogic and restful_authentication use different methods. You don’t want to change this method because it will break backwards compatibility with your current passwords, meaning no one will be able to log into their account. Fear not, because I did all of the hard work for you…

Use the same password algorithm as restful_authentication

# app/models/user.rb
class User < ActiveRecord::Base
  acts_as_authentic do |c|
    c.act_like_restful_authentication = true
  end
end

Transition to one of Authlogic password algorithms

The first thing you need to do is make sure your database field “crypted_password” and “salt” allow for the storage of at least 128 characters (assuming you are migrating to Sha512). restful_authentication uses Sha1 which is 40 characters. If you are limiting the size, you need to create a migration that looks similar to.

change_column :users, :crypted_password, :string, :limit => 128,
  :null => false, :default => ""

change_column :users, :salt, :string, :limit => 128,
  :null => false, :default => ""

Now just tell acts_as_authentic what you are doing:

# app/models/user.rb
class User
  acts_as_authentic do |c|
    c.transition_from_restful_authentication = true
  end
end

You could pass an optional argument to transition to any password algorithm you want. By default Authlogic uses the Sha512 algorithm, but let’s say you wanted to transition to the BCrypt algorithm. No problem

# app/models/user.rb
class User < ActiveRecord::Base
  acts_as_authentic :transition_from_restful_authentication => true,
    :crypto_provider => Authlogic::CryptoProviders::BCrypt
end

For more information on BCrypt checkout my blog post about it.

What’s the difference?

act_like_restful_authentication will not change a thing, your users passwords will remain in the same format. From your database’s perspective, it will be as if you are using restful_authentication.

transition_from_restful_authentication starts changing your users passwords using the Authlogic passwords system that you specify with the :crypto_provider option. How does it do this? It’s simple, every time a user successfully logs in and their password is encrypted with the restful_authentication algorithm it will update their password with the Authlogic algorithm. When a new account is created it will use the Authlogic algorithm. This allows your user base to slowly transition and allowing them to still be able to log in.

That’s it. I’m not going to go into the Authlogic set up because I already have a tutorial on this.

Let me know what you think or if you have any questions.