larsen

Interviews about books, in the spirit of usesthis.com.

I'm publishing a new interview every week (you can follow @bookflocks on Twitter for announces).

There's still much work to do:

. RSS feed

. A page collecting all the books mentioned in the interviews

. Better mobile version

. And so on and so forth…

I hope you'll find it interesting, feedbacks are definitely welcome

You are confusing cause and consequence (nice pictures, tho')

One of my university professors some years ago said the source of Rogue was one of the C program he read. I've never been able to find it, and I am curious since then. Does anyone?

At $previous_job we were using RT to manage the spec -> dev -> QA -> deploy cycle. For each new task a new ticket is required. Project managers and team leaders split this ticket into smaller sub-activities (new tickets children of the original one) and assign them to developers. Each developer is responsible for including testing instructions in a ticket comment, and providing the references to revisions relevant for the test. When a developer is ready for QA, he passes the ticket to his project manager, who can test and decide if the activity is ready for QA. At the end of the process, QA receives a single ticket, with a set of dependent tickets each one with instructions about how to prepare the QA environment and do the test.

On top of that we built various tools. A web-based kanban board displaying the status of each task, command-line utilities to make developers' and QA guys' lives easier (for example, there was one adding comments to tickets for every commit; or another allowing PMs and QA to fetch the list of revisions needed for a task), and so on...

To build the tools we used RT::Client::REST, a Perl client for RT. Given the REST interface, though, I think you can find something for Python or any language you plan to work with.

I use git at work and for personal stuff. The learning path is maybe a bit steep if you come from things like Subversion, on the other hand I instructed a developer new to VCSs and so far he didn't complain, shoot his foot, or shoot mine :)

git is only my personal preference, generally speaking I recommend to go for a distributed version control system: it's modern, it's mainstream, and it's more versatile in terms of workflows you can implement.

Version control. You can observe the benefits even working alone on relatively small projects. And it's one of the pillars to experiment with more reliable ways of deploying software