Need A Job?

By barneyb on May 26, 2011

I have a need.  A pressing need.  I need new coworkers.  Three of them.

Boring stuff first.  Mentor Graphics Corp is the EDA industry leader and makes all kinds of crazy design and simulation software for electrical engineers, and now embedded developers.  If you have a cell phone or a computer, it's almost guaranteed that you're using something which either embeds Mentor IP or was designed/tested/manufactured with the help of Mentor products.  The company is about a billion dollars in annual revenue and publicly traded.  Our team is currently seven application developers plus a designer, a front-end developer, a multimedia guy, a content editor, and a couple of operations people.  Plus Ron, our boss.  We're hiring three more application developers.  The positions are full-time, on-site, in Wilsonville OR.  Blah, blah, blah.

I work in the corporate marketing department (which is weird, but bear with me) on the web services team which is responsible for pretty much all the public-facing web infrastructure for the company.  www.mentor.com is the primary property, but we run the support portal, an internal business intelligence application, corporate blog hosting, and a couple industry journal sites.  We own everything that comes after the business requirements; divisions in the company come to us with business problems, and we spec, architect, implement, and host the solutions.  Despite the fact we're in the marketing department, IT comes to us for expertise.  Our primary platform is Adobe ColdFusion, but we support Groovy, Java, PHP, and Python for different applications where there was a compelling case to not choose a CFML-based solution.

Now the interesting stuff.

There is a formal job description somewhere, but I don't know where, and I wouldn't link to it even if I did.  If you want to work here, you need two things:

  • technical competence
  • a passion for development

We expect you to be able to not only implement a spec, but also design solutions.  You shouldn't have to be reminded that not everyone speaks English and that clocks around the world don't all say the same time.  You should know why pure functional languages don't have synchronized blocks.  You should have a preference between emacs and vi and be able to articulate in two sentences or less.  You should have commits to some public VCS repository somewhere.  You want to be part of a large non-hierarchical team working on a variety of projects.  You should know what MVCC stands for without looking it up.  You should want to help the six-months-from-now you have less pain, even if it takes a little more work today.  You shouldn't be proficient in all of Java, C#, JavaScript, Python, Ruby, and Lisp.  You should be proficient in at least one of them, and be competent in at least one more, and be able to compare and contrast the merits of the rest.

If that sounds like you, drop me an email at barney_boisvert@mentor.com or bboisvert@gmail.com.  Ron wants a resume, but I want two paragraphs and ~30 lines of interesting code.  Not 40, not 20.

Our hiring process is straightforward: get your info, quick mini-interview via phone, a simple code test, and an on-site interview to meet the team.  Mentor pays competitively, and has exceptional benefits beyond the salary.  Positions are full time, relocation assistance is likely available if you're not in the area – working remote is not an option.  Ron is very reasonable: if you're the right person, he'll go to bat for you/him/me to ensure things work.  Everyone here understands that spending a little cash to get the right people pays off every time.

Posted in , ,

UPDATE: Route 53 API Regression

By barneyb on May 26, 2011

Yesterday I posted about an apparent regression in the AWS Route 53 API, but it appears that it was a documentation issue, not an actual regression.  A member of the AWS team contacted me and confirmed that the docs for the 2010-10-01 version of the API erroneously listed the parameter names with initial caps, even though the implementation only respected lowercase parameter names (which is what the current version – 2011-05-05 – both respects and documents).

So if you followed the docs and didn't test in the wild, code built atop the 2010-10-01 API will not page correctly.  In addition to clarifying the specifics of the problem, AWS indicated the API docs for the 2010-10-01 version had been updated as well, but I pulled them down this morning and they still list initial caps on the parameter names.

In any case, lowercase names for parameters are the way to go, regardless of which version of the API you're using.

Posted in

Route 53 API Regression

By barneyb on May 25, 2011

If you're using Route 53, the latest revision of the API (2011-05-05) changed the casing of the 'name' and 'type' parameters for paged listings.  Previously (in version 2010-10-01) they were 'Name' and 'Type'.  Unfortunately, it appears that the casing change has leaked backwards to the old API version.  So if you're doing paged listings anywhere, you'll want to go update your code to use the lowercase names, even if you're still using the 2010-10-01 endpoint.

UPDATE: AWS contacted me and apparently the problem was documentation, not a regression.

Posted in

Myths about Introverts

By barneyb on May 17, 2011

