Victoria Mui – Midway Update

Expectations, Status & Progress

Coming into this UCOSP project course, my ultimate goal was to be able to utilize the human-computer interaction (HCI) and user experience (UX) design knowledge that I’ve acquired from both school and work to enhance the usability of MarkUs.  Through this experience, I’m hoping to solidify my understanding of various usability concepts and familiarize myself with more projects out there.

Up until now, I feel that I’m on track with the work that I’m doing with MarkUs.  I’ve been spending most of my time redesigning and reorganizing a lot of features and functionality MarkUs currently offers.  There’s no better way to do this than to keep prototyping and getting user feedback through usability sessions.  Because of my full-time position, I have not been able to collect as much usability feedback that I’d like to in person.  But I’ve found that running these designs by the team is often just as helpful.  But most importantly, having a supportive supervisor to help collect the user feedback certainly helps me since I am working remotely most of the time.

In short, I think I’ve stayed on track because: I have already redesigned quite a few views; and have made various suggestions to the overall MarkUs interface.

Things I’ve learned thus far

In the past, I’ve done very little usability work for web-based applications, and I’m also very new to designing interfaces from scratch.  Thanks to my team, I’ve learned quite a few things about designing web interfaces in particular.  For example, small things like screen resolution will have a huge impact on the usability and presentation of the entire user interface.  So it’s certainly something that needs to be considered early in the design cycle, and kept in mind at all times.

Another key thing that I’ve learned up until now is the prototyping tool, OmniGraffle.  Instead of seeing the tool as being a burden, it has now saved a significant amount of my time.  For example, I am now more comfortable using new canvases and layers in my prototypes wherever I see fit.

Next Steps

In the remainder of the course, I plan to continue working on the UI of MarkUs.  I focused on the Grader Assignment and Group Formation views for the first half of the term, but those have now been addressed.  Next, I am planning to tackle the Properties view – our goal is to make the Properties view intuitive to not just regular users, but also those that are using MarkUs for the first time.  New designs for the MarkUs Dashboard are also to come.

I’d also like to maintain the good communication and coordination we’ve had as a team in the weeks to come.

I’ve had an awesome time working with the team, and I’m looking forward to the rest of the term!

Fatima’s Midway Update (Pony-Build)

Few months ago,when I first joined Pony-build, I was excited and eager to learn more about this project in particular and open-source in general. I knew my limited experience might make my progress slower than expected but I was determined to learn more no matter what.
I couldn’t join the UCOSP community for the “Code Sprint” in Canada; however, I started to communicate with the project lead Titus C. Brown and the rest of the group via Skype to make the initial system set ups. I encountered many problems throughout the process, but Titus was always patient and very helpful.
Getting familiar with Git and the already written code  took me more than a while. My first build fully worked after few weeks , but when I have started my second one, it took me few hours to get it build and compile which shows the big progress I’m making.
I have also learned how to ask for help from the rest of the group, who have been ready to lend a hand when needed.
Today, my enthusiasm remains the same and I’m ready to learn more.

Xiaoxiao’s Midway Update-Ingres

My overall progress is a bit slower than I expected, because environment setup took me too long in early February. But I have started implementing actual code and current progress seems good.

The main difficulty I have had so far is setting up development and testing environment. A large scale open source project such as geotools requires me to install and configure a lot of programs before development starts. Therefore, this setup progress is time-consuming and requires attention to detail.  I set one argument in a single program’s configuration to a wrong value, and the whole project wouldn’t build. This mistake wasn’t discovered until after I spend 5 days double checking all settings and with Lim’s help. Moreover, a Ubuntu crash forced me to reinstall the system and to started all over again. However, I find this (rather painful) process valuable and rewarding, since this is the first time I need to do so many configurations at the same time(linux, java, eclipse, mvn, geotool, geoserver, openvpn) to make software work.

The reading overhead is also much more than the actually development. I have to spend at least 3 hours per week to read online documentations, mailing lists, and book.

But the overhead in setting up environment and reading greatly helps us to understand what we need to write. Writing code is really the last and easiest thing to do if you can understand the problem to solve.

Midway Update- Khushboo Shakya

UCOSP has been an adventure for me. From the time I made my mind to participate in this program, I have had lot of different/ new experiences.  Getting excited about attending the code sprint and then getting denied for the visa was the first one. For once, I thought I won’t be able to participate in UCOSP. But fortunately, I still could. With the help of Skype, we had a virtual code sprint for our group, Pony-Build. It was a little hard at the beginning, especially for me because I had little to no experience on thing Titus (my lead) was talking about. But I had a good team; everybody helped me with setting up for the project.

