Friday, April 19, 2013

Remapping a Control key to Windows / Super Under Ubuntu 12.04

My old ThinkPad keyboard rocks: it has a trackpad and a trackpointer, types nicely, has a palm rest, and is generally awesome. It does not, however, have a Windows button: this makes using it under... well, anything... difficult.

I'm currently developing with a company-bought Ubuntu laptop after having used OS X for the last three years almost exclusively. Like Windows and OS X, it pretty much demands the use of a Super key for accessing OS functionality and popping up utilities and applications.

I used two tools to do the remapping, xev and xmodmap. The lower-left control key is key code 0x25 (37). Ultimately it ended up being simple, and my .Xmodmap looks like this:

clear Control
keycode 37 = Super_L
add Control = Control_L Control_R

I also added the following to my .xinitrc, but it may be redundant:

xmodmap .Xmodmap

It's more awkward than a proper Super key, but it's workable, and I'm typing happier.

Tuesday, March 12, 2013

sftp "Received message too long" on OS X

Today I started receiving the following error when I tried to sftp to my localhost, both from the command line and from the Ruby Net:SFTP library:

$ sftp ftpuser@localhost
Received message too long 1399157792

Trivial digging revealed that ftpuser's .bashrc script was writing to stdout, which apparently is enough to confuse sftp all 'round. I modified the command it was running to redirect stdout to /dev/null, and the problem was resolved.

Tied to the Web Layer

Struts 2 claims that "actions can be POJOs". Developers find out pretty quickly that not extending ActionSupport means you lose some Struts 2 functionality (primarily I18N and validation).

One source of confusion is what "POJO" means. POJOs don't mean you don't extend a base class. POJOs are classes not directly tied to unrelated libraries, specifications, etc. For example, Struts 1 actions were directly coupled to the Servlet specification and Struts 1: S1 action methods had signatures including things like HttpServletRequest and ActionForm.

I think of S2 actions as the interface between the client (browser, REST consumer, etc.) and the stuff that actually gets stuff done. S2 handles validation, type conversion, flow (or at least conversion of business-level flow into web-app flow), etc.

Heavy lifting happens outside of anything related to my web layer: persistence, logic, and calculations happen in services, utilities, models, and glue. How is it relevant that my web layer actions are tied to their web layer? What would be the cost of changing web layers?

Web layers all have their own ideas about how to interface to clients. Some use annotations. Some use XML. Some use conventions. They do validations differently. They handle flow differently. They handle form parameters differently. No matter what, the layer between the client and my business logic is going to change, radically or not, if I port to a new web framework.

That my actions extend ActionSupport isn't going to be the pain point: the request handlers are going to change no matter what. How I expose validation errors to the view will change. How I retrieve form parameters will change. How I define validation will change. How I do I18N will change. How I code the view layer itself will change.

That's not to say there aren't (or shouldn't be) unified ways to do all those things, but at the moment, there isn't a single standard approach (and maybe there shouldn't be, although a "web AST" would be cool). The trick is to minimize the coupling between the client and the application's guts.

- Work in progress -

Monday, March 04, 2013

"Unknown error" while signing in to Apple App Store

I was unable to log in to the Apple App Store while trying to update Xcode on my MBP.

Here's an Apple discussion thread regarding possible solutions.

What ended up working was signing out, clicking "Store -> Create New Account", accepting the Terms and Conditions, then canceling out of new account creation and signing in again.

While deleting the network interface plist, cookies, etc. was educational, it didn't work.

Accepting T&C while not creating a new account so I could use my old one... "It just works"?

Thursday, August 23, 2012

A JRuby, Rails, RSpec, Spork, and an error walk in to a bar...

I was running a specific rspec over and over during a tight development cycle. The way our system was set up it was taking 30+ sec to run a single spec file, which made running them onerous.

We had Spork running at one point, but it wasn't working for me, with a "undefined method 'flush' for nil:NilClass" error (and a couple of others depending on the incantation):

After upgrading Spork (we had been running an older version), setting the JRUBY_OPTS environment variable, and restarting Spork, the spec time dropped to ~8 sec. Still not particularly fast, but faster-enough to make it worth it.

Not currently running Guard. Not sure if the upgrade or opts made it start working.

This post is a work-in-progress.

Wednesday, August 08, 2012

RSpec Error With Implicit Subject

Ever write a trivial spec like this:

And get something totally baffling back, like this?

Backstory: Refactoring some pre-written classes to use metaprogramming to create some methods and values. I wanted specs in place before starting the metaprogramming to avoid breaking things.
In retrospect, I should have figured this out sooner. In my defense, I love the Olympics and was distracted. The constructor of the model gives it away:

A parameterized constructor, no default value: rspec couldn't instantiate the implicit subject.

Silly mistake, exacerbated by magic, hidden functionality–it's one of the greatest things about Ruby, but can occasionally lead to opaque behavior, especially during the Olympics.

Saturday, November 12, 2011

Testing singletons while avoiding their constructors

Singletons are evil, and here's why.

Fair enough. Yet they exist, and they're not intrinsically evil--just misused. Can we mock enough to make testing them feasible? Yep, and here's a Contrived Example™ that shows how (and why we might want to).

"Embedded" singletons or utility classes can make testing is problematic. Injected singletons are different; then it's an issue of whether or not it should be a singleton at all--different discussion.

"Embedded" singletons look like this. (Utility classes are essentially the same, minus an instance.)

Let's say (a) we need to test this code, (b) we cannot modify this code, and (c) the singleton's constructor is long-running, but required for fetch() execution. For testing, then, we need to (a) avoid the constructor for speed reasons, and (b) mock the fetch() method to return known data for the test. We can't just mock fetch(), because the constructor would still run.

Here's our (contrived) singleton class; we sleep() in the constructor to pretend it's doing something interesting like caching data from a web service, to be returned by fetch().

The undecorated test does what you'd expect, and takes as much time as you'd expect.

Now, with a combination of PowerMock and EasyMock, we'll put the kibosh on that, eliminate the constructor, and return the data we want. (PowerMock sits on top of EasyMock or Mockito. (Both are great, although I tend towards Mockito.)

Most of the test class is self-explanatory. The nutshell version is that we annotate the test class itself and tell it to run with the PowerMock runner (@RunWith), and that we're going to be messing with LongRunningCtor's innards (@PrepareForTest).

Inside the test itself, we tell it to suppress LongRunningCtor's constructor (before mocking, otherwise the constructor will fire during the createPartialMock() call). We also prepare for mayhem by calling mockStatic(). (This mocks all the class's static methods; we could also choose specific static methods to mock using mockStaticPartial().)

Our test now takes a fraction of the time because we're skipping the slow constructor, and our mock returns known data so we can exercise only the calling code.

Ideally, code is structured so this kind of byte-code treachery is unnecessary--it's a great reason for dependency injection/inversion of control. In the real world, technical and timing constraints don't always allow the kind of restructuring we'd like.

With the aid of some tools that do the low-level dirty work for us, we have a relatively clean way to work around some types of system limitations, and still write tests that can execute quickly.

The gist used in this post also includes the relevant Maven dependencies.