Myth #1 – Introverts don’t like to talk.
This is not true. Introverts just don’t talk unless they have something to say. They hate small talk. Get an introvert talking about something they are interested in, and they won’t shut up for days.

Myth #2 – Introverts are shy.
Shyness has nothing to do with being an Introvert. Introverts are not necessarily afraid of people. What they need is a reason to interact. They don’t interact for the sake of interacting. If you want to talk to an Introvert, just start talking. Don’t worry about being polite.

Myth #3 – Introverts are rude.
Introverts often don’t see a reason for beating around the bush with social pleasantries. They want everyone to just be real and honest. Unfortunately, this is not acceptable in most settings, so Introverts can feel a lot of pressure to fit in, which they find exhausting.

Myth #4 – Introverts don’t like people.
On the contrary, Introverts intensely value the few friends they have. They can count their close friends on one hand. If you are lucky enough for an introvert to consider you a friend, you probably have a loyal ally for life. Once you have earned their respect as being a person of substance, you’re in.

Myth #5 – Introverts don’t like to go out in public.
Nonsense. Introverts just don’t like to go out in public FOR AS LONG. They also like to avoid the complications that are involved in public activities. They take in data and experiences very quickly, and as a result, don’t need to be there for long to “get it.” They’re ready to go home, recharge, and process it all. In fact, recharging is absolutely crucial for Introverts.

Myth #6 – Introverts always want to be alone.
Introverts are perfectly comfortable with their own thoughts. They think a lot. They daydream. They like to have problems to work on, puzzles to solve. But they can also get incredibly lonely if they don’t have anyone to share their discoveries with. They crave an authentic and sincere connection with ONE PERSON at a time.

Reading through these was quite remarkable.  Clear, concise, precise, and accurate.

From http://suzywire.tumblr.com/ (and deliberately truncated at six).

Posted in

Base CSS Templates

By barneyb on May 17, 2011

After my Progressive Enhancement presentation at cf.objective last week, I had several people ask about baseline CSS that I use.  This sort of surprised me, since I figured at a developer conference CSS would kind of be glossed over (and I built my presentation with that bias).  That said, CSS is a fundamental aspect of progressive enhancement, and I am pleased people are interested in as well.

I use a pair of primary CSS templates when I throw together a new application: CSS Tabs and table.data.

The former is a small snippet of CSS which will turn a UL of LIs into a nice tab bar.  It supports customizing size and colors, as well as stacking multiple bars with different horizontal alignment (left align main nav, right aligned 'help' and 'logout' tabs).  It is NOT a client-side tabber, it's strictly presentational enhancement of a list of normal server-side links.  You could certainly use JS to manipulate the classes on the LIs client-side, but it provides no functionality along those lines.

The latter is a simple starting point for styling data tables (which, by the way, should be the only type of tables you have).  By default it uses a yellow theme for alternating rows, but if you add the 'grey' class it'll flip to a greyscale approach.  It has support for subheadings, multi-column headings, numeric cells, and 'total' rows.

Both are really designed as a starting point for your application to get a base level of prettiness out of the box.  table.data, in particular, usually ends up being further enhanced by the application stylesheet, perhaps to add new cell types or a different color scheme.  I've attempted to make them easy to extend without having to modify the code directly, which will let you grab a new copy (in the case of bug fixes) and not lose any of your changes.  Remember, layers of enhancement is the mantra.

I also generally end up with a .box class, along with .box.error and .box.success variants.  But those are typically more bound to the application's specific look and feel, so I haven't generalized those out into a separate stylesheet.  They're more semantic markup conventions I try to use consistently across applications.

Finally, I posted about inline progress bars last fall, which is a technique that has served me very well on several applications since then.  This is a hybrid JS/CSS technique, not pure CSS, but it's easily dropped into an existing application with the proper markup structures.

Posted in

Even Better Inline Progress Bars

By barneyb on May 17, 2011

In the handful of months since I last posted about inline progress bars, I've made some enhancements to the mechanism. In particular, the original mechanism didn't handle overages very gracefully, and while overage isn't strictly needed for progress, I've ended up wanting the same inline display for other types of measurements (e.g., fundraising dollars against a goal).

The JS has grown slightly more complicated, creating a richer structure to style to handle some of the new stuff:

jQuery(".progress").each(function() {
  var $this = jQuery(this)
  var frac = parseFloat($this.attr("rel"))
  if (isNaN(frac)) {
    return // bad data
  }
  var html = $this.html();
  $this.empty()
    .append(''
      + '<span class="container">'
        + '<span class="status-text-spacer">' + html + '</span>'
        + '<span class="progress-bar" style="width:' + (frac * 100) + '%;"></span>'
        + '<span class="status-text" style="width:' + Math.max(100, frac * 100) + '%;">'
          + '<span class="status-text-spacer">' + html + '</span>'
        + '</span>'
      + '</span>'
    )
  if (frac >= 1) {
    $this.addClass("overage") // strictly for external targetting
      .find(".container")
        .css({
          marginRight: (100 - 100 / frac) + "%",
          width: (100 / frac) + "%"
        })
  }
})

The CSS is still about the same for the base functionality, but with the new stuff, it's far richer:

.progress {
  display: inline-block;
  position: relative;
}
.progress .container {
  display: inline-block;
  position: relative;
  border: 1px solid #999;
  background-color: #f7f7f7;
  color: #f7f7f7;
  white-space: nowrap;
  padding: 0;
  margin: 0;
  width: 100%;
}
.progress .container .progress-bar {
  display: inline-block;
  position: absolute;
  z-index: 0;
  top: 0;
  left: 0;
  height: 100%;
  filter: alpha(opacity=80); /* yeah IE! */
  opacity: 0.8;
  /* .neutral is the default */
  background-color: #ddd;
  border-right: 1px solid #666;
}
.progress.overage.neutral-overage .container .progress-bar {
  background-color: #ddd;
  border-right: 1px solid #666;
}
.progress.ok .container .progress-bar,
.progress.overage.ok-overage .container .progress-bar {
  background-color: #dfd;
  border-right: 1px solid #393;
}
.progress.error .container .progress-bar,
.progress.overage.error-overage .container .progress-bar {
  background-color: #fdd;
  border-right-color: #c66;
}
.progress .container .status-text {
  display: inline-block;
  position: absolute;
  z-index: 1;
  top: 0;
  left: 0;
  color: #000;
  margin: 0;
  padding: 0;
}
.progress .container .status-text-spacer {
  margin: 0 5px;
}

So now instead of just doing this (which will render a neutral bar):

<span class="progress" rel="#raised / goal#">
  #dollarFormat(raised)# of #dollarFormat(goal)# raised...
</span>

You can control the various presentation very granularly (red below 100% and green from 100% up):

<span class="progress error ok-overage" rel="#raised / goal#">
  #dollarFormat(raised)# of #dollarFormat(goal)# raised...
</span>

The original version rendered green bars for everything, with this incarnation you can have neutral, ok, or error semantics for your bars.

Posted in , ,

cf.objective Presentation Links

By barneyb on May 16, 2011

If you're looking for slides and/or code from any cf.objective presentations, they're mostly published on the cf.objective site.  Visit the schedule page, click on a session title, and there should be a download link beneath the session description.  There are still a few missing, but most are there, and the rest should be up in the near future now that the speakers are mostly all home.

Posted in ,

cf.objective: Replace Your Iron With a Cloud

By barneyb on May 13, 2011

My second talk from cf.objective 2011 is currently underway: Replace Your Iron With a Cloud.  Again, a slides-only presentation which you can get either as PPTX or PDF.

Posted in ,

cf.objective: Progressive Enhancement

By barneyb on May 12, 2011

For those of you following along at home, I'm current presenting on Progressive Enhancement at cf.objective 2011.  This presentation is slides-only, and I've made them available as both PPTX and PDF if you want to take a look.

Posted in ,

cf.objective Tomorrow!

By barneyb on May 10, 2011

Tomorrow I'll be in Minneapolis for the 2011 iteration of cf.objective.  If you've looked at the schedule, you'll know I'm speaking twice: one about progressive enhancement first thing Thursday morning after the keynote, and again Friday right after lunch about migrating your apps to the cloud.  You'll also know that there are a hell of a lot of good sessions, so I'm really excited about it.

As is often the case with internet folks, I know a whole lot of people by name and/or handle, but far fewer in person.  So if you see me – I'm the tall, furry guy who isn't Andy Matthews – please say hello.  And as if you didn't need even more incentive, the company I work (Mentor Graphics Corp) for is currently looking to hire a couple more full-time developers out in beautiful Portland, OR.

Posted in , , ,

« PreviousNext »