Working at Canonical, three years in. a.k.a wtf just happened?

A couple of people have reached out to me via LinkedIn and reminded me that my three year work anniversary happened last Friday. Three years since I left my job at a local place to go work for the Canonical where I got the chance to be paid to work on open source software and better my Python skills with the team working on Launchpad. My wife wasn’t quite sure. “You’ve only been at your job a year and a half, and your last one was only two years. What makes this different?”

What’s amazing, looking back, is just how *right* the decision turned out to be. I was nervous at the time. I really wasn’t Launchpad’s biggest fan. However, the team I interviewed with held this promise of making me a better developer. They were doing code reviews of every branch that went up to land. They had automated testing, and they firmly believed in unit and functional tests of the code. It was a case of the product didn’t excite me, but the environment, working with smart developers from across the globe, was exactly what I felt like I needed to move forward with my career, my craft.

2013-09-02 18.17.47

I joined my team on Launchpad in a squad of four other developers. It was funny. When I joined I felt so lost. Launchpad is an amazing and huge bit of software, and I knew I was in over my head. I talked with my manager at the time, Deryck, and he told me “Don’t worry, it’ll take you about a year to get really productive working on Launchpad.” A year! Surely you jest, and if you’re not jesting…wtf did I just get myself into?

It was a long road and over time I learned how to take a code review (a really hard skill for many of us), how to do one, and how to talk with other smart and opinionated developers. I learned the value of the daily standup, how to manage work across a kanban board. I learned to really learn from others. Up until this point I’d always been the big fish in a small pond and suddenly I was the minnow hiding in the shallows. Forget books on how to code, just look at the diff in the code review you’re reading right now. Learn!

My boss was right, it was nearly ten months before I really felt like I could be asked to do most things in Launchpad and get them done in an efficient way. Soon our team was moved on from Launchpad to other projects. It was actually pretty great. On the one hand, “Hey! I just got the hang of this thing” but, on the other hand, we were moving on to new things. Development life here has never been one of sitting still. We sit down and work on the Ubuntu cycle of six month plans, and it’s funny because even that is such a long time. Do you really know what you’ll be doing six months from now?

P1100197.jpg

Since that time in Launchpad I’ve gotten work on several different projects and I ended up switching teams to work on the Juju Gui. I didn’t really know a lot about this Juju thing, but the Gui was a fascinating project. It’s a really large scale JavaScript application. This is no “toss some jQuery on a web page” thing here.

I also moved to work under a new manager Gary. As my second manager since starting at Canonical and I was amazed at my luck. Here I’ve had two great mentors that made huge strides in teaching me how to work with other developers, how to do the fun stuff, the mundane, and how to take pride in the accomplishments of the team. I sit down at my computer every day and I’ve got the brain power of amazing people at my disposal over irc, Google Hangouts, email, and more. It’s amazing to think that at these sprints we do, I’m pretty much never the smartest person in the room. However, that’s what’s so great. It’s never boring and when there’s a problem the key is that we put our joint brilliant minds to the problem. In every hard problem we’ve faced I’ve never found that a single person had the one true solution. What we come up with together is always better than what any of us had apart.

When Gary left and there was a void for team lead and it was something I was interested in. I really can’t say enough awesome things about the team of folks I work with. I wanted to keep us all together and I felt like it would be great for us to try to keep things going. It was kind of a “well I’ll just try not to $#@$@# it up” situation. That was more than nine months ago now. Gary and Deryck taught me so much, and I still have to bite my tongue and ask myself “What would Gary do” at times. I’ve kept some things the same, but I’ve also brought my own flavor into the team a bit, at least I like to think so. These days my Github profile doesn’t show me landing a branch a day, but I take great pride in the progress of the team as a whole each and every week.

The team I run now is as awesome a group of people, the best I could hope to work for. I do mean that, I work for my team. It’s never the other way around and that’s one lesson I definitely picked up from my previous leads. The projects we’re working on are exciting and new and are really important to Canonical. I get to sit in and have discussions and planning meetings with Canonical super genius veterans like Kapil, Gustavo, and occasionally Mark Shuttleworth himself.

Looking back I’ve spent the last three years becoming a better developer, getting an on the job training course on leading a team of brilliant people, and crash course on thinking about the project, not just as the bugs or features for the week, but for the project as it needs to exist in three to six months. I’ve spent three years bouncing between “what have I gotten myself into, this is beyond my abilities” to “I’ve got this. You can’t find someone else to do this better”. I always tell people that if you’re not swimming as hard as you can to keep up, find another job. I feel like three years ago I did that and I’ve been swimming ever since.

