Uncategorized

I just wanted a hamburger

What was supposed to be a quick 10 minute trip to the nearby Carl’s Jr. for a hamburger ended up with blood, police and arrests.

I’m back home visiting my family for a few days, and my brothers and I decided to make a quick run to grab a couple hamburgers. It was about 1 AM, but we’ve done this before, hundreds of times, and never had a problem. It was pretty quiet out, and trouble is the last thing we expected.

We got our burgers and began to walk home. Across the street from the burger joint is an AM/PM. There’s an alley way right behind that that takes us to a small parking area off a street that connects to our street. It’s a nice quick shortcut, well lit, and safe enough. Usually.

As we were heading through the parking area, we heard footsteps behind us. I turned around and saw three guys, but they were a distance aways. I had a bad feeling, but thought I was being paranoid. As we continued to walk, they continued to keep their distance, until we walked onto the street in an unlit area.

One of the guys (they were all teens) pulled his shirt or jacket over his face and grabbed my food. He said, “Give me the food. Give me the food!” I held onto the bag and he pulled hard, breaking the bag in two. He took it and started to laugh. Without hesitation, my brother yelled at him to give it back, and threw his little Dixie cup of water at him. The guy turned around and started to punch him in the face.

There was blood everywhere.

This all happened so fast that I couldn’t react in time, but immediately after I saw another one of the guys start to go over to my brother as if he was about to join in the fight. I jumped between them and said, “Hey, it’s cool. Just take the food and go.” I was frightened that they would pull a knife or gun on my brother and wanted to just end it right then.

They turned around and started to leave. The guy who punched my brother said something like, “I sure was hungry!” and they laughed and continued down the street. We saw them turn onto this one fairly long street. I immediately called my parents, waking them up, as at this point I really wanted more people nearby in case those guys realized they could get our wallets instead of just our food.

I then called the police. They were here within two minutes, faster than my parents even. And not just a couple police. Two police cars sped past us, down the street those guys went (as I described to the operator on the phone), and then two police cars stopped where we were. A third came by later. And a fire truck. And an ambulance.

It turned out that they were expecting something big a block away and thought this might be it. So they sent in the cavalry. Fine by us. They took our statements, had us each identify the suspects (who they had nabbed almost immediately). I was able to positively identify one of them, though he wasn’t the attacker. My brother, however, was able to give a positive identification for the attacker. We were told he’d likely be in jail before the night is up, and maybe his accomplices as well.

So at least we got them off the street. My brother, though, is currently at the hospital getting stitches, and I’m feeling guilty as hell for talking them into coming with me for a burger. I just wanted a hamburger, and instead I got my brother a trip to the hospital, and some guys off the street. What a night.

Happy birthday Review Board!

One whole year…

While attending SuperHappyDevHouse, David and I realized that it was the one year anniversary of Review Board‘s public announcement. (This was the evening of May 17th. I’m just a few hours late in getting this post up.)

It’s been a pretty awesome year for Review Board. What begun as a small project intended for use in our team at VMware and in our personal open source projects turned into a large project with a great community of developers and users. It’s now being used by dozens of companies and projects (some of which have given us permission to list them publicly) and has had code contributions from over 35 users. To everyone who has contributed to the project, we’d like to give our thanks. Review Board wouldn’t be the tool it is today without your help.

I’d like to list some of the major things that have happened in the past year.

  • Review Board has been adopted by one or more teams at around 40 companies (including Yahoo! Search, VMware, and Tripwire).
  • Received contributions from over 35 users.
  • Added support for CVS, Subversion, Perforce, Git, Mercurial, and Bazaar.
  • Added support for useful features such as interdiffs, screenshot commenting, syntax highlighted diffs, customizable dashboard for keeping track of review requests, status reports, a full JSON API, and more.
  • Several presentations were given at various companies and conferences on Review Board by third parties.
  • One public presentation was given by us at LugRadio Live USA 2008 (view the presentation)
  • We’ve started hosting projects for this year’s Google Summer of Code on our Summer of Code server.

That’s just a small sampling. There have been many changes made to stabilize the codebase, improve usability, and generally make the product more awesome.

