Gunpla Chronicles 2 - Building the Core Fighter

One of the coolest things about the Real Grade RX 78-2 is the inclusion of a working Core Fighter.  The tiny aircraft can actually be used to help form the torso of the Gundam just like in the show.  Due to its small size, I decided it was a good place to begin.

Before beginning this build, I told myself that I needed to improve on my skills and make fewer mistakes.  To that end, I got a few additional tools to help me out, most notably a set of hobby sandpaper sheets to use in place of the very coarse grit nail file I abused the Zaku with.  Unfortunately, by the end of the first night of work on the Core Fighter, I feel like I haven't gotten any better, and may have even got worse.  Here's a picture of what I wound up with:

You can't quite see it, but the clear plastic of the windshield is a bit scratched up.  Furthermore, those big black panel markings on the top of the fighter are dreadfully ugly, and it turns out that I placed them in a spot where stickers are supposed to go.  I'm not really sure if I can remove them now that they've dried, but I'm crossing my fingers that I can find a reasonable solution.

Here's a picture of the bottom of the fighter as its in docking mode:

There's a nice big scratch running down the left side.  I think this might have been the result of overly aggressive sanding, which means that my new tools are actually doing me more harm than good at this point.

If there is one thing I did learn from my first build, it is the importance of being able to walk away when things look bad, so you can return to it with an actual gameplan, rather than futzing around with desperate, half assed attempts at a solution.  I left this one alone for now, but rest assured that I'm not done with it yet.

Gunpla Chronicles 2

The first series of Gunpla Chronicles entries detailed my attempts to build the Real Grade Char's Custom Zaku II.  While I didn't do a very good job of updating my progress down the stretch, I did get manage to finish the kit.  I found the experience to be challenging, educational, and ultimately rewarding.  While I made more than a few mistakes (and nearly broke one of the leg pieces permanently), I still think the Zaku came out better than I expected for a first try.  To this day I cannot  work in my office without stopping to admire the thing.

I don't know how much farther I plan to take Gunpla as a hobby (I lack the time, money and space to build kits on a regular basis), but ever since last spring I knew I wanted to build at least one more kit to tide me over for the foreseeable future. Now, almost a year later, it's time.

After doing more research on Gunpla, I decided I wanted to stick with the Real Grade line.  The kits are reasonably priced, their small size is perfect for my office, and they are incredibly detailed and well articulated.  I also knew that the choice of which kit to build would not be easy.  After building the Zaku, there aren't many models in the Real Grade line which I care about, not when it is so heavily represented by mobile suits from Gundam Seed.  But of the remaning options, I still had to decide between two of my favorite mechs of all time - the original RX 78-2 Gundam, and the Gundam Mark II.  I like the look of the Mark II better, but the nostalgia factor of the RX 78 was undeniable.  Ultimately, the choice was driven by an overwhelming feeling of obsessive compulsion; Char's Zaku would look out of place standing next to the more advanced Mark II.  Indeed, it had to be paired with its nemesis, the RX 78.  And so it was done.

It may be old school, but it still can't help but look badass

Wish me luck folks.

Jelly Bean on the GNex

By some strange miracle, the Android Jelly Bean update was released for the Verizon Galaxy Nexus today.  For the last 2 months I never felt the usual (and completely shameful) anxiety I get when waiting for an Android update to be approved by Verizon.  Rather, I was entirely relaxed, perhaps because Ice Cream Sandwich is still good enough on its own.  However, once I heard the news, I went nuts.  All after noon I tried to force the update to push using various tricks I read about online.  A terrible idea, mind you, and a waste of time, so I bit the bullet an attempted Plan B - "Installing the update manually".

I used to do this all the time with my old Droid 1.  Someone in the community would grab the update file, which you loaded onto the SD card. From the bootloader, you could then install the update and reboot.  It was simply, easy, and you didn't need to mess around with rooting the device.

But that was back in the Wild West days of Android, when the bootloader was wide open.  These days, most devices lock their bootloaders, though some, like the Galaxy Nexus, protect it with the equivalent of a screen door.  That is to say, it was made by design to be incredibly easy to unlock.

