Actors as a new model of computing

I know, I have not posted for way too long. Honestly the news on multicore sort of dried up. It is like we slipped into a hype cycle black hole.

Anyhow, as I was recently laid off from the day job, I have some extra web surfing time. I found this video on the actor model of computation. For a little background, here is the Wikipedia on the Actor model.

Let me warn you, this is geek porn. Three very smart people talking very deeply about deep computer science. The guy quotes Dijkstra and says he is wrong.

I sat transfixed for 45 minutes. If anyone finds a link to the book he mentions, let me know. I could not find it on Amazon. The ideas all relate back to an event driven mulitprocessor system. The idea of actors takes it further, many of the concepts are familiar and related. It is even more interesting to find this was out there and published for a couple of decades. Nothing new in the world I guess. I need to research and understand the ideas around inconsistency they discuss towards the end of the video.

Some further research found a number of papers by Carl Hewitt. He mentions which has a paper.


Founder Institute Graduation and me.

I have graduated from the Founder Institute Summer 2011 Denver class. Making that statement is huge.

Honestly, I can say I have learned so much in 90 days. None of the learning has been easy. Some of it does not apply to me and my start-up today, but it will in the future.

The mentors were great. If anyone reading this is in FI, or thinking about applying, here is one piece of advice. Take advantage of the access to the mentors. These are people who have started multiple companies and are currently running start-ups.  Talk to them, ask them difficult and stupid questions. Everyone really wants to help and make every founder a success. Do to a busy life, kids, and a day job, I did not talk to the mentors enough. Finally I had to take some sick days to visit with them in person. It was worth the time and effort.

The effort on homework is not small. Again, do the work and you will get the benefits. The things I have learned apply to my day job, and to my start-up. I am now an educated founder. As a technical guy, learning about the business side was great. All the things that I worried about just because I did not understand have been resolved. I have at least been introduced to hiring, raising money, lawyers and more.  This type of education is better than an MBA. It is an education in the way these things work in the real world.

So, I have graduated. I am still recovering and catching up at home and work. In the next few weeks expect more posts on the blog for Cloud Firmware.

Founding a company

In a previous post I said I was accepted to The Founder Institute. If you are interested in founding a company, just read the site there is an amazing amount of information available for free.

The Summer Denver 2011 class is two weeks from graduation. I am still part of the class, and am a founder now.

I have incorporated “About Five Technologies”, a Delaware C corporation. As of today I am the sole stock holder and the entire board. That may change soon, as I am seeking a co-founder or partner.

The product I am working on is Cloud Firmware. If you are interested in the company’s progress or embedded software, please sign up with your email.

Smart-grid Security


My current day job is working on ZigBee devices integrating with smart-grid power meters. So I follow the industry. If you want to keep up with the news of the day put FreakLabs Open Source Wireless into your RSS reader. They aggregate the news of the day.

They linked to Smarter hackers lurk in smart-grid future a post about smart-grid security from Greenbang.  As a smart consumer, you and I both know the only way to sell security is by generating fear. We all buy virus protection because we fear our computer will get powned. We lock our doors at night because we fear a break in.

In the article they put up the straw man argument that a hacker could bypass multiple layers of security, understand unusual and proprietary wireless protocols, and then break into your house.  I have to say “WHAT!?!?!?”.

Stop using the intruder argument for security. A sophisticated hacker decrypts RSA keys, then uses a crow bar to break down the door? Really? No, I mean really? How about  just watch the house and see when you drive away. That seems easier than running a network sniffer and decoding keys.

To be fare, the article uses the intruder as an example, then warns that there a bigger security issues. Major things like mass power outages and Stuxnet viruses should be the focus of security.  The “your not home so someone will break in” example over simplifies the issues and needs to stop. Please, please if you found this in your search to write a network security article do not imply that someone may break into my house because of my smart meter.

A better hack

This was in the back of my head while out walking yesterday. I thought, “if you could hack the network, what would you really know?” How often I run the dishwasher? BFD. That led me to a much better hack.

