first-questions.txt

### Question 1
If you are going to install something on Linux, what are the different ways that could be done?

In the overwhelming majority of situations linux software is installed either by using a package manager or compiling from source. As a long time Debian user, I install probably 90% of the core software I use via apt, and in many ways the Debian *is* apt to me. I’ve learned to fix installation problems using some combination of apt and dpkg, and more than any other reason that familiarity is why I use Debian. 

In recent years many companies and developers have built their own package management apps on top of their language or application. Ruby gems, Python packages, Go get, NPM and NVM, and cloning repos from github are all common ways to install additional software on a linux system. This allows their particular software ecosystem to be maintained outside of the mainline OS. 

Compiling from source usually allows the greatest degree of choice for the who/what/where/when/how of adding software to linux. This can present some problems if working on a cloud install or a system owned by someone else, as one needs build tools available and often write access to places like /usr/bin that an administrator might have sensibly locked away from users. Still, nothing gives more control over installing software than compiling it by hand.

As a quick example for which does what. For some reason I have become accustomed to using the `tree` command on linux machines. Since tree is a pretty standard critter, and not revised all that often, adding it with apt from the standard Debian repos is just fine. Tree doesn’t change much and is available in every distribution of linux anywhere. If I’m installing Docker their installer adds their own repo to whatever linux distribution is being used. Once that is configured on Debian apt will install and update Docker from the same CLI as the generic Debian repos (this is also what the Gitlab install shell script does). Adding the Docker repos to the distribution gives the convenience and familiarity of the standard distro package manager while still allowing Docker to update and modify their application on their schedule. Finally, one of the things I usually install from source is Vim, for the simple reason that one of the bundles I use expects Vim to have lua support, and it’s surprisingly tricky to get Debian Vim installed via apt with lua. Or at least it was for me. Luckily Vim from source is one of the easier installs out there, clone the git repo, run config with a few flags, and install. 

### Question 2
What are the advantages and disadvantages of using a Web framework such as Rails?

In my mind all Web frameworks are there to make some standard set of Web technologies easier or more sensible for the developer to use. D3 packages a ton of standard HTML5 and SVG graphics with some basic data sorting/processing into fairly rational Javascript functions. AngularJS provides two way data binding to the model, DOM manipulation, templating, and other tools via (more or less) lexically consistent Javascript. The advantage of those and any other Web framework should be that a developer can avoid some of the heavy lifting and boilerplate code, letting her concentrate mostly on what an application is supposed to do.

For me the disadvantages of using a Web framework generally involve choosing the wrong hammer for the nail at hand. Obviously this varies depending on the situation, but as an example, the two way data binding in AngularJS can be pretty costly as an application tries to scale, and it is often fairly chatty over the network. If processing power and network latency are not issues then nobody ought to care, but if one is trying to push data over the wire to users on cell phones in Bangladesh one can run into problems. I guess then choosing the *right* framework for the job is crucial. 

Last but certainly not least, Web frameworks often have communities and cultures built around them. To say that I am not a Rails expert is to wallow in understatement, but the Rails community has a top flight reputation for being transparent, helpful, and inclusive. If one is choosing to spend many hours over many years working with many people on a piece of software, those community attributes can easily be far more important than anything technical  Technical problems often have workarounds, unpleasant human interactions often do not. 

### Question 3
What would you do if you found a bug in your software and wanted to use git to help identify when this problem started?

Git bisect is probably the best option here. Git bisect allows two points in time to be set; a previous known good version and some broken version, usually the current one. Git then picks a point roughly halfway between the known good and known bad versions. That point in time can be checked out, compiled, and tested. If that first bisect tests OK, then git assumes the bug is further forward in the commit history and does another bisect between the current checked out (good) version and the known bad version. If, instead, that first bisect tests bad then another bisect is done between the current (bad) version and the previous known good version, since the bug must have been introduced prior to the current bisected checkout. This process continues narrowing the commit history until the precise commit that introduced the bug is located. While this might seem a bit cumbersome, it is almost always vastly easier and faster than checking out and testing every commit in order. 

Also, though this does not involve git, if the gods are feeling kind there may be log files.

### Question 4
Describe the resources or steps you may use to resolve a customer’s problem when you don’t know the answer. (Make assumptions wherever you need to about how the GitLab team works).

First, I always note that the customer needs to know that the problem is being worked on to get a resolution. Second, I would send out a quick note via whatever internal communication system is used to see if anyone else had already fixed the problem or a similar problem previously. Often there is internal knowledge that might not have made it into documentation, so it is located is someone else’s brain instead of somewhere it can be read. If that is true, then the quickest fix can be found there and then one makes a note to include that in doco or something similar. Third, I would try to reproduce the problem locally, to narrow down whether the issue is related to the software I’m supporting or if it is an issue with the network/config/crypto/install on the customer end. Depending on what that reveals, the issue could be a problem with our software or a problem with something else. If the issues seems to be external, then going through the doco for the likely suspect, searching StackOverflow, and so on can be, for better or worse, the only way to fix something. If the issue seems to be with our software and is not covered by existing internal materials, then it is probably best to bring people into the loop who work on that part of the application. That might involve talking to other support people, the QA team, or developers, depending on the problem. When some sort of answer is available, then I always try to get back in touch with the customer as quickly as possible.