Author Archive

Rails: Completing Requested Action After Authentication

February 26, 2008

Within Seekler, we have several actions that are only available to logged-in users. We wanted a general solution that would first redirect the user to login or create an account and then complete the action the user initially requested. The primary motivator for this was non-logged-in users clicking ‘create your own list’ on a Seekler list. If a user clicked this link, we wanted to allow them to login or register and then have the list creation action take place and return them to their newly created list. We had other cases of site actions, that also required being logged in, so I was hoping to find a simple way to do this across the site.
We use the acts_as_authenticated plugin (I know most people are now using restful_authentication, we haven’t switched yet), which relies on before_filters to verify users are logged in before using logged-in-only actions. I ended up just adding one line into that system that makes it simple to return the user to his or her previous action after logging in.
In a controller using acts_as_authenticated, there is normally a before_filter requiring authentication before any actions except the actions available to all visitors

before_filter :login_required, :except => [ :show, :list]

This means that on an action like :create the user will end up calling the login_required method in /lib/authenticated_system.rb. If you add the following line to that method, it will record the information you need to redirect the user back to the action they intended after they login.

def login_required
username, passwd = get_auth_data
self.current_user ||= User.authenticate(username, passwd) || :false if username && passwd
session[:last_action] = request.env['REQUEST_URI'] unless logged_in? && authorized? # add this line!
logged_in? && authorized? ? true : access_denied

At this point, the filter will direct all non-logged-in users to your associated login failure action, in our case /account/login
In the login action, (after doing any other login specific code) you just have to redirect the user if they have :last_action set

def login
# login stuff
if session[:last_action]
redirect_to session[:last_action]
redirect_to :controller => 'account', :action => 'index'

You can add a bunch of other things like ignoring certain actions you don’t want to forward the user to, or also return the user to wherever they were before clicking a login link, but this simple version gives the basic idea. Obviously this code is specifically for the acts_as_authenticated plugin, but it should be relatively easy to generalize this same sort of solution to work for any type of authentication that is in use on your Rails project.
If you want to see this in action, just visit a list like Best Charities on Seekler and click the ‘create your own list’ link in the top right.


Capistrano path and environment variable issues

February 12, 2008

We have been using Capistrano for awhile now and it has been working great. Recently, for reasons we are not sure of, migrations started failing. When we executed ‘cap deploy:migrate’, we would get an error “no such file to load — rcov/rcovtask”. After a lot of investigation, I found that this meant that the system, for whatever reason, couldn’t find our gems anymore.
Since Capistrano hardly gives any information when failing, it took awhile to figure out what was going on. sshing in as our Capistrano user, and running printenv, showed that the environment variables for the Capistrano user were all set as expected. After some investigation, we learned that since Capistrano runs a non-interactive user, the environment isn’t set up the same. To figure out the environment that Capistrano was running as, I created a task and added it to config/deploy.rb

desc "Echo environment vars"
namespace :env do
task :echo do
run "echo printing out cap info on remote server"
run "echo $PATH"
run "printenv"

After saving your deploy.rb file you should be able to execute that command on your servers by running “cap env:echo”.
This printed out a different path than sshing in as our Cap user and also was missing the RUBYOPT=rubygems environment variable. Obviously, not having RUBYOPT set was causing the problem of not finding out gems.
So next, we just had to set up the correct environment for the non-interactive Cap user. This was a little tricky since non-interactive users don’t load all the environment settings like normal users. This is done for extra security. Unfortunately, it means it is a little more annoying to set up these variables, and not as well documented.
If you need to add environment variables or change the PATH for a non-interactive user, you need to edit two files. First ssh in as the user under which the non-interactive scripts will be run. Then, in that user’s home directory, create a file ~/.ssh/environment (in our case /home/cap/.ssh/environment). Edit this file and add whatever environment variables you need (in our case RUBYOPT=rubygems), and save the file. Then edit /etc/ssh/sshd_config, and add the following line
PermitUserEnvironment yes
I would run ‘man sshd_config’ to make sure your version of sshd supports this option, as some older versions and distros (we are using Debian) do not. Then restart ssh by running “sudo /etc/init.d/ssh restart”. At this point, you should try running “cap env:echo” again, which should print the RUBYOPTS environment variable set correctly. This fixed our problems and migrations began running again without a problem.

Seekler’s top 10 reviewers

February 5, 2008

Seekler added the ability to add full reviews to items you rank awhile ago. Only recently have we been showing off this feature, and making it obvious to the users. It has been popular for users to read reviews about the items ranked on our lists. So as a little thank you to our users that have started adding reviews, I present the top ten users with the most reviews on Seekler.

  1. dan
  2. ben
  3. michaelwong38
  4. peter
  5. vacelts
  6. DomFilosa
  7. galactic_dev
  8. drew.klein
  9. nicole
  10. Jezebel

Congratulations, and thanks for your time and reviews, keep up the good work.

Seekler List Widget

December 4, 2007

