Configuring Microsoft Sculpt Keyboard for Mac

I like the Microsoft Sculpt ergonomic keyboard, and here’s how I’ve configured it to work well on my Mac:

In System Preferences->Keyboard select “Modifier Keys…” and enter these settings – be sure you’ve selected “Microsoft Nano Transceiver” at the top:

Screen Shot 2016-03-22 at 9.25.03 AM

I’ve remapped Caps Lock to Escape using Seil because I’m a vim user, so you can ignore the Caps Lock setting if you actually use Caps Lock as Caps Lock.

Now the Sculpt keyboard’s Alt key is like the Apple key, the Windows key is like Alt/Option, and Control is unchanged.

Additionally, I wanted to use the Sculpt’s Home and End keys to actually go the the top and bottom (or start and end) of things, so I installed Karabiner and selected For PC Users->”Use PC Style Home/End #2″:

Screen Shot 2016-03-22 at 9.34.53 AM

I hope that works for you, too!

Announcing a New Embedded Software Site: Embedded.fm/blog

I’m excited to announce that Elecia White, Chris White, Andrei Chichak, and I have started collaborating on a new embedded software engineering blog over at Embedded.fm/blog.

It’s slightly related to the Embedded.fm podcast because it’s about embedded software and embedded systems, but most the content will be separate from the podcast.

Andrei and I will both be writing about getting started in embedded systems (using two completely different approaches), Elecia will be sharing excerpts from her upcoming book about taking apart toys, and Chris White will be talking about various projects. Hopefully there will also be entertaining embedded-ish rants.

Please stop by and check it out! I’ve had a blast reading pre-published stuff that will show up on the blog, and I hope that you’ll enjoy it too.

Why C Arrays Start at Zero: I Don’t Know.

Why do C arrays start at element zero? It’s probably not why you think.

Mike Hoye did a detailed investigation here: http://exple.tive.org/blarg/2013/10/22/citation-needed/

The TL;DR is that Hoye says most programmers think C has zero-indexed arrays because the creator of C chose zero for the run-time efficiency of pointer and array arithmetic. Hoye says this is wrong; he claims that C uses zero-indexed arrays because its predecessor BCPL used them, and that BCPL chose zero-indexed arrays for compile-time efficiency. (I’m not convinced by his technical arguments, by the way, but that’s beside the point I’d like to make.)

The history of zero-indexing is interesting if you enjoy reading about the history of programming languages. Otherwise it’s hardly notable.

Except.

Except you probably thought you knew why C arrays start at element zero. “Well, it’s because pointer and array math are efficient when starting at index zero.” If asked, you’d probably say it confidently, definitively, as a Fact with a Capital F. You might even be correct, but you’re only guessing.

Hoye goes on to say that programmers who think they know something as Fact without actually knowing it are living in a “mythology.” They’re fooling themselves and others.

The honest answer to “why zero?” should probably be “I don’t know.” Perhaps followed by, “I think it makes some pointer and array operations more efficient at the machine level, but I don’t know why Dennis Ritchie chose it when he created C.”

We don’t use the phrase “I don’t know” often enough. Maybe we’re afraid of being thought of as dumb or ignorant or more junior than we want to appear, or maybe we’re afraid of being found out as impostors.

Recognizing and admitting your ignorance is one of the fastest ways to learn. Recognize and admit when you don’t know something, at least to yourself.

Why did it take me 20 years of being a software engineer to realize how important this is?

I don’t know.


 

