Gunpla Chronicles 2: Accessorize

After finishing the Core Fighter, I continued to stay small, working on the Gundam's weapons before getting to the mobile suit itself.  I began with the Beam Rifle, which has a nice two tone look in this kit:

There's not much to say here.  There aren't any nasty marks on the plastic, and I got some nice panel lining on the grey sections of the piece.  I also managed to get the red sticker around the barrel of the rifle to line up nicely.

Next up was the shield.  There's one noticeable flaw on this one - the yellow cross on the front of the shield is uneven at the bottom.  I blame this on overeager sanding.  It isn't hugely glaring, but I'm still disappointed with myself:

On the bright side, I'm happy with how the stickering worked out.  The shield has many stickers which go on its left and right sides, and I think I got them to line up quite well.

The Hyper Bazooka rounds out our assortment of armements.  If the shield was all about sticker alignment, the bazooka was an exercise in proper panel lining.  This thing has a lot of panels, and its small size means that accidental smudging was all too easy.  I had one fit with the eraser that was so bad I had to call in reinforcements (otherwise known as a Qtip).  I can't complain about the finished product though:

Taken as a whole, the unevenness of the cross was my only major gaffe, which means I did a better overall job with these weapons than I did with the Zaku's.  I had a lot trouble applying the stickers on those, and I left one side of the Heat Hawk with what I can only describe as "battle damage".  I'm really happy with my work so far, but all of this has been a warmup for the real thing.  Time to build the Gundam itself.

Gunpla Chronicles 2 - Core Fighter Update

Before I begin the meat of this post, I have an update on the Core Fighter.  I read on numerous gunpla sites that panel lining marker can be removed with a pencil eraser.  I thought it sounded too good to be true, but take a look at what happened when I took an extra fat eraser to the top of the craft:

Good as new! And in a hilarious twist of fate, I lost one of the two stickers that are supposed to go where I just removed the marker.  Thankfully, I didn't like the look of the stickers anyway, so I don't
mind the loss (and I'm still happy that I removed the marker - it looks perfect the way it is now).

I also looked more thoroughly into how to effectively use sandpaper on model kits.  Call me naive, but I didn't realize that you could actually smooth out the look of plastic by using very high grit sandpaper.  While none of the sheets I have are as fine grit as the ones the super Gunpla builders suggested using, they were good enough to fix up the bottom of the Core Fighter.  The lighting in the picture below isn't quite as good as the previous shot of the underside, but I can vouch for the fact that that huge scratch has been buffed out about as nicely as it looks here.

With my two major crises resolved, it was time to apply the remaining stickers. Here's how it looks as it waits to be sprayed with some clear coat paint:

... those stickers look a hell of a lot worse in the picture than they do in real life.

In my last post, I was far from happy with the way the Core Fighter was shaping up, but after being patient and correctly applying these fixes, I think it looks pretty fantastic.  Perhaps it was a good thing that I faced such a challenge right off the bat.  It helped me prove to myself that I can tackle this kit with a better mindset, and that ultimately, I have what it takes to improve.

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.