Archive for October, 2007

Happy Halloween!

October 31, 2007

Have fun!


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. launches!!! (for real this time)

October 25, 2007

The wait is over – you can check out Seekler. As I previously mentioned, we’re doing a staged release, so in this version you’ll need an alpha site password to create an account. We hope to open it up to more users in the next few weeks. If you’d like to be invited, be sure to sign up.
Here are some of our most popular lists right now:

We’re very excited about this release. Please check out Seekler and let us know what you think. Any and all feedback would be hugely appreciated. Thanks!

First Public Release Coming Soon

October 22, 2007

Launching is a tricky business. One one hand …
We want to show Seekler to the world as soon as possible.
For one thing, we want to get more eyes on Seekler so we can start getting a wide array of feedback. But we also want to start building buzz, getting incoming links, etc. Just as importantly, we want to start to get a glimpse of what our scaling needs might be.
At the same time …
We want to make sure our existing users have a near-flawless experience.
We want to continue to get detailed feedback from our current small group of users so we can respond quickly and fix almost every bug they run into. Also, we want to make sure that the site doesn’t slow down to the point it’s unusable or crash altogether.
After thinking about it a lot, we’ve decided that a staged roll out makes the most sense. Here’s our current plan:
Stage 1: Publicly Viewable
First, we’re are going to let everyone get a look at Seekler. You’ll be able to see how Seekler will help you find cool stuff by checking out all the lists that are hosted on the site. However, only a small group of beta testers will be able to actually submit data at this point.
Since most of the viewing operations are cheap, we think we can show off the concept of the site to a lot of users without killing performance. We can also continue to refine the data submission and editing experience with our awesome beta testers. At the same time, we can hopefully get more users excited about Seekler and let some search engines crawl the site as well.
Estimated Release: Sometime this week!
Stage 2: Private Invitations
After that, we’re going to move to an invitation system for sign ups. We’ll expand our group of beta users considerably. If you’re interested in getting an invitation, submit your email address at Seekler
At this point, we’ll have ironed out the big issues in data submission and editing, so we can continue to invite as many users as our servers can handle. We’ll continue to incorporate the feedback we get from all our users during this expansion.
Estimated Release: Hopefully about a month or so, but we’ll see
Stage 3: Public Beta
Finally, we’ll open up the sign up system so anyone can join. We’ll probably continue to call this release ‘beta’ just because that’s so Web 2.0 ish. Then we cross our fingers and hope that we can continue to grow our user base.
Estimated Release: When it’s ready
So that’s the plan. Stage 1 is coming next week!

We’re interviewing with YC!

October 19, 2007

Dan and I are incredibly excited and honored to get the chance to interview with Y Combinator in Cambridge, MA this Nov 3-4.
For those of you that don’t know, YC invests in very early stage software companies. If we get accepted into the program, it’s quite literally the best thing that could happen for Seekler at this stage of development. We really, really want this.
But we’re trying to not get our hopes too high – this is far from a done deal. Many of the teams that fly out to Cambridge will come back disappointed. As Paul Graham said:
“In the startup world, closing is not what deals do. What deals do is fall through. If you’re starting a startup you would do well to remember that. Birds fly; fish swim; deals fall through.”
With that advice in mind, we’re going to keep working on Seekler as if there is no chance that we’ll get accepted. You’re going to see some big announcements in the next few weeks.
As we were completing our YC application, I remember thinking that even if we didn’t get an interview, the process of doing the application was hugely valuable in itself. It forced us to understand our project and business a lot better. I feel the same way about the interview. The absolute worst-case scenario is that we interview and don’t get accepted – but that means we get to talk face to face to Paul Graham and Jessica Livingston about Seekler! How cool is that?
By the way, for those who didn’t get an interview, we feel your pain. We applied last cycle and got rejected (from both YC and TechStars). Remember that every person interviewed in ‘Founders at Work’ was rejected, often several times. They say that persistence is the single most important trait in a founder. Keep moving forward.

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

Testing Wish List

October 6, 2007

