pwk
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.
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.
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.
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.
"...the Higgs boson, a hypothetical particle that scientists theorize gives mass to other particles and thus to other objects and creatures in the universe."
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.
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.
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!"
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.
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.
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.
(1) Leaving out the time value of money, etc
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.
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...
I did once spend an afternoon making recordings of myself playing guitar at different levels of sobriety. Results pretty much as expected :->.
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 厉害?