And of course there’s a number of things happening in the near future:

  • Monotone support.
  • A new, improved administration UI.
  • Extensions support, allowing Review Board to be extended in a variety of ways and integrated into other products.
  • A new set of command-line tools and a Python library for working with Review Board servers.
  • Support for P4V (for Windows Perforce users).

Database Migration and Parent Diffs

Today, a change went in that improves Review Board in two fundamental ways.

First, we now have a fast, powerful way of doing database migrations in-place, without dumping and loading the database. While this should make life easier for users and allow us to modify the database without fear of breaking people’s installs as often, it will also save administrators of large Review Board servers a lot of time. Before this change, the VMware database (of over 25,000 review requests) took at least 30 minutes to do a full migration. Now it shouldn’t take more than a minute.

Second, we’ve just landed the initial support for diffs based on parent diffs. If you’re a user of a distributed version control system (such as Git or Mercurial) you’ll appreciate this. Before, your change had to apply against revisions in the master repository, making it impossible to put up a review request for a change on a sub-branch of a branch when the parent branch didn’t exist on the server. Now, a diff of the parent branch can be uploaded along with your sub-branch’s diff.

Confused? Maybe an example will help. Say you’re working on a large restructuring change in your “code-restructure” branch in your local Git checkout. You have a topic branch off of your “code-restructure” branch with changes you want to put up for review. This used to be impossible without including the whole “code-restructure” branch’s changes in your diff as well, but now, you can put up a diff of the topic branch along with a diff of the “code-restructure” branch, and the topic branch’s diff will appear on Review Board, ready for review.

The backend code for this is now in Subversion. We’ll be adding support to the post-review tool shortly, making this accessible to anyone. Review Board will become fully usable for distributed version control systems.

Are you using Review Board?

Review Board is gaining popularity, and more companies are beginning to use it. If you work for a company or an open source project that’s using Review Board and can give us permission to list you on our Happy Users page, please let us know!

And here’s to an even better year for Review Board.

Free Review Board Hosting for Summer of Code

Google Summer of Code 2008 is on, and soon students will begin coding, which means mentors will be reviewing code. While the Review Board project is not a participating project in this year’s Summer of Code, we felt Review Board could help with the whole process, improving things for both the students and the mentors.

Starting today, and for the duration of this year’s Summer of Code, we at the Review Board project would like to supply up to 30 projects with free Review Board hosting at gsoc.review-board.org. We’ll handle maintenance of the server, support, and provide assistance to get students and mentors set up.

Doing code reviews with Review Board is simple and saves time over reviewing standard raw diffs, with features such as a powerful diff viewer with syntax highlighting and inline commenting, interdiffs, status reports, and support for a wide variety of revision control systems. We believe it can be as effective a tool for open source development as Bugzilla and Trac have become.

Th Summer of Code server is intended for Summer of Code-related changes only. While we’d love to provide hosting for projects in general, we have limited resources. However, should your project decide to set up its own Review Board server in the future, we’ll be able to assist in migrating your Review Board history to your new server.

If you’re interested in trying out Review Board for your Summer of Code project, you can find out how to apply on our Summer of Code Hosting page.

To learn more about Review Board and how it works, you can look at our project website or watch our presentation from this year’s LugRadio Live USA.

Review Board presentation at LugRadio Live 2008

This year’s LugRadio Live USA conference was a blast. There were some great talks, interesting booths, and fun swag.

The Review Board presentation went pretty well. I think in my next presentation I’ll demo more often instead of just at the end, but all in all people seemed to find it interesting. The presentation focused on what Review Board is, how it works, and how it could benefit open source. With luck, it will encourage projects to begin using a real code review system, making life easier for all involved.

For those that missed it, the slides and the presentation video are now available. Enjoy!

Django Development with Djblets: Unrooting your URLs

Typically, Django sites are designed with the assumption that they’ll have a domain or subdomain to themselves. Often times this is fine, but if you’re developing a web application designed for redistribution, sometimes you can’t make that assumption.

During development of Review Board, many of our users wanted the ability to install Review Board into a subdirectory of one of their domains, rather than a subdomain.

There’s a few rules that are important when making your site relocatable:

  • Always use MEDIA_URL when referring to your media directory, so that people can customize where they put their media files.
  • Don’t hard-code URLs in templates. Use the {% url %} tag or get_absolute_url() when possible.