I wrote this piece for Embedded.fm (http://embedded.fm/blog/2016/2/9/why-c-arrays-start-at-zero) and am cross-posting it here.

Fred Brooks talk: “A Personal History of Computers”

I was lucky to see Fred Brooks give a fantastic talk called “A Personal History of Computers.” Dr. Brooks is legendary computer scientist and author of “The Mythical Man-Month,” which, if you’re in the computer industry in any capacity, you should read, think about, and then re-read at least once a year for the rest of your career. (His newer book, “The Design of Design,” looks promising as well, though I haven’t read it yet.)

Dr. Brooks is 84, and his highly entertaining and personal talk walked us through his history with computers, which is basically most of the history of computers. Here’s his abstract:

I fell in love with computers at age 13, in 1944 when Aiken (architect) and IBM (engineers) unveiled the Harvard Mark I, the first American automatic computer. A half-generation behind the pioneers, I have known many of them. So this abbreviated history is personal in two senses: it is primarily about the people rather than the technology, and it disproportionally emphasizes the parts I know personally.

And here’s a video of the same talk that he gave elsewhere: http://www.heidelberg-laureate-forum.org/blog/video/lecture-tuesday-august-25-2015-fred-brooks/

I took two things away from the talk:

  1. Nothing ever changes.
  2. Everything changes all the time.

Nothing ever changes. Brooks discussed two works that he called the most important computer papers ever:

  1. “Preliminary discussion of the logical design of an electronic computing instrument,” a paper by Arthur Burks, Herman Goldstine, and John von Neumann.
  2. “As We May Think,” an essay by Vannevar Bush.

The von Neumann paper describes, in detail, how modern computers work. Bush’s essay describes, in detail, how modern networks and the internet works. They were written in 1946 and 1945, respectively. They were both so fundamentally brilliant, visionary, and practical that we haven’t been able to (or had to? or wanted to?) improve much on them in the last 70 years. Nothing ever changes.

And yet, everything changes all the time. Brooks spend his early career at IBM, which designed mainframe computers. Mainframes were physically huge and economically expensive, and were bought (or leased) and run by large companies, universities, and governments. At first mainframes were the only type of computer around. If you were a scientist or researcher who wanted to use The Computer (your company or university had at most One Computer, if you were lucky!), you had to use it according to how the high priests who controlled The Computer dictated. You had to share it with every other Department in your organization.

Minicomputers changed the sociology of the One Computer when they were introduced in the mid-1960’s. Minicomputers were smaller and cheaper than mainframes, and could be bought and run by mere Departments. Minicomputers changed the social and organizational dynamics of who could use The Computer; now each department or group could have their own computer to use as they liked! This quote in John Markoff’s new book “Machines of Loving Grace” sums it up well:

Computing was now sneaking out from behind the carefully maintained glass wall of the corporate data center and showing up in the corporate office supplies budget.

The microcomputer’s introduction in the 1980’s changed the sociology of computing again, this time making it possible for a person to have their own computer! “Personal computer” is a throwaway phrase in 2015, but when the personal computer was introduced it caused a massive change in how computing, and therefore work, was done.

Brooks said that now the sociology of computing is changing again as we have smart phones, watches, and other increasingly ubiquitous computing devices available.

And yet, nothing ever changes. At each transition point, Brooks said the companies that were successful in the current popular technology were too “fat, dumb, and happy” to reinvent their products or businesses to be successful in the new technology. They were “culturally not geared for” making the transition.

He didn’t use the words “disruption” or “disruptive innovation,” but what Brooks described was popularized as “The Innovators Dilemma” by Clayton Christensen in his book of the same name. Apparently each disruptive new era in the history of the computer came about in the same way as the previous ones.

It was great hearing about the history of computers from someone who had personally been there for most of it, and who knew many of the key players personally. I highly recommend watching the video (linked above) and reading “The Mythical Man Month,” as well as the von Neumann and Bush papers.

Business idea: Amazon Cloud Printing

Here’s a free business idea for Amazon: AMAZON CLOUD PRINTING.

It solves the problem of people who need a high quality printout without having to buy an expensive commercial printer or drive to a copy store, like an animal.

Here’s how it works:

  1. You request AMAZON CLOUD PRINTING online.
  2. An AMAZON DRONE flies an AMAZON LARGE COMMERCIAL PRINTER to your location.
    • Please open the window first, and then demolish the wall. It’s a big printer. You’ll have about 10 minutes to do this after submitting your AMAZON CLOUD PRINTING request. AMAZON CLOUD PRINTING is not responsible for damage or injury.
  3. The AMAZON DRONE waits for you to plug in the AMAZON LARGE COMMERCIAL PRINTER and load it with AMAZON COMMERCIAL PRINTER PAPER (not included).
  4. The AMAZON DRONE waits for you to unplug AMAZON ECHO, if present. AMAZON DRONE requires all of your attention. AMAZON DRONE is all you need.
  5. The AMAZON DRONE takes the file to print from you on an AMAZON USB THUMB DRIVE.
  6. The AMAZON DRONE prints the file on the AMAZON LARGE COMMERCIAL PRINTER.
  7. The AMAZON DRONE hands you the printout.
  8. You pay the AMAZON DRONE.
    • Cash only. No change given.
    • The AMAZON DRONE will count the money in front of you.
  9. The AMAZON DRONE then enters its WAIT-FOR-TIPPING mode.
    • It remains in this mode until you tip it, or until the INCENSED-DRONE-TIMEOUT is reached.
  10. Depending on the WAIT-FOR-TIPPING mode outcome, the AMAZON DRONE leaves with the AMAZON LARGE COMMERCIAL PRINTER using the original entry point, or a new one.

You’re welcome.

Moving to chrissvec.com

I’m in the process of moving from http://saidsvec.com to http://chrissvec.com.

When I created the original “Said Svec” site I thought it was a clever name, like, “stuff that Svec said,” you know? It turns out it’s confusing though – some people think my name is Said Svec, instead of Chris Svec. It’s an ambiguous site name, which is too bad, but fortunately chrissvec.com was available, so here we are.

Expect lots of churn as I import the old site here get it ready for production.

Empathy Driven Development slides

Here are the slides from my Embedded Systems Conference 2015 talk on Empathy Driven Development:

Empathy Driven Development slides (pdf)

The slides include a rough transcript of what I said.

I had a great time giving the talk and discussing it with others at ESC.  I’ve given this talk a number of times for software engineers, electrical engineers, mechanical engineers, and a few mixed groups as well, and I’ve learned that it applies to almost any engineering group.

I’ve had a few requests to give the talk for people’s teams & companies and to explore what it might look like in your particular environment, which I’m happy to do. Please email me at svec@saidsvec.com if you’d like to arrange a visit to your user group/meetup/team/company.

Thanks!

 

Edit: I reduced the pdf file size (and image quality) so the pdf is now 2MB instead of the previous 50MB.

Empathy Driven Development talk at ESC Boston 2015

I’m excited to be giving a talk about Empathy Driven Development the Boston Embedded Systems Conference!

The talk will be on Wednesday, May 6 at 2pm. Get all the details here: http://www.embeddedconf.com/boston/scheduler/session/why-empathy-driven-development-is-not-just-some-touchy-feely-new-age-fad

You can come to the talk for free if you register for the Demo/Exhibit pass.

You can hear more about Empathy Driven Development in this interview I did with Elecia & Chris White on their Embedded podcast: http://embedded.fm/episodes/2014/11/24/78-happy-cows

Empathy Driven Development interview

I was interviewed about “Empathy Driven Development” on the Embedded podcast: http://embedded.fm/episodes/2014/11/24/78-happy-cows

“Empathy Driven Development” is my attempt at making software engineering (and other types of engineering) better, specifically for the engineers who do the work. Very early thinking, but I think the interview went well!

I’ll be writing more about Empathy Driven Development here in the future, so stay tuned.