Ok, I'm not a spring chicken, and I'm not as into gamming as I used to be. (back in the days of creating game Levels for UT2004, QUAKEII, Doom, and other such hot titles of yester-year) But I have to say I love my Wii. My biggest complaint about the unit, in fact all game consoles, is that I have to endlessly keep changing out the game disks. Lame. More over, being the father of a 6 year old boy and a 3 year old girl, I have to say I'm tired of replacing trashed $40.00-$60.00 game disks that get ruined because, well, kids are kids and have a hard time understanding the care of game disks, though my son is getting better and learning through Wii-Timeouts.
I discovered that you can hack your Wii to use a USB Hard Drive, and through various 3rd party utilities, can also rip your games all down to the hard drive and have your Wii play them directly from hard drive. This sounded risky to me, but with 2 kids I figured one thing. If I do this and it works I will save the cost of a brand new Wii by eliminating the need for game disks to be out, and needed consistently. If it worked I would only need to use the game disk one time for the initial load, then I could store them neatly. My kids won't trash disks and I won't have to buy the fourth copy of Mario Kart Wii (I know, most parent say simply don't replace the disks...but I like to play too, and am technically inclined)
I did it. It worked, holy cow this is the greatest thing in the known Wii universe. I loaded a program called USB Loader GX, and then used it to load my games on to the Hard Drive. It downloads the case art and the game disk art in just a few clicks, and here's the cool part. You get a awesome 3D Rolodex like view of all your game cases as the menu system. You just flip through them, pick the one you want, click on it and start gaming. As an added bonus the in-between level-loads and auto-saves go WAY faster as the HD and USB 2.0 interface are much faster than the DVD Drive.
I have to say, if you think you can handle it go for it and hack your Wii today. I suggest visiting www.wiihacks.com to learn more.
p.s. I haven't had to change out game disks for my three year old daughter in a few days now. Talk about a nice reprieve.
p.p.s. Oh, if you damage you Wii, and you can, hacking it I really don't want to hear any complaints about it. Life is about knowing your limits. Mine allow me to hack my Wii.
Saturday, October 24. 2009
Subversion, Hudson, Maven, Archiva make a nice team.
Not so back in the past, our software development environment utilized jFrog Artifactory for artifact management, Apache Continuum continuous integration system to build our code, and a preponderance of batch files slung all over the place executing various Ant builds. To top that off there was also c# code that was being built at developers workstations and submitted into subversion source code repositories. The office mantra was "I don't understand, it worked on my workstation!". It was, in short, ugly and difficult to follow at best. We had scripts that mixed any given part process; products were built, gathered, downloaded, or packaged at just about any stage, and in any order. There was no separation of the various states of the build, and therefore complete and utter locked co-dependency on the current technologies being used in the process. An update in one place meant visiting many batch files, hoping not to miss one.
So how did we get here? Did we hire incompetence? Did we have issues making decisions? No; not at all. This is more of a symptom of sprawling software development. You start out with your software specification; this is in essence like the foundation of a house. Processes are set in place and development begins. Eventually the house is built, but development is still on-going as the product's potential is realized. And so the house grows to the point of exceeding the limits of the foundations. But not to worry; foundations can be changed, and expanded upon.
Enter Maven2 Project Management system, Hudson Continuous Integration Build System, Archiva Build Artifact management. The process was completely rebuilt from the ground up. Where we once had many interweaving batch files performing most of the work, we now had complete separation of processes. Maven allowed us to define project dependencies, codependences, relational hierarchies, and various build goals. Maven is everything Ant ever hoped to be, and more.
Now our programmers were checking in their code. Hudson would monitor our source code repositories every 10 minutes. If source code was checked in to a given project, be it c#, c++, or Java, then Hudson would build the code and perform (findbugs) code analysis, task analysis, junit tests and provide statistics lines of code, workspace size consumption and project size. If Hudson detected any cross-project dependencies, it would then kick off their builds too. Hudson would then check in the resulting compiled binaries or assembled sources into Archiva artifact management system.
Next we have one batch file that simply simply gathers all the relevant binaries (or artifacts), assembling them in a working directory exactly as they would packaged into an installer. This process has no responsibility for building anything, and only cares about the most recent, successfully built artifacts published to Archiva. It doesn't care how the files are packed or what technology is used in the distribution process. Nor does it care how the binaries came to be.
Lastly the files would be packaged by our installer platform. This last step doesn't care about any previous steps. All it knows is that files at location X need to be packaged into an installer. The installer could be Install Shield, Jexpress, Wise, VSS Packaged and Deployment wizzard... whatever the technology, the basic workflow is the same. The nice part is that Hudson also allowed us to perform the last two steps as Jobs so end to end we were totally automated and monitored.
What is even better is that we have one process that simply builds our code base and assembles it. We have a completely separate process that gathers all the necessary binaries for the installer. Lastly there is a completely separate process that actually packages all the binaries, and file dependencies. We can upgrade technologies in any part of the process with little to no effect in the other areas allowing us to be more agile and to be able to jump to newer better technologies as they become available at low risk to our product's stability and quality.
Hudson Extensible Continuous Integration System
http://hudson-ci.org/
Apache Archiva Artifact Management
http://archiva.apache.org/
Apache Maven2
http://maven.apache.org/
Subversion Source Code Repository
http://subversion.tigris.org/
So how did we get here? Did we hire incompetence? Did we have issues making decisions? No; not at all. This is more of a symptom of sprawling software development. You start out with your software specification; this is in essence like the foundation of a house. Processes are set in place and development begins. Eventually the house is built, but development is still on-going as the product's potential is realized. And so the house grows to the point of exceeding the limits of the foundations. But not to worry; foundations can be changed, and expanded upon.
Enter Maven2 Project Management system, Hudson Continuous Integration Build System, Archiva Build Artifact management. The process was completely rebuilt from the ground up. Where we once had many interweaving batch files performing most of the work, we now had complete separation of processes. Maven allowed us to define project dependencies, codependences, relational hierarchies, and various build goals. Maven is everything Ant ever hoped to be, and more.
Now our programmers were checking in their code. Hudson would monitor our source code repositories every 10 minutes. If source code was checked in to a given project, be it c#, c++, or Java, then Hudson would build the code and perform (findbugs) code analysis, task analysis, junit tests and provide statistics lines of code, workspace size consumption and project size. If Hudson detected any cross-project dependencies, it would then kick off their builds too. Hudson would then check in the resulting compiled binaries or assembled sources into Archiva artifact management system.
Next we have one batch file that simply simply gathers all the relevant binaries (or artifacts), assembling them in a working directory exactly as they would packaged into an installer. This process has no responsibility for building anything, and only cares about the most recent, successfully built artifacts published to Archiva. It doesn't care how the files are packed or what technology is used in the distribution process. Nor does it care how the binaries came to be.
Lastly the files would be packaged by our installer platform. This last step doesn't care about any previous steps. All it knows is that files at location X need to be packaged into an installer. The installer could be Install Shield, Jexpress, Wise, VSS Packaged and Deployment wizzard... whatever the technology, the basic workflow is the same. The nice part is that Hudson also allowed us to perform the last two steps as Jobs so end to end we were totally automated and monitored.
What is even better is that we have one process that simply builds our code base and assembles it. We have a completely separate process that gathers all the necessary binaries for the installer. Lastly there is a completely separate process that actually packages all the binaries, and file dependencies. We can upgrade technologies in any part of the process with little to no effect in the other areas allowing us to be more agile and to be able to jump to newer better technologies as they become available at low risk to our product's stability and quality.
Products worth looking into:
Hudson Extensible Continuous Integration System
http://hudson-ci.org/
Apache Archiva Artifact Management
http://archiva.apache.org/
Apache Maven2
http://maven.apache.org/
Subversion Source Code Repository
http://subversion.tigris.org/
