crelf

QUOTE (ASTDan @ Jul 12 2008, 07:31 PM) You're spot-on. This pattern isn't for every situtation, as it's loosely-typed. That said, it's the looseness that makes it so powerful. We use it in one of our standard architectures to apss data between asynchronous nodes using user events, and it's amazingly fast.

QUOTE (Eugen Graf @ Jul 12 2008, 07:25 PM) Please give us some context on that almost-statement - at least an emoticon.

QUOTE (Val Brown @ Jul 12 2008, 05:40 PM) Unless something untoward happens to you and someone else needs to take over (either with your direction, or in your absence). There are more efficient and secure ways to protect your IP - especially if you want your ideas to continue to benefit the world in your absence.

Good stuff! :thumbup:

QUOTE (crelf @ Jul 12 2008, 11:36 AM) Done! Thanks for the inspiration :thumbup: http://lavag.org/old_files/monthly_07_2008/post-181-1215889423.gif' target="_blank">

QUOTE (ASTDan @ Jul 12 2008, 11:16 AM) We often use a current value table (CVT) that's based on the attributes of a variant (with polymorphic write and read methods). I haven't written a method that writes/reads the repository items to/from file, but that would be pretty trivial. Sorry I can't upload the toolkit (it's part of our internal reuse library), but here's a screen shot that give you an idea of the process: http://lavag.org/old_files/monthly_07_2008/post-181-1215876907.gif' target="_blank">

QUOTE (Justin Goeres @ Jul 11 2008, 07:01 PM) ...but then you'll be part of the system! QUOTE (Aristos Queue @ Jul 11 2008, 07:32 PM) ...For these reasons, I believe atheism exists. Oh, that's good - that's really good

QUOTE (Justin Goeres @ Jul 11 2008, 06:13 PM) Not at all - it just means that she didn't bake them for long enough - you're suggesting that the loaves of bread are the "system", whereas it could be much much larger than that I suggest she bake a loaf for an infinite amount of time and then we'll look at the results...

QUOTE (Pollux @ Jul 11 2008, 04:27 AM) While it would be fun, if you're actually interested in comparing SLOC to your LabVIEW code, have a look over http://forums.lavag.org/Node-count-versus-SLOC-t3632.html' target="_blank">here.

QUOTE (Troy K @ Jul 11 2008, 01:58 AM) As mentioned in the original post on the NI Discussion forums, the modularity index (like most programming language metrics) is http://dictionary.reference.com/browse/heuristic' rel='nofollow' target="_blank">heuristic. That means that the number alone means nothing - it's when you compare the number with results from code components that can be correlated.

QUOTE (JiMM @ Jul 10 2008, 12:55 PM) The other white meat.

QUOTE (Aitor Solar @ Jul 10 2008, 07:39 AM) So you're trying to initialize a 2D array where each row is [0,1,2] - the change you're proposing would require the ability to select between rows and columns. I don't find it surprising that functionality doesn't exist, as I've never seen a usecase for it. That said, if you do have one, let NI know as a feature request.

QUOTE (Justin Goeres @ Jul 9 2008, 05:41 PM)

QUOTE (Michael_Aivaliotis @ Jul 9 2008, 01:14 AM) That's hot!

There'll also be random cool LAVA mechandise in the prize list, including coffee mugs and mouse pads, from the LAVA Store: The LAVA Store is perfect for all your geeky needs: Coffee Mugs Mouse Pads Trucker's Caps Sitckers T-Shirts Stamps (yes, I said stamps!) Check out these products, and more, at the LAVA Store! Thanks LAVA Store :thumbup:

QUOTE (Xrockyman @ Jul 8 2008, 11:21 AM) Search the LabVIEW help for "run-time shortcut menu".

