It is recommended for any project that you start by setting up a Virtual Machine first. It is really up to you if you want to do this step but Sam Taggart, CLA and LabVIEW Champion of SAS presents some good reasons you should:

• Using Virtual Machines Part 1
• Using Virtual Machines Part 2

Setup depends on the Virtualization software you choose. As Sam stated the two major ones are:

From Sam's blog:

"There are basically 2 ways to create the initial VM to use for your base VM. One way is to create a VM from scratch and install Windows using an iso. In VMWare, it is pretty straightforward and there are plenty of tutorials online if you get stuck. A quicker way is if you already have a physical machine is to use a free tool from VMWare. It takes a physical machine and converts it into a virtual machine. "

For VirtualBox, see the online manual here for instructions on setting up your first machine. After you have one up and running, you can clone it using the Clone Virtual Machine wizard. (See the online manual here).

Again quoting Sam:

"Whichever one you use, you want to be conscious of the size of the hard drive. You want to make it as small as possible and yet have enough space to do whatever development you need to do. Somewhere in the 50-100Gb range seems to work well. NOTE: You can expand it later. Also there may be an option to preallocate the entire harddrive space. Don’t do that. We want it to grow as we fill it to save space on the host. "

Before installing anything else you might want to consider what software you want on your base VM. If you want to avoid setting things up from scratch again, create a base VM first, clone it to make a working VM, then install the software that is project specific. The specific software might include which version of LabVIEW/LabVIEW NXG to install.

For working on the GCentral Indexer there might be other software you wish to install but at a minimum you will need:

• LabVIEW NXG 4.0
• LabVIEW 2019
• Git for Windows

Other software suggestions include:

• SourceTree (Git Client GUI, easier than Git Commands)
• Chrome, Firefox, Opera, etc. (If you don't like I.E. or Edge)

If you are new to Git for source code control and chose to use SourceTree (and I recommend you do) here is some help getting SourceTree set up and connected to the GCentral repository.

1. Open the GCentral GitHub repo in a browser. The repository is located on GitHub at: https://github.com/gcentral/Website

2. Fork the repo to your own account:

One of the files that comes with the source is a Dependencies.vipc file. This is a VI Package Manager Configuration file. Open it with VI Package Manager to install all of the dependencies.

The indexer for the GCentral Website consists of two projects:

1. The NXG WebApp
2. The LV WebServices

Remember, its best practice to commit your code often with detailed change messages. Refer to best LabVIEW coding practices on the LabVIEW Wiki and ask questions if you get stuck on the GCentral Development Question section on LAVA.

After you have finished the changes you wish to contribute, you can submit a Pull Request to us to review your contribution. Instructions for how to do this can be found here. (For any other GitHub help click here.)

These first suggestions are from Matthias Baudot, whom created the indexer:

• Refactor the storage of Packages on the WebServices in a Database instead of a file as it is now. I think using SQLite would be a good idea since it doesn’t involve complex infrastructure with the need to install a database server. The WebServices will need to be modified to go look for packages in that database instead of looking at the Repo global variable.
• Implement a Configuration File for the Web Services where we can specify the repositories to be fetched (GPM, VIPM, NIPM). Right now, there is only one GPM repo and 2 VIPM repos. When we will add NIPM, it will be important to be able to specify the feeds in a config file rather than rebuilding the WebServices when a new feed needs to be added.
• Currently there is some complexity in the code which allows having unique URLs for each Package and Version, so it is easy to give that URL to someone to have him landing on the right page immediately. It is also useful for Search Engines indexing since a unique URL will exist for each package version, without having a real HTML web page. This makes the whole code more complex than what it should be. Maybe some people at NI, or someone with JavaScript knowledge can help remove this complexity. Probably by using JavaScript from the WebVI to programmatically retrieve the URL attribute and display the proper package version.
• Rating packages
• User Login allowing them to register private repos/feeds

Have ideas of your own? Please, share your own ideas on GCentral's discussion thread on LAVA.