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"?