All excellent examples. Some of the things that help these events work:

      - variety. I can't drink or have donuts or pastries for health reasons, but I love to cook chili, or chicken wings, or something hearty for lunch. other people have different health, cultural, or religious restrictions.

      - self-sponsored. volunteer organizers, keep it simple and light. too many companies that do "events" over-control them; timed to the minute, checklisted, get in the queue, march in time.

      - contests. some folks had a clever idea where I'm working; everyone picked an innocuous secret about themselves, and everyone had to guess who, in another department, had which secret. it gave people the chance to talk socially, rather than about work.

      - time and consideration. too many companies that do "events" fail to leave time to socialize. especially with support staff, arrange to cover for them while they join in. push back meetings to another day, lighten up on "get this done by the end of the day" B.S. tasks. give people a chance to enjoy the event without worrying about the pile of stuff on their desks.

> The God question is sort of like dividing by zero in math. The result isn't 0, it is undefined,
> or sometimes referred to as "not a number", and sometimes referred to as infinity.
> It definitely exists, and can even be useful in certain applications, depending on how you
> treat it, but what it means is impossible to determine.

I like that comparison. Thanks!

> Only the Agnostics take a logical stance when it comes to god, and simply state "I dunno"
> and go on with their lives.

Nitpick: logical, if you _believe_ that the failure to choose is a safe, neutral option.

    "Would you like carrots or broccoli with your meal?"
    "I dunno."

Is a neutral option choice.

    "Here comes a truck heading straight for me! Should I dodge left or dodge right?"
    "I dunno."
    SPLAT!

Is a case where failing to choose is a choice, with consequences.

Imagine you're in Germany in the 1930s. Someone asks what your opinion is of these brown-shirted guys and their leader, Adolph somebody, with the Charlie Chaplin mustache.

"I dunno" is fine; but history shows that trying to learn what these guys are all about would be much safer than just moving on with your life in blissful ignorance.

Is it enough to say "I dunno" and move on, or do you need to proceed to "I'll take time to study, so I can make a decision."

> I'm also careful not to commit the fallicist's fallacy - that is, just because an argument
> is fallacious does not mean the conclusion itself is false

Or phrased differently, lack or scientific proof for or against an assertion/theory/belief doesn't make it untrue, just unproven/unprovable.

Good comment.

I expect you're right. I (and a number of people I know), purchased Amazon Gift cards at the 11th hour.

Convenience and rapid availability would apply very well to any dowloadable media.

>> Not in the US, where delayed/misdirected, effectively "lost" EFTs are commonplace.

> I have to disagree, here. I've banked with several different credit unions, a couple of small
> banks, and three or four large banks over the past several decades. I've never had an EFT go
> missing. Besides, if the problem was as widespread as you believe our entire e-commerce
> marketplace would have never taken off. Amazon seems to be doing quite well. :)

Fair comment, but I must point out a few things:

  - I didn't say the EFTs went missing; they weren't completed or cancelled. The bank knew where they went; they just couldn't resolve it in any reasonable time frame.
  - I didn't say debit cards there. That specific comment was EFTs. Online banking payments in place of checks. Debit cards work very well, and I use them online at several places. But the legal protections aren't there. The banks have largely implemented good policies for handling debit card issues. But in case of an error, there is no legal protection. And banks often don't offer any of the same protection policies for online direct bank payments.
  - I didn't say it was widespread, just commonplace. It happens to a lot of people; percentagewise not often. But with the number of people using them, even a tiny percentage adds up quickly. They are probably significantly -less- frequent than check errors. But check errors are governed by law. Consumer EFTs not so much.

Check the Risks Digest and Consumerist.com, as well as a number of mainstream news sites. If happens, and when it happens, it's often very bad.

> I will concede, though, that person to person EFT capabilities have been FAR too slow to emerge.

Not just consumer to consumer; they are often -very- unfriendly to small businesses. I've worked for many firms that don't offer direct deposit, not because they don't want to, but because of the horribly obstructionist bank policies.

Thanks for your comments.

>> not all customers have access to electronic funds transfer.

> That's your problem, right there. Fix it.

It's a problem, but not the only problem in the US.