One way we think Seekler can be useful is for interacting with readers on a website. Publishing a list on a blog is a common post. The comments on published lists are commonly suggestions for other things to add to the list, or the commenter’s own ordering of the list. Trying to read through all the comments and combine them mentally is pretty hard. If you create lists on your blog with the Seekler widget, not only do you have a nice looking list, you also have a way to collect feedback from your readers in a useful way. For instance compare, Most Wanted Guitar Hero 3 songs with a blog post on that topic. Below I have included my list of Seekler feature requests, you can also check out what the community is requesting. Feel free to contribute to the list.

The widget shown above is our first test of a widget that will show one specific list. We also have a widget that will show all lists by a specific user.

Take some time to check these widgets out and give us some feedback so we can improve them and make them ready for release for all of our users.

Seeking Our Niche

November 21, 2007

We originally built Seekler with a few key niches in mind, including comic books, programming resources, and movies. We have kept Seekler fairly general hoping that it could serve a large range of areas. As we have approached launch we have discussed many niches we thought we could target with Seekler, but we didn’t write down or fully develop our thoughts. We knew that we couldn’t try to attack all of our niches at once and that some would be a better fit initially. We also knew that some niches were already well-served by existing sites like Amazon.
After a few of our Seekler pitches didn’t go as well as we would have hoped, we realized the example niches we used heavily affected how people thought about that site. Sometimes coming up with the examples on the spot didn’t lead our conversation in the right direction. We realized we needed to spend some time and reflect on which niches Seekler could be perfect for and which were not as good. After working on our niche list, we started seeing patterns and discovering new niches we think Seekler could serve. Figuring this out has been incredibly valuable, helping us focus our development.
To help us focus in on the best niches we created a graph like so:
We then started placing our ideas along the graph until patterns began to emerge. It forced us to realize some of the topics we thought we could serve were actually bad matches, while other topics we never considered were well-suited for Seekler. The resulting graph can be seen below.
One pattern we noticed is that Seekler is not good at niches that require professional reviewers. We previously used digital cameras as an example for a good product people could use Seekler to narrow their choices down and then find in-depth reviews. It turns out the using the community review process for digital cameras really makes no sense. We allow a large community to build up opinions by offering lists in order of best to worst. The average consumer only buys one camera every few years, how could they rate their 10 best digital cameras every year? Only professional review groups can get full collections of cars, cameras, and other more expensive or rare items. These are a bad fit for our community review process, and well served by professional reviews which often fully review the entire market of items.
Seekler is excellent at products that people buy or use regularly and cost little to no money. The average person goes through a lot of music, books, comics, and games, for example. So it is easy for a comic fan to list his favorite Marvel comics. These niches are a better fit for the Seekler community and actually harder for expert reviewers to cover, as they can’t expect to have in-depth reviews across the entire space. Another reason community reviews can be useful is that in some cases, the opinion of experts isn’t as important as much as say the opinion of your friends, people your age, or of a diverse community in general. There are many areas where the long tail of reviews is often poorly served, while there are clearly many fans that exist with valuable opinions on often overlooked niches. For instance I think Seekler will reach a collection of the top 100 punk songs far before Rolling Stone will ever create that list.
In some ways we see the community review process as complimentary to in-depth reviews. While topics like punk music the opinion of the community may be enough to warrant a purchase. There are other cases where the user still may want in-depth reviews, after narrowing down your choices. We think the community review process can help you quickly narrow down the list of comics or anything you’re interested in faster than trying to read a huge collection of expert reviews. In this case while the user still may really be interested in in-depth reviews that get into the details of a comic, Seekler can still help them find interesting new comics which they can then follow up on.
Just learning these concepts about Seekler was important, as it helped us to improve our pitch. It also helped us realize some of the features we had planned were more important than others. Taking a step back from our code, after months of programming, and thinking more about the problem we are trying to solve gave us a better focus on our problem and a better understanding of our users. We don’t think we have found all of the best niches to initially focus on, but we have a better understanding where we should begin. If you have any suggestions, we are all ears as we are hoping our initial users will also help lead the direction of the site, by suggesting niches for Seekler to target.

Review: Website Monitoring with Mon.itor.Us

November 16, 2007

I thought it might be a good time to share another tool that we work with. After running multiple sites over the years, I eventually started looking for tools to verify my site was up and running. I started by writing my own scripts to just verify my sites were accessible and email me if there were any problems. Then I found some online services that would check this for me, but they always seemed to run into their own issues. At one job, we used Nagios which is a great piece of Open Source Software, but may be a bit of overkill to set up for simple website monitoring. If you need customized and complex monitoring, I think Nagios would clearly be the way to go, but if you have simple needs, I think easier solutions would make sense.
So while continuing my search for an optimal solution, I eventually stumbled upon Mon.itor.Us, which has been a great solution for us. It is very easy to set up, most of the services are free. It can send weekly reports or only notify you when there is a problem on your network. It has some nice features such as accessing your site from a few locations across the globe, which gives you a better picture of your site’s response time.
Mon.itor.Us offers monitoring for HTTP, HTTPS, FTP, SIP, TCP, UDP, IMAP, SMTP, POP3, PING, and DNS. The site also offers other monitoring services like user agent tracking, site visitor statistics, and other options. This more than covers our simple needs: in fact, we use other services for our visitor statistics.
Mon.itor.Us isn’t perfect, but has served us well. We wanted to get SMS notifications if any of our sites went down, which isn’t a free service of Mon.itor.Us. Seeing as we didn’t want to set up our own monitoring and dealing with enabling SMS, it was easily worth the $5 dollars that we spent to enable SMS notifications for our account. The time saved by outsourcing this function of our IT easily covers the minor cost. The only other complaint is that the site’s UI can sometimes be confusing. For instance, when I was trying to edit my account information, I could only figure out how to add new accounts, but not edit existing ones. It turned out that after viewing the ‘new account’ form you could then click on existing account names to edit them. The dual use of the form which initially is only for adding accounts wasn’t clear to me. Other than these minor complaints the service has worked extremely well for us.
Mon.itor.Us has made it simple for us to not worry about monitoring Seekler, so we can focus on other things like coding.

