Stephen Hibbert has already described his initial reaction in his blog: Working With Intel AMT: HLPAI! and I recommend that you read what he has to say. Stephen has had an, er, interesting job: learning AMT with just the SDK's documentation and samples to help him; if his response to the HLAPI is a valid gauge, then we've really done something right, which of course is pretty pleasing.

This is a "technology preview" release. What that means is that the software has been through a validation cycle and is at least "beta" quality. It also means that there may still be some rough spots. And it means that we have plans for more features.

However, what it really means is: We Want Your Feedback! Here is your chance to try something out and directly influence the development and direction of the work we are doing. Let us know what you like, what you don't like, what works, what doesn't work, and what you'd like to see next.

The way to do this is by posting in the Manageability Forums. We will be monitoring the forums to see if the HLAPI meets your needs, and to try to understand what we can do better in the future. This is also the place to report any real bugs you may happen to find. (Please give enough information so that we can reproduce the problem.) And if you like what we've done, we want to hear that too! (A little positive feedback goes a long way. :-)

The HLAPI represents quite a lot of labor; if it makes your lives easier, then it's worth it: Let Us Know!

As always, we'd appreciate any comment. We really want to know if you think this kind of content is helpful to you.

What would you like to see next?

The new e-course is available here.

We've fixed a problem in the original e-course and it can now be viewed using Firefox 1.5 and above as well.  The e-course, which provides an introduction to Intel AMT and the SDK, is available here.

What would something like this look like?  Well, for the sake of discussion let's assume that we're working in C#.  We might have an object that implements a number of interfaces, one for each significant AMT feature.  The interfaces should make it easy to program the most common use cases, and avoid forcing the programmer to have to keep track of all the gory details. So, starting with making the connection to AMT:

ConnectionInfo ci = new ConnectionInfo(hostname, username, password, tls,"",ConnectionInfo.AuthMethod.Digest, null, null);

IAMTInstance amt = AMTInstanceFactory.Create(ci);

Next, let's look at a relatively simple feature: Hardware Asset. This feature retrieves lots of information about the managed system and returns it.  It's simple because it's read-only: you only retrieve information.

The CIM classes for this feature are complex, returning lots of stuff besides just the information that is really of interest. Many of the values are encoded as integers; the programmer has to translate these values into something meaningful, like an enum.  Hardware Asset information includes things like features supported in the BIOS, the amount and kind of memory available, the type of CPU, where it's located, what kind of socket it's in, the number and types of disks, and ..., well you get the idea.

As one example, how would the class that describes the media devices (disks) look?  Maybe like this:

public class MediaDevice {

public class MediaCapabilities {

public bool Unknown { get; set; }

public bool Other { get; set; }

public bool Sequential_Access { get; set; }

public bool Random_Access { get; set; }

public bool Writable { get; set; }

public bool Encryption { get; set; }

public bool Compression { get; set; }

// ...

} // End of capabilities

// Properties of media

public string ModelNumber { get; set; }

public string SerialNumber { get; set; }

public UInt64 MaxMediaSize { get; set; }

public MediaCapabilities Capabilities { get; set; }

} // end of class

We can now print this information with a simple function call:

PrintMediaDevices(amt.HardwareInventory.MediaDevices); // array of devices

The magic is hidden inside the amt.HardwareInventory.MediaDevices property.  The implementation does all the work to retrieve the information from AMT and make it available.  Note that we haven't even said anything about the use of EOI (SOAP) or WS-Management!  The library does all the work!

There are lots of questions we could ask about this kind of thing:

• Am I on the right track here? Does this look attractive?
• Is C# the right language?  Would it be more broadly useful to provide a higher level API in Java? In C++? In FORTRAN? (OK, just kidding about FORTRAN.)
• Which features of AMT need this kind of simplification the most?
• How important is support on multiple platforms (Windows, Linux)?
• How many generations of AMT should be supported?

So. This is what I've been thinking about recently.  I (and my management!) would love to hear your feedback about this example and about some of our questions.  Thanks!

I had the pleasure of being involved in the development of this training.  As with books, and face-to-face course material, you, the end user, see only the finished product.  But behind it is a lot of work, by many people.  In this case, we had four people from the SDK group (two engineers including me, our manager, and our documentation specialist) working together with a very talented lady whose specialty is producing e-learning courses.

I have written books, and developed course material, but doing an e-learning was a new experience for me.  I particularly enjoyed working with the people on our team here – they are top notch, even if I do say so myself!

