Managing server-side ssh commands

When running a long-running command over ssh, sometimes I need that command to be aware of the client connection and to exit with SIGINT on disconnect.

http://stackoverflow.com/questions/3235180/starting-a-process-over-ssh-using-bash-and-then-killing-it-on-sigint

Stdin and stdout are the best ways to detect an active connection. (Other alternatives require port forwarding, or log trolling.)

This is the best way I have found to do this. You want something on the server side that attempts to read stdin and then kills the process group when that fails, but you also want a stdin on the client side that blocks until the server side process is done and will not leave lingering processes like <(sleep infinity) might.

Rails ajax render template

When working Rails Ajax queries, I commonly need to update more than one section of a page. For instance, a submit action might update a data table, but may also need to show some notifications in #messages. I've collected a few techniques that I've found posted in various forums and blogs into this solution that I use.

One important thing to note is that Rails is much friendlier with form submissions with remote: true than it is with $.ajax() calls. ActiveRecord models tie gracefully with the form_for tag, but sometimes link_to tags are used with anchors (links).

The first thing to use is the remote: true form option which sets the html data-remote attribute. Secondly, set a custom data-update-target attribute which specifies which div to replace with the body of the rendered ajax layout.



The shared messages template is used by both the main application layout and the ajax layout to provide updated notices on ajax actions.



Here is the ajax layout template rendered for the response:


And here is the javascript that extracts the #messages div replacing the notices, and replacing the data-update-target div:



Finally, in the controller, set the ajax layout for the action.

Android Model-View-Presenter

There are a lot of conflicting recommendations around using the MVP pattern with Android activities. The two suggested approaches make different tradeoffs, and while one of the approaches looks good on the surface, it misses the point.

The first school of thought is that the view is the layout and the activity is the presenter. This approach is convenient because the view only needs to subclass a layout like RelativeLayout and the presenter already receives some of the interesting events such as onCreate, onResume, etc.

The second approach is cleaner from the presenter perspective. The goal of the MVP pattern is to separate the view logic from the view itself. Therefore, the presenter should be divorced from any kind of view specific hierarchy, such as extending Activity. This goal exists to make the presenter more testable, and it is worth the message forwarding from the activity (now the view) to the presenter.

It is fairly trivial to create a common AbstractPresenter and AbstractViewActivity that forward the most common events to the presenter: onCreate, onResume, onPause, onDestroy, onCreateOptionsMenu. Now it becomes much simpler to define the Presenter.View interface that extends your common view interface and provides the view specific methods such as setSelectedTab, enableMenuActions, or whatever interfaces you may need.

Also, by making the activity the view, the most trivial logic can be left in the view itself since only the most interesting logic needs to be tested in the presenter. For example, when handling a menu item action, a confirmation dialog may need to be shown. The real presenter logic takes place in the ok/positive button listener, and there is no need for the presenter to handle the logic of confirming the action with the user. It is actually the logic that taken when the ok button is selected that is the subject under test, so the ok button listener delegates this action to the presenter.onSomeInterestingAction.