At least, that's what everyone in the community claimed.  Yet when I first looked for instructions on how to do it, I came away more confused than before.  Everyone recommended downloading a variety of user made tools that would unlock and root the device for you.  As I mentioned in my last post, I'm not a big fan of running software like this without knowing what it is doing.  For me, this isn't an option.  Personal choice aside, however, I failed to understand how unlocking the GNex could be considered easy when it required community enthusiasts to come up with the tools to do it?

I knew there was another way.  There had to be.  Why else would people say it was designed to be unlocked?  I confirmed my suspicion fairly quickly.  At least one tutorial on the subject referred to an alternate, more difficult method of unlocking, one which involved using the Android SDK.  Suddenly it all made sense.

Here's the scoop, so far as I can tell.  If you have the Android SDK, you have all the tools needed to unlock the bootloader on the GNEX.  With one command, you can reboot it into recovery mode, and with another you can issue the unlock command.  Done and done.  Installing the manual update file for Jelly Bean does require from outside help, in the form of a custom recovery tool like Clockwork Mod Recovery.  Thankfully, Clockwork is a well known and reputable piece of software, so I wasn't afraid to use it.  Moreover, once I ran it, I could immediately tell what its purpose was. It looks just like the bootloader/recovery program from the OG Droid, the one I used to use.  My only issue with Clockwork was getting it running.  From what I can tell, you can flash it onto the phone using the SDK tools, but it seemed to go away once the phone restarted.  If that's the case then I'm even more pleased, since it means I can load it up for one time uses when need be. 

When all was said and done, I had the official Jelly Bean update on my phone, and I learned a valuable lesson.  What most Android enthusiasts considered "hard mode" is actually very easy if you're the kind of person who 1) isn't afraid to install the SDK, 2) knows how to do it, 3) did it already for actual development, use and 4) understands what it does.

Moreover, I discovered that while the actual developers in the Android hacking community are far smarter than I, the guys who are obsessed with unlocking/rooting/flashing ROMs are not necessarily so.  Guess I have to trust my instincts a little more.

Rolling Your own (source code)

When I was first learning how to use Linux, package managers were a godsend.  I still remember the first time I saw someone use apt to download some needed software.  Here was an OS that was free as in beer, free as in speech, and was backed by multiple mirrors of hundreds of software packages which will instantly configure themselves on your system.  For a moment I felt like I was living in the future.  In reality, I was living in a world where the dominance of Windows blinded me to the fact that the cutting edge of computing existed elsewhere, and it was awesome.  On a more practical note, the ease of use of Debian packages made it much easier to set up a working Linux environment. Dare I say that if it weren't for package managers, I would have never considered Linux to be anything more than a curiosity.

Nowadays, I don't use packages that much.  As the years went by, I found myself being forced to build various pieces of software from source.  At first I simply pasted commands into a shell, but eventually I grew to understand what those commands meant, until I finally got to the point where I could grab a tarball and install it without any guidance.

Then something else happened.  Building from source went from being an option, to being my preference.  And it's becoming true more and more with every week.

My current view is that Package Managers are indispensable in at least two situations.  The first is if you're a newbie, or if you use Linux for basic computing tasks.  The second is if you are running a server in an enterprise environment, where your system needs to stay up to date, and simply cannot break.  For someone who falls into these camps, I'd say you're crazy not to rely on packages as much as possible.

For developers and power users, however, I think the negatives of package managers become more severe.  Namely, they introduce a  lack of control and transparency to your system, leading to problems that can waste as much of your time as a finicky source bundle.  For instance, what if you want a certain feature to be enabled, or disabled?  With the precompiled package, you have no say.  On the same token, what if your distro's package repository is slow to update to the latest version of a programming language?  These concerns don't affect everyone, but when they do, it can be incredibly frustrating.