These solve some of the issues, but doesn’t address relocating a Django site to a subdirectory.

Djblets fills in this gap by providing a special URL handler designed to act as a prefix for all your projects’ URLs. To make use of this, you need to modify your settings.py file as follows:

settings.py

TEMPLATE_CONTEXT_PROCESSORS = (
    ...
    'djblets.util.context_processors.siteRoot',
)

SITE_ROOT_URLCONF = 'yourproject.urls'
ROOT_URLCONF = 'djblets.util.rooturl'

SITE_ROOT = '/'

SITE_ROOT specifies where the site is located. By default, this should be “/”, but this can be changed to point to any path. For example, “/myproject/”. Note that it should always have a leading and a trailing slash.

The custom template context processor (djblets.util.context_processors.siteRoot) will make SITE_ROOT accessible to templates.

SITE_ROOT should be used in templates when you need to refer to URLs that aren’t designed to respect SITE_ROOT (such as User.get_absolute_url). Your own custom applications should always respect SITE_ROOT whenever providing a URL.

ROOT_URLCONF is typically what you would set to point to your project’s URL. However, in this case, you’ll be pointing it to djblets.util.rooturl. This in turn will forward all URLs to your project’s handler, defined in SITE_ROOT_URLCONF.

This is all you need to have a fully relocatable Django site!

To sum up:

  1. Add djblets.util.context_processors.siteRoot to your TEMPLATE_CONTEXT_PROCESSORS.
  2. Set SITE_ROOT_URLCONF to your project’s URL handler.
  3. Set ROOT_URLCONF to ‘djblets.util.rooturl’
  4. Prefix any URLs with SITE_ROOT in your templates, unless the URL would already take SITE_ROOT into account.

This is functionality that will hopefully make its way into Django at some point. For now, you have an easy way of unrooting your Django project.

Workstation 6.5 Beta 1 – Now with 100% more Unity!

I talked a little while ago about working outside the box with Unity. At that time I gave a sneak peak into what I’ve been working here at VMware the past few months. Well, now everyone can see.

We just announced VMware Workstation 6.5 beta 1, the first public beta for Workstation 6.5. Among many other awesome features is Unity, a feature we introduced in our Fusion product (for MacOS X) which allows you to run your applications from your virtual machine on your desktop without needing to be confined to a big box representing the VM’s monitor.

Unity is available in both our Linux and Windows releases of Workstation 6.5 beta 1, and there’s currently support for Windows guests (Windows 2000 and up). However, it’s a beta so you can expect some problems. To help people get started, here’s a rundown on what you can expect from Unity in beta 1.

Features Overview:

  • Shaped windows
  • Guest mouse cursors
  • Proper window types for most windows (Menu, Dialog, Tooltip, etc.)
  • Special effects with Compiz
  • Virtual desktops
  • Copy and paste between host and guest
  • Start menu integration
  • Window borders and badges

Seamless window integration

With the press of a button, the applications in your virtual machine will pop out and appear on your desktop, intermixed with all your native applications. These windows can stack in any order along with your native windows and will maximize, minimize, and close as you’d expect any normal window to. They’ll appear just like they would in the guest, aside from any borders or badges you have set to help identify the guest windows (more on that in a minute).

We do our best to set the window types on these windows to best reflect their type in the guest. This means that a tooltip from the guest will look and act like a tooltip in the host, as will a dialog, menu, etc. This is important for supporting the special effects provided by a window manager.

Special effects

If your window manager has any special effects set for the windows, they’ll apply to guest windows. For example, users of Compiz will be glad to know that their wobbly windows will work for such applications as Office 2008 or Minesweeper, and your guest menus will still burst into flames when they appear.

There are a few cases where the effect isn’t as strong as with native windows. Due to the way we receive window updates and events, the display of a window will often update before we receive open, close or minimize events. We plan to make this work better for some event types in the next beta, but for now, I recommend choosing special effects that modify a window in-place (fire, fade-in, etc.) instead of one that zooms a window to a location for opening/closing windows.

Wobbly Windows

Virtual desktops

Windows may not natively have virtual desktop support, but Linux does, so we felt it was important to make virtual desktops with Unity just work. You can place your guest applications across your virtual desktops. Maximize Office on one desktop, play a game of Solitaire on another, and reserve a third for your Internet Explorer debugging session.

