06-10-2014 03:43 AM
Hey guys,
So there are many tools in LabVIEW that help us reuse codes so we dont have to spend hours on codes that
someone else has already made. Packed libraries for oftenly reused code such as API,
VI/project templates to reuse architecture, VIPM and source code control to install and keep track of them, just to mention a few.
And then there are documents like Software Engineering in LabVIEW, Software Engineering Technical Manual and Exercises for LabVIEW, CompactRIO Developers Guide, but I am curious if there are any other documents
or other tools to further help organize and ensure this practice.
Experience definitely is the best way to keep track of which tools to use at the right time,
however I was just thinking that if anyone at their company had a guideline/tool to organize code reuse.
Also, let me know any other strong tools in LabVIEW that are but not mentioned above .
I am not a software engineer so any idea is appreciated
Thanks.
06-10-2014 12:42 PM
A key tool that you didn't mention is source-control -- like Subversion.
But the biggest part of code reuse isn't about tools, it's about mindset. Even if you have the best tools available, your code reuse project is going nowhere if the code you are writing is not reusable. It's a manner of learning to implement modularity that exposes what is need to use the code effectively, while hiding the implementation details. In looking for material that will show you how to do this, be very careful of reading books where the examples are illustrated with other languages like C++ or Java. Those languages make their own assumptions and have their own limitations -- which LV probably doesn't share.
Look for books and papers that teach the principles, not "cookbooks" teaching techniques.
Mike...
06-12-2014 11:57 AM
Thanks for the advice. It makes sense.
But I was just wondering how code library could be systematically organized.
For example, as a person continues programming for his job, he will notice some of his code could be reused.
So he/she will create a library of his own so in future projects, he can access them any time.
This is fine because a person can keep track of his code library and organize it the way he wants it.
But if this involves a group of programmers, people wouldn't know what others have in their own code library.
So they might be spending time creating and organizing their library when it has been already done by somebody else.
I feel like if its a small group of programmers(2-10) working in the same company,
there should be a way to share and organize that library.
06-12-2014 12:04 PM
You should have a repository of reuse code. If these are packages, JKI makes it really easy for you to build the package and then update the repository. VIPM can also be set up to look at this repostory and pick up any updates to these packages.
You should also be in constant communication about when a package is available or when you want to submit a VI for reuse.
06-14-2014 05:49 PM
Constant communication and VIPM seems like a good idea. Never used the proprietary edition of VIPM, I wonder how good it is.
If you dont mind sharing with us, how do you organize code reuse at your workplace?
06-16-2014 12:40 AM
A simple way I use to share the code between projects is by giving a general name to all the code that I can use for another project. So whatever the code that I believe can be reused, I keep it in a seperate folder and anytime I can pull the code from there. Considering the main application code as already said it depends on the way to create the code. For the most part I go for the sub vis wherever possible and then its easy to cleanup and use it for other application. Creating a seperate repository for the reusable code helps good.
06-18-2014 08:20 AM
I am also interested in hearing how people organize their re-use repositories, as I'm just getting started setting up using Tortoise SVN and the Viewpoint Toolkit
I tend to work on many different unique projects throughout the year, but tend to re-use some common pieces of code depending on the project.
For SVN you have to check out the entire folder, so what works for a folder structure?
REPO\ [top level]
\COMMON\
\DRIVERS\
\PROJECT\
\COMMON\ would contain folders of unique specialized function groupings
(Ex subfolders could be Timing, TDMS, FileIO, GUI, GPS, etc.)
\DRIVERS\ would contain folders of specific instrument drivers by sensor or device, usually *.lvlib
(Ex Garmin, GX2, GX3, GX4
\PROJECT\ would contain a folder for each unique project throughout the year
Question: If I check out \Timing\ and \Garmin\ into a working directory, then check-in a Project folder, are the Timing and Garmin folders still linked and updated in \COMMON\ and \DRIVERS\ ?
06-18-2014 01:34 PM
I just read another "better" option is to have multiple repositories?
Then should each "module" and project folder be its own repository?
Examples from before would be for a repo for each of the following: Timing, Garmin, and Project
How are updates to Timing and Garmin handled if updated in Project?
Looking for some feedback from experienced SVN users.
Thanks.
06-18-2014 05:53 PM - edited 06-18-2014 05:54 PM
@Stranman wrote:
I just read another "better" option is to have multiple repositories?
Then should each "module" and project folder be its own repository?
Examples from before would be for a repo for each of the following: Timing, Garmin, and Project
How are updates to Timing and Garmin handled if updated in Project?
Looking for some feedback from experienced SVN users.
Thanks.
In a way, yes. Your revisions can quickly get into the thousands if you have a lot of projects. Plus, in the event a repository gets corrupted, it's not THE repository.
06-27-2014 06:41 AM
What is the Subversion behavior when a module that is part of its own repository is added and included into a project that has a repository.
Does the module maintain its link to its originating repository?
Thanks,
- P