It's All Just Ones and Zeros

6 Years

Today my blog turns 6, which is 110 years is binary.  To celebrate, I’m going to reveal a couple of Easter Eggs that I’ve slipped in over the years.  Specifically, the titles of some of my apps.  One thing I love about writing my own apps is that I get to pick the name.  An in two cases, I named the app in such a way as to set up a joke.  That’s just the type of guy I am.

 

Project Thunderdome:

Yes, it’s part of a movie title, but the joke goes deeper than that.  It’s probably best explained by this Mystery Science Theater 300 clip.  By the way, I’m a huge MST3K fan.

 

The TTP Project:

This app never achieved the popularity of Thunderdome, which is a shame.  I wanted to unload this joke on more people.  Basically the conversation would go like this.

(me an you chatting about PLM API programming)
Me: … You should check out my sample app, The TTP Project?
You: What does TTP stand for?
Me: The TTP Project

Again, I stole this joke from another source.  Because that’s also the type of guy I am.

-- Doug

---

My Take on Vault Data Standard

Earlier this week I listened in on a webinar on Vault Data Standard and it got me to thinking.  Coming from a Vault API background, I have a different view of Data Standard then what is usually presented.  So I’d like to provide my thoughts since this is a blog and all....

---

APIs on top of APIs

Data Standard provides a lot of features you can get through the API.  You can create custom commands, custom UI and make calls to the Vault server.  What’s interesting is that Data Standard itself is a Vault Explorer plug-in.  So the Data Standard API is basically an API on top of the Vault API.

It’s basically like the movie Inception, but with APIs instead of dreams.

Many pieces of the Data Standard just pass through to the Vault API.  Adding custom commands is an example of this.  The settings in the DS .mnu files are exactly the same as the properties on CommandItem from the Vault API.  In this aspect, knowledge of the Vault API transfers directly over to Data Standard.

Another example is the $vault object that shows up in the .ps1 files.  The purpose of the object is for making web service calls to the Vault server.  $vault is a WebServiceManager object being passed in directly from the Vault SDK DLLs.  If you want to do anything with $vault, you need the Vault API documentation on-hand.  Again, if you are already familiar with the Vault API, than this is no problem.

What I’m more curious about is the people without a Vault API background.  How well are they able to utilize Data Standard?  Does DS ease them into the world of Vault programming, or does the Vault API hit them like an impassable brick wall?

---

Beyond the API

The stuff that interests me most is the stuff that can’t be done through the Vault API. 

First and foremost, the CAD plug-ins are awesome.  Data Standard is not just a plug-in to Vault; it plugs into AutoCAD and Inventor as well.  That way you can easily create an Inventor dialog that is Vault-aware, for example.  Going through the traditional APIs would be a daunting task.  You would need to be an expert in both APIs and would have to figure out how to hook the two together.  DS solves all that stuff for you in a way that makes it look easy.

Another aspect of DS are the template features.  New CAD files can be copied from a template instead of staring from a blank file.  DS uses Vault functionality to centralize the storage of the templates.  This is less of an example of a generic API and more of an example of a focused solution.  Data Standard is really a dual product: It’s an API, and it’s an end-user utility.  

The two aspects are not at odds with each other, but I’m not sure if they blend well together either.  It feels to me more like a Swiss Army knife.  It’s a bunch of seemingly unrelated stuff packaged together.  Maybe that’s why it’s a hard product to describe it to people.

---

Migration

One thing like like about compiled programming languages, such as C#, is that you get compile errors when something goes wrong.  That way if an API changes, you know right away what broke.  PowerShell, however, is a scripting language.  So it’s harder to find the breakages.  Usually, they show up at runtime and only if specific pieces of code are run. 

If you have a lot of PowerShell code in your Data Standard implementation, you may find it hard to maintain.  Everything will seem fine at first after an upgrade, but things start failing as people start using the custom functions.  Even if you think you have everything updated, a CAD user somewhere may hit lesser-used code that calls an obsolete Vault API function. 

Yes, Vault provides compatibility for older versions of the web service API, but in order to use them, you need to have the older SDK objects.  If Data Standard is passing in the 2015 version of the WebServiceManager, then you can’t make use of the 2014 server APIs.

There are lots of ways to solve, or minimize these issues when they do come up.  For now, Data Standard is new, so nobody has run into migration issues... yet.

