MarkUs Blog

MarkUs Developers Blog About Their Project

Archive for the ‘Course Administration’ Category

UCOSP / FOA Winter 2014 Introductions

without comments

Shenglong
I’m finishing up my last year at Western University for Finance & Computer Science. Most of my experience to date has been product and UX related, so I’m hoping to hone some technical skills as well as get a better feel for rails through my work on MarkUs. This seems like a great opportunity to learn about collaborative development, and to build something that can make many lives easier. I love buildings things, so this seemed like a natural fit!

zachmunrocape

Zach

I’m a third year student at the University of Toronto. I became interested in the UCOSP program after my Software Tools and Systems Programming Instructor and current mentor for MarkUs – Karen Reid – talked about her trip to Facebook and experiences students had with the program. I wanted to get involved with MarkUs specifically as I have used MarkUs as a student so it seems really cool to contribute to something I have seen in used in a live classroom setting. Finally, alongside a distributed and local development and support environment, I believe this could foster a challenging and enjoyable project for the semester.

Christopher

I’m a Master student at the Cornell University. I found this class interesting when I read the description of the class in how we will collaborate with other students from other universities to work on an open source project. I think this will be a very important and useful experience since I think this is how the “real world” application is being developed and built especially when we join to a company that already has its system running. I hope this class will be a great and enjoyable experience for me for this semester.

Jeremy

I’m in my last year at the University of Western Ontario. I was introduced to UCOSP by a friend who took it in first semester, and it sounded like a great opportunity. I’m excited to learn and gain experience that comes from working on an open source project. Also, I’m looking forward to meeting new people that are interested in this type of work. I think this is going to be a great class for giving us skills and tools that we can apply to the workforce when we’re done school. I’m happy that I got accepted to work on Markus, as it was one of my top choices, and I can’t wait to start contributing.

Alex

I’m a Masters of Engineering in Computer Science student at Cornell University. I did my undergraduate degree at Hobart College, where I received a BS in Computer Science. I became interested in taking a class where we work on an open source project because I use open source software everyday. I am very excited to work with everyone involved in the MarkUs project. I can’t wait to start contributing to the ongoing process, while learning about Ruby on Rails and also learning about the development of an open source piece of software along the way.

Tiago

I’m in my last year of computer engineering at the University of Campinas (Unicamp) in Brazil, also, from 2011 up to 2013, I did the last two years of the French engineering diploma in Télécom Paristech in France. When I saw the description of UCOSP, I thought: “This is going to be awesome!” Working on an open-source project with people all around the world will give us an incomparable experience, improve our skills and teach us a lot! I hope we can contribute a lot with MarkUS this semester.

Kitiya

photo (2)1I am a fourth year software engineering student at the University of New Brunswick. I know the UCOSP from my professor and a friend of mine who joined the program last year. I think it would be awesome experience to work with new people all across the world. This will be a good start to contribute my knowledge to an open source project. I am also looking forward to learn more about developing website through Ruby on Rails.

Other than coding, some of my interests include skating, playing badminton and photography.

Andrew Hernandez

My name is Andrew Hernandez and I’m in my fourth and final year at Western University. I heard about UCOSP last year from a friend who participated and he told me it was a great way to get industry experience and learn how to work with others. I’m looking forward to learning more about Rails and MarkUs throughout this term and look forward to meeting all of you at the code sprint.

Rafael Padilha

My name is Rafael Padilha and I study Computer Engineering at State University of Campinas, in Brazil. I saw in the FOA a great opportunity to develop some technical skills, meet new people and work in an open-source project as MarkUs. I am looking forward to learn more about Ruby on Rails and MarkUs during this term.

Written by Zach Munro-Cape

January 24th, 2014 at 4:12 pm

Posted in Uncategorized

Who is Doing What? – Fall 2011

without comments

The MarkUs team is meeting weekly on irc.freenode.net #markus on Wednesdays, 3 p.m. (EDT).  Every Tuesday, each member of the team (including myself) must come up with a “punchline” status update.  These updates are short, bulleted, straight-to-the-point reports that tell us how everybody is doing.  They follow a very simple format: see these three examples.  The punchlines need to be published on this blog every Tuesday, and it is every team member’s responsibility to give them a read before coming into the meeting.

