dstorrs

I have to admit, the first time I read your comment I waved it off impatiently as "yes, yes, obviously that" but I'm glad I re-read it. I hadn't thought about the fact that her interests may be changing quickly and often, nor some of the other practical mental challenges that her age might bring like an attention span that is significantly different from day to day. Thanks for pointing that out -- I suspect you just saved both me and L a lot of dissatisfaction.

2] When you get the reminder, spend 10 minutes reading http://www.emacswiki.org/ Find just one thing that interests you.

3] Make a point of using that one thing at least a couple of times over the course of the day.

If you want to learn all the keyboard commands, spend your first few days (re-(re-(re-)))reading the basic keylists.

It will start to stick in less time than you think, and you'll have fun doing it.

My question: does it actually have practical utility as a weapon of war for the modern US Navy? This seems like fighting the last war -- this is about building a weapon that goes on giant ships, when the new war is all about information and special forces strikes.

"Um, what?" --Every open source developer, ever.

>[using a DB join means that] the query takes almost a second

This is, at best, an overgeneralization and at worst outright FUD. I don't know what sort of data or database engine you're working with that might make this true, but it's definitely not a requirement that it be this way. The RDBMS backing my site is trivially able to return all needed data in fractions of a second for most cases regardless of the presence of joins. If it can't, that generally just means that I forgot to index something properly.

Moving past this, going with a simple key/value store instead of an RDBMS means giving up at least three of the ACID properties in favor of nothing more than a speed gain.

- Atomic: No transactions. If the system dies between two related commits...oops, your dataset is inconsistent.

- Isolated: No transactions, again. You cannot make guarantees about what information an object will have -- e.g., you cannot say "Every user will always have at least one entry in Pages, because we automatically create a non-deletable Home page for every user at signup." If you rely on that, you will eventually hit a user who is halfway through the signup process and has a user entry but no Page entry.

- Durable. If your backing store has not actually flushed your write to disk and the system crashes...oops, you're hosed. I hope you weren't storing your Accounts Receivable data in that NoDB.

1] MySQL supports more replication options, whereas PostgreSQL focuses on the ones that 95% of users will care about and does not implement the rest.

2] MySQL's replication has several failure modes that can lead to data loss or non-synchronization. For example, it is statement based by default, so any statement which includes a call to NOW() will return different results on master and slave. PostgreSQL also has failure modes, but the defaults are designed to minimize them -- e.g. it always uses WAL and data file rewrites to ensure that data is properly synced and consistent.

3] Due to points 1 & 2, if you aren't an expert and don't need the extra features offered by MySQL, you are probably better off with PostgreSQL.

4] 3rd party tools exist for both servers which close many of the feature gaps between them.

Could someone who is more knowledgeable than me tell me if this is a fair reading?

I found this book horrifically tedious, and everyone I talk to apparently thinks it's the Greatest Story Evvvaaaarrr1!!!11!! It's nice to know that I'm not completely alone on this.

The first few books are excellent. Once she gets promoted past the point where she can really be a ship captain, the stories turn political and start to drag a bit. Weber evidentally realized that this was not working, because he's started writing about new characters who are lower-level and therefore more interesting, so the newest books are once again a blast.

"Data startups need three bodies (hustler, designer, prodineer). Talk to customers early. Here are the levels of knowledge: 1) data, 2) charts, 3) reports, 4) actionable analytics; higher numbered levels are more valuable."

You're misreading.

I presented two possibilities, but nowhere did I claim that they were the only two possibilities -- ergo, no false dichotomy. You aren't clear about where exactly you believe that I presented a straw man, so I can't respond to that one. If you're saying that modern union shops do not result in the sort of inefficiencies I mention above, then the kindest response I can find is that we must have very different experience of union shops. I invite you to examine the union-imposed rules at, e.g., Yale Medical School, which is what I was particularly thinking of when I wrote that.

> The purpose of unions has always been to bargain collectively in situations where individual actions alone would result in a greater detriment to each worker.

Thank you for that basic restatement of the definition of "union." You did, however, leave out the important bit: that the nature of union bargaining is always the workers of a corporation demanding policy changes from the owners of a corporation.[1] These changes always involve a cost which reduces the bottom line profit of the corporation -- e.g. higher pay, shorter hours, etc. From a strictly short-term, monetary POV, anything that reduces the bottom line is non-optimal. In the long term, however, or when other measuring sticks are used (social health, GDP, etc) these changes may be enormously better than the policies they replace, because they result in more total wealth in the hands of the consumer, more leisure time in which to consume / innovate / create / be healthy / etc.

This is exactly what I said in my original post. Hopefully you will more clearly understand the more spelled-out version.

