Start the recording, get your presentation ready, wait a few seconds, and then start talking. When you're done with your presentation, stop talking, wait 5 seconds, then open whatever you need to stop recording. This will let you or us chop off the beginning and end, creating a more clean demo.
Don't assume your audience knows what you're working on! These videos are going up on YouTube, and the viewers may have no idea what your project is about. In each video, briefly talk about what you're building, and don't assume people have watched your prior videos (it's okay to reference them though!) or have read your code.
Name your demo videos as `<UCOSP|OA> Demo Day <number> - <Your Full Name> - <Project Summary>.<ext>`. For example: `UCOSP Demo Day 1 - Christian Hammond - Dinosaurs Everywhere.m4v`.
Now that Django has good support for database migrations, we ideally would want to begin moving away from Django Evolution.
That said, migrations are currently too slow to rely upon, as they have no optimization step for any given set of migrations that would be applied. This means 5 migrations that all alter a single table will execute as individual `ALTER TABLE` statements, slowing down migration and regressing Review Board upgrade times.
There are really two scenarios here:
Django introduces an optimizer step in some version of Django that we can support (1.9 would be the earliest, though it's doubtful it'll happen by then). In this case, we'd switch to migrations.
Django does not introduce an optimizer, and we have to stick with Django Evolution to keep migration times sane.
We'll cover both scenarios here.
Switching to Migrations
If migrations are fast enough, we'd rather switch to them. There are a few ways to go about this:
We convert evolution files and history to Django migrations.
We continue to maintain Django Evolution, and use a special `Operation` subclass to invoke evolutions at the baseline.
The Django Evolution retrofit work will be covered later. We'll focus on #1 in this section.
There are two stages necessary to convert over:
Converting evolution files
Django Evolution and Django Migrations use similar formats, though Django Evolution's format is lacking in quite a bit of information. A partial converter could be built, but it would still require a good amount of user information.
Here are some key differences:
Writing a converter
The best route to go may be to introduce a tool that generates migration files by introspecting code, even code that no longer has working imports. This would mean dealing with the parse trees, and could be buggy.
The reason for going that route is that we'd need to run this at multiple points in the history of the codebase. The tool would take all evolution files, find out which commits introduced them, and then jump through the history, generating migration files at the appropriate times.
Given that the project may have changed quite a bit throughout its history, this needs to be able to deal with quite a bit.
Updating migration history
Django migration history is pretty straight-forward. It keeps the app label, the name of the migration file, and the timestamp it was applied.
This is easy to convert over, since we have all this data.
What we'd need to do is convert either in `migrate` or in `rb-site upgrade`. The latter won't work for developer installs, though, so we probably need the former. There's a `pre_migrate` signal we can listen to for this.
Preserving Django Evolution
If we can't move to migrations (due to the lack of optimization), or we can't/don't want to convert all the evolution data over, we may want to just get Django Evolution fully working on Django 1.7+.
There's a lot that would have to be done to get this working. On the one hand, most of the database code it depended on is now just gone. On the other hand, the new code is finally a mostly stable API, so it should be more future-proof and documented.
Even with this, there's going to be the issue where models without migrations don't behave well with models containing migrations, and that we'd still want a path to move away from evolutions to migrations in the future.
There are a couple options for integration:
Hook into `pre_migrate` (or `post_migrate`?) and do the evolution there.
This doesn't really allow for any control, flexibility, or dependency management.
Add a new `EvolveOperation` migration op that kicks off evolutions for a given app.
This allows for dependency management.
It does not allow for the kind of batch optimization we need, without getting tricky.
Something like having Django Evolution grab all the migrations, find out which aren't in the database yet, and going through them up until it hits one that isn't an `EvolveOperation`. Then run those.
It also would require a new migration file every time we add a new evolution file.
Could maybe just require this and pass in the evolution name as a parameter. One more step toward using solely migrations. Or pass the entire evolution contents, but then we're getting pretty far away from being compatible with older django-evolution.
There may also be some other advantages to keeping django-evolution around as a project. We have some nice stuff for manipulating evolution history, which we've found useful for certain situations when customers have gotten themselves into trouble. These could stay and work on migrations as well.
Welcome to the Review Board project! You've been chosen by a secret society of monks and/or your professors to work with us for the semester on our humble little project.
By working on Review Board this semester, you may just be making your own life easier down the road. Many of our former students have been hired by companies who noticed Review Board on their resumés. Several of these students have ended up using the features they developed every day in their dream job.
Periodically collecting status reports from the team and posting them on the Student Blog.
Communicating often with us and your fellow students.
Attending and presenting at monthly "demo days"
We expect you to be spending about 8-10 hours per week working on Review Board. Of course, there's no upper bound on the amount of time that you can spend if you so desire.
We'll want to see you active on Slack, responsive to feedback on your code, and we want to see descriptive and thorough status reports.
At the end of the course, we'll give a final grade recommendation. Your professors will then take that into advisement when determining the actual grade to give. It's possible that your professor will have other requirements outside of ours. For example, you may be required to write an occasional blog post, write a research paper, or give a presentation. In this case, they'll include those when they figure out your grade, but we usually don't see any of it. If you do have additional requirements, it's important to let us know, so we can adjust our expectations for how you're spending your time accordingly.
This may sound like a lot, but it really just boils down to setting expectations, following through, getting your work done, and being active. Once you get out into industry, the"soft" skills of planning and communication are just as important as being able to write good code.
A note on time management
Every once in a while, we have to give a bad grade recommendation (sometimes even a failing grade). It's never been due to someone being unqualified or dumb--to get in to this program, you have to be a top student at a top school. Instead, the thing that trips people up is time management.
One thing that many of our former students have discovered is that it can be very helpful to set aside contiguous blocks of time each week. You've been asked to spend 8-10 hours a week on this class, but it's going to be much more effective to break that up into two or three blocks of several hours instead of trying to grab 30 minutes here and 15 minutes there. Having some time on your calendar that's blocked off will also help you avoid procrastinating the loosely-defined Review Board work in favor of the well-defined work for your other classes. You may also find it helpful to schedule these blocks with other people at your same university, even if you're working on different open-source projects--that way, you'll be accountable to someone else to spend some time each week working on your project.
Introducing the mentors:
I also like faking competence at photography, toying with making games (on occasion), and long walks on the beach.
I got involved with open-source software in high school, when a friend installed Red Hat Linux on a spare machine in one of the computer labs. I continued tinkering with various different open-source projects during school, eventually getting involved with the GNOME project, where I first met Christian (online--it was another few years before we met in person). After graduating from college, I moved out to Silicon Valley to join the Workstation team at VMware, where Christian and I worked together for many years. At some point, during one of many sessions complaining about how crappy it was to e-mail a patch file to a mailing list, Review Board was born.
At the time, I don't think either one of us had any idea that Review Board would be more than an experimental prototype, but it turned out that a lot of other people had the same problems that we did. It's been a humbling experience to watch as something we built has become one of the de facto tools in the industry. In August 2013, we decided to take the plunge and make Review Board our full-time job. We're currently working on building a sustainable business around Review Board, to ensure that the project will always have the support and attention that it deserves.
When I'm not writing code or dealing with the annoying parts of running a business, I practice and teach martial arts, cook elaborate meals, and occasionally pull out my cello to play a bit of music.
My day job is hacking on Firefox desktop, making the UI do wonderful and beautiful things. I also contribute to Mozilla Thunderbird. In my off hours, I play guitar and sing back-ups in a pop rock band , bike, bake, and read. I have a particular fondness for graphic novels and 90's style point-and-click adventure games .
During the day I work at Mozilla, hacking on Firefox desktop as part of the front-end team. Outside of hacking on open source, I enjoy playing board games, skiing, volleyball, and more recently disk golf.
Like Mike and Steven, I first began contributing to Review Board as a student through the UCOSP/Open Academy program in my final semester. It was a fantastic learning experience, and I'm thrilled to be able to continue contributing and helping out where I can.
I'm currently working at Amazon in Seattle in the Social Shopping org. In my free time, I enjoy working on side coding projects, reading, playing the guitar/cello, and playing games.
Christian HA hoopy frood who really knows where his towel is.
Finally, we recommend setting up your development environment as quickly as possible. This can sometimes take more time than you'd think, depending on your environment, so get this going fast. Come to us if you have any issues.
Traditionally we've used IRC to communicate, but we're going to be trying something new this term: Slack. Slack is a relative newcomer to the scene, but in just a year or so it's become one of the most popular communication tools for startups and mid-size businesses. Slack is a lot like IRC, but it has first-class web and mobile clients, which makes it much easier to access in our modern mobile-device world. There's also an IRC gateway to it if you can't give up your favorite IRC client (but beware that you'll be losing some features like images and file sharing).
We'll send you an invitation, which you'll use to set up your account. Once that's done, just open up reviewboard.slack.com in a browser or one of the apps (there are mobile apps, and a fairly nice Mac app). You'll be expected to be present in the #students channel at a minimum, and there are a few others you can join if you're interested.
We expect you to maintain an active presence in Slack. Slack keeps logs of everything, so you don't need to be connected all of the time (though you certainly can be). You should make sure you open things up at least once a day, and we highly recommend turning on push notifications for your mobile device. This is so that we or your fellow students can ask you questions and get an answer from you, and vice-versa. Ideally, check in on Slack as often as you're checking Facebook.
Unlike previous terms, we're not going to be holding a weekly team meeting. That said, we do want to hear from everyone at least once a week, and ideally more frequently. Your mentors will be active and available on Slack, so take advantage of them. Communication in a team is an important skill to develop, especially when working in a geographically distributed team. If we forget you exist, you probably aren't going to get a very good grade.
If you have any questions at all during a week, or you're stuck on anything, don't wait until your status report to ask. Hop on Slack and ask us! Even if we're not around at the time, so long as you maintain a presence in Slack, we'll get back to you.
This is so important, we'll say it again: Ask questions!Unlike many (all?) of your other courses, we don't want you to toil away on your own until you get the right answer. We don't consider it cheating if you ask us or your peers for help. If you're stuck on something for too long, ask. Being comfortable asking questions is a very important skill to develop in this industry!
One person will be responsible every week to collect these status reports from everyone, and to post them as a single post on the student blog. See Collecting Reports below.
Status reports will be collected on Friday. You'll have until 12:00am PST Sunday to get them in before we'll consider them "late." Missing or late status reports will have a negative effect on your grade.
Once the status reports come in, you'll need to post them to the Student Blog. Please include them in the "Status Reports" category.
After they're posted, reply to the e-mail thread you started with a link to the post.
If any are missing, you may need to hound your fellow students for reports, or ask them to update your post with their status. Remember, it's your job that week to get all the status reports up! If you're waiting on someone's status report past Sunday, please get in touch with the mentors and let them know.
Once a month, we'll get together as a team and have each person give a quick demo of what they've been working on. This is a great opportunity for you to show off what you've done, and will hopefully give you some milestones in the middle of the term.
Schedule weekly (except on demo weeks) face-to-face meetups
Primarily focused on "This week I learned"
Short - something like, 2 minutes per student
Add "This week I learned" to the Sonar status report
Create Slack bot / integration that pays attention to messages from students in the students channel with a format that indicates that they've accomplished some task. This gets automatically injected into that weeks status report.
student: "idid: Finished frobnicating the whichwazzits"