Unity with Virtual Desktops

Copy and paste

Copy and paste is an important part of any user’s daily work. We currently have support for copying and pasting text between host and guest. You can’t yet copy and paste images or other data, though.

Start menu integration

Helper’s Head

A desktop environment isn’t useful without the ability to get to your programs. We provide a little tool called Unity Helper that runs automatically and provides start menu integration. Simply move your mouse to the top-left corner of your primary monitor and the menu will pop down, providing a start button for each of your VMs in Unity. Click the button and your start menu’s contents will appear.

The start button will match the color of the Unity badges and borders that are set to help you quickly identify your VM.

This functionality is pretty new so there are some kinks to work out. For example, if you don’t have a top panel or your top panel is larger than 24 pixels, you might notice the window in a wrong location. This is a bug that will be fixed in beta 2. We’re also hoping to add more options for the location of this window.

Applications Menu

Another useful tip is that you can use Unity Helper to launch applications in a guest via the panel or command line. Simply run:

 $ vmware-unity-helper --run /path/to/vm.vmx c:\path\to\program.exe arguments

This only works if your VM is currently powered on and in Unity or if the VM is not open anywhere. It’s not a supported feature at this point.

Borders and badges

In order to help identify a window belonging to a particular VM, we have color-coded badges and borders on the Unity windows. The border goes around the window and fades from corner to corner, and the badge is a little VMware logo sitting on your titlebar. Both are purely decorative and optional. You can turn them on or off in VM Settings or change the color. The color will also match the start button.

Badges and Borders

Known bugs (and workarounds)

As with any beta, there are of course bugs that you may hit. Pay special attention to the first item on the list.

  • Start menu problems after a crash. If there’s a crash, sometimes the start menu integration won’t work the next session. The trick is to exit Workstation (leave the VM running in the background), delete /tmp/vmware-$USER/unity-helper-ipc-*, and bring Workstation back up.
  • Occasionally Unity may crash. This is a known bug when a guest window changes its type when we don’t expect it. If you hit this, don’t worry! Your VM is still running in the background. Just re-launch Workstation or Player and go back into Unity mode.
  • Graphics glitches. Sometimes you’ll notice the background appearing when you close or minimize a window. We hope to fix this up for the next beta.
  • Multiple monitors are not supported in beta 1.
  • Drag and drop is not supported in beta 1.
  • Due to a recent regression just before beta 1, there are graphical glitches for applications not on the current desktop.
  • Some applications behave badly. Photoshop and Flash (the creation program, not the plugin) (ab)use windows all over the place, and so you’ll see windows where you wouldn’t expect them. Sometimes they don’t even get proper updates, making the UI unusable. We’re looking into solutions for this.

There’s more, but those are the main ones I can think of that people may hit.

Give it a try and feel free to report bugs in the user forums.

Botching the Trivial

As a developer, I’m used to screwing things up. It comes with the job, and that’s why we have beta testers, QA, and code reviewers. You get used to it, and usually it ends up not being too big a deal.

What’s really embarrassing is when the screwup is literally staring you in the face and makes it into a major release. This was the case with the VMware Workstation and Player application icons in Workstation 6.0.

During development of Workstation 6.0, I felt the icon set needed a refresh. We try to fit in well with the GNOME desktop, and our icons just didn’t match. They weren’t bad, but they could have been better. I spent a lot of my free time creating a new set of icons for the application in the Tango style. This included application icons.

Our previous application icons were beveled and out of place in a Tango-themed desktop, so I replaced those as well. The result was really nice. After getting people to look at them, I committed them and wrote scripts to install all our fancy new icons with the product.

But something wasn’t quite right. I knew it but didn’t really think about it until after the release. There was something about the icons in the panel and menus. They looked fine on my development system toward the end of the Workstation 6 development cycle, but didn’t look right when I next installed a build on that system. I guess I shrugged it off as just being something screwy with my setup, but when I installed Workstation 6 on my laptop, the icons still looked wrong.

They were blurry. I made nice crisp icons! Where did these blurry ones come from? I figured it had to do with my panel size and that it scaled the 24×24 ones down to 22×22. That must be it, I thought.

