jedschmidt

i do the same for Content Security Policy: `default-src 'none'` by default, then add what i need when i need it.

agreed. i think the economics of ramen make less sense outside of japan, where it’s more expensive and turnaround is slower because folks linger longer (often to amortize the cost of waiting to get seated in the first place).

this reminds me of a naive and happier time in tech, when i built a game called ramendan with twitter’s open API. you had to eat ramen every day for dinner, and tweet proof with the hashtag #ramendan, link to a photo (this was before twitter supported images), and geotag it so that we could make sure it was after sundown in your timezone.

https://www.pechakucha.com/presentations/the-savory-month-of...

i went super deep on 140-byte code golfing[1] back when twitter was taking off, and it changed the way i think about code. for a brief while we had a small community collaborating on byte-squeezing techniques[2], and i was constantly amazed at the creativity that this constraint brought about, from mandelbrot renderings to sudoku solvers. possibly the best part was more than a decade later when i found my golfed UUID implementation[3] deep in my employer's codebase.

[1] https://youtu.be/JsAetmgJRss?si=AxIFySX7ktzu5GL5&t=193

[2] https://github.com/jed/140bytes/wiki/Byte-saving-techniques

[3] https://gist.github.com/jed/982883

In my experience, as long as a controlled window is communicating with the SW, the connection will remain alive.

A service worker would work fine; the connection would be instantiated from the SW and each window/worker could communicate with it via navigator.serviceWorker.

Instead of adding a non-standard API to opt-out of existing networking functionality, it would be great to see a lower-level networking primitive to unlock these kinds of use cases. I wrote more (with a proof-of-concept) here: https://readable.writable.stream

If there's demand for it, would love to look into that.

Sure, as it could with any part of your app, including wherever your JSON.parse code lives.

Not _quite_ arbitrary; the only code run is that generated by lave. Arbitrary code present in functions is parsed, but not run.

My original HN submission was clearer, but alas didn't go anywhere: https://news.ycombinator.com/item?id=11185365

Absolutely. The downside of running a full-blown eval() exists in JSON too, it's just that the eval() there is taking place in the reviver function, which requires a lot more coordination than a self-contained file.

As far as efficiency, I'd think for most uses the issue would be on the JSON.parse end. In this case, lave might be more efficient, since JSON reviving often ends up creating temporary objects that need to GC'ed after reification.

My situation is for an intranet environment, so I suppose I could just ask nicely that they don't change validations. But chances are most of my target users aren't familiar enough with Google Spreadsheets to even get that far.

I really like the idea of using Google Spreadsheets as a quick and familiar GUI for entry or querying on data sets, as long as you understand the tradeoffs (write latency isn't great and they max out at 400,000 cells).

But this is especially nice when you build a layer on top of Google reduces lock-in, instead of adding another proprietary API. This is what I did with sheet-down[1], which turns a Google Spreadsheet into a LevelDB-compatible data store that can be swapped out with a file system or other compatible backend[2] once you outgrow Google.

[1] https://github.com/jed/sheet-down

[2] https://github.com/rvagg/node-levelup/wiki/Modules#storage

I wish `void` would get more love for IIFEs instead of just sitting there in a dark corner of JS, unloved.

    var foo = 'bar'
    var baz = 'bletch'
    
    void function (global) {
      //module pattern code here ...
    })(this)

Having gotten more accustomed to the VM approach over the past year since I wrote this post, I agree.

Are you sure he was saying "ore"? Given the fact that his grammar is otherwise pretty tight, I wouldn't be surprised if he were instead using "ware".

You might also want to consider whether a B Corporation would make sense: http://www.bcorporation.net

tl;dr: URLs with all periods prepended by a zero-width space evade Twitter DM malware detection, but are still recognized (and clickable) by Chrome, Firefox, Safari, and Twitter's own client.

    javascript:prompt(0,location.href.replace(/\./g,"\u200b."))._

Gaunt in 128 bytes of JavaScript:

    function(a,b){return a[b="replace"](/./g,a=function(a){return a[1]?String.fromCharCode(parseInt(a,2)):+(a==" ")})[b](/.{7}/g,a)}

I first saw this neat trick in Billy Hoffman's presentation on circumventing automated JavaScript analysis (scroll down to crazy idea #1):

http://www.blackhat.com/presentations/bh-usa-08/Hoffman/Hoff...

This is an awesome solution for folks using Backbone and who don't mind a tight framework coupling.

But if you're not on Backbone, or don't want to add another constraint to how your app is built, it's pretty easy to set up your own PhantomJS server; I presented on this very topic at TXJS this week[1], and created a library[2] that makes it a snap to set up.

[1] http://www.flickr.com/photos/tr4nslator/sets/721576332659462...

[2] https://github.com/jed/rndr.me

As a fairly regular user of Punchfork, I definitely wish it were still around, but this feels self-entitled.

Let's not forget that the data Punchfork is letting users take out is the exact information they put in: a list of liked recipes. The original recipe data is just one click away.

I'm not sure how this is any different than a personal Twitter archive; it contains only your tweets, not those of the folks you interacted with.

I (and all Punchfork users, I assume) received a notification on January 3rd, including the following:

    Initially, support for Punchfork will continue, but
    we will soon be retiring the Punchfork site, API and
    mobile apps. We believe that a unified destination
    benefits our users in the long run, and the Punchfork
    team (me) will focus on contributing to Pinterest as
    the premier platform for discovering and sharing new
    recipes and other interests on the web.

EDIT: Gmail binned this email in "Promotions"... I wonder if that explains why some didn't see it?

Does anyone know how often they update their containers for other platforms? The maximum node.js version on Beanstalk is 0.8.21, but the current stable is now 0.10.0.

this is apparently blogspam that embeds the original article from iA:

http://informationarchitects.net/blog/the-web-is-all-about-t...

You're being redirected because JavaScript is disabled. I should make this more clear.

Put your domo code into a function that takes data and returns a DOM object. BAM, there's your template.

Your JavaScript code can only have one global object, I don't see a reason to pass it in instead of finding it for you.

This is great feedback, will definitely look into this.

Thanks for the reference to crate, I'd never heard of it. I'd imagine the pushback on ideas like this is much less in homoiconic lanugages like clojure, since when all is said and done everything is an AST.

I don't know much about Mason, but this isn't a templating engine; it's just a wrapper library on top of the DOM API. Since it doesn't need any compilation or coordination outside of the JavaScript process, it's much less complex, and composes well without passing partials and other cruft into the template data.