How the fuck is refusing to be interviewed translated as 'threw a hissy fit'.
My 2 year old throws hissy fits.
This was not a hissy fit.
What the hell is wrong with you people?
Eric Schmidt is a human being and yet most people around here seem to think that he should be happy being treated like shit. Fuck that and all the power to him.
Since when is it Googles responsibility to syndicate any and every news agency out there? Does CNet pay google to syndicate their news? Google's been giving them a LOT for free. Google has taken NOTHING away from CNet.
Now would you care to explain just what Google has done that is so wrong? Considering they've done nothing other than refuse to do interviews.
This happens all the time. It just happens that Eric's, and thus Googles response has had a more resonating effect than when your average public figure refuses an interview.
What, should everyone on the planet be forced to talk to news agencies at the agencies whim? And just swallow when those same agencies publish stuff you don't want published, or agree with?
Christ people, why can't anyone think about the world they would _like_ to live in?
Eric would have done the exact same thing. He's not pissed because they used Google to find the info. He's pissed at what they published in the article.
Where the info was found is irrelevant. (CNet however would rather have you believe that _where_ the info was found is everything. It's not.)
Although, Google did not say "you're not allowed to do it with my personal information". Google is not condemning CNet for using Google to find said info.
Eric is pissed and rightly so. Just so happens he owns Google, a company that CNet and other news agencies like to do interviews with and report on.
CNet got personal, hit below the belt, and Eric has done nothing more than tell them to fuck off. He has not censored them. He has taken NOTHING away from them. He's just not going to give them anything anymore either.
Whatever little old your or I would choose to do in that situation, I think using our corprate muscle to censure the perant company of the journalist who published the said article is just silly.
Whoooaaa...hold on a second here. This is a _very_ serious misinterpretation of the facts.
Google is censoring nothing to do with this. Google has simply refused to communicate with a news agency that acted in bad faith. How the hell did the idea of censoring get into the picture?
It has nothing to do with Google, or what you can find via google.
It has to do with reporting personal information about a person in a way that is objectionable to said person, and said person actually having some recourse they can take. (Typically unlike you and me)
Just because information is available doesn't mean journalists shouldn't think about what they are reporting on. You wouldn't like it if CNet told the whole world these kinds of facts about your life. Unfortunately, in your case and mine, there's piss all we could do about it.
I say kudos to Google for standing up to asshole reporting.
Also, it is important to note that ".NET" means quite a few things...NET does not mean web-only. There are console.NET apps, form-based.NET apps, and web based.NET apps. There's also different languages that encompass.NET, such as C#, VB.Net, and J#.
Quoting your original pedantic, arrogant comment that started this all off. Asshat.
Man you're an asshole who just has to be right aren't you? You don't hear what anyone has to say except for what's coming out of your own mouth do you?
If you really do what you say you do for a living, you of all people should understand why using browser capability switches on the _server_ is a bad idea. You even gave one of the blatant reasons yourself, unreliable user agent strings.
You also assume that because I don't do so, that I must be providing IE only content. WTF? I completely explained myself here, go fucking read it yourself.
You attacked my living first, I've only defended myself. And yet you do it again. Fucking jerk.
I bet you're a real treat to work with.
I also bet that this is the same kind of attitude you'd give to a customer of yours that happens to use Opera.
And not that I give a flying fuck what you care, but I damned well do run a number of very high traffic web applications. Not one single user is ever blocked or served shit that doesn't work with their browser thank you very fucking much.
Yes, but if you actually read most of these posts you are talking about, you would realize that they are almost all doing it because of the benefits they are gaining by doing so. They are doing it to improve their systems, not just because.
So what are you suggesting? Should I move this old legacy asp site I've got sitting here, implemented with VB6 com components, into a C backed Perl app? Or go full Java? Would that be wiser?
(Hint: That's a trick question, you don't have enough info to answer it appropriately)
I guess I should go back to QBasic or something else that actually has been declared obsolete.
Absolutely nowhere did the parent state that they were directly 'porting' working asp code to asp.net.
And even so, there is no such thing as a magic 'port' tool, for ANY language. Porting is not a one-click operation. Porting is usually a lot of work in any scenario.
Doesn't matter anyways, because you most certainly _can_ port asp to asp.net. You just have to know how, and what the limitations are. Apparently your skillset would not qualify you to attempt such a task. VB programmer are we?
But, I'm quite certain you already know all of that and that I've been trolled along here.
Just FYI, as it appears you may care if you haven't ran across this yet:
Here's the most important usability problem occurring in AJAX implementations: XMLHttpRequest breaks the users expected back functionality as calls via XMLHttpRequest are not http requests and as such have no effect on the browser's history. (Also usually makes it impossible for a user to create a valid bookmark to where they want)
This does not mean that XMLHttpRequest should not be used, it just has to be used carefully. Unfortunately right now, it's being seriously abused because it's 'cool'.
Basic rules I'm going by: Use XMLHttpRequest for 'enhanced' features only. If the user clicks on a link, it should behave like a link. They will expect to use the back button, period. Do NOT use XMLHttpRequest here unless you also provide a means for the user to back out of clicking said link.
I'm using XMLHttpRequest for things like dynamic form validation/updating etc based on change events and the like. All degrades nicely as the server end of course still does all of this work, but nice when it can occur on the client as well. The user doesn't expect to use the back button after tabbing between form fields etc so no problems or confusion.
In other cases, use the hidden IFrame solution (or other equivalent). Requests to load source of an IFrame _are_ added to the browser's history. Back just works. So if you're dynamically fetching a bunch of data/content based on a user clicking a link or button, but don't want to reload the page, it is much better to do it this way.
Used in conjunction with each other very feature rich robust applications can be created that also degrade gracefully, and don't confuse users.
Wow, you really showed me. Wish I had known all of that before I started writing.net based web applications.
Now to counter the one real problem I have with what you said, about browser capability settings. Have we learned _nothing_ yet?
Code to supported standards, not to browser specific capabilities. Never NEVER switch code based on the user agent info provided. Test for capabilities on the client when you _must_ use possibly unsupported features.
Even GMail does this. Do you think they're using a server-side browser capability test to determine whether to instantiate XMLHttpRequest on the client directly or as an ActiveX control? Absolutely not.
So yeah, thanks again for talking down to me about what I do for a living, and yet proving that you do not know anywhere near enough to be partaking in this discussion in such a demeaning pedantic way.
Why is it that a screen reader works fine with a normal windows application, but falls apart leaving the user 'blind' with most web applications?
Because there are a huge number of guidelines that are followed in building windows apps. The tools just work that way.
All of the required guidelines exist to build fully accessible sites online. We just need to use them.
There is simply NO reason for all sites with accessability requirements to be simply styled text. Rather, if we use the available guidelines we can provide much MORE accessible web applications then are currently available. (My personal thoughts are that ALL web content should be fully accessible. If not, it's not right)
We simply need 2 things: A change in the false assumption that this is not possible. And, actually follow through.
I know I do. As a web app developer, I concider that a requirement of my job.
I think I've been fairly clear that the big difference now isn't what is _possible_, it is what is now within the grasp of your average developer/given resources.
I was writing AJAX functionality 6 years ago. A _lot_ of work, not reliable, NO tools available.
In asp.net 1.x, the foundation was laid, but it was still too time consuming/difficult to roll rich web apps with it.
With 2.0, it's in the box, available to point and click developers.
AJAX has been a viable _set_of_technologies_ (it is not a tool) for a long time now. There are just now viable tools that can easily make use of AJAX.
Yes, but it only really works as advertised in 2.0, when one is talking about rich web applications. (IE: Features in a web app one would expect in a normal app)
Non-IE output in pre 2.0 is severely lacking, very few advanced controls, and no AJAX features built in.
Yes, pre 2.0 does work, but it's with 2.0 that it works well enough to be adopted by a lot more developers.
It's a hugely matured platform now. There is tonnes of documentation and examples out there. More and more every single day.
If you can't see the wave coming, then you're not looking in the right direction.
As for language support, I see you managed to leave JScript.Net off of that list, which is exactly what you request, does exist, and is provided out of the box from MS.
You want Ruby, Perl or Python in there, write the IL Interpreter for it, or help one of the projects out there doing just that. Oh, that wouldn't be good enough either? Where's pascal.net and cobol.net? Shit, how many languages must MS provide for you to be happy for christs sake.
Man, talk about want your cake and eating it too.
(Oh, and if you don't 'get' OOP enough to use.NET, you have absolutely NO business talking about.NET. Just don't use it then.)
Please see the qualifications to my statement, and subsequent comments. I most certainly realize that.
However,.NET _has_ been used almost exclusively until recently to build rich intranet applications, as up until 2.0 there wasn't a lot available to the developer in terms of rich features unless you were to fall back on traditional asp/ActiveX type functionality.
2.0 absolutely changes this and is why we are just now beginning to see.NET driven rich web apps online.
No, I realize that. I'm generalizing on how asp, and recently, asp.net has been mostly used to produce rich intranet applications with ease.
Asp.net, and especially 2.0 have made huge advances in removing the ActiveX dependancies to allow for easier development of rich applications for the public internet.
Asp.net 2.0 is the first from MS to really provide the tools and controls to design richly featured websites from within their IDE (VS2005) using the provided toolset.
I've been doing the same for years, starting with traditional asp. However, it required doing all the complicated stuff by hand and from scratch. As such, it wasn't/isn't done a lot. It's a joke using VS2005. We will begin seeing more and more of these applications every day now.
Slashdot Mirror
OK, I'm sick of hearing that statement.
How the fuck is refusing to be interviewed translated as 'threw a hissy fit'.
My 2 year old throws hissy fits.
This was not a hissy fit.
What the hell is wrong with you people?
Eric Schmidt is a human being and yet most people around here seem to think that he should be happy being treated like shit. Fuck that and all the power to him.
No, the point is that CNet did this to someone that could actually stand up to them unlike you or me. (I think I hear an echo)
The problem is not with Google. It is with CNet.
Oh, well then.
o gle&btnG=Search+Newsg le+Search&meta=
Since when is it Googles responsibility to syndicate any and every news agency out there? Does CNet pay google to syndicate their news? Google's been giving them a LOT for free. Google has taken NOTHING away from CNet.
Here:
http://news.google.ca/news?hl=en&ned=ca&q=CNET+Go
http://www.google.ca/search?hl=en&q=CNet&btnG=Goo
Now would you care to explain just what Google has done that is so wrong? Considering they've done nothing other than refuse to do interviews.
This happens all the time.
It just happens that Eric's, and thus Googles response has had a more resonating effect than when your average public figure refuses an interview.
What, should everyone on the planet be forced to talk to news agencies at the agencies whim? And just swallow when those same agencies publish stuff you don't want published, or agree with?
Christ people, why can't anyone think about the world they would _like_ to live in?
Eric would have done the exact same thing. He's not pissed because they used Google to find the info. He's pissed at what they published in the article.
Where the info was found is irrelevant.
(CNet however would rather have you believe that _where_ the info was found is everything. It's not.)
I believe we are in total agreement here.
Although, Google did not say "you're not allowed to do it with my personal information". Google is not condemning CNet for using Google to find said info.
Eric is pissed and rightly so. Just so happens he owns Google, a company that CNet and other news agencies like to do interviews with and report on.
CNet got personal, hit below the belt, and Eric has done nothing more than tell them to fuck off. He has not censored them. He has taken NOTHING away from them. He's just not going to give them anything anymore either.
Whoooaaa...hold on a second here. This is a _very_ serious misinterpretation of the facts.
Google is censoring nothing to do with this.
Google has simply refused to communicate with a news agency that acted in bad faith. How the hell did the idea of censoring get into the picture?
Lets stick to the facts, mmmkay?
You don't think that similar information about you, or your family is available on the internet?
Put the shoe on the other foot.
Just because it's the founder of Google does not mean he is not a human being, and should not be treated as such.
I have one thing to say: (Though I could certainly say a lot more)
With great power comes great responsibility.
If you can't see the relevance of this statement, then maybe we should just go ahead and un-invent the internet.
It has nothing to do with Google, or what you can find via google.
It has to do with reporting personal information about a person in a way that is objectionable to said person, and said person actually having some recourse they can take. (Typically unlike you and me)
Just because information is available doesn't mean journalists shouldn't think about what they are reporting on. You wouldn't like it if CNet told the whole world these kinds of facts about your life. Unfortunately, in your case and mine, there's piss all we could do about it.
I say kudos to Google for standing up to asshole reporting.
Quoting your original pedantic, arrogant comment that started this all off. Asshat.
Man you're an asshole who just has to be right aren't you? You don't hear what anyone has to say except for what's coming out of your own mouth do you?
If you really do what you say you do for a living, you of all people should understand why using browser capability switches on the _server_ is a bad idea. You even gave one of the blatant reasons yourself, unreliable user agent strings.
You also assume that because I don't do so, that I must be providing IE only content. WTF? I completely explained myself here, go fucking read it yourself.
You attacked my living first, I've only defended myself. And yet you do it again. Fucking jerk.
I bet you're a real treat to work with.
I also bet that this is the same kind of attitude you'd give to a customer of yours that happens to use Opera.
And not that I give a flying fuck what you care, but I damned well do run a number of very high traffic web applications. Not one single user is ever blocked or served shit that doesn't work with their browser thank you very fucking much.
Asshole.
Yes, but if you actually read most of these posts you are talking about, you would realize that they are almost all doing it because of the benefits they are gaining by doing so. They are doing it to improve their systems, not just because.
So what are you suggesting? Should I move this old legacy asp site I've got sitting here, implemented with VB6 com components, into a C backed Perl app? Or go full Java? Would that be wiser?
(Hint: That's a trick question, you don't have enough info to answer it appropriately)
I guess I should go back to QBasic or something else that actually has been declared obsolete.
Absolutely nowhere did the parent state that they were directly 'porting' working asp code to asp.net.
And even so, there is no such thing as a magic 'port' tool, for ANY language. Porting is not a one-click operation. Porting is usually a lot of work in any scenario.
Doesn't matter anyways, because you most certainly _can_ port asp to asp.net. You just have to know how, and what the limitations are. Apparently your skillset would not qualify you to attempt such a task. VB programmer are we?
But, I'm quite certain you already know all of that and that I've been trolled along here.
Just FYI, as it appears you may care if you haven't ran across this yet:
Here's the most important usability problem occurring in AJAX implementations: XMLHttpRequest breaks the users expected back functionality as calls via XMLHttpRequest are not http requests and as such have no effect on the browser's history. (Also usually makes it impossible for a user to create a valid bookmark to where they want)
This does not mean that XMLHttpRequest should not be used, it just has to be used carefully. Unfortunately right now, it's being seriously abused because it's 'cool'.
Basic rules I'm going by:
Use XMLHttpRequest for 'enhanced' features only.
If the user clicks on a link, it should behave like a link. They will expect to use the back button, period. Do NOT use XMLHttpRequest here unless you also provide a means for the user to back out of clicking said link.
I'm using XMLHttpRequest for things like dynamic form validation/updating etc based on change events and the like. All degrades nicely as the server end of course still does all of this work, but nice when it can occur on the client as well. The user doesn't expect to use the back button after tabbing between form fields etc so no problems or confusion.
In other cases, use the hidden IFrame solution (or other equivalent). Requests to load source of an IFrame _are_ added to the browser's history. Back just works. So if you're dynamically fetching a bunch of data/content based on a user clicking a link or button, but don't want to reload the page, it is much better to do it this way.
Used in conjunction with each other very feature rich robust applications can be created that also degrade gracefully, and don't confuse users.
Wow, you really showed me. .net based web applications.
Wish I had known all of that before I started writing
Now to counter the one real problem I have with what you said, about browser capability settings. Have we learned _nothing_ yet?
Code to supported standards, not to browser specific capabilities. Never NEVER switch code based on the user agent info provided. Test for capabilities on the client when you _must_ use possibly unsupported features.
Even GMail does this. Do you think they're using a server-side browser capability test to determine whether to instantiate XMLHttpRequest on the client directly or as an ActiveX control? Absolutely not.
So yeah, thanks again for talking down to me about what I do for a living, and yet proving that you do not know anywhere near enough to be partaking in this discussion in such a demeaning pedantic way.
1.x yes, 2.0 not so much.
Cold fusion is only viable for closed systems.
If you're talking a web front end to any sort of distributed or enterprise system, it's simply the wrong tool for the job.
It is wonderful for web 'designers' to put out nice content with cool features, but for building true applications, no, most certainly not.
That is not true, or at least, very near sighted.
Why is it that a screen reader works fine with a normal windows application, but falls apart leaving the user 'blind' with most web applications?
Because there are a huge number of guidelines that are followed in building windows apps. The tools just work that way.
All of the required guidelines exist to build fully accessible sites online. We just need to use them.
There is simply NO reason for all sites with accessability requirements to be simply styled text. Rather, if we use the available guidelines we can provide much MORE accessible web applications then are currently available. (My personal thoughts are that ALL web content should be fully accessible. If not, it's not right)
We simply need 2 things:
A change in the false assumption that this is not possible.
And, actually follow through.
I know I do. As a web app developer, I concider that a requirement of my job.
I think I've been fairly clear that the big difference now isn't what is _possible_, it is what is now within the grasp of your average developer/given resources.
I was writing AJAX functionality 6 years ago. A _lot_ of work, not reliable, NO tools available.
In asp.net 1.x, the foundation was laid, but it was still too time consuming/difficult to roll rich web apps with it.
With 2.0, it's in the box, available to point and click developers.
AJAX has been a viable _set_of_technologies_ (it is not a tool) for a long time now. There are just now viable tools that can easily make use of AJAX.
Yes, but it only really works as advertised in 2.0, when one is talking about rich web applications. (IE: Features in a web app one would expect in a normal app)
Non-IE output in pre 2.0 is severely lacking, very few advanced controls, and no AJAX features built in.
Yes, pre 2.0 does work, but it's with 2.0 that it works well enough to be adopted by a lot more developers.
Ouch, now that is scary.
Thanks for the link!
That's great, and from personal experience that is certainly a lot easier to do now with .NET.
.NET? We always did for just the reasons you mention.
.NET a lot quicker as it wasn't a total redesign of every last bit of the system.
However, what stopped you from having a consolidated business logic layer before
Helped us get up with porting our systems to
Anyways, great that you've made that happen. Better late than never!
What a load of crap.
.Net off of that list, which is exactly what you request, does exist, and is provided out of the box from MS.
.NET, you have absolutely NO business talking about .NET. Just don't use it then.)
It's a hugely matured platform now.
There is tonnes of documentation and examples out there. More and more every single day.
If you can't see the wave coming, then you're not looking in the right direction.
As for language support, I see you managed to leave JScript
You want Ruby, Perl or Python in there, write the IL Interpreter for it, or help one of the projects out there doing just that. Oh, that wouldn't be good enough either? Where's pascal.net and cobol.net? Shit, how many languages must MS provide for you to be happy for christs sake.
Man, talk about want your cake and eating it too.
(Oh, and if you don't 'get' OOP enough to use
Please see the qualifications to my statement, and subsequent comments. I most certainly realize that.
.NET _has_ been used almost exclusively until recently to build rich intranet applications, as up until 2.0 there wasn't a lot available to the developer in terms of rich features unless you were to fall back on traditional asp/ActiveX type functionality.
.NET driven rich web apps online.
However,
2.0 absolutely changes this and is why we are just now beginning to see
No, I realize that. I'm generalizing on how asp, and recently, asp.net has been mostly used to produce rich intranet applications with ease.
Asp.net, and especially 2.0 have made huge advances in removing the ActiveX dependancies to allow for easier development of rich applications for the public internet.
Asp.net 2.0 is the first from MS to really provide the tools and controls to design richly featured websites from within their IDE (VS2005) using the provided toolset.
I've been doing the same for years, starting with traditional asp. However, it required doing all the complicated stuff by hand and from scratch. As such, it wasn't/isn't done a lot. It's a joke using VS2005. We will begin seeing more and more of these applications every day now.