Why would you loose customers? If you stick to the standards, your website will still be usable in IE6.
It might not look exactly the same way it does in a modern browser, but IE6 users have already shown they do not care about those things. You do, obviously, but you don't use IE6.
Just because it has users doesn't mean that you have to support it. Internet Explorer quickly rose in popularity in the first place because web developers blatantly stopped supporting Netscape, even though it had the majority market share at the time.
Futhermore, the thing to realize about IE6 users is that they do not care about the web. They don't care that your website has pixel-perfect accuracy, for instance. So why waste your time optimizing your website for their benefit? The natural degradation designed into the HTML specifications still allows them to access the content in a limited fashion. That is all that they want. If they wanted to see more, they wouldn't use IE6.
Not going to happen. Half of the apps I want to use are GTK, half QT.
The Mac is not a whole lot better. Half of the apps I want to use are Cocoa. A quarter of the apps I want to use are Qt. The other quarter are Carbon. Each of those toolkits have their own unique look and their own unique behaviors. Just try to use some of the somewhat hidden but incredibly useful features that all Cocoa applications get for free in a Carbon or Qt application, for example.
Such as selling additional merchandise related to your book. There are a million things you can capitalize on if you have the audience. Just think outside the box a little.
There's nothing stopping you from writing a book and selling it. Just don't expect anyone to buy it. If you want to turn a profit you have to look beyond the book itself.
We can debate about what is right and what is wrong all day long, but the fact is that this is the current marketplace an author has to work with. The point is that if your book is a success, there is still lots of money to be made beyond the book itself.
Better authors writing newer books realize that the book is not the product, but the marketing tool. If you have hundreds of thousands of people looking to download your book for free, you have yourself a huge captive audience to exploit in other ways. You do not need to sell the book itself to capitalize on your efforts.
From what I recall, people had to stop using Netscape 4 because many popular sites became IE-only (because of the prevalent use of ActiveX, among other things).
I live in "bufftuck nowhere" in Canada and have had high speed DSL out to the farm for nine years now. The only thing really holding back some parts of this country has been the result of copper ownership.
What America (and Canada, for that matter) needs to do is take the lines away from the companies who refuse to provide upgrades to rural customers. As observed in my area, smaller, independent phone comapnies/ISPs can be quite profitable with a focus on providing telecommunication services for rural customers. They just need the ability to provide upgrades to the existing infrastructure.
A hardware transition is a lot different than a software one. Windows, at one time, ran on a number of different types of processors so Microsoft is no stranger to the "FAT binary" concept.
Cocoa once had support for Java. Problem was that the static-typing of the language made UI development much more difficult than necessary. Objective-C, being dynamically typed, was the obvious choice for development. Java support was deprecated before OS X was rolled into the iPhone.
If Java was orders of magnatude easier to develop with as you claim, most Cocoa developers would have been already using Java and Java would have naturally been supported by Cocoa Touch.
Everyone knows that Ruby has performance issues. The fact is that the performance problems are not problems for short-lived operations like serving web pages. The article even backs up the claim.
Ruby scales just as well as every other language. The article never once claimed that Ruby does not scale. It claimed Ruby had performance problems; a topic mostly unrelated to scaling.
If Ruby users were in denial about the problems with Ruby, there would not be several projects working on solving the problems. However, like I mentioned above, just because a problem exists in one domain does not mean it exists in another. Ruby will scale and perform just fine under tasks the Ruby fanboys you refer to are using it for (like Rails applications).
Re:Should have used PHP.
on
Twitter On Scala
·
· Score: 4, Insightful
While Facebook uses PHP where Twitter uses Rails, Facebook uses a plethora of languages to make the whole system work. So Twitter really isn't going to Scala any more than Facebook is going to Erlang. Which is the say that they use the best tool for the job, not one tool for every job.
but it has failed several times in the past 6 months due it's low-level hardware usage, mainly in the area of networking.
What could you possibly be doing with a simple remote control app that wouldn't pass the Apple test? (Assuming that the application was well written so that it wasn't constantly crashing, etc.) Given that it is only using the public APIs, there isn't anything particularly "low level" that you are allowed to do with the hardware.
What is different is that it uses the Foundation library for the underlying implementation. i.e. a Ruby array maps to a NSArray, a Ruby string maps to a NSString, etc.
School is just another investment. You spend X number of dollars in hopes of making Y number of dollars later. If X plus the money and interest you could have made while in school exceeds Y, school was a terrible investment.
Since you are still in school, it is impossible for you to even venture a guess if the time has paid off.
What difference does it make if GET has an upper length limit? You're only requesting a short URI. When you are sending data you are using POST or PUT which do not have the same limits imposed on them.
The web browser is just another web service client. Slashdot is just another web service. The mere fact you were able to post your message shows that the model works just fine. Why add unnecessary complexity?
I'm sure you have some edge case waiting to point out where HTTP fails and SOAP does not. But just because SOAP is better suited for one out of every million projects, it does not mean that it is suitable for every project.
It comes down to using the right tool for the job. SOAP may have it's place, but if you're writing a quick CGI script to expose a web service like the article seems to imply, SOAP is most certainly not the right tool.
We know Apple were under tight time constraints with the iPhone. If it was between MMS or email, I think they made the right call. I believe MMS will come to the iPhone eventually, but they need to implement much, much more important features to implement first (i.e. Push).
And yes, the iPhone does need some way to share data between applications. But I think we will eventually see something more like the Services menu in OS X as opposed to copy and paste.
Slashdot Mirror
Having been on my fair share of gravel roads, it's the oncoming vehicles that tend to throw up stones at you, not the vehicles in front of you.
Hence the need for a 10,000-machine Hadoop cluster to do the work of a single machine running a C++ application. Or something like that.
Or he is assuming that the third party will receive 5000 votes.
It is something related to Javascript. When disabled, pages load an order of magnitude faster.
Through one of IE's numerous vulnerabilities?
Why would you loose customers? If you stick to the standards, your website will still be usable in IE6.
It might not look exactly the same way it does in a modern browser, but IE6 users have already shown they do not care about those things. You do, obviously, but you don't use IE6.
Just because it has users doesn't mean that you have to support it. Internet Explorer quickly rose in popularity in the first place because web developers blatantly stopped supporting Netscape, even though it had the majority market share at the time.
Futhermore, the thing to realize about IE6 users is that they do not care about the web. They don't care that your website has pixel-perfect accuracy, for instance. So why waste your time optimizing your website for their benefit? The natural degradation designed into the HTML specifications still allows them to access the content in a limited fashion. That is all that they want. If they wanted to see more, they wouldn't use IE6.
The Mac is not a whole lot better. Half of the apps I want to use are Cocoa. A quarter of the apps I want to use are Qt. The other quarter are Carbon. Each of those toolkits have their own unique look and their own unique behaviors. Just try to use some of the somewhat hidden but incredibly useful features that all Cocoa applications get for free in a Carbon or Qt application, for example.
Such as selling additional merchandise related to your book. There are a million things you can capitalize on if you have the audience. Just think outside the box a little.
There's nothing stopping you from writing a book and selling it. Just don't expect anyone to buy it. If you want to turn a profit you have to look beyond the book itself.
We can debate about what is right and what is wrong all day long, but the fact is that this is the current marketplace an author has to work with. The point is that if your book is a success, there is still lots of money to be made beyond the book itself.
Better authors writing newer books realize that the book is not the product, but the marketing tool. If you have hundreds of thousands of people looking to download your book for free, you have yourself a huge captive audience to exploit in other ways. You do not need to sell the book itself to capitalize on your efforts.
From what I recall, people had to stop using Netscape 4 because many popular sites became IE-only (because of the prevalent use of ActiveX, among other things).
We did get routing by carrier pigeon. And yes, sockets did handle it just fine.
http://www.blug.linux.no/rfc1149/
I live in "bufftuck nowhere" in Canada and have had high speed DSL out to the farm for nine years now. The only thing really holding back some parts of this country has been the result of copper ownership.
What America (and Canada, for that matter) needs to do is take the lines away from the companies who refuse to provide upgrades to rural customers. As observed in my area, smaller, independent phone comapnies/ISPs can be quite profitable with a focus on providing telecommunication services for rural customers. They just need the ability to provide upgrades to the existing infrastructure.
A hardware transition is a lot different than a software one. Windows, at one time, ran on a number of different types of processors so Microsoft is no stranger to the "FAT binary" concept.
I'm afraid history disagrees with you.
Cocoa once had support for Java. Problem was that the static-typing of the language made UI development much more difficult than necessary. Objective-C, being dynamically typed, was the obvious choice for development. Java support was deprecated before OS X was rolled into the iPhone.
If Java was orders of magnatude easier to develop with as you claim, most Cocoa developers would have been already using Java and Java would have naturally been supported by Cocoa Touch.
The judge drives like this.
The plaintiff drives like this.
The defendant drives like this.
"Lutz said the first-generation Volt will retail for about $40,000 and generate no profit for GM."
Everyone knows that Ruby has performance issues. The fact is that the performance problems are not problems for short-lived operations like serving web pages. The article even backs up the claim.
Ruby scales just as well as every other language. The article never once claimed that Ruby does not scale. It claimed Ruby had performance problems; a topic mostly unrelated to scaling.
If Ruby users were in denial about the problems with Ruby, there would not be several projects working on solving the problems. However, like I mentioned above, just because a problem exists in one domain does not mean it exists in another. Ruby will scale and perform just fine under tasks the Ruby fanboys you refer to are using it for (like Rails applications).
While Facebook uses PHP where Twitter uses Rails, Facebook uses a plethora of languages to make the whole system work. So Twitter really isn't going to Scala any more than Facebook is going to Erlang. Which is the say that they use the best tool for the job, not one tool for every job.
What could you possibly be doing with a simple remote control app that wouldn't pass the Apple test? (Assuming that the application was well written so that it wasn't constantly crashing, etc.) Given that it is only using the public APIs, there isn't anything particularly "low level" that you are allowed to do with the hardware.
What is different is that it uses the Foundation library for the underlying implementation. i.e. a Ruby array maps to a NSArray, a Ruby string maps to a NSString, etc.
School is just another investment. You spend X number of dollars in hopes of making Y number of dollars later. If X plus the money and interest you could have made while in school exceeds Y, school was a terrible investment.
Since you are still in school, it is impossible for you to even venture a guess if the time has paid off.
The web browser is just another web service client. Slashdot is just another web service. The mere fact you were able to post your message shows that the model works just fine. Why add unnecessary complexity?
HTTP?
I'm sure you have some edge case waiting to point out where HTTP fails and SOAP does not. But just because SOAP is better suited for one out of every million projects, it does not mean that it is suitable for every project.
It comes down to using the right tool for the job. SOAP may have it's place, but if you're writing a quick CGI script to expose a web service like the article seems to imply, SOAP is most certainly not the right tool.
We know Apple were under tight time constraints with the iPhone. If it was between MMS or email, I think they made the right call. I believe MMS will come to the iPhone eventually, but they need to implement much, much more important features to implement first (i.e. Push).
And yes, the iPhone does need some way to share data between applications. But I think we will eventually see something more like the Services menu in OS X as opposed to copy and paste.