pwk

Sideways reply due to stack depth, sorry...

What's the practical difference between a government saying "You must sell your product for this price or we won't allow you to do business in this industry" and Wal-Mart saying the same thing?

You're right that there might not be much of a practical difference for the company making the socket sets, but they aren't the only factor in the equation. Your question addresses only the seller, and markets are made of both sellers and buyers.

If the government sets price limits, that means the company can't do business even if there's a willing buyer. You're removing the right of free choice.

When it's Wallmart setting a price that they're willing to pay, and it's lower than the price the company is able to sell for, that just means there isn't a willing buyer. Wallmart is in some sense acting as a proxy for the people who shop there, who are clearly saying that price is what's important to them.

To paint an exaggerated picture: if I'm trying to sell my socket sets for $1000 each, and no-one wants to buy them, that doesn't mean the market isn't free, it just means that there isn't a match in the buyer side of the market for my product.

How is that a free market?

A free market doesn't guarantee that you get to stay in business.

what good is a socket set for 15¢ less than the competition when the socket set company that used to pay you $35,000 a year moves to Indonesia and now pays you $0?

Over the long term and looking at the bigger picture, we'll hopefully wind up with a good number of people in Indonesia who are better off.

I agree, this is compelling for a lot of the same reasons as the anagrams problem. I spent weeks playing with anagram code at one point, and like you I felt an immediate compulsion to start writing code for Sling Blade Runner. So far my (ruby) code just does the obvious: builds the graph connecting up the movies and then uses brute force to find all chains of length two, then three, etc. Bogs down at chain length of about 11. Added some quick and dirty optimizations and pruning heuristics, and I'm geting chains in the mid-hundreds. I think this approach can be extended further, but isn't particularly clever :-/.

It's a fun project! I built one several years ago, after playing around with a bunch of different approaches. I wound up with a human-guided tool that seems to work pretty well for coming up with interesting ones:

http://anagramlogic.com/

If I had known about this 14 years ago I would have certainly tried it, I tried many things... the ones that I think were helpful for me are:

Ice bathes for my arms: I filled a sink with water and ice and submerged my arms up to the elbows; this was obviously useful for short term pain relief, and might have helped reduce inflammation over the longer term. It was important to wait until the arms were warmed up again before going back to typing.

Keeping fingernails well trimmed; surprising, but it made a big difference.

Massage; I think it was through massage that I started realizing that even though my symptoms were in the wrists the problem was probably more systemic, it's amazing how much pain a good massage can discover in surprising places!

Stretching; stretching the wrists felt immediately good, as did standing in a doorway, arms on the door frame, and leaning forward. Working on the hamstrings probably helped longer term.

Weight lifting, particularly exercises that strengthened the back; lots of people have mentioned it here, and I credit this for being the biggest long term help.

The "cylinder with accordion-like folds" looks like the business end of the toilet plunger I recently bought, so it's already mass produced and easy to source cheaply.

Photography is different from other fields in that the typical unit of work is quite small: one photo. That means amateurs can overwhelm the professionals by shear volume. There are so many more of them, and they take so many photos; so what if 99.9% of them are awful, as long as there's a good filter to find the gems.

This of course doesn't work if you absolutely must have photos of some particular event, so there will always be room for professionals even if they're squeezed.

I was amused to find this bit of awkwardly worded text in the article:

"...the Higgs boson, a hypothetical particle that scientists theorize gives mass to other particles and thus to other objects and creatures in the universe."

The Gold Bug Variations, by Richard Powers: a love story that touches on music, genetics, history, art... lots of themes that HN readers might appreciate.

Notational Velocity is great.

Quite some time ago I wrote a little web-based note taking app, trying to make it as much like NV as I could -- I really liked NV, but wanted to be able to access my notes from multiple locations. I still use it myself all the time, though I never really polished it or shared it widely.

http://pi-guy.net/webnotes/

You also don't need to ask for the card type (Visa, MasterCard, etc); it can be automatically determined based on the number.

Well, scale can mean "spend time and money building infrastructure that supports lots of traffic" -- doing this before getting the traffic is premature optimization.

