HookLyingSyncer: gem to keep method_missing and respond_to_missing? in sync

   A while back, I wrote about the need to keep method_missing and respond_to_missing? in sync.

   (A brief refresher: in 2011, Avdi Grimm wrote a blog post about that.  In the comments, I wrote up a quick and dirty hack to do so, in very restricted cases, and then a still-dirty improvement, that unfortunately has since been mangled somehow.)

   At RubyConf 2014, Betsy Haibel spoke on Ruby metaprogramming, including that same need.  That inspired me to work on the concept again, taking a different approach (essentially a decorator) that I had briefly considered in those comments.

   The result is my new gem HookLyingSyncer.  (I was going to call it FirstResponder, but that name was already taken.)  The code is at https://github.com/davearonson/hook_lying_syncer.  For now, the code looks like:

class HookLyingSyncer

  def initialize(object, matcher, &block)
    @object = object
    @matcher = matcher
    @block = block
  end

  private

  def respond_to_missing?(sym, include_all=false)
    matches = find_matches(sym)
    matches.any? ? true : @object.send(:respond_to?, sym, include_all)
  end

  def method_missing(sym, *args, &blk)
    matches = find_matches(sym)
    if matches.any?
      @block.call(@object, matches, *args)
    else
      @object.send(sym, *args, &blk)
    end
  end

  def find_matches(sym)
    result = @matcher.call(sym)
    result ? result : []
  end

end

   The tests contain some examples, with further usage explanation in the README.  Long story short, it can be used on instances and classes, to add or override method definitions, including overriding new so as to add methods to all new instances of a class.

   This is my first time actually making a gem, and I haven't done much with metaprogramming before, especially something that other people are going to use to do their metaprogramming.  So, any feedback would be greatly appreciated!

Windows and Linux and Mac, Oh My!

   Someone recently asked in the Google Plus Ruby on Rails community: Which platform would be the best to use for Rails?  My answer got so long, and is so applicable to working in most other languages, that I decided to turn it into a blog post, so here it is, with a few minor edits.

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

   Basically, any reasonably popular platform EXCEPT Windows.

   Windows (ignoring the Server variants) is made for the desktops of non-technical people (and people developing software specifically for Windows).  It comes with essentially zero development tools, and you have to pay for most of the serious ones, especially for the MS stack.  You can kinda-sorta fake a lot of Unix by installing Cygwin, but that's just a kluge and falls way short.

   Linux and other Unix variants such as BSD, Solaris, etc. are made for servers, and the desktops of VERY technical people.  They come with (optional on installation) lots of serious development tools, with many more easily available, most of them free.  Of these OSes, Solaris is pretty much dead, and BSD is very rare outside the server room (so there's nowhere near as many resources for help and education), and the others except Linux have very tiny market share, so let's focus on Linux.  However, Linux  has a bad reputation for requiring a lot of tweaking to get it to work reasonably well, especially if you're using hardware that is in any way not absolutely standard, such as a graphics card from within the past year or a maker that's not one of the top three.  This was reality, and why I switched to a Mac, in 2004, but I've heard Linux has gotten a LOT better about this since then, especially the Ubuntu "distro" ("what's a distro" is a whole 'nother question!), which (I've heard) places great emphasis on working right out of the box.  Linux is also free (though you can buy boxed sets with docs, support, and so on), and generally efficient enough to make good use of older PCs that won't run well under recent versions of Windows.

   A Mac is a reasonable compromise, at least as of when OSX first came out.  (Before then, it was aimed mainly at graphics people, like artists and people who put together print newsletters and magazines.)  The tooling situation is similar to Unix, except that it doesn't come with quite so many, and usually older versions.  It also doesn't require anywhere near as much tweaking as Linux does, because you're running it on exactly the hardware it was designed for.  It's even more consistent in its UI behavior and look-and-feel than Windows, and about as easy to understand -- but it's different, so you'll have a lot to "unlearn" if the Windows way of doing things is deeply ingrained in your habits.  It also used to be much more stable and secure than Windows, but MS has made great strides in their security and stability, catching up and, depending how you measure things, possibly surpassing OSX's security (not sure about stability).  On the other claw, it's a good bit more expensive than a bog-standard Windows box, never mind Linux, but frankly, they're so good that putting together a Windows PC with the same performance will usually cost about just as much, even before factoring in the cost of serious dev tools, OS upgrades (usually dirt-cheap or even free on a Mac), etc.  You can get some good bargains on a used Mac, one or two generations old; ask a Mac-using friend to sell (or even give, if you're lucky!) you one of his old castoffs, or take your chances on eBay.

