crelf

Ok, so we were trying to compare apples to oranges. 'nuff said That's not entirely true, but it's not entirely unture either. I think that some new softwares are expected to be buggy, possibly because they haven't gone through alphas or betas, and/or the market has forced an early release on a less-than-mature product. It's also one thing that makes software so awesome - changes (whether they're bug fixes or feature additions) can usually be made with a much faster turn around than hardware. That's not always the case, but if we're talking about product platforms here (which we're not ), then it's a great way to go- especially if you have more than one customer: you can weight feedback on feature requests and make strategic business decisions based on them, which can be super efficient during alpha and beta cycles, as opposed to waiting until full releases. Again, apples and oranges. Image an iPhone user who wants an app that allows them to read their email: if you said to them "I've got an app that does 98% of what you want, but 1% of the time it'll take an extra 30 seconds to download attachments, so I'm not going to release it for another 3 years until it's perfect". The iPhone user goes and downloads another app. Also, skyscrapers aren't ever perfect - they're good enough. And I'm pretty sure building owners are given tours of their buildings before they're completed As for the type of systems you build, I agree with you - and we make similar-sounding systems too. Such tings are decided at requirements gathering and design phases, and are usually locked down early. That said, we also have a suite of software products we use on these programmes, so it's a balance. In summary, as Jeff Plotzke said during his 2010 NIWeek session: "Models can, and should, fit inside other models." That's an admirable goal, and works extrememly well in some industries. I sometimes find it useful to get feedback from end users during development, because, in the end, we want compliant systems, on time, on budget, that make our clients happy. That last item can be tricky if the first time they see it is the last time they see you Anyway, it depends onthe idustry, technology , and client. All I'm trying to say is that deriding alpha and beta programmes completely doesn't make sense to me - every tool has a place.

I agree that you can't dump it in someone's lap totally unfinished, but I couldn't imagine dumping it my customer's laps without them having an opportunity to tool around with it before its officially released. What you're suggesting might work for systems that have few and very well defined features, but once you scale up even just a little, the possibilities of what your customers might do with it grow quickly. Look at LabVIEW: I'm glad they have betas, because, without infinite resources or infinitie time, they can't possibly imagine to test all of the combinations of awesome things we're going to try to make it do. Maybe we're comparing apples to oranges, or I'm missing your point. It's a thread hijack anyway, so I'm going to split to t a separate thread.

...and the opportunity for your potential customers to help shape the direction of your product by pushing it through use cases you hadn't thought of

Maybe that's part of the stuff that Wirebird Labs is working on? I'd keep an eye on them...

Yes! I was skeptical when we ordered these, but they work great - and have LabVIEW drivers (well, wrapped DLLs ).

Revoked.

Is your exe builder/installer pointing at a custom ini that has this line in it?

1.27. PS: The cake is a lie.

You want a cookie?

Okay, now it just got creepy.

More info here.

Sure! With gravy, a side of potatoes and peas.

Can't speak - too awesome! Wait, is that Kim Jong Un? This is totally my favorite Chinese group at the moment - I picked up a CD when I was in Donguan a few months ago. FWIW: My 2 year old son loves them too

She's on to us! <sound-of-circling-helicopters> Sorry Cat - I fully support the concept that links in posts should be full, as there's no reason for them not to be. My guess is that I've pasted them from somewhere else: sorry about that, I'll be more vigilent in future. As an aside: we use bitly to shorten links in our @lavag twitter feed - it gives us metrics on clicks, so we can see what stuff y'all are actually interested in. Apparently you like cats.

It's difficult to compare, as we don't know exactly what's going on under the hood, so we might be comparing apples to oranges without knowing it (eg: a c++ function might do a poorer job of finding an edge, but the IMAQ one might be slower). I guess I need to know where you're coming from to better explore your question. Are you trying to decide on whether to use the Vision toolkit or something else based solely on execution speed? What's your target? PS: The functions that are called in the Vision toolkit are invariably DLLs anyway, so perhaps the comparison is moot?

I think that maturing API designs is a key concept in professional software engineering, and for one's knowledge to grow, it's an important topic to understand (no one masters it, but it's fun trying ). I think NI's done an above average job on promoting good API design (even way back when they launched the NI Instrument Driver Network), and it's paying off with well designed products flowing into the LabVIEW Tools Network. Here's an interesting article on high level API strategies on API Evangelist to get you started - read it here.

Please post your VI (you can take out most of your code if yo like) so we can take a look at it.

That this happened is actually kind-of neat: it suggests the number of people taking up community editions of the GDS has exceeded Symbio's predictions. Yay! By the way, if you're reading this thread and don't know what the GDS is, have a look at it here. Then download and install it. Do it. Do it. Install it. Do it.

LAVA likes to keep you informed, and we know that a lot of our members have different ways of getting to LAVA, and one of those is to follow @lavag on twitter (we have over 400 followers). We'd like to ask our followers what they think of our tweets: Do we tweet too much/too little? Is the feed too technical/not technical enough? Do we tweet the right kind of posts/are we missing the mark? Have you followed us in the past, and don't anymore? We'd love to hear why and what we can do to change. We've been tweeting for a while now, and we'd love your feedback on the @lavag twitter feed to help us better shape how we connect with you!

I've bought my t-shirt and I'll wear it next year at NIWeek - I'd love it if others joined me!

At first look, you might think "I'm not going to use that - I'll unsintall it so it's not hogging my PC resources", but I ask you at least learn a ltitle more about it - it's actually quite useful, especially if you use TDMS files, although it works great on other formats too.

Sounds like it doesn't fit your model at all. And that's okay - that doesn't mean Requirements Gateway is a bad product, it just means that it's not a good fit for you. I can't agree more - we often open up the graphical view on even a small project for a few laughs. That said, for what I do, IMHO the graphical view isn't high value anyway.

Put me down for a "me too" on a lot of these posts - we use it a lot, but our document templates match it well (or vice versa) so using it from project to project is simple and fast, but that's only because we spent a significant amount of time setting it up right (like most tools, I guess). As asbo said, even if you're not in a regulated industry, it's worthwhile and gives you peice of mind. Even if it's just to make sure you don'e have duplicate requirements codes or the like. Of course, using it to its full ability is awesome too: there's nothing like a traceability report that's generated by a 3rd party tool which was written by an ISO 9001 certified company to make your customer sleep better at night

Dave talked about it for a few minutes and showed screenshots in this presentation: Sure, but as an integrated tool, VISnippet will probably be a little more hesitant to change, and wi'll definately take longer. I agree that updating VISnippet with all the CCT features would be perfect, but that's probably not oging to happen. That said, getting the CCT changed will probably result in less resistance, *and* the CCT developer doesn't have to wait until the next (or later) release cycle. I don't mind either way - it's not a feature I'd probably use - I'm just expanding on the process as I see it.