dazzer's comments

Well no... the middle child only comes into existence upon the introduction of the younger child.

Hah this is pretty much me at my current joint... and the worst part is it just feels like there's nothing left after.

Technical Evangelist sounds like a good fit.

i.e. someone who loves the product, knows about the product, and is able to pitch the product in different ways to different audiences (techy users, developers, etc.). This person would also know how to demonstrate the best features of the product.

I don't know. I had the feeling you were raising a contradictory point? Or am I mistaken.

I vote for the solution below which asks "how do you wish to be identified" instead of "what is your gender".

Lets propose that you have a child, and in your wisdom, decide that letting your child roam on the streets is low risk and thus ok.

Do you then proclaim to everyone that they must let their children roam alone on the streets as the real risk is low?

What is important is people have a choice to act on their perceived risks. In your example, the ability to wear clothes to hide their gender is their choice, it is not imposed on them.

In this case, they do not have a choice that is sufficiently suitable.

And that's a separate issue to what Randall is raising.

Guys, lets not get carried away by the issue here.

The issue is NOT about gender identification. It is Google+ not providing the ability to hide your gender on your profile (I won't say they're FORCING you to post your gender).

The issue of Gender Identification is merely an example provided to justify the usage of such a feature. So let's avoid a massive gender debate here, when you can read all about it in the post itself.

At first glance at your comment I said "how would that help". Then I thought about it a second time, and I think this is actually a legitimate way to approach the problem of gender identification. So +1 for me.

Wonder what others think

Yup I see it as an oversight.

While I believe that people get overly sensitive about gender (or any politicall-incorrectness), I also believe that it is in their right to do so, and if Google does fulfil this request then all the better for it.

Aside, though, this post by Randall seems a little overkill at this stage... unless Google has taken an obvious stance on the issue there is no reason to take umbrage.

That's a taboo I don't understand.

What's wrong with talking about what you earn? I can understand if it was pride/ego preventing people from talking about it. But from the workers' perspective wouldn't it be better to know what the going rates are to make sure you aren't getting ripped off for your work.

"Looking for co-founder" is another way of saying "I have no money to pay for a technical team so I'm offering you a stake in a potentially successful venture". Makes sense to me.

Seems to me like an obsolescence strategy.

By declaring right out that it is no longer going to be supported, people will be encouraged to write for the newer databases. Eventually when the standard MySQL version moves up, it won't be stuck in 4.1. Plugins authors will also appreciate that they have been given enough heads-up to update their plugins.

This will also give people time to upgrade their databases if they're managing their own.

"Is an app an HTML5 app simply because it makes use of HTML5 technologies?"

Yes.

When you maximise a window, it takes up the entire screen. In the case of multiple monitors, it takes up the entire screen of the current monitor it is currently displayed in. Multiple monitors are therefore a hardware method of window management without having to manually resize them.

In Windows 7 you can now dock windows to the left or right. This has worked really well for me on a single 24'' at 1900x1200 resolution. In the past this was not possible out of the box.

Isn't dropping trailing slashes a bit dangerous? They have different semantic meanings.

Technically, (my interpretation is that) it abstracts your application from your db. The ORM acquires the data, allowing your application code to concentrate on using the data.

I agree with rimantas. Views and Stored Procedures should not be used to perform business logic stuff i.e. I should not have to create a view with massive joins just because a logic need requires it. And I should not have to dive into my database when a business rule changes!!! Views and Stored Procedures are useful when you lack a layer of abstraction (e.g. An MS Access FrontEnd) where you may want to put security restrictions on the data that is exposed to a particular group of users, OR for performance reasons where a reasonably complex query can be run faster as a stored procedure. Of course this is my personal view, and is definitely a point of contention for many people.

The whole point of an ORM is to abstract the data from application code. Business Logic can be built on top of it with minimal knowledge of the underlying data storage system except in exceptional cases. ORM frameworks aim to simplify the process of writing these boilerplate code and continue to fulfil most common use cases.

For a second I thought you made a site where people could contribute their ideas and try to gain public support. At which point I would have just pointed at Kickstarter.

Interpreted pedantically, removing ORM techniques means dealing directly with resultsets or loosly typed structures. This is definitely what I DO NOT want in any of my views. If you're working with an OO language like C#.NET or Java, good luck!

Any abstraction on any level is going to add a performance hit no matter what.

If this was really an issue, wrap your ORM Framework stuff (differentiating from ORM the pattern) in a DAL layer so that your BLL does not worry about the existence of the ORM. Then as you scale, optimise your DAL with either inbuilt optimisations or when desperate write your own SQL (if you don't even know SQL then you're a poor excuse of a developer)

Think of them as like Ikea furniture - they don't look great, and they don't often fit in every household if they have complex requirements. But they're highly modular, and easy to assemble. So when you need something in a jiffy, just bring it home, fix it up and it'll perform its purpose. When it no longer fits the purpose, get something else. And every household has to just start somewhere.