zootm

Have you seen RecordStream? It's some good cli tools based on streams of json which might be handy.

https://github.com/benbernard/RecordStream

I've used it a lot and it's a godsend for a most "record-y" manipulation.

The sibling comments point out some good points about your general critique, but it's worth noting your code isn't really "equivalent"; almost everything you chopped was a datatype declaration, which isn't required in Java any more than in Ruby:

      @GET
      public Map<String,String> greet(@PathParam("name") String name) {
        return singletonMap( "content", "Hello, " + name );
      }

I like both of these systems, and Java is undeniably the more verbose language, but this framework really isn't an egregious example of that.

Similar on Android; the widget behaves perfectly, which is ironically a poor experience on mobile.

Looks like it would be very nice on a desktop though!

It was more the cases where I was wrong, rather than right. Some feedback indicating that the form could not be submitted, and one needed to press "forfeit", would have been appreciated, if only because it is not the way web forms work.

It's a small thing (and I did like it once I realised how it worked) but when doing things in an unusual way a little bit more guidance is required at first.

Enjoyed the quiz!

That is annoying. Also irritating is the fact that the quiz seems to stop accepting answers after a couple of questions for me; in both Chrome and Firefox so far. I want so desperately to get a score!

Edit: Actually, it just turns out (after reading the source) that in some cases it just won't accept the answer if it's wrong. I did the honourable thing and selected "Forfeit", allowing me to continue :)

From the product page: http://aws.amazon.com/documentation/swf/

I don't disagree that it's difficult for those running servers who want to filter this sort of thing out, given the state of the current tools. The fact remains that it's the right way to do this sort of thing, however.

As for me, I happily do not run any public websites other than my personal ones, and in that context I don't much care about analytics, so I'm afraid that I can't show you a good way to do this in Apache. For what it's worth, thought, I think the header for prefetch is "X-Purpose: prefetch" in Safari and Chrome, and "X-Moz: prefetch" (yes, really) for Firefox.

The analysis software already needed to be modified. And if your Apache isn't already configured to try and find this sort of thing, you're also counting things like page prefetches as true views.

The header is the correct place to put information like this, regardless of whether the deficiencies of the server software.

Headers are a perfectly reasonable way to signal this, and they're sending them. Adding GET parameters changes the URL fetched even though the browser still wants the same resource -- that would be wrong.

The fact that there are servers which don't allow users to do the sort of log analysis they need to do is not the fault of Google. Headers are the correct place to put the information.

As a sibling quote mentioned, 1.9 is fast relative to 1.8. JRuby is pretty fat in general, with the potential to approach Java speed at times, although I think specific things can slow you down a lot. In particular it was the case (not sure if it still is) that exceptions in JRuby were pretty expensive, but many Ruby libraries treat them as cheap, leading to performance problems if you move from one platform to another.

I was not trying to be precise though, just give a feel for the different implementations.

"Acceptably quiet" and "acceptably private" are pretty subjective -- I found myself answering yes to both despite the fact that my work environment is fairly noisy, and not st all private. These things (especially the latter) are acceptable.

The interpreter in 1.8 and earlier is definitely pretty sluggish; I believe the 1.9 implementation was intended to be quite a lot faster, and JRuby is pretty fast. No idea about Rubinius or IronRuby or other alternative implementations.

It's definitely the case that stock Ruby 1.8 is slow for a great many applications, though. Having said that, there's alternatives, and a lot of the time efficiency of execution is not at the forefront of the objectives for systems written in Ruby.

Funnily enough, until very recently this was my response to Twilio :). Actually, now I look at it, it's still my response to Twilio re: text messages.

Of course I still need to figure out something to do with Twilio.

Well I certainly hope getting Daft Punk when searching for Radiohead isn't what it normally does...

It works as a modifier if you press another key with it, else it focuses the Start Menu.

As well as him feeling this is strong, I think he probably puts a lot of weight on the public popularity of the song he's parodying when choosing a "lead" single. I suspect marketing parodies is at least as much dictated by the popularity and timeliness of the choice of source as the actual parody itself.

It's in there now, although it only shows major version numbers (generally not unfair, although a major version of Chrome doesn't necessarily mean the same as a major version of, for example, Firefox).

Edit: Actually, I just noticed that Opera 9.1 and 9.5 are there, along with Firefox 3.5, so scratch that!

I wondered the same thing so let me save you the search:

> http://help.dottoro.com/ljlumkqh.php

The page implies that there is limitations to the IE8 implementation, and that it's only available in relatively recent browsers. In addition, I believe that sizzle implements a set of selectors larger than most or all browsers support natively, although this I am less sure of; the Sizzle documentation certainly implies it strongly:

> https://github.com/jeresig/sizzle/wiki

I don't think "nothing like jQuery" is really correct here; its API is very similar to jQuery. In fact, it behaves a lot like a very small subset of jQuery, as a neighbouring post to this one points out.

I can imagine it's handy if one wants something like the jQuery API but doesn't need support for all of the CSS selector features, or for older browsers, and wants to save a few bytes on downloads, given that it's much smaller (the uncompressed jQuery source is something like 60 times the size of this library, although in its defence that includes inline documentation).

Because 301'ing provides little or no incentive for the offenders to do the right thing. Also it doesn't stop the excess traffic, it just reduces it.

In the UK (on amazon.co.uk) the items are available but 75p each: http://www.amazon.co.uk/s/ref=nb_sb_noss?url=search-alias%3D...

Firefox 4 on Linux gives a message at the bottom saying something like "WebFonts not supported, falling back to image fonts", meaning that the scaling examples look horrible and most examples are very fuzzy. Shame, looks neat otherwise :)

That's an interesting idea. The only problem I can see is that every segment needs to be min. 5MB, so you'd probably need to buffer an extra segment compared to the "naive" implementationto ensure the last segment is big enough.

Nice, I wasn't aware of that one!

What we need is an API which lets us somehow shorten our hugeurls...

I think that http://hugeurl.com/ probably has first dibs on this joke by a couple of years.

Implicit wrappers have long been an issue for this sort of optimisation, although I was pleased to read that the new JVM escape analysis feature seems to deal with that very effectively:

http://www.decodified.com/scala/2010/08/27/scala-rich-wrappi...

As other comments have noted you can generally degrade to writing near-Java code and the results will be basically the same bytecode. I'm sure there are exceptions but if you want to, you can avoid object creation. Implicit conversions are one of those cases which will not be called out as a warning or similar, though, so something to be careful of.

You also get diverted to it if you tap "Why?" when the "Battery < 15%" notification appears, for what it's worth.

Took me ages to notice that since it's next to "Okay", and poorly-designed dialogs have me trained to assume that that's a "Cancel" button that does nothing.

Well, yes, obviously the comparison is only informative for the "reading" application of the iPad. This is also the reason that comparing the prices and some other aspects of the devices is pretty worthless. But if you're interested in the differences in screen technology this is a very neat comparison.

This is definitely the main point in this "debate"; some people will just prefer one screen type over the other. A lot of people seem to be advertising these opinions as objective fact, and that's quite a dangerous trend.

I'm personally of the opinion that e-Ink is what I'd prefer for reading, but I absolutely despise reading on screens; anything lengthy I print out. And while I think that e-Ink is better for reading, that's all that e-Ink devices (while being a lot cheaper than the iPad) do. If you read less and do other things more, then e-Ink is unlikely to even be an option for you unless you feel like shelling out for another device for the few times you do read at length.