Designing a Prezi

Over the weekend we started designing a Prezi for our final group presentation.  I had never used Prezi before, so I went through the tutorials to learn the basic functionality.  Working with a fully customizable blank canvas poses the added complexity of design flow.  I really like the concept of Prezi over PowerPoint, since it is so much more customizable, but I do think that it will take longer to finish.


As far as progress, we have not gotten very far yet, but it is fun to work with, and today we will be working on it more as a group.


In addition to playing with Prezi, I also finished the group evaluation form that is due today in class.

The End is Nigh

Our big group bug ended up being a flop.  Glenn spent a week or so to stitch together 3 images to test the bug and our solution (<3Gb, =3Gb, >3Gb).  The bug stated that images over 3Gb wouldn't render properly, but we were having issues loading MUCH smaller images, even less than 1Gb.  Having only 1.5 weeks left of class, we don't have the time to futher problem solve this issue.

Since our group bug seemed like a dead end, our group considered working on my 2nd bug as the new big group bug, since it ended up being more complicated than I initially thought.  However, when trying to test for the bug existence, the patches and test files included in the bug report were alone proving to be troublesome.

To further complicate things, this bug requires design clarification before we can imlement a patch, and would require many back-and-forth emailing with the VTK developers.  We would have to discuss implementation specifications before even starting to fix the bug.  Based on past experience communicating with the developers, this conversation alone could take weeks, especially since we are not  very established in the VTK community.

This bug would probably have been doable if we had initially chosen it as our group bug, but now it doesn't seem like there is not enough time.

That being the case, we are planning on bringing our bug fixing to an end and instead start to focus on our group presentation (using prezi).  At least we were all able to experience the entire OpenSource code commit process from our first individual bugs.  Today, we are planning on meeting to start our designing/creating our presentation.

Next Bug