In regards to transparency, consider Synaptic Package Manager, which doesn't tell you what gets installed, or where it gets installed to, until the package is actually on your system.  This is counterintuitive to me.  The package is installed without asking you for a destination.  That means it must know where it is supposed to go.  Why can't I see that ahead of time?

Furthermore, I can't shake the feeling that the dependency lists for some packages could be leaner than they are.  Far too many times have I installed what looked to be a simple package, only to find that it has to bring twenty friends along, some of which look completely unrelated.  Back when I (admittedly foolishly) tried to run Ubuntu on five gigs of disk space, I'd fill it up in a blink, until I went in and uninstalled a half dozen kernel images and a list of libraries as long as my arm.  This problem plays into a more general attitude among developers which assumes that disk space is trivial (for more examples, see Maven, Ivy, rubygems, and other programming-language related package managers).  Even when it is, I don't want to fill my HDD with more data than it needs, nor do I want to spend time pruning it months from now.

For all these reasons, I've grown to rely on building from source almost exclusively.  It lets me know exactly what's on my PC, and where it is located.  For example, I find that it is easier for me to keep track of binaries if I install them to  /opt, rather than spreading them out between /opt/, /usr/, and /usr/local.  It also lets me install multiple versions of software, and change between them as needed.  To be fair, there are pitfalls with this approach.  Some things don't build nicely, especially on OS X.  Thankfully, most of my pitfalls have managed to double as learning experiences, and I hope that the lessons learned will make future installations smoother.

But there's one thing about building from source which bothers me more than anything else.  I'm starting to get fanatical about it.  When I tried to get Ruby setup last month, I found myself increasingly frustrated with the community's insistence on using Macports or Homebrew to grab needed pieces.  I felt allergic to the voodoo that the various Ruby management systems (such as RVM) practiced behind the scenes.  I even chaffed at Google's insistence on making the pre-compiled version of Go a .pkg installer, which placed everything in /usr/local whether you like it or not.  The way I saw it, the people who have an interest in installing Ruby don't fall into either of the two camps which benefit from Package Managers.  Abstraction is good in programming, but abstraction at this level can lead to someone working with a tool that they don't really understand.  If it ever happens to break, they would find themselves at a loss at what to do.  As I mentioned before in regards to Ruby, convention over configuration can only go so far.  Sooner or later, you need to look under the hood.  Once you get over the initial hurdles, and your system is suddenly working exactly the way you want it, the feeling you get is nothing short of triumphant.

Again, I think my own stance is too strong.  It perceives the world as too black and white, and it does not factor in any number of edge cases.  Ultimately, it doesn't really matter whether or not you use package and roll your own, as long as you can do the stuff you want to do.  It's not worth it to get worked up over these kinds of debates. Not when there are stupid projects to undertake, like building Linux from Scratch.

Ruby Update

Remember that post I wrote about my adventures in installing Ruby?  The one I JUST wrote?  Turns out all of my struggles were unneeded.

You see, one of the reference books I was using is called RailSpace, and it attempts to teach already experienced programmers how to use Rails by building a small social networking site from scratch.  I thought it was a great concept, and I enjoyed what I was reading.  The book's use of Ruby 1.8.5 and Rails 1.2 was the driving force behind everything I slogged through.  What's worse, after finishing that last post, I still couldn't get through the book due to version mismatches between Ruby/Rails/Rubygems/whatever else.  I was completely hosed, even in triumph.

Yesterday, I googled the RailsSpace book to look for guidance.  Often times programming books have a dedicated websites with updates, sample code, and sometimes even message boards.  I thought I might find that someone had the same struggles years ago when the book was new.

Guess what the first Google result is when you search on "RailsSpace"?  It's called the "Ruby on Rails Tutorial", which alone doesn't sound like much.  What it REALLY is is an updated version of the RailsSpace book, created by one of its authors, Michael Hartl.  While it isn't entirely the same, it still has you making a social networking site using Rails, and it is written in the same style and pacing as the book.  I've already begun to work through the first two chapters, and I've yet to encounter a single hiccup.