> The capability for electronic funds transfer should be automatically granted with any bank
> account - both via debit card and via internet. In the Nordic countries, cheques are
> essentially extinct.

Most other nations have different financial protections on EFTs than here in the US.

One root cause of this is that the banking system in the US grew from state-chartered banks, not federally-chartered banks. 50 states, all with different rules and regulations.

Much of the current legal and technological infrastructure to begin to _consider_ phasing out checks in the US was only put into place post-911. At that time, the federal government was confronted with the fact that they had been nursemaiding a check clearing system leftover from the early 20th century, and even a brief interruption of airline service significantly impeded the ability to move huge boxes of paper checks across long distances quickly.

The legal overview still isn't as good as it needs to be. People in the US are still advised by security and financial planners to use _credit_ not _debit_ cards, because the protections against errors and fraud are "bank policy" which can change in an instant, not "the law".

Correcting an issue with bank errors in clearing a check required banks to put the funds back in place and follow a real procedure for resolving the issue quickly.

With EFTs/Debit cards, banks are typically _very_ slow to restore the funds, and often glacially slow (and incompetent) at resolving the issues.

Personal experience: I've set up EFTs for recurring bills at various times in the past. In each case, the bank was unable to complete some transfers, unable to cancel the transfer, unable to resolve the issue quickly, and I was charged for late payments. Some of these took several _months_ to resolve.

> The only cheques deposited are invariably from countries with backward retail banking (UK, US, Canada, etc.)

As noted by another poster, it isn't all retail. In fact, it likely isn't even _mostly_ retail that deals with checks. Small service industries: appliance repair, contracting/home remodeling, charities and non-profits, small-business suppliers and wholesalers, shippers and transport firms, any companies dealing with Asian, South American, or former Soviet-block nations need to deal in checks all day, every day. Or lose the bulk of the business they do.

> electronic transfer to or from other accounts (worldwide) is fast and cheap,
> and provides immediate confirmation of receipt of the payment.

Not in the US, and the banks are shielded from the need to confirm _by law_. I'm also curious about the claim that it's fast and cheap (reliable implied) worldwide. I mentioned several regions above where checks are still common. I have no doubt that fast, cheap and reliable EFTs are available in all those regions. But are they reliable to all businesses in those areas? Sure, if you are dealing with a big Asian electronics, metals or chemicals supplier, I'm sure it's no problem. What about the small-lot specialty suppliers; do they have the same fast EFT access, with reliable transfers protected by law? I'm not so sure.

> There is no risk of "delayed/lost in the mail" as happens to cheques with remarkable
frequency.

Not in the US, where delayed/misdirected, effectively "lost" EFTs are commonplace.

> On-the-spot payments (small stores and large, petrol stations, vending machines,
> parking meters, etc.) are made using the debit card for the account.

Mostly true in the US; some things (parking meters) are not usually equipped for debit cards. In part, this is due to the fact that there are more parking meters in some major US cities than there are _people_ in some of the Nordic countries you mentioned. Since ownership and management of these is at the local, city level, replacing them is an expensive and time-consuming proposition. But it is being done.

> There is no need to carry wads of cash in your wallet, and shops do not have to handle
> or transport large amounts of cash.

Both good things.

Just pointing out that there are fairly significant legal and technical hurdles that the federal government hasn't the constitutional authority to just force through ("That's your problem, right there. Fix it."). They need to work with and enlist the cooperation of a republic of 50 independent states. and thousands of businesses.

Thanks!

> AFAIK French legal system doesn't use this "precedence" the same way you USAers do.

You're probably correct. France's legal system is quite different from that in (most of) the USA. Louisiana still uses a lot of the French legal systems it had in place when it was a French territory.

But IIRC, the typical US legal precedent usage isn't specific to the US, but is based in the British Common Law, which is the legal system in many nations which were formerly British territories.

IANAL; I just play one on the Internet ;>