But, scale can also mean "get lots of traffic" -- this is growth, not optimization; in this case, trying to optimize revenue before the growth happens could be considered premature optimization.

Maybe not, perhaps he also tweets 'In closet, with gun' when he's in the closet, with a gun?

The Aeropress is pretty good. It's cheap, easy to use, and surprisingly easy to clean. I used to use it to make mochas and faux-cappuccinos (pseudo-espresso from the Aeropress plus milk frothified using a whirly-agitator thing instead of steam) but these days I just make Americano-style coffee, which I like because it comes out rich and smooth. I'm not really a coffee snob, though, so YMMV.

One of the comments reads

Historically I’ve approached big projects with the nonstrategy of “let them overwhelm you in your head, then put them off till moment when the fear of not finishing exceeds the fear of starting.”

This is well put, and exactly how I handled all of college. It worked OK there because project size was generally reasonably bounded.

The "fear of starting" is pretty insidious. A project often looks hugely different on either side of "started working" line -- it can be a really quick change from "I'm not really sure how this is going to work" to "I'm in a groove, this is going great!"

The concept of a "risk thermostat" is interesting -- people seem inclined to maintain a more or less constant level of risk. I've noticed an effect that interacts with that: my risk inclination seems to have some initial static friction that changes to a lower level of kinetic friction once I'm moving. Example: some years ago I was feeling a little hesitant to try snowboarding because it seemed "risky" (I knew I'd fall a lot). The first time I tried it, I was having so much fun that I pushed myself well into exhaustion and took some crazy tumbles that didn't stop me from getting up and riding more. I suppose my initial response might just have been an underestimation of the "reward" part, rather than an incorrect estimation of the "risk" part.

As a user of ruby/rails, this whole issue is crazy. Don't waste your time paying attention to it.

Interesting, thanks for the pointer.

The language (interpreter ? VM? ) leaks memory?

AFAIK the interpreter has no intrinsic leaks, but many ruby applications keep objects referenced beyond their intended life, preventing GC.

Edit: You extended your edit after I started responding :->

perhaps by holding onto objects and not letting the GC collect them

Yup, that's my understanding.

The game he's writing about produced average revenue of around $4500 a month for it's first two years, and is currently making around $1000 a month. That's not enough data to plot a curve, but his long term revenue for a game seems quite respectable, particularly when considering he has a stable of 12+ games that are probably all still earning some amount.

From the article:

Aside: should the guys who drive an armored car that carries millions of dollars in bonds get paid more than the guys that drive an armored car that only carries thousands of dollars in cash? Does the amount of money handled change the difficult of the work?

The amount of money handled does change the cost of failure. It also changes the amount of risk the drivers face.

I don't agree with much in this article. My thoughts on Marcus' list of "dumb ideas":

1. Default Permit - this one makes sense, getting "fail open" vs "fail closed" right is important in lots of places in engineering.

2. Enumerating Badness - isn't this is just the typical method for implementing default permit?

3. Penetrate and Patch - yes, it's always better to design a system to be secure and to code it with good security practices in mind, but any system with more than a handful of lines of code will be too complicated to guarantee correctness. "Penetrate and patch" can still find errors in well built systems. I do think that different ways of doing the "penetrate" part have different value. For example, I much prefer "white box testing" (ie testing with access to source code) to "black box testing". Extending this concept, when writing code with security in mind it can be helpful to consider common approaches an attacker might take (ie simulate the "penetrate" part of the process mentally), and use that insight to write better code (ie "patch" the code as it's being written).

4. Hacking is cool - well, the truth is, finding flaws can be intellectually gratifying. Sure, maybe the "coolness" factor has an impact on how many script kiddies exist, but there will always be people who like to "hack" stuff. Some portion of those people will stray into gray and black areas.

5. Educating Users - sure it's hopeless, and designing systems and processes to minimize people's impact is a win, but the prediction that users who need education will not be in the high tech workforce in ten years... not gonna happen.

