Commence a weekend of trying to catch up for class on Monday.
Unfortunately, the majority of my time so far has been spent on OOP, so I haven't had that much of a chance to start projects or do readings for my other classes. Good news about that, the deadline for the first project in this class will be much sooner than for my other classes, so I've got some time to get my other classes figured out before my time away from school comes back to bite me in the butt.
As several other people have mentioned, the threat of an all-or-nothing grade for this assignment is making this a very stressful project indeed. I don't expect a zero, but I can't shake the feeling that I'm going to miss something important and get totally screwed.
Some good news, I finally figured out that I had an invalid assertion somewhere that was causing some of Sphere's inputs to get rejected by the assertion. Now Sphere is accepting my solution and I can move on to implementing a cache.
Labor Day Git Session
Labor day was definitely much-needed time to get some reading done for class and to get some extra practice with Git. One of the things I had been meaning to do was to source control my .bashrc and .bash_aliases (and various other settings files) so that I can easily transfer them between my various Linux boxes/VMs and the lab computers. Since I had some settings on several different systems, this gave me a chance to try out Git's branching and merging features.
From trying to use Git's branching and merging features, I've come away with some impressions about Git compared with Mercurial. Anyone who has spoken to me in class probably knows I prefer Mercurial over Git, mostly because Mercurial integrates better with Windows, but I've definitely come to like some aspects of Git.
One thing which really stood out as a clear advantage that Git has over Mercurial is that branches in Git can be deleted, and in fact they often are. This is one of the major changes in workflow that I'll have to get used to. Git encourages creating a branch to work on an issue, and then when the issue is resolved, merge the branch into master and then delete the new branch. In Git you can keep your experimental branches to yourself.
In Mercurial, the whole idea around using branches is somewhat different because branches are around forever and are part of your commits, so they are pushed to the remote repository when you do a push. You can't keep experiments to yourself, or overwrite history of the repository, so once you push to a Mercurial repository, it is there forever, even if you abandon whatever you were working on. This makes collaborating on experiments a much more difficult, costly, or embarrassing affair in Mercurial. If you want to create a "branch" in a Mercurial repository to do an experiment, Mercurial encourages you to clone the repository into a different directory, and work on your changes there, and then if you like what you did, merge your changes with the main branch. Branches in Mercurial are good for keeping track of collaborative work that spans a long period of time, or keeping an active Dev branch and then merging into the main branch when everything has been stabilized (รก la many corporate systems for version control management).
I would definitely say based on the above that if creating branches to work on issues is your preferred way of doing things, then Git is the system for you. However, I have found that Mercurial gets along just fine without that and since there end up being more branches in Mercurial repositories, the branches tend to have more utility in Mercurial.
The big thing that's going to keep me with Mercurial though when I'm working primarily by myself and/or on Windows is the simple fact that Mercurial is written in Python and so is naturally cross-platform. This makes it a wonderful experience on Windows. Git for Windows bothered me so much that I'm now primarily working in a Linux VM or on the lab computers.
I was so excited when I learned about making command aliases in Git because that means a little less typing for me. However, it seems that the Windows version of Git is not able to deal with command aliases. Thanks Git. -.-
Settings Repository
Well anyway the happy result of my experiments with Git is that now my Settings repository is available on Git. If you'd like to check it out and take any of the snippets for yourself, feel free to have a look.
I rely heavily on aliases that will mostly only make sense on my systems, since I use them to quickly switch to specific directories in my file structure.
However, I do like the colorful prompt I've come up with. This started when I tried out Arch Linux for the first time and saw that the default prompt is colored, which makes it very easy to differentiate your prompt from the output in between, which also happens to make it easier to see when the output of a command begins and ends.
Here's a screenshot of my prompt and the specific lines you'll need to make this work on your system as well. (Assuming bash obviously.)
..
Project Progress
Now that I've gotten more comfortable with Git and I have my Linux VM up and running, I'm making a lot more progress. One of the most frustrating parts of the project is writing the unit tests. Since this project is primarily focused around computations which would be tedious by hand, properly testing the evaluation functions is either going to require that we trust that our program already did it correctly (which will be useful later after the unit tests have been created with the quick-and-easy approach and then changing the implementation to use a cache), or to find some table of solutions online, or having to compute the answers by hand.
I'm still working out the best way to do this, but either way I'm making some progress with adding unit tests to my project.
Does anyone else think it is funny that we can technically see other peoples' unit tests and acceptance tests? I'm not planning to look at anyone else's until I've done my fair share of my own work, but it could definitely be helpful to add some extra tests if we're allowed to borrow other peoples' unit tests and acceptance tests as extra assurance that our programs are behaving correctly.
I'm still working out the best way to do this, but either way I'm making some progress with adding unit tests to my project.
Does anyone else think it is funny that we can technically see other peoples' unit tests and acceptance tests? I'm not planning to look at anyone else's until I've done my fair share of my own work, but it could definitely be helpful to add some extra tests if we're allowed to borrow other peoples' unit tests and acceptance tests as extra assurance that our programs are behaving correctly.
No comments:
Post a Comment