> Visual Studio, specifically VC++6, rocked in the days of writing Windows apps.
> ...the editor itself was just awesome. It was solid, never crashed ...and was
> fast fast fast.
> ...Later versions, though, got seriously sluggish, and yes, ultimately it's
> just a glorified text editor, so why are all these windows sliding in and out
> at odd times, they rearranged all the project settings...Plus everything up to
> VS2008 has just been slow for me...from constant annoyingly-slow to
> wait-did-it-freeze-up-on-me-oh-no-it-just-came-back slow. Plus I've been
> able to crash pretty easily all of them...It's just that painful.

Hear, hear. Same pain on my end.

Especially with SSIS; redrawing the pretty little boxes seems to suck up all the processing power, and bring any other MS tools, like instances of SQL Workbench, to a halt.

Add to it the fact that, while the tools allow you to build project using msbuild and useful tools, the defaults are still exactly wrong. I work with a couple of teams at work who regularly have deployments to our production servers bomb, and they can't back out, because setting up the msbuild scripts and properly versioning the right files isn't the default.

It requires you to override the tools and do it manually. The pointers and clickers don't know how to do that and don't want to learn. So where I have Rakefiles (I was using ms-build, hoping to get others to use a decent tool by choosing one from MS. After fighting for months, I said screw it and just started using rake), they have 40 page manual checklists and tons of committee meetings to prevent errors -- and they still fail as often as not, and they never know what changed.