The first task was to run the example script to see if the script works in my local machine and the server. This took few days as my computer was not set up properly. But finally I got it working. The next task was to choose a python package and to develop a build script. I chose the nose package and started working on that. Titus already had some example build scripts in his Github so it was a big resource for not just me but all of us in the team.  During the time when I was working on the nose package, I learned a lot about how build scripts work and also about Github. Getting used to Github took quite some time. The idea of different branches and repositories was quite new to me. I had done some sub versioning in Netbeans but this was something different. Now that I know how Github works, I feel much more confident. While working with nose builds script, I came across a lot of problems which helped me learn and understand these problems: what certain error means and how to solve and avoid such errors. Google has been the best friend all this time. I took quite a long time to do this but it was all worth. For my next task, I have chosen to work on building more scripts. I want to continue building more scripts so that I am more confident. Maybe I will do something different after this.

So far this capstone project has been a learning experience. I have learned my mentors, friends and Google! As I said earlier UCOSP has been an adventure for me and I hope it will still remain the same in the next half of the semester.

Cheers Khushboo!

Midway Update – Wei Xian Woo (Thunderbird)

I am not proud to say this, but my performance on Thunderbird could have been better.

Am I behind?

• Yes, I am at least three weeks behind the schedule I set for myself. I would have liked to submit my first patch by the end of January, but I ended up doing that only in the third week of February.
• At the start of the term, I broke down the feature I was responsible for implementing into reasonably sized pieces and estimated that each piece will take approximately 1-2 days to implement. Even at this point, I feel that those estimations were fair and achievable given what I knew about my schedule at the time.

Why am I behind?

• The term turned out to be a lot busier than I originally anticipated – for school (assignments + a research assistantship) and preparation for external exams
• Figuring out how certain pieces of Thunderbird code interact with each other and where certain things are took longer than expected. For example, where/when is the first Thunderbird main window created? (No, searching for “startup” and other related keywords did not help.)
• I spent almost two full weeks understanding the various types of Mozilla unit tests and identifying one that can do what I need. Mozilla has 7-8 types of these, out of which only 3-4 of them are currently used in Thunderbird. This time I felt was badly spent because asking Blake (which I had to do anyways) would have gotten me an answer much quicker.

What have I learnt up to this point?

• How Mozilla apps (in particular, Thunderbird) work. The whole idea of using JavaScript to implement a feature like session restoration and storage is pretty fascinating.
• Writing tests – despite having five co-op work terms of development experience, I definitely learnt some good stuff about testing here.

So, how’s the remainder of the term going to look like for me?

• Within the next 2-3 weeks, I hope to finish up the remaining pieces of the feature. In fact, my revised 1st patch is almost ready as I write this and should be ready for submission sometime today.
• I hope to be able to work on at least one other bug for the final month, which will hopefully take less time to tackle now that I have better understanding of how things work in Thunderbird.

The “Engineering” in Software Engineering

My first degree is in engineering, and while I’m too clumsy to have ever actually practiced [1], the courses I took still shape the way I look at things. In particular, I still enjoy articles like this one,which reports parse and load times for Javascript on various platforms. I really wish that a course on systems performance was a standard part of every undergrad CS degree; I doubt that’ll happen any time soon, but this stuff is out there if you look for it. And see also this post about scaling up Django — again, there’s lots of good engineering thinking on show.

[1] The scar on my right hand is from picking up a soldering iron the wrong way around twice in one afternoon.

Jackie Huynh – Midterm Update

Wow, it’s already half way through the term. Working with Greg and the Basie team has been a great experience. I am glad that I chose Basie as the project to work with, as I got to learn Django and Python. I feel that I’m working at a pretty good pace with Basie, but sometimes I feel that I’m not doing enough when compared to the more experienced members on the team. In the next half of the term, I will try and set better goals for myself, and strive to achieve them.

Additionally, during the next half of the term, I would like to learn more on web development in general, and JQuery. This is my first time working with JQuery (and Django) and I’m surprised how well JQuery works. It was pretty simple to pick up JQuery, but I feel that there is still a lot to learn. Also, I feel that my team has some very experienced members and that I could really benefit from working with them.

During the first half of the term, we’ve been bashing away at bugs and getting Basie 0.6 released. This coming half, I’m really looking forward to improving Basie by adding new features. Now that I’ve gone over most of the learning curve of Django, Python, and JQuery, I hope I can achieve more than before.

The Mercurial Team’s Midway Report

When we set out at the beginning of UCOSP, my goal was for us to contribute significantly to Mercurial by the end of the semester. How well have we accomplished that goal so far?

At the beginning of the semester, all of the students were given small, self-contained bug fixes and features that we’d discovered people wanted over the course of developing Kiln, mostly in the form of Mercurial extensions. Four of these were quickly completed: cedit, a command-line-based way to configure Mercurial; cache-annotations, which makes annotating files repeatedly ridiculously fast; globexclude, which allows you to exclude files based on their glob pattern when doing conversions to Mercurial; and caseguard, which warns you when you are committing files that have names that will prevent Mac and Windows users from using your repository. Of these, globexclude and caseguard will be submitted (with some slight modifications) for inclusion into Mercurial 1.6, and cache-annotations already ships with every version of Kiln. This part of the project I consider a complete success.

Since then, we have transitioned from everyone doing a little project to everyone working on bfiles, an extension to Mercurial that is designed to ameliorate using Mercurial with projects that involve large binary files.

