Home Office Usage Scenarios #1 and #2

People have asked me to write something about some of the typical usage scenarios that I often find myself in at my home office. Since those are generally not easy to explain in a few words and since they could otherwise fill up the FAQ page a lot I’ve decided to just write them as posts in the blog and relink those back from the FAQ page for details.

Note: This was written when I was using the old setup, not the new setup, so details now vary but the general idea of the content here is still the same and as applicable as it was before.

Screen configuration details:

• Helium: bottom center two monitors, input A.
• Oxygen: bottom center two monitors, input B.
• Halon: top center two monitors, input A.
• Argon: top center two monitors, input B.
• Isis: left-most top monitor.
• Osiris: right top monitor (4th from the left).
• Radon: right-most top monitor, input A.
• Hydrogen: right-most top monitor, input B.
• Others: No monitors, remote access only.

MaxiVista configuration details (typical):

The following configurations are the typical ones that I switch between frequently. The switching is performed by popping up a PowerPro custom menu and selecting with a single click which screen configuration I want. This will trigger commands to be sent to all required systems (via a custom written Windows Service process that runs in the background of all systems and VM’s) which will automate the otherwise manual process of configuration.

• Helium extends three additional monitors on Halon and Osiris in order to provide Helium with a 5 monitor desktop.
• Radon extends three additional monitors on Halon and Osiris in order to provide a 4 monitor desktop.
• Hydrogen extends similar to Radon.
• Argon extends two additional monitors on Helium.

Monitor and general details:

Isis and Osiris are the two main internet gateways and base servers in the network (mail, DNS, monitoring, etc.) and generally contain my Skype, a web monitor, a remote server/web monitor app, Magic Mail (a really lightweight mail checker that checks several of my key accounts for mail, had to adapt it a little by modifying the source to fit my purpose and display style), and are usually used to pop up a web browser in case the other monitors are cluttered with windows. Osiris acts as a video conferencing gateway as well as the primary backup server in case Isis needs some maintenance or a failover on the connections are in effect.

Helium and Halon are the primary systems used for every day work. Both can boot to either 32-bit or 64-bit and provide a bit of redundancy in case either of the dual boot systems gets hosed for some reason. Normally Helium runs 64-bit by default and Halon runs 32-bit, giving me direct access to both flavors without having to reboot anything.

Argon runs most of the core VM’s that extend the network to a full service ‘development center’ while Oxygen and Hydrogen will take over certain of those virtual processes and machines when there’s more specific work to be done. The other systems are used for a variety of things depending on the actual work I’m doing so it varies a lot.

Usage Scenario #1 (General)

Helium will be running the development tools (VS, etc.) and my editor(s) as well as the e-mail client, etc. The development environment and editor along with all associated windows (class views, etc.) and one or more command line windows usually take up at least the two monitors hooked up to Helium and extends to the above described MaxiVista configuration if more space is needed.

Halon will typically run MSDN documentation, other internal API and development related documentation, specs, designs, applications under test, one or two VM’s used in direct development (mostly to run some shielded processes) so that the center four monitors form a complete overview of what I’m doing at the time.

When important e-mail arrives that requires me to temporarily drop what I’m doing to look into a certain issue, problem, or piece of code on a different project I can switch to the other inputs on the monitors and using Synergy directly control any other system where I can start up a development environment for whatever specific details I need to access and look into things. This while not having to abandon the work I was doing prior to getting a message that has me re-prioritize something.

Switching between the dual inputs and systems, and thus switching between tasks that I’m doing means that I lose very little time in closing down one project in order to focus on another. Of course this doesn’t happen a dozen times a day, some days it never does, so the mental switching between projects is usually limited to situations where more than one project finds itself in crunch-time. Digitally speaking this is somewhat similar to having two or three individual offices with individually configured systems and walking in and out in order to perform different tasks.

Starting up the development environment is also a matter of a few clicks on a custom PowerPro pop-up menu which will take care of starting up everything I require, and also to position the windows exactly where I prefer them to be. Various components or parts of projects have their own configuration that will trigger the startup of the tools required for the job. If I startup a debug session it will automatically start up the output logger on one system at a specific location on any of the screens.

I’ve often received comments of people asking me whether I know of the existence of ALT-TAB. Yes, I do. But it’s darned inconvenient to use that when a system is cluttered with 20 or more windows. It ends up being something more like alt-tabtabtabtabtab rubbadubdub. It is far more efficient for me to have all the information for any given task clearly in front of me instead of burried under a flurry of windows.

When I perform a full build run of a large project involving a lot of source code, components, automatic generation and integration of API documentation, resource compilation, etc. it usually spawns two full screens with windows related to my custom tools that run the entire building process from checking out source from the server, running unit tests, right upto building a usable release. Often a build process breaks or fails and being able to catch that in time and when needed debug the process itself takes up twice the screen space I already have. Normally I just continue work on Halon while Helium takes care of the full build management that is spawned and performed by a dozen VM’s running on the network (usually on Argon but not exclusively so).

Because I don’t just write code but also need to take care of architecting and always keeping an eye on the bigger picture of a project it really helps to have a lot of information available at any given time, clearly visible and easy to spot the little things that can easily slip by and be forgotten.

Usage Scenario #2 (Specific)

For a more specific scenario I’ll use the example of something I did a while ago which involved the reverse engineering of a Bentley MX model file binary format.

In order to figure out all the bytes and chunks of data (which were stored in an appended and linked form not unlike how a harddisk stores fragments of files all over it and using pointers to the location of the next fragment) I wrote an application specific to help me with this. The application itself used Docking Windows and Views like Visual Studio and allowed me to “paint” color markers all over the hexadecimal data, decode streams of bytes and entire chunks, and also allowed me to add routines to the application that would assist in automatically decoding entire portions of the data.

This application would be running on Helium, full screen. Next to it on the second screen would be the visual representations of the data files used as targets for decoding, along with notes and documentation that are made throughout this process.

The source code of this specific application which I called “mXposed” (the small screenshot below) would be running on Halon in its full development environment so that I could keep adding to the code, compile and build, and immediately run the updated build on Helium.

In this situation the amount of information really does require 4 screens, or 3 with a much higher resolution, in order to be moderately efficient. Switching windows while looking at code and routines and correlating that back to the visual representation of the data and the data views offered by “mXposed” would have been a royal pain in the beeeeehind.

Any web surfing and e-mail that transpired during various stages of this process, like requesting different sample files with specific content in it, would be running on Osiris on its screen. So a 5 screen configuration was certainly very helpful in doing all this within record breaking time (without the configuration I used and the approach I took it would have easily required 20-30% more time on a process that already took several weeks in itself).

The most valued tool in all this, as always, was Syngery, the network TCP/IP based “KVM switch”. This is the reason why hardware VKM switches have never worked out well for me. I need to be able to seamlessly control several machines at onces without having to perform a manual action that is required with hardware KVM switches, even if it’s just hitting a set of hotkeys to move control over. The “M” in the KVM switch would be of no use at all to me anyway.