VirtualBox has a nasty little habit of suggesting small virtual Hard disk sizes when creating Guest Virtual Machines.
Anyone who has worked with Windows guests knows that 25.00 GB is ridiculously small for a standard install of most versions of Windows Server (excluding Windows Server Nano).
My general rule of thumb is to increase the default Hard disk to between 60 and 80 GB depending on the purpose of the Virtual Machine. Though it is easy to be caught out; And you are now in a position where you will need to resize the guest Hard disk. To complete this task we will make use of the VirtualBox commandline tools.
The steps below were tested against VirtualBox 5.0.16
Step 1: Backup Everything!
Ensure that the guest virtual machine is in a Powered Off state.
Backup the guests Hard disk. In my case I created a copy of the guest Hard disk on a separate drive.
Step 2: Ensure the VirtualBox commandline tools are in your PATH
Open the Environment Variables dialog confirm that the following is present in your PATH variable.
On Windows 10, this can be done by searching for environment variables with Cortana.
If it is not present in either the System or User Variables path, add it. My personal preference is to add it to the User variables path as shown in the image below.
Once completed, Open powershell and execute the following:
Which should result in output similar to:
Step 3: Resize the Virtual Hard disk.
In order to resize a disk we need to execute vboxmanage with the modifymedium option.
In previous versions of VirtualBox the option was either modifyhd or modifyvdi.
vboxmanage modifymedium disk NAMEOFDISK.EXT --resize SIZEINMB
In my case I executed the following:
Step 4: Boot and Resize the Disk in your Guest OS
If all has gone well, the final step is to boot into your guest OS and resize your drive partitions.
The steps for which are heavily dependent on your Guest OS and can be readily found on the internet.
In July of 2015, I made my first real organizational change in 13 years. Moving from the safety and security of what was an extremely cushy Software Engineering role with AussieWeb into a more formal consulting role with SSW. After six months of consulting, I have decided, with some consistent prodding from my family that the consulting was not for me. Don’t get me wrong. I’m not saying that SSW isn’t a great place to work; it is (and they are always hiring), it’s more that I wasn’t enjoying developing enterprise applications. I was starting to feel the itch to be back developing productized services and SaaS applications at scale. Rather than being constrained by corporate technology choices and the ever present “billable by the hour” world of consulting.
Luckily for me; one of the staples of the Brisbane tech-community, Joshua Wulf, all round nice guy and Legendary Recruiter with Just Digital People had some inside knowledge of a Brisbane based organization that not only had a need for someone with my skillsets, but was also family friendly. Suffice to say I did not hesitate when Josh mentioned that the two founders Neeshil Pabari & Joe Antonini would like to meet.
When I arrived at the Lüp (pronounced Loop) office, it immediately felt familiar, very similar to what I had previously been accustomed too at AussieWeb. My initial meeting with both Neeshil and Joe immediately answered any question as to whether or not Lup would have the type of high performance culture that I was looking for.
Lüp itself is an interesting organization; one that has a distributed team, and provides a unique solution to the problems faced by exhibitors at large scale events. Though what caught my attention was the mixed technology stack, the need to scale quickly when needed, and the opportunity to work on some challenging big data and optimization problems.
I don’t think it is a stretch to say that I am looking forward to the new challenge.
I am currently working on a legacy application that has recently had a “solution” upgrade to work with Visual Studio 2015.
During the course of my work I have encountered minor Code Lens attribution bug.
The bug essentially attributes test results of a child class, to the base class from which it is inherited.
The test results are then propagated up the class hierarchy to all classes which inherit from the base class.
Create Unit Tests for new Attribute
Figure: Unit Tests for RemoteRequireAttribute
Create ActionFilter that inherits from RequireHttpsAttribute | ActionFilterAttribute and implement functionality.
Figure: RemoteRequireHttpsAttribute class signature
Execute Tests. All Passing
Figure: Passing Unit Tests
View another class that inherits from ActionAttribute. VS2015 Code lens now shows 5 of 5 tests passing.
Figure: 5 of 5 passing tests
Closer inspection of the tests shows that the are not related to this class, other than the base inherited classes.
Figure: 5 of 5 passing tests are all for RemoteRequireHttpsAttribute ActionFilter.
For those of you who are wondering what my system looks like:
Surface Pro 3 - Max specs.
Windows 8.1 Fully patched and at the latest version
.Net 2 through 4.6 installed and fully patched to the latest versions
VS2013 and VS2015 are both installed and fully patched.
This is due to Homebrew installing packages into /usr/local/Cellar/ and then symlinking to /usr/local/bin by default.
Normally I would advise updating dnvm via Homebrew like so:
brew update; brew upgrade dnvm;
However as Brennan Conroy mentions: “Unfortunately we don’t support upgrade through homebrew”.
Figure: Unfortunately we don’t support upgrade through homebrew.
The correct method as of August 16th 2015 to upgrade dnvm if installed via Homebrew is the following:
brew remove dnvm; brew install dnvm;
Personally, I find this to be somewhat of an issue, though given the beta nature of ASP.Net 5 it’s to be expected. At this stage I am investigating the viability of a patch to dnvm.sh to support dnvm update-self from a Homebrew install. More on that at a later date.