I think the problem is that read/write heads are orders of magnitude larger than the real estate consumed by a single bit. There's thousands and thousands of tracks across the radius of a disk and enough room for only 40 or 50 read heads on the same disk. I think you'd get more storage out of solid state memory such as a usb thumb drive.
Plus it still needs to spin the disk to put the data under those heads, so although you would save seek time you'd still pay for latency which is always averaged out to half the rotational period of the disk (between 4.1 and 5.5 ms on most modern disks).
Although I agree with the idea that IT exists to satisfy the needs of the users, IT also exists to assist users fulfill the needs of the organization.
There are a number of problems with using email as a file storage technique that are *unrelated* to the technical details of email storage and the like, but instead are a result of the nature of email.
For example, although using email as the storage mechanism provides a sort of version history for a given file, it fails to provide a mechanism for the authoritative copy of that file. So although the version you have in your email was current when you received it, you don't have any way to find out if someone else has made changes to the file and failed to provide you with a new copy of it.
If the user(s) who controlled the file leave the company, their replacement(s) have *no* way to get the most recent version of that file. I.T. might be able to dig this out of the previous controllers' email accounts, but it's a time consuming process and not necessarily guaranteed to provide accurate results since they don't understand the surrounding issues (for example, has ownership of the file currently been handed off to a third party).
Aside from issues with detection of the most recent version, there are other issues, such as that every version of the file has multiple copies being retained for each applicable party. If I share a file with my 20 person department, the storage for this is at a minimum of 20 times larger than the storage if an *appropriate* mechanism is used.
Further, users will not clean up old email data unless they are forced to. This includes data that is trash data. For example, that 6 mb video forward that's been going around, or the 30 jokes the user received today. These are things that aren't going to go on a file server.
Email quotas in a corporation exist for a reason: to require users to exercise good file management practices. They're not just I.T. arbitrarily deciding to prevent evolution of email usage.
Email works excellently as a file storage mechanism when only one or two people are going to be using that file, and when those users either will never leave the company / change positions, or when their leaving their position invalidates the usefulness of that file. And although such situations exist in every day business practices, those situations also evolve themselves into the sort of situation which email is poorly suited to manage, usually with out the user being aware that that evolution has happened.
Hence it's better to encourage users to use tools which *are* appropriately suited by their very nature to the actual problems which the users are attempting to resolve.
I wish I had one, perhaps I should actually *write* one. We figured out most of the Ajax methodology ourselves, as I mentioned we were doing this stuff before Gmail & the term "Ajax" came along.
The basic overview is that you have various
's on your page with ID attributes. You create a wrapper function (eg, ajax(function,arguments,onReturn)) which makes a call with the XMLHttpRequest object back to your server, passing the function and arguments. On the server, the function does its processing (you need to make SURE that only functions you expect to be called directly by users can be called through this script). The server side function gets its results ready and hands them back to the server side Ajax script, which formats it as XML and sends it back. Back on the client end, the onReturn code executes across the result data, creating HTML out of the XML being sent, and putting this HTML into the appropriate
on the page.
Only the portion of the page that needs to change actually changes, the user never reloads anything else. Because this happens asynchronously, multiple operations can happen in parallel and the user can continue to interact with the rest of the page while their operation performs in the background.
Imagine looking at a product listing on an ecommerce site. You can click "Add To Cart" next to each item on the page in rapid succession. You don't have to wait for each adding to successfully register, you click "Add" and it immediately appears in the shopping cart, with perhaps an indicator that the add is still taking place (italicise the text of the product name, for example, and unitalicize it when the add is done).
The reason why it's a paradigm shift is that this makes the web page behave much more like a desktop application, but it can be more responsive than some desktop apps I've seen which are not capable of parallel operations like this (while processing an action, no further actions can happen). The web developer works only with individual page parts, and they don't have to worry about what else should be displayed on the page. You've already sent data to the client about the user's personal information (login name, view preferences, and such), there's no need to re-send this the next time the user clicks on a link. You get to preserve the state of previous page hits.
There's no longer a model of pages, it's a functional model. Individual layouts happen as a page hit, everything else is a function call. That function returns raw data and the client lays it out. All formatting is client side, and this combined with the fact that you're only building the portions of pages that changed leads to greatly reduced server loads.
But most importantly of all, the user never ever waits on the server to respond unless they either need confirmation that the operation has happened, or they are depending on the results of that response for their next operation (eg, when you do a search for a given product, you have to wait for the server to give you that product listing before you can add it to your cart).
Unless you're foolish about it, the XML data is anywhere from 2/3 smaller to 3/4 smaller than equivalent HTML.
There's no need to send back javascript code to do evals, this cannot possibly be more efficient than good XML. The client loads the javascript necessary to interpret the XML into HTML (depending on the complexity of the site, my experience shows that this will be between 10k and 30k) up front. I know Gmail is much larger than this, and I can't really speak to that, but as I understand it, some other folks have mentioned that they think it's pretty poorly designed from a filesize efficiency standpoint.
We set up multiple channels for data to come back. If you *do* need javascript on the client side, and you don't want that to be loaded initially (eg, form validation code), you can send it across the <script/> channel. Content comes across the <content/> channel, and doesn't contain HTML markup, just data that's formatted by the client script into HTML, server side errors come across the <error/> channel, and raw data (for use in scripts or graphs and the like) comes across on the <data/> channel.
We keep track of which client side scripts have already been sent in the user's session (each function is sent atomically, though multiple functions might come across on the same response), and only send any one function exactly one time to the client unless they reload their page (when we clear which scripts we have sent them since their client has lost those scripts with the reload).
Because all these scripts come through the XML channel, we also run them through a simple javascript compression algorithm (renames variables and functions from descriptive names to a, b, c... aa, ab, ac, etc, removes comments, and strips extra whitespace). We still get to work on the script in formatted, commented, descriptive glory, but the user gets the actual data being loaded cut way back.
As I said in my parent comment, most responses fall below 1000 bytes, and fit within a single TCP packet; even if your eval(XMLHttpRequest.responseText) managed to shave a few bytes off, it wouldn't actually make any impact whatsoever on the load time of the response.
You see, we do make it possible to send back javascript for eval, but we don't try to mung our display data into javascript for this purpose, and we're not so narrow minded as to put a single type of data or a single piece of data in any given Ajax response.
I can see your point about XML verbosity if we were using something as verbose as SOAP and WSDL, but those carry additional functionality that we don't need: they have to describe their API, while we control both ends since it's the same product, and so all the SOAP descriptiveness is unnecessary.
Just for your own edification, here is a sample of our test form from our latest project, it's slightly formatted because it's copied out of Mozilla, there are no newlines or extra spaces in the actual source: <i>Well, I *was* going to put it here, but apparently I "violated the 'postercomment' compression filter. Try less whitespace and/or less repetition. Comment aborted."</i>
This generates 7528 bytes of HTML, but it is only 2606 bytes of XML data for the user to download, a savings of basically 2/3. This form is larger and more complex than most forms on our site, and still it only needs 2 TCP packets.
Just because other people implement it poorly doesn't mean there isn't a correct way to implement it. I was speaking specifically to people who said, "Don't use Ajax, because it has cross browser implications." It does, but they're meaningless because every modern browser supports it, and a simple compatibility layer handles it just fine.
Use the.responseXML property, which is a parsed DOM document of the response XML. Iterate across DOM members here and build your page from that. You don't want to send HTML back and access it via.responseText, you want to send back bare bones (just the data), and do all the translation of that to HTML on the client side. This can save 2/3 to 3/4 of the data transfer.
Yes, responseXML is the correct place to access it, it's a DOM document.
And you're right about not trusting the data from the client, you still want to check this all server side, but you *also* do client side checking so that the user gets immediate feedback on the validity of their data. Serverside you can just abort with out having to try to deliver back a message (or you can deliver back a message in case you think that your server checks and client checks might be out of sync).
Oh, and getting all the Slashdot pundits on their soap boxes, preaching about technologies they don't really understand, and making dire predictions about the unworthiness of the tech.
Seriously, being someone who actually has quite a bit of *real* experience with Ajax (though we were doing it before the term was coined) across multiple browsers, I can say that the ratio of comments which demonstrate the author understands the full implications of Ajax to those who are just spouting nonsense is about 1:75. I've never read an article on Slashdot before where so many comments missed the target, and I feel like I've been around Slashdot for a little while.
The idea behind Ajax *does* revolutionize the web paradigm. All this nonsense about cross browser compatability issues is just that: nonsense; it works in Mozilla, Firefox, IE, Opera, and Konqueror each on their respective available platforms. I've actually heard people talking about "Ajax enabled advertisements instead of Flash." Other gems like "Ajax doesn't do anything that a well programmed web application can't do," and "It's just needlessly complex web pages" only point to users who fail to grasp the fundamental concept.
Let me tell you: Ajax is FAST. You don't realize how unresponsive web pages are until you get to play with a web app that is always waiting on you, no the other way around. When I submit information, why do I need to wait for that information to get to the server before I can begin to perform another operation if that operation isn't dependant on the previous? Click Add To Cart then *immediately* start searching for the next item. Stuff like that.
The amount of data being exchanged is far less (if you do it RIGHT, you people who are talking about using the XMLHttpRequest.responseText property, this does NOT include you). Rather than reload an entire page with all the framework, you're loading only the portion of the page that changed.
Aside from piecemeal page loading, you also get to load only the relevant data. For example, rather than load a form, and all the form formatting to make the text fields line up correctly, and all the validation code to validate that form, you load a series of XML tags that contain only the basic information needed to tell the client how to lay out the form. The client takes care of generating the HTML for the form, and your form data looks more like this: <input name="username" label="User Name" required="yes" minlength="5" maxlength="10"/> versus <tr class="lightRow"><td class="labelColumn"><label for="username">User Name:</label></td><td class="inputColumn"><input id="username" name="username" maxlength="10"></td></tr> , then later form validation code.
Often times your data fits inside a single TCP packet.
I'll make this concession: yes, this is stuff that could be done before the Ajax philosophy using Flash or Java Applets. But both require a plugin, and one of them is even proprietary. Both have potential firewall issues, and neither will run on a vanilla Fedora Core build. Both require higher resource consumption for the user, and both lend to a feeling of sluggishness on the site for the user.
That's not to say that it's not without its dangers. Like all web apps, you can't trust the data from the client. Here the client gets a bit lower level access to the data. You still have to make sure that you're protecting yourself well against data poisoning attacks.
The thing I like most about this model though is this: It's truly a MVC (Model View Controller) framework.
The model is of course your server side logic scripts. The View is the browser (the server side logic scripts send back generically formatted data, the browser does all the display). The Controller is the combination of XMLHttpRequest object, and the processing management script on the server. It's very conceivable that you could write a new front end for your application by simply
But Netflix gets to save on shipping by doing a bulk shipping daily or weekly. Wal*mart gets extra income from people who come in for the movie and get attracted by other stuff (games, munchies).
My reasons for not using opera: o Non-free (ok, an ad banner isn't too tough to cope with) o Lack of NTLM negotiation (all corp sites are inaccessible, *including* our dev boxes) o Lack of Socks proxy option (I tunnel socks outbound from work over SSH to protect my network traffic)
Things that make me wish I could use Opera: o Excellent CSS support o That awesome zoom (that zooms the images too) o Ability to edit cookies in the UI (used for testing, honest -- I'm a web developer)
And a lot more than 10! Hundreds. Perhaps as many as several every day. It's job justification, and if I were in their shoes, I'd be finding articles that agree with my point of view and buying them, because that's how you don't get fired as a technology decision maker, when something goes wrong. You point to the "industry experts" who recommended the path you went down, and then your bosses (/C[EITF]O/) are satisfied that you acted with due process.
Out of touch corporate decision makers buy this sort of crap all the time. What's sad is that 9 times out of 10, these articles say essentially, "You shouldn't do this because it's scary." The decision makers listen to this, and the company stays stagnant.
You can certainly try your site, but unless you put the articles up in the name of a huge consulting / research firm, you're not going to get anyone to buy them. The market for this type of article has millions of corporate dollars to spend, and they need to be able to justify their mistakes by pointing to "trustworthy" research like these articles. They're not going to take your word on it, you don't have the name recognition that will save their ass.
And when you're considering a rollout that might cost a large company 5-6 million dollars, $50 is quite easy to justify for a little advice.
IMO, the reason these type of articles tend to say, "Keep doing what you're currently doing, and avoid this new tech" is because that's almost always a safe road for any tech that doesn't promise to make a company money or bring significant competetive advantage.
What strikes me from the post is this sentence: The V-6 Honda Accord Hybrid delivers 30 miles per gallon.
My Ford Contour gets about 35mpg average and isn't a hybrid. Sounds like it's better for the environment not just for oil consumption, but also because it doesn't have the issue of disposing of old batteries.
Once you give notice, they are not required to let you stay on for the duration of your notice, they don't even have to let you stay on any longer than is necessary to clean out your desk and escort you out the door.
If you give notice, and expect to take 2 weeks of vacation during that notice, they can simply terminate you now rather than in 2 weeks. Hence you don't get paid for that vacation unless they elect to let you.
I think it was pretty reasonable of them to offer to give you that time as vacation at all, especially for so little a thing as doing an exit interview. You might even have been able to swing that on the phone, but even if not, it's not unreasonable for them to want information from you as to why you're leaving the company, etc. Even if they should have known it, the "Current employee grievances" file is a different one from the "Grievances that caused employees to quit" file, and the latter will be taken much MUCH more seriously. People like to whine about their jobs (I do it, and I think I have a good job), but when they take specific action based on those complaints, it sends a much stronger message.
By refusing the exit interview, you lost an excellent opportunity to help prevent your boss from being able to abuse someone else.
In college, the professor who generated the highest level of respect from me out of all the professors I worked with was my chemistry prof (I was computer science).
Aside from obviously being intelligent, very well spoken but generating only statements that even folks with weak vocabulary could understand, having incredible enunciation (Sri-lankan by birth, raised in England gave him what I would term *perfect* enunciation), he had very well defined roles in his life for his work and his religion.
He was Christian, devoutly so (not in a wierd way but perfectly willing to defend his belief to any and all who were willing to challenge him on it). He didn't preach to us, and in fact, in the 3 semesters I spent in his classes, he only ever once mentioned his faith.
He did it something like this: "The topics we are about to cover may disagree with your personal or religious beliefs. We do not go into these topics in order to challenge your beliefs, rather we act in a truly scientific nature by treating them as an acting theory. Acting theories are treated as possibly being truth in our evaluation of them, even when there are conflicting theories. In these cases, both theories are treated as truth, and both theories are evaluated to their fullest until one or both are clearly defeated with empirical evidence.
"I am a Christian by belief. I treat creationism as truth, and I treat evolution as truth, both within the limits of recognizing them as theory.
"Understand that in the debate of creationism versus evolution, mankind will never be able to definitively disprove either one. We cannot observe how the universe was created, hence we have no empirical evidence of the method, and hence evolution, whether or not it is true, cannot be absolutely proved. Likewise, at the heart of creationism is a fundamental premesis of an omnipotent being. If such a being exists, then no matter how much evidence is discovered for evolution, this being could always have created this evidence.
"The Christian God demands that people believe in him by faith. Although He could offer compelling physical evidence of his presence by spelling 'God created you, evolution is false' in the stars, doing so would defeat His desire to be believed in through faith. If He exists, and our understanding of Him is accurate, then He will never prove Himself in this way.
"The debate of creationism versus evolution is stale mated. Discussing the merits of creationism versus the merits of evolutionism is outside the scope of this class. There may be courses on this in the Philosophy department, I'm not sure. Also, discussing the attributes of creationism falls outside the scope of this class, and is best left to clergy.
"If anyone wants to discuss it with me personally, you know my office hours, and I would be more than happy to do so.
"So all of that pretext aside, let's discuss the attributes of chemistry that pertain to the theory of evolution."
I think the problem in public schools is that a discussion like this doesn't happen in most schools. This is what gets Christians upset. Evolution often isn't even referred to as a theory. In my high school, it was "Evolution" and "The theory of relativity." The word theory and the word evolution never occurred in proximity. This is actually bad science even if you are willing to completely discount the existance of a contrary theory. Public schools don't tend to leave evolutionism open ended or leave any doubt as to their certainty of the theory. Probably mostly because this finesse is past the ability of most high school teachers, who were never trained for it.
Speaking directly to your comments about the two theories co-existing, the reason this isn't acceptable to most Christians is because the Bible says differently, and Christians accept the Bible as direct unflawed communication from God.
Personally, I'm Christian, but I don't view the Bible that way, for the sole reason that man is who wrote it. Because
No kidding, they can put one in my back yard for $28k per year too! They can even use my daughter's bedroom as the control center (not really, that's a Simpson's reference).
$28k will cover or exceed most people's mortgages! I wouldn't mind being shunned in the community when I'm using $20 bills for toilet paper.
Good call, maybe we should just put a $1,000 levy on all personal computer purchases to cover the cost of pirated software too, eh?
Maybe your car should come with a $40,000 levy to cover the cost of uninsured drivers.
Re:Just a proposal, hopefully...
on
Dutch Pass iPod Tax
·
· Score: 5, Insightful
I'd completely go for the iPod tax.
Now I've paid for music, it's no longer illegal for me to go out and download it.
I know that's not really how it'll work legally, but I've always strongly felt that if any standard tax is passed on devices for listening to music, then anyone in possession of such devices are free to access all the music with out limit. Why else have a tax if not to remove the individual purchase rate.
I'd gladly give up $200 one-time for indefinate no-further-charge unlimited access to all the RIAA (or whatever it is in the Netherlands) music.
All that said, it is a mockery of justice to have ANY corporation able to levy a tax on citizens for any reason. If this was a tax so the government could afford to cover the legal costs that *it* is incurring, then it falls well within what most standard taxes are for. But if it's a tax that presumes purchasers of a consumer device are going to use it for illegal ends, and compensate the, erm, "victims" in advance, then you've just created a "Guilty until proven innocent" model.
Personally I have a 40g iPod which is about 2/3 full. Every single bit of data on it is something which I have a right to place there. I do believe in paying for music (though actually most of what I have on there is audio books -- which I've paid for). This sort of law would charge people like me, who are wholly operating within our rights within the law, for the crimes of others, with the presumption that I'm too weak minded to resist the temptation to break the law.
He probably means that it can be performed on the chip in a single operation. More registers means higher possible complexity of result for a single operation.
Yes, the AMD can do it too, but it requires multiple operations on the chip to come to the same result.
This is of course only an example, I'm not familiar with either chip's instruction set, it's just a way that I can imagine the superiority of one over the other. I still don't like macs:-)
Am I the only one who noticed that there were sound effects in space? I really hope this is only in the trailer, and that the actual movie stays true to the series by removing the sound effects from the space scenes.
It was the first space scene sans engine noises, that first completely hooked me on Firefly. I couldn't believe someone writing sci-fi actually obeyed the laws of physics in this sense. And the soundlessness of it, filled instead with that guitar drawl, really lent a feeling of surrealness, and in fact, I thought it made space seem like a lot scarier place than any other sci-fi had ever managed -- the thought of being stranded out there, in utter silence, alone and forever, really got me.
Believe it or not, but there are some parents who know more about computers than their children. We call them things like "Network Administrator" or "Software Developer."
Every time software or legal initiatives come along that might provide parents greater control over their kids lives, standard Slashdot hubris receives the most mod points. "Instead of giving parents this tool, the parents should just be good parents." Things like these are tools that help to *enable* parents to be good parents.
Anyone who thinks they can watch their kids all of the time is either naieve, has never been a parent, or is simply completely smothering their children.
Tools like this enable parents to put a line in the sand. Perhaps little Timmy does know more about computers than you, and perhaps little Timmy also knows how to open the cookie jar when you're not looking. The point is that you've laid a line in the sand of what you as a parent believe is wrong. If you catch Timmy playing GTA:XXX when you specifically blocked that sort of game, then you have tremendous resource. Personally, what I'd do is confiscate the computer for a few weeks, or otherwise completely remove access.
You have to give your children leeway to discover who they are as individuals, but you also need to raise caution barriers in areas that you as parent deem to be detrimental to your children's well being.
I personally think that games like GTA warp a child's sense of right and wrong, at least up to a certain developmental stage. You're free to disagree with me on that (someone always does, even if it's not you specifically), but it's my perogative to believe that, and it's my perogative to raise my children that way no matter how sheltered some standard Slashdot readers may think my children will be.
Tools like this allow me to define to my child, with out any ambiguity, what I think are right and wrong for him or her to do. Even if my child circumvents that caution barrier, the message is still successfully communicated, without little Timmy having to wonder, "Is raping a hooker a good thing or a bad thing?" When little Timmy borrows a game from a buddy, he will know when he sticks it in the computer that it's a bad thing, before he even plays or perhaps installs the game.
Also, I really like the idea of time limiting game play. You can play video games for two hours today, but then you have to do something else that's either more mentally stimulating (playing with lego's, drawing a picture), or more physically stimulating (exercise, playing with other children). I don't have to worry about doing the accounting, I can focus on living my life with my child. Heck, I'd like that ability for myself, I know I can get absorbed into something, and 4 hours rolls by before I know it.
Slashdot Mirror
But if you're doing scrolling with the keyboard, you're now performing an analog operation with the keyboard, which is a digital input device.
Seems like idle time would be short for that operation, but that "time to navigate" would be faster to use a mouse.
It'd be interesting to see some real timed results of people accustomed to your method navigating a given link on a website vs someone using a mouse.
How well does this work for repeated links (such as "Reply to This" here in the comment thread)?
I use my keyboard for a lot of things that others use a mouse for, but choosing links on a web page isn't included in this.
I think the problem is that read/write heads are orders of magnitude larger than the real estate consumed by a single bit. There's thousands and thousands of tracks across the radius of a disk and enough room for only 40 or 50 read heads on the same disk. I think you'd get more storage out of solid state memory such as a usb thumb drive.
Plus it still needs to spin the disk to put the data under those heads, so although you would save seek time you'd still pay for latency which is always averaged out to half the rotational period of the disk (between 4.1 and 5.5 ms on most modern disks).
Although I agree with the idea that IT exists to satisfy the needs of the users, IT also exists to assist users fulfill the needs of the organization.
There are a number of problems with using email as a file storage technique that are *unrelated* to the technical details of email storage and the like, but instead are a result of the nature of email.
For example, although using email as the storage mechanism provides a sort of version history for a given file, it fails to provide a mechanism for the authoritative copy of that file. So although the version you have in your email was current when you received it, you don't have any way to find out if someone else has made changes to the file and failed to provide you with a new copy of it.
If the user(s) who controlled the file leave the company, their replacement(s) have *no* way to get the most recent version of that file. I.T. might be able to dig this out of the previous controllers' email accounts, but it's a time consuming process and not necessarily guaranteed to provide accurate results since they don't understand the surrounding issues (for example, has ownership of the file currently been handed off to a third party).
Aside from issues with detection of the most recent version, there are other issues, such as that every version of the file has multiple copies being retained for each applicable party. If I share a file with my 20 person department, the storage for this is at a minimum of 20 times larger than the storage if an *appropriate* mechanism is used.
Further, users will not clean up old email data unless they are forced to. This includes data that is trash data. For example, that 6 mb video forward that's been going around, or the 30 jokes the user received today. These are things that aren't going to go on a file server.
Email quotas in a corporation exist for a reason: to require users to exercise good file management practices. They're not just I.T. arbitrarily deciding to prevent evolution of email usage.
Email works excellently as a file storage mechanism when only one or two people are going to be using that file, and when those users either will never leave the company / change positions, or when their leaving their position invalidates the usefulness of that file. And although such situations exist in every day business practices, those situations also evolve themselves into the sort of situation which email is poorly suited to manage, usually with out the user being aware that that evolution has happened.
Hence it's better to encourage users to use tools which *are* appropriately suited by their very nature to the actual problems which the users are attempting to resolve.
Wrong, any users can *connect* to privileged ports, only privileged users can *listen* (accept connections) on privileged ports.
Otherwise you'd have to be root to use Thunderbird to send an email to an outside server.
I wish I had one, perhaps I should actually *write* one. We figured out most of the Ajax methodology ourselves, as I mentioned we were doing this stuff before Gmail & the term "Ajax" came along.
The basic overview is that you have various 's on your page with ID attributes. You create a wrapper function (eg, ajax(function,arguments,onReturn)) which makes a call with the XMLHttpRequest object back to your server, passing the function and arguments. On the server, the function does its processing (you need to make SURE that only functions you expect to be called directly by users can be called through this script). The server side function gets its results ready and hands them back to the server side Ajax script, which formats it as XML and sends it back. Back on the client end, the onReturn code executes across the result data, creating HTML out of the XML being sent, and putting this HTML into the appropriate on the page.
Only the portion of the page that needs to change actually changes, the user never reloads anything else. Because this happens asynchronously, multiple operations can happen in parallel and the user can continue to interact with the rest of the page while their operation performs in the background.
Imagine looking at a product listing on an ecommerce site. You can click "Add To Cart" next to each item on the page in rapid succession. You don't have to wait for each adding to successfully register, you click "Add" and it immediately appears in the shopping cart, with perhaps an indicator that the add is still taking place (italicise the text of the product name, for example, and unitalicize it when the add is done).
The reason why it's a paradigm shift is that this makes the web page behave much more like a desktop application, but it can be more responsive than some desktop apps I've seen which are not capable of parallel operations like this (while processing an action, no further actions can happen). The web developer works only with individual page parts, and they don't have to worry about what else should be displayed on the page. You've already sent data to the client about the user's personal information (login name, view preferences, and such), there's no need to re-send this the next time the user clicks on a link. You get to preserve the state of previous page hits.
There's no longer a model of pages, it's a functional model. Individual layouts happen as a page hit, everything else is a function call. That function returns raw data and the client lays it out. All formatting is client side, and this combined with the fact that you're only building the portions of pages that changed leads to greatly reduced server loads.
But most importantly of all, the user never ever waits on the server to respond unless they either need confirmation that the operation has happened, or they are depending on the results of that response for their next operation (eg, when you do a search for a given product, you have to wait for the server to give you that product listing before you can add it to your cart).
Unless you're foolish about it, the XML data is anywhere from 2/3 smaller to 3/4 smaller than equivalent HTML.
... aa, ab, ac, etc, removes comments, and strips extra whitespace). We still get to work on the script in formatted, commented, descriptive glory, but the user gets the actual data being loaded cut way back.
There's no need to send back javascript code to do evals, this cannot possibly be more efficient than good XML. The client loads the javascript necessary to interpret the XML into HTML (depending on the complexity of the site, my experience shows that this will be between 10k and 30k) up front. I know Gmail is much larger than this, and I can't really speak to that, but as I understand it, some other folks have mentioned that they think it's pretty poorly designed from a filesize efficiency standpoint.
We set up multiple channels for data to come back. If you *do* need javascript on the client side, and you don't want that to be loaded initially (eg, form validation code), you can send it across the <script/> channel. Content comes across the <content/> channel, and doesn't contain HTML markup, just data that's formatted by the client script into HTML, server side errors come across the <error/> channel, and raw data (for use in scripts or graphs and the like) comes across on the <data/> channel.
We keep track of which client side scripts have already been sent in the user's session (each function is sent atomically, though multiple functions might come across on the same response), and only send any one function exactly one time to the client unless they reload their page (when we clear which scripts we have sent them since their client has lost those scripts with the reload).
Because all these scripts come through the XML channel, we also run them through a simple javascript compression algorithm (renames variables and functions from descriptive names to a, b, c
As I said in my parent comment, most responses fall below 1000 bytes, and fit within a single TCP packet; even if your eval(XMLHttpRequest.responseText) managed to shave a few bytes off, it wouldn't actually make any impact whatsoever on the load time of the response.
You see, we do make it possible to send back javascript for eval, but we don't try to mung our display data into javascript for this purpose, and we're not so narrow minded as to put a single type of data or a single piece of data in any given Ajax response.
I can see your point about XML verbosity if we were using something as verbose as SOAP and WSDL, but those carry additional functionality that we don't need: they have to describe their API, while we control both ends since it's the same product, and so all the SOAP descriptiveness is unnecessary.
Just for your own edification, here is a sample of our test form from our latest project, it's slightly formatted because it's copied out of Mozilla, there are no newlines or extra spaces in the actual source:
<i>Well, I *was* going to put it here, but apparently I "violated the 'postercomment' compression filter. Try less whitespace and/or less repetition. Comment aborted."</i>
This generates 7528 bytes of HTML, but it is only 2606 bytes of XML data for the user to download, a savings of basically 2/3. This form is larger and more complex than most forms on our site, and still it only needs 2 TCP packets.
Just because other people implement it poorly doesn't mean there isn't a correct way to implement it. I was speaking specifically to people who said, "Don't use Ajax, because it has cross browser implications." It does, but they're meaningless because every modern browser supports it, and a simple compatibility layer handles it just fine.
Use the .responseXML property, which is a parsed DOM document of the response XML. Iterate across DOM members here and build your page from that. You don't want to send HTML back and access it via .responseText, you want to send back bare bones (just the data), and do all the translation of that to HTML on the client side. This can save 2/3 to 3/4 of the data transfer.
Yes, responseXML is the correct place to access it, it's a DOM document.
And you're right about not trusting the data from the client, you still want to check this all server side, but you *also* do client side checking so that the user gets immediate feedback on the validity of their data. Serverside you can just abort with out having to try to deliver back a message (or you can deliver back a message in case you think that your server checks and client checks might be out of sync).
Oh, and getting all the Slashdot pundits on their soap boxes, preaching about technologies they don't really understand, and making dire predictions about the unworthiness of the tech.
Seriously, being someone who actually has quite a bit of *real* experience with Ajax (though we were doing it before the term was coined) across multiple browsers, I can say that the ratio of comments which demonstrate the author understands the full implications of Ajax to those who are just spouting nonsense is about 1:75. I've never read an article on Slashdot before where so many comments missed the target, and I feel like I've been around Slashdot for a little while.
The idea behind Ajax *does* revolutionize the web paradigm. All this nonsense about cross browser compatability issues is just that: nonsense; it works in Mozilla, Firefox, IE, Opera, and Konqueror each on their respective available platforms. I've actually heard people talking about "Ajax enabled advertisements instead of Flash." Other gems like "Ajax doesn't do anything that a well programmed web application can't do," and "It's just needlessly complex web pages" only point to users who fail to grasp the fundamental concept.
Let me tell you: Ajax is FAST. You don't realize how unresponsive web pages are until you get to play with a web app that is always waiting on you, no the other way around. When I submit information, why do I need to wait for that information to get to the server before I can begin to perform another operation if that operation isn't dependant on the previous? Click Add To Cart then *immediately* start searching for the next item. Stuff like that.
The amount of data being exchanged is far less (if you do it RIGHT, you people who are talking about using the XMLHttpRequest.responseText property, this does NOT include you). Rather than reload an entire page with all the framework, you're loading only the portion of the page that changed.
Aside from piecemeal page loading, you also get to load only the relevant data. For example, rather than load a form, and all the form formatting to make the text fields line up correctly, and all the validation code to validate that form, you load a series of XML tags that contain only the basic information needed to tell the client how to lay out the form. The client takes care of generating the HTML for the form, and your form data looks more like this:
<input name="username" label="User Name" required="yes" minlength="5" maxlength="10"/>
versus
<tr class="lightRow"><td class="labelColumn"><label for="username">User Name:</label></td><td class="inputColumn"><input id="username" name="username" maxlength="10"></td></tr>
, then later form validation code.
Often times your data fits inside a single TCP packet.
I'll make this concession: yes, this is stuff that could be done before the Ajax philosophy using Flash or Java Applets. But both require a plugin, and one of them is even proprietary. Both have potential firewall issues, and neither will run on a vanilla Fedora Core build. Both require higher resource consumption for the user, and both lend to a feeling of sluggishness on the site for the user.
That's not to say that it's not without its dangers. Like all web apps, you can't trust the data from the client. Here the client gets a bit lower level access to the data. You still have to make sure that you're protecting yourself well against data poisoning attacks.
The thing I like most about this model though is this: It's truly a MVC (Model View Controller) framework.
The model is of course your server side logic scripts. The View is the browser (the server side logic scripts send back generically formatted data, the browser does all the display). The Controller is the combination of XMLHttpRequest object, and the processing management script on the server. It's very conceivable that you could write a new front end for your application by simply
But Netflix gets to save on shipping by doing a bulk shipping daily or weekly. Wal*mart gets extra income from people who come in for the movie and get attracted by other stuff (games, munchies).
My reasons for not using opera:
o Non-free (ok, an ad banner isn't too tough to cope with)
o Lack of NTLM negotiation (all corp sites are inaccessible, *including* our dev boxes)
o Lack of Socks proxy option (I tunnel socks outbound from work over SSH to protect my network traffic)
Things that make me wish I could use Opera:
o Excellent CSS support
o That awesome zoom (that zooms the images too)
o Ability to edit cookies in the UI (used for testing, honest -- I'm a web developer)
Not me :-)
And a lot more than 10! Hundreds. Perhaps as many as several every day. It's job justification, and if I were in their shoes, I'd be finding articles that agree with my point of view and buying them, because that's how you don't get fired as a technology decision maker, when something goes wrong. You point to the "industry experts" who recommended the path you went down, and then your bosses (/C[EITF]O/) are satisfied that you acted with due process.
Out of touch corporate decision makers buy this sort of crap all the time. What's sad is that 9 times out of 10, these articles say essentially, "You shouldn't do this because it's scary." The decision makers listen to this, and the company stays stagnant.
You can certainly try your site, but unless you put the articles up in the name of a huge consulting / research firm, you're not going to get anyone to buy them. The market for this type of article has millions of corporate dollars to spend, and they need to be able to justify their mistakes by pointing to "trustworthy" research like these articles. They're not going to take your word on it, you don't have the name recognition that will save their ass.
And when you're considering a rollout that might cost a large company 5-6 million dollars, $50 is quite easy to justify for a little advice.
IMO, the reason these type of articles tend to say, "Keep doing what you're currently doing, and avoid this new tech" is because that's almost always a safe road for any tech that doesn't promise to make a company money or bring significant competetive advantage.
It's a 91 LE I think. Only 4 cylindars, so that probably explains the difference between mine and yours.
What strikes me from the post is this sentence: The V-6 Honda Accord Hybrid delivers 30 miles per gallon.
My Ford Contour gets about 35mpg average and isn't a hybrid. Sounds like it's better for the environment not just for oil consumption, but also because it doesn't have the issue of disposing of old batteries.
Once you give notice, they are not required to let you stay on for the duration of your notice, they don't even have to let you stay on any longer than is necessary to clean out your desk and escort you out the door.
If you give notice, and expect to take 2 weeks of vacation during that notice, they can simply terminate you now rather than in 2 weeks. Hence you don't get paid for that vacation unless they elect to let you.
I think it was pretty reasonable of them to offer to give you that time as vacation at all, especially for so little a thing as doing an exit interview. You might even have been able to swing that on the phone, but even if not, it's not unreasonable for them to want information from you as to why you're leaving the company, etc. Even if they should have known it, the "Current employee grievances" file is a different one from the "Grievances that caused employees to quit" file, and the latter will be taken much MUCH more seriously. People like to whine about their jobs (I do it, and I think I have a good job), but when they take specific action based on those complaints, it sends a much stronger message.
By refusing the exit interview, you lost an excellent opportunity to help prevent your boss from being able to abuse someone else.
In college, the professor who generated the highest level of respect from me out of all the professors I worked with was my chemistry prof (I was computer science).
Aside from obviously being intelligent, very well spoken but generating only statements that even folks with weak vocabulary could understand, having incredible enunciation (Sri-lankan by birth, raised in England gave him what I would term *perfect* enunciation), he had very well defined roles in his life for his work and his religion.
He was Christian, devoutly so (not in a wierd way but perfectly willing to defend his belief to any and all who were willing to challenge him on it). He didn't preach to us, and in fact, in the 3 semesters I spent in his classes, he only ever once mentioned his faith.
He did it something like this: "The topics we are about to cover may disagree with your personal or religious beliefs. We do not go into these topics in order to challenge your beliefs, rather we act in a truly scientific nature by treating them as an acting theory. Acting theories are treated as possibly being truth in our evaluation of them, even when there are conflicting theories. In these cases, both theories are treated as truth, and both theories are evaluated to their fullest until one or both are clearly defeated with empirical evidence.
"I am a Christian by belief. I treat creationism as truth, and I treat evolution as truth, both within the limits of recognizing them as theory.
"Understand that in the debate of creationism versus evolution, mankind will never be able to definitively disprove either one. We cannot observe how the universe was created, hence we have no empirical evidence of the method, and hence evolution, whether or not it is true, cannot be absolutely proved. Likewise, at the heart of creationism is a fundamental premesis of an omnipotent being. If such a being exists, then no matter how much evidence is discovered for evolution, this being could always have created this evidence.
"The Christian God demands that people believe in him by faith. Although He could offer compelling physical evidence of his presence by spelling 'God created you, evolution is false' in the stars, doing so would defeat His desire to be believed in through faith. If He exists, and our understanding of Him is accurate, then He will never prove Himself in this way.
"The debate of creationism versus evolution is stale mated. Discussing the merits of creationism versus the merits of evolutionism is outside the scope of this class. There may be courses on this in the Philosophy department, I'm not sure. Also, discussing the attributes of creationism falls outside the scope of this class, and is best left to clergy.
"If anyone wants to discuss it with me personally, you know my office hours, and I would be more than happy to do so.
"So all of that pretext aside, let's discuss the attributes of chemistry that pertain to the theory of evolution."
I think the problem in public schools is that a discussion like this doesn't happen in most schools. This is what gets Christians upset. Evolution often isn't even referred to as a theory. In my high school, it was "Evolution" and "The theory of relativity." The word theory and the word evolution never occurred in proximity. This is actually bad science even if you are willing to completely discount the existance of a contrary theory. Public schools don't tend to leave evolutionism open ended or leave any doubt as to their certainty of the theory. Probably mostly because this finesse is past the ability of most high school teachers, who were never trained for it.
Speaking directly to your comments about the two theories co-existing, the reason this isn't acceptable to most Christians is because the Bible says differently, and Christians accept the Bible as direct unflawed communication from God.
Personally, I'm Christian, but I don't view the Bible that way, for the sole reason that man is who wrote it. Because
No kidding, they can put one in my back yard for $28k per year too! They can even use my daughter's bedroom as the control center (not really, that's a Simpson's reference).
$28k will cover or exceed most people's mortgages! I wouldn't mind being shunned in the community when I'm using $20 bills for toilet paper.
Good call, maybe we should just put a $1,000 levy on all personal computer purchases to cover the cost of pirated software too, eh?
Maybe your car should come with a $40,000 levy to cover the cost of uninsured drivers.
I'd completely go for the iPod tax.
Now I've paid for music, it's no longer illegal for me to go out and download it.
I know that's not really how it'll work legally, but I've always strongly felt that if any standard tax is passed on devices for listening to music, then anyone in possession of such devices are free to access all the music with out limit. Why else have a tax if not to remove the individual purchase rate.
I'd gladly give up $200 one-time for indefinate no-further-charge unlimited access to all the RIAA (or whatever it is in the Netherlands) music.
All that said, it is a mockery of justice to have ANY corporation able to levy a tax on citizens for any reason. If this was a tax so the government could afford to cover the legal costs that *it* is incurring, then it falls well within what most standard taxes are for. But if it's a tax that presumes purchasers of a consumer device are going to use it for illegal ends, and compensate the, erm, "victims" in advance, then you've just created a "Guilty until proven innocent" model.
Personally I have a 40g iPod which is about 2/3 full. Every single bit of data on it is something which I have a right to place there. I do believe in paying for music (though actually most of what I have on there is audio books -- which I've paid for). This sort of law would charge people like me, who are wholly operating within our rights within the law, for the crimes of others, with the presumption that I'm too weak minded to resist the temptation to break the law.
He probably means that it can be performed on the chip in a single operation. More registers means higher possible complexity of result for a single operation.
:-)
Yes, the AMD can do it too, but it requires multiple operations on the chip to come to the same result.
This is of course only an example, I'm not familiar with either chip's instruction set, it's just a way that I can imagine the superiority of one over the other. I still don't like macs
Am I the only one who noticed that there were sound effects in space? I really hope this is only in the trailer, and that the actual movie stays true to the series by removing the sound effects from the space scenes.
It was the first space scene sans engine noises, that first completely hooked me on Firefly. I couldn't believe someone writing sci-fi actually obeyed the laws of physics in this sense. And the soundlessness of it, filled instead with that guitar drawl, really lent a feeling of surrealness, and in fact, I thought it made space seem like a lot scarier place than any other sci-fi had ever managed -- the thought of being stranded out there, in utter silence, alone and forever, really got me.
Believe it or not, but there are some parents who know more about computers than their children. We call them things like "Network Administrator" or "Software Developer."
Every time software or legal initiatives come along that might provide parents greater control over their kids lives, standard Slashdot hubris receives the most mod points. "Instead of giving parents this tool, the parents should just be good parents." Things like these are tools that help to *enable* parents to be good parents.
Anyone who thinks they can watch their kids all of the time is either naieve, has never been a parent, or is simply completely smothering their children.
Tools like this enable parents to put a line in the sand. Perhaps little Timmy does know more about computers than you, and perhaps little Timmy also knows how to open the cookie jar when you're not looking. The point is that you've laid a line in the sand of what you as a parent believe is wrong. If you catch Timmy playing GTA:XXX when you specifically blocked that sort of game, then you have tremendous resource. Personally, what I'd do is confiscate the computer for a few weeks, or otherwise completely remove access.
You have to give your children leeway to discover who they are as individuals, but you also need to raise caution barriers in areas that you as parent deem to be detrimental to your children's well being.
I personally think that games like GTA warp a child's sense of right and wrong, at least up to a certain developmental stage. You're free to disagree with me on that (someone always does, even if it's not you specifically), but it's my perogative to believe that, and it's my perogative to raise my children that way no matter how sheltered some standard Slashdot readers may think my children will be.
Tools like this allow me to define to my child, with out any ambiguity, what I think are right and wrong for him or her to do. Even if my child circumvents that caution barrier, the message is still successfully communicated, without little Timmy having to wonder, "Is raping a hooker a good thing or a bad thing?" When little Timmy borrows a game from a buddy, he will know when he sticks it in the computer that it's a bad thing, before he even plays or perhaps installs the game.
Also, I really like the idea of time limiting game play. You can play video games for two hours today, but then you have to do something else that's either more mentally stimulating (playing with lego's, drawing a picture), or more physically stimulating (exercise, playing with other children). I don't have to worry about doing the accounting, I can focus on living my life with my child. Heck, I'd like that ability for myself, I know I can get absorbed into something, and 4 hours rolls by before I know it.