Over the weekend, I took some time to implement the patch code from the attached files on the bug report (http://public.kitware.com/Bug/view.php?id=11231).

I had some issues getting the images to render, so I decided to spend the rest of my time reading and understanding the code.

Today, we need to work on our group bug.

An Approved Code Submission, and the Ominous Superquadric Source Bug

After our meeting last Tuesday, I decided to poke the VTK developers again, since my bug fix code still hadn't been reviewed/approved.  According to email responses that my other team-mates have received, the VTK developers are going to try to be more proactive in approving smaller bugs, since this is how new contributors get involved.


Yesterday, I got a reply email from David Thomas, one of the lead developers, saying that my code had been reviewed, and that the changes were approved.  


I can officially say that I have completed the full cycle of contribution to an Open Source project!! =D
(and it feels good)


However, we still have to complete our group bug, and our 2nd individual bugs.


That being the case, I started doing research for my next bug squashing:
0011231: Superquadric source has y axis orientation but claims to provide z axis orientation.


Basically, there are two conflicting statements.  vtkCylinderSource.h states that the axis of the cylinder is aligned along the global y-axis, where as in vtkSuperquadraticSource, the default axis of symmetry is stated to be aligned along the global z-axis.  HOWEVER, when rendered, both the cylinder and superquadratic appear next to each other aligned along the same axis of symmetry.


This bug might be as simple as changing the verbage in the documentation and IO statements, or as complex as re-rendering in the appropriate direction.


I need to send out an email to the developers to clear up this discrepancy.  A plus though is that the bug tracker has test code attached, so I should be able to start hacking away at it soon.

UPE Indution

Today was the UPE Induction Ceremony.  Pothering, Pharr, and Stalvey were in charge of the induction.  Overall it was a nice quaint ceremony, and a great honor.  The food and socialisation afterwards was very enjoyable.

As far as the VTK project goes, I still haven't gotten a response from my code submission, and will have to contact the developers again.  Hopefully today we will make some headway with our group code change.

POSSCON

Last Thursday (24th) I attended POSSCON.  I rode up with Tony to keep him company, but ended up sleeping the whole way >.>


The building that POSSCON was being hosted in was spectacular.  I loved how open it was, and felt that the organization of the event was nice.  Before attending any of the lectures, I grabbed a muffin and stopped stopped by a few of the interesting booths including Oracle, HSSC, MakerBot, and Linode.  At each of the booths, I engaged in conversation with the representatives.  The 3d printer, MakerBot, was pretty fascinating, although I had heard of them prior to POSSCON.  The plastic models were cruder than I expected them to be, but I see it's value for prototyping.


The rest of the day, I bounced back and forth between the Education and Healthcare sessions.


First, I attended Education seminar by Allen Tucker about FOSS projects and using them for educational purposes.


For the 2nd session, I attended Healthcare to learn about models in Healthcare Information Systems, but was disappointed when the spokesperson didn't show.  Instead they ended up holding a panel of individuals who discussed opensource in healthcare and were available to answer questions.


During lunch I was introduced to Ian Sanderson, the head organizer of the Healthcare sessions.  We talked about HSSC (Health Sciences of SC) and Bioinformedical Informatic Services.  I explained my interest in data mining, machine learning algorithms, and my past experience doing research at the Department of Bioinformatics, Biostatisticics and Epidemiology over at MUSC.  He seemed to be impressed, and introduced me to a man named Randall Alexander.


I then spoke to Randal Alexander, who is the Program Manager at MUSC in Biomedical Informatics Services.  I mentioned that I was considering grad school in the future, and he asked me to send him an e-mail with my resume for a potential internship opportunity.


After lunch, I attended Walter Bender's presentation on Sugar Labs and was very impressed.  I have always been interested in his work, and it was really nice to hear him talk about his goals and ideas firsthand.  I really wanted to talk with him after the lecture about future educational methods (since progressive education is one of my interests), but he was swarmed with people, and I thought it best to try him another time.


The next session I went to was on Education by Corey Donohoe.  I found what he had to say about higher education and open source interesting.  At this point, I remember feeling appreciative that we have an open source program in our cs path at CofC.


After that I went to the Healthcare lecture by Dr. Dan Russler.  To be honest, I wasn't too interested in this lecture, and zoned out hardcore.


I ended up leaving a little early with Carlynn and Alex.  To my dismay, upon returning to Charleston, I found out that my name had been called at the raffle to win a book on iPad Programming.  I was disappointed because not only do I never win ANYTHING, but also I've been looking to get into mobile app development. qq.


Overall, POSSCON was a great experience, and I'm glad that we were 'forced' to attend.

Pushing my Bug

As I stated in my last post, I was able to make the changes to the source code to correct my bug, and all that remained was to commit my change.  Last week during our team meeting I finished the process by pushing my branch of the code using git.  Now I just have to wait for feedback.

Planning for POSSCON and Sqwashing Another Bug

During our group meeting yesterday, I tackled a small bug (0011257) found in VTK/Utilities/octree/octree_curser.cxx.  The bug itself was very simple; One of the conditional statements "if ( axis < 0 || axis >= (1<<d_) )" had to be changed to "if ( axis < 0 || axis >= d_) )".  The way it was before, if the class was already loaded elsewhere, then it would cause an error.

I made the change to the file in my branch of the code, and then went through the steps to commit my code.  I did run into a small problem of not remembering my keyring password, so I did not complete the git commit, but I should be able to get that submitted soon.

As far as POSSCON planning goes, I read through the list of speakers that will be there.  There are a few individuals that I'd enjoy having a conversation with.  Below are the individuals that are most interesting imo:

• Dr. Jihad S. Obeid - CoEE Endowed Chair in Biomedical Informatics at the MUSC
• Dr. Dan Russler - VP Clinical Informatics, Oracle Health Sciences Strategy
• Walter Bender - Founder & Exec. Dir. - Sugar Labs, Co-founder One Laptop per Child
• Sebastian Dziallas - Engineering Manager, Sugar on a Stick (SoaS)
• David Nalley - Community Manager, CloudStack
• Mel Chua - Hacker, Red Hat Community Leadership Team

Spring Break

Over Spring Break, I tried to think as little about school work as possible.  That being said, I did make sure to read the daily VTK digest via the mailing list to keep up to date with the current VTK news.

Last night, I started to play with the code a bit.  There are a few bugs from the timeline that I think I could work on personally.  Next time the group meets, we should be able to get another bug finished and submitted.  I'm hoping that I will be able to use my branch of the project to commit the changes.

Creating a Timeline and Getting into Git

Our group met on Sunday evening to create a timeline for us to adhere to for the remainder of the semester.  This involved finalising our selection of bugs, deciding how much time to allocate to each bug based on severity and complexity, and roughly choosing an order in which to tackle them.

Out of the bugs we chose, one of them seems difficult, and will be worked on steadily for the rest of the semester.  For the remaining bugs, we are anticipating being able to squash and submit one bug per week.

In addition to creating a timeline, I also created my own branch of the project on the project's version tracker site.  Up until now, my project was built using the distributed source make files.  For us to submit our first bug, we were using Glen's machine, because he had already  set up Git.

To do this, I first had to set up an account on the project's version manager site.  Then I installed Git on my machine and linked it to my account on the project's site.  Finally, I create my own branch, which I named "bugSquashing".  Now, I can work with my own copy of the project, and commit my version after changes have been made.

Patch/diff Exercises

TOS Exercises:  7.2.2, 7.8, 7.9

7.2.2 - Testing the 'diff' command

When using the '-u' flag for the diff command, the output is changed to be more robust.  The entire contents of the file are shown as well as the lines that were removed and added.  Without the '-u' command, only the modified lines are displayed.

$ diff -u hello.c.punct hello.c

--- hello.c.punct       2011-02-24 11:45:00.000000000 -0500

+++ hello.c     2011-02-24 11:44:19.000000000 -0500

@@ -5,6 +5,6 @@

 #include <stdio.h>

 int main() {

-   printf("Hello, World!\n");

+   printf("Hello, World.\n");

    return 0;

 }

$ diff hello.c.punct hello.c

8c8

<    printf("Hello, World!\n");

---

>    printf("Hello, World.\n");

7.8 - Creating a patch file

First, I created a file called 'foo' with the contents 'bar' using vi editor.

To make the patch file, I entered the command:

$ diff -u /dev/null foo > foo-1.0.patch

Next I deleted the file 'foo' in order to test the patch.

$ rm foo

To apply the patch, I typed the following command:

$ patch < foo-1.0.patch

Then I checked the contents of the file:

$ cat foo

bar

Success!  A patch file was created, and applied successfully.

7.9 - Patch echo

I followed the 7.9 Exercise steps (since they are explicitly listed out, it would be redundant for me to explain the process).

Everything worked as it should.  I now know how to create patches!  Cool!

Bug Squashed

We had a very productive group meeting this morning.  Up until now, we had come up with several methods of squashing the bug, but were having minor problems.

After some back and forth on the bug page's message board, we received some helpful advice from a developer named David Doria.  He gave us a link to the vtkSTLWriter Class documentation.  Fixing the bug ended up being incredibly simple.  The necessary steps were:

1. Add a conditional statement
2. Add a cout with the warning text
3. Modify the .h file to include a function call in the source code

As far as submitting the code, we all found various wiki posts about submitting, but it wasn't until Glen found a detailed step by step process that we were able to get anywhere with submission.  The commit process is basically a sequence of git and ssh commands (this process has been posted on our wiki).

Unfortunately, we were halted in the commit process due to lack of authorization.  An e-mail was sent out to the developer's mailing list, and hopefully we will be authorized to submit the code soon.

Alumni Symposium

Last Tuesday was the Alumni Symposium.  It was really nice to hear the different viewpoints of individuals who are now successfully pursuing Graduate school, industry, or starting their own business.  Particularly, I was interested in the advice that they all had to give.

The overall advice was to be proactive in keeping up with new technologies and  technological breakthroughs.  It was also advised to get involved in an OpenSource project, and learn how to code for mobile devices.  Fortunately, our Software Engineering course is providing the experience of participating in an OpenSource project.

I have always wanted to learn how to program for the Android OS.  Their advice has reinforced my interest in writing a mobile device app.  In my spare time, I will try to be more active in pursuing this goal.

Squashing a Bug

On Tuesday after class we decided to scan the VTK BugTracker again to select a different bug to work on.  After looking at all of the bugs (yes we looked at every open bug) we decided to work on "0010854: vtkSTLWriter should warn when input is not all written".


Basically, vtkSTLWriter only writes up to 3 points for each polygon, however, there is no limit to the number of points that can be input. This is how it is meant to function. The problem is that there is no alert to the user when not all of the input is being used. So, whenever the input exceeds 3 points, the user should be warned that the output does not reflect the input.

We then decided on a strategy for tackling the bug.

1. Locate the vtkSTLWriter code.
2. Incrementally count the number of points passed to the method in the points list.
3. Implement a conditional statement to check the number of points (whether or not it exceeds 3).
4. If True, display warning message via standard output to the user informing them that only the first 3 points were being used.

We also located the segment of code that handles vtkSTLWriter.  The fix should not be too difficult, and hopefully we will be able to have our submitted code approved by the revision committee.

Overall, this was a very productive meeting.

Bug Tracker Exercises

TOS Exercises: 6.4, 6.5, 6.6, 6.7


6.4
The oldest bug on the VTK Mantis BugTracker is dated: 2003-08-13 16:09.  The summary of the bug is "0000142: Application Error on Render after changing vtkImageActor DisplayExtent."  When the xMin was changed while viewing a 2048x2048x1 image, the image was being incorrectly wrapped in the viewer.  This bug was never reported to have been fixed, most likely because it is a minute problem, or it no longer exists with newer versions of VTK.  


Theoretically, if you decrease the xMin value of an image that is loaded with a pixel dimension, then there are a few ways to handle the area that is no longer needed:
1) You could re-render the image using a canvas with smaller dimensions.
2) Display whitespace in the area that is no longer being used because of the smaller image.
3) Wrap the image in the area that was initially defined, but no longer used.


