Seeking Sophrosyne

Stop SOPA, Save the Internet

http://boingboing.net/2011/11/11/stop-sopa-save-the-internet.html

I can't think of anyone who should not be opposed to this. On Wednesday, November 16th, please call your representative. The Internet is the greatest haven of free speech mankind has ever seen, and groups like the RIAA and MPAA want to close it off. Yes, this is worse than the bailout if you disagreed with the bailout. Yes, this is worse than the war in Iraq if you disagreed with that. Yes, this is worse than Occupy Wall Street or the Tea Party, depending on where you stand. Yes, this is worse than the debt limit debate.

This has nothing to do with piracy. This has to do with free speech. Share it, call your representatives, and let's stop this bill from getting passed. We are a bastion of free speech, but that bastion is cracking. Let's shore it up.

Notes on deploying Lift apps to Glassfish

I just wrapped up switching our deployment of OpenStudy from Jetty to Glassfish. We learned a couple of things, but the most important one has to do with non-Jetty continuations support. The default web.xml that ships with Lift sample apps and such unfortunately does not include a required parameter, and also doesn't seem to be in the right schema, to enable Glassfish continuations. This caused us some serious head-scratching (and a lot of tied-up threads), since very few places deign it necessary to tell you that you need to have this setting in your web.xml. 

To fix up your web.xml, you'll want to drop the doctype and change the web-app tag to:

This indicates you're using a more recent version of the schema, which lets you specify you want async (continuation) support. Part 2 is updating the filter declaration that sets up the Lift filter and servlet. You'll want to drop the description and display-name tags in the filter, since they no longer seem to be supported. Most critically, you need to add

<async-supported>true</async-supported>

This lets the container (Glassfish in our case) know that we want continuations for our app. If you're wondering why we're telling the container we support continuations rather than the container telling us that it supports them, I didn't find a proper explanation of that. All evidence points to this being a requirement if you want a Servlet 3.0 container to enable continuations support.

The other thing we quickly noticed is that Glassfish seems to use up more file descriptors than jetty does as it manages similar load. This seems like it may be related to the bug at http://java.net/jira/browse/GLASSFISH-11539, though that bug is marked fixed and we're running Glassfish 3.1.1, which is well past the 3.0.1 fix release. Nonetheless, we find the file descriptors leveling out around 34000, so as a stopgap we simply go to /etc/security/limits.conf and add:

@admin soft nofile 10000 @admin hard nofile 65535

This bumps up the file descriptor limit for processes run by users in the admin group, which our glassfish process user is.

So far things have been going well; we switched to Glassfish to avoid the NullPointerExceptions that jetty starts giving us under load (more at https://groups.google.com/d/topic/liftweb/MeJnuk-lH9A/discussion). So far, we haven't seen a similar instance with Glassfish, but it's early days yet. Fingers crossed!

Free your popup arrows (from images, mostly)

I've always been a fan of doing things without images when possible. There isn't always a clear reason for it; the classical reasoning is that it saves bandwidth and HTTP requests etc etc, but to be honest my main goal is a challenge. Yes, we often derive the aforementioned benefits, but really it's just fun to try and figure out how to do things that *should* be doable without images in straight HTML+CSS+JavaScript. To that end, today's little project is creating a popup with an arrow pointing back to something coming out of one of the borders. Something that looks a little like this:

Sexy right? That little left arrow is the challenge. First off, some markup:

This is more or less lifted directly from the OpenStudy code base. I'm not going to bother detailing how the owl is taken care of; instead, I'll focus on the borders, drop shadow, and most importantly the left arrow.

Notice that there is a class `left-arrow' on the div. This is because we want to create the system so that it has relatively flexible positioning. On OpenStudy, we use left-arrow, right-arrow, bottom-left-arrow, and top-arrow. For the purposes of this post, we'll focus on left-arrow and right-arrow and leave the rest for tinkering purposes.

First off, you'll notice that there is no element dedicated to the arrow. Unfortunately, this isn't because it isn't necessary; I just like to have markup that is devoid of empty elements that are strictly presentational. When I do need them, as in this case, I put them in after the fact using JavaScript. In this case, when a tooltip is loaded via AJAX, the loading process adds a new div with class `arrow':
This is nearly the end: what remains is taking that div and turning it into the arrow we see above. To do this, we take advantage of CSS transformations. These let us, for example, rotate an element. Here, we will give the div an equal width and height and then rotate it 45 degrees so that it is a diamond instead of a square:

https://gist.github.com/1089727/4db7f762a00d2e8d968cb1df621c0f07f994084d

Here, we apply the 45 degree rotation and set the equal width and height. So far so good. We have a diamond on a container; if we give it a background, we see:

Now we'll give the popup itself just a little bit of styling:

https://gist.github.com/1089727/88342e10db731132e595ca13a5744233e9379d4c

And then we position the arrow absolutely within the containing div and match the background color:

https://gist.github.com/1089727/f17fd009aa3e018cbec630e369df6db49dbe1b1c

The result looks like this:


Two Sides

Let's remember that we wanted to do both left and right arrows, however. We can move the specific positioning stuff to its own class, and add a version for right arrows:

https://gist.github.com/1089727/1e16a91618451883f05b60bd50ee97daf4bb0b63

If we add a version of the div in the markup with the right-arrow class instead of the left-arrow class, we get:

Brilliant!

Fill That Up With Rounded Shadowy Sexiness

Last but not least, we want to add some rounded borders and drop shadows. We'll continue with the CSS3 trend here and use border-radius and box-shadow to provide these. First off, for the main dialog:

https://gist.github.com/1089727/046199815ad28c034a7ee6cbf0901aa4911820b6

That's Real Close Now (tm), but not quite there. If we look at what that produces:

We can see here that the arrows are ugly because they're missing a drop shadow. But now that the arrows are themselves elements, we can make use of box-shadow to give them shadows, too! This was in fact one of the main motivators for making these arrows via CSS and divs: images with drop shadows don't blend well with box-shadowed divs, unless you're very careful about creating the blend area between the box-shadowed div and the arrow image. Instead, we take this approach. Adding the box-shadows to the arrows (note that they are subtly different for the right vs left arrows):

https://gist.github.com/1089727/69e1d8309f8246df007604186a2220c2a64b2eff

Finally, we have this look:

That looks super-sexy.

They Will Not Stop Degrading Us

Sexy though the above is, we do have to think about Lesser Browsers (tm). To this end, at OpenStudy, we degraded our approach to use arrow images without a drop shadow and non-rounded boxes with no drop shadow, as well. We use modernizr, so we vary the CSS styles based on whether CSS transforms are available. If CSS transforms are not available, tough, you get no drop shadows:

The non-drop-shadowed version looks like this now:

Note that the border radius declarations are there whether or not CSS transforms are enabled. On a browser that doesn't support them (*cough* IE7 *cough*), the borders will be sharp, but the arrow will remain. The two arrow images (which could be sprited, but aren't)? Here they are:

Check Dat

That's it. Obviously many of the styles in the popup show in the initial screenshot are missing. The close button is unstyled, the text is generally untreated, and there's no proper close X. But the styles presented here are focused on how we can get a drop-shadowed arrow that varies its side by class name and is built without images. When degrading gracefully to other browsers, we leave the drop shadow at the door and use images for the arrows.

One missing component here is that we arguably shouldn't be using left-arrow and right-arrow are classes. It's my general philosophy that classes should be semantic, indicating what something is rather than what it looks like. In this case, we could use SASS or Stylus or Less or some such package with an appropriate mixin to use some other class or id to apply the proper styles to the arrows. But, I will leave it at that for now. Sexy arrows, maximum CSS goodness. It's all you could ask for.

Flowdock for Design, Bugs, and General Happiness

Our team at OpenStudy has been using Flowdock for some time. It's become our chief collaboration tool for development and design, and one of our main ways to communicate news. We're a small team -- 1 full-time developer, 2 development interns, 1 QA intern, 1 full-time designer, 1 CEO and 1 marketing manager. We keep Flowdock oriented towards development and forward motion; information about market analysis, business development, and competition generally is kept on Yammer.

Flowdock gives us one place with everything we need, and has been a huge boon to team communications. First and foremost, we use it for team chat. But in this case, Flowdock doesn't really offer much over an IRC room and a decent client, or something of that general sort. There are some small niceties, but nothing significant. Flowdock's real power comes from the features it adds on top of chat. Indeed, the one feature that gives us the largest benefit after chat is the ability to send emails directly into our dock.

Before I get into the multi-faceted use we make of emails, I'll mention how we use chat. OpenStudy has an office, and all the full-time employees are there during the day. Chat is useful in two broad cases: when the development interns are able to do some work, but aren't at the office, and when we're trying to get someone's attention in the office. Like many people, we like to work with headphones on sometimes to concentrate on what we're doing (though not always -- most days at least some of us are spinning up some tracks in the OpenStudy turntable room at http://turntable.fm/openstudy_trax). Flowdock lets us mention someone's name to ping them (audibly and by a desktop notification) and let them know we need to ask them something. We don't always respond immediately; indeed, that's not the point. The point is that we have an easy way to let someone know we need them without necessarily interrupting their flow. Chat also comes in useful when we're staying home sick, for obvious reasons, or when an emergency comes up at an off hour and we need to coordinate.

Email, email, email

Email makes our Flowdock go 'round. We use email for two key flows:
  • Design feedback/assets
  • Bug tracking
 
Sometimes, design gets completed at off times when we aren't in the office -- weekends, evenings, etc. To give us a head start, our designer,Siddharth, emails the designs into Flowdock so we can get a look and start thinking about/commenting on them. Other times, he needs feedback on different variations, and sends them to the dock so we can all look on our computers at our leisure.

Sometimes feedback on variations happens on the dock, sometimes in person in the office.