Please, do not come and arrest me for posting this. My point is not to enable crime, just to point out the folly of security theater. Schneier on Security is my role model here.

OK, so lets pretend we are real sophisticated crackers. We want to make money from the smart-grid role outs in our town. So we start hacking the utility systems. That seems hard and as a cracker, I am mostly lazy.

Instead, let’s send out some spam. Spam is easy. The spam says (I am paraphrasing here.):

I am the evil smart meter cracker that the utility warned you about. Do as I say or I will mess with your meter, cause a power outage and give you a giant electricity bill!

Pay me $5 per month and I will change your meter settings to save you $20 per month. The utility is just trying to screw everyone, so lets stick to the man. For $10 I will save you $30. More than that is dangerous and we may get caught. Don’t tell anyone, see above.

Send payment to my overseas criminal account (or use bitcoins) details here.


Smart Grid Cracker

Now, here is the beauty of it, don’t change a thing on the meter or smart grid. If the cracker actually has access, then they can send monthly emails saying “You bill is for X it was X+$20 before I changed it, we are sticking to the man!!”. This scam can work with absolutely no network access, just a spam email system.

Now, please tell me how much encryption to use inside the network to fix this huge security hole?

“Two and a Half Men” super soap opera twist ending

Because Frank left a comment, I now have to reveal my super soap opera twist. I know Frank pretty well, and am very sure he is proud of the fact that there is one more piece of useless content on the Internet because of his comment. (I’m kidding of course.)

So, when we last left off the Two and a Half Men cast was having fun with Ashton K. as Judith’s new love, Herb and Alan living in the beach house in Malibu, and we added Judith’s daughter to the cast. The daughter is the key to this twisty turning plot.

The writers have kept us in suspense about who is the baby daddy of the daughter. It could be Alan or it could be Herb. There have been many times we almost found out the truth, but it remains a mystery. For 2-3 seasons they have kept us in suspense (if they are any good and smart). Now the truth is about to come out.

Someone, it does not matter who decides to get DNA samples and do a test. I think the best character would be Evelyn, Alan and Charlie’s mother. It is just the sort of thing she would do. The testing is a big secret, so the samples must be taken without the victims (Alan and Herb) knowing anything is going on. Evelyn can get Jake to help, for more fun.

The secret is, of course, not a secret. Everyone knows. They then start to swap samples. By the end, no one is exactly sure which sample is the true one. Lots of sneaking around and almost getting caught physical comedy. Really, it writes itself.

Now, lets add the twist. The last switcher is the daughter. She swaps out the sample she believes is her father, Alan’s, for Ashton’s DNA sample. It is a bitter sweet moment, as she is trying to keep both her fathers happy, by keeping the true biological father secret. That is the season ending cliff hanger.

The super soap twist is next, and I think you can see it coming from a mile away. In the season premiere, we get the results. The real father is… Ashton K. (whatever they name his character). Only the daughter knows of course. Now the whole plot starts to unwind. We review each and every switch and swap. The truth all comes out. Finally, Alan and his daughter have a moment alone. He thinks he is the father, Herb is OK with it. She knows the truth. Does she tell him? Does she tell Ashton’s character?

Hey, they have to write something for themselves. I am not doing someone else’s job for free.

Requirements that work

Two posts on Requirements. Two! This guy must be a major process weenie!

No, ask my friends, I am not a process weenie. Getting the requirements is the first step towards a successful project. Do this right and the rest flows like fine wine. Do it wrong and the project is a Death March to hell.

The requirements document is the root document for the whole project. From this one document, the engineers figure out what to build, and how long it will take, the marketing people figure out how much to charge, and the users figure out if they want to give you money. It simply has to be right.

Everyone who read the email had a vision in their head about the CarNet Player. You probably pictured it in the dash of your own automobile. I am also 100% confident none of us had exactly the same picture. The requirements will remove the variation in each persons mental picture until will all see the same thing. They help us remove ambiguity.

