Thursday, October 12, 2017

And.... we're back!

I decided to try to resurrect this blog again. The biggest hurdle isn’t getting started, it's finishing a post; finally having it good enough. I’ve started several posts over the past few years, but never finished. Realizing this though, the knowledge I may never publish starts to becomes an impedance to starting. I’ll try to overcome that through high-level outlining and shorter posts, breaking things up if necessary.


On the way home from work yesterday, I decided I wanted to do more reflective writing. To me this means: Looking at my life, deciding what I want to do or change, coming up with a plan if possible, and documenting it. There is something about writing that I think makes reflection more deliberate and effectual. Without it, I think a train of thought can become interrupted and trail off without any resolution. I used to do this often in college but haven’t done much of in the past 15 years. This post serves as a public version of it.


I also decided I wanted to focus on trying to do three things on a regular basis: Learn, Do, and Write


I feel like I’ve done well with learning. I’ve completed a lot of MOOC courses (I recommend starting with Learning How To Learn on Coursera) and reading (currently reading Thinking, Fast and Slow) but I’d like to continue and increase this.


“Do” more or less means projects, mostly software, but it could be some sort of hobby building or community service. I’ve started but abandoned a few things. I will probably pick a couple of them back up, specifically an engine for the board game Sorry that I can develop AI / Machine Learning players to simulate against each other as well as a machine learning approach to playing Ultimate Tic Tac Toe. Ultimately, I’d like to do something that is more widely beneficial but this will be a start.


Lastly writing is a way to share what I learn and do, as well as accomplish my goal of more reflective writing. Again, this blog provides an avenue to do such.


Some things I might post about soon include:
  • Things I like about my new house
  • My new job and commute
  • Plan and progress on my personal software projects

Thanks for reading

We are a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for us to earn fees by linking to Amazon.com and affiliated sites.

Thursday, April 7, 2016

Maintain System Responsiveness when Running a Parallel Visual Studio Build

The recent addition of encryption to laptops with spinning platter drives has proven painful for many developers on my project. A big complaint has been the lack of responsiveness of the system while doing a parallel build. Tasks that should be nearly instantaneous take several second to nearly a minute. Since some of these tasks such as switching between files or applications might need to occur many times in a minute to complete a larger activity; these delays stack and take away the opportunity to be productive doing other things like preparing slides or creating documentation. This article provides a work around to solve this problem until SSDs are available to all developers who need them. Note that improving your system's responsiveness while building will increase the time that it takes to build.

This method works by lowering the I/O priority of the processes doing the build. This is not possible using the built in Windows Task Manager. Instead use either Process Explorer, which is available for free from Microsoft, or Process Lasso, which has a free evaluation but requires a paid license for commercial use. Process Lasso also has a neat feature that I'll go into more detail about later that automatically changes the priority of the processes any time a build start.

Using Process Explorer you can change the priority of all MSBuild.exe1 processes to Background (Low I/O).

Using Process Lasso you can change the I/O priority of all MSBuild.exe1 processes to Very Low. You can do this "Current" which will only affect the currently running processes, or do it always which will modify any MSBuild.exe process currently running or created in the future while Process Lasso is running. It took some work to get this to work, I had make sure I had it configured to control all users processes, then make sure I closed and reopened Process Lasso after installing. If you want this feature to work, play with it and make sure it is.

A few things to note: If you work on some unrelated code and want to build a small project while a big parallel build is running, it will take a really, really long time for that small project to build. Get around this by cancelling your large build and letting your small project build then resuming your large build. Remember, the solution described here is just a work around, if you want to do things in a reasonable way, you're going to need an SSD. Also, if your system is unresponsive while building, you'll probably notice other times that it is unresponsive during heavy I/O as well. If you your system to always be snappy, you're going to need an SSD. And, once again, if you are using this method to do other things it will make your build take longer. If you want to be able to work while building and still have reasonable build times, you're probably going to need an SSD.

