Category Archives: Wiki

Catching Up on GIT

Howdy all,

Luckily Jon and I have been working internships all summer using some sort of variation of a Version Control System.  I guess I didn’t learn as much as I thought in 401 for GIT as I really needed.  My git-foo has improved significantly (Jon’s is still way above mine, though. )  Right now I’m working on my james-dev branch (at least the one I push to) and usually branch when I’m trying something new.  I’m really digging the issue tracker but, I think one day this week I am going to take some time out, probably with Jon, and really get our Wiki in gear.

In other news, old news that I never mentioned, Joe was MIA for a while and I finally got in contact with him and he said he was too busy and couldn’t commit I emailed Karl about it but I never got a response, I’m sure he’s just enjoying summer.

From the blog jamescelona » WSU CS by jamescelona and used with permission of the author. All other rights reserved by the author.

Organizing our GitHub repository

Our Android project will have an online repository hosted at GitHub. I’ve never used GitHub, though at work I use a local install of the similar Gitorious service. So far, we don’t have anything in the repo besides a GPL notice. The repository does have an integrated wiki that I have put some work into already. James and I discussed how to organize the repo and we decided we wanted to follow a professional approach that an actual project team working on commercial software might follow. Here is an excellent description of the model we will be using.

Basically, there will be four permanent branches. The first two branches, jon-dev and james-dev, are personal development branches that will hold snapshots of the project as we are working on it. We will keep our individual work separate in these branches so nothing one person does can affect the other. Here we also have the freedom to absolutely break the app while not affecting the snapshots in the next two branches. The code in these branches cannot be guaranteed to  build into a perfect working app, but that is to be expected because this is the entry point for brand new contributions.

The third branch, develop, is where James and I will merge our work from our individual branches after we have gotten our code working the way we want. Snapshots in the develop branch should build into a relatively stable app, similar to nightly builds in a major open source project, though bugs may still be present.

The fourth and final permanent branch, master, is reserved for major releases of the app. Once the code in the develop branch has enough features implemented, and has been tested thoroughly, it can be merged into the master branch and tagged as a milestone build. Apps build from code in the master branch should be considered stable and without major bugs.

We can also create temporary hotfix branches as we need to. For example, if a bug is discovered in the master branch, we can create a branch to fix the bug, merge it back into master after the fix has been tested, and then delete the temporary branch.

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

Feedback to the Euca2ools User Guide

In an earlier post, I said that I felt we had succeeded in making a clear and understandable user guide for Euca2ools. While I still feel that this is the case, we got some useful criticism of the guide from the last group to present on Wednesday. This group was tasked with trying to use Euca2ools and Eutester by only following the guides on our wiki, and then to report their findings and suggestions. They told us that while the guide overall was well-made, there were two areas that were difficult to follow.

The first issue was finding the user credentials when setting up Euca2ools. I admit to having trouble with this as well at first, but it did not even cross my mind to put instructions into the guide on how to find your credentials. Oh well, that is why having other people critique your work is good! I edited the wiki to fix this problem.

The second issue was about getting a working SSH connection. This is the biggest weakness of the guide. Getting SSH to work consistently never happened for us. We have several theories on why it failed so often. We suspect  as dynamic IPs could be the culprit. I do not have any solutions currently better than what is already posted in the guide, so it will stay as it is for now. Perhaps a future class will be able to fix up that part of the guide for us.

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

Evaluation of the Euca2ools User Guide

Most of my work this semester has been experimenting with Euca2ools and modifying our User Guide to reflect my findings. My primary goal in collaborating on this User Guide was to make it easy to follow, especially for a Linux novice such as myself. Ultimately, I think we achieved our goal. My group partners are definitely the experts and filled the guide with very useful information on how to perform the various tasks. I took their knowledge and formatted it, expanded on it, and tried to explain as best I could what each command was doing. A lot of trial and error went into this, as a lot of the time I wasn’t exactly sure what I was doing. A positive side-effect: fumbling through Euca2ools and revising this guide over the semester did help me a lot with my knowledge of Linux.

