Thursday, December 8, 2011

Ruby Geekery: Defining method_missing and respond_to at the same time

   Not all the code (or coding comments) I'd like to share with the world, is on my own blog.  Recently I made a comment I'd like to direct y'all to, over on Avdi Grimm's wondrous blog, Virtuous Code.  Long story short:
  • Ruby has this interesting mechanism called method_missing, whereby you can call a method that doesn't really exist, but method_missing will be called instead, recognize the name, and know what to do, often by pulling apart the name and acting on pieces.  (Yes, that's how a lot of the magic in Ruby on Rails works.)
  • There's also respond_to?, which you can use to ask if an object responds to a given message, which is "OO-geek talk" for whether it has a given method.   (Yes, "method" is basic OO terminology, but I mean hardcore OO-geek talk, the kind used by people who actually use languages like Smalltalk!)
  • The problem is, adding a method by having method_missing recognize it and perform the action, does not also add it to the things respond_to? knows about!  You could also manually add it to respond_to? at the same time, but that's not very DRY.  As some of us pointed out, that's exactly the kind of drudgery we expect Ruby to save us from.  (Sometimes you can have method_missing really add the method, in which case respond_to? should see it just fine, but that's another story.)

  • So Avdi wrote a blog post about what he came up with to do it automagically.

  • As I started reading his post, I envisioned a way to do it.  When I got to how he did it, it was a lot different.  His is suitable for dynamic situations where mine wasn't.

  • Later I came up with another way that is also dynamic, though some rough spots remain to be worked out.

  • Later still, I intend to come up with some further improvements.

  • Your feedback is solicited, whether there or (preferably) here.
   See: http://avdi.org/devblog/2011/12/07/defining-method_missing-and-respond_to-at-the-same-time/.

Tuesday, November 22, 2011

I Am Decider, Hear Me RoR!

   I have finally gotten off my duff and pushed a little app to Heroku.  The UI has not yet been polished at all, and the workflow still needs some tweaks, but the basic functionality is there.  It's a decision support tool, that lets you create a bunch of Decisions.  Each Decision has Alternatives (which just have names), and Factors (which have names and weights).  Editing a Decision lets you rename it, and add or remove Alternatives and Factors.  Showing the decision presents a spreadsheet, on which you can rate how well each Alternative rates in each Factor.  It sums them up and shows you how each Alternative fares overall against all the others.


   Check it out at http://thedecider.heroku.com.  Let me know if you find it at all useful, or unclear, or whatever.


   Plans for it:
  • Polish the UI!  Those of you who know my career, know that I've usually done software that has no UI, or at least not one that needs visual polish (as opposed to a command line or an API).  So I decided to concentrate on the functionality first, as usual.
  • You can't get an email reminder of your password.  Frankly I haven't dealt before with having a RoR app send email.  I need to learn how to do that.
  • The rankings cause a submission on change.  The Alternatives are automagically sorted in descending order.  Either of these alone is fine.  Together, though, they mean that the Alternatives can seem to "jump around" while you're busy editing.  I intend to fix this by making you click a Submit button to submit any changes.
  • Signing in takes you to a home page, on which the only function link is to your list of decisions.  I'll make it take you there instead... and if there's ever anything of further interest on the home page, provide a Home link.
  • It's clumsy to have an Edit screen to add Alternatives and Factors and a Show screen to edit the Ratings.  I intend to just have the Show screen, with Add Alternative and Add Factor buttons.
   Any other suggestions?  Any other simple little RoR apps you'd like to see me do?


   After I clean up some klugy tests, I'll post the latest code on my Github repo -- what's there now is an earlier non-working version.

Wednesday, October 5, 2011

For Hire!

   Well that didn't quite go as planned!  :-(

   Long story short, I've been "let go".  Turns out Rosetta Stone needed more of an ActionScript guru than I was able to turn into over the course of about ten months, starting from scratch.  Of course, it didn't much help that they refused to send me to training on it.  Reading AS books and following AS blogs in my spare time, listening to AS podcasts during my commute, and asking my colleagues about their approaches when writing or analyzing AS, was not enough to make it "click" for me.  Oh well.

   Now I'm trying to turn that into a BID -- Blessing In Disguise -- by getting back to trying to land work in modern languages with a bright future (which I don't believe ActionScript has).  You can help by checking out the Availability page on my main web site, and telling me about suitable opportunities.

   A bit of background:

   I learned Java on my own time, expense, and initiative (the same way I learned many other things), back around 1997 or so.  But, I didn't push hard enough to land serious work in it.  Sure, I used it on my own, and got little snippets of work here and there, like a target for the static analyzer at Secure Software, and modifying a JSP page at BAE... but nothing "real" that would get me "street cred" in it.

   Now look at the job market.  Java seems to be about 3/4 of the job ads around here... and even the simplest of them, other than for freshouts, demand five solid years of recent hands-on enterprise-level (read: paid) experience in J2EE, with all the "trimmings" like Hibernate, Struts, Spring, and so on.  Those of us who aren't fresh out of school, and haven't had significant Java experience yet, are effectively locked out of ever getting it.  (Unless of course we luck into a very open-minded employer, but those are a rarity -- especially with the now-perennial surplus of Java coders.)

   So much for Java.  Now let's look at Ruby.

   Ruby is new enough that companies are having a hard time finding people.  (Of course, that doesn't stop HR from insisting on years of experience, but as always, the best way is to bypass the drones with their checklists of words they don't really grok.)  It's highly productive, with much less boilerplate than ActionScript, never mind Java.  Even aside from Rails, it's taking off like crazy.  And... it's very easy to learn.  I learned enough in one hour to do the "homework" Comcast assigned after the interview.  This means we may soon face a perennial surplus of Ruby coders as well.

   I missed the Java boat, and don't want to miss, if you'll pardon the expression, the Ruby yacht.

   (No, I didn't make that all up just to use the pun.  But it was there, and those of you who know me, know that that means I just had to use it.  If you don't get it, click here.)

    To reiterate the main point, you can help by checking out my consulting web site, and telling me about suitable opportunities.

