Author Archives: Jon

The trickiness of using Git in an Eclipse project workspace

I know there is a Git plugin for Eclipse, but I prefer to do things the old school way with terminal commands. So when it came time to make sure my Eclipse project folder was being tracked by our remote repository on Github, I thought I could just clone our repository and then create a new Eclipse project in that same directory. Except Eclipse does not let you create a new project in a directory that already exists. And I wasn’t going to try to clone into a directory after it had already been populated by local Eclipse files; who knows what kind of problems that would have created.

If there is an elegant solution to this problem, I didn’t find it. I changed the name of the cloned directory, then created my Eclipse project using the original directory name now that it was unused and available. Then I moved all the Git files into the new directory, and deleted the now-empty one with the changed name. And everything works great.

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

Odd-sounding warning in Git is not a big deal

As I am preparing to make my first commits to our project, and I get bombarded with several of these warnings, one for every changed file:

warning: LF will be replaced by CRLF in res/layout/activity_main.xml.
The file will have its original line endings in your working directory.

I have no idea what this means. Luckily, Google had my answer here: LF stands for line feed, and is what Linux systems use to delineate newlines in files. CRLF stands for carriage return line feed, which is what Windows uses for newlines. That makes sense as I am working in Windows. It looks the impact of this change is pretty insignificant and the warnings can be disabled by entering the following in the Git shell:

git config core.autocrlf true

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

Using Git in Windows

With our GitHub repository ready, and now that my Android development environment has been setup, it was time to install Git so I can actually start working. Git is a Linux tool and all my previous Git experience has only been inside that environment. But luckily Git has been ported to Windows, so I can use Git on my Windows machine without having to run it inside a VM. There are several options for running Git in Windows, and first I chose msysgit, the official Git for Windows project. I then abandoned that in favor of the GitHub application, which promised seamless connection to the GitHub website, including automatic maintenance of SSH keys.

The GitHub app has a nice GUI interface, and seems to be very easy to use. But I honestly haven’t used it much–the app also installs a Git shell, which I vastly prefer to the GUI. The Git shell emulates a Linux terminal, inside a Windows command prompt. Several of Linux commands are emulated inside the shell, such as cp, mv, rm, ls, cd, and others. Tab completion is also implemented which is wonderful. The emulated commands are not as powerful as their real versions (for example, typing “ls” works, but my preferred “ls -lh” doesn’t), but it’s still great to have this option. You can even open text files for editing from within the command prompt– just type notepad instead of nano or gedit. Lastly, a hugely useful addition to this Windows implementation that isn’t even in the Linux original:  the prompt in the shell uses symbols to help you keep track of your added, modified, and removed files, and changes color depending on your commit status!

From the blog Code Your Enthusiasm » WSU CS by Jon 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.

Setting up the Android SDK & Eclipse

This summer I will be developing an Android app with James, who is also a senior CS major at Worcester State. Neither of us have ever done anything like this, so needless to say it will be an adventure. The first thing I had to do was to properly set up my development environment. Google has a guide here, but it wasn’t the smoothest process. There was a bit of trial and error along the way. I have a fairly modern computer running Windows 7 64-bit. Here’s my rundown of setting everything up:

Step one was to install the JDK, Java Development Kit. That was easy enough. Oracle’s website has lots of options, so it was important to choose the standard 32-bit JDK installer. Even though I have a 64-bit system, I chose 32-bit in order to maximize compatibility.

Step two was to install the Android SDK. Once that has been installed, running the SDK Manager lets you choose what Android platforms to download. For now, I only downloaded the latest version, 4.0.3/API15.

Next was to install Eclipse. Eclipse.org has a lot of options. I opted for Eclipse for Java Developers 32-bit (matching my 32-bit JDK), though I hear Eclipse Classic works too. There is no installer exe for Eclipse, only a zip file, which might confuse Windows users. You just need to extract the zip file into your JDK directory, and that’s it. In my case, Eclipse ended up in “C:\Program Files (x86)\Java\jdk1.7.0_04\eclipse”. Then you run eclipse.exe from that folder and off you go.

