Started writing some Unit Testing year ago and found that with the services I develop, unit testing is futile. That said, I have my own extremely broad testing infrastructure that is constantly running JScript and PowerShell generated client requests against my servers, some of those requests intentionally contain client request errors that we've seen come from specific client types. If you are dealing with library functions and methods that have fairly simple input parameters, Unit Testing can be useful. When dealing with a client server model that takes a wide variety of complicated XML HTTP posts, from various vendors, all of whom implement specifications differently, not so much. Most of the problems would be caught somewhere else farther down the stack. That said, I have a variety of iOS clients to test with since Apple's developers excel at not following specifications, especially when it comes to return codes.

Audio and Aegis

Well, there is that statue of King Wenceslas riding a dead horse upside down, so perhaps the Czech's need it spelled out also. :P FWIW, here in Texas, it's simply called "riding" (with horses being the default beast of burden, followed by motorcycles).

I've been using FoxIt Reader ( foxit dot com ) for years, been very plesaed with it.

Junctions are your friend! For instance, Outlook always likes to use the system drive for some things (ie. C:\Users\{username}\AppData\Local\Microsoft\Outlook). Let it set it up. Shut down Outlook. Move the data to the drive you want and create a junction in place of the original directory Outlook created. I do this with a few applications, ensuring that my data is on an 8TB Raid 5 array instead of on the system volume. The only caveat is that it CAN give you deceptive disk usage numbers from some utilities that don't understand junctions.

I'm probably one of a sparse number of MFC holdouts. Decades ago, back in the Borland Turbo C++ days, I used OWL. After that, MSFT C++ and MFC. I should note that the only aspects of MFC that I use are the UI centric ones. Windows, Dialgos, Property Sheets/Pages, Menus, etc... never used Ribbons, can't think of an instance where I would. The majority of my work doesn't involve UIs, most of it is functional code called by others, APIs, and ISAPI Services. When I do require a UI, such as for configuration or reporting access callable from our main product, MFC is there. It is consistent, and it continues to function as designed from one VC++ release to the next. Because most of the modules I write must integrate tightly with our primary product as "plugins", moving to a ".net" would incur a lot of additional work. I also feel that when I do need something highly specialized, it is easy to inherit from MFC and create controls with modified appearance and behavior. As long as MFC is available, I'll continue to use it, and if they decide to no longer ship it with VC++ and cause errors using legacy MFC libraries, I would likely recompile it for use with the newer release.

Windows 7 was the natural evolution of Windows XP. I still use Windows XP virtual machines for running tons of JScripts that mimic xml-http clients that interact with the server products I write/maintain. I use 32 bit XP VMs mainly because the memory requirements are low and it runs well in a sandbox under Hyper-V. I still have some 64 bit XP installations backed up, but no need to run them any more due to the limited usage I require. I don't do any PC based gaming. I spend enough time on computers while working.

I spend most of my development time using 64 bit Debug, but have to build both 32/64 and Debug/Release and test before I check in. I call MSBuild from a batch file to build everything. My dev environment is highly customized, and have a post build deployment script that runs and updates all 4 installations automagically to 4 different VMs that I have our products running on. At the end of each build, it triggers automated testing on each of those VMs.

I would venture to say that Windows 8 was the "first" step backward... I can't stand Windows 10. The flat design kills me, the plethora of extra processes just to maintain a functional OS is crazy. While I did recently build a Windows 10 machine for myself, since I know that eventually, I will require it, my primary workstation is still a Windows 7 64 bit machine with 32Gb of RAM and a bunch of SSDs in a few RAID configurations. That said, my home networks are well fire-walled, in fact, friends/guests/visitors that require WIFI access get an entirely different router and and gateway. All of my development/testing/work resources are on a separate network from the rest of my home, so as long as I don't do something terribly stupid, the lack of new security updates is not of too much concern to me. If it ever gets to the point that I can't run all of the development tools that I require on W7 64 bit, then I will bite the bullet and transition to the Windows 10 box, but until such a time, Windows 7 still rocks!

I would likely do more Open Source Development... Most likely some extensions that I have on the back burner that would tie into the product I currently develop for my employer. Perhaps also pull out some archived shareware I wrote long ago, update it and re-release it as open source, as I've not found anything like it available on the web, but I know that there is a desire for it in specific circles. I would also start up several (4 or 5) side businesses that I've wanted to implement, unrelated to software development, and specifically beneficial to the small community that I live in (I live way out in the country on forty acres). I'd also likely try to purchase some of my neighbor's land so that I could raise more cattle.

Yeah, it wouldn't surprise me, especially considering that MSFT has opened up parts of their codebase to specific partners. There were a lot of unusual references to various farm animals back then. LOL!

I used to work for Microsoft, in Exchange CPR (Critical Problem Resolution), writing bug fixes for Exchange from version 5.5 through 2007. One of the more notable comments from the Exchange source was in the Information Store Code... // This blows dead goats! A few years back, they started going through the codebase, cleaning up/removing such flamboyant comments.