The fact that the image is wrapping isn't necessarily a bug, but rather a preference of handling the modification.  Personally, I'd have the image and canvas re-rendered to fit the smaller pixel dimensions.


Maybe this bug wasn't officially worked on and fixed because newer versions of VTK have implemented different methods of handling image renders.


6.5
I had already created an account on the Mantis BugTracker.  This process involved filling out a basic info form submission and email verification response.  My username is perry.spy.


6.6
This is a work in progress.  Since we changed project focus, I have been having problems getting VTK built.  Although I have been making progress on a daily basis, errors are still being generated in the compilation stage of VTK installation.  Obtaining missing dependencies is the smallest of problems that I've had.  Currently, I'm running into issues where I've had to modify the file structure, create links between directories, and change CMake settings.  Hopefully I'll have VTK built soon...


As far as reproducing a bug, a vast majority of the bugs found on the VTK Mantis BugTracker are exceedingly specific, which makes reproducing them on my machine rather difficult.  For example, many describe errors involving specific hardware configuration, system configuration, or specific platforms.  All of which I would be unable to reproduce.


Furthermore, I think that the majority of the BUG documentation is good, based on the examples read in TOS 6.6.  By this, I mean that the bug summaries are good, platform version, system information, configuration, and steps to reproduce are all (for the most part) documented in each bug.