If I had known about this site a week ago, I could have saved so much time and stress.  If I had to pick a silver lining out of the storm clouds, I'd say that I still learned quiet a lot in my failures.  I just don't know if it was worth the overall time spent.

No use crying any more over spilled milk I guess.  Time to do something productive.

Ruby on OS X

A few weeks ago I decided to try (once again) to learn Ruby and Rails.  In the past, I never got far in this endeavor, on account of getting confused and/or bored. This time, I haven't gotten far because I haven't been able to get the damn language working the way I need it to.

Allow me to elaborate. I am using several pieces of dated but still useful reference material.  The good thing is that they were all published around the same time, meaning they all use the same (or similar) version of Ruby, Rails, and Rubygems.  The bad thing is that all of these tools have received major upgrades in the years since.  Version mismatches usually lead to incompatibilities, and sure enough, the commands listed in my Rails book are flat out broken when used with Ruby 1.9 and Rails 3.  I needed the old stuff, and I needed it configured properly.

My quest to to achieve this perfect development environment was a monumental pain in the ass, redeemed only by the fact that it taught me a ton about Ruby, the Ruby community, and the innards of OS X.

My first major hurdle came while trying to compile Ruby 1.8.5 from scratch.  It turns out that as of Mountain Lion (or maybe Lion, I forget), OS X has no pure version of GCC.  It's all LLVM, with either a Clang or GCC front end.  Suffice to say that only the most bleeding edge version of Ruby compiles nicely with these tools.  Everything else simply craps out at one point or another.   At this point, I decided to look for some alternatives.  RVM is a popular tool for managing different versions of Ruby, so I tried to give it a shot.  It failed spectacularly.  Unbeknownst to me,  RVM installs different versions of Ruby by compiling them.  Obviously it failed just as hard, no matter which version I tried to install.

I went back to the Internet to look for solutions.  The most common suggestion was to install Apple's pre-Lion version of GCC4.2 using Homebrew.  I don't like Homebrew (or Macports or Fink), and I wasn't excited about using it just for the compiler I needed.  So instead I found a wonderful guide to building GCC from scratch on OS X.  The instructions worked perfectly, and they left me with a working, up to date compiler that was installed to a sane location.

I didn't know it yet, but at this point, I had all the tools I needed to get Ruby up and running.  Yet I still struggled when building from source.  One issue is that the Ruby source has some glaring issues (at least in version 1.8.5).  For example, I found one file that had #define where it needed #defined,and another which tried to pass a const char* to free() (which, at least on my system, requires a void* argument.  Then there was the file which defined two constants which already existed in OS X's version of stdlib.h.

The second issue was getting make to use my hand build version of GCC.  It was easy enough to put it on my PATH, but that wasn't enough.  Some parts of Ruby's build process use the generic cc command, and on OS X this is a symbolic link to /usr/bin/clang.  I only discovered this last part today.  A week ago, I had what looked to be a working version of Ruby which failed to install gems.  When I googled the error messages, all of the hits were concerning the aforementioned issues with compiling Ruby using LLVM and Clang.  I kept thinking "but I'm not using them.  I have GCC4.7.  I can see that it's being used by make. "  Only it wasn't being used by make. At least, not during the entire build process.  When I finally changed the cc symlink, the build finally succeeded.

Just kidding.  It failed again.  For whatever reason, several of the modules in the ext/ folder of the source tree had empty Makefiles.  I'm still unsure as to how this happened, but the issue went away after running make distclean, and then another make.  This time, I had a fully working copy of Ruby 1.8.5.  After that, everything fell into place.  Rubygems. Rails 1.2.  It's all working fine, as do the book examples.

At first, my takeaway from this ordeal was that Apple was doing a fine job fucking up OS X as a legitimate environment for programmers. By the end of it, my tune changed.  I still don't like the loss of GCC (and now I won't have to worry about it either), but if FreeBSD can get their system running with Clang and LLVM, I hesitate to say that either tool is a problem.  Rather, the issues seemed to stem  from the way Ruby is/was written.  I'm not saying it isn't worthy of being used in production environments, but I don't expect (and don't encounter) such sloppiness in any other major programming language.

