The Project Paradigm

[Cat]

The next version of the Big Project is ready to be shipped (so to speak ). I've got a couple days before I head out to sea for the installation and I thought I'd spend it doing a little code organization.

This is a set of code that I've been developing over the past few years. Somewhere along the way, NI in its infinite wisdom, decided I needed to be using projects to organize my code. I won't go into the headaches this has caused me, since it's one of those "improvement" I'm stuck with. But I do think part of the problem that I have with the Project Paradigm is that I really don't know how to use it to its full advantage. I realize there are multiple answers to this question, but I'm hoping you all can give me a few pointers.

Here's the situation: I have a project with 2000+ vis in it (well, really only 1800+. The other 200 are two OpenG polymorphic vis I use ). This project consists of a main program that calls a whole bunch of code dynamically, nine or ten "tools" programs, and 4 or 5 ancilliary programs that aren't really part of the Big Project, but are needed for other parts of the test setup.

All 15 of these programs have their own executable and those executables go into one installation package (that resides in the Big Project). I've started attempting to move the ancilliary programs off to their own projects and just pointing to their executables in the installation package. I'm not really sure if I should move all the tools programs off too, mostly because keeping track of 15 projects will be a headache.

Also, what vis should be listed in the project directory when I'm done? Right now, there's a whole bunch of vis that I don't need -- whatever I created while the project was open. Should the listing just consist of whatever top level vis and files I need to actually use to build the executables? Or should all 1800 vis be listed (hopefully not!).

As you all can probably see, I need a lot of remedial help!

Cat

[crelf]

Also, what vis should be listed in the project directory when I'm done? Right now, there's a whole bunch of vis that I don't need -- whatever I created while the project was open. Should the listing just consist of whatever top level vis and files I need to actually use to build the executables? Or should all 1800 vis be listed (hopefully not!).