Inside Eclipse, the next step is to install the ADT plugin, which will integrate several Android tools into Eclipse. This is where things started getting a little hairy. According to the Google guide, Eclipse should be able to grab the tools from a repository located here: “https://dl-ssl.google.com/android/eclipse/”. Eclipse did that, then proceeded to tell me that the tools couldn’t be installed. After a lot of searching, I didn’t find a fix, but I learned the problem possibly has to do with the fact that I am using a newer version of Eclipse (Indigo) than when the guide was written (Helios). Thankfully, Google offers a manual download of the tools here, so I was finally able to get the ADT plugin up and running.

Now that the Android SDK and Eclipse were both configured, it was time to write a program! The Google guide has a very nice-looking series of tutorials, starting with a Hello World app. The first thing to do was to make an AVD (Android Virtual Device), an Android phone emulator. This went smoothly. So did creating the new project, and writing up the simple code. Now to run my very first Android program…

FAIL. In the console, in bright red, I see the message “PANIC: Could not open: C:\Users\Jon\.android/avd/my_avd.ini”. What is this?? Why can’t it find my emulator??? I check, and sure enough, there is no .android folder in my Jon directory. The .android folder is on the root of my D:\ drive, and the AVD is in there. So why is Eclipse looking in my user folder, and how can I fix it? After a lot of searching, I found my answers here. It turns out that this is an ADT bug, and to fix it, I had to make a symbolic link between the two locations. So, in a Windows command prompt, I ran:

mklink /J “C:\Users\Jon\.android” “D:\.android”

An .android folder showed up inside my user directory, identical to the one in D:\. It’s important to note that if I ever want to delete this link, I need to run rmdir rather than just delete the folder. Otherwise, Windows will delete both locations instead of just the symbolic link. I went back to Eclipse and tried running my program again, and it worked! I’ve never been so happy to see “Hello World” appear on my screen.

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.

Eucalyptus Presentations

On Wednesday, all of the groups presented on what they had accomplished during the semester. I did not realize how much work we actually got done as an entire class until I saw the presentations. There were 7 presentations in all:

  1. Eutester Issues
  2. Cloud Overview
  3. Eutester Documentation
  4. Infrastructure
  5. Leveraging Python for Eutester
  6. Using Euca200ls (my group)
  7. Installing Euca2ools and Eutester

The first group gave an overview of the open and closed issues on Github. The second group gave a very detailed overview of the ideas behind cloud computing and defined many general and Eucalyptus-specific terms. The third group described the process of attempting to document the Eutester code. Dave and Mike, the infrastructure group, had an entertaining discussion about how much frustration went into setting up a working Eucalyptus cloud. The fifth group went into depth about using Python with Eutester. My group described the main functions of Euca2ools and the process of creating a user-friendly guide on our wiki. We actually succeeded in demonstrating a working SSH connection to an instance created from an image that I uploaded to our Eucalyptus cloud, which I consider to be a big accomplishment! The final group critiqued the experience of attempting to get several modules up and running, specifically Euca2ools and Eutester, just by following the wiki guides that we had all created.

It was very interesting to see the other groups present, especially the groups involved with Eutester. Spending most of my time with Euca2ools, I did not look into Eutester very much at all. Seeing all of my classmates describe their experiences with it was great to see.

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.

Success!

Today is a big day in working with Euca2ools on our cloud. I have successfully uploaded an image, kernel, and ramdisk to the Matrix server and an instance is actually running off of my image. This has been a trial and error process that has taken weeks, and I am pretty satisfied. Here is the proof:

The instructions posted on our user guide by Dhimitri and Mindo were really helpful, but of course being a complete noob to Linux I was confused by some parts. The wiki will be changing slightly to reflect my new found understanding and hopefully the revisions will help anyone else trying out this process in the future.

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.