> A corporation is by nature this same mechanism [for using collective action when individual action would be sub-optimal] applied in the market, so which side you prefer — the worker or the owner — is fundamentally one of politics in the end.

While this is technically true (as in, it does not contain an explicit inaccuracy), there are some significant differences between a corporation and a union. Most notably, the benefits of being in a union accrue essentially equally to all members, whereas the benefits of being in a corporation do not -- the owners and top officers reap far more of the rewards than the "bottom rung" employees. Furthermore, their incentive structures are very different -- a tech support guy is paid $N/year as long as he shows up for work and the company doesn't go bust (incentive to keep the status quo), but the CEO is making most of his money off of stock options and/or bonus (incentive to change the status quo).

[1] I'm using the word "corporation" loosely here because it's more commonly applicable and it's easier than naming the various possible employing bodies (government, NGO, non-profit, etc). Most often it's a corporation per se.

> incremental crackers [were used to] harvest thousands of passwords [and] forced Unix systems in the 1990's to adopt "shadowed" password files.

As someone who is interested in security but has not spent significant time studying it, I'd be interested to hear more about this. How did Unix solve the rainbow table issue? What is an incremental cracker and how does it relate to shadowed password files? (I'm familiar with the latter but not the former, and a Google search generates more noise than signal without more keywords to go on.)

IMO, the "killer app" for unit tests is regression testing. If I make a change and the test suite still passes, I can be reasonably sure that I didn't break anything. All the other benefits are "nice to haves" in my mind.

- Businesses are, in fact, what generates most of the wealth and innovation in a country

- Taxes, whether personal or corporate, are not economically efficient. Government can be compared to an electrical grid -- the money comes in one place, flows out somewhere else, and there are line losses on the way. (Government overhead, wastage, etc)

- As to workers' rights: any society represents a particular set of choices about production needs and social needs. Sometimes those needs are cooperative, sometimes orthogonal, and sometimes they are in opposition. When "workers' rights" means "give us the money and the time to innovate and consume outside of work", it's good for society. When it means instead "give us the power to force you to comply with stupid and inefficient rules about who can do what" (e.g. most modern union shops that I've encountered), that's bad for society.

- Traditional: You are the breadwinner, your wife has the primary housecare / childcare duties.

- Modern: You do your breadwinning from home and are self-employed instead of working for a company.

- Traditional: You and your wife recognize the importance of passive income.

- Modern: You both recognize that investments are no longer a reliable way to make passive income. Instead, you are working on a company / product / service (AppIgnite) that will create new wealth. [1]

[1] I'm not saying that the passive income is the ONLY reason you're doing this, or even the primary reason. But I'm sure an awareness of market changes factored in somewhere.

IMO, the basic principle of TDD is solid: write the tests, then write the code. Like most ideologies, this takes an acorn of wisdom and grows it into an oak tree of folly (or some other really pompous metaphor -- that sentence rather got away from me).

The problem comes when people think the tests are something valuable in and of themselves. They aren't. They are only valuable insofar as they show a developer (a) if something is broken and (b) what it is.

I generally agree that Mocks are more trouble than they are worth -- they are an entire mini-codebase that doesn't contribute business value and must be maintained. But usually you can get most of the benefit without spending the effort: e.g. instead of a Mock::DB, have a separate instance of your prod DB running a snapshot; instead of a Mock::HTTPConection, just do a real HTTP request.

In short, I relate to your philosophy and share it to a certain extent, but I encourage you not to let the TDD zealots drive you away from what can be a useful tool.

As to your position that "filtering the noise" is easier than "increasing the signal", I think that you have perhaps...shall we say, not carefully considered the logistics involved? But leave that aside.

The danger with disenfranchising anyone, for any reason, is that of false positives. To paraphrase Blackstone, I would far rather that a hundred idiots were voting than for one wise person to be unfairly disenfranchised.

Fundamentally, society works because most or all of its members believe that they are better off as members of the existing framework than they would be by moving away, rebelling, etc. The last time Americans were bound by laws and taxes concerning which they had no voice, they threw quite a party in this little town up in Massachusetts...I think they served tea?

Thank you so much for reminding me of him.

How come I can still have syntax errors? How come it is ever possible to have a syntax error in a program? Shouldn’t the IDE at least be helping me to have a valid program all the time? Finale doesn’t let you write a measure with the wrong number of beats and then complain when you push play. It just fixes it for you — “oh look, you need a rest there.”

====/QUOTE

Oh Luke Palmer, no.

NO. The absolute last thing I want from my editor is for it to be modifying the code without my explicit request. Then if something breaks, I need to worry about whether I broke it or whether the editor broke it. (And yes, yes, I know, the compiler "modifies my code", blah blah.)