I have {mylastname}.org, have had it for a couple decades. Costs: Domain Name Registation: I renew for multipole years at a time. The .org registration has gone up in recent years. Your cost will vary depending upon the top level domain. Easiest, but not the cheapest, is godaddy for maintain the name registration. DNS: I use a free DNS provider (freedns.afraid.org). As it states... free! I used to handle DNS on my own servers back when I own a small hosting business, but freedns.afrain.org is a piece of cake to work with. I write (C++) and run my own mail server on a Windows Server machine located at my employer's colocation (they've allowed this no charged for over a decade now). Again... Free. Only potential pitfall is ensuring that DNS I occasionally touch the DNS so that it does not get cancelled due to lack of administrative use. Hasn't happened in all of my time at freedns.afraid.org. So, aside from domain name registration, which I usually renew in 5 year chunks, no real monthly or annual costs.

Of course, there could also be... auto war; If the compiler were inspecting at variable names for possible type information, it just might treat that as volatile. :)

Not an answer to the original question, however, since this part of the thread is dealing with style/formatting... Thankful that VS now supports the .editorconfig specification. I prefer and use 2 space indentation, as to avoid scrolling left and right to be able to read my code. I also use { and } on their own lines at almost all times, the primary exceptions would be public: inline accessor get methods where exposing the member variable itself would be a bad idea... ie. private: DWORD m_cbAllocated; public: inline DWORD get_Allocated() const { return m_cbAllocated; } In those cases, I find that breaking the method down into multiple lines is overkill. I also like white spaces after ( and before ) as long as it is not an empty construct. It simply makes it easier for me to read. ie. if( ERROR_SUCCESS == ( lRet = RegOpenKeyExA( HKEY_LOCAL_MACHINE, rPF.sPath(), 0, KEY_READ, &hKey ) ) ) In comparisons to constants, I always like to have the constant on the left (see above). This serves two purposes... It is easier to see what I am comparing to without scrolling right past all parameters, and it ensures that a typo (say a missing '=' sign), doesn't compile if comparing to an lValue. (resulting in a bug) ie. LONG lRet = RegOpenKeyExA( HKEY_LOCAL_MACHINE, rPF.sPath(), 0, KEY_READ, &hKey ); if( ERROR_SUCCESS = lRet ) { ... } Not for everyone, but after doing this for 30+ years, it's what I'm used to, and no employer in their right mind is going to force me to change this late in the game. Here's the complimentary grain of salt .

I replaced all of the fluorescent tubes in my garage/shop with LED tubes a few years back (and added more locations). SO much brighter, no flicker, and still have not seen a failure. Beware however, that not all LED tubes are wired the same. It can vary by manufacturer. Some want leads on one end only, while some require one lead each at either end, and there is often no documentation/guidance regarding this. (You'll know pretty quickly upon applying power.) So, best bet is to stick with a single manufacturer and purchase extras.

I wouldn't have expected that. Didn't have a problem with that in my garage/shop. Do you know if purchasing a different white value (color frequency) would make a difference?

Technical books I general hit different parts of multiple books in a given time-frame. General Fiction and Non-Fiction, I prefer to read one at a time, and in series, as I like to immerse myself into the plots. Comic books, I generally save up a few months of a given title and read them in sequence. Mainly because the amount of content in a given comic book is usually not long enough to satisfy. (I still subscribe to paper comics). Technical publications, I will read on a monitor... but for entertainment purposes, give me paper. I find it difficult to enjoy non-technical writing on any type of tablet or monitor. Perhaps because I spend enough time in front of them in my work hours (which are usually too long anyway).

From the first line of code to transitioning from an Auto Mechanic to a professional Software Developer. 1977 (ish): Writing Basic code on a Bally Entertainment System, wrote a simple Multi-Die + Adjustments dice rolling routine for D&D. Had to load and save via cassette tape. Late 1977: Followed shortly thereafter by an Apple II+ that my dad received for his office. Wrote several D&D applications where I could run a random campaign pretty easily. Unfortunately, it was at his office most of the time. 1982: A KayPro II luggable continuously borrowed from a neighbor who didn't care to use it (it was supplied through his emplyer). I finally had something I could use on a regular basis. Ported all of my D&D code from the Apple II+ to the KayPro and wrote even more stuff for our D&D campaigning. :) 1983: Life happened... Didn't touch a computer for 5 years. 1988: Discovered BBS's via a friend of mine who ran one. Rented to own an 10Mhz IBM XT clone, taught myself QuickBasic and Pascal. Quickly acquired 2 80286 machines. Taught myself C. Picked up an 80386 machine. Ran a BBS of my own, wrote BBS Doors, other utilities. 1990: I was hired as a programmer writing billing and management code for a company (now defunct) in Carrollton Tx. The journey begins!

I know the feeling. I work for a small software firm and our primary product is so mired in old code (much of it Borland OWL which pretty much only one person in the company touches these days), that any attempt to improve the product is met with the same "that will be a ton of work that we can't do because we need to concentrate on new features". I almost always end up implementing new methodologies in my off-time or in projects that are entirely within my control, and slowly begin interfacing the legacy code to use them in "baby steps" ("what about Bob?"). We have countless requests for specific improvements that have literally all been handled in a "proof of concept" I wrote a few years ago, but until I can mirror all of our internal and external legacy API calls, there is no way to drop in this new system. That proof of concept was proven to be faster, more memory efficient, more fault tolerant and more resilient to abnormally high concurrent transaction counts than our old legacy system, while also opening up the door for a clustered parallel processing solution. 4 years later, that "proof of concept" still has not been implemented in our product because of the fear of beginning a new branch that could get out of date with current fixes while in development. (Though, I have it running as an alternate service provider for several of my projects on one of my test servers.) I feel your pain!