---

Memories of my first AU

You can divide my career at Autodesk into two parts.  The part before Autodesk University and the part after.  No single event has had as much impact.  Of course, the fact that I work for Autodesk had a lot to do with it.  So individual results may vary.

Pre AU, I was mostly your average computer programmer.  People would give me features to code, and I would code them.  I pretty much relied on management to tell be what was important in the product and how people used the product.  I did not yet have a blog or a YouTube channel.  However, some interesting things were starting up.  Vault Mirror, my first “app,” was up on Autodesk Labs, and I was actively participating with the newly created discussion group for Vault.  But AU put those initiatives in high gear.

---

The year was 2006, and one of my tasks was managing the Vault API, so ADN invited me over to show it off for DevDays.  I decided to stay for the whole week and attend as much Vault-related content as possible.

The classes themselves were stuff I already knew, but the real benefit for me was after the class. People would hang around after the class to talk to the instructor.  This gave me a chance to listen and talk to people, which I don’t usually get do to as a programmer.

The amount of information I gained from those simple conversations was amazing.  It changed my view of the product and how people use it.  Sure, at a technical level the product is the same, but it’s not always clear how technical details come together to form a useful product.

Even outside the classes, I was able to have good interactions.  At lunch, I’d sit with a bunch of strangers.  After seeing from my badge that I worked at Autodesk, the conversations would pretty much go like this...

“So you work at Autodesk, what do you do?”

“I work on the Vault product.”

“Vault?  I think I may have heard of it.  What does it do, exactly?”

“Well, let me tell you...”

And before I knew it, I turned into a salesman. It’s not something I would want to do every day, but it was still a welcome change from day-to-day programming work.

---

The main stage event blew me away.  Before then I had no idea just how cool Autodesk is.  Sure the Media and Entertainment division is a big help with their 3D animation software.  But the geeky CAD stuff was just as cool to me.  Cities designed in 3D, factory floor simulations, etc.  Not many companies could pull off that kind of presentation, so I felt privileged to be part Autodesk.

This is probably the only part of AU that has lost it luster for me.  I still enjoy the main stage events, but they don’t pack nearly the same punch as the first one.  Although I was very happy to see Vault an PLM get some time on the main stage last year.

---

After that first AU, things changed for me.  I still spend most of my time programming, but my role expanded in ways I couldn’t comprehend.  A significant portion of my time now goes to API training and support.  Maybe those changes would have happened anyway, but AU was definitely a tipping point.

I’ve been back to AU four times since then, and I learn something new each time.  Most of my apps are inspired by my interactions with customers and resellers.  But there are intangible benefits too.  Every feature I code is influenced, sometimes at a sub-conscience level, by those interactions.  I can’t wait for this year’s AU.

See you there.

---

Finally a Good Splash Screen

I’ve been waiting for this for almost 9 years, and it’s finally here.  Vault has a good splash screen!

Don’t get me wrong.  The old splash screens were not bad, they just didn’t fit well with the product.  Commonly the Vault screens would be very CAD related.

The above image would look perfect on AutoCAD or Inventor, but it just doesn’t fit Vault.  It’s not a bad image, but it doesn’t describe what the product is about.

---

Some of the early releases of Vault used “guys standing around a table” imagery.

This is better, but it doesn’t quite hit the mark.  Notice the lack of computers or anything hi-tech.  Some of the images even featured people staring at blueprints.  Although there is a collaboration aspect to Vault, it’s not really meant to simulate face-to-face meetings like what is being shown.

---

Vault is really about connecting and organizing CAD data, which brings us to the Vault 2014 splash screen.

Ahh, look at it.  A thing of beauty.  It has a nice hi-tech vibe to it and is pleasing to the eye.  So what do the interconnected balls represent?  The vault client and server components?  CAD files?  People?  Data management systems?  The answer is all of the above.  Vault does all of those things, and those things are a fitting description of Vault. 

Vault is a hard product to describe, so it doesn’t surprise me that it took so long to get it right.  I’m just glad it happened.  As a programmer, I usually don’t care about things like branding, but it looks like some real effort was put in to understand the products.  I’m not just talking about Vault either.  All the new Autodesk product releases are accompanied by amazing imagery.

The post-AU blog article

AU is now over, and I’m almost fully recovered.  My limp is barely noticeable and my right eye is mostly in focus.  It will take a few more weeks for the slot-machine ringing noises to fade away, but that’s to be expected.  This is a good time to go over Vault API related topics from AU.

 

Vault wins at Apphack
Autodesk Developer Network put on an event called Apphack.  The idea is that people could submit their apps, and the public votes on which one should win.  I think there were around 20 entries.  The winning entry was a Vault App!

Rob Oud from CAD & Company submitted Vault Project Portfolio.  It’s a Vault Browser app for Windows 8 tablet.  I was able to see a quick demo between classes, and the app looks very cool.

 

My classes were not recorded, again
Every year a rumor goes around that every class will be recorded, and every year it turns out to be a lie.  I don’t think I’ve ever had an AU lecture recorded.

Anyway, my two classes “Programming Integrations Between Autodesk Vault and Other Systems” and “Programming Custom Objects with the Autodesk Vault API” will be converted into blog posts over the next few months.  It’s probably for the best anyway.  You can’t Google for content within a video very well.

 

Process is critical
I like to attend as many Vault classes as I can.  Mainly I just sit and listen.  One common theme this year was process.  If you don’t get your processes defined properly, your Vault deployment will be a failure.  That got me to thinking what I usually think about:  Can I write any apps for this? 

It’s a bit of a “chicken and the egg” problem.  How can I write a Vault app that helps with Vault deployment?  Any suggestions would be welcome.

An Introvert’s Guide to AU

I’m pretty much what you expect from a professional programmer.  I have all 7 seasons of Star Trek: TNG on DVD.  I play computer games long into the night.  And when it comes to people, my official policy is “no thanks”.  I can write code for 8 hours solid without any problems.  But put me in a group of people and ask me to mingle, and I’m burnt out within an hour.

In a few weeks, I’ll be going to my 5th Autodesk University conference.  Here are some of the techniques I’ve picked up over the years to cope.  Don’t get me wrong, I love AU.  I just don’t ease through the conference like my extrovert co-workers.

---

Be a Wallflower
If you are a regular attendee, you can quietly slip into the background.  Attend the classes you care about, visit the exhibit hall, watch a few sales pitches, and you’re done.  Despite the crowds of people, you can remain fairly anonymous.  The only thing is to make sure that you don’t miss out on anything important.  If you have a question about something, make sure to hunt down the right people and get the answers you need.

For my first AU, I was able to mostly get away with this technique, but those days are over.  This year I’m presenting two lectures, co-presenting one lecture, presenting at ADN DevDays, providing support for ADN DevLab, and manning both the Vault and PLM 360 booths.  Also there are about a dozen contacts, inside and outside of Autodesk, that I need to hook up with while I’m there.  There is no way for me to slip into the background.  So, I’ve had to come up with some new techniques.

---

Alcohol
Just about every AU event has a generous supply of alcohol.  I find that one or two beers really takes the edge off.  Of course, you must know and respect your limits.  There is nothing more pathetic than getting bombed and making a fool of yourself at a software convention. 

I have to represent Autodesk, so my limit is pretty low.  I also make sure to balance things out with food, of which there is also a generous supply at AU.  Remember, this is a marathon.  Pacing is everything.

---

Tablets and Smartphones
For us introverts, mobile devices are probably the best inventions of all time.  If you are at a table full of people, you can just pull out your phone and start playing away.  You are not being rude; you are working!  Also, about half the people at the table will also be busy on devices too, so you won’t even look out of place.  These devices are turning everyone into introverts.  I guess we really will be inheriting the Earth.

---

Get Enough Sleep and Food
Social situations are exhausting enough, you don’t need to make it worse by being hungry or tired.  The goal here is to make everything as confortable as possible to counter-balance any social discomfort.  If I know I’m in for a busy day, I usually pay for the full breakfast at the hotel restaurant instead of the free conference breakfast.  It’s worth the money to insure that I can perform better.

My Take-away from AU

I was busy at AU last week, which is why there wasn't much activity from me online.  I'm not going to repeat AU news that has already been posted elsewhere (PLM, Autodesk 360, etc), that's not what this blog is about.  I'll keep things focused on the Vault API and share some things I learned.

Yes, I learn things at AU.  Not things about the Vault API, but how people perceive and use the Vault API.  The more I understand my users, the better I can distribute information.