Don't Cast Your Net So Wide!

   My current client, in my work as a freelance software developer, uses Jing screencasts heavily.  The QA analysts use them to demonstrate problems and how they test solutions.  I've started using them myself for demos of my implementations (for BA/PO approval) and bugfixes (for QA approval).

   But don't worry, this isn't going to be a heavily technical post, with programming and systems terminology thrown at you.  It's just going to be a bunch of tips I've figured out for making a good screencast that your viewers can easily follow.  These tips apply whether you're recording with Jing or any other tool, and hosting the video at screencast.com like Jing offers, or anywhere else.

   First, sometimes people screencast a very large area, when they don't need to.  It might be the entire screen of their monitor, or a very large window that could have been made smaller.  This means that the viewers have to use a very large window themselves, or scroll around a lot, in order to see everything.  Maybe they don't actually have to see everything that's being shown.  That's a prime indication that the size should be cut down!  This becomes even more important with Jing-type videos (as opposed to YouTube), since you can't just click anywhere, or press the spacebar, to stop or pause it.

   But how can you cut down the size?  What I've been doing is to use a relatively small window (whether browser or terminal or whatever), usually as small as I can.  For what I've been doing lately, that's around 960x720, but I've done others at 800x600 and even 640x480.  (If you host your videos on YouTube, they have several standard sizes you can aim for, for the clearest picture.)

   You might need multiple windows, such as if your demo involves both a terminal or editor window where you're editing code or directly manipulating data in a database, and a browser window where you show the results.  In that case, stack them in the same area, so that the largest one completely covers the other(s).  If you need to have multiple of them visible at the same time, lay them out that way, within the size of the largest one.  If that's not possible, use another window that's there just to establish the size; you don't have to ever actually show it.

   Then, when starting your screencast, tell your software to record the area covered by the largest window.  With Jing, it's easy; upon telling it to Capture, it will give you crosshairs so you can lay out an area.  Instead of dragging an area, simply click on the window, and it will choose that as its area.  (It will also tell you just how wide and tall the area is, so you can get the size you want.)  If you're using something else, it probably has a similar feature; at the very least, it should let you switch which window is being recorded (so you might not need to stack them), maybe even following along with focus.

   Sound quality is also important.  If your voice sounds "distant", with your system's fans making a lot of noise, you may be very hard to understand.  The usual cause of this is using your laptop's built-in microphone.  That's fine for informal chatting, but for recording, where the listener can't just ask you to repeat something, it doesn't cut the proverbial mustard.

   At the very least, use some kind of external microphone.  You can use an old-fashioned one, or even the one on a pair of cell phone earbuds, plugged into your system's microphone jack -- if it has one.  If you opt for earbuds, just be careful about letting it rub against your shirt, as that will make noise.  Even laying it on the desk in front of you will probably be better than a laptop's built-in mic, as it will be further from the fans and closer to your face, but beware of typing noise.

   Better yet, use a headset, with a boom mic.  (Position the mic higher than the base of your nose, so you don't get breathing noises.  I usually put mine beside my cheekbone.)  If it's the kind with a fairly directional mic, "listening" mainly in the direction of your mouth, it will even help cut out some of the other random background noise.  Headsets can still come with the old-fashioned 1/8" plug, but USB headsets are everywhere nowadays.  You can get a decent-quality USB headset for well under $20, though you may find it worth splurging if you use it a lot, or need fancy features like a noise cancelling mic.

   (For about four years now, I've been using the cheap-seeming set that came for free with my Rosetta Stone order.  I've used it for an average of about half an hour a day in that time.  It's comfortable, very light, and gives very good voice quality -- as you'd expect, to feed into their speech recognition software.  The only problem that has developed is a slight looseness in the boom when within about 45 degrees of straight up.  You could probably find something of similar quality for the princely sum of $10 on eBay.)

   Then there's the whole matter of presentation skills.  On that, I'll mostly defer to Toastmasters International.  The few tips I will put in here are: plan out what you're going to say and do (typing, mousing, window switching, etc.), speak loudly enough to be heard easily but not painfully loudly, and don't drone on in a boring monotone.  Keep your sentences digestably short, and use vocal variety to emphasize the important points.  Remember, the listeners can't see you!  (Except of course if what you're screencasting is your camera feed, but that's a whole 'nother story.)

   After you've finished making your screencast, watch it yourself!  You might spot some parts where it might not be clear what you're trying to show (or even what you said), or where you make the watcher sit through an extended period of your floundering around trying to figure something out.  If so, take it as a practice run, and do it again.