Ubuntu backlight brightness

Posted on by
Reply

Since I bought my new laptop a few months ago and installed Ubuntu 12.04 on it I have not been able to adjust the brightness of the backlight. Until yesterday, this had not bothered me much; I typically use my laptop in well-lit rooms so the extra brightness was a minor annoyance. Yesterday at the SciPy conference it became an issue while sitting for extended periods of time in the darkened main ballroom. A bit of searching led me to this question on AskUbuntu, which is not specifically about my laptop model but provides a general fix that worked for me. The fix, summarized here:

  1. Edit /etc/default/grub
  2. Change the line GRUB_CMDLINE_LINUX="" into GRUB_CMDLINE_LINUX="acpi_osi=Linux"
  3. Run sudo update-grub
  4. Restart the machine

This is a known bug in Ubuntu with no definite timeframe for a fix.

My frustrating Friday

Posted on by
Reply

Last Friday (03FEB12) I had the first code review for a major new feature I’m currently working on. The design and implementation of this feature are my responsibility, and I’m the only one working on it, so I feel a significant amount of pride, responsibility, and ownership. From this overly-sensitive perspective, the review didn’t go so well.

The application implements real-time signal processing algorithms running on a cluster of machines configured as a grid. Its completely written in ANSI C, despite the fact that one of the overarching design requirements is that the top-level application have no platform-specific code unless absolutely necessary. I don’t agree with the language choice, but the project has sensible reasons for this (the application has a lot of legacy and only two engineers besides myself (out of a team of 18) know C++, and since no one besides me really knows any other languages). Where I start to butt heads, and get increasingly irritated, is in the design choices.

I write object-oriented C as much as sensible, though I do sometimes break encapsulation to make my new code fit cleanly into the legacy portions. I try to break my code up into small, descriptive functions to make it easy to tell what is going on where. I try to keep variable declarations within the innermost scope they are required in. I make heavy use of const, and initialize variables at declaration. None of these are appreciated, and some aren’t even tolerated.

Now, I don’t want to give the impression that I whine about having to follow coding standards. I don’t. Standards are necessary, especially on a large project, where stylistic issues come down to personal preference. However, everything I mentioned above has valid, functional purposes. Some are considered best practices, not only in C but most other languages as well. Yet in my leads’ ideal world, none of those elements (except possibly const usage) would be present in the code.

In this most recent review, I got called on #3 and #4. They want to see all the variables declared at the top of the function, and would prefer them to be initialized at the beginning of the function itself. The reasoning: maintainability. The whole reason for #3 and #4 in the first place is maintainability (and, in a few cases, optimization). However, the code they have been writing and reading for the past 20+ years hasn’t changed measurably from K&R’s style.

The current codebase is unmaintainable, and the corporate coding and design standards were tailored to match the style of all the 15-year-old legacy code the application is built on, to avoid the work of having to update the old code to new standards. A few months ago, I compared the corporate standard to the project standard, and was not happy with the items they tailored. The corporate standard is much more sensible, and we should have updated our codebase as we went to meet it, not make the old code compliant by definition.

I didn’t really want to use this blog for venting about my job, but I’m losing sleep over this tonight and felt writing about it might help.

Ideas, and an Eclipse trick

Posted on by
Reply

When I started this blog I knew my updates would be infrequent, but I didn’t expect to go ten months without one. I’ve had many ideas for posts, and other things, in that time. I have tried different methods to help me remember these ideas, from sending myself emails to maintaining a Google Documents list to carrying around a little spiral-bound notebook. So far, none of these methods has really done anything for me.

A couple weeks ago I read a blog post by someone else who had similar problems with some of the methods I describe above, in particular the notebook method. (I wish I could find the link to this blog. If I come across it again, I’ll add it.) He finally settled on using small blank cards to capture his ideas and thoughts. He writes a single thought on a blank card when it pops in his head; at the end of the day, he takes the used cards and stores them in a box that he consults regularly. I’ve decided to implement this by cutting some blank 3×5 index cards in half and carrying the pieces in my wallet. When I have an idea, I write it down and put the card back in my wallet. I’m still trying to build a habit out of this, and I’m still working on the storage and regular consultation parts, but so far its working better than my notebook did. In fact, the Eclipse trick I’m going to mention is one of the first things I wrote down using this method.

