Archive for the ‘Developer Essentials’ Category
- submitted pull request to add unit tests for issue #559
- worked on issue #230: suggested UI design, dove into code
Working on issue #1028:
Implemented colour-coding for the rubrics: green for selected marks and yellow for old marks.
Set unedited criteria to old marks upon changing marking_state to complete.
Need to decide on some UI details:
For example, when starting on a remark request, does the total shown on the page start with the original total mark and them adjust to remarks or start with 0 and reflect the actual remark result in the database (which is not populated with the original result at the beginning)?
Populate extra marks (i.e. bonus/deduction)? could and probably should be done in a separated task I think.
- Sort out all the UI details and submit a pull request for #1028
- Reached a point where my level of progress can now be integrated into the master MarkUs branch. I have begun to work on making jQuery compatible with Prototype by using jQuery in a noConflict mode. I have also been making sure none of my changes have broken anything throughout the MarkUs application.
- Have a problem with some of the features of the new data tables for displaying students, but should be resolved once Prototype is renabled.
- Keep working on getting jQuery to work with Prototype with jQuery being in a noConflict mode.
- Worked on fix for issue 1027 (going over code base and updated it to use appropriate result related methods)
- takes some time to understand what certain areas of code are doing to know which is the appropriate fix for it
- finish up fix for issue 1027
- work on some remark related bugs
- Added code to allow for unlimited tokens for test scripts. Tokens are currently not used anywhere so it’s just a boolean somewhere waiting to be used when we implement student run tests. Added code to choose between using the latest or best mark for all test scripts.
- Possibly make a full test script or work on getting students to be able to run test scripts.
- Initial UI for the grader tab for grade entry is complete, with all of the kinks worked out.
- Modify the functionality to assign graders on a many-to-one basis to users, instead of to groups.
- Submitted pull request for issue 1035
- Waiting for pull request to be merged
- Keep working on grades sheets’ viewing functionality for TAs
- Worked on displaying test run position with Redis and Resque
- Redis-status requires the perform method to be a class instance method, but right now it’s just a module method. It might take a lot of code refactoring to change it.
- Keep working on displaying test run position and test run progress
- Began making changes to make jQuery code noConflict() to be compatible with Prototype
- Working on update_collected_submissions function used in the Assignments dashboard.
- Meeting with Marc this Friday to regroup on progress and goals for the end of the semester
- Worked on submissions, and integrating the existing API. Also started documentation.
- Thinking of including small examples for working with the API. What language would be preferred out of Java, Python and Ruby?
- Finish up the assignments routes.
For the past while, I’ve been working on updating the database schema for the relationship between Submissions and Results. Originally, Submissions was created so it had a one to one relationship with Results. However, a feature was later added so that students could submit remark requests, requiring more than one result to be related to a single submission. The schema was then changed so that submissions had the following relation:
has_one :result, :dependent => :destroy
belongs_to :remark_result, :class_name => “Result”
Where ideally, we would want a has_many relationship. With the previous implementation, an error appeared about old results sometimes not showing up (documented in this blog post). A quick fix was implemented but it was dependent on database ordering and time stamps. I took the following steps to improve this implementation and schema:
1. The schema
- I updated removed the belongs_to remark_result relation, and changed the has_one result to has_many
- This change means that submission.results will return an array of results and that we can no longer call submission.result and submission.remark_result to get the results
2. Helper methods
- I implemented two helper methods: get_original_result and get_remark_result that would return the appropriate result for the submission
- These helper methods utilized the already existing field: remark_result_id in the Submissions table in order to differentiate between the two results (this removed our dependency on ordering/timestamps)
3. Updating the code base
- I updated the way results were created so that they would add to the array of results, and I had to manually fill in the remark_result_id column of the Submissions table when a remark result is created (since the belongs_to dependency no longer exists)
- All areas of the code that were using either the result or remark_result had to be updated with the helper methods and then tested to ensure functionality did not change
Originally, the suggestion on issue-941 (the schema update issue) was for the two methods to be get_result and get_old_result. The idea behind the methods was that get_result would return the remark result, if it exists, otherwise return the original result. Then, get_old_result, if a remark result exists, would return the original. When I implemented this approach, I realized several errors and differing functionality. Comparing it to the original code, I realized that the remark result was actually not being used in many places in the code base and that the original was result was generally used most of the time (without checking if a remark exists). Another problem is that in some cases you only want the latest completed result to be displayed rather than just the latest existing result.
So, the approach we took was to update the schema without changing any functionality (by using helper methods that would return the same type of result – original or remark – each time), and then follow up by going over sections of the code and updating them so that they will be using the appropriate result in that case. This issue has been opened and can be found here.
My suggestion for implementation is to create another helper method, get_latest_result, that would utilize the current helper methods get_original_result, get_remark_result, has_remark?, and remark_submitted? to return the latest result (note: only use remark result if remark request has been submitted). We would have to determine areas where this method would be appropriate to use instead of always using the original result.
As per the “Next Steps” section, I have added in helper methods and then gone over the code base that uses results, updating method calls where appropriate. I implemented two helper methods: get_latest_result and get_latest_completed_result for the update. The former will return a remark result only if the remark request has been submitted, and the latter will only return a result whose marking state is “completed”. These changes can be found in pull-request 1058.
- was assigned to issue #1007
- worked on issue #1007: examined existing code in order to find the methods needed for this feature
- reproduced issue #559 and added a more detailed description – as a comment
- got started developing to implement the required feature
- learned how to use the debugger
- finished Ruby on Rails tutorial
- created issue #1007 for the issue I’m working on
- reproduced issue #1007
- finished Ruby on Rails tutorial
- unsuccessfully tried to reproduce issue #270 thus asked for it to be closed
- created issues #1005 and #1006
- was assigned to issue #559
- Submitted a pull request #998(https://github.com/MarkUsProject/Markus/pull/998), followed by two additional commits: updating French translations and creating a migration.
- Started looking at #938(https://github.com/MarkUsProject/Markus/issues/938).
- Learned how to create a migration for changing database schema in #915(https://github.com/MarkUsProject/Markus/issues/915).
- Continue working on #938(https://github.com/MarkUsProject/Markus/issues/938).
- Revise pull #998(https://github.com/MarkUsProject/Markus/pull/998) as needed.
- Continuing to work on issue 941(https://github.com/MarkUsProject/Markus/issues/941). Located and switched out all instances of submission.result/submission.remark_result for the appropriate method. Resolved majority of issues that occurred after changing the schema.
- After changing the submission schema, a foreign key is no longer being set for the remark_result_id column in the Submissions table. I sent an email to the developers list to gain some insight. Working on determining the best way to approach this. Results are used in many aspects of the application. I need to thoroughly test the application to ensure all areas that were affected have been updated.
- Determine a fix to populate the remark_result_id in the database with the new schema. Test application for any errors that may have been overlooked. Write a blog post to follow-up on this post(http://blog.markusproject.org/?p=4614) which was about the original issue and the temporary fix that I am working on replacing.
- Started work on converting Prototype to jQuery. Keeping track of my changes as I go along.
- None so far.
- Keep working on the changes over to jQuery. Will post a blog post as well as documenting the changes I have done so far so other members on the MarkUs team can follow along.
- Configured Markus to use a public key for the SSH calls.
- Discussed the current state of the test framework with Brian and Mina.
They referred Nick and I to a Google doc
(https://docs.google.com/document/d/1IFfGQ3VIYq8p2ZSy13GJPkOAVoaAw-zRcrQOj9LyKuQ/edit). Read the document to get an idea of what needs to get done.
- Getting tests to mark based on the rubric is difficult and
needs some design work.
- Try to fix functional tests for the test framework. There’s currently over 130 failing.
- Setup branch with Marc to begin collaborating on migration.
- Lost the weekend to the MHacks and a test today (tues.)
- Continuation of jQuery migration.
- This week was a bit busy for me so I didn’t get to do as much as I
wanted. I mostly just did reading and planning (not much coding).
- Received and read an extremely helpful documentation about the MarkUs Automated Test Engine from last term’s developers:
Thanks a lot guys!
- Removed a stray comma in this one file, and made a pull request. Avery minor typo, but with the comma there the Config UI won’t load at all.
- Decided that I’d work on UI.
- The document might be a bit out of date. There are several “UPDATE”
remarks saying that certain features should be implemented. But those
features are already implemented (which isn’t a bad thing).
My concern is that there are several screenshots in the document, and
I was planning to just follow them when working on the UI. But now I’m
worried those screenshots may be from old design plans.
- Start working on the Config UI. The bullet points on page 13 look good
to me and I’d like to start implementing some of them.
- Going through the Graders tab under assignments to see how much of it can be used for the grade entry form.
- Need to connect with Oussama to create a plan so that we don’t duplicate work.
- Start setting up graders for the grade entry form.
- working on giving TA’s the ability to enter grades
- reviewing relevant existing code under the grader’s tab
- Had to submit multiple assignments and write a term test this past week
- Attempt to recycle parts of the code as the functionality already exists for a different user role
- Plan possible changes to database schema
- Continued work on issue 19, though now that I’ve realized notifications are occasionally displayed at different levels in the page, I may have to re-think the solution.
- Read up on RESTful API design
- Tested and reviewed the code of the current Markus API
- Started a discussion and analysis of the current API via issue 1012
- I could not get /api/submission_downloads working yet – I keep getting a 422 response despite having what would seem to be a valid request.
- Update the documentation for the existing API
- Discuss with Karen what other new features, aside from gradebook entry, she’s like to see in the API
I’m currently researching areas where Markus performance may see improvement. This involves reading through major parts of the wiki, particularly those relating to the schema and design, as well as previous issues and parts of the code base on Github. The blog is also a great source of information, as prior contributors have mentioned performance issues. Severin even did a complete benchmark of Markus: http://blog.markusproject.org/?p=3383
His findings, throughout the 4-part analysis, include the cost of subversion interactions. In part 3, he mentions that it’s likely that the primary contributor to heavy IO during peak traffic involves svn: subversion repository creation and file storage on existing repos. But can this be improved upon?
One of the future goals for the Markus Project includes a transition from Subversion to Git. I love Git, and Grit is a well-documented ruby gem for interacting with Git repositories. Much better documented than the svn ruby bindings. But given a switch from svn to git, could we expect improved performance?
Much of the git community claims that git is much faster than svn: https://git.wiki.kernel.org/index.php/GitSvnComparison The git website even presents some benchmarks for comparison: http://git-scm.com/about/small-and-fast The numbers are promising, but unfortunately, the commit operations include pushing, which I don’t believe is part of Markus’ operations. They also don’t involve grit nor the svn ruby bindings. So to research whether or not Markus’ peformance could improve from a transition to git/grit, I figured I’d have to write a small benchmark.
The code can be found in a gist: https://gist.github.com/4658271
The code discussed completes 4 operations, and outputs their running time:
- Initializing 10,000 svn repos
- Initializing 10,000 git repos
- Initializing and commiting a small test file to 10,000 svn repos
- Initializing and commiting a small test file to 10,000 git repos
The test file that’s committed is called ‘test.txt’, and contains the string “hello world”.
The 40,000 repositories is a small enough sample size such that my laptop can complete the script in a bit over 10 minutes. I may come back to this with a larger sample, leaving it to execute over night, at a later time.
And note that the script keeps a reference to all those repository objects, so it uses a fairly large amount of memory. We aren’t setting things to nil to give the garbage collector time to go through while the process is running.
Before getting to the results, here’s some details on the benchmark environment:
OSX 10.6 Snow Leopard
2.4Ghz Core 2 Duo
svn version 1.7.8 (r1419691)
git version 184.108.40.206
And now for the numbers:
- Creating 10,000 svn repos: 119184.502 ms
- Creating 10,000 git repos: 120582.207 ms
- Creating and commiting to 10,000 svn repos: 285041.101 ms
- Creating and commiting to 10,000 git repos: 223160.437 ms
From this simple experiment, we can see that initialization was only minutely slower with git than svn, which comes as a surprise given the smaller size of git repositories. But we start to see a stronger contrast once committing files was involved, and svn showed to be ~22% slower in comparison. If initialization wasn’t included in those operations, the difference should be even greater.
I should also mention the size of the generated directories. 20,000 repositories were generated with both git and svn, making for 40,000 in total. The combined size of the 20,000 SVN repositories, of which half had our test file committed, is 594 Mb. And git? 278 Mb. That’s less than half the size!
And so given the benchmarks previously available, as well as the results from this simple benchmark, I agree with the majority: a switch from SVN to GIT should help improve performance. It may not be a high priority at this time, but with svn interactions being such a bottleneck under heavy load, it should help alleviate some of the strain. As such, though I’ll continue researching areas where Markus may see performance benefits over the coming week, I’ll keep this transition in mind as a possible goal for this work term. It would certainly be a large task to complete.
If we weren’t having so much trouble with svn-bindings today, we would really be having fun at the UCOSP code sprint at Facebook headquarters.
Here is some information (and hopefully pictures) of the team that is working on MarkUs this term:
My name is Marc Bodmer and I am a 4th year student finished up my last term at the University of Guelph. I am into front end web development, working on side projects with new web technologies at every chance I get. Along with MarkUs, I am also working on another project related to conference planning. I have written a short tutorial book on Ember.js called Learning Ember.js that will be released in February, 2013. I love attending conferences and meetups. In my spare time, I play squash, rollerblade and snowboard.
If you want to find out more about more or find out my accounts on various social networks, you can visit my website.
Daniel St. Jules
Hi, my name’s Daniel St. Jules, and I’m a 4th year student at the University of Ottawa. I joined MarkUs with an interest in working on a larger Rails code-base, and because I really enjoy developing web-based projects. Some of my projects can be found on http://danielstjules.com/ and on my Github. Aside from development, my hobbies include snowboarding and basketball.
My name is Alysha Kwok and I’m finishing up my last term of Computer Science at the University of British Columbia. I am most comfortable working with Java and have worked on mobile applications (iOS and android) on co-op and course projects. I am new to Ruby on Rails but am eager to learn. My hobbies include graphic design, ballroom dancing, and yoga.
Here’s a picture from the code sprint at facebook so you can put a face to the name =]
Hi, my name is Mike Wu, and I’m in my last term of undergraduate studies at the University of British Columbia. I grew up in Beijing, China, and I have been into computers and technologies ever since I was a kid. From co-op and courses, I have become familiar mostly with Java and desktop application development, so this project is a great opportunity for me to learn more about web technologies through Ruby on Rails.
My other interests include sports (especially basketball), photography, traveling, and music. I’m hoping to learn a few tricks to make my website more awesome!
My name is Mike Stewart, and I’m in my fourth year of Software Engineering at the University of New Brunswick in Fredericton. I’ve completed 4 co-op software development terms at different companies, mostly working with Java and C++, as well as some web development. I’ve also developed apps for Android and Blackberry and have put together a few websites over the years, though I’m completely new to Ruby on Rails. I look forward to working with this very talented student team, and learning even more about web development!
Other than development, some of my interests include skiing, SCUBA diving, and volunteering with a few organizations.
Oussama Ben Amar
My name is Daryn and I’m in my last year at UofT studying computer science. I’ve worked on MarkUs in the past summer so feel free to email me directly if you have any questions (email@example.com). I had an internship at IBM last year, also working with Ruby on Rails, developing an information management system that organized events and data which were crucial to my team. On my off-time I like to get active and play sports such as basketball, ultimate frisbee, and dragon boat. Any sports fans out there? Anyways, I hope to get to know everyone better over IRC even if I don’t get the chance to meet in person.