I've known for some time that the API consumers fall into two camps, the professional programmers and the non-professional "scripters".  Since I'm a professional programmer myself, I'm good at providing information targeted at the first group.  The second group is where I rely heavily on feedback.

---

The Scripter persona

Let me take a crack at describing the Scripter (feel free to let me know if I missed something).  This person wants to customize the Vault but doesn't want to spend days learning the entire Vault API.  Usually they want to write tools tailored to their own environment.  There is a task that they do over and over and they want to automate the process or reduce mouse clicks.  The best-case scenario for them is to find a similar tool that they can tailor to their own needs.  Having to start from scratch is a big pain and sometimes a show stopper.

Cost of entry is also a big factor.  It's very important that a scripter can get something working early on, even if its just a Hello World example.  Spending hours figuring out how to get a command to load is not acceptable. 

---

Feedback

Most of the feedback I get from scripters is positive so I'd like to share that with you.  I don't get much feedback on things that aren't working, but I do get questions like "Do you have an app that does X?"

The good:  SDK Samples
These examples are easy to read and easy for scripters to modify.
How to make it better:  More samples in the same style.  In other words, samples that illustrate one useful concept in a clear and simple way. 

The good:  .NET
It's an easy-to-use and powerful programming platform.  It's free and supports VB.
How to make it better:  Get rid of the "compile" step.  This goes back to reducing cost-of-entry.  The less steps equals lower cost-of-entry.  And, technically, scripting means that the code does not need to be compiled.  There are a couple of techniques that can help with this goal, such as PowerShell and run-time compilation.  I haven't yet taken a serious look at these techniques, but it's on my agenda.

Blog Objectives

Now that I am (momentarily) out of apps to post, I'd like to take some time to talk about this blog.  What are the objectives?  What is the plan for the future?  That sort of thing.

The philosophy:
This blog is 100% meat.  There is no filler for fluff.  If it's not related to Vault, it's not getting posted.  There will be no vacation photos, stories about my family, movie reviews and so on.  Some other blogs do that, and that's fine, but it's just not my style. 

A consistent level of posting is important too.  The formula I use is 1 posting per week and 1 sample app per month.  I've been able to keep that pace for over a year an a half, which is a decent accomplishment in my opinion.  The downside to this approach is that there is an excess of content and certain times of the year (like now with the release of Vault 2012) and a lack of content at other times (like right before a release).  The result is a slower release information so that it lasts for the whole year.  Hopefully, you are not even aware that I'm doing this.  Nevertheless, let me know if there is a topic you want me to hit sooner than later.

Programmers are my target audience, but I'm very aware that free apps is a big draw for all types of Vault users.  The two groups are very different from each other, but I haven't heard any complaints.  Regarding programmers, I want my blog to serve the whole spectrum.  From professional software engineers to hobbyists that barely know how to code.  Not every post will hit the entire range, but overall, the blog should have something for every type of programmer.

My blog is just part of a network of Autodesk online content.  On the Vault side alone, there is a usage blog, support blog, wiki and discussion group.  The hope is that all these pieces come together to form something positive and useful.  I try my best to fill my own little niche while adding benefit to the overall network.

Future plans:
I don't have specifics or timetables or anything like that.  But I do have some ideas bouncing around in my head that I would like to start acting on in the upcoming year.

• Quick start guide:  If you are new to Vault programming, I imagine the whole thing can be overwhelming.  So I will be creating a section geared specifically for getting someone coding on Vault as quickly as possible.  It may just be a page that links to some of my old posts, or it may be something more experimental, like a video tutorial series.  I'll probably start small and grow it over time.
• Developer community:  Since my blog is the de facto place to go for Vault apps, I'd like to use it as a cornerstone for a development community that extends outside Autodesk.  The trick is how to do that without sucking up too much of my time.
• Retroactive updates:  As new Vault releases obsolete my older posts, I need to go back and add addendums indicating how things have changed.

Don't change what is working:
I have no intention of changing anything.  Based on all the feedback I've received (both internal to Autodesk and external) this blog is on the right track and I should keep doing what I'm doing.  I have no intention of changing my rate of posting, sample apps, webinars, level of technical detail and so on.

Final Notes:
I love what I do, and hopefully it shows with every post.  Maybe one day this blogging stuff will seem like work, but I don't think that day will come anytime soon.