We started by simply “story boarding” the training in PowerPoint, using bulleted lists of what we wanted to cover.  Over time we filled the material in, reorganized it, reworded it, argued over it, and sat in (many) meetings weighing the phrasing of practically each and every sentence that went into the final material.  Once the basic coverage and outline were settled, our training specialist went to work producing the animations used in the training.  These too underwent evolution; the final version is much different (and better!) than the initial animations.

The last stage of producing the learning is to add professional narration; we got someone really good.  Although I had been through the material many times during its development, I was surprised at how much of an additional dimension the material acquired simply by adding good narration.

All in all, this training represents a lot of work; we think it is a worthwhile investment of our time, and we hope you will too.

We are very excited about this WBT, and we hope that all you folks out there trying to learn about Intel AMT and the SDK will try it out.  Even more important: WE WANT YOUR FEEDBACK!  Tell us what you liked and what you didn’t like, and what other kinds of WBTs you would like to see!  We are listening, really!

So, what was a long-term Unix/Linux guy like me doing in the heart of Microsoft Land?  Well, as part of the things we're looking at for the next version of the Intel AMT SDK, we want to make it easier for developers (that is, you, yes YOU out there in reader-land) to use the classes and libraries we supply in the SDK.  Visual Studio is the most-used Integrated Development Environment (IDE) in the world. Thus, if we're going to make it easier for developers to write code for AMT, in either C++ or C#, we need to look at what Visual Studio offers us for improving the developer experience.  THAT is why I was in Redmond, to learn what we can do to make life easier for you.

This was the first Visual Studio Developer's Conference that Microsoft had done that was open to the general public; previous meetings were for their Industrial Partners only (i.e., people who have paid Microsoft for help and support). I was impressed that there were a large number of the VS developers - the guys designing and writing the code for VS - there to present talks and meet with us end users.

I think this kind of interaction is great for both sides: developers need to understand directly from the users what they need, and users need, every once in a while, to talk straight to the guys building the things they're using.  Intel could learn a thing or two from this, although the upcoming Intel vPro Developer Virtual Bootcamp looks to be a good start.

So, it's all about the different roles we play during the course of our lives. While I personally like to live in the Linux and Free Software / Open Source worlds, Intel pays me to do what's necessary for its customers, and in that role, I attended the conference.

That leads me to the final part of this post. At the moment, we are still in the "thinking" stages for anything we might do with Visual Studio. While we have some ideas as to things we'd like to do with VS (after all, we also write software for AMT!), we would REALLY like to hear your ideas and your thoughts. Please feel free to either reply to me directly offline, or to leave a comment on this post with your thoughts, suggestions, or just wild and crazy ideas as to what you'd like to see in Visual Studio to make it easier to write software for AMT.

Drop me a note if you want to meet with me, and we'll see what we can do!

And on a related topic, if you have ideas about Visual Studio enhancements to make it easier to work with the Intel AMT SDK, please let me know!  I can't make any promises, but we are definitely looking at ways to make it easier for the Visual Studio user to work with the SDK.

As you can imagine, with six kids aged 9 - 16, it was somewhat, er, lively, but after enough encouragment, the kids settled down a bit and weren't quite so noisy.  We got two lanes, one with the bumpers for the younger kids, and one without for me and the older ones.

It was a lot of fun.  The bumpers are a great invention for helping kids to learn to bowl and keeping them from getting too disappointed. (I wish they were around when I was a kid!)  I used a fairly light ball and scored what I think was an all time high for me (139).  In particular, because my right arm is feeling better (see my earlier post on Chinese medicine), I was able to play much better than in the past.

No-one worried too hard about trying to teach anyone else how to bowl correctly, everyone just did tried different things, did their best, and had fun, instead of being overly competitive.  That was also great; seeing how all the kids enjoyed each others' company and encouraged each other.  It also helps that the computer keeps score, and the cute little animations are entertaining too.

Two games apeice times seven people plus shoes adds up, but it's certainly cheaper than many other activities, and just as much fun.  Bowling is also a great alternative to a day spent playing video games and watching movies, and it is also a great way to get out and do something on a rainy day.

It's something I wouldn't mind doing as a family activity more often.

Rob Pike, formerly of Bell Labs and now of Google, wrote a multi-file multi-window text editor in the mid 1980's named "sam". It is available still, and particularly at the time it was written, was way ahead of many other editors. In some ways, it still is.

In the early 1990s at one of the USENIX conferences, there was a round table on editors, and he reported that he told the following joke: Three programmers were at the happy hour in a bar. The sam user was there because he was done with his work for the day. The vi user was there because he was taking a break before going back to work. The Emacs user was there because - what else could he do? - his arms were in splints.

