Jump to content

How do you organize your code reuse repository


Recommended Posts

Hello.

It's my first time posting on LAVA. :)

 

I recently posted the same topic on the NI forums, but I wanted more feedback so I am posting it here as well.

 

So my question is how do you guys organize the code reuse repository at your workplace?

Is it on an individual basis or is there a systematic way?

 

Any idea is appreciated, thanks!

Link to post

I kudo'd the second post talking about how the reuse mindset is more important then the actual code.

 

In addition I deal heavily with VIPM, as I hope all reuse libraries do.  Making a package is easy and can install things to the palette, change LabVIEW.INI keys, add tools items, add quick drop functions, add templates, add quick drop shortcuts, add glyphs for the icon edtor, and do all kinds of things.  

 

I work at Magna where we have many packages.  One issue that comes up is if you have a package, that has a dependency of another package, and the second package has a dependency of the first package, then strange things can happen and it is generally a bad thing.  Because of this I have made a handy reuse dependency map.

 

post-6627-0-28411100-1403268186_thumb.jp

 

I wish this could be done automatically but it probably wouldn't look nice.  Basically this shows each package in our package configuration file, and what internal packages have dependencies on what other internal packages. When making creating new packages, or updating old ones this helps me understand what links already exist, and helps avoid the situation I mentioned earlier.

Link to post
What did you use to make this? I assume yED can produce something similar, but I like your chart.

I knew I saw something like this.  Thank you I will look into automating it in the future.

Link to post
  • 3 weeks later...

Wow I didnt realize the default setting for notification was off until now.

 

In addition I deal heavily with VIPM, as I hope all reuse libraries do.  Making a package is easy and can install things to the palette, change LabVIEW.INI keys, add tools items, add quick drop functions, add templates, add quick drop shortcuts, add glyphs for the icon edtor, and do all kinds of things.  

 

This should be enough reasons for the paid version of VIPM.

My boss is trying to save money by creating installers for code reuse :(

But how do other developers know if more code has been added to the reuse library? Is it notified through team meetings?

Link to post
My boss is trying to save money by creating installers for code reuse :(

 

Stupid boss :P

In a time before VIPM, an installer (or in my case a solid zip file) used to be a good solution, however since a couple of VIPM versions the feature to create packages is available even with the community version. Also still working is the OpenG package builder (however I recommend VIPM). Just try it, it works like a charm (but keep in mind: there are certain limitations because of the license).

 

But how do other developers know if more code has been added to the reuse library? Is it notified through team meetings?

If you want to automate the process of updates you should get a license for VIPM and setup your own repository. Once you publish a new version everybody who is registered (also requires license) will see a * on the package. In terms of cost, the time spend to tell everybody that an update is available (meeting, or sending mail with everybody copy-pasting files) vs. sending a mail and everybody clicking 'update' in VIPM should be considered (again the VIPM solution is solid and tends to work where a manual task causes issues that could be avoided).

 

In my case we send mails with a link to the new *.vip file, so it is only a matter of a couple of clicks. 

Link to post
My boss is trying to save money by creating installers for code reuse :(

 

Installers are probably the worst option for toolkits/reusable code within a company. Sure if you are going to distribute to third parties it warrants the extra effort, but internally it just adds more overhead for pretty much everything (coding, testing and documentation) as well as causing all sorts of problems with version control. It has few, if any, benefits.

 

A far superior solution (and generally free) is to use your favourite flavour of source code control for distribution from a central server. It does come with some caveats, but it is infinitely better and more flexible than installers.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By 0_o
      Hi,
      This is not specifically LabVIEW related:
      How do you organize important posts you read and want to save for the time of need?
      For example, I want to save an interesting post from Lavag/NI Forums or any other LV blog.
      This post might contain VIs and I would like to tag it in a way that will let me find it when it becomes relevant.
      I would like such a post to be saved locally like an RSS so that I'll get the new comments and won't depend on the site to keep the links alive.
      I see the veterans here keep track of all the new posts and even offer solutions by giving links to some old posts without having to search for them sometimes.
      Do I miss something? How do you organize it all? I hope to hear of some cool little RSS app that will let me search through the tagged vis and posts stored on my computer and not about some bookmark manager.
      Thanks in advance.
       
    • By RedAndGreen
      I often have to create interfaces for power supplies. I often use the QMH for my overall architecture.
       
      I have created a QMH that controls multiple power supplies. It was designed in such a way that it takes a minute to add an additional power supply. Of course I am using Dynamic Dispatch to use multiple types of power supplies. It works quite well.
       
      I am trying to get better at LVOOP and plug-ins. I was thinking of creating an abstract class that contains a QMH for just one power supply. Of course I would create children for several types of power supplies. My plan with the single QMH for each power supply would be to use it as a plug-in or use a sub panel so that all the QMHs are on one UI.
       
      If anyone has any advice on the methodology please feel free to comment. Also I am new to LAVA so I hope I am not asking something that has already been solved.
       
       
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.