Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

I'm not being critical but... (Re-use) Part 2

swatts
Active Participant

Hello Hunnies

Over 4 years and a 100 articles ago I wrote "I'm not being critical but... (Re-use) Part 1" and amongst the 20 or so people that care about such things it caused a bit of a stir. I think it might be worth revisiting this and talking about something Greg Payne brought up in CSLUG the other month.

 

Here's a link to his article on the topic

 

If you've not read the aforementioned article I strongly recommend reading it and also all the comments too. But to summarise I expressed the opinion that the current and LabVIEW model for reuse sucked and explained that you can have source-code control where project code is in the repo, but if the dependencies (user lib, instr lib and even unprotected vi lib files) weren't also under source-code control a high-percentage of your code could be modified without control.

 

Various techniques for handling this issue were discussed and at SSDC we settled on making all of our projects atomic (various articles and presentations describe this). This sorted out the control but made re-use a little cumbersome, so I would mark it as about 8/10. Here's some pros and cons

 

Pros

  • Every project is self-contained in the repo.
  • Easy to manage.
  • Portable from machine to machine.
  • No cross-linking

Cons

  • Managing re-use across projects is cumbersome and manual
  • Each project repo is big

The presentation that filled me with enthusiasm at CSLUG was given by Greg Payne and he talked about was Git Submodules (SVN External Items may also work). So for now let's talk just about a repo and external links to other repos.

 

Submodules.png

A project will have links to a version of a toolkit, dependency or library (including a hash number for traceability). The VIs will from all the linked repos will be checked out as you would normally checkout a project, but there will be notifications if a toolkit can be updated. You could also push back requests and updates for a toolkit.

 

A nice user interface for this would be a palette of toolkit repos that you can include into your project and this needn't be much different than the palette view currently available. Additional info would be version data I reckon. Some search, bug reporting and registration interfaces would also be useful. 

 

And that would be perfect.

So we now have the challenge, this is all very possible IMO.

 

Thought food and homework peeps

Lots of Love

Steve

 

 

 

 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments