Tuesday, June 25, 2019

On licensing software engineers

In this post I will attempt to argue that, if one believes that there should be a licensing process for professional software engineers (and there are good arguments that there shouldn't be), that the licensing process for professional actuaries would serve as an excellent model to copy, and is superior to modeling a software engineering licensing process off of the so-called "Professional Engineer" (PE) license available to, e.g., civil, chemical, mechanical and electrical engineers.

Every once in a while, particularly after a catastrophic software-induced failure (for instance, after the allegations of unintended acceleration on the part of the Toyota acceleration control module), I hear renewed calls for software engineers to be professionally licensed, to ensure that only competent and trustworthy people can practice in the field (or can practice particular roles in the field).

What I hear people propose the most often is to add a "Software Engineer" exam to the set of exams one can take to become a licensed "Professional Engineer".

This is a problematic idea for several reasons.

First off, the standard PE track requires taking a "Fundamentals of Engineering" exam prior to taking the PE subject-matter exam. The FE exam is all good stuff to know, but it seems to cover the overlap between traditional fields of physical engineering. A computer science student or software engineer might know this material by coincidence, but current programs aren't necessarily designed to impart this knowledge.

Second off, the standard PE certification strongly assumes that one has an engineering degree from an ABET-accredited engineering program, likely in the engineering school of a major university. Without even getting to the many software engineers who don't even major in CS, the ABET requirement, as it stands, would make it impossible for people who majored in CS at Carnegie Mellon or at, I believe, CalTech, to attain a PE license. Discussion of PE certification for Software Engineers have talked about backdoors and grandfather clauses for institutions like these -- but when the top programs in a discipline require a grandfather clause for the certification you're proposing, perhaps something is wrong with the certification.

Third off, many of the best practical software engineers I know don't have degrees in computer science or computer engineering. Many have degrees in other STEM fields, and some have no degree at all, yet are far more practically competent than large numbers of people who hold CS degrees.

Luckily there are professional domains other than engineering that have long-established professional licensing systems. I propose that a better one to copy would be the system used to license "actuaries".

Actuaries work in industries like finance, insurance, etc. Their role involves measuring and managing risk and uncertainty. To an outsider like myself their field looks like a highly specialized subfield of applied statistics.

And they have a licensing system.

Best of all, they have a licensing system that, in the US, does not require that your degree be in any particular field (source : https://www.howtobecome.com/how-to-become-an-actuary ). Yet, at the same time, their licensing system is rigorous enough that those actuaries who did not major in "actuarial science" often have undergraduate degrees in mathematics.

And, like computing, their discipline is considered to be a quantitative field, which, arguably, is a better analogy for how to treat professional software development than "engineering"

Their certification process proceeds in steps and involves a mixture of exams and apprenticeship. Exams include topics like markov chains, survival models, generalized linear models, etc. Apprenticeship, I presume, entails working (for pay?) under a certified actuary.

Of course, I, personally, prefer the current system of "no certification process whatsoever". But, if you're going to make a certification process for software developers, I think the actuarial model is a better model for most day-to-day software engineering than the PE model.

I *could*, however, imagine a PE license for something like "controls" or "cyber-physical systems", and a world in which someone in charge of the Toyota acceleration control module would have to be dual-certified in that and in a non-PE software development certification modeled after actuarial certification. In such a world the person who is in charge of writing your banking software might have to hold some currently non-existent software development certification, but would not need a PE certification to perform what is, acknowledgedly, a critical function, but not which is also not a task that requires training in physical engineering.

Back in the robotics world

I now work for Standard Cognition

Wednesday, July 6, 2016

disassembly at repl?

I realize that "I just discovered something amazing about LISP that other people have known about for 30 years" posts can be kinda irritating, but I'm going to make one anyway.


Apparently in some (all?) dialects of common lisp, one can create a new function at the REPL, ask for its assembly at the REPL, and get the assembly for the function one just typed.


Check this out.


CL-USER> (defun snarf (n) (+ 5 n))
SNARF
CL-USER> (disassemble 'snarf)
; disassembly for SNARF
; Size: 39 bytes. Origin: #x100606317C
; 7C:       498B4C2460       MOV RCX, [R12+96]                ; thread.binding-stack-pointer
                                                              ; no-arg-parsing entry point
; 81:       48894DF8         MOV [RBP-8], RCX
; 85:       BF0A000000       MOV EDI, 10
; 8A:       488BD3           MOV RDX, RBX
; 8D:       41BBD0010020     MOV R11D, 536871376              ; GENERIC-+
; 93:       41FFD3           CALL R11
; 96:       488B5DF0         MOV RBX, [RBP-16]
; 9A:       488BE5           MOV RSP, RBP
; 9D:       F8               CLC
; 9E:       5D               POP RBP
; 9F:       C3               RET
; A0:       0F0B10           BREAK 16                         ; Invalid argument count trap
NIL
CL-USER> (documentation 'disassemble 'function)
"Disassemble the compiled code associated with OBJECT, which can be a
  function, a lambda expression, or a symbol with a function definition. If
  it is not already compiled, the compiler is called to produce something to
  disassemble."
CL-USER> 

Sunday, February 14, 2016

No more IR remotes.

At work I frequently program computers attached to banks of 9 or 12 HDMI screens, sometimes programming clusters of such computers to drive even larger display walls. At home, I only have one HDMI-compatible screen, but the array of small, cheap devices attached to it is growing by the minute. In each setting, the fact that these screens are designed to be controlled and configured via IR remotes is causing me a headache.

At work my IR-remote headache is that doing any sort of action to the screens (turning them on, turning them off, adjusting them) requires pointing the remote in such a way as to control one of them, but none of the identically-manufactured neighbors. For all I know, maybe there's a way to pair each one with a separate remote -- but then one would have to remember which remote went to which screen, and I doubt any such pairing would allow 45-way uniqueness. Our "solution" has been to try to avoid ever needing the remotes, and to stick a paper cup around the IR emitter so that the IR remote can be shielded from all but one screen at a time.

At home, I only have one screen I want to control, but to use it with any device I need to first find the thing I use to control the device (possibly a laptop or a smartphone) *and* the remote for the TV. Mostly I only need to turn the thing on/off, change the volume, and switch HDMI inputs -- but it'd be nice if I didn't have a separate remote I always lose for those actions

I can't be the only one facing these problems. Consumers seem likely to plug an ever-increasing array of strange devices into their home television sets, not all of which even come with IR remotes, while my belief that landscape of screens in the office environment will change radically enough to make this useful in the workplace is... ...something that I am implicitly gambling on in the "startup Lotto".

And it turns out the HDMI people thought of this already. So there is already most of a solution out there, called "HDMI-CEC" for "HDMI Consumer Electronics Control" (see Wikipedia's page on the topic). But, after fiddling with it, I cannot yet get it to do everything I want.

First off, I can't send HDMI-CEC signals over any HDMI connection from a discrete GPU from a (particular manufacturer of high-end graphics cards whose name starts with "nv"). The manufacturer, apparently, believes that HDMI-CEC is a consumer feature, and is not something their high-end cards should support. I beg to differ. I write software for walls of between 30 and 45 monitors and would like to be able to programmatically turn these monitors on, and apply things like "gamma correction", "color matching", "color temperature" and other settings. I would also like to do this on a per-program basis, so that one program driven by one set of designers/artists can have one set of monitor settings, and another program, designed by a different set of people, can have a different set of monitor settings. I'd also like to be able to individually address monitor settings for such a bank of monitors so that we can write our own software for calibrating them. Or, hey, so that some third-party can write software for calibrating large banks of monitors, and for storing the monitor settings in a way that allows us to programmatically re-apply them at any time. So, if anyone reading this works at a major graphics card manufacturer (particularly one whose HDMI outputs on their discrete GPUs don't support things like HDMI-CEC), please pass this along.

Second off, it is not clear to me whether HDMI-CEC is actually capable of changing all the settings I want to be able to change. Libraries exist that allow me to send commands for on/off, input selection and volume (although the volume for some TVs seems to only work if there is an external audio amplifier, which baffles me). But there seems to be a lower level of communication available which I have not fully sat down and understood. I don't know what this lower layer is capable of, I see some menu-related messages, but it is not clear what I can do with them. I suspect I should be able to record the sequence of menu actions required to apply a particular setting on a particular manufacturer, and play these back blindly, which means that it might be possible, albeit awkward, to be able to control any monitor setting reachable via the menu system normally accessed with the screen's IR remote. But it'd be nicest to have device-independent ways to set standard pieces of monitor configuration (color temperature, gamma value, audio volume) in a way that actually works, input selection in a way that I can figure out using the HDMI-CEC tools for the Raspberry Pi).

Update

It turns out that, if I'm willing to stick with nvidia hardware only, nvidia-smi and friends will do almost everything I need. And what it doesn't do, I don't need to do for the massive display arrays I deal with at work (I have no need to individually power monitors on and off there, audio goes over a separate channel, and I have no need for input switching)

For home use, HDMI-CEC remains just barely inadequate -- but, hey, maybe buying a newer TV (and an external audio system) would fix the problem.

Sunday, August 9, 2015

A quick guide to visiting Downtown Los Angeles

When friends have visited LA, I used to give them a list of pieces of advice. Since then I've shifted to stating that I would collate my advice-to-visitors into a blog post, and forward it to each new visitor. I have yet to do that. But since this coming week is the week of SIGGRAPH, and many people I know are likely to be, not only in LA, but in the one part of LA I know well enough to give advice about, I feel it is time to finally write this up.

One of the problems to giving visiting advice for LA is that the "city" is actually comprised of many different subcities, visitors will want to visit sites scattered among many of them, the realities of traffic mean that one should not plan to visit sites in two different sub-cities in the same day, and the only areas I'm sufficiently familiar with to give advice on are Downtown, East LA, the San Gabriel Valley, and Orange County. This completely omits Hollywood, Mid-City and the Venice / Santa Monica areas, all of which are places any tourist should visit. Luckily SIGGRAPH (held next week) takes place in Downtown LA, meaning that I have a whole raft of acquaintances who primarily care about downtown.

Transit If all of your LA destinations, other than the airport, are downtown, you can get by using public transit alone. General schedule and route information can be found at a variety of places, but the first thing you're going to want to do is to travel from your airport of choice to Downtown LA.

    If you are flying into
  1. LAX : You should take the LAX Flyaway bus to "LA Union Station" LAX flyaway bus
  2. Ontaria Airport : Take a cab to the Rancho Cucamonga Metrolink Station. From there, take Metrolink to "LA Union Station"
  3. Burbank Airport : I have no idea.

By car If you do choose to arrive by car (and brave parking and traffic), you will spend a good chunk of time stuck in traffic. My only advice to you is to reprogram your car radio such that one of the stations is FM 89.8 KCRW. LA has other radio stations as well, pick them according to your musical tastes. But prepare to be disappointed by those that purportedly play the genres of music you like (unless you are into hip-hop, which has historically been big here).

Getting around downtown If you're pressed for time, there is a nearly-constant swarm of Uber cars. I'm sure the same is true of Lyft. Downtown is the part of LA that is best-served by public transit. You'll probably want a TAP card if you're doing this. I personally prefer to explore downtown by bicycle, but locking up one's bike safely can be a bit of a nightmare.

Things to visit downtown. The following points of interest are worth stumbling into once or twice.

  1. LA Union Station. I wouldn't go out of my way if you're going everywhere by car : but if your'e going by public transit, you'll probably end up here anyway. Take a look around. It is a beautiful building with fascinating crowds.
  2. Grand Central Market : A variety of food and grocery stands embedded within a larger building downtown. Great for lunch. It has moved slightly beyond the "gentrification sweet spot" into the edge of "upscale banal", but still beats the convention center for lunch.
  3. LA Centra Library : Kindof a nifty old building. Closer to the convention center than the other places I'm mentioning : http://www.lapl.org/branches/central-library.
  4. Last bookstore LA : Don't pretend you don't have a use for a stack of used sci-fi novellas for your plane flight back to wherever you came from. http://lastbookstorela.com/

Where to eat. Lunch near the convention center is likely awful : but LA is emerging as a bit of a foodie city. Here are neighborhoods and destinations I can recommend.

  1. Grand Central Market : Google maps says this is a 33 minute walk from the convention center. I'd advise using public transit instead, which Google tells me takes 15 minutes. I don't know what the intervening neighborhoods are like, as I rarely travel near the convention center.
  2. Little Tokyo : If you're stuck at the convention center, it can be kinda tight to get here for lunch. But the ramen joints are well worth the effort, and it is an extremely compelling place to have dinner. I will not reveal my favorite ramen joint unless you are visiting me for dinner (partly because I only know its location, not its name), but my runner-ups include "daikokuya" and "shin-sen-gumi". Sushi is also available in this neighborhood.
  3. Boyle Heights : Famous for Mexican food. Food destinations should be clustered around "Guisado's tacos", near the "Mariachi Plaza" stop on the LA Metro Gold Line. Parking is plentiful.
  4. San Gabriel Valley : By public transit : The San Gabriel Valley is LA's suburban Chinese-American enclave, and arguably has some of the best Chinese food in North America. If you are going by transit, you probably want to take the 487 bus (or 489 bus) from LA Union Station to Del Mar and Marshall (or Del Mar and Valley). There are quite a few shopping plazas around there that are full of Chinese restaurants, very few of which are bad. I particularly recommend "Sam Woo". The third floor of the shopping plaza containing a "Daiso" store and a "Focus" store has an excellent dim sum restaurant (whose name keeps changing). Bear in mind that dim sum stops being served at the end of lunchtime. Those wishing for dim sum for dinner are likely out of luck. An alternative to the 487/489 is to take the LA Metro Silver Line express bus to El Monte Station, and then to take an Uber or a Lyft to your final food destination, which is an excellent way to reach Din Tai Fung. The area around El Monte station itself is not too interesting : it will take a car trip to get from there to where you want to eat. The 487/489, on the other hand, drops you immediately in the middle of a dense shopping-district full of restaurants.
  5. San Gabriel Valley : By car : If you are going by car, different parts of the SGV open up. For instance, one of the best dim sum restaurants in the area, "Ocean Star Seafood" in Monterey Park, is difficult to reach by public transit, but is easily accessible by car. Parking nearby, while non-trivial, is free, and normally feasible.
  6. Koreatown, mid-city, Hollywood, whatever -- I know there are good places to eat in these neighborhoods, but I don't know where they are. Sorry. The best I can do is advise you to look up whatever Jonathan Gold has had to say about these neighborhoods
  7. LA's so-called "arts district" -- a better destination for drinks and entertainment than for food. If you're headed there and you know me, give me a call. Get there the same way you would get to "Little Tokyo". It has a sausage restaurant as well as vegan and vegetarian options.
  8. Chinatown : If you have a car, don't bother. It'll probably be just as quick to hop on the 10 Fwy headed east, skirt around downtown, and wind up in Monterey Park, which has better food (take the Atlantic Blvd exit off the 10 and head south). Plus Monterey Park has parking! If you wind up here anyway, "Empress Pavilion" has decent dim sum, there is a Sam Woo, although I'd almost advise going to Olvera Street or Phillippe's instead.

Thursday, May 14, 2015

Folding bicycles, wheel size, stability

One of the problems with public transportation in many American cities is the problem of how to get the last 2 miles from where your train / express bus / CalTrain stops to where you're actually trying to go (equivalently, how to get from your starting position to your train/bus stop). In some cities the solution is to take a different bus/train line and transfer : but in Los Angeles County and in Silicon Valley this is often untenable, and can turn a 20-minute ride on an express bus into a multi-hour transit saga.

A frequently proposed solution is to take one's bicycle on the train/bus. This works somewhat well for trains, but busses (I live close to an express bus line) in Los Angeles County tend to have only two slots on the front of the bus for carrying bicycles. If those are full when you catch the bus, you're out of luck. At certain times of day, even trains will restrict the number of full-sized bicycles that can be brought on board.

One way around this is to use a folding bicycle, such as the one pictured above. Conceptually it is great, and it makes a bike-and-bus commute feasible for me that would otherwise be difficult or unreliable. But it has issues.

On the one hand, it is difficult to fit under the seat. The Metro web page states Folding bikes with 20 inch or smaller wheels can be taken on board. Make sure your bike is folded and stored under a rear seat so as not to block aisles and doorways. . This is difficult and awkward. The size of the bicycle when folded (as can be seen from the pictures above) is dominated by the size of the wheels.

On the other hand, the stability of the bicycle (and its ability to handle rough terrain) affect its ability to go fast. Already riding my 20-inch-wheeled folding bike feels sluggish and unstable compared to my full-sized bicycle

So how might one try to go about making a folding bicycle more stable while reducing the size of its wheels? Here is a proposal.

For lateral stability it turns out there has been some interesting recent work on what makes bicycles stable. This video shows a small-wheeled bicycle that rides stably, without the help of trail or angular inertia. Further details on this work can be found. The authors even mention folding bicycles in their excellent TED talk.

For stability going over rough terrain, potholes and curbs : NASA has already faced the problem of making a lightweight vehicle that can be folded into a tight package and retain the ability to traverse large obstacles. Their solution for many of the Mars rovers was the rocker-bogie suspension system. It is not designed to go at high speeds, and may have neglected dynamic stability : but it may be a good start. Note that a "bicycle" designed with such a system might end up having far more than 2 wheels.

Neither of these, by itself, constitutes a "solution" to the problem of making a stable folding bicycle with small wheels capable of riding over rough terrain. But hopefully it provides a direction. And maybe it'll bring us one step closer to Richard Register's desire for cities built around transit and bicycles.

P.S. for graduate students, inventors and entrepreneurs in the United States it may not be completely implausible to get funding from DARPA to develop better folding bicycles