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'.
Do I understand correctly that your stable 'master' branch is always ready for release? Basically it means that changes (fixes) should be relatively small, otherwise they are released via channels, correct?
Everyone runs dev environments locally and tests. A dev environment is really easy to set up with mongo and node. Occasionally, we’ll put stuff on a staging environment if we want to test a database or infrastructure change. Big, experimental client changes go to the alpha channel on production.
So when you have 2 features/bug fixes in the same area, built in 2 different branches and deployed to isolated dev/test environments... the first time you might find out that they dont work well with each other is in Staging? Why wait for that when you could deploy to a common environment and catch issues sooner?
Btw... I am trying to get some teams in my company to get out of branching. So trying to understand your view (which is exactly what these teams are doing), hence these questions...
That rarely happens in our experience. With our internal board, we know who is working on what and in what area of the code. Plus, all code is reviewed by someone working in the same area.
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.
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!
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. =)
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.
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.
Took a look at the dev board as a way to "demo" the service without signing up. It seems... overly complicated? Maybe I really do just need to sign up.
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.