I wanted someone who was completely new to Euca2ools to be able to successfully do something productive by only following our guide. I think we came pretty close. Now that the semester is at an end, the guide is as finished as it will be until perhaps a future CS class takes over on the same project. It definitely is not 100% done. Eucalyptus is a huge project and Euca2ools is a major part of it. There is always more that we could do in writing the user guide, but I am happy with the progress we made.

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

Working with Euca2ools

The past two weeks I have been working on documenting Euca2ools with Dhmitri and Chris. Euca2ools is a collection of Linux command-line tools for interacting with a Eucalyptus cloud. There is documentation on the Eucalyptus website on how to get Euca2ools installed and working but it can be a confusing process, especially if you aren’t extremely familiar with the Linux command line, like I am. Dhmitri did a great job of consolidating all of the steps required and posting them on our wiki. He also added a few steps of his own that may not be apparent to a Linux novice. I followed his steps and was able to get a working Euca2ools installation after a fair amount of trial and error.

Based on my experiences, I expanded on Dhmitri’s instructions and tried to add more explanation of what you are actually doing with Euca2ools and why. I also added some nice color formatting to try and spice up the page and make it easier to follow. Check it out here: http://cstest.worcester.edu/wiki/pmwiki.php?n=Main.Euca2ools

As of right now the page is not finished– for some reason I am blocked from making further edits to the page! I wonder if it is because I made too many edits in a short time and the page is locked. Hopefully this gets resolved soon and I can make the remaining planned changes to the page.

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.

Week 2: IRC and Wikis

Most of our class during week 2 was spent on activities focused on teaching us how to use IRC and wikis–two important tools of the open source world. We started by installing IRC clients on our laptops and meeting up in the #teachingopensource channel on the Freenode server. I haven’t used IRC in over 10 years, and back then, I used mIRC. Since it had been so long, I figured a quick Google search was warranted to see what IRC clients were popular. The general Internet consensus was that XChat was among the best, but unfortunately it is shareware for Windows with only a 30 day free trial. As I was in a rush to get set up and connected, I stopped researching IRC clients at that point and installed KVIRC, a free client that was recommended by a classmate.

[Digression: KVIrc I found to be poorly laid out and had a terrible color scheme–yellow text on a white background for links… Really?? I stuck with KVIrc through the remainder of the class, but afterwards I decided to look for something better. I ended up finding XChat 2, a freeware version of XChat on Windows (because XChat, while being shareware, is still open source). So now I am using XChat 2 on Windows and XChat on my Linux VM and I am happy with both.]

After everyone had joined #teachingopensource, we learned some essential IRC commands, such as /nick and /join, as well as how to message someone directly. We also learned how to register our IRC nicks (I am registered as JonH_WSU in Freenode). Professor Wurst then explained that we would be using IRC to partner up and edit each others wiki profile pages on the Teaching Open Source wiki. There was only one rule: no talking. All communication has to be done through IRC only!

The channel soon became a whirlwind of activity as everyone started chatting at once. Before I learned how to send a message to someone directly, it was hard to keep up with the rapidly scrolling channel and pick out what was being said to me by my partner. However, learning that trick made it much easier to chat with one person out of the entire channel. As a side-note, it was very amusing to be among a classroom of 25 students, completely silent except for constant frantic typing. And every so often, a burst of laughter would erupt out, then back to silence. It was surreal at times.

Editing my partner’s wiki was easy. I had learned a great deal about wiki editing and its markup language from taking Robotics last semester, where we had to maintain individual course wiki pages. Using IRC chat, Facebook, and some general knowledge of my partner James, I had his profile wiki page up and running in no time. He did a pretty good job on my page, too.

From the blog Code Your Enthusiasm » WSU CS by Jon and used with permission of the author. All other rights reserved by the author.