6.7
Triage, or prioritization based on severity of condition, is an excellent and necessary process with OpenSource projects due to the vast number of bugs, and few number of developers working on the issues.  All bugs should be reported, but not all bugs should be given equal time and effort in terms of bug fixing.  The Mantis BugTracker system that ITK and VTK use includes a triage system.  All bugs contain one of the following severity values: feature, trivial, text, tweak, minor, major, crash, and block.  Mantis BugTracker also gives you the option of sorting based on an assortment of bug attributes.  Clearly, sorting by severity is important for dedicated developers.


5 "major" bugs for VTK are:
*0011817: vtkRenderingPythonTkWidgets.dll cannot be found when trying to create a vtkTkRenderWidgetInteractor using vtkpython.exe
*0011810: VTK 5.6.1 fails to build against Tcl 8.6.1.1 due to errorline being declared private in the Tcl_Interp structure
*0011771: SetOrientation doesn't work for the vtkTextProperty of vtkAxis
*0011790: vtkBoxWidget2 does not respect interaction filters.
*0011739: Medical Image Properties from vtkMedicalImageReader2 always return null when loading a DICOM file


These bugs are of great severity because they are generally cross-platform, and have to do with modular component interaction errors, or necessary functionality.

Freeciv

The task of building Freeciv was rather enjoyable compared to the other projects that I've tried to build in the past.  Maybe it's just that I've become more comfortable getting dependencies, or perhaps it was just taken more lightly since this was only an exercise.