(For the record, I use vi [ok, vim these days], not Emacs.)

Which leads in to my point. For well over 20 years (!) I've had different levels of pain in my right hand and right arm from working on a computer day-in and day-out. In fact, I've been using the mouse left-handed for at least 20 years, even though I'm right-handed, in order to save wear and tear and pain in my right hand. (Side point: Boy does this confuse people when they try to use my computer!)

At one point, around 12 years ago, I had some physical therapy which helped some, and was given some exercises to do, which also helped. But of course, things didn't cure entirely, and it is REALLY HARD to take a break to do exercises every hour when you're trying to get work done, particularly when you're into the "flow" of software development.

Anyway, I long ago reached the point where my arm was hurting constantly, from waking up in the morning to when I went to sleep. Sometimes more, sometimes less, but all the time. Howver, it had been getting worse over the past few years. Around April, I finally decided to do something about it. I really didn't want to go to an Orthopedist; I didn't think surgery was the answer. I'd heard enough about "alternative medicine" from enough people that I decided to try Chinese Medicine (acupuncture).

I have to admit, it is weird, particularly at first, having needles stuck into different parts of you. (I should emphasize that having the needles in you is NOT painful.) Besides needles, they also use magnets, and electrical stimulation through some of the needles.

No matter how weird, though, I can't argue with the results. Today, my hand and arm are MUCH MUCH better. They don't bother me nearly as much as they used to, and I think I am less tired because I don't have the constant background pain. I am hopeful that they will stop bothering me entirely, but even the point I'm at now is like an 800% improvement over where things were just a few months ago. I only wish I had done this sooner.

To sum up: it pays to be open-minded about alternative medicine. Particularly for something like Repetitive Stress Injury (RSI), if you suffer from it, try visiting a good Chinese Medicine practitioner before running off to a surgeon.

As a result of giving my teenage daughter the classic Dragonrider books by Anne McCaffrey, she has become an averous science fiction reader.  The problem is keeping her supplied with enough things to read that are also appropriate for her age.  To this end, I recently pulled out a volume of collected books by Isaac Asimov: The Foundation Trilogy, The Stars Like Dust, The Naked Sun, and I Robot, all in one volume.

And of course, as a voracious reader myself, I reread these volumes, after not having read them in probably close to 20 years.

I found it interesting how some of the stories have held up better over time than others.  What really struck me were some of the social conventions that would never show up in modern day novels.  For example, in the Foundation books, cigarette smoking is taken for granted; it is something that is as casual as sipping a soft drink or chewing gum might be today.  I guess that's really the way it was in the late '40s and early '50s when those books were written.  Also, the idea of media moguls, where one person controls the newspapers, no longer really applies.  Even more out-of-sync is the idea that people would still be reading newspapers after 10,000 years of human history!  But as those books predated even television, such things shouldn't be surprising.

Also interesting was the clear expectations for how atomic power would change the world; that didn't happen, nor do I think it really will.

I Robot, on the other hand, held up better; the psychology related stories are more human, and thus more constant, than technology related stories. The same for The Naked Sun.

I've had this experience with other works, of course, such as one of stories in The Ship Who Sang that talked about a "Dylanist" as someone who uses music to influence society (written in the late '60s, of course), but the differences here struck me even more.

We don't often realize it when we read current SF works how much they reflect the times in which they are written.  I also suppose that when we're younger (I did a lot of reading in my 20s) we're not attuned to such larger things either.

All in all, it was fun to come back to these classic works, although with a different perspective (getting older does that to you, I guess).  I have, in general, become more analytical and critical in my reading, even of relaxing fiction kinds of things.

So, it's back to the boxes in the basement to see what else I can give my daughter... Wish me luck. :-)

That said, let's get on to the topic at hand. I am a new software engineer in the group that produces the Intel® AMT SDK (Software Development Kit). The SDK is made available to the wide world via Intel's web site.

The SDK group, besides working on new features for the next versions of Intel® AMT and Intel® vPro®, is looking into ways to improve the SDK. This is one of the major tasks that I have been charged with.  It is our goal to make AMT and vPro technologies easier to use and to write code for.

However (there's alway a "however", right?) we need as much input as possible from the people who are using the SDK so that we can do our job well. We need to know both what we're doing right, as well as what we could be doing better. We have some ideas which we are pursuing, but we really want to hear what you, our customers and end users, have to say about the SDK.

I hope in future posts to talk about some of our ideas and I'm looking forward to the whole blogging experience. But in the meantime, I'm here mainly to hear what you have to say!

Thanks.