It wasn’t until a couple of days ago when I finally decided to look into this thoroughly. What I saw made me so sad. The .desktop files for the applications contained:

Icon=/usr/share/icons/hicolor/48x48/apps/vmware-workstation.png

Yes. I never updated the old .desktop file generation code to use an icontheme name. It was still using the really old code querying the 48×48 icon we used to ship.

I suddenly realized why it used to look fine on my box. When I first tested these icons, I hand-modified my .desktop file to test the icons. It wasn’t until I installed a new build that I got the shipped .desktop file.

As you can imagine, I felt like an idiot. I decided to fix this quietly without making my idiocy too obvious to everyone else. (Don’t tell anyone, please. They think I’m smart.)

Just to give a sense, here’s a before and after shot.

Before
Broken WS6 icons

After
Fixed WS6 icons

Ah, much better. We have pretty icons again! Of course, had I fixed one single line of code and looked at a generated .desktop file once before release, that wouldn’t have happened.

But everyone makes at least one stupid mistake in a release, right?

Django Development with Djblets: Custom Tag Helpers

I’m planning to cover all of what Django can do, but for now, let’s start simple with something most Django developers spend way too much time creating: Custom tags.

Django’s nice enough to provide a @register.simple_tag decorator for creating very basic tags that don’t take a context but do take parameters. This is great, but what if you want more? Many Django applications use the same boilerplate time and time again to create their tags, but we make it much easier.

Introducing @basictag and @blocktag.

@basictag

Ever wanted to use Django’s @register.simple_tag but needed access to the context? I’ve found far too many cases where this would be useful, but Django doesn’t make this easy. Your tag code would end up looking like this:

class MyTagNode(template.Node):
    def __init__(self, arg1, arg2):
        self.arg1 = arg1
        self.arg2 = arg2

    def render(self, context):
        arg1 = Variable(self.arg1).resolve(context)
        arg2 = Variable(self.arg2).resolve(context)

        return context['user']

@register.tag
def mytag(parser, token):
    bits = token.split_contents()
    return MyTagNode(bits[1], bits[2])

Do this a few times and it’s bound to drive you nuts. How about this instead?

from djblets.util.decorators import basictag

@register.tag
@basictag(takes_context=True)
def mytag(context, arg1, arg2):
    return context['user']

Far less code and increased readability. Hooray!

@blocktag

@blocktag aims to do the same thing @basictag does but for block tags. A block tag is a tag that contains nested content, like @spaceless or @for. This usually requires even more boilerplate than the above code fragment, except with the added complexity of having to grab the contents of the block.

We’ve condensed it down to this:

from djblets.util.decorators import blocktag

@register.tag
@blocktag
def blinkblock(context, nodelist, arg1, arg2):
    return "<blink>%s</blink>" % nodelist.render(context)

If you’ve built block tags in the past, you’ll appreciate how simple that was.

Django Development with Djblets

Django is an awesome development platform for web applications. With such features as database abstraction, template/view/url separation, built-in authentication with interchangeable backends, it’s made web development much more enjoyable.

We use Django in Review Board with much success. Over time, as we’ve come to develop new features, we realized that much of our codebase was useful outside of Review Board and, bit by bit, moved pieces into a library we call Djblets.

What does Djblets do?

A bit of everything, really. Any time we have useful functionality that isn’t tied to Review Board, we put it here.

Djblet’s feature list currently consists of:

  • Authentication improvements, making it easy to register and login in one step, seamlessly, handle password recovery, and more.
  • Flexible datagrids for displaying data in a paginated list with user-specific column customization, ordering and sorting.
  • Decorators to drastically simplify creation of simple and block template tags.
  • Caching functions for calling a function and caching the result if the data isn’t already in the cache, and a special URL pattern matcher that prevents caching of any contained URLs.
  • Unit testing utility classes.

And of course more little things here and there.

Downloading Djblets

Djblets is not a released app, but it’s pretty stable and well tested. You can check out a copy from our SVN repository, or automatically include it in your own repository through an svn:externals entry.

Djblets is licensed under the MIT license, making it usable in most projects.

Using Djblets

Over time I’ll be writing articles on using the many features of Djblets. See the other posts in the series, or dig around the Djblets source code.

Scroll to Top