modification aggregator for recipe sites

We have a bag of shrimp to cook through, so I’m looking up shrimp curries, here among other places. Now, commenters on recipe sites are famous or infamous for commenting about their modified versions of the recipe, and this recipe is no exception, but something crossed my mind that never had before:

“My husband said it didn’t taste like something he would eat at an Indian restaurant as all the Indian food he’s had is pretty spicy and this was not. We ended up adding some curry and cayenne pepper.”

“I did, however, find it necessary to increase the spice amounts and added 1 tsp… I found the sauce to be a bit thin so I thickened it up by using a cornstarch slurry.”

“Very runny, though. Next time I’ll simmer longer and add some flour.”

shrimp

It is, of course, not shocking that commenters might agree that a recipe needs modification in certain ways and also agree on how to do it. But wouldn’t it be nice to flag popular modifications that reliably improve the recipe?

The obvious difficulty here is how to dredge the comments for modifications automatically. I think the non-obvious difficulty is interpreting the star ratings, so you can figure out what modifications are really useful. If someone says “I had to thicken the sauce” and rates the recipe four stars, are they rating the modified version or the original? Presumably it varies. The best option might be to have a “needs” button, where you could pick from a drop-down menu or insert your own text; it would be easy to aggregate those results. But even if every recipe site in existence implemented such a thing tomorrow, there’d presumably still be some value in figuring out how to extract useful summary information from already extant reviews.

(This all said, I think I’m going to go with the Alton Brown-endorsed shrimp tikka masala from Martha Stewart Living.)

email to kindle

Here’s what I want: A Gmail plugin that will grab a long email, convert it to epub or mobi, and send it to my Kindle account so I can read it on any device I want. This may represent a lot of effort for relatively incremental value, as my phone has both a Kindle app and Gmail on it; nonetheless, it is my desire.

That is all.

the azure eye of sauron

Also, I just wanted to say for posterity that it freaks me out that Facebook has gotten far enough into my phone’s hardware that, when I’ve got a new notification, the phone LED blinks blue.

It never blinked blue before — just green for full battery, yellow for low, red for dying. But Mark Zuckerberg wiggled in there and Did Something. He’s probably filming me right now. (Or, rather, he’s probably filming the inside of the phone pocket in my bag.)

The blue LED happened at the same time as push notifications, which were also signified by a double vibration. And at least some Facebook notifications can’t be individually cleared from the notification bar — they only disappear if you go look at them or clear everything, which sometimes isn’t practical (e.g. if there are updates I need to download but don’t want to immediately).

What’s awful is how effective the whole thing is. The blue LED and the double vibrate definitely tap into the dopamine system. I normally never use the Facebook phone app, because of how idiotically slow it is, but now that my phone only seems to speak Facebook, I have used it a lot more. Why read an ebook for five minutes when I can check some dumb-ass fake obligation off my list?

Anyway, I finally bothered to look up how to turn phone notifications off, which is embarrassingly easy. But I am a little bit shaken by how the whole thing works.

kindle dx screen savers

In the grand tradition of making minimal modifications to other people’s hard work and then taking all the credit, I have transmogrified Sean Hartter’s Dark Tower movie posters and M. S. Corley’s retro Harry Potter covers into black-and-white screen savers for the Kindle DX, which you can grab below. I realize that most Kindle owners don’t have DXs, but I also realize that most Kindle owners don’t read this blog; if enough people request them in a standard Kindle size, I’ll do them. (If I have time. I do have a baby on the way.)

If you don’t know how to jailbreak your Kindle, you can learn here (and download 66 Wonder Woman screen savers, if that’s your bag). If you want your screen savers to show up in random order, though, make sure you follow the directions for randomization in the comments — the original post is wrong. For the links to the original images, I’m indebted to John Struan of Super Punch.

converting latex to ebook

OK, I think I’ve finally figured out the best way to turn a LaTeX book into an ebook: Use TeX4ht (SimpleTeX4ht will work if you’re on a Mac) to convert the book to HTML, and then use Calibre to convert the HTML files to epub or mobi or what have you.