But instead of everybody logging in and editing a single blog post for the status updates, we’ll rotate responsibility for collecting/publishing punchlines every week.  Similarly, we will rotate the duty of converting our IRC meeting logs into notes.

Here’s the schedule outlining who is doing what each week.  Teammates:  I highly suggest bookmarking this page.

  • Week of Sep 12: punchlines:  Severin, minutes: Alex
  • Week of Sep 19: code sprint
  • Week of Sep 26: punchlines: Luke, minutes: Razvan
  • Week of Oct 3: punchlines: Eric, minutes: Severin
  • Week of Oct 10: punchlines: Alex, minutes: Luke
  • Week of Oct 17: punchlines: Razvan, minutes: Eric
  • Week of Oct 24: punchlines: Severin, minutes: Alex
  • Week of Oct 31: punchlines: Luke, minutes: Razvan
  • Week of Nov 7: punchlines: Eric, minutes: Severin
  • Week of Nov 14: punchlines: Alex, minutes: Luke
  • Week of Nov 21: punchlines: Razvan, minutes: Eric
  • Week of Nov 28: punchlines: Severin, minutes: Alex
  • Week of Dec 5: punchlines: Luke, minutes: Razvan
  • Week of Dec 12: punchlines: Eric, minutes: Severin

Written by Severin

September 13th, 2011 at 9:32 am

Posted in Uncategorized

Introducing the MarkUs Team – Fall 2011

without comments

We are 5 students working on MarkUs – as part of UCOSP – this fall. Who are we?

Alex Krassikov

Alex is a forth year Computer Science student at UofT. He is the vice president of the Computer Science Student Union at UofT, creating ample opportunities for students to socialize and have fun while making valuable connections for the future. Alex has most of his experience in Java, C, and Python, but in the past has dabbled in languages such as Scheme. He occasionally uses his coding skills to make little apps that help him make accurate decisions in his favourite video games or help his fellow neighbours. Besides coding, Alex enjoys recreational activities which include but not limited to: ultimate Frisbee, playing board games, baking cakes and muffins, as well as staring at cute pictures of cats.

 

 

 

 

 

 

Luke Kysow

 

Luke is a fourth year Computer Science student at UBC. He has worked for UBC on their website UBC Events, for SAP in their Innovation Center and recently for EA on their FIFA site. Luke has worked in Ruby, PHP, Java, C, a little Perl and soon to be added Erlang, Haskell and Prolog! He has also done freelance work on the side, creating websites, and is in the midst of starting a company with a friend. When he’s not on the computer, Luke is rock climbing, bouldering, skiing and playing video games… okay that last one is on the computer too.

 

 

 

 

 

 

 

Razvan Vlaicu

RazvanRazvan is a fourth year computer science student at UW. He has worked all of his off terms while in school for a startup company in Waterloo called Aeryon labs doing software development for their product. Razvan has spent most of his development experience in C, C++, and Java. In his spare time he enjoys bicycling, running, and exploring the art of video game design.

 

 

 

 

 

 

Erik Traikov

ErikErik is a fourth year computer science student at UW. As a co-op student, some of my work terms have included doing SQL & PL/SQL scripting, teaching scheme and c/c++ to first and second year students at the university, and doing iPhone development in objective-c. In my spare time, I like to play dungeons and dragons as well as Magic: the Gathering. In fact, I was invited to nationals in august, and I will be attending a tournament this weekend (sept 17) in Montreal.

 

 

 

 

 

 

 

Severin Gehwolf

SeverinSeverin is a fourth year Computer Science student at University of Toronto who spent most of the last 16 months hacking on Eclipse plug-ins. In particular, Fedora Packager for Eclipse and Eclipse Linux Tools. Severin’s programming experience ranges from Perl hacking on XIMS, Ruby and Ruby on Rails to Java and Eclipse Plug-ins with some occasional forays into the C/C++ programming world. Severin studied business in Austria, has done Apache httpd web server administration, is now maintainer of some Fedora packages and currently works for Red Hat. He is mostly interested in operating systems, networking, Web programming and computer systems in general. He enjoys to hack on MarkUs in his spare time and will have a closer look at MarkUs’ performance this term. In his spare time he enjoys canoeing, skiing, running, reading, good food and the occasional beer as well as describing himself in the third person 😉

