myWhazz Development

I’m in the process of moving our site from 100% full-browser Flex to a mix of HTML and Flex. We should have done it that way in the first place, but full-browser Flex got us way off the ground extremely quickly so I’m not too bothered. The single biggest change to moving our app into an embedded swf rather than full height and width and it seems to be moving along pretty smoothly.

I have one post on Generating Flex Layouts with Ruby Templates that’s been in the ol’ crock pot for awhile, stewing away. I also have one in the hooper that I’m not satisfied to publish yet that talks about Flex vs. HTML for new web sites/applications. Until the dinger dings, however, seeya next time!

Last night was the monthly Madison Software Developer meetup.  Quite a few folks were there, and as always it was great to hear about the interesting software that’s being worked on in the Madison, Wisconsin area.  Check out the meetup group and stop by sometime!

Last night’s discussion (aside from introductions) was mostly around Google Wave, Objective-C/C++, the virtues of Python, camera bars (you’d have to have been there), and more.  Having it in the Sundance bar was pretty cool– the place was dead so we had room to stretch out and relax.

The problem with embedding flash/flex components in web pages is that you must specify the viewport of the ‘movie’ and it’s tough to change it. That’s fine for flash movies, as they’re mostly movies. But Flex apps may need to change their size depending on what type of workflows they implement. I figured it would be a tough nut to crack: we’d need to trap resize events, and then call out to javascript in the embedding html page to resize the viewport appropriately. Not the hardest thing in the world, but I didn’t look forward to writing all that javascript.

Until I found out the coolest technique evar: you write your Javascript in an XML tag in your Flex code, and then inject that Javascript out into the browser at runtime and call it. That’s cool shit right there, friend. Big, huge ups to Noel at doesnotcompute for creating a reusable object that encapsulates this behavior: BrowserCanvas.  Noel’s examples are really illustrative, but they are Flash-oriented so I had to do a little re-jiggering to  use the lib in my existing Flex code.

Note: the widget I wanted to embed was a workflow nicely encapsulated in a single component, so I was able to easily add the item to the application at runtime rather than to write out the mxml. The toughest thing was just trying to figure out where to init the BrowserCanvas class, as I didn’t know exactly where the stage was available in the Flex Application life cycle. I ended up hooking into addedToStage and it worked fine.

The other issue I had to deal with was that I needed to explicitly pass the name of the object/embed objects that embedded the swf in the html page (”Shopping” in this case). The example at Noel’s website somehow figures it out automagically.

I also can’t end the post without shouting out the inspiration for the BrowserCanvas: this post on actionscript.org. It’s a really good read that lays out the idea behind Javascript injection from the flash/flex runtime. A fantastic read.

I spent all day Friday trying to prep a company CentOS VPS for a rails app. My first job: get ruby installed. Being more used to Ubuntu flavors of Linux I had no previous experience with YUM, but a package manager is a package manager is a package manager. I went for the gusto:

Oh, ruby installed alright. Version 1.8.1. Ugh. I updated the yum repositories again and updated only to find myself at version 1.8.5. Double Ugh. So, time to install from source. I ended up finding a really good writeup of the process at the fine blog Catapult Creative. The problem was that my CentOS install was ‘hardened’ per company policy so it had no tool chain, extremely outdated (’approved and tested’) versions of libs and apps, and little-to-no package manager repositories enabled. 

Now that I had an actual tool chain, I started about building ruby. I won’t go into the gory details (the link above has excellent step-by-step instructions). The only problems I had were that I needed to enable support for readline, etc. in the ruby install and it doesn’t compile by default. Also, to get the install to work with mysql I had to rebuild the native extensions for the mysql gem. After banging my head against the desk for 45 minutes, I realized it was a command-line typo that had done me in (!~CURSES). Ladies and gentlemen, note that, oddly, you need a total of 4 dashes in the instruction:

I was only using 3 dashes. After that, things were up and running quickly.

In reading the excellent RSpec Book, I came across a great idea that I’ve been using as my mantra of late: “write the code you want to have.”  In its original context, the authors discuss how to write your test scenarios when you have not yet implemented the code behind them.  In that case, they suggest you code to an imaginary world where you use all the wonderful methods and accessors that would make your life simple.  Then, you go and implement those wonderful methods and accessors.

I think it’s also useful at another, more philosophical level, however; sometimes we don’t write the code we want because we perceive it to be too difficult to write.  Or we don’t work in a language because someone says it won’t work, or we won’t be allowed to deploy it.  In these cases, writing the code we want to have becomes more of a rallying cry in order to Get Shit Done.  I need to make some kind of cross stitch sampler to hang on my wall with that thing.

