Author Archives: demelode

About demelode

UWO Compsci/Visual Arts Double Major

Meeting Minutes March 16, 2013

– Hiro and Yurimingo are getting close to the endpoint for the work period. Jon is the week after them.
– Please post status reports on time from here on out.

– Lots of progress in final major task.
– Moving forward, address the current reviews on both tasks.
– After thats done, more in-depth reviews will be provided.
– Reviewing other course-mates work is a goal as well.

– Wireframes and mockups are a great way to plan for future design.
– A goal will be to make the user page trophy display area more attractive/polished up.
– Lets get a WIP up as soon as possible for the ‘Importing Trophies’ task.

– To address question: <name> is a python capture group.
‘’, name=”group”),
what is “<name>”?
that’s part of python regular expressions
yurimingo: ah – ok, so a URL definition is a regular expression with some special features
it’s called a “capture group”
it means that anything that matches “[A-Za-z0-9_-]+” will be accessible in the match object using m[‘name’]
i see
yurimingo: this is the function that this URL redirects to:
yurimingo: the name is going to be extracted, and passed to this function
oh thanks
yurimingo: not to be confused with the ‘name=”group”‘ at the end of the definition
yurimingo: that part is for naming URLs – see

– Address more efficient querying by ID, and not by review request.

– Done implementation of handling multiple trophies, awaiting reviews.
– Please go through the current review request and mark issues as closed if they  have been addressed.
– For the last two weeks, doing some code reviews and easy fixes are a good option.


Meeting Minutes for Group B – February 23, 2013


  • Thanks to everyone for getting the status reports in on time.
  • Make sure to look at the calendar, as the “midterm” of our time here is upcoming — make sure you look at your goals and let the mentors know if things need to be honed in/adjusted (communication is key).


  • Jon:
    – Has completed first full review request of task.
    – He should deal with results of reviews, and also start looking at the hackpad ideas.
    – Some ideas are: extend the submit banner to inc. new optionals, maybe work on extensions
    – It’s midterm week so maybe pick something small to work on.
  • Yuri:
    – Has questions about testing.
    – Don’t worry about unit testing until after the feature is working.
    – The relationship between review requests and trophies is hard to understand.
    – Make sure to fully remove unused/old code when its core use is discarded, including the evolution readjustment.
    – Achievable goals should be set for next week, things need to be broken down to a measurable level.
    ChipX861) Be able to list all trophies that stored in the database. They should appear on the user page, with the icon, and with the review request ID. 2) Make sure that is using Hiroki’s latest model, and not the stuff in LocalSiteProfile. 3) after that, write some code when a review request is published that creates a Trophy. Just do it for every review request for now, to make sure it works.
    – Best order of dealing with this would be 2 -> 3- > 1
    – Email the mentors a copy of your plan for the week.
  • Hiroki:
    – This week, he has added database usage, and wrote a unit test.
    – Let’s see a WIP request after the meeting.


Shoot First, Ask Questions Later — Or Not?

Originally posted on February 20, 2013

It’s been quite a ride so far at Review Board, that’s for sure.

Jumping into a project the size of Review Board can be a daunting task, especially when many of the frameworks, languages, and features included in the project are new to learn or in use at a much more advanced level then what one is used to when dealing with class projects.

It’s almost natural as a student to sit back as an individual, take the time to research and browse the internet for hours on end to find an answer to question sets or programming roadblocks, because students like us are required to only work alone and not receive outside help.

Honestly, I’m sure I’m not the only one who heard the big, “Ask us questions, us mentors are here to help!” at the meetup — only to sink right back to the classic student-is-alone attitude once getting back to the realities of university.  That combined with the struggles of course time dedication are definitely the death knell for any UCOSP project member.

However, after completing my first major task-set for Review Board, I’ve learned many things about languages, frameworks, development processes — you name it, the list goes on. But the two most important lessons that I’ve learned are definitely time management and using my resources. If you saw my schedule, you’d think I was insane, as it’s jam packed with school work, classes, and a high intensity, high hour part-time job. But somehow I’ve been able to set aside sections of time each week — whatever large chunk of time I can get — so that I always see myself moving forward on my tasks, as the last thing I want is to fall off for a week and not know where to get back up.

