We got Labor Day off this week, so we only had two classes. An alumni from UT who now works at Bloomberg came and gave a talk on Wednesday, so we really only had one class.

I only had two classes last week as well, but that's because I was in Virginia. Everyone else (give or take) had three classes.

One thing that occurs in this class is that outside speakers are brought in to talk about life after UT. So on Wednesday we had an outside speaker who talked about his life at Bloomberg. He gave some tips about resumes and interviewing, so that was handy. Of course, the talk had a certain slant towards us applying to Bloomberg. It seems like a nice place, but I'm not sure NYC is cut out for me. They probably have tighter UAV laws - Austin has plenty of open fields which will let you fly UAVs on them, so maybe this summer I'm going to stay in Austin again.

We didn't do much on Friday, we just talked about exceptions. We also mentioned pass-by-reference, but that is a rant that I will save for another (slower) day. I already have a rant for today.

We finished the Collatz project this week. I have little to say about the project that I haven't said already: it tries to teach us tools by forcing us to use them without any rationale (see my prior rant on issue tracking).

For instance, I believe that source control should be used to control source. It is not a tool to control built files.

Doxygen is a tool that generates documentation. The documentation comes from comments in the source code of files, and Doxygen can be controlled using a Doxyfile much like how make is controlled with a Makefile. Doxygen generates HTML documentation and plops it into a html/ directory.

Proper use of source control, I think most people would agree, would be to commit the source code and the Doxyfile, and not the html/ directory. The html/ directory is generated, and committing it would be like committing a compiled binary.

But alas, the project requirements require us to commit the html directory and not the Doxyfile, even though we hand-modified the Doxyfile.

What's the lesson we're being taught? I don't know. I hear people say that we are being taught valuable lessons that will apply to industry.

To be honest, if I were an employer, I would rather hire someone who had never heard of git but was able to learn than someone who knows the git commands but commits binary files and random log files. It doesn't take much time to pick it up. Everyone in this class picked it up in the span of a week (or dropped the class).

Which brings me to...

Tip of the Week: Don't blindly use git add -A before every commit. You will eventually grab all manner of binary files, temporary log files, test files, editor scratch files, and so forth. When you do eventually grab those files, you inconvenience everyone else.

Story time: In Spring of 2015 I had Dr. Rellermeyer for Operating Systems. There was a big final project for the second half of the semester, which was to build an operating system that would run on an ARM chip (Raspberry Pi, in particular).

That project was unlike any other class project. We were essentially a pretend company - Dr. Rellermeyer was a customer, who said "I need an OS that can run a binary". The rest of us self-organized to accomplish that goal, like any real-world company [1].

There were two dozen of us working on the project, all frantically compiling the code and trying to get it to work. One day somebody accidentally pushed the binary executable and 20MB of log file. For the next week, everybody got a nasty case of merge hell, because the binary changes on every commit. On top of that, they would overwrite their own binary whenever they pulled from the repo, and then spend forever trying to figure out why their code didn't seem to be running.

To rub salt in the wound, ever since the repo takes roughly forever to pull.

I think eventually someone got around to rebasing it, but rebasing public history is nothing but pain.

Moral of the story: If you didn't add or remove any files in your commit, don't run git add -A. git add individual files, or use git commit -am"commit message".

[1] I guess real-world companies usually start with 1 or 2 people and add more, rather than starting unorganized with 20 people, but maybe we're talking about a company that had grown to ~100 people and ~20 interns before smart buses eliminated everyone who wasn't a fresh intern.

This is an image of me doing what I do when I'm not at a computer.