P1040511.jpg

Three years is a long time in a career these days. It’s been a wild ride and I can’t thank the folks that let me in the door, taught me, and have given me the power to do great things with my work enough. I’ve worked by butt off in Budapest, Copenhagen, Cape Town, Brussels, North Carolina, London, Vegas, and the bay area a few times. Will I be here three years from now? Who knows, but I know I’ve got an awesome team to work with on Monday and we’ll be building an awesome product to keep building. I’m going to really enjoy doing work that’s challenging and fulfilling every step of the way.

DSC00329

Juju Quickstart and the power of bundles

The Juju UI team has been hard at work making it even easier for you to get started with Juju. We’ve got a new tool for everyone that is appropriately named Juju Quickstart and when you combine it with the power of Juju bundles you’re in for something special.

Quickstart is a Juju plugin that aims to help you get up and running with Juju faster than any set of commands you can copy and paste. First, to use Quickstart you need to install it. If you’re on the upcoming Ubuntu Trusty release it’s already there for you. If you’re on an older version of Ubuntu you need to get the Juju stable ppa

sudo add-apt-repository ppa:juju/stable
sudo apt-get update

Installing Quickstart is then just:

sudo apt-get install juju-quickstart

Once you’ve got Quickstart installed you are ready to use it to deploy Juju environments. Just run it with `juju-quickstart`. Quickstart will then open a window to help walk you through setting up your first cloud environment using Juju.

Quickstart can help you configure and setup clouds using LXC (for local environments), OpenStack (which is used for HP Cloud), Windows Azure, and Amazon EC2. It knows what configuration data is required for each cloud provider and provides hints on where to find the information you’ll need.

Once you’ve configured  your cloud provider, Quickstart will bootstrap a Juju environment on it for you. This takes a while on live clouds as this is bringing up instances.

Quickstart does a couple of things to make the environment nicer than your typical bootstrap. First, it will automatically install the Juju GUI for you. It does this on the first machine brought up in the environment so that it’s co-located, which means it comes up much faster and does not incur the cost of a separate machine.  Once the GUI is up and running, Quickstart will automatically launch your browser and log you into the GUI. This saves you from having to copy and paste your admin secret to log in.

If you would like to setup additional environments you can re-launch Quickstart at any time. Use juju-quickstart -i to get back to the guided setup.

Once the environment is up Quickstart still helps you out by providing a shortcut to get back to the Juju GUI running. It will auto launch your browser, find the right IP address of the GUI, and auto log you in. Come back the next day and Quickstart is still the fastest way to get back into your environment.

Finally, Quickstart works great with the new Juju charm bundles feature. A bundle is a set of services with a specific configuration and their corresponding relations that can be deployed together via a single step. Instead of deploying a single service, they can be used to deploy an entire workload, with working relations and configuration. The use of bundles allows for easy repeatability and for sharing of complex, multi-service deployments. Quickstart can accept a bundle and will deploy that bundle for you. If the environment is not bootstrapped it will bring up the environment, install the GUI, and then deploy the bundle.

For instance, here is the one command needed to deploy a bundle that we’ve created and shared:

juju-quickstart bundle:~jorge/mongodb-cluster/1/mongodb-cluster

If the environment is already bootstrapped and running then Quickstart will just deploy the bundle. The two features together work great for testing repeatable deployments. What’s great is that the power of Juju means you can test this deployment on multiple clouds effortlessly.  For instance you can design and configure your bundle locally via LXC and, when satisfied, deploy it to a real environment, simply by changing the environment command-line option when launching Quickstart.

Try out Quickstart and bundles and let us know what you think. Feel free to hop into our irc channel #juju on Freenode if you’ve got any questions. We’re happy to help.

Make sure to check out Mat’s great YouTube video walk through as well over on the Juju GUI blog.

Ubuntu Community Appreciation Day: My Loco!

So on Ubuntu Community Appreciation Day I want to toss a big thanks out to the Michigan Loco. It’s a great bunch of guys and gals that I talk with online every day and have helped keep me sane, taught me new things, and overall have just made this community thing work for me. If it wasn’t for them, I’d not be running Ubuntu and working on Launchpad today. So hats off to everyone in the Loco and here’s to all the other great people making this community rock!

Mutli-monitor on the go, DisplayLink usb monitor