QUOTE (TobyD @ Jul 8 2008, 11:13 AM) There’s bound to be resistance to every new feature of LabVIEW. I don’t think there’s any real reason to shun new funcitonality just because it can be done in a different way that forces you to think in a certain way. I think that most relatviely experienced programmers understand the power (and responsibility) of the conditional terminal foor loop. I agree that it could be abused by people new to programming, but that can be applied to just about everything in LabVIEW (cross-post from http://thinkinging.com/2008/07/07/labview-85-feature-for-loop-conditional-terminal/#comment-12455' rel='nofollow' target="_blank">here).

QUOTE (Aristos Queue @ Jul 7 2008, 06:41 PM) Right - all native LabVIEW and allows you to engineer and reverse engineer your classes.

QUOTE (san26141 @ Jul 7 2008, 03:26 PM) I tried updating the link, but it isn't working. Here's another copy: Download File:post-181-1215466225.vi Edit: OK - that one doesn't work either. Reported to the admin.

JKI Software (a National Instruments Alliance Partner) has generously donated a VIPM Professional Edition license with Subscription (that includes one year of support and upgrades): VI Package Manager™ is a package management tool that organizes and maintains VI Packages™ within your LabVIEW environment. All OpenG libraries and tools are supported for download using VIPM. VIPM allows you to quickly access online code repositories and get them into your LabVIEW development environment in the shortest amount of time possible. VIPM Professional Edition specs: Download free OpenG libraries Install VIs directly into the palette Automatically resolve VI dependencies Keyword search for VIs NI Certified, Compatible with LabVIEW Save and recall configurations Scan projects for dependencies on reuse VIs Distribute packages to other developers Automatic Check for Package Updates Download Packages Directly from the Internet Integrated VI Package Searches Cross-platform Compatible Simultaneously Manage Multiple LabVIEW Versions and more... JKI's software engineers are experts at integrating tools into the LabVIEW development environment. The VIPM was developed according to the LabVIEW development guidelines and is certified by NI as Compatible with LabVIEW. Thanks JKI Software :thumbup:

PS: The LAVA/OpenG NI-Week 2008 BBQ door prize list is now open. If you or your company would like to donate prizes for drawing on the night (which means free advertising to a very tightly targetted audience) then please PM me and I'll add you to the list.

QUOTE (Poom-Thailand @ Jul 7 2008, 01:58 AM) So say we all!

QUOTE (JiMM @ Jul 6 2008, 05:49 PM) That is true, if you measure "costs" as purely financial As an aside - the processes that I'm talking about don't necessarily come cheap - they do take time and expertise to scale them for your operation, and implemenation isn't immediate either. That said, it doesn't need to be a painful process: as long as the stakeholders (management, engineering, operations, etc) are all substaintially involved in the development of the processes, then it's difficult to fail. As I said earlier, I'm no expert, so check out the Control System Integrators Association* (CSIA) for more info - they're the guys that really know how to do this sort of stuff well in the context of test. Check out their website - it's got some interesting stuff on it. * V I Engineering, Inc. is both CSIA certified and has a CSIA Executive Board Member on staff, and National Instruments is a CSIA Partner.

QUOTE (alukindo @ Jul 6 2008, 01:45 PM) I don't think we do - I think of software development as craft that is aided and bound by certain rules - rules which I refer to as engineering processes. I honestly think that we're talking about exactly the same thing, just looking at it at different levels. QUOTE (alukindo @ Jul 6 2008, 01:45 PM) BTW: The question on 'newer projects and clientele profile' was a general one intended to differentiate project types that you do now versus the older (smaller) projects that you noted you did in the past. In no way did I intend to divulge your business relationships or client-base. My apologies if it seemed that I was trying to spy on anything. No worries at all - I didn't think you were trying anything untoward at all, I just wanted to be clear on how much I can and cannot share. QUOTE (alukindo @ Jul 6 2008, 01:45 PM) In any case, when I visited the VI Eng web site I got direct answers to that question. I figured that you would Anyway, good luck - it sounds like you're at an exciting step along your path :thumbup: If you need any help or want someone to bounce ideas off, that's what LAVA's here for. QUOTE (alukindo @ Jul 5 2008, 07:39 PM) A link of GUI for these is available here. PS: I like your GUIs - they seem to follow the standard principles of user interface design (see here and here), especially the preservation of precincts and vision flow.

Aw bugger - I just wrote a long answer, but lost it all due to one erroneous keystroke I'll try to summarize what I'd already typed: QUOTE (alukindo @ Jul 6 2008, 12:05 PM) That's not what I was trying to say at all, in fact: it's the complete opposite If you have an appropriate acceptance test plan (ATP), then you can't not meet the requirements. I think what you're trying to say is that, although you might deliver something that meets all the baselined requirements, it might not actually be appropriate for the job it was intended. In other words, it does what they asked for, not what they wanted. That's the difference between verificaiton and validation QUOTE (alukindo @ Jul 6 2008, 12:05 PM) Usually what I find is that the written-down requirement statements may be met but what lacks is useability or lack of small user-features that look insignifucant but prove to be critical in getting the larger task accomplished. The commissioning test will even pass with good reviews. But after three to six months of use, user complaints creep in based on scenarios of use that make the application look cumbersome or even a show stopper. Then you were working with poor requirements. If the user complains that something is wrong (or even a shopstopper) then that requirement wasn't captured during the requirements gathering phase. That's an area where, as engineerings, we can all really value-add: spend time with your customer and try to really understand what they want. PaulG's right: a one or two page requirement spec is a reason to be wary on anything bigger than the smallest of code components - it usually means that the customer hasn't really thought through their requirements, and are probably making assumptions that your product will contain certain features, act in a certain way, without that being defined in the requirements. If they're not in the requirements, then they don't need to be tested. Hint: it's vital that you write (and accept only) requirements that are written in an industry-standard format (we use IEEE 1233 1998) - words like "shall", "may", "will" must be defined, and make sure that all of your requirement statement ("shall") are noted in a way that they are traceable in design and ATP documents (have a traceability matrix that keeps track of all these things). We have a whole team of engineers that work primarily on maintaining the technical solution throughout a project (requirements gathering and analysis, design, acceptance test planning, etc) - the team may not necissarily complete all of these tasks, but they coordinate them and ensure that they are all completed satisfactorily. We do this is for a few reasons, but the most important one is to make sure that the customer gets what they signed up for. Delivering a system that doesn't meet the requirements is poor engineering, and if we started a project working from requirements that we knew wouldn't satisfy the customer, then that's of little value to anyone, and frankly something that we simply don't do. If, during the project, it becomes apparent that the requirements need to be changed, then that's absolutely fine too: that's why engineering change orders (ECOs) were invented Quick Note: ECOs need to cost the customer money if the requirement change means more work (don't forget project management, accounting, etc required to process the ECO). That said, if they need the same amount of work or less work, then there's nothing wrong with zero-cost or refund ECOs. Ultimately, your customer is paying you to meet a list of requirements, and should be costed that way. QUOTE (alukindo @ Jul 6 2008, 12:05 PM) I am interested and would appreciate clarification on the nature of the newer projects and your general client profile? Sorry, but I don't comment on our business relationships or client-base. That said, if you told us more about the sort of projects that you're working on, it might add some context to your posts. QUOTE (alukindo @ Jul 6 2008, 12:05 PM) Are the customers aware of the software development process? Generally, yes. If they aren't when the relationship first begins, then they are before a contract is drawn-up. QUOTE (alukindo @ Jul 6 2008, 12:05 PM) Do they do many software projects? This isn't going to answer your question, but our services are much more than software alone. We build test systems, so while software is an important compnent of them, it's not the only component. So, your question needs to be more broad (although, you rewriting it doesn't gaurantee that I'll answer it ) QUOTE (alukindo @ Jul 6 2008, 12:05 PM) The interesting part is how did you transition and stay focused on these other projects? I don't understand your question. PS: I'm not a systems engineer per se (we have a whole team for that), but our operations model requires everyone in to be knowledgeable about systems engineering. We follow an internally-modified version of the V-Model on our projects, and have had great sucess. Why? Because everything we do is traceable to the requirements. If we deliver what we the customer wants and add value to the development process, then the customer is happy and we're making a difference in the world - and that makes crelf happy I don't think I've given away any trade secrets here - these processes have been used successfully for decades, and have (with a little modification here and there) proven themselves to work for the types of porjects we work on. That said, they are not the only method, and may not be appropriate for you. All I'm saying is that they work for us, and that you should do your own research into a model that is right for you. :!: Absolutely shameless plug: In fact, it might be worth your while to contact someone to help you define your process.