Write the code you want to have.

I got real sick while on vacation in the mountains (a combination of cold/flu and altitude sickness) and had some down-time to work on my rails app.  My main goal is to get all of the user login/user invite functionality locked down before I start expanding the feature set of the app itself, as well as to get the existing code (not a whole lot) under test.

The QuickBase gem I’ve been working on uses RSpec for the unit tests, and I’d heard good things elsewhere so I bought the PDF version of The RSpec Book before we headed to the airport.  I’ve done TDD before, and am used to the xUnit syntax and philosophy but it was real interesting delving into Behavior Driven Development (BDD) and the way they used Ruby to reduce testing to real english sentences.  Below is an actual working example of my login integration tests using Cucumber:

I gotta say, to actually run the tests and see all green after writing that made me grin ear-to-ear.  I should note that it took me awhile (and a few swears) to get the constituent parts installed on my Macbook Pro (nokogiri in particular has a bug involved with installing it to vendor/gems and is very opinionated about your installed libxml2 version).  After a little bit of configuration heartache, though, I got things running really well.

The other slight issue I had in getting RSpec working with my model unit tests was that RSpec adds some generators for your use in Rails (rspec_model, for instance, which wraps the built-in ’script/generate model’) except that it generates the appropriate test code under /spec instead of /test.  I had obviously created many models, controllers, etc. without using the wrapped generators, so I had some work to do to manually establish the /spec folder hierarchies.  I also had to google a bit to figure out how to move over and include my fixtures from /test.  Ultimately, though, things settled down pretty quickly and I’m loving it.

I guess I should also declare that I_KNOW_I_AM_USING_AN_OLD_AND_BUGGY_VERSION_OF_LIBXML2 and loving it.

Also: I got Google Wave developer sandbox access.  More to come wheeeeeeeeeeee!

I’ve recently subscribed to Zed Shaw’s twitter feed and it’s been very illuminating. Just yesterday he posted a new [blog|article|rant] at his site about why he (A/L)GPL’s his code after his experience with Mongrel. Personally, I appreciate his stance, which (from the linked post) boils down to:

Open source to open source, corporation to corporation.

Specifically, I appreciate honesty like this, and Zed has an excellent point that many corporations accrue many ducats using open source code and libs without ever giving back to those same projects.  The good ol’ boy, ‘no-one-ever-got-fired-for-buying-IBM’ effect is still strong at large companies; they either want to be able to discreetly pay nothing for software or be able to brag that they bought a $40 million Oracle system.  So, allow OSS projects to use your stuff free, and charge those corporations up the wazoo for using the sweat-of-your-brow to get rich.  If your stuff really is that good, they’ll pay.

I feel like Zed’s latest post dovetails interestingly (though likely not his intention) with a talk he gave that I raved about on twitter awhile back.

Zed Shaw – The ACL is Dead from CUSEC on Vimeo.

This is a really good talk not only about a specific solution to a specific problem (ACLs in the banking industry, and how to build a better mousetrap) but later in the talk he also gets into some stuff that any software developers/engineer/programmer/whatever-you-want-to-call-yourself should at least have an opinion on.

Zed favors constantly improving yourself by writing code.  Learn new languages, new frameworks, new technologies.  Invent things.  Useful things.  Most importantly: do not give these useful inventive things to your miserable employer unless your compensation and respect is commensurate with them.  If your employer treats you fantastic, then hack away on the nights and weekends to deliver an improved build of Library X!  If you’re little more than a code slave, then do your job competently, go home, and create open source Library X for the good of mankind; or hell, create  your own company and sell Library X back to your original employer.

The reason that the monkeyfucks at slashdot don’t get this view is because it’s nuanced.  He’s not saying “Fuck your employer! Dog it at work! raggahaggharrwr!”  As he explains quite well in the video (starting at the 42:00 minute mark), you have your work coding, and you have your home coding.  If your company treats you really well, then let them in on the secret nuggets you’ve been doing at home!  If not, then be professional, do your assigned tasks, be polite, write really good code, but don’t let them have your ideas and inventions!

I like his views on a philosophical level, which contributes to my irritation when said views are dismissed because “I’ve never heard of him or his supposedly awesome projects.”  Jesus, if commercial (or apache/mozilla-level in the oss world) success were a prerequisite for an opinion, the slashdot comment boards would have goddamned tumbleweeds rolling through.