The trick, which I had incredible trouble digging up on forums, is getting Calibre to deal with footnotes. If you just give it the base HTML file, it’ll hang forever. You’ve got to give it a ZIP of all the HTML files (since TeX4ht creates each footnote as a separate HTML page crosslinked to the body of the text). Better put the CSS file in too if you want all your precious bolding and italicking to come through.

Drawbacks: TeX4ht doesn’t seem to handle images properly (which is to say “at all”), and it likes to put large text (unless it’s specifically designated a chapter heading) into monospace font. I haven’t figured out why either of these things is, but they seem like the kind of thing one could write a Python script to deal with. Which I will probably do at some point. But not tonight.

I also feel I should say that Pandoc, despite claims for versatility that would make the Swiss army green, takes an incredibly long time to install from MacPorts and appears entirely inert. It’s supposed to be able to handle LaTeX, HTML, and epub, but was good for neither the LaTeX-HTML nor the HTML-epub step of this process. But if anyone wants to give me a Pandoc one-liner that’s as good as the LaTeX-TeX4ht-Calibre scheme described above, I’d be happy to try it.

resolutions to a couple of psychopy issues

After several hours failing to get PEBL working, I’ve been coding up some scripts for a computerized testing battery in PsychoPy. I really like it overall; it covers PyEPL‘s major deficiency of not being able to create arbitrary stimuli online, and the learning curve is much gentler, at least for someone who doesn’t know much Python in the first place. It doesn’t enforce certain good habits that PyEPL does (e.g. segregating config files, obsessively logging everything), and I can’t figure out how to change the awful font choices in the editor or (just as good) get it to run from plain Python rather than within the PsychoPy app — but overall I’m well pleased.

I’ve run into two real problems in the last week or so of semi-intensive PsychoPy programming that I wanted to share with the Internet (and, possibly, my future self). Neither is a problem in the sense of “PsychoPy fails at x”; they’re problems in the sense of “This is an approach that might seem reasonable, but it won’t work.”

  1. Vertices of ShapeStim shapes. This is actually documented, but I didn’t notice it for a while, so here it is again: Vertices are offsets from the pos argument to the ShapeStim object. If you give the damn thing vertices with absolute screen positions, the resulting shape will be shaped right, but the size will be all messed up. You actually might only notice this if you need to put ShapeStims and RadialStims or PatchStims on the same screen — but you’ll notice then, mark my words.

    Related: I’ve confirmed the documentation’s admission that filling breaks for shapes that have concavities. Creating those shapes out of their convex components, however, works just fine. Also, it looks like giving a filled shape a depth argument of anything other than the default causes the lines, but not the fill, to take that depth — as far as I can tell, the fill just disappears in these situations.

  2. The proper way to wait for keypresses. Coming from a very old version of Psychtoolbox, or perhaps just from the Land of Bizarre Programming Practices, I’m accustomed to waiting a certain amount of time t (but no longer) for a keypress by doing something like this:

    while trialTime < t:
    .... update trialTime
    .... check for keypresses
    .... if there are any, record RTs, process them, and break

    If you do this in PsychoPy, the natural idiom to use for the “check for keypresses” step is event.GetKeys. This approach will miss a lot of keypresses. It’s not a subtle issue, luckily; your program will just fail to respond to something like four out of five keypresses. However, there’s actually no need to use this structure. event.WaitKeys has a maxWait argument that serves just as well to enforce the time limit (something it took me a while to realize), and you can record RT just by resetting a clock before the WaitKeys call and recording time from that clock after it. I don’t understand why the for loop over GetKeys has this issue, but I haven’t detected any drawbacks to just using WaitKeys instead.

google: pwned

I may have zero readers and zero comments (plus or minus epsilon), but Googling my pedestrian-ass name now yields this blog on the first page of results. I’m going to roll with the idea that that’s a good thing, for now.