Here are my suggestions. Nothing will make this easy. Did I mention Requirements are hard?

  1. Read the books! Read them now, not while you are under pressure to produce the document.
  2. Take all the time you need. We can not do a schedule without the requirements? SO make a schedule to research, interview, and write the requirements.
  3. Requirements are Unlimited. Yes, unlimited. Reach for the moon, ask for everything and leave no crazy idea out. If you can not implement cold fusion, it is OK. We will trim the possibilities later.
  4. Get the right People. First, don’t get the entire engineering, marketing and sales team together in a big room and announce the next great thing. Get a few people who represent each group and start the process. When you have the requirements specified, you can actually answer some questions about the next great thing. The big announcement will go much better.
  5. Keep the requirements and business case separated. Most people think it is good to keep the requirements separate from the functional specification. We don’t want technical details in with the requirements. Along the same lines, keep the business case out of the requirements.
  6. Don’t confuse features with functions. Requirements specify functions. Playing audio is a function of the CarNet Player. Playing an MP3 format file is a feature. Specifying features limits the implementation.
  7. Don’t make a Swiss Army product. Products that do one thing and do it well work much better than all things for all people products.
  8. Ask inside the company first. If, like me, you are starting from scratch, there is no one to ask. If you are in an established company, interview the people you work with. Customer service is the best place to start. They will definitely have a list, and be glad to share. Sales, manufacturing, engineering, even the billing people in accounting should be considered. These people will want to talk to you, not just say ‘whatever’.
  9. Use a tool. If you have access to one, use it. Learn the language of the tool and use it well.
  10. Test the requirements. Do a review, walk through and formal review.
  11.  Put the requirements under change control. Once you have version 1.0, don’t make changes without reviewing them. At the root document a requirement change will change many other realted documents. Use a traceability matrix to keep track of related documents.

Use Functions, Attributes, Constraints, and Preferences

This is taken from Exploring Requirements: Quality Before Design by Donald C. Gause, and Gerald M. Weinberg. Their way of classifying requirements is very helpful.

A function is the what of a product. It describes what the product will accomplish. These are the actions the product performs. For example, the CarNet Player must be able to play audio. Playing MP3 format files is a feature. Separate functions would be how it gets the audio, stores the audio, and so on.

Functions are classified as evident, hidden or frill. An evident function would be that the player must fit into a car.

Attributes are desired characteristics. These describe the product. Things like user-friendly, reliable, manufacturable, safe, and low power are attributes.

Classify attributes into Must, Want, and Ignore.

Constraints limit attributes. These are the testable items in the requirements. An attribute the product must have is limited by the constraints.

If we say the player can fit into a car, that gives a lot of leaway. Something that plays music and fits into a car would be Doug and his guitar. If it must fit into a standard size car stereo enclosure, we have constrained the size. We can put a number to it of X by Y by Z. This can be tested.

Preferences are desirable but optional constraints. Some solutions are preferable. If we can deliver all the must have attributes within the constraints we are done. That may not the the preferred solution. Preferences give us guidance. We prefer the player supports all audio formats. If it can not, we still have a product.

Make the constraints, and preferences measurable. We don’t have to know exactly what fast is, but if we can measure it we can find out.

We are done, now what?

First, test for ambiguity. Poll people about the document. When people describe the product in their own words, do they all use the same words? Are their radical differences in what they describe? If the answer is yes, back to the word processor. Schedule, number of man hours needed, and cost are good metrics to test.

Test the requirements. Do a review, walk through and formal review.

Put the requirements under change control.

Let’s Get Started

An upcoming post will be the requirements for the CarNet Player. Once that is done, we can start on the supporting documents, the design and implementing our vision. Stay tuned.

A last note
I am assuming most of my audience are engineers like myself. If you are, the next time you start a project, please get involved with the requirements. Volunteer to write them if you have to. At least try to be on the team. You’ll be making you life easier for the duration of the project.