I also learned a lot about the Ruby community.  Specifically, I decided that the concept of "convention over configuration" espoused by Rails developers extends into the community at large.  Did you know that RVM will change the way the cd command behaves on your system?  Even if the change isn't problematic for 99.9999999% of users, it is still something I'd like to be told about at installation.  I also grew frustrated at how so many of the proposed solutions to my problems boiled down to using a tool that would automagically download and configure the tools I needed in order to build and install the tools I wanted to use.  In other words, they wanted you to paste a few commands into a shell and hit enter, regardless of whether or not you knew what it would do to your system. To be fair, this isn't exclusive to the Ruby community, but I grow tired of it in general.

Don't worry though; I still have a Ruby specific gripe.  Before I installed Rubygems, I had a sneaking suspicion that the latest version would not be compatible with old versions of the language.  This is in fact true, but good luck finding this information out on the Rubygems homepage.  It may very well exist, but the only place I found the answer was an old question on Stack Exchange. Without that hunch, who knows how much more time I would have spent struggling.

Ruby'ers - I get it.  I really do.  Configuration sucks.  It's boring, error prone, and compared to writing actual code, is no fun at all.  But dammit, sometimes it's necessary.  If you ignore configuration, you will have no idea where to look when something goes wrong.  And despite the fact that these languages and frameworks ask us to trust them, they can and will make mistakes.  The only way to deal with them is to know what the heck is going on in the first place.

Core Image Fun House on Mountain Lion

All in all, I'm torn on what I think about OS X Mountain Lion.  If I'm lucky, I'll write a more detailed post explaining my personal pros and cons, but this post has to do with one of my biggest cons - the loss of Core Image Fun House (which I just wrote about in my last post).

The problem stems from Xcode 4.4.  It seems that Apple made some major changes to the IDE since the last version I had, including removing the /Developer folder, which was where Fun House, along with several other utility apps, resided.  The other utilities were retrievable through optional downloads from Apple's Developer site, but none of them seemed to contain Fun House.  I scoured Google for some sort of answer, and was able to confirm that it is, in fact, not being offered with newer versions of Xcode.  I still have no idea as to why, nor have I found anyone else who's wondering where it went (which was a reminder that the Internet doesn't always pounce upon every single change in the state of the world).

Thankfully, I did manage to find a solution. Fun House is an incredibly simple program, and it looks like Apple used to include it as sample code back with Leopard.  The code is still archived, meaning you can build it yourself a fresh copy of the executable.  Here are some general steps on how to do so:

1) Download the source code from the above link (look for the button labeled "Download Sample Code").

2) Unzip the archive, and open the project in Xcode (you should just be able to select File -> Open and open the folder itself).

3) Once the project is opened, it isn't runnable right away.  If you're on Mountain Lion, you're going to have project configuration errors to resolve.  If you click on the yellow exclamation point in the top-center of the IDE, it should bring up a list of errors in the left hand column.  Here's an image of what you should be seeing:

4) Double clicking on the second of the two errors will allow you to fix the settings.  You'll get a popup stating all of the changes Xcode will make.  It will look like this:

Click "Perform Changes".  If you get a message about enabling snapshots, choose whatever option you want.

Once the changes are made, the code should be runnable, with one final caveat. You have to run Fun House as a 32 bit app, rather than 64.  Most likely it'll be set to 64 bit by default, and you'll need to change that. In the top left corner, near the run button, you should see the something labeled "Fun House -> something something 64-bit".  Click on this to change it to 32 bit.  Then you can hit the run button.  If all goes well, Core Image Fun House will launch.

If you get a successful launch, you can move on to the final step - creating a .app file that you can run when you're not in Xcode.  In the left hand column, if you select the little folder icon, you'll get a resource view of your project.  Under the products folder, you should see the .app file.  Right click it, select "Open in Finder", and you can then copy the file to wherever you'd like.