bsaunder

Sure, that makes sense.

Don't know if it makes a top 20 though. ;) Seems like it could be a bit hard to manage beyond a local module scope.

there will be bad days. Some days just aren't meant for programming. Do something else those days or you'll cause more harm than good.

Does that ever seem like a good idea? The description suggests it may be a long list. That should give you a hint that you don't need to do this to solve the problem.

Read the title, scanned the linked page, read the insightful comments. Gained a bit of information on the current state of cryptography. On to the next item. The accumulation of all such tidbits that appear here that has been incredibly useful.

fogus: thanks for posting all: thanks for the perspectives.

Back to my irregularly scheduled program...

Excellent advice. I think often times when we feel 'stuck' there are a world of other options we are not considering. If things are truely that bad on all perspectives, it shouldn't be hard to find a partial solution that improves them.

I think the school systems are missing out on the transformational capability inherent in the use of technology. It's like using airplanes to drive around the country without ever leaving the ground. Until they transform the process of education, it's just typing instead of writing.

2. Seems like a partial consequence of the higher churn rate modifications.

I've found that scoring is a rather slow operation (relatively speaking), and so at the very least people should consider using memoization when they score or some other technique to reduce frequent scoring of identical terms.

Technically dumb is not necessarily economically dumb. I also don't agree with your assertion that it's technically dumb.

Seems like your product might be in a good position to get some local advertising revenue. There are probably lots of smaller independent businesses that cater to hikers and would love to boost their traffic. Spend some time talking with them.

UPDATE: Perhaps collect some information regarding the most frequently accessed locations on your maps and target businesses in that area.

e.g. If Oprah only publishes 3 tweets a day, but her one million followers each check 100 times a day (just to be on the bleeding edge of gossip), it's much less effort to push the change.

On the flip side, if you post status changes several times a day but your followers rarely check (daily/weekly), pull may make more sense.

Although, I suppose that a push inherently requires an update/write, while a pull is generally a read. Seems like this might need to be taken into consideration as well.

If accessed frequently, but changes less frequently, then push makes sense, if changes frequently, but accessed infrequently, then pull makes sense.

It also seems likely that the same piece of data may have different ratios from different perspectives.

I'd bet that it is.

Perfect, and complete, probably not. Useful to someone trying to grasp the basic options available, sure. The "old school" style may be the best way for you, but certainly would cause problems with many developers or while trying to use some large JavaScript libraries (though fortunately most those tend to use some type of encapsulation (except the unfortunately ubiquitous Prototype)).

If you don't like JavaScript patterns or the subject doesn't interest you read the link head line and move on. If you are interested, I think the article is a nice brief summary of some ways to use JavaScript.

I think that's his/her point. The manufactured pot would need to be priced higher (to pay for the production equipment over a reasonable depreciation period) in comparison to the hand produced pot that incurs no such overhead to produce, just cheap labor. So in effect, yes, a manufactured pot would be more than a hand produced pot.

I do think the commenter confused the matter by including imported items in the argument.

Given unlimited future earnings, you are right that a manufactured product may be cheaper to produce since there's much less labor cost, but in all practicality I'm not sure it applies.

To say that it's only the buyer's perspective seems to be ignoring the other side (as you correctly point out the OP did).

I can accept that to produce and distribute that content costs someone money. The ad based revenue model aligns very nicely with the quality of the content produced (assuming greater quality == more readers).

The problem with the pay per read model is that you don't know if you want to pay before your read. Now that probably works for larger publishers of quality work (e.g. IEEE), but for those random one-hit-wonder bloggers (and there are many of them), how would you know if yesterday's highly linked post was worth the 50 cents?

Some times a three paragraph blog post is insightful enough to be worth the nickel, sometimes I wish they paid me for the 2 minutes it took to read.

With a book or a larger volume of work, it's easier to briefly browse and make a purchase decision.

For the informal survey, I don't use ad blockers, but I just don't get bothered by the ads (with the random access afforded by a visual page they are rather simple to avoid). The onerous ones click-throughs and pop-ups), yeah, those are annoying.

Throughout my programming career, I've noticed a strong correlation of bugs with code that was given less attention (it was deemed to be an easier problem to solve, or compartmentalized and solved later).

I don't think it's fair to claim people were stupid just because a detail was overlooked. Perhaps they could have allocated their attention differently, but without knowing all of the trade offs it's hard to say they made a bad choice.

I think that people have a finite amount of "attention" that they can devote to things during a day. Furthermore spending attention on a task seems to consume energy. It's reasonable to think that occasionally some items get less attention than they should.