Seekler alpha press coverage

October 30, 2007

Seekler is in the web news again with Mashable’s Seekler preview write up. Overall it sounds like pretty good first impressions. The comments are a little weird as they are giving out prizes for troll week in a Halloween theme. It is nice to see some links and interest popping up on the web as we start to reveal more of Seekler.

Seekler Statistics

October 18, 2007

Some people have asked how the alpha release is going, so I figured that we could share some site statistics. We have been happy about how the alpha has been going: we have been getting phenomenal feedback from our users and made hundreds of tiny improvements over the last few weeks.
Current Seekler statistics:
45 Community Lists
200 Individual Lists
1000 Items
500 Tags
40 Users
We have been sending out new invites every couple days, so if you are interested in getting a chance to help drive the direction of the site, feel free to sign up at Seekler!

Dropping the www

October 17, 2007

www is deprecated. There are many reasons people have been slowly moving away from the www subdomain: most of them are covered on For Seekler, we decided to go for short URLs, hence we build all our URLs for the non-www domain. I think it is nicer. Unfortunately, I couldn’t remove the www on old sites as they had already built up a ton of links to both the www and non-www URLs. But Seekler is starting fresh with no-www and supporting

Review of using Trac for project management

October 14, 2007

After entering our 500th ticket into our project management tool, I thought it was probably time to talk about our tool of choice. Trac is a simple open source project management tool. We decided to use Trac because of its reputation of being simple and easy-to-use in the open source world. I think the project is probably described best on its website:
“Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way. Trac should impose as little as possible on a team’s established development process and policies.” –Trac website
Ben and I had both used other issue or bug tracking software previously, but found that sometimes the software was overkill for the needs of developers. I think we have both been happy with Trac, which while keeping it simple has helped us to organize, prioritize, and share development duties. In my previous experience with other issue tracking software I frequently found that the software was more in my way and harder to deal with than was worth the effort. Most of the time, Trac has been a pleasure to use.
There are many ways teams can use project management software. I will describe the most helpful ways we have been utilizing Trac. If there are other ways teams have found project management tools especially useful let us know.

  • Using Trac we set milestones with deadlines, which help prioritize our development towards our next release’s goals.
  • Viewing progress on our current milestone, which helps us to estimate our release schedule.
  • We create bugs and issues which by default are assigned to the ‘nobody’ user, which either of us can accept and begin working on.
  • We can assign certain tasks to the ‘both’ user, which lets us know this is an issue we need to discuss before either of us moves forward on the ticket.
  • After fixing a bug we assign the ticket back to who ever created it so they can verify it was fixed as expected.
  • We have a ‘future’ milestone that we use to create tickets about ideas for additional features or improvements that we aren’t planning on working on soon, but want to be reminded of in the future.
  • Using Trac lets us have a searchable archive of bugs, issues, and features which we can review as necessary.

We have had a few complaints with Trac.

  • The search feature doesn’t work well. Trac needs an advanced search with options like don’t search closed tickets.
  • No batch editing. We frequently have wanted to make the same change to a large collection of tickets.
  • There should be more sorting options after a query. I frequently want to sort by two options such as by ticket owner and priority.
  • Trac is kind of slow.

We have found it too slow to quickly just enter bugs, which we discover while working on some other issue. If entering a ticket takes much time it can throw off your train of thought. We normally deal with this, by writing issues on a piece of paper and entering them into Trac later. We still find ourselves occasionally building up a list of a bunch of trivial fixes and sharing a piece of paper or a whiteboard to see who is working on what and when each issue is complete. We only tend to do this if we just build up a bunch of tiny issues we plan on taking care of by the end of the day and many of the fixes could be fixed in nearly the same amount of time as creating a ticket in Trac. We also recently started using Trac through mod_python, which has helped to decrease the lag of the system. I will admit that we are running our bug tracking software on pretty old hardware, so I am sure running it on a decent machine would really help as well.
For a small team looking to manage their bugs and issues quickly, I doubt you could find a better product than Trac out there right now. It is easy to install, configure, and use. You also can’t really beat the price (free). For a team on a budget, that is always a nice bonus. Anyways, we know there are many options for issue management and we decided we should share our experience with Trac, which has worked well for our situation.
Trac – Integrated SCM & Project Management