Today was a full day of qualifying rounds for the 2014 US FIRST regional competition in California, PA.
I didn't investigate the arrangement, or the rules, too closely, but picked up a few things throughout the day. Each team alternates between the "Blue Alliance" and the "Red Alliance", and each round has these alliances comprised of different team members. In this way, each team gets to work with and compete against various permutations of all the other teams. This arrangement provided for some very interesting matches, as some robots complimented others extremely well. Similarly, some robots provided better defense against others.
As I understand it, all of the teams on the winning alliance earn points. This allows strong teams to carry weaker ones. I like this, because it avoids penalizing a weaker (or perhaps junior) team, while still allowing for competition and the element of surprise. The top eight teams at the end of all of the qualification rounds then get to pick teammates for the final rounds. This is where the "all teams play with and against each other" format pays off: a team might not have scored consistently well, but they may compliment a high-scoring team's tactics and thus be selected to join them.
Without a doubt most of the teams played strong offense today. As the day progressed, the skill of the robot drivers improved, and the quality (and quantity) of shots taken also improved. Most of the teams avoided any kind of aggressive defense until the afternoon rounds. Whether this was a function of learning the other teams playing styles (and strengths), or gaining a better understanding of what the referees would count as a foul, the end results were much more interesting afternoon matches.
The Bexley team made a conscious decision to make a defensive robot. Their thinking was that they could block opponents shots, and provide a valuable service to the other teams who had focused on offensive robots. This approach actually would have served them quite well, except for three major problems.
First, the Bexley robot was tall and thin, leading to some balance issues. During one match, the robot zoomed forward and toppled over onto its face, rendering it completely inoperative. The entire auditorium let out a gasp of surprise and shared frustration as the robot fell over.
Second, the Bexley robot wasn't a very effective blocker. The goal was to quickly hoist a pole into the air to block the upper goals. The competition rules placed firm limits on a robot's height, but permitted a telescoping arm of some sort to be extended for short periods. For several reasons the Bexley robot simply couldn't hoist the arm high enough to effectively block shots.
Third, the Bexley robot was pretty flimsy. Furious repair work was performed after almost every round. The other robots were almost all short and squat, which yields a number of competitive advantages. Those robots that weren't short or squat had superior design and construction.
Each match is played in two phases: a 30 second autonomous phase in which the robot does it own (pre-programmed) thing, and a teleoperated phase, in which a human driver controls the functions of the robot. Some of the autonomous sequences were nothing short of amazing. One team managed to score two aerial goals in that 30 seconds, all under the robot's own control. Other autonomous phases were absolutely comical, as a robot would spin in circles and lob a playing piece out into the audience.
During one of the later matches, the Bexley team placed their robot into position at the start of the match, and then stood back for the autonomous round. Their robot quickly extended its blocking arm, and managed to successfully block a shot from an opposing robot. It was actually quite a treat to see the robot perform as desired, and there was an awful lot of cheering (and laughter) from our section.
I'm impressed with the organization of this event. The FIRST people have been doing this for two decades or more, and it shows. Teams are queued up well before their match. The matches are executed in quick succession. And there's little wasted time after a match: the teams that just played haul their robots off the playing field as the next contestants are hauling their robots on.
The pit areas are a flurry of activity. There's a strong focus on safety, and pit access requires safety glasses. Simple prescription spectacles are not sufficient.
I've learned an awful lot about what makes a successful robot, as well as some of the traits of a successful team. I'm more energized than ever before to volunteer to help Bexley with next year's competition.
There are more qualifying rounds tomorrow morning. Then lunch, and then the real competition starts. I doubt anyone will pick the Bexley robot as a teammate, but we may be surprised tomorrow! I'm really looking forward to seeing how this concludes.
Jonah is a member of his high school's US FIRST robotics team. We joined him in Uniontown, PA for his team's chance to compete against other schools.
I helped Jonah and his teammates a bit at the beginning of their season by providing some guidance on Linux. It wasn't much, but it somehow earned me the title of "mentor." Maybe I can live up to that title next year.
On the few occasions I participated, I was generally impressed with their robot, and the speed with which they assembled it.
Walking into the competition area today, though, gave me a whole new perspective. The other schools' robots are all extremely well done. Dauntingly so. Watching some of the practice rounds was nothing short of awe-inspiring. While I was smoking cigarettes and listening to death metal at 16, these kids have figured out hydraulics, electronics, and computer vision systems, not to mention basic mechanical skills that I still lack!
Jonah's team's robot had some problems today, and was utterly unable to move during its practice round. I helped investigate the situation afterwards, and it appeared to me to be a networking issue between the control station and the robot. Due to time constraints (and some rather inflexible rules), they were unable to verify that they resolved this problem, so they'll be going into tomorrow's competition with more than a little trepidation.
Despite this, and despite the odds being against them in light of some of the competition, Jonah and his team are in pretty good spirits. They're pretty realistic about their chances, and are looking to enjoy the experience, as well as to pick up a few ideas for next year's competition.
Inspired by Tess's Halloween costume, and with an interest in improved visibility while I'm riding my bike at night, I made a minor modification to my front tire.
This was also an excuse to finally use Sugru, a substance about which I'd heard a great many things but never had a reason to use myself. The stuff is extremely easy to use, and made attaching the LED lights to my wheel super simple. The battery pack is affixed to the spokes with simple zip ties. I'll need to make some improvements on that, in order to be able to replace the batteries without having to cut the ties.
I used a full pack (5 grams) of Sugru in order to mount the lights. I could probably have gotten away with less, but as this was my first application I decided not to be to stingy with the stuff.
I have several more packs of Sugru left over, so I'll likely add LEDs to my rear wheels, too!
I rode the bike to work this morning and noticed more than a few people taking a look at my wheel. I definitely felt safer riding home in the dark knowing that I was a more visible object on the road.
A coworker told me about Revolights today. They look super cool, but they're also super expensive: $230 for the pair! Maybe I'll ask Santa ...
Tess lost her iPhone on Tuesday night.
She'd purchased this iPhone used with her own money, so the loss of the phone was a hit financially as well as a detriment to her lifestyle. Tess wasn't sure if she simply misplaced it, or maybe a friend had collected it for her.
On Wednesday morning she used Find My iPhone to discover that it was several blocks away from our house, either in an apartment building or perhaps somewhere along the wooded banks of the Alum Creek. Angela called the cops and explained the situation. The nice officer went over to the area in question, but wasn't able to identify which apartment might contain the phone. Interestingly, the phone's icon went dark on the Find My iPhone map about the time that the cop got nearby, so presumably someone had turned it off.
When Tess came home from school Wednesday, we were able to get some more details, and do some more investigating. She did have a PIN code activated, so it was unlikely that anyone had used the phone to do much. Looking at the phone's activity according to our Verizon account suggested that three texts were sent around the time Tess thinks she lost it. Additionally, some data had been used through the night.
At first, we thought that perhaps one of Tess's friends may have taken the phone and sent the texts. Several of her friends do know her PIN, and kids do silly things to one another. The recipient of the texts were Tess's ex-boyfriend, so conceivably someone could have sent something to him from Tess's phone trying to stir up trouble. Then they may have left the phone back where they found it, thinking that Tess would reclaim it.
A second look at the Verizon account indicated only a small amount of data usage. This was probably just background apps phoning home, and not someone actively using the phone to do anything. This was reassuring.
The location of the phone on Wednesday pretty clearly indicated that someone other than one of Tess's friends had possession of it. Or perhaps someone found it, discovered it locked and unusable, and dropped it by the creek banks no longer interested in it.
We consulted the Find My iPhone map again several times, and confirmed that the phone was reporting the same location. I decided to take the dog for a walk to see if I could spot the phone. The plan was that I'd call home when I approached the area, and Angela or Tess could activate the phone's ringer to help me locate it.
I got to the target location, called Angela, and asked her to activate the ringer. Almost immediately the phone's icon went dark on the map. I poked around for a bit, trying to see if anyone was obviously tending to an iPhone. I did see one homeless guy camped out by the water, but I was more than a little hesitant to approach him by myself. I asked Angela to again engage the ringer. This time she told me that the phone's icon was moving on the map!
It moved a couple blocks over, and then came to a stop. The game was afoot! Clearly someone had the phone in their possession, and were moving quickly: either on bike or in a car. I headed toward the new destination, and explicitly told Angela to not engage the ringer again. No reason to give away our activities.
I approached the corner at which the phone was reporting its location and saw a young boy sitting in plastic swing hanging from the branch of a tree. His shoulders were slumped, and he was clearly looking at something in his hands. As I rounded the corner, I saw that he was holding something white. Tess's iPhone is a white one, and is in a white case. Confident that I'd found the phone I approached the young boy.
"Hey, is that a white iPhone? My daughter lost her's," I said to the kid. He looked up at me a little surprised, but almost immediately held out the iPhone to me. It was definitely Tess's phone.
I didn't have much cash on me, but I did offer the kid a couple bucks for finding the phone. I've no idea whether this kid is the one who took it, or if he found it somewhere. Either way, I was perfectly willing to give him a small reward for returning it to me. He sheepishly said "That's okay" and lowered his head.
After getting the phone back, we tried to fill in the missing pieces of our theory. Tess reviewed her text history and found that the texts to her ex-boyfriend were in fact sent by her earlier that day. The time of these texts reported on the Verizon account was off quite a bit from when Tess sent them, which made our investigation a little more complicated. It also didn't help that she didn't remember that she'd texted with him on Tuesday -- that would have been a useful data point to have when building our theory.
Thankfully the story had a happy and non-confrontational ending. The phone was peacefully recovered, and was intact.
Two years ago I gave a presentation entitled Real World Job Skills the Free Software Way at the 2011 Ohio LinuxFest. I presented an updated version of this at the 2013 Ohio LinuxFest this weekend.
For this presentation, I expanded the subject to include all of open source, not just free software. That distinction is subtle, but important. I also expanded considerably on the list of skills one can gain from working with open source software.
I focused on three major benefits from participating in one or more open source projects: core competencies, other technical skills, and non-technical skills.
One of the remarkable things about open source is the sheer quantity of projects. Many projects aim to solve the same (or similar) problems in very different ways. This is an important thing to keep in mind, as it means participants have greater exposure to alternatives.
The prevalence of open source also means that it's so easy to try, with little risk. Whether you dabble on your own hardware, or you use a hosted provider somewhere, there's really no excuse not to be learning something open source.
Generalization > Specialization
One of the first things I did in my presentation was to admonish the attendees to learn a little about a lot. Sysadmins need to know a little SQL, and maybe a little about one or more programming languages beyond just shell scripting. Developers should know a little about system administration in order to better understand how their applications work in the bigger picture. "Specialization is good, but generalization is better," I told them.
Wikipedia lists more than 250 distinct Linux distributions, more than 70 open source programming languages, and more than 70 open source database systems.
When I think of open source, I think of the big projects that demonstrate the success of the development model: the Linux kernel, the Apache httpd, various development languages like PHP, Python and Ruby, and all of the open source database systems. These are the big ticket technologies with which one can gain real technical skill. Linux admins and MongoDB admins and Ruby developers are all in demand these days, so by participating in open source projects (of all kinds) you can build demonstrable skill in these technologies.
And beyond the big ticket items listed above, open source will help you learn things like version control, virtualization, configuration management, development frameworks, and a whole lot more. All of these are used by employers, so you're only making yourself more appealing to current or potential employers by gaining expertise through open source participation.
Other Technical Skills
Regardless of what projects you choose to use, your involvement with open source software will help you develop a lot of ancillary skills. You'll need to be able to file cogent bug reports. You'll need to be able to deal with people of different cultural backgrounds. You'll need to communicate with people for whom your language is not their's. Communication is absolutely a technical skill, and can be honed through participation in open source projects.
There's also things like writing unit tests. More and more open source projects are demanding that contributions include tests to verify the patch you may be submitting. Writing tests demonstrates that you have a commitment to the success of the project as much as the success of your specific patch. It's a commitment to quality.
Building packages for existing open source projects is an important -- and oft-overlooked -- technical skill. Packaged installations are a primary component of automation, and are critical at bigger employers.
Owen suggested to me that UX -- user experience -- is another technical skill to be gained from open source. At first I scoffed at this, thinking it was too niche of an example, but after some discussion on the matter I realized how important this actually is. UX is far more than just responsive web design or mobile application interfaces. I asked the attendees of my presentation how many of them enjoyed using SELinux, and no hands went up. I then asked how many people simply turned SELinux off, and almost every hand went up. That's because, I pointed out, the user experience of SELinux is pretty poor. The same can be said for Sendmail M4 configurations, and a host of other things. UX is about the experience of the user of your product or project: that may be a sysadmin writing SELinux policies.
Participation in open source will help you build technical acumen in a variety of different and important ways. It will also help you develop a host of non-technical skills, all of which will make you a better employee.
Problem solving is, I think, one of the biggest non-technical skills. The reason I claim this isn't a technical skill is because problem solving involves looking at the bigger picture. You don't need to know how to fix something to correctly identify that it's broken. The staggering quantity of open source projects means that if you have trouble with Project X, you might find success with Project Y. So you can't get Apache to do what you want? Maybe you'll succeed with nginx or Lighttpd. Maybe Fedora will work where Debian has stymied you.
This kind of lateral thinking is important to employers because it helps them identify alternate solutions. It also helps influence discussions of "build vs. buy." If you don't know what options exist in the open source world, you're pretty much at the mercy of vendors to sell you what they have. If, however, you have open source experience and expertise, you have a real shot at building the best solution for your situation.
Communication and teamwork are two other non-technical skills you'll develop through open source. Communication is absolutely a skill, and it gets better through iterative use. Open source is, essentially, all about communication: whether it's mailing list discussions, or back-and-forth on a bug tracker, or actual code contributions, you're communicating with the other members of your community. You'll need to learn to be precise, unambiguous, and (mostly) tactful.
Similarly, teamwork is something that many people think "just happens," when in fact its a skill that develops over time. The larger, more successful open source projects have successful teams distributing the effort of writing code, writing documentation, shepherding bugs, and more. Smaller projects with fewer participants may struggle to handle all of the responsibilities successfully.
Professional networking is the final non-technical skill that I highlighted as a benefit from open source involvement. You'll meet a lot of interesting people, and these people will be able to help you out in surprising ways. When I have problems at my day job, I often contact one or more of my peers in the open source community to brainstorm or bounce ideas off of them. In my experience, the people I know often know what I need to succeed. And speaking more broadly, open source participation introduces you to people and cultures from all over the world, making you a more interesting person to know.
Just like the first time I presented this, I asked the audience "How many of you have a GitHub account? And how many of you link your GitHub account from your resume?" And as before, the response to the second question was almost non-existent. (I was pleased to see a handful of hands answer in the affirmative, though, so some progress is being made!) One fellow in the front of the room said "Because there's so little there!"
To this I responded that the lack of original material in your account is ancillary to the public history of your participation in open source projects. Sure, you could fork projects in which you're interested, but your GitHub account should also document the bugs you've reported, the improvements to documentation that you've submitted, and generally enumerate your specific interests by the projects you star. All of this will help potential employers evaluate your skills and interests.
I did point out that open source skills are easier to highlight when applying for a new job. The question of how to advertise your open source experience to an existing employer is a little trickier. It depends greatly on the kind of employer, the relationship you have with your peers and superiors, and a lot more. It's certainly not impossible to leverage open source expertise into an improved situation at your existing employer, but it takes a little more effort -- and probably a little more savvy -- to succeed.
After my prepared remarks, I opened up a discussion with the attendees. This is always my favorite part of a presentation, because it gets away from the script into the things in which people are really interested.
One young man asked me what I thought of certifications. I equivocated a little, saying that they're not a bad thing to have, but neither are they sufficient in my mind. A cert essentially says "I was able to pass this test," but doesn't really impart the same information as reviewing someone's GitHub history. Someone else in the audience astutely observed that hiring managers and HR folks are unlikely to go look at your GitHub account, whereas they are likely to immediately understand the relative benefit of a certification.
This was a great observation and caught me by surprise. My first response was "Well, let's change that together!" which got some chuckles. It's true that a certificate is a decent proxy for experience. A trusted third party says "Scott knows this" and that makes it an easy baseline for HR folks and hiring managers. This highlights the importance of the cover letter when applying for a job, because you can provide more explication for your open source experience.
A young man in the front row asked about the relative benefits of generalization versus specialization, specifically inquiring whether there were situations in which generalization might be a professional detriment. This started a great conversation between several others in the audience, and was probably my favorite part of the session. A lot of good points were raised. I wrapped things up by comparing professional skills development to university education: Your major program of study doesn't mean that you ignore other subjects altogether. Universities want their graduates to have a well-rounded, general baseline of education upon which their major focus builds.
One man shared that he volunteers with high school students, and wanted to know if I could identify the one or two most important skills to develop prior to specific professional experience. I suggested that communication and teamwork were probably the best choices. Being able to communicate effectively online isn't a skill being taught by many schools, so real guidance in this regard would go a long way. Even many adults with established open source careers still have a hard time saying "Your code sucks" in a way that doesn't also imply "You suck." This generated a lot of nodding heads in the audience.
To my surprise, this question was followed up by an actual high school student asking my advice whether he should apply his time and effort developing something new of his own, or if he should instead spend his energies by contributing in smaller ways to established projects. In my mind, the two are not mutually exclusive. Participation in other projects is sure to yield benefits to his own efforts in unexpected ways, so why would he not do that?
The discussion was great this year, and I'm really glad I made an effort to leave time for it. Several people approached me after the session to have a word, and that was also a lot of fun. I always enjoying hearing anecdotes about open source success.
I hope I get the opportunity to give this presentation again!