Recently, I was made a gift of a Raspberry Pi project computer, and I’ve been going nuts ever since doing numerous projects with it. None of them are particularly unique, because this is basically a Linux computer, so I could do any of these projects on a regular computer. However, the fun thing about the Raspberry Pi is that it can be a small device that is focused on doing one thing, with a small physical and energy footprint. (This particular project could also be applied to a regular Linux-based desktop computer, but this tutorial will be Pi-focused in some of it’s aspects.)
I recently found the need to venture into the somewhat shady realm of Mercurial hooks. (If you are not familiar, Mercurial is a git-like Version Control System written in Python.) Within my development environment, after making releases, we construct named branches of the release, to be kept pristine in perpetuity. This allows us, at any time in the future, to reconstruct a particular release identical to what has been released to the public, or to sub-branch from that point for any subsequent patch releases that might be necessary.
Working with an OS X virtual machine under Windows presents some interesting challenges that a Windows VM would not. In this particular case, the act of “shrinking” a VMware disc is not a straight-forward process when OS X is the operating system. In this article, I present one way (of probably many) of reducing the footprint of an OS X volume.
This is just a brief article to note the debugging work flow I used while recently developing the Associated Windows Shell Extension. Windows Shell Extensions can be a bit tricky to debug, especially when you use the live Windows Explorer to test your work, as I do. The work flow I use is not very complicated, and doesn’t require hacking the Windows Registry (as some techniques do). There are other work flows that run separate Explorer processes, and do not require elevated privileges, but this is the work flow I use.
Necessity is indeed the mother of invention. Most things you see around you in life are there because somebody one day had a need that the current crop of available tools could not satisfy. Seeing the need, a tool maker then created (and eventually refined) a tool so everybody could get the job done. Of course, one of the really cool things about being a tool maker is that you never have to wait for somebody else to solve your problem.
Typically, when I set up a new Windows machine for somebody, I simply allow the default account to remain as an Administrator (when I do my personal machines, I actually take complete control, activating the “Administrator” account and using that for myself). When there is a one-to-one mapping of person-to-account on a machine, then there are typically no issues with things like installing software. The person who uses the machine has complete access to do whatever they need or wish (good or bad).
I know there are a plethora of YouTube videos and blog posts out there about fixing the “Red Ring of Death” on your XBox 360. Fixing the RRoD turned into a multi-million dollar industry, truth be told. Well, I’m going to show you how to fix yours using about $4 worth of parts so you can get yours up and running without having to spend any more just to find the right path. To date, I have successfully fixed two machines using these steps, and as I write this article, I am in the process of correcting a third (pictured). So far, my approach, cherry picked from several sources, has proven successful — and here it is for you to use, free.