Monday, May 25, 2009

GSoC: Hackystat, May 18-25

Most of this week's toil focused on getting Hackystat up and running for reals on my laptop. I was having a significant amount of difficulty, because something utterly bizarre is going on with my environment variables. I will describe the problem briefly here, as while it no longer a problem for setting up Hackystat, I have the feeling it will be a problem again.

I wanted the environment variables to be system-wide, as opposed to just for my user profile, so I defined them in /etc/environment.

The command "source /etc/environment" should have applied the changes in that file to the system, and indeed, calling "echo $" before sourcing from /etc/environment would print a blank line, while after sourcing it would print the appropriate value from /etc/environment.

However, the ant build just refused to recognize the new variables. The ones I had defined previously, JUNIT_HOME and so forth, worked just fine. The new ones, CHECKSTYLE_HOME and so on, where the ones that ant refused to believe existed.

Restarting is what fixed this the last time: however, it did not solve the problem this time.

Finally, I attempted to run the ant stuff from a root terminal. This time, it broke on JUNIT_HOME... Apparently the user terminal had access to the JUNIT_HOME variable, but the root didn't?!?! This confuses me mightily. The variables are defined in /etc/environment. That is a root file. WTF?

So I never got that working properly. Thankfully, Philip came out with the Ivy integration, which is like a gift from God.

Ivy Integration

The screencast was tremendously useful. I only ran into one problem, which was that I couldn't run it from a user terminal in the folder where I had placed the sensor example. (I had put all of the hackystat stuff in /opt/, which requires root access to alter. But that was no big deal. Sudo make me a sandwich!)

However, there are only a couple of things that it might be useful to clarify.

It took me a looong time to figure out that the Ivy thing was something you'd have to repeat with each project. I asked Austen some questions about it, and he was most gracious, but I felt that there was a crucial insight that I was missing. I did not feel that I understood, at all, how the sensor example related to a hackystat install. I might have understood better if it were called a "Project Example" as opposed to a sensor example. I thought that the primary purposes of it were to
1. ensure that the sensors were installed correctly
2. familiarize the user with the data that was being sent.

What I didn't understand at the time is that it is also an example of how to set up a project. So, every project has to have those xml build files, similar to the ones in the sensor example, and each project will have its own copies of the .jar files for the QA tools. Initially I thought this was very wasteful (something that Philip does touch on in the screencast, though at the time I didn't understand why). However, on further consideration, it seems like a really good way to do it, as then you can really easily use different versions of a tool for a project, without having to worry about it upsetting all your other projects.

So, as I understand it, when compiling a project to send data to hackystat for the first time, you have to go through all of these different ant build targets. One could probably write a script to tie them all together. It's a lot of time overhead for the first compile, but it works! Which is better than I can say for my efforts with the original set up method.

Ivy Integration Conclusions:

1. Ivy rocks. For realz, yo. Having tried the old installation way and failed spectacularly, I can say that the Ivy integration is easily a thousand times less painful and frustrating. I see it opening up an entire new userbase for Hackystat.

2. The exact purpose of the sensor example could use some clarification. It's possible that I missed some crucial insight in the documentation, but if I did, then future users are sure to do so as well. Maybe a more step-by-step guide to setting up a new project would be useful. I would probably even volunteer to write that.

In other news:

I'm running approximately a week behind schedule (although I feel significantly less panicky now that Hackystat is at least working.) Today I will finish watching the developer screencasts. I'm not exactly sure where I will go from there, as I suspect the screencasts will open new avenues of information to pursue.

I am hoping to get a design up this week. I'm not so much worried about the data mining part of the project as about the information retrieval and storage.

Also, why can't I cue screencasts to a particular point? Is that intentional, or is it a byproduct of my OS or browser or something?

Total hours for May 18-25: 15


austen.ito said...

Hrm. I can cue the screencasts. Maybe it's because your on linux? ;)

Anonymous said...

Hi! I use debian (a distro very similar to your ubuntu).
I downloaded the screen casts and used "gxine" to watch them, allowed to cue them to any particular point I desire.

about the environment variables maybe your problems were due to the fact that they're read by the system at logging time, and if you define them in a shell instance, they have scope only for that particular instance. Then opening a new instance or logging as root with sudo (as you wrote), causes them to not being recognized. however it's sufficient to disconnect (ctrl+alt+backspace) instead of restart everything.

hope this can help...maybe you could help me compiling Hackystat, indeed: I'm encountering some issues...ehehehehe XD

it's a pleasure to meet you