I look forward to meeting you at the code sprint!

Written by Severin

September 13th, 2011 at 3:35 am

Posted in Uncategorized

Week 8 : Markus Plagiarism and Markus Research

with one comment

Markus Plagiarism

Benjamin Thorent

  • Status
    • Worked on the interface (configuration form)
    • Ruby tutorials for interface
  • Roadblock
    • Hard to understand/see some links between files
    • Lack of time this week
  • Next steps
    • Work on the database to finish the form
    • Work on results display
    • Work on Ruby scripts

Shion Kashimura

  • Done
    • Work on Ruby scripts
  • Road blocks
    • Many files to see to understand the global functioning
  • ToDo
    • Final report
    • Finish scripts

Markus Research

Anthony Le Jallé & Michael Lumbroso

  • Status
    • We found a way to have math support in annotation, it allows math to be
      specified in TeX, LaTeX, or MathML notation. It uses the MathJax library
      (http://www.mathjax.org)
    • The solution seems to be fully cross-browser.
  • Roadblocks
    • Identify every file where annotation is displayed and include the MathJax
      solution.
  • Next steps
    • Writing user documention about how to write math equations in annotat

Written by nvaroqua

March 19th, 2011 at 4:47 pm

Posted in Uncategorized

Week 7 : Markus Plagiarism and Markus Research

without comments

Markus Plagiarism

Benjamin Thorent

  • Status
    • Report on CPD
    • Managed to make Ant work with Plaggie
  • Roadblocks
    • Ant difficult to handle
  • Next steps
    • Work on the MarkUs Interface
    • Work on the Plaggie output

Shion Kashimura

  • Status
    • Last version of specification book
    • Ruby tutorials
    • Began to work on the Ruby script
  • Roadblocks
    • Sometimes hard to understand how Ruby scripts, Ant, and Plaggie can be
      linked
  • Next steps
    • Work on the MarkUs Interface
    • Work on Ruby scripts

Markus Research

Anthony Le Jallé & Michael Lumbroso

  • Status
    • Scope statement finished (not fully completed but we know where we are
      going).
    • Start to implement ideas for MathML support.
  • Roadblocks
    • MathML is not fully cross-browser.
    • Michael had no internet connexion last week.
  • Next steps
    • Choose the better solution for MathML and implement it.
    • Start to modify Markus to fit Markus Research.

Written by nvaroqua

March 19th, 2011 at 4:42 pm

Posted in Uncategorized

Week 6 : Markus Plagiarism and Markus Research

without comments

I’m sorry for the late feedback on what ECN’s student have been doing. Here are the punchlines of Week 6 !

Markus Plagiarism

Benjamin Thorent

  • Status

    • Report on CPD
    • Managed to make Ant work with Plaggie
  • Roadblocks

    • Ant difficult to handle
  • Next steps

    • Work on the MarkUs Interface
    • Work on the Plaggie output

Shion Kashimura

  • Status:
    • First version of the specification book
  • Road blocks
    • Took a lot of time to write specifications (we had to modify our conceptual
      model and user interfaces several times)
  • Next steps
    • Second version of the specification book (taking into account comments from
      everyone)
    • Report on Plaggie
    • Begin to write Ruby script independently from the choice Plaggie/CPD
    • Begin to see for user interfaces in MarkUs

Markus Research

Anthony Le Jallé & Michael Lumbroso

  • Status
    • We have a complete but not final version of the scope statement.
  • Next steps
    • Finish the scope statements according to commentaries of the clients.
    • Start the implementation
  • Roadblocks
    • Time & Holidays

Written by nvaroqua

March 19th, 2011 at 4:36 pm

Posted in Uncategorized

Markus Plagiarism

without comments

The two students of Morgan Magnin and Guillaume Moreau, both teachers
of the computer science department. I am in charge of helping the students with
the technical aspects of Markus.

The Markus Plagiarism Project

Plagiarism can be defined as trying to pass off (parts of) documents (text,
source codes…) written by someone else as one’s own (ie, without indicating
which parts are copied from which author). Plagiarism occurs often in academic
environments. Students then intentionally or unintentionally include sources
in their work without a proper reference. Manual detection of plagiarism in a
collection of hundreds of student submissions is infeasible and uneconomical.

As far as Markus allows correcting assessments, it could be interesting to
know when a student’s work is plagiarized from another student’s work.

That is where the purpose of this project comes: integrating a tool to detect
plagiarism in the project available on the Markus interface. Some softwares
already exist. The students mission is then to develop or to see how to
integrate anti-plagiarism tools in Markus

Organization of the project

The way Ecole Centrale de Nantes manages students projects is a bit different
from the canadian format.

In particular, students are expected to write a document before beginning the
project with the specifications of this project, and to describe all the steps
of the project. You can find an example on the <a Sections implementation :

That also means each project has a specific goal, and should be ended by the
end of the term.

For Markus Plagiarism, the first step Benjamin and Shion are taking is to have
a look at ways to detect plagiarism, and existing solutions. The second step
will be to decide on a solution, then to start implementing it.

Possible Solutions

Ideas of criteria for plagiarism
detection

Here are a few ideas Benjamin and Shion found plagiarims on source code.
Some of them were provided by Guillaume Moreau, and where mentionned in a
previous post: http://blog.markusproject.org/?p=1346

  • Compare name or/and the number of classes and functions
  • Compare the structure of the scheme of classes (number of classes and
    associated functions and attributes)
  • Compare a randomly chosen sequence (a few lines) of the code, forgetting
    about the layout.
  • Compare the order of all variables used, excluding names often used such as
    i, j, temp…
  • Compare the order of elements (classes, functions, variables)
  • Compare the comments and also check homogeneity of spell mistakes all
    through the comments
  • Check for the homogeneity of coding styles through the entire code.
  • When tests are provided with the source code, test the compilation of the
    code. If the code does not compile, there is a high probability of
    plagiarism.

Issues

Different criteria can be more or less relevant depending on the size, the
complexity and the language used. Also, teachers may provide code to students
for an assignment. The two solutions proposed by Benjamin and Shion to counter
these issues are the following:

  • display a probability rate, or a score instead of a boolean result
  • the teacher would set some parameters depending on the assignment (like the
    code provided)

Benjamin and Shion also raised the possibility of performance issues. I’m not
too afraid of that, as the process can run at night, or at an hour where
students are not supposed to work (nor teachers).

I will soon post more informations on the solutions Benjamin and Shion have
found and studied !

Written by nvaroqua

February 1st, 2011 at 7:14 pm

Posted in Uncategorized

Work Started, Work Completed, and Work Yet to Come

without comments

Whoops – we’ve already started off a brand new semester, and we forgot to write about what happened in the Fall!

So, without further delay, here’s what happened with the UCOSP team last semester for MarkUs:

Projects that we started…

There were 3 main projects last semester.  In no particular order, they were…

Re-mark Requests

Vivien and Misa were tasked with implementing a re-mark request feature.  This feature would allow students to request re-marks, and have graders / instructors issue re-marks, all within MarkUs.

    Dashboard Statistics

    Hora and Kurtis were asked to put some graphs into the MarkUs dashboard to display mark distributions and other useful data.

    Automated Testing Framework

    Evan was put to work tackling the long-awaited automated testing framework feature.  The idea is that students (and graders) should be able to run submitted code through a series of testing suites, and get the test results back, all within MarkUs.

    You can read about each project in more detail here.

      What got finished…

      Misa and Vivien put together some great mock-ups for the Remark request GUI, sorted out a new database schema to support it, and wrote the majority of the code to get the feature working.  There are still some leftover bits that still need to be merged, and Misa / Vivien will be finishing up that work in the next few weeks.

      Kurtis and Hora found a great Javascript graphing library to use (Bluff), and also figured out how to nicely cache statistics within MarkUs in order to keep the Dashboard snappy.  The code is more or less finished, and just needs to be merged.

      When he wasn’t helping us with user and developer support, Evan was kicking butt on the automated testing framework, and he got a lot done – especially with regards to the token system, which allows instructors to control how many times a student can run tests.  There is still some work to do before the automated testing framework can be considered finished, and will likely be pushed at again this semester.

      What’s left to do…

      So, for the re-mark requests and dashboard statistics, we need to do some last minute merging and polish.  For automated testing, we’re definitely going to need another round of focused development.

      Anyhow, that’s where we got to.

      Great job everyone!

      Written by m_conley

      January 11th, 2011 at 2:33 pm

      Posted in Uncategorized

      Who is Doing What: Winter 2010

      without comments

      The MarkUs team is meeting weekly on irc.freenode.net #markus on Fridays at 3:30PM.  Every Thursday, each member of the team (including myself) must come up with a “punchline” status update.  These updates are short, bulleted, straight-to-the-point reports that tell us how everybody is doing.  They follow a very simple format: see these three examples.  The punchlines need to be published on this blog every Thursday, and it is every team member’s responsibility to give them a read before coming into the meeting.

      But instead of everybody logging in and editing a single blog post for the status updates, we’ll rotate responsibility for collecting/publishing punchlines every week.  Similarly, we will rotate the duty of converting our IRC meeting logs into notes.

      Here’s the schedule outlining who is doing what each week.  Teammates:  I highly suggest bookmarking this page.

      • Jan 22:  punchlines:  Mike, minutes:  Robert
      • Jan 29:  punchlines:  Robert, minutes:  Farah
      • Feb 5:  punchlines:  Farah, minutes:  Joseph
      • Feb 12:  punchlines:  Joseph, minutes:  Victoria
      • Feb 19:  punchlines:  Victoria, minutes:  Bryan S
      • Feb 26:  punchlines:  Bryan S, minutes:  Brian X
      • Mar 5:  punchlines:  Brian X, minutes:  Mike
      • Mar 12:  punchlines:  Robert,  minutes:  Farah
      • Mar 19:  punchlines:  Joseph,  minutes: Victoria
      • Mar 26:  punchlines:  Bryan S,  minutes: Brian X

      Written by m_conley

      January 18th, 2010 at 9:04 pm

      Posted in Uncategorized

      Marking Scheme for Gabriel, Mélanie and Simon

      with one comment

      Since Gabriel, Mélanie, and Simon are focusing on the development of the same feature, they have decided to use a team evaluation scheme.

      1) Flexible marking scheme feature completion: 30%

      • An instructor can choose/change which marking scheme an assignment should graded with.
      • An instructor can add/edit flexible criteria for an assignment.
      • An instructor or TA can grade submission with the flexible marking scheme view.
      • A student can consult his results with the flexible marking scheme view.
      Create or edit assignments As an instructor
      I want to be given the choice of which marking scheme an assignment should be graded with.

      2) Automated testing: 20%

      • Unit testing
        • Tool integration (ex : mocha)
        • Use of mocks to isolate units.
        • Code coverage (average of 85%)
        • Meaningful test cases
        • No test failure
      • Functionality testing
        • Tool integration (ex : Selenium)
        • Meaningful test cases
        • No test failure
      • Acceptance testing
        • Tool integration (ex : Cucumber)
        • Meaningful test cases (the most important acceptance criteria for each user story)
        • No test failure

      3) Documentation: 20%

      • The code should be documented
      • The tasks for this feature should be split up into tickets with clear descriptions
      • There should be a document posted under “MarkUs Component Descriptions” on the DrProject site that explains the current state of the feature, future plans, etc.
      • There should be a short screencast of the feature posted on the DrProject site

      4) Overall Process: 30%

      • Blog posts, status reports, or review requests indicated steady progress throughout the term
      • The new marking scheme respects the client’s request.
      • Good programming practice (clear code, small methods, use of constants, OO architecture)
      • Consulted with other team members about design/implementation decisions and/or helped other team members (eg. through blog posts, review requests etc.)
      • Contribution to the existing tests.

      Written by simonlg

      October 30th, 2009 at 11:58 am

      Posted in Uncategorized