Either way, the only real problems I ran into was having to get dependency packages, and that is more of an exhaustive process than a troubling one.  A few of them I downloaded manually by using "sudo apt-get install", but I also utilised the package manager.  There didn't seem to be any errors in Freeciv itself, or any added complexities of a unique install process that some I've encountered while building other projects in the past.

As far as ITK, I've gotten itk core built (the hardest part of that was figuring out how to use CMake).  Now I just need to build VTK, the visual application project that runs with ITK.

Downloading and Building and Installing! Oh my!

The first step was to download the most current ITK tar.gz from their site as well as installing CMake.  CMake is a cross-platform, open-source build system.  ITK uses CMake to control the software compilation process so that updates can be compiled more independently.  CMake can be downloaded as pre-compiled binaries, and therefore needs no installation itself.

First, make a directory to contain the ITK content:
$ sudo mkdir /usr/local/itk

Navigate into the itk directory:

$ cd /usr/local/itk

Extract the itk files: and delete the tar.gz:

$ sudo tar xvzf InsightToolkit-3.14.0.tar.gz

Delete the tar.gz, since it is no longer necessary:

$ sudo rm -rf InsightToolkit-3.14.0.tar.gz

Next, create a bin directory:

$ sudo mkdir /usr/local/itk/InsightToolkit-3.14.0/bin

Navigate into the bin directory: 

$ cd /usr/local/itk/InsightToolkit-3.14.0/bin

Run CMake to compile: 

$ sudo ccmake -DITK_USE_REVIEW=ON ..

This will open the CMake GUI.

Press 'c' to compile.

Wait for the compile to finish.

Press 'g' to generate the make files.

Now install:
$ sudo make -j4

$ sudo make install

Tada, ITK is now installed! 

Subversion

Subversion is a simple and powerful version management tool.  Fortunately, I have become quite comfortable using the svn commands from my summer internship at MUSC's BioInformatics department and also working on Dr. Manaris' Music Armonique Project.

The first step was to checkout 462playground/ from the stono.  This was done by entering the command:

$ svn checkout https://cirdles.cs.cofc.edu/repos/462playground/

Next, I created a new directory with the command:

$ svn mkdir perry

Then I created a test.txt file containing some text using vi editor, and added it to my directory with the command:

$ svn add test.txt

To commit my changes, I issued the command:

$ svn commit

Out of curiosity, I updated my checkout to see if any of our classmates had added anything new with the command:

$ svn update

Project Report and Ideas for Contribution

As far as the project report, the ITK site contains detailed descriptions of the project, it's functionality, and history of development, as well as a list of core members.  Writing up the report is as simple as annotating these sections of the website.

After signing up for the ITK development mailing list, I sent out an email to the team introducing myself.  Additionally, I provided background information on the intentions of our Software Engineering Practicum class, and asked for any feedback on ideas for contribution.  Within the day, I had heard back from 3 separate members welcoming us to the community and directing us to their bug tracker and ideas wiki.