6. Action is Better Than Inaction - From the article: I know one senior IT executive - one of the "pause and thinkers" whose plan for doing a wireless roll-out for their corporate network was "wait 2 years and hire a guy who did a successful wireless deployment for a company larger than us." Not only will the technology be more sorted-out by then, it'll be much, much cheaper. What an utterly brilliant strategy! Ugh! How about looking at risk vs reward. How much did that conservative "pause and thinker" put his company behind by waiting two years to adopt some new technology? Yes, sometimes that's the right choice, but sometimes high rewards merit taking big risks! This is as true when thinking about security as it is in any other business decision. A blanket recommendation to avoid risk does not cover all situations.

Think of it this way: the game cost his company 120K to build, and his company has pretty much made that back, so his company has broken even(1). While developing the game he paid himself a decent salary, so he personally has done well (and that's the part that actually matters).

(1) Leaving out the time value of money, etc

Eh. There are different levels of monkeypatching. I have no problem with extending even a fundamental class with a new method if it's done with care, despite the potential downsides. I think the upside of monkeypatching can outweigh the downside when it facilitates tight, readable code (not that I'd consider the code in this post an example of that). The real problems show up when changing the behavior of existing methods, and that's where I think the downsides often outweigh the upsides.

...is Phusion essentially just a slightly better FastCGI?

Well, it depends on whether you're looking at it from an academic or practical standpoint. AFAIK the technologies are not entirely dissimilar, as you suggest, but there are notable differences once you actually put them into use. I've used both for running rails apps, and a few things stand out for me:

1. Passenger is much easier to set up: it took me about 5 minutes to get my first Passenger based rails app up and running. The last time I set up a rails app w/FastCGI (admittedly a few years ago now) it took me much longer. This comes down to simpler configuration combined with better documentation. Subsequent application deployment is also easier (no manual server restarts required). This is worth a lot in practical terms, even if not flashy.

2. Passenger seems more stable. I never had quite the problems with FastCGI that others appear to have had, and I've only been using Passenger for a few weeks now, but there's a reason people used FastCGI less often once Mongrel became available.

3. Oh, and there's some neat stuff too: automatic spawning and pruning of application instances in response to demand, etc.

Depends on the app platform. In the rails world Phusion Passenger (aka mod_rails or mod_rack) in combination with Apache is making inroads for serving up dynamic content. Despite the bigger footprint and other downsides of Apache, I'm hearing more and more that stability and ease of configuration of Passenger are a win. I'm only running it on a low usage backend app for the moment, but it was definitely easy to set up.

I do learn somewhat from reading stuff online, but it's often because I'm inspired to play around with something on my own. Like a lot of people, I learn the most by doing. So I think the point that a lot of people are making is a good one: write more code.

There are some concepts from practicing music that might be interesting to consider in the context of coding:

1. Play music that's beyond your current abilities; playing the things you already know won't help you improve. This is pretty easy to put in the context of writing software: don't write yet another little ruby app, write it in Haskell or Io or Clojure or Erlang...

2. Isolate weaknesses and focus on specific things to improve. I think this is tougher in software than in music, because a good musician is always listening to good music to benchmark against, but it's probably not as common for developers to constantly be reading good code. So, maybe go find some good code to read and find ways in which it's better than what you're churning out.

3. Don't practice music with mistakes; it's better to slow down and get it right than to learn it incorrectly. So maybe a test suite for that weekend hack isn't a bad idea...

I should do more of that... in both music and coding...

It can be hard enough to make empirical observations about one's own performance even when not under the influence of a mind-altering drug.

I did once spend an afternoon making recordings of myself playing guitar at different levels of sobriety. Results pretty much as expected :->.

My second job in Boston was at OpenMarket, a now long-dead internet bubble 1.0 startup that was founded by DEC CRL alumni. I enjoyed my time there, but your term "unwieldy" might be a good explanation for why it didn't survive. The company enjoyed some initial success, but did seem to have trouble changing direction, which made survival difficult once the 1.0 hype was fading.

我的汉语不太好, I needed to look up 厉害: http://www.nciku.com/search/zh/detail/%E5%8E%89%E5%AE%B3/130...

Pretty neat site, along with looking up characters by typing or cutting and pasting you can draw them and it tries to guess what character you're looking for.

What prompted you to start with 厉害?