Bope - only list the VIs in the project that you need to get access to or call dynamically and need to add manually to the build definitions - all the other ones will be listed under the dependancies section (if they're being used). For example, I have a few projects with 100s of VIs, and I only have 5 or 6 VIs in the top level project.

You can also put other files in there two (I usually have a link to the application's ini file, if it has one, as well as documentation, etc). The project isn't just for building - it's for managing the project. Sure, there may be issues (you mentioned that you're stuck with an "improvement" that you don't like) - if it's really in your way the let us know about it - one of us may have found a work-around, or maybe you're not using it in the way it was intended. That said, if it's a real issue, let NI know and maybe they'll fix it...

[Grampa_of_Oliva_n_Eden]

Bope - only list the VIs in the project that you need to get access to or call dynamically and need to add manually to the build definitions - all the other ones will be listed under the dependancies section (if they're being used). For example, I have a few projects with 100s of VIs, and I only have 5 or 6 VIs in the top level project.

You can also put other files in there two (I usually have a link to the application's ini file, if it has one, as well as documentation, etc). The project isn't just for building - it's for managing the project. Sure, there may be issues (you mentioned that you're stuck with an "improvement" that you don't like) - if it's really in your way the let us know about it - one of us may have found a work-around, or maybe you're not using it in the way it was intended. That said, if it's a real issue, let NI know and maybe they'll fix it...

And here I have been working to ensure there is little or nothing showing in dependacies!

I use the project to give me a more logical organization than just using folders. i think it was Aristos Queue who was talking about organizing files in-side a class and as far as LVOOPwas concerned it prefered to find all files in the same folder as the class or in a sub-folder of same. A large class would be hard to navagate if we just mimic the folder structure in the project. So I'll create vitrual folders in the project that break down the functions logically. So the project lets me organize things better.

I also like the ability to keep support files in the project and I include them in Source Distributions that I use to occationally clean-up the project folder and wipe out the orphans.

I have alos used a project for my re-use stuff.

Ben

[Christian_L]

All 15 of these programs have their own executable and those executables go into one installation package (that resides in the Big Project). I've started attempting to move the ancilliary programs off to their own projects and just pointing to their executables in the installation package. I'm not really sure if I should move all the tools programs off too, mostly because keeping track of 15 projects will be a headache.

Cat

In addition to crelf's comments, you can also store LV projects in a LV project. So you can create your other projects and add them to the Big Project. You can double click on a project in the Big Project tree to open it up.

I personally would keep everything in the main project and create virtual folders to keep things organized and separated, including your 15 exe build specs and any necessary installer build specs.

[Grampa_of_Oliva_n_Eden]

In addition to crelf's comments, you can also store LV projects in a LV project. So you can create your other projects and add them to the Big Project. You can double click on a project in the Big Project tree to open it up.

I personally would keep everything in the main project and create virtual folders to keep things organized and separated, including your 15 exe build specs and any necessary installer build specs.

Reply #26 (you will probaly have to click for page 2) in this thread on the dark-side has images contrasting the folder vs Project views.

http://forums.ni.com/ni/board/message?board.id=170&thread.id=378937&view=by_date_ascending&page=1

and another one from the Dark-side

http://forums.ni.com/ni/board/message?board.id=170&message.id=392299&query.id=518014#M392299

Ben

[Cat]

Bope - only list the VIs in the project that you need to get access to or call dynamically and need to add manually to the build definitions - all the other ones will be listed under the dependancies section (if they're being used). For example, I have a few projects with 100s of VIs, and I only have 5 or 6 VIs in the top level project.

Okay. I've already started putting that together. I've pulled top/dynamic vis out into a new project. Another Q: is there a way to copy build specifications from one project to another?

Sure, there may be issues (you mentioned that you're stuck with an "improvement" that you don't like) - if it's really in your way the let us know about it - one of us may have found a work-around, or maybe you're not using it in the way it was intended. That said, if it's a real issue, let NI know and maybe they'll fix it...

I'm very willing to admit (and was trying to in my original post) that some of these issues may be my fault. My main problem has been that between the Big Project and other projects I'm working on, there is a lot of code reuse. I've managed this all quite fine for years. Ever since I had to start using projects, there have been several occasions where I have altered or even deleted code because I was editing it in one project and didn't realize what impact this was having on code in another project. I don't think this is something that can be "fixed" by anything other than me knowing what the features/limitations of projects really are as they apply to a large installation with many parts.

[crelf]

I have alos used a project for my re-use stuff.

Are the VIs in the project, or is it just a convienient way to access your vip files?

In addition to crelf's comments, you can also store LV projects in a LV project. So you can create your other projects and add them to the Big Project. You can double click on a project in the Big Project tree to open it up.

Totally! I have a small app that is a hardware explorer that loads hardware classes dynamically - it's great to have the lvproj files for all those classes in the main app's lvproj for quick access.

[Cat]

In addition to crelf's comments, you can also store LV projects in a LV project. So you can create your other projects and add them to the Big Project. You can double click on a project in the Big Project tree to open it up.

Yes, thanks for reminding me. That's probably what I'll end up doing.

Reply #26 (you will probaly have to click for page 2) in this thread on the dark-side has images contrasting the folder vs Project views.

Thanks for the links, Ben. It's good to know I'm not the only one wondering how/when/where/why to use projects. There's a lot of good info in those threads.

I keep forgetting there's another LV forum (tho I did read everything I could find on projects on the NI website a couple weeks ago).

[Grampa_of_Oliva_n_Eden]

Yes, thanks for reminding me. That's probably what I'll end up doing.

... There's a lot of good info in those threads.

I keep forgetting there's another LV forum ...

Seems to be rather common condition round here.

Ben

Chris,

Re: your Q about re-use project in my project.

In this last project I put the re-use project in the app project just as an experiment. I latter added virtual folder to the main app for the re-use stuff to make it easier to find. BUT I don't pretend to know which method is better. Care to share your thougths?

Ben

[Daklu]

I use projects a little differently than Chris. I prefer to keep any file I consider "editable" as part of the project. That way I can organize them in virtual folders in a way that makes sense. The code in dependencies is typically from user.lib, vi.lib, and those kinds of places. In other words, it's reuse code that has built and distributed. If I see reuse code in dependencies that isn't in user.lib, it usually means I've accidentally linked to the source code and I need to fix it.

[crelf]

I use projects a little differently than Chris. I prefer to keep any file I consider "editable" as part of the project. That way I can organize them in virtual folders in a way that makes sense. The code in dependencies is typically from user.lib, vi.lib, and those kinds of places. In other words, it's reuse code that has built and distributed. If I see reuse code in dependencies that isn't in user.lib, it usually means I've accidentally linked to the source code and I need to fix it.

I agree with almost all of that - I don't think our models are so different, except that I don't keep *all* of my project-specific (you called it "editable") code in the project - only stuff I expect to edit, or higher level VIs where I can drill down a level or two to those other project-specific VIs tha I might need to change once or twice. Otherwise I can see the project space getting a little unruly. That said, there are cases when I'll have almost everything specifically listed in myu project (ie: not in dependancies).

[Cat]

If I see reuse code in dependencies that isn't in user.lib, it usually means I've accidentally linked to the source code and I need to fix it.

I use user.lib just for generic tools. Nothing application dependent.

Most of the code I reuse across applications is reading/writing file formats, performing basic analysis functions (mostly of the FFT variety). Other users want to use the file format we've developed for the Big Project so they can use my analysis tools. So I am deliberately using code from Big Project in those other projects. As I said in my original post, I haven't had any problem managing this until recently. Maybe I need a library called reuse.lib where anything that's cross-application goes. Or maybe I just need remedial source code control tutoring.

Otherwise I can see the project space getting a little unruly.

"Unruly." That's the exact description of my Big Project.

[crelf]

I use user.lib just for generic tools. Nothing application dependent. Most of the code I reuse across applications is reading/writing file formats, performing basic analysis functions (mostly of the FFT variety). Other users want to use the file format we've developed for the Big Project so they can use my analysis tools. So I am deliberately using code from Big Project in those other projects.

That sounds like the second step most people do in the re-use road (the first step is to recognise that you need reuse ). Monolithic reuse libraries are nothing new, but they aren't really a solution. They work great for a while, but the quickly become unmanageable, and are usually left to die

As I said in my original post, I haven't had any problem managing this until recently. Maybe I need a library called reuse.lib where anything that's cross-application goes. Or maybe I just need remedial source code control tutoring.

Actually, none of those will really solve your reuse dilema - sounds like you need VIPM - seriously.

[Cat]

Actually, none of those will really solve your reuse dilema - sounds like you need VIPM - seriously.

I think I have the very first version on some ancient laptop around here...

Part of the reason why I stopped using it was that a few years back it was declared by the Powers That Be that we could never touch an outside network with our acquisition computers. Not that they are classified, but just because... That made updating/synching problematic so I abandoned it before I ever really started using it. Plus back then there was only the Big Project and reuse wasn't an issue. Mostly I was using it for the very first OpenG versions.

All that being said, I could take my current development laptop home (it's not considered one of our acquisition computers) and download there. After that, are the any issues with running the Professional version off the net? Or should I be asking Jim these questions?

[crelf]

All that being said, I could take my current development laptop home (it's not considered one of our acquisition computers) and download there. After that, are the any issues with running the Professional version off the net? Or should I be asking Jim these questions?

Unless you want to use VIs available thorugh the VI Package Network (like OpenG and JKI sutff) then you don't need to be connected to the internet to use VIPM internally - you can just set up and access your reuse packages internally (or off an internal network using the enterprise edition of VIPM).

[jcarmody]

Unless you want to use VIs available thorugh the VI Package Network (like OpenG and JKI sutff) then you don't need to be connected to the internet to use VIPM internally - you can just set up and access your reuse packages internally (or off an internal network using the enterprise edition of VIPM).

If you can use portable media, you can install OpenG & JKI packages onto a PC that's not connected to the internet.

[crelf]

If you can use portable media, you can install OpenG & JKI packages onto a PC that's not connected to the internet.

Right, and if you're allowed to download and install VIPM then I can't see why you wouldn't be allowed to download and install OpenG and JKI packages using the same method...

[Cat]

Right, and if you're allowed to download and install VIPM then I can't see why you wouldn't be allowed to download and install OpenG and JKI packages using the same method...

<BR><BR>Oh, definitely. It's just a matter of lugging my laptop home and doing it there. I'm heading off to install and test the Big Project soon. If I get a chance I'll download the freebie version of VIPM tonite. I've got 12 hours on a plane to play with it. <IMG class=bbc_emoticon alt= src="http://lavag.org/public/style_emoticons/default/blink.gif"> <BR><BR>Thanks for all the input everyone!

[Jim Kring]

I think I have the very first version on some ancient laptop around here...

Part of the reason why I stopped using it was that a few years back it was declared by the Powers That Be that we could never touch an outside network with our acquisition computers. Not that they are classified, but just because... That made updating/synching problematic so I abandoned it before I ever really started using it. Plus back then there was only the Big Project and reuse wasn't an issue. Mostly I was using it for the very first OpenG versions.

All that being said, I could take my current development laptop home (it's not considered one of our acquisition computers) and download there. After that, are the any issues with running the Professional version off the net? Or should I be asking Jim these questions?

Hi Cat,

Sure, let me know if you have any questions. You can reach me by several means, but the JKI Software Contact page is a good place, in this case.

VIPM serves two main purposes:

1) VIPM Community Edition helps people download and install LabVIEW Tools created by the community.

2) VIPM Professional Edition helps you create your own packages of Reusable VIs.

VIPM can be configured to not connect to the outside network. Additionally, VIPM Enterprise Edition allows you to create a repository of packages on your company's intranet (LAN, VPN, etc.) for sharing packages with your team.

Cheers,