dodger

Fog Creek dev, here - we, too, have had absolutely great hires from less-selective colleges and with not-so-great resumes. But if you're pressed for time and resources and you have to use a heuristic for where to put recruiting efforts, this can be a good one.

This task used to be more distributed over the server-side devs, but having a single release manager who does this most of the time and other people who do it occasionally and/or when the release manager isn't working seems to work well.

Yes, more or less a new branch for each fix. But with git and Kiln, it's really not a drag at all; the merges are generally really easy and mostly performed by our release manager when the card makes it to 'Ready to Merge'.

One time I was talking to a designer about doing it this way. The designer said "Yeah, that's a great way to find a (look of total disdain) _local_maximum_." As usual, some truth to both points of view.

Okay, we just pushed a change so that https://trello.com/business-class will behave nicely for everyone. For now, you can sign up without waiting for beta approval. =)

Thanks so much!

Hi! Trello Dev here! Could you change the Business Class link to point to https://trello.com/c/2A9OEGta for now? That would allow people to sign up for the beta, and the current link doesn't work unless you're already approved for the beta.

(I'm currently changing the business-class route to redirect you to that card if you don't have access.)

Thanks for the kind words about Trello, we're glad you like it!

. . . and here's an example of an issue with scaling it up: http://stackoverflow.com/questions/13770826/poorly-balanced-...

Yes, I was trying to say that developing Trello is still really fun, even as it's getting bigger - we are starting to see some minor scaling challenges, but it's still a great time.

But we do use Trello to manage Trello, with a public dev board (https://trello.com/dev) and also internal boards to track things that are not yet public or that are too granular to expose externally.

Uservoice has a neat and somewhat complex setup: http://www.uservoice.com/blog/founders/trello-google-docs-pr...

And there are a bunch of good articles about how people are using Trello; searching for 'How I use Trello' turns up a lot of ideas. That being said, it's not going to fit everybody every time.

. . . and is still super, super fun to work on.

The Trello team loves WebSockets for push, and we did all of our initial prototyping and a lot of the first version doing RPC over the socket for writes and gets. However, now that we're supporting a REST API for other services to integrate with, we're moving everything other than pushing updates over to that so that we only have to support one API as we grow Trello's feature set. If we decide to go back to making requests over the socket, my best guess is we'll use the REST semantics and just send method, URI, and args in a WebSocket message and expect a response.

Fog Creek!

http://www.fogcreek.com/Careers.html

Software Developer Systems Engineer Front-End Designer/Developer Intern in software development (Summer 2012)

c is terrifying.^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HComputers are terrifying.

Yep! We intend to use our shiny, well-organized REST API for future development and probably port existing functionality to it, too!

That's great!

Agreed, it made some necessary, non-backward-compatible changes as a result of being such a young project. I think it is likely that we will upgrade to a newer version soon.

We worked around the bug (which only happened when we were doing REALLLY long queries when we disconnected a client) and moved to Linux, where the bug does not exist. Awesome sysadmin Tim GDB'd into Mongo and figured out that it was an issue with SpiderMonkey, fixed in later versions.

Actually, those have been great (and thank you for making them)! We had an outage during beta because somebody forgot to wrap an array comprehension assignment (CoffeeScript) and we didn't test right. Backbone has been really good, and while we had some complaints, I think many have been resolved in more recent versions - we're on something ancient.

Socket.io: https://github.com/LearnBoost/socket.io/issues/686

MongoDB (on FreeBSD): https://jira.mongodb.org/browse/SERVER-3927

Redis: https://github.com/antirez/redis/issues/91

. . . are a few.

I took it to mean "be forward-thinking rather than conservative."

Right now? Just what we can get out of MongoDB. We need better search, and it should be coming soon. Vote it up! https://trello.com/card/board/better-search/4d5ea62fd76aa113...

Today I'd consider going with a service, but first I'd see how https://github.com/LearnBoost/websocket.io looks. Most of our problems have been with abstractions in the socket.io client and scaling issues with server process chatter. The chatter shouldn't be necessary with websockets-only.