Problem Database Update 2: This is going to be awesome
We’ve now had a few meetings and discussions about the physics problem database, and I now know enough to say with a healthy certainty that this is going to be an awesome collaboration.
First, I am completely amazed by the response I’ve gotten from people interested in helping with this project. Over 20 people responded to my initial interest form. And the talents these people are bringing are extraordinary. Here are just a few of the volunteers who responded:
- Aaron Titus, one of the original co-creators of WebAssign
- Shawn Cornally, creator of BlueHarvest, founder of ThThTh industries.
- Alemi, founder of the Virtuosi and Python master
- The eponymous Mylene, author of the great blog Shifting Phases.
- Evan Weinberg, author of Gealgrobophyiculus, willing to work from the other side of the planet.
Truly, I’m astonished that we can assemble a crack team of international developers to work on this project—the internet rocks again, as always. But perhaps the coolest thing about our development team was how many people responded to say they didn’t know much about software development/web design/databases, etc, but they would love to learn and help out in any way possible. This really got me thinking—what if we could do this project in such a way that not only do we create this problem database, but the process we use to create this database can help actually help people to learn these skills?
This gives me a good idea for a mission for our new Global Physics Code Shop, not just to write software, but to bring people into the process of creating software and help them learn how to add to our efforts, which should make for better software. What better way to learn web development than by jumping into a real project that you will ultimately end up using?
I also think that experienced programmers will also benefit from trying to explain what they are doing so that it can be understood by others. I constantly find myself falling into the trap of learning just enough about a new language or tool to just “get by,” but if I force myself to then go back and try to explain it to someone else, I’m going to need to learn it much more deeply, and this will likely translate into insights that will lead to better code and ultimately, better software.
So that’s what we’re going to try to do. We’re going to try to document our work on this project as we go along in such a way that even the most novice user, who hasn’t done anything with database design, or doesn’t even know the basics of HTML can follow along with our efforts, and with enough dedication, make significant contributions to this project. This means that as we develop things, we’re going to try to do more than just put in a few comments. We’re going to try to create documentation (blog posts, screencasts, and whatever else we can think of) that tries to teach what we’re doing.
Description of v1.0 of Physics Problem Database
Here is the minimum set of functions we want the Physics Problem Database to be able to do:
- Allow users to login and write their own problems in a variety of formats (multiple choice, free response, numerical response, etc).
- Allow users to add solutions to a problem.
- Allow users to add comments to a problem.
- Allow users to add attachments (photos, pdfs) to problems, comments or solutions.
- Allow users to tag problems and then search for those problems by tags.
- Allow users to create a list of problems and then display those problems to be printed as an assessment to be given to a student.
There’s obviously a ton of other functionality we’d like to add down the road, like having students be able to log-in, keeping track of what problems have been used by what students, or being able to import and export problems into different formats. Hopefully all of these will be added in good time, but for now, we want to be somewhat agile and try to get something useful out the door as quickly as possible.
Based on the expertise of the people working on this project, we’ve decided to develop the database using PHP and MySQL. MySQL is the standard in databsae development (this will hold all of our problem information), and PHP is a scripting language that runs on a webserver and can dynamically generate webpages using the information stored in the database.
One other tool we will be using is Laravel, a PHP framework, which is essentially a library of code designed to make it easier to develop web applications. Laravel will make it much easier to things like access control, or really fancy stuff like Dropbox integration.
The first task we have to accomplish is developing a schema for our database that decides exactly what information we will be storing in our database, and defines the relationships between various objects in our database. In our most recent discussion following the weekly Global Physics Department meeting, we made some headway into planning this out, and then Alemi and Aaron stepped up with some excellent suggestions.
Andy and I had a quick conversation today to discuss a few more details (link to recording of that conversation). Based on all these suggestions, I then tried to pull everything together and work up a first draft of the schema in MySQL Workbench, a great free app that lets you design databases (and much more).
Here’s the link to the MySQL workbench document I created: PPD database schema.mwb.
Also here’s a pdf of the schema:
And finally, here’s a short video where I try to explain the schema for the database and ask a few questions for your consideration.
Two quick questions I have after developing this schema:
- I’m not sure we need a many to many relationship between tags and users. Shouldn’t that just be a 1 to many relationship, as in 1 user can create many tags? We aren’t going to have tags associated with multiple users, are we? Or might be need to find all of the users who have used a particular tag?
- I’m a bit confused by why the attachments table has 6 different foreign keys created by MySQL Workbench—there are 2 for each relationship between problems, solutions, and comments. In our first iteration, I think every image you upload is going to be associated with either a problem, solution or comment. We won’t do any fancy stuff to try to re-use an image to be associated with both a comment and a problem, for example. So I’m wondering what happens to the problem and solution foregin keys if I upload an image associated with a comment. Will they just be NULL to indicate that there is no relationship?
Organization and next steps
We haven’t yet figured out exactly how we’re going to organize development. Ultimately, I think we will be breaking into teams that are working on various aspects of the project (backend programming, interface design, etc). Our first step is to finish setting up a repository on GitHub which will allow us to share the code for the database, and allow you to download a working copy to test out on your own computer, modify and resubmit for inclusion in the code we ultimatly deploy to be used by everyone.
Andy is already playing around with the Laravel framework and setting up PHP/mySQL on his windows machine, and he’s already created a short screencast that shows you how to get started with doing the same.
Once I get the GitHub Repository fully set up, I’m also going to set up a blog over there, and will move long posts like this to that page as well, so my readers who don’t want to have anything to do with this project don’t have be bothered by these posts.
That’s it, so far. I’d love to know what you think If you’ve got a lot of experience in coding, I’d love any suggestions or critiques you have for our work so far. If you don’t have any experience, and are interested in helping, I’d love to know what you think of our efforts so far and if you find our screencasts and explanations helpful. I certainly found it helpful to try to talk my way thought the design instead of just throwing it together.