The midterm evaluations came up very quickly. Now’s an excellent time to take a step back, look at your project, and your progress so far, and see if you’ve got enough velocity. It’s worth noting that the midterm “grade” is purely advisory. It’s useful to work on UCOSP projects in a concentrated blast / multi-hour session as opposed to 20 minutes here and there.
We now have more support for easily shipping and building static media files for extensions. If you look in the rb-extension-pack repository in the rbseverity dir, you’ll see how it works.
Is it still possible to get a good grade in this course even if you’re a little behind?
I’m thinking about using a jQuery accordion for my security list. How should I go about doing that?
Keep it simple for now. Just make it a list. A simple but readable list of passes and fails is good enough – things like an accordion are more polish than necessary.
I’m not sure about everything regarding design.
So the flag in the review_request is there to prevent unnecessary database queries, which add significant time to a page. When you view a review request, extra_data is already loaded, so it’s a quick and easy check. That’s only there to prevent scanning to see if a new trophy should be added, though. It still has to look up trophies from the database if we know they’re set, maybe make that flag trophy_count – That way we know if there hasn’t been any calculated (missing from extra_data), or if there’s none (0), or if there’s at least 1. If there’s at least 1, we do need to do a database query, and show the trophies.
For r/4699, Summary and Description are used to determine a matching review request. If they are not provided and guessing is not enabled, we still want to guess them, but the values won’t be used in the update. The logic for guessing is currently embedded in the diff logic, and is a bit difficult to make independent. An easy hack is to enable guessing before calling get_diff(), and turn it off and restore the original summary and description values after extracting the guessed values. This is approach isn’t very clean so I’m not that fond of it. Any suggestions on how I should proceed?
What I suggest, is refactoring out the whole guessing code into its own methods. These methods should not rely on the options object at all. I would think we can just do this for those SCMs.
My question is basically about the next course of action I should take. Would it be better to get the back end going now, or should I keep working on the front end?
I think you should get the backend/api working before spending more time on the interaction.
Is there a quick way to map Django models to Backbone.js models?
The two aren’t necessarily the same – it really depends on the data you’re getting and from where. The Django model is what’s in your database, which is often but not always different from what you want to expose to the API. There’s often a 1:1 relationship between API resource and backbone.js models, though. As far as I know, we manually keep the two in sync – we don’t have tools that update the Backbone models if the API changes. You can extend our BaseResourceModel to handle the details of communication with the API, but you’ll still need to define the field names yourself.
Is it a sensible workflow to get front-end stuff working before doing too much on the backend?