Monday, June 6, 2011

Not the FTP Client

   Just a disclaimer: this site is not connected with the Codosaurus FTP client, found at http://grilledbacon.com/.  I only discovered that yesterday, and by an amazing coincidence my first iPad will supposedly be arriving soon (anniversary present), so I haven't even tried it.

Sunday, April 24, 2011

Password Security

   Some of you might know that this blog is not my only means of communicating technical information.  I have also led classes, mentored colleagues, given briefings, and so on, at work.  What some of you might not know is that I also give speeches at my Toastmasters club.  Occasionally the topics are technical, such as this one I gave last Thursday.  (Okay, it's nothing new for me, but it may be for you....)

===8<---cut here---

What's the Good Word?

   Raise your hand if you've got anything important protected by a password... and keep it up if you know how to pick a good password.

   Mr. Toastmaster, fellow Toastmasters and honored guests, if you put your hand up, but didn't keep it up, you need to listen up.  First we'll look at what makes a *bad* password, so you can avoid them, and then, some ideas on how to make a good one.

   A bad password is one that is easily guessed.  In the movies, the clever hero racks his brain for the one word that the villain uses to protect his evil schemes.  Reality, though, isn't usually like that.  Most attackers aren't after *your* account, but *any* they can crack.  They won't research you, let alone type guesses one by one!  Pros use tools that try hundreds of guesses per second, from lists.  So it boils down to what's on the lists.

   There are generally three levels of lists.

   First are common passwords.  Some might be otherwise decent passwords, but so many people use them, that now they're worthless.  Password.  Short phrases like LetMeIn.  ILoveYou.  Finger-drumming patterns like 123456, Qwerty, and Asdfgh.  And the name of the site.  If a lot of other people are probably using your password... change it as soon as you get home!

   Next come words of types commonly used for passwords.  Names for people (first, last, or nick names), pets, places, schools, sports and their teams, from all over the world.  So if your password is the name of your significant other... or your chihuahua (like Paris Hilton did)... or any of these others... change it as soon as you get home!

   Last comes the entire dictionary, or rather all the dictionaries they can find, including jargon and foreign languages.  So if your password is in any dictionary, what should you do?  Yes, change it as soon as you get home!

   It's not enough to spell a word *backwards*, or substitute digits for letters they resemble, like zero for o and one for i.  These tricks are so well known that attackers also use lists like that.

   I've scared you enough for one night, so let's look on the bright side: what's left for good passwords?

   The best passwords are long and random, with upper and lowercase letters, digits, and punctuation.  The bad news is, that makes them hard to remember!  The good news is, you don't have to!

   First, you can use multiple words.  For an account at SunTrust Bank, the name might remind you of sunburn, and the "trust fall" team-building exercises.  Put them together, in either order, with some numbers or punctuation in the middle or on the ends.  Maybe you got sunburn on a team-building retreat in 1987, so use "1987FallBurn".

   Next, try a virtual password, based on a longer set of words.  Pick a line from a story, a song, or a poem.  Take the first letter from each word, or the second or last or whatever.  Using the first letters of the first line of "The Star Spangled Banner" yields "Oscys,btdel".

   Lastly, use multiple ways of altering words.  Digitize every *other* eligible letter.  Add something to each digit.  Press Shift on every other character.  Doing all that to the worst password of all, "password", gives "p&s*wOrD".  Much better!  Doing it to the virtual password we made earlier, gives "O8CyS,0tD6L".  I'm sure that's not in any dictionary!

   Just pick a memorable starting word, or set of words, and a few ways to combine and change them, and remember those.  Then you can *recreate* your password any time you want!

   To recap:

   DON'T use common passwords, or common words, including names, places, sports, and teams, even with digits put in for letters, and backwards.

   DO use multiple words, virtual passwords derived from several words, or at least long words, and alter them, to get a mix of upper and lowercase letters, digits, and punctuation.

   With these few simple secrets, you can keep your secrets secret.

===8<---cut here---

   Of course, there's a lot more I could have said, like not just using letters because of brute-force attacks, quote some gurus, how to keep them safe, and mention specific password leaks like the big ones from Hotmail and Gawker... but this was for Project #5 out of the "Speaking to Inform" advanced manual (now finished, yay!), so I had a dictated timeframe of six to eight minutes. The above just barely fit within the grace period, coming in at about 8:20.