One other thing I noticed is that Intellisense can take a long time to run and its heavy I/O exacerbates the problem. I disabled Intellisense until I get an SSD which will make Intellisense usable again.


1. Its necessary to do this to the MSBuild.exe processes because they are always started at normal priority, despite their priority of their parent process

Wednesday, August 19, 2015

Git 2.5 handles multiple working copies, and its available now for Windows

Yesterday, I posted about tricks and scripts to support multiple working copies all using the same repository. Later in the day I realized Git for Windows 2.5 had been released. Now you can uninstall any previous distribution of Git, and install this. Any thing like GitExtensions or SourceTree will use it if you add Git to your path during installation. Then you can use the nifty worktree command to create new working copies that all point back to a single repository on your machine. This means native support for multiple working copies; no symbolic links necesssary.

Tuesday, August 18, 2015

A single git repository with multiple working copies on Windows

A project at my company recently transitioned from ClearCase to Git. The codebase is large and monolithic and as such a bare clone of the repository with relatively few commits is over 20 GB not counting any working copy files. Many developers have several clones of the repo to allow working on different releases without having to switch branches and rebuild all the code which is time expensive on this large codebase. This means having 3 or more copies of a growing 20 GB git repo.

Why is it necessary to have duplicates of the data in a repository on a given machine? Its not. Git has a user contributed script to create symbolic links to an existing git repository for a new working copy called "git-new-workdir". (Git 2.5.0 will have this feature baked in, with the worktree command EDIT: Apparently it has now been released for Windows.) When I attempted to use this script from git bash on Windows, however, it created a copy of the working copy instead of referencing it with symbolic links as intended.

Eventually, I found a branch of it for Windows that uses mklink to create the symbolic links. I put the script in the same directory as my working copies so that I can navigate in git bash to that directory and run it with "bash git-new-workdir-win". It expects the path to the original repository (on your machine), the path to the desired new working directory, and optionally the branch to checkout.

Before I found this script, I was able to get the same functionality by manually creating the links following a guide I found for getting this functionality on Windows XP. Note that the script yields slightly different results that are probably slightly better than this manual process, although either solution works. Specifically, the script does not symbolically link the logs directory but does symbolically link a few of the files such as "config" found in the root .git directory.

If you have existing working copies you want to convert to using symbolic links without having to recheck out code, you should be able to retain them and use the manual method to overwrite the directories within the .git directory, or run the script to create a new working copy, then overwrite the directories and files in your existing .git with just the ones that are symbolic links in the new working copy. I'll take this opportunity to give a shout out to Link Shell Extension, which is a great shell extension for creating symbolic links, hard links, etc within Windows Explorer without having to use mklink through the command line. This extension will make it obvious which directory elements are symbolic links in Windows Explorer. Also make sure you've pushed any commits/branches you want to keep before overwriting things inside your .git.

Since symbolic links will fail if the source they are pointing at are removed, I first moved an existing repository to a safe place on my machine, then replaced all my existing repositories/working copies with links to this repository using the mechanisms mentioned. This mitigates the risk of accidentally deleting the source of your symbolic links if you were to use an existing working copy's repository then some time later remove it when it is no longer needed. If you want to start with a brand new repository instead, you can pull down just the .git directory without creating a working copy using git clone --bare.



tl;dr: Get this script and run it

Wednesday, April 27, 2011

First post

   At the suggestion of a friend, I have created this blog to supplement Facebook in providing an outlet for sharing my greatness. Actually, I'm genuinely interested in producing something that is entertaining and a bit less narcissistic than Facebook. I'll consider this a success if after reading each post you can't wait for the next. The blog should contain plenty of humor and interesting subjects whether it be food, drink, film, or me trying new things. Some ideas for upcoming posts include: A fried egg/fried chicken sandwich, model rocket launching with the boys, trying out bonsai, and an interview with Colin Firth. I think it will be a bit like a combination of Jack Handy and Alton Brown. Although really no comparison should be necessary, its me, after all.