All of which is to say: I don’t agree with everything dude says, but then again I don’t have to.  He’s written some damn fucking fine code in his day, he’s orders of magnitude smarter than me, and I appreciate his views on Coding For A Living.  Also, you really should watch that video above– it’s got lots of good stuff in it.

And please let me be an example: don’t ever, ever, EVER read the comments at slashdot; they’ll melt your brain.

Recent frustrations have led me to flee back to Ruby/Rails, and so I updated everything the other day (gems, rails, etc.), bought myself a github account, and started to tinker with some web app ideas I’ve had floating around for awhile.  In doing so, I revisited a lot of old plugins and gems I used in the olden days (in railsworld, that means 2006), and tried to find out what the Rails community had moved towards in the interim.

User Authentication

Thanks to some advice from the MadRailers group, I first investigated AuthLogic for user authentication. Back in the day I remember using Salted Login Generator, which I had a tough time getting to work just because it generated so much damn code.  It was hard to see the plugins’ philosophy from afar (though likely more about my inexperience with Ruby/Rails than having specifically to do the plugin.)  As the Railscast superbly explains, AuthLogic doesn’t generate much code at all which leaves you to implement the lion’s share of the functionality.  That’s good!  By hooking up all the wires, you learn about how the module works and it’s easier to extend and customize it.

User Authorization

Once authentication was tapped down, it was time to turn to authorization. This I had very little experience with, since I didn’t explore it much way back when. Suggestions abounded, but I ended up exploring padlock_authorization, which was incredibly easy to setup and get working right away. Since my solution’s roles were heavily resource-based (this widget may have an owner, several readers, and an editor), this worked really well for me out of the box.

App Invites

I wanted to be able to have an owner of a resource be able to issue an invite to a non-user to be able to sign-up and automatically be added to the resource in a default role.  If there’s one thing I know about things like security and randomness, it’s that I’m not smart enough to devise my own solution.  Mostly because common sense only gets you so far in things like that.  I’d rather be able to generate truly random tokens to hand out to invitees than make my own random_string() function.  As usual, I found a great gem that did exactly what I wanted.  The uuid library is easy to install, and really easy to use.  From there I set up a simple SiteInvites model/controller and use the uuid.generate(:compact) method to populate the token field.  Works good so far!

Development UI

My main priorities at this point are to get the underlying models and interactions working.  However, I like to have at least a skeleton UI to work from until such a time as it becomes a priority.  To that end, ryanb’s nifty-generators were a godsend.  They set up some new script/generate targets to allow you do simple prototyping and skeleton work with prese-generated styles.  It’s great for getting something halfway-decent looking up and running quickly.

Summary

The four above gems and plugins have really been awesome in the pursuit of laying down a good foundation for a couple of the apps I’m writing.  Check them out, and donate to the authors if you really like them!  I’ll be continuing to blog about things I run into as I develop my apps.

I believe I’ll be taking in the next MadDotNet meeting on July 8th.  I attended the user group meetings a few times when I first moved back to Madison, but it didn’t really appeal to me at the time.  But after talking to a few guys at the Software Development meetup last week I really want to check it out.

The next meeting also covers RESTful services in .NET, which I’m excited to hear about.  A-way back when I tried to build a C# desktop app that talked to a RoR RESTful service and all that was really supported was SOAP/everyothermicrosoftonlytechnology.  For this meeting, I got myself the speaker’s book to check out beforehand.

A few days ago I started building an app I’ve had in my head for awhile now.  I wanted to see if I could throw my current Flex skills and personal situation (wedding planning) at Intuit’s new cloud computing platform.  I read up on IPP docs for awhile, downloaded all the tools, and then embarked on creating a test app (just crudding a name, date, and combobox selection) which took me all night and left me a little less enthusiastic.  But my heartache is your benefit, as I now have a useful tip.

The interesting thing about IPP is that you make your database first (online at workplace.intuit.com) before generating all your ORM/transport code in Flex Builder.  Even more interesting: the workplace schema generation process has no guardrails.  You can make fundamental choices (not mistakes, but choices) that will simply not allow your generated code to work.

So here’s the tip: do not name any fields in a table the same as a data type (especially built-in data type) in Flex.  My fatal problem in building the test app is that I named the date field ‘date’.  When the code was generated I got lots of (initially very confusing) compile errors:

Huh? Date is a built-in type, how is it not found?  Ahh, the class now defines a property called Date, which returns a type called Date.  Problem solved… eventually.  I went back to workplace and changed the field name to MyDate, and resynced the code generator with the new schema.  After that my app built, and I was able to continue developing.

Also, Cairngorm for small projects is like stuffing an aircraft carrier into a swiss army knife.