HN user

yeahbutbut

70 karma
Posts0
Comments42
View on HN
No posts found.

That should probably be based on access patterns, not on mutability flags. If it's "archived", but has 1K downloads a day it should be in cache.

If you attempt to read the script in your browser first, and everything's great, then go pipe to bash, the server can send alternate content based on your user agent.

curl | less

Or copy the request "as curl" from the network tab of any modern browser.

That strikes me as being less about controlling the message and more about making sure that the people entering the library know how to handle manuscripts that old (especially the part about not allowing undergraduates...). Digitizing the works opens them up to everyone anyway so it's not as though they're withholding anything for reasons other than lack of the resources to digitize the entire collection (hey, contribute!).

If they wanted to hide something it wouldn't be in a library anyway, it would have been burned or stashed in a private vault somewhere.

That quote seems more like standard preservation concerns, and exactly what I would say if I had a museum of 400+ year old paper documents that I didn't want destroyed by people without adequate respect for their history.

f.ex. where did the fixed width files come from?

Encrypted and signed files sent over the wire from a company we do business with. Additionally I was just pairing the values up with local names that I chose (the fixed width file had no column names itself, they sent us a word doc (ugh)). And the function that called extract had exactly one local, the array I built representing a row from the file (unused after the initial call to extract).

Extract also lets you prefix the extracted vars, avoid overwriting name collisions, etc. http://php.net/extract

The code from this article is unsafe because it directly operates on user input, was not explicit about what values were required (you can filter an array by key easily enough...) and doesn't isolate the environment it's extracting in. That's the unsafe behavior.

You're right, let is a macro so you can't pass binding forms from a variable, my mistake. But surely Scheme has some function for binding variables to the local scope...

My point is that trusting user input is the error, not having the ability to play with the scope.

"Let's make a function that has the side effect of introducing variables into scope. That's a great idea."

And ``let'' is? ;-)

Doing a (let [request] (check-auth ...)) would be equally dumb. Let's not blame the tools.

I've found exactly two:

Ghetto templating (using a PHP file as a template). Extract an object from the database into local vars to echo in the "template".

Parsing fixed width files, zip the columns with their names, then extract in the processing function.

In both cases you know exactly which vars are being replaced. The real WTF is extract on $_{REQUEST,GET,POST,SERVER,...}.

For two options, almost certainly not ;-)

For N ports, or for a port list defined from a config file however it could be. It's even nicer in python:

    ports = [80, 443, ...]
    if port in ports and http:
        ...
Or with underscore:
    var ports = [80, 443, ...];
    if(_(ports).contains(port) && http) {
        ...
    }
Good collections make it better than manually checking the return code or checking an explicit set of port values. Also configuration > magic_nums.

I agree with the sentiment that the framework "disease" has gotten a little out of hand (it seems like we have a new one every few weeks now...). However, these same people would come up with a dozen ways of routing URLs to handler functions if they weren't given some sort of standard solution to use.

Basically, frameworks are a way to work on a team without everyone reinventing solutions to problems that are almost beneath notice when trying to get dynamic content on the web.

The reason we don't have single CGI scripts for each url, and instead route everything through a single bootup script is to centralize things like session management, database initialization, memcache, configuration... etc. Things that you could do on every page, but that would be too cumbersome, repetitive, and generally don't change often.

When working with django, or zend, or cake, or whatever the framework of the day is I've often just wanted to go back to the simplicity of plain WSGI. But then I see the mess that people still make when everything is done for them and realize that would just create a new hell.

It takes discipline to program at a lower level, and understanding. Both of those qualities are in short supply.

Allow me this one; are your belongings really yours if you forget to lock the door?

Practically, it depends on where you live. In major urban areas: no they're gone and they probably aren't coming back. Insurance might replace some of them.

In the sticks? Most people don't lock their doors, even if they shut them.

I know bringing things from the real world into the digital realm often results in badly overstretched metaphors.

Except this metaphor is already stretched beyond breaking. An index isn't even a copy.

Copying a set of publicly available read-only files is not theft (you still have your copy I haven't deprived you of it).

But we're not even talking about copying your files, just the names you've assigned to them. And in his proposed form, even allowing you to remove the names from our index.

Pretty kind treatment for a copy that you've given me when I asked for it.

Creating an index of these files seems more like driving down the street taking pictures of all the houses with their front doors left open. Something Google seems to get away with on a regular basis.

I'm pretty sure that by HTTP client he meant rendering engines. And in this analogy the data integrity is "whatever crap I have to send to the client to get the expected output on all client machines". So it's somewhat fair to say that if you have wildly divergent interpretations of HTML rendering then you have a data integrity problem, since you can't guarantee that the same data will be interpreted the same way by all clients. None of that has to do with HTTP the protocol though... so I'm confused as to why HTTP the protocol was mentioned instead of HTML and rendering engines.

There is some value in being able to read non-expert code, you're more likely to run into non-expert code during your day to day job. Someone like Abelson, or Armstrong, will write clearer almost effortless code. Someone at work may spend a thousand lines trying to munge an associative array out of a database result. You have to be able to read both.