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.
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).
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 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.).
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? (more…)
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.
(more…)
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.
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.
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.

This post is somewhat of a 2 part announcement:
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.

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.
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:
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…