The welcoming responses produced a sense of acceptance that I had not experienced in the past working on OpenSource projects.  Although project ITK is still somewhat intimidating of a project, I am now even more glad that our team has chosen this project.

Along with being greeted by these 3 developers, several ideas for contribution were also provided.  The ideas included tackling bugs from the bug tracker, working through some small problems found on their ideas wiki, as well as a larger and more indepth mentored focus idea.  It was suggested that we start off by working through some bugs on the bug tracker so that we can become aquainted with the submission process, as well as allow the community to assess our capabilities.  Several problems on the ideas wiki, specifically the "wish list" and "small problems" section also sound promising for potential focuses.  As far as the specific mentored project, it is great to have someone already volunteering to mentor us, but the application seems to be a lot more intense, and it would behove us to start with smaller tasks first, in my opinion.  Regardless, it is nice to have somewhat of a sense of direction in the project.

The Cathedral and the Bazaar, Mailing Lists, and IRC

In The Cathedral and the Bazaar, Eric Raymond discusses his approach to initiating and developing an OpenSource project.  His strategy and process was based around the success of the Linux OS.  The paper is a recount on the step by step thought process of development.  Throughout the paper, he conveys his strategies through 19 'lessons' that developers should ponder.


Towards the end of the paper, he contrasts his experiences with the ClosedSource program manager's functions.  He then goes on to argue the restrictiveness of the ClosedSource process by showing how none of the functions are applicable to OpenSource methodology.


The key concepts that I've taken away from this paper are that designers should follow their hearts and design to achieve personal goals.  Also, as a designer, you will know when an approach is correct because it will be simple and provide a cohesive set of functionalities true to the identity of the project entity.


After reading the paper, I'm further convinced of the effectiveness and inherent beauty in OpenSource development.


In addition to readin "The Cathedral and the Bazaar", I registered for ITK's mailing list, and spent a good deal of time fully examining their website.  I also started to read the ITK Software Development Handbook, which covers everything about development for the toolkit (includes architecture, class and function documentation, etc.).


On a side note, I emailed the ITK development team introducing myself, our team's intentions, and asking for any initial direction.


As far as an IRC channel, I am familiar with mIRC, but I don't believe that the ITK development uses an IRC.  In the email to the developers, I asked if they used any sort of real-time communication tool.  Hopefully I will get a response...

Picking Projects

I was unable to join the rest of my group for Thursday's in class meeting, so I did some project research on my own and emailed them a list of projects that I found interesting as my contribution.

After reading the project descriptions, the three that I initially found the most interesting were STEM, GeoChat, and Helios.  However, upon further inspection, I realised that GeoChat had a broken link, and the other two were poorly documented and didn't have clear methods of contribution.

The four that our team eventually decided on were ITK, Plone, Tor, and VuFind.  After researching all of them further, I have really become interested in ITK.  Not only is the topic fascinating, but the documentation is good, and they seem to have well defined methods of contribution.  Plone and VuFind were also interesting, but ITK is the winner in my mind.

We plan on meeting again before class, and hopefully we will all be able to agree on a project that we all like.

Blog, Wiki, and POSSCON

In class, we formed into teams for the semester-long OpenSource project.  My teammates include myself, Andrew Bissada, Glenn Faken, and Matt Lyons.  We also established group roles and named the group "Work Without Pay."

After class, I created a blog space using Blogger called "Perry's 462 Blog", registered on the student Wiki, and created a link from there to my blog.  I also registered for POSSCON using "student" as the discount code.  I wasn't sure which day to attend, so I marked them all, and will decide when to go once my schedule is more finalized.

In addition, I read chapters 1 and 2 of "Teaching Open Source".  These chapters contained mostly background information on FOSS and OpenSource projects in general.  I found the Contributor Mountain pyramid model particularly interesting (found in chapter 2).  In this hierarchical model, we all start as users, and progress to seekers, collaborators, and then contributors.  Climbing the ranks take place as one becomes more involved in a project.

Also, my teammates and I decided to get a head start on choosing a project, so I read through the summaries of each project.