I’ve been using Eclipse at work for my C and C++ development for the past four months or so. The vast majority of my development is in C, though, so for our core application code I’ve been creating C projects in the CDT. The other day, however, I wanted to work on a small amount of C++ code that is part of an external tool that gets rolled up in our application. Since my project only has the “C” nature Eclipse couldn’t resolve any of the C++ headers or keywords, making it fairly useless for editing this tool code. Unfortunately, once you create a CDT project and choose either “C project” or “C++ project”, there is no way to change this decision; in particular, there is no way through Eclipse to add the C++ nature to a C project. I discovered after examining the Eclipse project file that there is a way.

The project XML has a section named <natures>, which lists all of the natures associated with the project. All you have to do to add C++ to a C project is add the line

<nature>org.eclipse.cdt.core.ccnature</nature>

to the <natures> section of the C project. Reopen the project, and you should have C++ listed as a language in the symbols and paths screens. This saved me from having to re-generate the whole project, or work outside Eclipse, just to handle that little bit of C++ code.

Oops…

Posted on by
Reply

So, after a 12-day hiatus, the site is back up. I lost yet another hard drive in my web server, and I foolishly was not making regular backups. Won’t be making that mistake again.

Anyway, I should have the follow-on to that STEM post soon, though with PyCon mere days away now it might not be until next week.

On the technical skills shortage and hiring practices

Posted on by
Reply

Well, when I said I would be posting infrequently, I didn’t expect to go three weeks between posts. I’ve had the thoughts for this post floating around in my head for the past couple weeks, but only today have they coalesced into something coherent.

The issue of skills shortages and inadequate STEM education in the US has been a noteworthy issue for me for at least the past year, partly for personal reasons and partly due to the significant role my employer plays in the current STEM education push. Since the shortages and the education are two somewhat-distinct stages of a pipeline, I intend to cover them in separate posts. This post covers the (supposed) skills shortage in the current workforce, which is the more personal of the issues for me; I’ll discuss the STEM education in a follow-up post.

Vivek Wadhwa posted a piece on TechCrunch a few months ago covering a range of issues with engineering employment. Something in particular stuck out to me:

Alden postulates that employers are looking for very precise skill sets that are not readily available either because of inadequacies in U.S. education and training, or because of insufficient mobility in the labor force.

I definitely agree with the first part of this statement. However, I don’t think training and mobility are the driving issues, though they certainly are issues. In my rather unscientific survey of job postings, I generally see two things: 1) requiring years of experience in precise skill sets; 2) strong preference for, and sometimes explicitly rejecting anyone but, local candidates. If good candidates are routinely rejected for one or both of those reasons, then solving the problems Alden mentioned won’t make much headway. In fact, this trend is one of a few things I think calls into question the efficacy of the STEM education movement, but that is a subject for my next post.

Then there is the appropriateness of the precise requirements. One of Vivek’s commentators summarized this problem well:

My experience is that companies are asking for specific skill sets that aren’t remotely connected to what the position needs. For instance, I saw an ad for the position I am currently happily in, and I didn’t apply because I didn’t have most of the skills they wanted. However, when I saw a link to the same ad from someone I knew who was working in the company, I gave it a shot and was hired right off the bat (because my skills were known to that person).

After a couple of weeks in the position, I could see that someone with the skills they were asking for would have been VERY unhappy in the position. These skills are very commonly advertised for in the industry I’m in, and I can’t help thinking that they’re probably as irrelevant in many of the other jobs as they are in this one, and companies insisting on those skills are eliminating many candidates that are likely perfect for the job in favor of ones that could be a poor fit (even if they’re available).

I have been there myself, having a position where the description didn’t match well with the actual work. To some degree, this inaccuracy is unavoidable; nobody can craft a job description that encompasses everything the position will be required to do. Still, after getting the job you should not hear something to the effect of, “You’re awesome, but we wouldn’t have hired you based on your resume.”. (I got this position through my department manager, so I didn’t formally apply.) I have coworkers who feel deceived to various degrees about what to expect on our current program as well.

From my little corner, these inappropriate filter functions appear to be a serious impediment to successfully filling engineering positions. These mostly affect large companies, but these are the same large companies pouring millions into the STEM effort and trying to get the federal government to do the same. The same companies that claim to be committed to “attracting and retaining world-class talent”. Perhaps these companies should take a critical look at their own houses before proclaiming a critical shortage, or be honest about what they are looking for.