Meeting Minutes for Group A – February 3, 2013


For anyone working on a larger project right now. If you have a lot to design, a good idea would be to create a hackpad page with your thoughts and to keep it up-to-date, so that we have a source of reference as we’re discussing it. This is especially useful if the project needs additional work after the semester ends: we’ll have something to go back through

It’s very important to get status reports in 24 hours before the meetings start, aka by Friday night. The reports need to be up so that the mentors can prepare so that they’re not hemming and hawing or making snap decisions in. For future meetings, we want to have all the status reports on Fridays. At least 24 hours before the first meeting, which is at 10:30 Eastern. Email your status reports to the mailing list (reviewboard-students) so that the traffic can be observed and the person on duty will gather them from there.

Some status reports indicate people are having difficulty finding time to work on the project. Finding time is very important. If you really want to get a deep understanding of your project, the code base, and really maximize your chances of getting your projects done you’ve got to put in the time. It’s also better to work in big blocks, 2 hours once a week will be more productive than 2 hours spread across a few days

Question Period

Q: I mostly work on my project on the weekend since it allows for larger blocks of time. Due to that, I don’t really have anything considerable for the status reports before the end of it. What should I do regarding that?

A: You could just report on the period from the last status report to the present and include what you’re hoping to get done “tomorrow” as well as any questions. So what you do on Saturday won’t apply to your Friday status report, it will apply to the *next* Friday’s report. The most important thing is to get any big questions sent in via the status report *ASAP* before the meeting. You should also feel encouraged to ask meetings throughout the week as well. Always feel free to contact the mentors via: IRC pings, email, or mail to reviewboard-dev or reviewboard-students (dev will give you greater developer exposure). The mentors also tend to be in IRC over the weekend so you can get your questions answered there as you work.

Q: Are there docs on how the unit test database is set up? I want to be able to get around the authentication system to perform the ‘delete ssh key’ test.

A: Look for other tests that do “self.client.login”. Somewhere we’re logging in as an ‘admin’ user. And to run an individual test: ./reviewboard/ — reviewboard.admin.tests:MyClass.my_function (you can include as much or little of that module path as you like… filename, class, function). You may need to also include the ‘test_users’ fixture

Q: What do you recommend for inspecting some random django model variable, preferably showing all its members and foreign key values. dir() and inspect don’t really do that for me, and most of the classes’ __unicode__ is too simplistic for this. I mainly use it for “code skimming”: quickly printing x, y, z variables, finding out which one contains things related to my problem. An example: class Comment(BaseComment) has: “anchor_prefix, comment_type, filediff, interfilediff, first_line, num_lines, last_line,” I would like to see them e.g. like I would instantiate an object Comment(anchor_prefix=”asdf”, comment_type=”asdf”, filediff=”<Filediff>”, interfilediff=”asdf”, first_line=”asdf”, num_lines=”asdf”, last_line=”df”) and e.g. the models.ForeignKey resolved (just 1 step) and __unicode__ or __repr__’d

A: You could use pdb interactively, or just add print statements. Best to pick a few things you care about and print those. For the example, you’d probably need some custom function that introspected the list of fields and then got the right values (so you don’t end up with all the extra django model cruft). Not aware of some standard tool/function for this. You could Google around too – someone else might have solved this.

Q: I just want to recommend into the wild to use linters and so on, especially the cool ones integrated into our editors are convenient. in some commits I saw some really confusing whitespace (e.g. in javascript a dedent after a { block) – editor linters can do that for us as we’re writing

A: Good idea, that’s the sort of thing we should take advantage of. Also, if you haven’t already noticed, Review Bot is running pep8 over your Python and Javascript code that you put up for review. And if you see that odd whitespace in a review request, be sure to call it out since we should be catching that.

Closing Remarks

A reminder to take a look at other’s code (including the mentors!). If you go to “My account” you can subscribe to various groups, which will put them on your dashboard. There are some review requests up there ripe for the picking. It’s ok if you don’t find you have anything to say. Looking at them is a great first step and getting to know our style is useful to you, and where code lives, and what work is being done. Reviewing makes it easier for us to know that you’re actually doing these things, but for your own personal development, just studying the code is good. Also a simple “nothing to say – looks like it makes sense to me” is better than nothing (e.g. it’s motivating and means that code has seen 2 dev’s eyes instead of only one). If you’re not confident, you don’t have to give a ship-it

Keep working hard everyone.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s