psnj

> But I notice that the only people that really hate it are powerusers.

This is an excellent point. If I write network clients in elisp just for yuks, I'm probably not Apple's target user for iTunes. Emacs' UI has broken my brain (and hurt my fingers.)

Vigorously agree. I have no idea why I have such a hard time using iTunes, but I do consistently, even doing really simple and obvious things. It horrifies me.

I was surprised by my almost-panicky reaction to seeing:

  Identifiers Can Have Blanks

  open_window_with_attributes(...)
  becomes:
  open window with attributes (...)

I think I actually felt that wrongness in my stomach. Like a more intense version of seeing our corporate network shared drive's files with spaces and parens in them.

I guess I'm old.

I used to work at OT when Glazer was there, and I attended a workshop once where he gave a talk. Very impressive guy -- I remember thinking "I want to work for the company that guy's working for!"

I think the "diamond test" is useful and elegant in its simplicity: a woman that requires a diamond to marry you is the wrong woman.

I say "sequel" ("s-q-l" hardly rolls off the tongue) but often in my group we call it "skewl", because in addition to shaving off half the syllables of "sequel", it sounds fittingly sorta gross.

Funny, that pulsing light drives me nuts. If I'm in a darkened room with my MBP, I have to cover it or turn it to face the other way.

> [...] there isn't such a thing as happiness.

> Misery and pain is part and parcel of being alive and that's the way it should be.

Is it not possible that there is happiness, but also misery and pain? I've felt both.

Is happiness "achieved"? Or "encountered"? "momentarily brushed-up against"? "allowed"?

In any case I think an approach like TTL's is worth trying: nowhere do they say "that eternal bliss is possible". It seems they're just trying to help people make things better for themselves.

I've always found this an interesting topic, and once in a while it's interesting to discuss it with someone who believes in a god.

Sometimes I wonder how much we choose what we believe, especially when it gets down to this bottom-of-the-soul (or "soul"), meaning-of-life stuff. When someone is incredulous at the fact that I don't believe in any sort of god, I 've said: "Let's try this: for the next sixty seconds, I'll start believing in God, and for the same sixty seconds, you have to stop believing in God. Are you in?"

Naturally, it's not really possible for either person to do this, but sometimes it promotes interesting discussion about the nature of faith — why can't we do this, etc, etc?

Of course, a lot of times it just pisses people off too.

Although it is a bit goddy for my tastes, I've always liked the Ritual Calling of the Engineer and the Iron Ring that goes with it, which is unusual because I'm certainly not one for ceremony. But I appreciate the serious tone and quiet underlining of the importance of the discipline.

I'm not an engineer, but one of my top software dev industry pet peeves: "Software Engineers" who aren't actually engineers. It drives me nuts.

I think this is great advice. I've been in some dark corners myself, and the parent comment resonated with me, especially:

* It seems like you're the only one dealing with this, but you're really not. My friend describes us as ducks -- all calm above the surface, padding madly underneath, but only you know about that. Everyone you know is dealing with something, and wondering why they're the only ones. They're not, and you're not.

* Exercise really does go a long way. After a long bike ride I get what really is best described as a "peaceful, easy feeling" (oh man I hate the effing Eagles) but it's true -- after a hard ride or workout you realize how much better you feel, and how stressed out you normally are in comparison.

* It sounds ridiculous, but's really easy to forget to have fun. Don't forget to do the stuff you love. When you do, you'll feel "more like yourself" again.

Anyway, the main thing to take away is that (as you've seen from these comments) lots of people are in the same boat, and there are things you can do to help yourself.

Good luck!

A startup in the co-working space I'm in is addressing this very problem: http://www.zeebu.com/

They create smartphone games for little kids. Twenty-first century pacifiers? Apparently the kids love them!

No mention of the "geeksnort"?

> Can you show me some statistics to prove that this > (junk mail) works?

One could argue that it must be effective, as it's expensive to print and post mail, yet marketers have been doing it for decades. Its results are also generally more measurable than those of mass market advertising.

> You have no other means to reach your customer

On the contrary, (addressed) direct mail is generally sent to as targeted a market as possible. If you know your market, you're generally better off putting a lot of resources into a well-qualified set of prospects, than taking a more "shotgun" approach.

> Checking parameters in every method (especially an OO system) is a sure way to have poor performance.

This seems overly general to me. I'm not sure it's a "sure way to have poor performance." It seems to me that (for example) a null-check is pretty fast.

> Normal methods should just work find even if a parameter is NULL.

What's a "normal method"? And if the business logic of the method requires a particular parameter to be non-null (or has some other constraint), what should happen when a null parameter is passed-in (by a test or otherwise)?

> 1. If you are going to assert these things, don't do it in the middle of the method - do it in a place that makes sense (start of the method).

Sure, I can see that -- assertions in the middle of a method might well indicate that maybe that bit should be split into more than one method.

But the article goes further than that: they seem to complain about assertions guarding parameter values. I really don't get that. Actually, I'll go one further: complaining about that is unjustifiable.

Anyway, I also don't always get the particular flavour of OOP dogma that Java devs sometimes seem to promote. It certainly feels different to me from Python world, and I suppose it is.

When I see the phrase "silently does nothing" I feel vaguely uneasy.

Could someone explain: "Be Defensive - They're out to Get Your Code! - Defensively assert about the state of parameters passed in methods, constructors, and mid-method."?

which, desarcastified, I take to mean:

"Don't defensively assert about the state of parameters passed in methods, constructors, and mid-method."

Specifically:

"You see, there are testing freaks out there that like to instantiate your object, or call a method under test and pass in nulls"

Isn't it the case that a calling a method with (say) null parameters where they are supposed to be non-null should raise an exception? Isn't an assertion failure reasonable in this case?

I understood and agreed with a lot of the other stuff (although it struck me as a bit dogmatic) but this one I don't get.

It's in situations like that where you see flight attendants doing their "real" jobs.

Agree.

When I was getting my pilot's license, I learned to be hyper-aware of another airplane that was less than say 1000 feet from me. But the strangest part of those lessons was getting back into my car afterward and getting onto the 417, where I was a couple of feet away from other cars, also going 75mph. I was completely at these other drivers' mercy: I had effectively no time to react to them, and knew from experience that lots of drivers are just plain awful (and this was really before you'd see people driving while texting with one hand and changing their kids' DVD in the other.)

It was very, very scary. Total loss of control — far more than in an airplane, where to a much greater degree if things go sideways, it was probably your fault anyway.

The other interesting thing about the scary drive was how long it stayed scary: maybe ten minutes, tops. After that — business as usual. Didn't even think about it.

It's interesting what we can get used to.

Yes, you're right. I agree that there are times that denormalizing makes sense. My point was that the item said:

* Throw away the normal forms you learned in school

* Denormalize [...] whenever it makes a query faster.

I think that's bad advice as stated. As you imply, you have to know why the rules are there to know when to break them intelligently. I didn't get that message from the item as posted, rather that the author thought that NF had little value, which probably doesn't belong in a list of database tips and tricks.

[edit: format]

Some reasonable advice in there, but #3? Ruh roh.