Finally, and most importantly, it’s all about asking questions. Use the mentors, they are like a dedicated Google just for your task. They aren’t marking you or assessing you — they are only helping you. Remember, this project is their project too, so they just want to make it better. Case and point, last night I was stuck on one of the final portions of my task, and my task is interesting as it doesn’t stay in one realm of the project, but instead encompasses just about every layer within the codebase, and thus is a whole lot to take in. Now, this part that I was stuck at led me down a path of uncertainty.

“Where is this error coming from?”

Well, before starting down what could have been a classic hour(s) long search-fest, I just popped the question down into IRC to see if it was familiar to anyone else, and it was amazing. Not only did the mentor (ChipX86) know exactly where the fix would be, but the location of the fix was in a place I didn’t even know existed, and definitely would never have found alone. That one question most likely saved me hours of searching and thus allowed my code delivery date to be that very night, instead of a week and a half later, or worse.

I like my time, as I don’t get enough of it nowadays.

So no more of this, “Shoot first, ask questions later” — because that just a waste.

Progression and Roadblocks

As per request, I am reposting my blog posts. This was originally posted on February 1, 2013.

Well, I finally got to sit down for more than an hour today, and here’s my progression.

As mentioned previously, last week I dealt with confirming the front-end design in the /templates/reviews/review_request_box.html template, as well as improving the relationship models for the dependency relationships in /reviews/

Today I was able to delve into the /reviews/, and I was able to set up an initial representation of the relationships within the admin panel. It’s full functionality is still waiting on the web API connections to be completed, but that will be referenced later.

Next, I was able to jump into the /reviews/, and begin to really research the inner workings of ReviewBoard. I was able to significantly improve my understandings of both the Django view framework and how it relates to this project, so it’s looking quite promising for now.

This new perspective allowed me to finally delve head first into the monster that is the /webapi/ file, and I was able to do some initial progress adding the dependencies into the whole mix. Specifically, I was able to contribute to the _set_draft_field_data function within the ReviewRequestDraftResource class, adding in the dependencies.

I’m going to follow up with some new additions over the next few days and see where this leads me. Some expected roadblocks could be confirming the connections that I’m building, properly addressing how to deal with drafts becoming published, and how to properly infuse these new features into the front end (i.e auto searching possible reviews, confirming that reviews exist when added, concurrency, etc.)

Week 1 Status Report

As per request, I will be reposting my blog posts. This was originally posted on January 27, 2013.

  • What did you do this week?

I got settled back into my normal schedule, attended my classes and had a bunch of work shifts piled onto me due to them allowing the weekend off (unheard of when working part-time retail).

For my project, I took a more in depth look into the overall Django environment; as like I said in our weekend, I am relatively good with Python, but I am new with Django and its MVC design structure.

For my task of Depends On/Blocks, I’ve researched into how the ReviewBoard system completes its inner-workings, and started mapping out some ideas on how to implement my task. I’ve set up the initial HTML/CSS mapping for the front-end, and have mapped out and implemented the potential models for the relationships.

  • What is blocking you from progressing?

At the moment its mainly getting the time to sit down and get things done (I have an open upcoming week so I should get some substantial progress), and just my overall knowledge of the layouts of Django and how ReviewBoard is structured (I’m really close to getting it all contextually understood).

  • What are you going to do next week? 

As I mentioned, I’m going to get some good time in to my goals, and hopefully I’ll get some progress going in addressing the internal connections to get Dependancies operational. From then, I might be able to address any outlying bugs that evolve from my developments.

  • Do you have any questions?

At the moment I’m good, but I know IRC is the place to be, so I’ll ask them there.

Depends On/Blocks Project

As per request, I am reposting my blog posts to the main feed. This was originally posted on January 19, 2013.

So it begins.

I’ve decided that my first project on ReviewBoard will be the task of adding two new list fields within a review request; namely the Depends On and Blocks sections. The Depends On will allow the ability to list previous requests within ReviewBoard that require completion before the current request can be fully addressed. Inversely, the Blocks section describes previous review requests that require the current request’s completion.

To do this, I’ll have to edit the front-end to display the new fields. Furthermore, the backend must be changed to allow for the new additions to the review request modelling, along with the validations for if the previous requests are valid request ids.