Zach Shepherd's WordPress Blog

Just another WordPress weblog

Tuesday, April 29, 2008

Updated Resume

I’ve updated my resume and, because of the personal information it contains, placed it behind a bit of “security”. It isn’t foolproof, just fool-resistant.

If anyone notices any typos (in the security or in the resume), let me know.

posted by Zach at 9:41 pm  

Wednesday, April 23, 2008

Semester Wrap-up: Things I Learned

I learned a lot this semester. I’ll list some examples below.

  • Android
    • A lot about Java
    • A lot about the Android language
    • A little about XML and DTDs
  • Docs
    • The DPL syntax
    • A little about automated backups
  • BenchVM
    • A lot about writing formal papers for conference submissions
    • A lot about KVM
    • A little about DTDs
  • As COSI Director
    • How to get people to take minutes
    • A little about LaTeX
  • As “Server Room Stuff” Maintainer
    • A lot about UPSs
    • A little about Screen
posted by Zach at 8:06 pm  

Wednesday, April 23, 2008

Semester Wrap-up: Projects

I worked on a variety of projects this semester. Information about each can be found elsewhere (and in other posts, of course).

posted by Zach at 8:01 pm  

Wednesday, April 23, 2008

Semester Wrap-up: Presentations

Earlier in the semester, Ryan and I held two presentations on MediaWiki. They can be found on the wiki.

posted by Zach at 7:58 pm  

Sunday, April 20, 2008

Virutalization Benchmarking

At the beginning of March, I had conversations with a few COSI members on possible research projects I could work on in my “free time”. What resulted from the conversations as a whole was the idea of a “Broad Spectrum Comparison of Virtualization Technologies” and the concept of “Broad Spectrum Virtualization Benchmarking”, a term latter shortened to “BSVB”

The goal was simple: Compare a variety of virtualization solutions using a variety of metrics across a diverse set of hardware and software configurations. The reason for wanting to preform BSVB was that many virtualization benchmarks are preformed on a limited set of configurations and the results assumed to be valid for all possible configurations, which is a rather unscientific approach (it completely lacks rigor). The main issue with my plan was that, in order to test just a few different configuration options for each category (hardware, domain0 operating system, domainU operating system, virtualization technology), the test set would have to be preformed on several hundred configurations, which is likely one of the reasons broad comparisons are currently uncommon*.

Because the number of tests was completely unreasonable to do by hand, the idea of a virtualization benchmarking suite was formed. One goal of the project became to make the suite modular enough that if anyone else had something they felt was important to test, they could add it without much difficulty. Another goal was that the tests be repeatable; that some exportable format exist to pass on the information necessary to re-run the tests. The benchmarking suite was named “Benchvm” in an effort to come up with an easy to type and remember name.

To achieve both goals, benchvm was designed to be completely modular. See the draft of The Woes of the Art of Virtualization Benchmarking for more information on the issues associated with virtualization benchmarking and the proposed solution: benchvm. Hopefully, once fully implemented, benchvm would be able to be used by anyone** doing virtualization benchmarking to provide a mechanism for the tests to be run in an identical way across a variety of systems with the added bonus of making the tests completely repeatable.

Currently, an effort to implement benchvm, as outlined in the paper, is underway. The goal is to have a working beta ready to preform tests comparing Xen and KVM with the goal of presenting benchvm and the preliminary set of results at XenSummit and KvmForum this year. The benchmarking side of things includes not only students and faculty at Clarkson, but a variety of other researchers (more information on this as plans become clearer).

* – By “uncommon”, I mean “unheard of”.
** – Of course, to be truly scientific, one comparison that would need to be preformed would be comparison two initial sets of tests, run with and without using benchvm, to ensure that benchvm itself has no impact on results.

posted by Zach at 8:06 pm  

Sunday, April 20, 2008

Virtualization Mailing List

Earlier this semester, Todd championed the creation of a virtualization mailing list for discussion of virtualization topics within, and outside of, Clarkson. Currently, there are members from a variety of virtualization backgrounds (Xen, Kvm, and VMware to name a few). For more information on the list (or for information on how to join the list), see the docs page on mailing lists.

posted by Zach at 8:05 pm  

Sunday, April 20, 2008

Android Status

Well, with Phase 1 of the Google Android Developer Challenge coming to a close last weekend, the team put in one last final push on our Digital Lifelines project and submitted it. According to the contest’s FAQ, we should hear back around May 5th.

While we haven’t made our apk (compiled Android program file) or source code publicly available, we do plan to release the program under GPL v3. If anyone is interested in getting a copy before the public release, contact any of the project members.

posted by Zach at 5:04 pm  

Sunday, April 20, 2008

Version Targeting

One hot topic in the web development world since I last posted was the version targeting in IE debate. People more knowledgeable than I have already spoken on the issue, and I’m really not quite sure what to think, so I’ll just provide some links.

Some links related to the issue:

posted by Zach at 2:42 pm  

Sunday, April 20, 2008

Accessible Charts

In the latest issue of A List Apart, Wilson Miner write about Accessible Data Visualization with Web Standards. Using XHTML and CSS, he manages to produce some very nice charts. They aren’t nearly as fancy as the Google Charts API or Open Flash Charts, but they are accessible and simple (from a markup standpoint as well as an implementation standpoint).

posted by Zach at 2:41 pm  

Sunday, April 20, 2008

Google’s way isn’t always the best way.

On the whole, I love google products, but they certainly don’t get all the details right all the time.

A little while ago A List Apart featured the article Sign Up Forms Must Die by Luke Wroblewski. In it, he cited one of several things I disagree with Google’s approach to: signup forms. Instead of forcing a potential user to go through the trouble of signing up before they even know if the service is worth having, websites can allow the user to experience the product and then sign up for an account (Wroblewski calls this process “gradual engagement”).

Another long-standing issue I’ve had with Google is Gmail’s terrible support for mail consolidation. Yes, they allow you to “Add another email address”, a wonderful feature, but the implementation is terrible. It will show the “From:” header as the address you selected, but the “Sender:” header is populated with the gmail address you’re sending from (even if your “From” address is another gmail account, which there is absolutely no excuse for). It allows you to reply from the same address mail is sent to, but doesn’t support conditionals (for use with lists and domains and such; I want to reply to anything to *@lists.clarkson.edu from my Clarkson address). In addition, there is no way to sort your “From” addresses (and they aren’t even sorted in some undesirable way that can’t be changed; from what I can tell, they’re completely random).

posted by Zach at 2:39 pm  
Next Page »

Powered by WordPress