Configuration Management¶
When I started in this 2022 fabacademy I expected to just start making things. Being behind my computer the whole bootcamp week and also the first assignment week was a bit dissapointing. My first reaction to our local instructor was: “I didn’t know fabacademy would try to transform me into a nerd!” I’m old enough to remeber MS-DOS, so working on the terminal feels a bit like going back in time. And it is so strongly advocated by the fablab community that in my head popped up: “Come on, we moved away from DOS ages ago guys!”
But I kept quiet (most of the time) and tried to just experience what it would bring me. So here it is.
Pre Work¶
During the student bootcamp we already installed different tools like 3D-CAD, schematics for electronics, visual tools and of course git.
Installing various CAD and design tools are very straight forward. My latest active use of Autocad was probably version 13, but nevertheless it still feels familiar to me. Installing FreeCad or KiCad is not causing any difficulties. Because I might want to use it outside Fabacademy I’m considering to install Rhino too. I will check the trial version when we get to 3D modelling.
I’m not very familiar with software development, so I was lucky that several of my fellow students were. They gave me help and advice to install my repository, git and some terminal tools like homebrew.
Version Control¶
In (technical) product development version control is very important too, so I’m familiar to work with that. I know too that it’s often overlooked and badly managed, despite all the sophisticated engineering or product data management systems that are used. Using that, or Git is not a guarantee for success.
Before the existence of Git, my sofware developing colleagues used a simple system: They made a folder for each version they wanted to release and within they made sub-folders with the name “YYMMDD” representing the date. This is in line with the famous Philips dot-version and date-version system. Each partnumber Lookst like XXXXXXXXXX.KK.YYMMDD, where the “.KK”, the dot-version, stands for releases or versions that are different in form, fit or function. “.YYMMDD” represents a release date that is fully interchangeable with others that have the same dot-version, but of course most of the time you will use the latest date.
Why am I writing this? Because Git is maybe nice for collaboration or maybe useful for the group assignments, but for keeping track of my work for fabacademy it looks like an overkill. And what I’ve missed is the important part for product development: managing the product structure or the product breakdown structure (PBS). I will make one when I get to my final project.
Working with Git¶
As I already mentioned: Terminal. I vaguely remember how it worked in MS-DOS, but I haven’t been working in Terminal much, apart from an occasional tweak like showing hidden files. Biggest problem: finding out what is a command, an argument, an option or a flag and what they mean. What would have helped is just a simple list of commands, options and arguments and what they do. I haven’t found a good one yet. The most helpful were:
- https://blog.teamtreehouse.com/introduction-to-the-mac-os-x-command-line
- https://support.apple.com/en-gb/guide/terminal/welcome/2.11/mac
Git¶
Understanding Git in the end is not that complicated. A very good source which also explaines why everything works the way it works is the book you can download for free at: https://www.git-scm.com/book/en/v2. I haven’t read it completely, but the getting started and basics chapters are a good start for both understanding how the system is set up and how to use the basic functions.
For installation on my mac laptop I got some help from fellow student Bente. It basically followed the simple cheat sheet in the documents from fabacademy:
Specifically the generation of the public and private key was something I didn’t feel comfortable with. For a freshmen like me it feels like doing a monkey trick without understanding how it really works. Git was pre-installed already on mac:
% git --version
git version 2.30.1 (Apple Git-130)
Only thing to do is generate the keys and clone the repo available on gitlab to my directory structure on my laptop. First action was to setup my identity:
$ git config --global user.name "My Name"
$ git config --global user.email "my@email.nl"
Secondly I had to generate public and private SSH keys:
$ ssh-keygen -t rsa -C "my@email.nl"
$ pbcopy < ~/.ssh/id_rsa.pub
And then I copied the public key to the settings in the repo:
I made a separate folder for fabacademy with three subfolders:
- files: my local working directory with all rubbish and temp files
- libraries: basic files for KiCAD, Arduino, etc.
- saco-heijboer: the locaal version of the repo
In the last folder I opened a terminal and entered:
$ git clone git@gitlab.fabcloud.org:academany/fabacademy/2022/labs/waag/students/saco-heijboer.git
When we set up the “share” repo for our group assignment it turned out to be quite easy. New keys are not necessary, so just adding the repo with the command below was enough. Because it’s a collaborative repo the only important thing to remember is to pull first before committing to make sure I add to the latest version.
git clone git@gitlab.fabcloud.org:academany/fabacademy/2022/labs/waag/share.git
VScode¶
Bente also advised me to install VScode. Hardliners probably don’t like that, but to me it’s quite handy. In my workflow I use VScode for committing, pushing and pulling. It also has a terminal window to check what’s happening under the hood.
There’s also a preview available in VScade, but that is only displaying the body content. It doesn’t show the menu or the ToC. So I switched to the localhost preview running in the terminal:
mkdocs serve
Now I can check if all content is exactly as I want it before pushing to the repo. There are still some minor issues BTW. One of them is making a link to a chapter within a page, like this one:
[Version Control](2-configuration-management/#version-control)
In the localhost it will give an error that it can’t find the link. In the web version it mostly ends up working without any problem, but because I eventually still encountered some issues, I changed all lnks from relative to absolute. So e.g. the link above would change into:
[Version Control](https://fabacademy.org/2022/labs/waag/students/saco-heijboer/tools4projects/2-configuration-management/#version-control)
Use and usability¶
At first I was experimently committing and syncing just to see what happens. Changed some stuff, like some pictures without knowing exactly what I was doing. And I was lucky: my picture sizes were not adapted, risking a to large file to push to gitlab. It turned out just below 10 MB, so it worked, but it will be in my history for ever. There are ways to delete this file, but this a bit complicated and I decided it wasn’t worth the trouble.
This brings me again to the question about how much history you need. It’s nice to be able to get back to any point, but we, meaning the human society, are storing an ever growing amount of data on servers. The necessity of this data is often at least questionable. I will try to use Git wisely and make a balanced choice for pushing my changes to gitlab or not.