Now that I’m going to be working for Canonical I’ve got to get ready for some week long sprints. Now, I LOVE my 12″ X201 thinkpad. It’s the best laptop I’ve ever owned, and I’ve owned macs, toshibas, dells, and larger thinkpads. When I’m home, I dock and use dual 21″ displays. When I travel, it’s the perfect size, yet still packs an i5 and 8GB of ram.

However, a week of living inside a 12″ display has me a little claustrophobic. So I decided I should do something about it. They make some decent looking USB powered external monitors that seemed like they’d travel pretty nice. Once cable, no external power needs, and another 1024px is a good thing. Mobile mutli-head..sweet!

Getting it working

The trouble is getting it working. The USB monitors use something called DisplayLink to work. Getting that to work is a little tricky. Fortunately, a few brave souls paved my way. You can see the links I checked out to get started

Once you install xserver-xorg-video-displaylink you’ll need an xorg.conf file since DisplayLink doesn’t work with all the hotplug business that makes modern video work.

It’s alive!

The problems

The real trouble is that I ONLY want this xorg.conf file when I’m actually using the USB display. When I’m docked at home or using a projector, I don’t need it. Right now I’ve just written a toggle script that I use to flip the xorg back and forth.

There are also some usage issues. It only works for me if the DisplayLink monitor is the primary one in the xorg server setup. This means the LightDM is running on there and it’s running in just a few hundred pixels of the display. I can still log in though so it’s not killer.

You can’t drag windows back and forth among them, which isn’t the end of the world, but some apps (like Google Chrome) only launch on the same display as the currently running instances. So I can’t find a way to get Chrome to run on both monitors. For now I just run Firefox on one and Chrome on the other.

Overall, I’m really digging the setup. I’m sitting at the bar with irc on a second display while I write this blog post out all unplugged from any power. I think it’ll make life a LOT nicer for road traveling for any extended time.

#!/bin/sh -e
# toggle xorg.conf on/off so I can add/remove it as needed
# requires a reboot after running to take effect

if [ -e /etc/X11/xorg.conf ]
then
    echo "Removing xorg.conf file"
    sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.usb
else
    echo "Setting xorg.conf file"
    sudo mv /etc/X11/xorg.conf.usb /etc/X11/xorg.conf
fi

My xorg.conf file I’m using

############ Original Video Settings ###########

Section "Files"
    ModulePath      "/usr/lib/xorg/modules"
    ModulePath      "/usr/lib/xorg/modules/drivers"
EndSection

##################################################

Section "Device"
    Identifier      "Configured Video Device"
    Driver          "intel"
EndSection

Section "Monitor"
        Identifier      "Configured Monitor"
EndSection

Section "Screen"
    Identifier      "Default Screen"
    Monitor         "Configured Monitor"
    Device          "Configured Video Device"
    SubSection "Display"
            Depth   24
            Modes   "1280x800"
    EndSubSection
EndSection

############### DisplayLink Stuff ###############

Section "Device"
    Identifier      "DisplayLinkDevice"
    driver          "displaylink"
    Option  "fbdev" "/dev/fb0"
EndSection

Section "Monitor"
    Identifier      "DisplayLinkMonitor"
EndSection

Section "Screen"
    Identifier      "DisplayLinkScreen"
    Device          "DisplayLinkDevice"
    Monitor         "DisplayLinkMonitor"
        SubSection "Display"
            Depth   16
            Modes   "1024x600"
        EndSubSection
EndSection

#################################################

Section "ServerLayout"
        Identifier      "Server Layout"
        Screen  0       "DisplayLinkScreen" 0 0
        Screen  1       "Default Screen" RightOf "DisplayLinkScreen"
        Option          "Xinerama" "Off"
EndSection

Visual of the display issue with LightDM

Ubuntu: Help Wanted

So Jono wants to know how we can get more developers interested in Ubuntu. We got talking about it in the #ubuntu-us-mi loco and it sparked an interesting debate. Just who are you looking for? Jono mentions “people interested in getting involved in packaging, fixing bugs, and joining our community”, but that’s not just developers. I mean, our guy that started the Ubuntu Bug Jams doesn’t do much development for Ubuntu. Our debate also had us wondering if packaging was really a developer task or if it was better left to the non-developers so as to free up valuable developer time to add more features and fix more bugs.

Personally, I took the idea of the Bug Jams and decided to start my own Packaging Jam. I wanted to to learn to be a MOTU and thought it would be great to bring in someone who knew the ropes. For me it’s hard to go through the documentation and figure out how things work. Especially since I was a PHP developer. What do I know of build systems? I just deploy from source code via scripts.

I never ended up reaching that goal of becoming a MOTU. It was just too hard to get through all the docs and learn all the rules. There are so many different tools. People think Git is a series of disjointed commands? Look at the list of things in bold here.

It’s insane. I’ve moved on now and I do Python programming and I’ve had to learn how to build packages for Python tools, but it seems a bit easier using tools that you already use for Python. I haven’t gone the extra mile to package things up into .deb files. I think that the popularity of scripting languages with their own build/distribution tools have taken a big hit on your pool of potential packagers and such.

Well anyway, back to Jono’s request. I think there are a few things. First, narrow down your post. What are you looking for, more help packaging existing app? Help doing bugs? Help developing awesome apps? Each are a bit different. Based on our discussion I’m going to run with packagers.

The two things I think that would help potential packagers getting going would be

  1. A more formal filled mentoring program. I think if existing packagers brought in trainees to help watch and build the packages during the alpha stage of a release, over time they’d pick things up. People need to learn best practices, how the tools fit together, and it’s best to pick this up through practical use under a guiding eye. The one trick is I wonder is how it would be best for two parties to share a common build/package environment. Developers can share an editor via various online tools, I’m not sure how to share a pbuilder instance.
  2. I once mentioned how I think one could build a practical web application to walk someone through packaging step by step. Imagine that you get walked through getting source, making changes to the changelog, and rebuilding the package. It could even be tied into the ppa system so that your ‘project’ can be built as part of walking through the various steps. It’s a lot of work, but I could see it as something that has different modules and as you work through them you learn a new trick with each.

We just want to help users…really, let us be

Ok, that’s it. If you’ve been listening to our Lococast.net episodes you’ll know that I thought the whole stackexchange for Ubuntu Q&A was a bad idea. Too many places for users to go and find help/answers seems like it’d be a large negative. In the end the community decided to go ahead with it and here we are.

Except, the Ubuntu community can’t seem todo anything without drawing out the complains from swaths of the neighboring communities. So we end up with with a series of events that look like this:

This is just crap. I mean, if a community wants to do it’s own thing, and they have the means to supply both the helpers and the helpies needed for the thing to work, why does anyone need to get up in arms about it. You think a joint one would prove more useful…then do it…prove it. If the joint stackexchange will provide more value to users, then the users will find that out and use it.

I’m already worried about issues with the volume of questions for just the Ubuntu community. You think some how making it a larger swath of people would make it better? We’ll see. But quit the whining.

Due to all of this I feel like I need to stand up for my community. While I’m not on board with this stackexchange being a long term solution, I feel like I need to step up and support it. So I’ve signed up and will be monitoring a number of tags in the stackexchange that are up my alley. In particular I’ll be keeping an eye on: python, vim, terminal, command line, and zsh. I might add some others as I get into it more.

Just a heads up for users, you can create a custom RSS feed of only specific tags by playing with the url. For instance, below is my url I used for just my tags. Notice each tag is separated via +or+.

http://ubuntu.stackexchange.com/questions/tagged/python+or+vim+or+terminal+or+command-line+or+zsh

Doing this will provide you with a page you can bookmark, but that page will also have an RSS feed on it for those tags. Definitely helpful since I’m going to try to keep things sensible by limited my involvement to my specialties.

So get over there and find your support niche today. Together the Ubuntu community is quite awesome, and I wish the rest of the world would quit trying to force things upon us we never asked for.

Lococast.net back, now with screencast goodness

A quick Lococast.net update. After PyOhio ate up one episode and then my illness ate up another, Craig and I finally got back behind the mics for episode 4. Thanks for everyone that checked in on us and sorry for the delay.

Along with that I managed to release something new. A screencast! That’s right, I’m getting tired of repeatedly trying to show the same tricks and decided if I screencast the stuff I can just point people at the videos. Video is a whole new ballgame to me, and I’m cheating by using this script from the great Ubuntu Screencast community.

My first episode is naturally one on Vim and the awesomeness of splits for very day use. I’m starting planning on my next Vim one now. Make sure to check it out. The videos are available from blip.tv (with better audio) and Youtube.

Let me know if there’s anything in particular you’d like to see covered and make sure you subscribe to the Lococast.net RSS feed to keep up on updates.

p.s. go check out my talk and the other great ones from PyOhio at: http://python.mirocommunity.org/category/pyohio-2010