My Rakefiles track changes and version numbers, and I can back stuff out when needed (which isn't often).

Good to hear that 2010 seems to be better; but around here, that means we'll probably start using it in about 2025...

That's one reason I specified I was going off the summary.

I don't use ComCast and din't plan to search out the sources, but it's good to know a little about it.

Thanks for the info.

Thanks! I'll check it out.

Quick disclaimer: I don't use TFS, and don't care for integrated solutions - not just MS, but any of them.

> ...using TFS was the first time I realized how much an integrated source control, team collaboration
> site, project management integrated solution makes sense.

In some scenarios. I know any number of companies where the MS integrated solution you use would fail utterly to be useful, because the people would not use the tools properly. Not just developers, but project managers, users, etc.

The *nix/open source advocates generally don't favor all-in-one packaged systems. The vast majority of the time, the system has specific, glaring deficiencies, While it often works well for a specific group, it fails to support others adequately.

This condemnation has been levied against Eclipse regularly, and from personal experience, I can tell you that the Visual Studio IDE alone, while it is absolutely adored by many, is in many ways a useless tinkertoy for others. MS (and other all-in-one solution providers) don't provide the perfect experience. They target a specific group, and often their "solutions" actively undercut the work of others. Some specifics:

> * Integrated work items with specialized and extensible work item types for tasks, bugs, issues etc.

Working with a system now at one assignment that is remarkably poor. It works beautifully...for on-call help desk support. It actively -impedes- tracking of bugs and tasks for development. I actually use a full external tool and update the approved system at the end. This is awfully inefficient: only 10 times more productive than trying to use the approved tool.

> * Work items, tasks, issues etc. editable through a web interface, but also right from inside the IDE.

That's handy - if everyone uses it. Where I'm on assignment, no one can be bothered to update information. I track things in my a web-enabled system, as I said. Several times a week, someone asks me to print out information in that system. It's become the system of record for a lot of this information, and anyone can use it; but I'm the only one who does. Everyone else's data is in little silos.

> * Work items, tasks, issues etc. editable through Excel or some other spreadsheet (regrettably project
> managers favorite tool is *still* Excel - but having it integrated so the rest of us don't have to
> mock around inside columns and rows to update status is a big relief).

Again, handy -- if anyone uses it. Not so handy when people actively break it by mucking around with the Excel sheets.

Just kill Excel use.

> * Source control without quirks when e.g. renaming files or removing files and adding files back with the
> same names (I've had bad experience with subversion)

Others have complained about similar issues, but they aren't universal. Chances are you're not managing the files properly in subversion. But subversion isn't the be-all and the end-all of open source revision control. It was never intended to be, just a better CVS.

Git is very nice, and there are -many- others to look at. Check Wikipedia.

> * Shelving - storage of not-completed changes on the server without checking in. We use it to share
> suggestions and if we cannot make the daily deadline on consistent check-ins.

Never used it. Frankly sounds like a hack; why not use a branch?

> * Configurable policy which can be set to reject commits/check-ins if a build has not been completed
> locally and/or if too many tests fails and/or if test coverage is too low and/or if there are too
> many/certain warnings (e.g. security related).

> * Dashboard with project manager-friendly roll-ups and graphs with speed, test coverage, test
> completions, tasks, status etc.

Tons of options and tools. Again, not an "integrated" one I can recommend, as I don't care for integrated.

> * Branching based on metadata - not on actual directory copying and separate repositories/directories
> on the server (goes to performance).

Hmmm. Sounds like a hack on top of a hack. Git's management of revisions sounds like it would meet your needs, although not the way you're describing the implementation aspect. I'm always wary of cases where someone asks for a tool that accomplishes "this goal", and mandates that "the underlying implementation should do that". It often ignores better implementations.

I liken it to someone who asks how to improve sort performance in C using X method. where you discover later he wants to sort database results that could be selected using order by and bypass the entire problem.

Actually had that one happen. over 14K lines of hand-optimized C++ code, and the programmer who wrote it responded to "why didn't you use an ORDER BY clause in the query" with "what's ORDER BY?"

> If this is a GPL violation, I'm sure it wasn't deliberate by Microsoft.
> People around here no doubt think differently.

Yes and no.

> I'd be interested to know what processes they have in place...in theory,
> something like this would be a...break-down in the process.

Microsoft doesn't have a great history with "process", of whatever sort, being followed by all business units. This is true with security, and using "other people's code", not specifically open source.

They don't seem to be that organized. I suspect if this is a true GPL violation, this isn't part of a grand evil genius conspiracy. But it's quite possible, in my opinion, that someone lifted this and that there really isn't much in the way of controls on this. Rules, sure; but no real process to ensure it happens.

I'm not saying, "Linux Rules, Microsoft Drools!" Just that MS, among commercial software companies, focuses on marketing aggressively, not process control.

> ...cable modem contracts [assume] that your bandwidth is shared... You can burst up to the
> advertised rate, but you are never guaranteed to get it 100% of the time.

The offensive part of this is not that there is no guarantee of availability, but that there is a guarantee that it will -not- be available for more than 15 minute increments.

> You get throttled *only* if the network is congested...

That's not what I saw in the summary. The summary states that you will be throttled if the network becomes congested -or- if you use more than 70% for 15 minutes. I would agree that throttling if the network becomes congested is reasonable, and scaling back the peak users at those times is the obvious measure.

But the "70% for 15 minutes" cap, when there is no congestion seems to be unsupportable. I can imagine thousands of legitimate scenarios where home users would use 70% plus for longer than 15 minute increments; not 24/7, but for longer periods than 15 minutes. If no other users are competing for the bandwidth, what is the justification for throttling?

> "The outage was caused by a system failure that created data loss in the core database and the back up,"
> [Microsoft Corporate Vice President Roz Ho] wrote in an open letter to customers.

It sounds like their "backup" was a replica on another connected server.

No actual offline backups at all.

When JournalSpace was destroyed, one SlashDot thread was "Why Mirroring Is Not a Backup Solution".

My favorite comment was by JoelKatz:

>> The whole point of a backup is that it is *stable*. Neither copy is stable, so there is no
>> "backup on the hardware level". There are two active systems.
>>
>> If you cannot restore an accidentally-deleted file from it, it's not a backup.
>> ... if the active copy of the data is corrupted, there is no backup.

> Dude, a .reg file *is* a script. There's no difference between double-clicking on FIXSOUND.REG
> and double-clicking on sndfix.sh.

Except sndfix.sh (oir any shell script) can have conditional and branching logic, and verify the current configuration settings.

A reg file can't do that; it is always "erase and replace, no questions asked."

That's why more Windows admins are using PowerShell every day.

> My big complaint with the registry is that it's too convoluted. Config files are typically
> either in the user's home directory, the program's working directory or its installation
> directory. Registry entries could be buried under something like HKEY_LOCAL_MACHINE/SYSTEM/
> CurrentControlSet/Control/Class/{4DE36972-E325-CE11-CBFC-86753094BABE} -- how the hell
> am I supposed to remember that? (Assuming I could even find that in the first place!)

Very true, and I feel your pain.