I would be lying if I said I wasn’t slightly disappointed with the work done on bfiles so far—not really through any fault of my students, as much as due to the nature of what they’re trying to accomplish. bfiles is necessarily a more complex problem than the initial, self-contained feature sprints: bfiles requires some changes to Mercurial’s workflow, and these changes don’t always have a single, straightforward solution, and so everyone has to take the discussion to the Mercurial mailing list to figure out how to proceed. Having these discussions is unquestionably not a waste of time. These are delicate issues, and working with the Mercurial community to determine how to proceed is an absolutely necessity. This has, unfortunately, had the side-effect of delaying writing some of the code we wanted for bfiles until we can get some of the design straightened out.

I’m nevertheless still very optimistic for the second half of the semester. We’ve sorted out a lot of the hard issues, allowing everyone to begin focusing on writing code again (even if only for initial prototypes, in some cases). Simultaneously, we’ve begun working on some aspects of bfiles that do not require so much debate to ensure that we’re doing the “right” thing. This means we can continue to code, while still carefully consulting the community on ambiguous areas.

Balancing requirements gathering with simply getting the code done can be a complicated affair on open-source and commercial projects alike. I think we’ve been erring too much towards discussion in the last couple of weeks, but as long as we can correct ourselves soon and get focused on the code again, I’m still confident that we’ll get nearly everything accomplished this semester that we set out to do.

Miles Midway Madness

Eclipse4Edu has gone fairly well. I feel like I am pretty much on track. I’ve been trying to put in one day a week towards this project and I’ve pretty much managed to do that. I think my major goals for this semester are to get the new Java class wizards and classes in good shape and get a good handle on simplifying the menus and toolbars by the end of the semester. I think this seems reasonable based on my experience with the first half of the semester. The code base is large and the process of coding while trying to integrate into the current code base is time consuming.

I’ve been pretty happy with the way that I give justifications for the patches I’ve submitted but I wish I could get a bit more feedback on those patches and other ideas. This is one thing I could improve on is try to get feedback a bit more quickly from the mentors on patches I submit. They seem open to me emailing them and harassing them so I should do that.

Working on open source has been an eye opener and a great learning experience. I am not used to working on such an open ended project where we can drive a lot of the direction and can make so many choices about our approach to the work. Also I was a little surprised by is that even in large, well known pieces of software like Eclipse there can be some really ugly code (I’m looking at you JDT new class wizard). The feedback from the mentors and other students on coding choices and ideas has also been helpful.

Best of luck to all the other students.

Cheers, Miles

Bryan Shen’s Midterm Report

Two months have passed since I joined Markus in Undergraduate Capstone Open Source Project (UCOSP). I thought it was just another course, but it’s a completely different than every other one I’ve ever taken.

The most noticeable difference is that no instructor is around! In a regular course, I am told how to do stuffs. I sit in a comfortable chair in the classroom, follow the instructions given by teachers and do best I to meet their expectation. This is all good, but most students end up acquiring a subset of the knowledge the teachers have in such courses.

It’s interesting that in UCOSP there is no such a instructor who knows “everything”. We use Ruby on Rails (RoR) to develop Markus, but I never had used any programming language similar to Ruby. I had to use it while still learning. It took me some time before I figure out this difference and notice how important it is.

When I started, I got a RoR book and stick to it as if it was an instructor. I read it page by page carefully, which I usually do in a regular course. But soon I found myself fall behind than other members. The book was too much to learn. With the speed I read it, I wouldn’t finish it before this semester ends. And even if I go through the whole book, I wouldn’t have enough knowledge to go with Markus, because RoR is developing so fast that Markus uses many third-party RoR plugins that the book doesn’t even cover. This forces me to take the other approach – set my learning objectives and learn only what is needed. I learned the syntaxes of Ruby languages and get the idea of Model View Controller (MVC) from the RoR book, where concepts are well organized. Then I studied the source code of Markus myself, and ask my google and my other team members whenever I have difficulties. As I look into more parts of the project, my knowledge of RoR has grown significantly. Since everyone is dealing with different aspects, we all have different sets of knowledge. When one has a problem, it is very likely another knows the solution. We are actually learning from each other. It is a good lesson for me – after all, self-learning and learning from peers will be a major way of acquiring knowledge in one’s life.

Honestly, I haven’t been doing as good as I expected. I was not wise enough to break a big task into small pieces. When I needed to fix a small bug, I could do it efficiently, even if there were lots of technical difficulties. But when a bigger task was assigned, I couldn’t do it as efficiently, because I tried to solve the task as a whole instead of dividing it and tackle it piece by piece.

Markus project once again tells me the importance of communication. Working on a project in a team is not like writing an algorithm alone.

By now, I’ve fixed several high priority detects of the Markus project, and I’m currently working on an enhanced feature.

I enjoy working on Markus. I feel honored when users make some positive comments and when I solve some defects they report. Within the remaining two months, I believe I can fit myself better in this position and generate more output to the project.