serproxy random crashes

For those of you using serproxy.exe to convert serial IO to TCP messages for serial port communication with Adobe Flash scripts, I would avoid using a USB to Serial adapter if at all possible. Stick with the serial port on your motherboard, if you have a desktop computer that still has one.

As I found out while working on some pieces for OMSI's Design Zone exhibit, 2-4 hours of constant serial communication can cause USB to Serial Adapter drivers to raise unhandled serial port errors, thus locking serialproxy.exe, and breaking communication from the Adobe Flash Movies I created to the hardware.

If you are in a situation where you need to use a USB to Serial adapter, the next step would be to update serproxy.exe to properly use ClearCommError() to constantly clear out errors. Without this, writefile() (the function call that communicates directly with the serial port driver) will crash serialproxy.exe.

Computer Game Remake?

No blog post in awhile. From now I will try to do a better job of kicking my butt into productivity mode.

Today I listened to the first "Triangulation" podcast, and was struck by how cool Warren Spector (a top computer game designer) is. After discussing Wing Command and some of his earlier games, I was sent down memory lane to my childhoold computer games. ____ Quest, Wing Commander, Rastan, the list continues. Warren, who also is trained in cinema, talked quite a bit about movies; specifically movies based off of computer games and comic books.

This discussion spured an idea: why don't they remake old computer games? This has been the theme the past 5-10 years in cinema. Examples include Indiana Jones, Star Wars, Tron, and apparently Ghost Busters soon. Why doesn't someone buy the rights to old Sierra games and remake them? I (and several others I can think of in my generation) would snap these games up in the heart-beat. Now that I have a little 9-month old, I'd love to (at some point in the near future) introduce her to modern versions of the games I played as a child.

I don't have the time nor the money to try to capitalize on this idea, so someone with money--please roll with this.

As a side note, I am surprised to say that I actually want to buy the Epic Mickey game they discussed. It sounds super neat to go back in time to all off Disney's old school cartoons that people have forgotten and save some of the characters.

Functional vs Performance Requirements

"Performance Requirements are about criteria and meeting criteria, Functional Requirements are about describing how a system behaves."

I think I agree with  that statement.

So for example, a Performance Requirement could be:

The laptop shall withstand shock of 20g's (good laptop!).

The criteria we are talking about is shock. To verify this requirement, we would measure the end product against this criteria, and see if it meets it.

A functional requirement:

The add button shall sum the values in fields A and B and present the result in field C.

We are describing how the end product will function, or (in other words), we are describing the end product's behavior. To verify this requirement, we would exercise this functionality and observe the results.

A Use-Case is not a Requirement

A small conversation from a past interview has popped back in my mind. The interviewer told me how important use-cases are when going from high-level requirements to the actual software that you write. I completely agree with this, and to this day I am kicking myself for not saying this first. I have a feeling the person interviewing me was seeing whether or not he could lead me to discuss the importance of use-cases and my experience developing them, but for some reason it didn't quite come to me.

Anyhow, amongst discussing use-cases, I asked him whether or not a use-case is a requirement. I recall (although my memory is a bit fuzzy) that he said it wasn't a high-level requirement, but a derived, lower-level requirement, or specification that gets into implementation. I nodded, but realized that I didn't necessarily agree with this (again I am kicking myself for not stating this out-right).

Requirements
A requirement is a nugget of information that describes a characteristic that a system must fullfill. A derived requirement, or specification, breaks down these morsels of information further, and typically has a "consists of" or "satisfies" parent-child relationship[1].

Requirements can be indexed, reused, and (importantly) associated with other requirements. The end result, a database of associated requirements, can be divided up and used to generate all sorts of things, including the end-deliverable, project plans, and work break down structures. That is why good requirements and specifications, along with whatever tool presents and manages them, are so powerful. They drive not just the deliverable, but the entire project.

Use-Cases
A use-case is not a requirement. A use-case is a sequence that involves an actor, start conditions, and an end condition. Like requirements, they describe a system. But although they most likely they will help determine requirements, they are not requirements themselves. They are more than just a nugget of technical information.

Depending on the actor, a use-case can help describe any level of the system. If the actor is the end-user, the use-case will help clarify and create the highest-level requirements. If the actor is a class, code module, or process, it will help clarify and create how lower-level derived requirements. So a use-case can describe and develop both how a system must behave, and how it will work.

Here is an example; a use case linked to higher level requirements.

A Use-Case
1. The end user opens the door to the aircraft.
2. The end user sits in the seat of the aircraft.
3. The end user press the on button button on the dash of the aircraft.
4. The aircraft engine starts.

Start Condition: Aircraft is off and unoccupied
End Condition: Aircraft is on and occupied.

A Requirement
1 The aircraft shall allow the pilot to turn on and off the aircraft.

But more Useful, a set of Associated Requirements:

1 The aircraft dash shall allow the pilot to turn on and off the aircraft.
1.1 The aircraft engine shall turn on when the on and off button on the dash in the down position.
1.2 The aircraft engine shall turn off when the on and off button on the dash is in the down position.
2 The aircraft shall have room for one pilot.
2.1 The pilot of the aircraft shall weigh less than 300 pounds.
2.2 The aircraft shall have a cushy leather seat.
2.2.1 The cushy leather seat shall cost less than $1000

We can see that

• A use case is different that a requirement.
• A use case helps create requirements.
• A use case can help create any level of requirements.
  

[1]As a side note I have seen cases where folks will refer to a requirement as a "specification" if it has a "satisfies" parent-child relationship, and as a "derived requirement" if it has a "consists of" parent-child relationship. In general I think all systems can be broken down into a requirements hierarchy, and where you draw the line between "what is needed" and "what fulfills" is arbitrary and depends on context.

What were you thinking Intel?

Whenever I see an amazing product driven by an ARM based processor, I continually ask myself why Intel sold off its line of ARM processors (known as XScale) to Marvell. Here is quick recap for those who aren't familiar with ARM versus Intel's x86 based CPUs:

ARM
ARM is not a chip maker, they are a software company. The software they write is a little different though. It is called a Hardware Description Language. This means that its end purpose is not to be interpreted by a machine, but instead to define a machine. Other companies that make computer chips can take the software definition for the ARM CPU core, license it, customize it, then fabricate it. This provides flexibility in what ARM based CPUs are, the end-customer decides what comprises it.

x86
The word "legacy" best describes x86. I was around 10 when I first used an IBM compatible x86 based computer. Since then the processor been upgrading via duck tape and all sorts of complex modifications in order to improve speed but maintain backwards compatibility. The end result is that I can still play the computer games I played when I was 10 on my PC.

Although x86 chip makers (Intel and AMD) over the years have tried to simplify the architecture, x86 processors have to do more "stuff" in order to maintain both backwards compatibility, and compatibility with Windows. This stuff consumes power, which is why you haven't seen anything smaller than netbooks driven by x86. The more power a CPU consumes, the larger the device using it has to be.

Because the desktop PC market has saturated, and smart phones are taking off, Intel really should have kept their ARM processors. They already had an edge in the market; Blackberries, one of the top iPhone competitors, are powered by xScale CPUs. But instead Intel sold off the processor line. They are restricting themselves to netbooks, laptops, and desktops. Why?

Irony

Has anyone ever noticed how ironic the name of the win32 error code #0 is?

Some Ships Leak from the Top

I marvel at those who have the ability to not speak. It is true, Information is Power, and the more you say the more power you give. I think salesmen know this, so knowing when not to speak and what not to say to them is key. The best know how to make you talk.

The first step is being comfortable with the uncomfortable silence. So easy to say, but so hard to do.