We’ve recently been working on improving our test coverage on Seekler. As a result, I’ve been thinking about some testing tools that I’d really love to have but haven’t seen yet for Ruby.
I’d been writing these ideas down in the hopes that I might implement one over a free weekend. But since it doesn’t look like I’ll have too many free weekends in the near future, I figured I’d post them here. If anyone has seen tools like these – or wants to build them – that would be sweet.
Test Refactoring Guard
All code gets messy as it grows and changes. That includes test code (and yes, you should be keeping your test code clean and DRY, just like your production code).
It’s easy enough to clean up your production code – just simplify and refactor. Your test suite will let you do so without fear (or at least with less fear) of introducing bugs.
But how do you refactor your tests? If you refactor your production code, you’ll know you messed up if a test fails. But if you make a mistake when refactoring your tests, they may not fail. Rather, they may stop checking some important condition in your production code. Your tests will still pass but your test suite is weaker.
The Google Testing blog suggests the following strategy: 1. Intentionally break your production code so that tests fail. 2. Refactor your tests 3. Make sure the tests continue to fail (in the exact same way) 4. Revert your production code to a working state.
Huh? Let’s say I have a function f and three tests for it. I intentionally break f so that my three tests fail. Then I refactor a helper method that is used in all three tests. But what if this same helper method is used in other tests methods that don’t test f? Couldn’t my refactoring break those tests? This strategy assumes that I can correctly predict exactly which tests will be impacted by my refactoring. If I could do that, I wouldn’t need any special strategies or tools to help me.
I’d prefer to have ‘safe mode’ for testing that I could enter when refactoring my tests. The simplest version could just remember simple stats about my tests and make sure they stay constant. For instance, it could remember the number of tests, the names of those tests, the number of assertions, and the types of assertions (for each test). If any of these changed, I’d get a warning.
Or the tool could use code coverage to check my work. It could do a baseline run mapping each test to the code covered by that test. If the coverage changed, I’d get a scary warning letting me know that I’d done something wrong.
Bad Checkin Identifier
We all know the feeling – you notice that something in your app is broken and you’re positive it used to work. Somehow this bug has slipped by your tests and now you need to fix it.
One of the simplest and fastest ways to fix a bug is to find the source control checkin that caused the bug. But manually going through all the checkins is a tedious and time-consuming process.
Assuming you’ve now written a test (or set of tests) that catches the bug, it’d be easy to for a tool to automatically find which checkin caused the bug. You’d feed it a span of revisions and for each one, it’d pull down the code, run your new test, and determine if it passed or failed. Once you find that revision x passed the test and revision x+1 didn’t, you’ve found the culprit.
Of course, there will be some very old versions where the test will fail because the feature being tested wasn’t implemented at all. But there still should be some set of revisions in which the test will pass. The tool would just need to be clever enough to ignore the old failures and find the transition from passing to failure.
Distributed Unit Testing
Well-written unit tests should be independent from each other and they should run quickly – so you can run them a lot. Independent computations that need to run faster? This is a problem just screaming for parallel processing – e.g. distributing tests across computers on a network.
Unfortunately, I haven’t found a widely-used, easy Ruby implementation yet. The closest thing I’ve found is this, which I’m planning on trying out. If that doesn’t work, I might try implementing something on top of starfish, which looks pretty cool.

Like I said, I don’t know of any Ruby implementations for these ideas, but if you do, please let me know. Are there any other Ruby testing tools you’ve been wishing for? Let me know – I’ll add them to my list in case I ever find a free weekend.

Seekler Alpha Release Completed

October 2, 2007

We have completed the alpha version of Seekler. This release includes the graphic design work for the site, the initial feature set planned for launch, and far too many bug fixes to count. We had hoped to have this release out a bit sooner, but various things kept us holding it back and in the end I think we have a better application for it. Along with announcing the Seekler alpha release, we are happy to share the first screen shots of our application in action. I can’t begin to describe how cool it is to begin to see users testing out our application.
My current ‘Best Movies’ list. My rankings are automatically merged into a community list, which I can view by clicking on the ‘view community list’ tab.
We have been touching up this release with the help of many of our friends and family. A huge amount of thanks goes out to everyone who has been using the site and giving us feedback. It has been incredible to get so much information about Seekler. We would have never been able to improve the usability of the site as fast or to the degree we have without all of you. After a couple weeks of being live, we have closed out most of the glaring problems and will start working on issues we had been waiting on until after finishing the alpha version. We of course will still be looking for more feedback, making improvements, and fixing bugs quickly as issues are pointed out to us. If you weren’t invited to try out this release, don’t worry: we will be inviting more people very soon. It is time the for our users to help guide the general direction of Seekler.
The community list for ‘Seekler Slogan ideas.’ There are eight users contributing, resulting in ‘Seek Together’ being the #1 slogan suggestion overall.
We are excited to start sharing more of Seekler’s features and getting additional feedback on the screen shots. If you have a particular aspect of Seekler you are interested in knowing more about, let us know and we can start sharing more about our current vision for the product.