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! 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.
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.
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 [email protected] for more details.
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).