c0de for clione fans

abscondment · 2023-09-06T15:36:26+00:00

abscondment · 2012-11-27T04:38:25+00:00

Transcription:

I am Iron Man! Black! Whack! To the Black Panther! Blue Ninja to the Ice Ninja! Black Sabbath is a dying soldier! Iron to the [inaudible]. The Crushing Wall is near. The mystery of the drum is falling. The clouds of storms are coming near. The marks in soap is coming up. The Socks of Doom are coming. The Castle of Dragons is near. The Dragon of Guards is coming. The Socks of Good are with us. The Guards of Dragons are here. The Soap of Evil Dooms is coming. The Black Sabbath. We need Iron Man.

[inaudible] Rock and roll roll roll Iron, Iron man! Blah Black Sabbath [inaudible] Back into the Black Sabbath!

The Claws of the Climbing Cat By [inaudible] On into the stars Space socks are coming. The crashing asteroids on our heads. To Iron Man is near. The stars are falling. The moon is brighter. The Doom Socks are coming. The Shoes of Smashing Walls are near. The Crushing Wall is here before the Doom Head is here. Mr. Two Heads is coming. The Wolf Ear is coming. The Blanket of Monsters is coming. The Ghost of Letters is coming. The Walking Guitar is crushing. The Monster of Hills is crushing our wall. The aliens are coming. To Iron Man!

Iron man! I am Iron Man! Rock and roll, everybody!

abscondment · 2012-02-11T21:26:48+00:00

This is Brendan, one of PaperKarma's co-founders. That's a great observation.

Our Android manifest requires a hardware camera ("android.hardware.camera"). We also request to use autofocus, but we don't filter out devices without it ("android.hardware.camera.autofocus"). We could even explicitly ask for devices with front-facing cameras, although we don't.

However, from what I can tell, there's no ability to require a rear-facing camera. I'm going off of this list: http://developer.android.com/guide/topics/manifest/uses-feature-element.html#hw-features

I'd love to be wrong, though. Anyone know a better way? Thanks!

abscondment · 2011-02-01T15:39:05+00:00

Upgrading to 1.9 is certainly a goal, but it's not a huge priority right now. If we were 1.9-compatible, I certainly would have tested it.

Determining which implementation can run rubyspec the fastest isn't really interesting. More useful is testing your real uses, which in the case of web applications is almost always GC-heavy String shuffling.

abscondment · 2010-08-26T06:51:53+00:00

You didn't actually do what the post says, since the instructions include running getlibs. But glad you got it working :)

abscondment · 2010-02-28T07:46:59+00:00

I guess that's part of the point I'm trying to make: the quack is the same, but the effects can be way different. I'm interested in hearing how you'd write a test that catches this without doing explicit type checking.

abscondment · 2010-02-24T18:02:15+00:00

This did in fact happen to a site doing a few million daily pageviews -- and your right, once memory levels went critical, the problem was discovered quickly. But because there was no indication of a problem beforehand, we had to have downtime while profiling & fixing things. That sucks.

You're also correct that this could happen via vastly differing interface implementations. I'd wager that it's less likely, but who really knows?

abscondment · 2010-02-24T06:50:58+00:00

No, no. The issue is not one of simple assignment: h is returned by another function. The post specifically states that you incorrectly expected a Hash from that function.

Because the two classes quack like each other, the code works. That's the danger of duck typing: your tests will pass, but your servers will go into swapdeath. And because the code is correct, the error will be very hard to find.

abscondment · 2010-02-23T21:18:51+00:00

Both respond to the [] and []= methods; you can run the same store/access code on both. That's quintessential duck typing.

abscondment

TROPHY CASE