bhb

Disclosure: I'm one of the founders of Devver. We're currently looking for companies with long-running Ruby test suites to try out our beta. We're also hiring http://devver.net/jobs

You're right, it is a concern for many companies. However, as services like GitHub, EngineYard, and Heroku show, many companies are willing to send their code to 3rd party services if the value proposition is compelling and the security is good.

In the future, we're certainly going to work to support more languages, but we felt it was important to focus on a single language early on.

There is not currently a way to specify the way tests are split across machines or the order. We're working on a solution but it hasn't been a problem yet for our current users.

Or we might just spin it as a feature - we find order dependencies in your tests!

You're right - we're currently focused on large code bases with tests that take a few minutes or more. If your tests run in a second, there isn't much we can do for you.

Good idea about specifying RSpec, etc on the front page.

Thanks for the feedback!

That's a good point. We've been thinking about how to express the speedup more clearly. This is super helpful.

Awesome feedback. We'll work on adding more info to really make the value proposition clear.

Thanks for the feedback! We've been meaning to add some real-world comparisons, but haven't gotten to it yet. Good to know that they would be valuable.

Clickable link: http://devver.net

Just something to consider - there were at least two TechStars 08 teams that had summer interns that they have hired as employees. Granted, they worked more than 15 hours per week (and I think one of them was paid, but I'm not sure). In any case, if HackStars can successfully make more matches like these, it'd be a good program.

(Disclosure: I'm one of the founders of Devver, one of the TechStars 08 companies)

I think that some of the variables will likely need to be adjusted (for example, 15 hours per week seems high to me), but I think the fundamental idea is interesting, although it's clearly not for everyone.

At 15 hours a week, it's clear that a volunteer developer is not going to come close to replacing a technical founder or a full-time employee. Any team that tries to primarily rely on volunteer developers will suffer for it.

I can imagine this appealing to developers (including those in college) who are strongly considering doing a startup or working for a startup, but want to learn more about the process and want to make great contacts (both technical and business).

There may very well be problems with the quality of some applicants, but assuming the application process doesn't filter them out, I would guess things will work themselves out during the summer. That is, the so-so devs will be a net drain and teams won't ask for their help, while any talented hackers won't be donating their time for long - they'll quickly get snapped up by the companies they help out (either during the summer for all equity or after a funding round for salary + equity).

Of course, this is all speculative. Maybe it won't work at all. But I suspect that connecting a group of hackers with teams that will, either immediately or in the near future, want to hire hackers could work out for everyone involved.

I second Boulder. Yes, its certainly not a big city, but its got more than its share of good restaurants and bars considering its relatively small population. Beautiful weather for most of the year, nestled right into the mountains. The startup community is stellar in my opinion. And yes, you can ride your bike almost all the time and when you can't, the buses are easy to use.

We're certainly under $10M in liability, we're confident in our model, and we're seeking less formal (but free) feedback from friends and peers on it, so I think you're right - we just won't stress about it too much right now.

Thanks a lot for the advice. I really appreciate it.

I was imagining presenting our security model to someone (or a team), having them ask questions, and then do some analysis of our systems to make sure we've implemented the model correctly (and don't have other gaping holes). Although a full audit of the code would be much more complete and secure, I was looking for a slightly different risk/cost tradeoff.

Honestly, I don't really know what kind of price is standard (or even the amount of time a audit would take). Can you give me a ballpark number?

Off the top of my head (which is likely to be way off), I was expecting something between $1000 - $3000

I have a friend who works for pMDsoft in NYC. He says its got a great startup-like environment.

http://www.pmdsoft.com/ChargeCapture/about_us/developer.html

If you want to talk to him directly, email me at ben at devver.net and I'll put you two in touch.

We're looking for a Ruby rock star here at Devver.net (http://devver.net). We're a small venture-funded startup that focuses on cloud-based developer tools. We're based in Boulder, CO, but we're comfortable working with a distributed team. If you are interested, contact us at contact@devver.net for more details.

I need to work tools like these into my development habits

That's a great point. Of course, there is a lot more upside to having the company you founded own your IP as opposed to some big company you don't control.

While I like the sparse design (and badass logo), a huge problem is that I get to site and within the first ten seconds I don't know what it does (or even why I should care). I decide to figure out more by typing an artist and click 'music search' but now it's taking forever. If I was a random visitor, I'd be gone by now.

While I expect the load time after typing will be better as you work on scaling (and work out the bugs), I still think you'd be a lot better off with a little text explaining why I should even type something in and hit 'music search'. Will I get to play music? Will I get to download music? Will I find the cheapest prices for buying music? Who knows. Just my 2 cents.

Exactly. I'd still love to see real study on whether unit testing is worth it (which our survey doesn't even begin to address, since it's very hard to measure). I think some good studies on that would be invaluable, but it's nearly impossible to control for all the variables, so I'm not holding my breath.

Failing that, most of the "evidence" one way or the other is based on asking people who test or don't test - and probably most testers would say that testing is great while non-testers would say testing wouldn't catch the kinds of bugs that matter. On the flip side, you have some testers saying it's not valuable (because their test quality is bad) and some non-testers saying they are sure tests would help, but only because they imagine tests to be a silver bullet.

In any case, our survey was just supposed to get a rough feel for how many people were doing testing (and what tools they used). What surprised me most was that even small teams (1 and 2 people) often had a test suite. This flew in the face of the anecdotal evidence we had previously gotten from other startups (almost none of ones we have talked to use tests).

Interesting article, but the author seems to assume that unit testing == TDD. I think weirdness of "write your tests first" is one reason people initially resist writing tests ("I can't do exploratory programming!")

I write lots of unit tests (and find lots of value in writing them), but I only do TDD about half the time. Generally, when I am writing a new feature, I write my tests after it's reasonably stable. However, when fixing bugs, I usually do TDD.

It does make it harder for me to completely throw out older versions, but it makes it way easier for me to refactor my old version into a better new version (which I think is often more productive than just starting from scratch)

I actually enjoy writing unit tests _because_ I'm lazy :).

When I write a piece of Ruby code, I have a choice: I could either write a unit test or load the code into IRB and manually test it (or even load the real app and test the code in there).

For me, doing it manually is often more work. Let's say I have five tests in my head. My code passes the first four, but fails the fifth. After I fix the bug I found, I have to manually go back and test all five behaviors again. Unfortunately, my code often has more than one bug, so this process can take awhile. Once my code passes the tests, I always run the real app to make sure there are no bugs in my tests.

Plus, for me, writing code is just more fun than doing tedious manual testing, even if it takes a little longer initially.

As with everything, there are exceptions. If I'm fixing bugs, I tend to have a TDD approach, but if I'm doing exploratory programming, I tend to not write tests until the code is pretty stable. It's also hard to unit test GUI code, so think about the expected return on your time investment.

One thing to keep in mind: tests are more fun to write (and more importantly, more effective) as you get better at them. Writing tests is an art unto itself - just because you write good production code doesn't mean you'll instantly write great test code. It takes practice.

I sometimes hear people say, "Unit testing takes too time to write and maintain!" While there will always be some costs, I've found that as I've gotten better at writing tests, those costs have gone way down, while the benefit has gone up.

Cool, I'll check that out.

I'd love for someone to make photo-sharing not suck horribly. Yes, Flickr is pretty great for some scenarios, but I still have yet to find a great solution for the following scenario:

1. I go to say, a wedding (but it could be anything) with a group of friends 2. Many people take pictures 3. After I come home, I want to easily look at, and optionally download, high quality version of all my friends photos for this event.

Right now, I see people using either Facebook, Kodak, Flickr, etc (I can't easily download high-quality collections), emailing several zips, or if they have a server, placing the photos on their and providing a link. There has got to be a easier way and I'm dying for someone to build it.

For the record, I don't think ideas are worthless. I'm just not going to build this anytime soon and I'd rather an awesome solution sooner rather than later.

I'm surprised that Puerto Rico hasn't been mentioned. My hacker friends and I dabbled in both Settlers and Carcassonne, but ultimately ended up playing mostly Puerto Rico. Great game. Unfortunately, I haven't had much luck getting my non-hacker friends to play.

A big hit in almost any group of people has been Speed Scrabble. Quick, easy to play in teams, and just great fun overall. If you like Scrabble, try it out.

Kind of cool. I could see it being a bit hard for the casual browser to find dreams of interest to them. I've seen others suggest tags or categories, either of which could prove useful. But you might also want to include a simple reddit-esque up/down vote for dreams people liked reading. That way people can just view the most interesting dreams.

Very small nitpick, but I think "It an old one, as old as forums" should be "It _is_ an old one, as old as forums".

Update: this has been corrected.

I think the problem is that often you really do want to know if customer is nil. The nice thing about having to explicitly specify this is that you localize the effects - and make it clear in your code that you want this 'pass-through' behavior in a specific part of your code.

If you wanted this behavior everywhere, you could just include this code

  class NilClass
    def method_missing(method, *args)
      nil
    end
  end

But I think this would cause more problems than it would solve.

Awesome, thanks for the advice. This is pretty much our biggest question right now (whether or not to go for the social angle and implement a facebook app), so I appreciate the feedback.