The more important use is for assets/final designs. These get put on the dock, tagged #design, and we can access them whenever and wherever we are. In particular, this means Siddharth can finish his designs at will, and whatever developer is tasked with implementing them grabs the one they need and builds. If we need anything else -- for example, if the developer doesn't have time to extract assets from the PSD -- we can ping him either inline or in the general chat and ask him for it, and he sends that onto the dock in turn. We haven't been missing assets since we've started using flowdock.

Part 2 is bug tracking. Yes, I saved the most interesting part for last ;) We've tried lighthouse, we've tried github issues, and they all feel just plain too heavy-weight. Flowdock offered us an opportunity to lighten the workflow up when we signed up for it back in February; we did, and our flow has been essentially painless ever since. It's the perfect fit for us.

To file a bug, we email the dock with tag #bug (we also add other tags, such as the browsers where the bug happens, depending on the situation). The email for us ends up being main+bug@openstudy... If we have any questions, we can comment on the Influx entry and ask any clarifying questions.

The next step for us is `verification' -- when a dev commits a fix and pushes it, it's time for our QA intern, Min-hee, to double-check that the bug is fixed (beyond our own checks). At this point, we tag the bug email #verification. Usually, we also comment on the bug so Min-hee has an easy link from the main group chat to the bug.

The comment added to the email puts an entry in the right-side chat pane. This is particularly useful for older bugs.

Last but not least comes the check itself. If Min-hee finds that the bug isn't fixed yet, he removes the #verification tag and comments on the bug to let us know, including any additional details if needed. We repeat this process until the bug is actually fixed; at this point, Min-hee removes the #verification and #bug tags, and adds a #resolved tag. As a side note, we've never actually searched for resolved bugs ;) I have the #bug and #design tags favorited on my Influx, since I use them so often.

The one disadvantage to this flow is that we can't associate a git push with a bug, nor can we mark a bug `verification' with a git push. Realistically, we've found the inability to mark bugs with a push to be a minimal problem. Our flow is interrupted already to do the git push itself, and, as we've just fixed a bug (or three), we are at a natural stopping point. Since we usually have the bug open in Flowdock already, we can just pop over, add the tag, and then get back to what we're doing; my average time to complete that action is 3 seconds or so. And ultimately, though it makes me feel good and cool in lighthouse, I haven't missed the lack of association between commits and bugs with Flowdock at all.

Missing Features

Two things are the only ones that are really missing in Flowdock that make things slightly harder for us. First up, the fact that we can't search for things tagged #bug that aren't tagged #verification. This can be a minor annoyance when we're on a bug whomping spree and have to find where the next un-fixed bug lies. Fortunately, #verification is usually the last applied tag, and Flowdock lists all tags in search result pages. As such, we can still reasonably skim and see where #verification tags are missing.

If we scan the right side of the search results, we can see if there is a #verification tag.

The second issue is that we don't have a clear count of how many bugs we have. If one of the top 8 or so tags is #bug, then there is an entry on the search page that, when hovered, will show the number of bugs; however, it would be nice if saved searches had a visible counter indicating how many items match that search. On the flip side, that would be useless for the design tag, so I'm not complaining too much.

General Happiness

All in all, the two issues above are minor nitpicks. The second feature may not even be a good idea beyond for the specific use case of bug tracking in Flowdock. The net conclusion is: Flowdock rocks, and we absolutely love our team workflow using it. Whether it'll work for you is a different question, but if it sounds appealing, you should give it a shot.

Backwards-word, forwards-word, and kill-word in iTerm 2

I recently switched to iTerm 2, and my biggest pain point was getting back the proper behavior of Option-Left, Option-Right, and Option-Delete: move back a word, move forward a word, and delete a word. These three are standard shortcuts in every Mac app, and not having it in iTerm 2 is painful.

So, a quick description. Option-Left and Option-Right are easy -- the most common way to achieve these is by sending the control sequence <Esc>-b and <Esc>-f, or \[b and \[f. In iTerm 2, you can do that by just pulling up the session configuration (in the preferences or via Cmd-I, going to the Keyboard tab, hitting the + sign at the bottom (of the right pane), and hitting Option-Right in the keyboard shortcut box. Then select `Send escape sequence' from the action box and type f in the box below it:

You can then do the same for Option-Left and b.

Option-Del is slightly more complicated. Deleting a word is done by sending \[^h, which is the equivalent of <Esc>-<Ctrl+H>. However, you can't insert Ctrl-H directly in the dialog above. Thanks to this fine blog post on word shortcuts in iTerm, we find out that Ctrl-H is the equivalent of the character code 0x7f, which we can insert in a few ways. I'll describe the easiest for me, the other two are in the linked blog post.

First, show the character viewer from the input method menu:

Then, select the code tables entry from the `view' box:

Finally, scroll the bottom pane down to the 0070 row  and select the very last column, under F:

Then make sure the box for the character where you put the f and the b for Option-Left and -Right is selected, and click the insert button in the bottom right of the character viewer. Nothing will appear to show up in the text box, but it is there! HIt OK, and you're done!