All the details were right on, but to be honest with you, they could beta eight web apps without AJAX and find them lacking. If he didn't know what the server sides were written in some of them may just be hyping him about AJAX. And it may not even be the cause of less performance, for example a Java app server could be slower than Perl CGI's as well.
So yes, he definitely should have provided more server side details.
An older Windows release, reasonably patched, running under Linux (win4lin) and behind a paranoid firewall is safer than XP or Vista.
Other than the Linux part, that's my experience. WinMe and Netscape / Communicator 7 with Javascript turned off behind a BlackICE firewall is practically impervious. So Google Maps doesn't work, so what.
The only thing I saw that would affect me was this WMF thing. But I disabled something or other as recommended so that doesn't affect me.
I also have an XP Pro with Firefox / Thunderbird and Javascript on behind a Symantec firewall, and that baby is on a lifeline to the mothership. Updates from Microsoft, Symantec, and Mozilla just keep rolling in. Just makes you feel all warm and fuzzy.
I wouldn't bring up IE if someone pointed a gun at my head, because it would have the same practical results.
rd
P.S. And for the usual kneejerk posts, no I don't reboot or turn it off, and yes it wakes up when I move the mouse. I have found that running both JBuilder and Paint Shop Pro will screw up the display and require a reboot to straighten it up, but that's about it for trouble.
In all cases, I'd kindly suggest the problem is not with the technology, but with the person doing the work.
It wasn't *a* person, but rather eight commercial apps using AJAX that didn't work, because users said so, compared to existing non-AJAX web apps that do work.
Other than that, your earlier examples of use of AJAX were good.
That's just stupid. A well designed AJAX app is faster to use than a regular one. Page reloads suck for applications.
And that's it in a nutshell, he's right (with his company's experience beta testing eight commercial apps using AJAX), and you're right.
You're saying about the same amount of calls, bur more strategic and interactive in updating a portion of a web page.
He's saying the commercial apps were making so many calls to be interactive (e.g. keystroke and mouseovers) that the servers were loading CGI programs many more times than with a full web page refresh.
And like you say, it's all in design as to how effectively that server load - client interactiveness tradeoff is handled.
I would say that developers would tend more toward PC app level interactiveness such as updating the data as you cursor up through a table at the cost of multiple CGI loads that a web page refresh wouldn't make.
The proof is in what makes it out there, and he described eight commercial apps failing with the users. Reality trumps theory.
Yet the AJAX implementation, running on an extremely powerful quad-core Opteron system with 8 GB of RAM, couldn't handle as many concurrent clients as our Perl-based CGI system could.
Very informative posts. The only thing missing was what the various commercial server side products using AJAX were written in. Perhaps you have already added something on that in a later post, or being commercial products, you may not know, but AJAX versus non-AJAX is the point, which I understand.
Well, you either don't understand what a protocol is, or you're real fuzzy on the idea of AJAX. Maybe you should put one of the other 8 guys on the line.
What a bunch of nit picking bs. He's supposed to refer to AJAX as "use of a non-standard MSFT HTTP hack eventually picked up by the other browsers" instead of "protocol"? Spare me.
And the rest of his original post was perfectly clear as well, such as server resources required to service the MSFT hack call. (Is that ok with you? I hope so.)
Loading a CGI program for freakin keystrokes. What a concept.
The main reasons are the need for a very low bandwidth and the ability to run on serial terminals.
Which I would interpret as "run on serial terminals that we already have".
That's the amazingly bad assumption, or bad interpretation if you prefer. As I said, you weren't the only one to assume that. It's hard to envision what the company IT management is thinking otherwise.
They have an AS/400 which in this day talks to PC's running a 5250 terminal emulation program.
I would characterize that as the amazingly bad assumption, rather.
5250 terminals are not serial port terminals. That's why an AS/400 shop saying they want to convert to Linux with serial port terminals is not leveraging any AS/400 terminals they had before.
Of course, if they had PC's running 5250 emulation they can use the PC's to run serial terminal emulation. It is clear to me the cheapness they seek is not in reusing hardware, it is the simplicity of the protocol and administration.
In any event, there is no AS/400 hardware to leverage to non-AS/400 Linux and serial port terminals, so not an assumption on my part, amazingly bad or otherwise.:)
But more to the original post. Imagine if a corporation ever got their collective butts out of the FUD and had everyone use the same version of Linux and made all workstations part of a giant grid. Say this corp had 4000 employees...4,000 node grid and no big overheated datacenter.
And what would be done on the desktops of that 4,000 node grid? Useful business processing requires concurrently accessing enterprise data. Just how does sending a program to a desktop to execute a remote database I/O, at least for a few lines of code until it sends back to mother ship that another program is to be called, is in any way helpful?
Frankly that sounds like the software is in severe need of reworking! If their machines are 20 years old that's bad enough, but if they have 20 year-old software that needs to be rewritten every time a new type of car is added, it's time for a redesign.
The stuff they are saying is just normal crap from people who are justifying a buzzword solution, in this case a Linux grid.
"Rewritten" is probably a weasel reference to a modification, and the reason a modification may be required is because people want to do something different for everything, so maybe they create some new business rules for a new model. So, yeah, a mod is made to implement the latest thoughts out of the marketing suite when they have a brainstorm.
Sure it's wonderful if they stay inside the box enough for each new model to just add a table entry with some different factors, and if it was just flat out inventory codes then of course no program change is needed.
But often things are different enough that routines handling the new business rules are added. The usual IT spiel is just have a rules system and type in whatever. The buzzword for that was AI. Thankfully I didn't have to read any more of that buzzword crap after the 80's.
So now it's the grid. The buzzwords change, but the crap doesn't.
Files can be distributed amongst the nodes for speed and redundancy.
This is a mindset of grid computing, perhaps for this ubiquitous analysis of static geologic files for oil and such I am always reading about in the buzzword press, but it is not reality in the real world of business computing.
Files are accessed and updated concurrently by hundreds of users and jobs. There can be no "distribution" of a file somewhere to do whatever it is you have in mind in a serious enterprise environment.
Not that people don't architect FTP'ing this stuff right and left to get snapshots to PC servers anyway.
They already have terminals, which need to be used.
That's an amazingly bad assumption. They have an AS/400 which in this day talks to PC's running a 5250 terminal emulation program.
The fact that the company wants to use serial terminals is only an indication they want to go as cheap a route as possible. A post or two in this thread jumped on a "they have serial port terminals to use" thing because any other possibility is sort of stupid.
...a management software system with text based user interface as the replacement of an older one running on AS/400. Despite my attempts towards a web UI, the customer is actually willing to have a text based UI. The main reasons are the need for a very low bandwidth and the ability to run on serial terminals. All this in the 21st century! Host systems will be Linux, the language will be C or C++.
I'm an AS/400 guy, used to be a PC programmer. I'm trying to understand this, any comments appreciated. What's clear to me is the company is converting from an AS/400 to Linux (yes, Linux runs concurrently in partitions on the AS/400, now called system i after several name changes, but I'm also assuming they want a cheap Linux server).
I remember in some early programming (I was original programmer for Melita Electronics, later International, they did well:) hooking Wyse serial terminals to a PC and controlling multiple terminals from a PC with a multi-serial port board.
The AS/400 of course has not had serial terminals, they have 5250 terminals or PC terminal emulators over TCP/IP now, IBM networking before that. So I take it this serial port thing is a throwback to what I used to do because this company says, we have a Linux PC server, let's hook up cheap serial port terminals? With serial communications limitations and dirt cheap PC's able to run any kind of terminal emulation cheaply, something very strange about that to me.
The best I can tell from this is the purpose of NCURSES would be to emulate 5250 PC emulation with a serial port terminal emulator. But like I say, any clarifying comments welcome.
The replacing a "management software system" equivalent to what they had on the AS/400 in C++ on Linux would seem to be quite a job in itself. All of the work that NCURSES does is taken care of by our 5250 I/O subsystem. That's quite a lot of I/O detail that he will have to insert into the replacement.
By the way, NCURSES doc says it runs on any POSIX platform, and the AS/400 (which is usually called iseries now) has a C++ compiler and is POSIX compliant. The C++ modules can be bound together with modules from any other language on the iseries into an i5/OS program.
It could communicate with anything over TCP/IP, but I would have to check if we can rig up serial ports for terminals.:)
O'Reilly is certainly a foundation of internet technical publishing. But Google Maps caught the imagination of many and the technical press went to town on the wonders of AJAX as Web 2.0.
Certainly other broadband enabled user content sites was a second component of the resurgence.
But some posted they thought it took both together to be Web 2.0, and as you have indicated, it isn't.
This is just ridiculous. Google Maps was the original buzz on Web 2.0. The kiddie content stuff also (Myspace / Youtube), but Google Maps was the epitome of the future in Web 2.0 press.
Oh Btw, the big problem isn't Iraq, that's just causing a gradual slide, it's the retirement of the baby boomers, we should start to see the effects fairly soon.
I thought Web 2.0 was supposed to be about user driven content using ajax and a load of other eye candy crap...
Two different aspects being referred to. The user driven content mostly doesn't even use AJAX. A more interactive browser experience (AJAX) from site driven content was supposed to be the other.
At least as far as popular technical buzzword press goes.
If so, I can only assume that you have no understanding of economics if you think we're so much worse off now.
Last 6 years has run up triple the debt of the 80's (3 trillion versus 1 trillion).
We're now paying for both the 80's and 2000's.
The only thing keeping us going is China and Saudis loaning us money so we can keep buying their stuff, and run that debt higher.
The only reason everyone won't bail at once is they don't want their dollar holdings to collapse, but they will be "diversifying" in greater and greater numbers.
The only thing that will drive home how much we owe is when there's a borrowing crisis, which will happen when enough "diversification" takes place.
Our children and grandchildren will be none too pleased. Already 18% of federal budget is for interest on all those loans. That's just interest.
And that doesn't even count all the Social Security "borrowed" that has to be paid back.
High-skill jobs do go unfilled because the requirements to fill the job are unrealistic. i.e. someone with 10 years experience in.Net with a master's degree who will work for under $40k per year. If the job really needed to be filled, the market would make it happen by paying the right price.
Although I agree with everything else you said, not this statement which is frequently made. It implies that there are people who can fill these technical jobs making more in a non-tech career and $40k isn't worth their trouble for the tech job.
Excluding those people who can fill the job but are making more elsewhere, because if they leave, their previous position has to be refilled, there is very little out there for a tech career person where even $40k can be made doing something else.
In other words, if the pay were raised to $80k I personally don't think there is this reserve of people who could fill the job making greater than $40k but less than $80k who would say, oh, ok, now it's worth my trouble to quit real estate or whatever.
I think the requirements and pay are based on outsourcing specs, and the employer has no expectation whatsoever of filling it with an American without outbidding someone else for an employee, so they'd prefer cheap in India.
If others real world experiences are different than this, I'll change my opinion on this.
If you think Web 2.0 has something to do with AJAX, you need to read more sites than just/.
I read more sites than slashdot, and while content providers such as you list are the first to come to mind for Web 2.0, AJAX is referred to fundamentally as the basis of Web 2.0 in the technical press.
Not that the technical press ever did anything but write about buzzwords.
Slashdot Mirror
All the details were right on, but to be honest with you, they could beta eight web apps without AJAX and find them lacking. If he didn't know what the server sides were written in some of them may just be hyping him about AJAX. And it may not even be the cause of less performance, for example a Java app server could be slower than Perl CGI's as well.
So yes, he definitely should have provided more server side details.
rd
An older Windows release, reasonably patched,
running under Linux (win4lin) and behind a paranoid
firewall is safer than XP or Vista.
Other than the Linux part, that's my experience. WinMe and Netscape / Communicator 7 with Javascript turned off behind a BlackICE firewall is practically impervious. So Google Maps doesn't work, so what.
The only thing I saw that would affect me was this WMF thing. But I disabled something or other as recommended so that doesn't affect me.
I also have an XP Pro with Firefox / Thunderbird and Javascript on behind a Symantec firewall, and that baby is on a lifeline to the mothership. Updates from Microsoft, Symantec, and Mozilla just keep rolling in. Just makes you feel all warm and fuzzy.
I wouldn't bring up IE if someone pointed a gun at my head, because it would have the same practical results.
rd
P.S. And for the usual kneejerk posts, no I don't reboot or turn it off, and yes it wakes up when I move the mouse. I have found that running both JBuilder and Paint Shop Pro will screw up the display and require a reboot to straighten it up, but that's about it for trouble.
In all cases, I'd kindly suggest the problem is not with the technology, but with the person doing the work.
It wasn't *a* person, but rather eight commercial apps using AJAX that didn't work, because users said so, compared to existing non-AJAX web apps that do work.
Other than that, your earlier examples of use of AJAX were good.
rd
Actually, I'd say Flash does a damn fine job in it's more recent editions.
And as far as AJAX goes, they say they support it. I also read that SAP has chosen it as their browser interface, which is significant.
rd
That's just stupid. A well designed AJAX app is faster to use than a regular one. Page reloads suck for applications.
And that's it in a nutshell, he's right (with his company's experience beta testing eight commercial apps using AJAX), and you're right.
You're saying about the same amount of calls, bur more strategic and interactive in updating a portion of a web page.
He's saying the commercial apps were making so many calls to be interactive (e.g. keystroke and mouseovers) that the servers were loading CGI programs many more times than with a full web page refresh.
And like you say, it's all in design as to how effectively that server load - client interactiveness tradeoff is handled.
I would say that developers would tend more toward PC app level interactiveness such as updating the data as you cursor up through a table at the cost of multiple CGI loads that a web page refresh wouldn't make.
The proof is in what makes it out there, and he described eight commercial apps failing with the users. Reality trumps theory.
rd
Why is it that you can't seem to be more specific about this "AJAX system?"
Actually, he referred to eight commercial packages using AJAX, all of which the users rejected.
That's real life.
rd
Yet the AJAX implementation, running on an extremely powerful quad-core Opteron system with 8 GB of RAM, couldn't handle as many concurrent clients as our Perl-based CGI system could.
Very informative posts. The only thing missing was what the various commercial server side products using AJAX were written in. Perhaps you have already added something on that in a later post, or being commercial products, you may not know, but AJAX versus non-AJAX is the point, which I understand.
rd
Well, you either don't understand what a protocol is, or you're real fuzzy on the idea of AJAX. Maybe you should put one of the other 8 guys on the line.
What a bunch of nit picking bs. He's supposed to refer to AJAX as "use of a non-standard MSFT HTTP hack eventually picked up by the other browsers" instead of "protocol"? Spare me.
And the rest of his original post was perfectly clear as well, such as server resources required to service the MSFT hack call. (Is that ok with you? I hope so.)
Loading a CGI program for freakin keystrokes. What a concept.
rd
I'm sorry to say it, but AJAX might just be the worst technology I have ever had to deal with.
Parent post should go on AJAX's headstone.
rd
Why are some IT people so bad at economics anyway?
Because IT people aren't involved in the economics of it. The economics is stinkin consulting companies shoving it to idiot PHB's.
rd
The main reasons are the need for a very low bandwidth and the ability to run on serial terminals.
:)
Which I would interpret as "run on serial terminals that we already have".
That's the amazingly bad assumption, or bad interpretation if you prefer. As I said, you weren't the only one to assume that. It's hard to envision what the company IT management is thinking otherwise.
They have an AS/400 which in this day talks to PC's running a 5250 terminal emulation program.
I would characterize that as the amazingly bad assumption, rather.
5250 terminals are not serial port terminals. That's why an AS/400 shop saying they want to convert to Linux with serial port terminals is not leveraging any AS/400 terminals they had before.
Of course, if they had PC's running 5250 emulation they can use the PC's to run serial terminal emulation. It is clear to me the cheapness they seek is not in reusing hardware, it is the simplicity of the protocol and administration.
In any event, there is no AS/400 hardware to leverage to non-AS/400 Linux and serial port terminals, so not an assumption on my part, amazingly bad or otherwise.
rd
But more to the original post. Imagine if a corporation ever got their collective butts out of the FUD and had everyone use the same version of Linux and made all workstations part of a giant grid. Say this corp had 4000 employees...4,000 node grid and no big overheated datacenter.
And what would be done on the desktops of that 4,000 node grid? Useful business processing requires concurrently accessing enterprise data. Just how does sending a program to a desktop to execute a remote database I/O, at least for a few lines of code until it sends back to mother ship that another program is to be called, is in any way helpful?
rd
Frankly that sounds like the software is in severe need of reworking! If their machines are 20 years old that's bad enough, but if they have 20 year-old software that needs to be rewritten every time a new type of car is added, it's time for a redesign.
The stuff they are saying is just normal crap from people who are justifying a buzzword solution, in this case a Linux grid.
"Rewritten" is probably a weasel reference to a modification, and the reason a modification may be required is because people want to do something different for everything, so maybe they create some new business rules for a new model. So, yeah, a mod is made to implement the latest thoughts out of the marketing suite when they have a brainstorm.
Sure it's wonderful if they stay inside the box enough for each new model to just add a table entry with some different factors, and if it was just flat out inventory codes then of course no program change is needed.
But often things are different enough that routines handling the new business rules are added. The usual IT spiel is just have a rules system and type in whatever. The buzzword for that was AI. Thankfully I didn't have to read any more of that buzzword crap after the 80's.
So now it's the grid. The buzzwords change, but the crap doesn't.
rd
Files can be distributed amongst the nodes for speed and redundancy.
This is a mindset of grid computing, perhaps for this ubiquitous analysis of static geologic files for oil and such I am always reading about in the buzzword press, but it is not reality in the real world of business computing.
Files are accessed and updated concurrently by hundreds of users and jobs. There can be no "distribution" of a file somewhere to do whatever it is you have in mind in a serious enterprise environment.
Not that people don't architect FTP'ing this stuff right and left to get snapshots to PC servers anyway.
rd
Yes, I am quite sure IBM did not say it was the year of the aging mainframe.
rd
They already have terminals, which need to be used.
That's an amazingly bad assumption. They have an AS/400 which in this day talks to PC's running a 5250 terminal emulation program.
The fact that the company wants to use serial terminals is only an indication they want to go as cheap a route as possible. A post or two in this thread jumped on a "they have serial port terminals to use" thing because any other possibility is sort of stupid.
But it is what it is.
rd
...a management software system with text based user interface as the replacement of an older one running on AS/400. Despite my attempts towards a web UI, the customer is actually willing to have a text based UI. The main reasons are the need for a very low bandwidth and the ability to run on serial terminals. All this in the 21st century! Host systems will be Linux, the language will be C or C++.
:) hooking Wyse serial terminals to a PC and controlling multiple terminals from a PC with a multi-serial port board.
:)
I'm an AS/400 guy, used to be a PC programmer. I'm trying to understand this, any comments appreciated. What's clear to me is the company is converting from an AS/400 to Linux (yes, Linux runs concurrently in partitions on the AS/400, now called system i after several name changes, but I'm also assuming they want a cheap Linux server).
I remember in some early programming (I was original programmer for Melita Electronics, later International, they did well
The AS/400 of course has not had serial terminals, they have 5250 terminals or PC terminal emulators over TCP/IP now, IBM networking before that. So I take it this serial port thing is a throwback to what I used to do because this company says, we have a Linux PC server, let's hook up cheap serial port terminals? With serial communications limitations and dirt cheap PC's able to run any kind of terminal emulation cheaply, something very strange about that to me.
The best I can tell from this is the purpose of NCURSES would be to emulate 5250 PC emulation with a serial port terminal emulator. But like I say, any clarifying comments welcome.
The replacing a "management software system" equivalent to what they had on the AS/400 in C++ on Linux would seem to be quite a job in itself. All of the work that NCURSES does is taken care of by our 5250 I/O subsystem. That's quite a lot of I/O detail that he will have to insert into the replacement.
By the way, NCURSES doc says it runs on any POSIX platform, and the AS/400 (which is usually called iseries now) has a C++ compiler and is POSIX compliant. The C++ modules can be bound together with modules from any other language on the iseries into an i5/OS program.
It could communicate with anything over TCP/IP, but I would have to check if we can rig up serial ports for terminals.
rd
O'Reilly is certainly a foundation of internet technical publishing. But Google Maps caught the imagination of many and the technical press went to town on the wonders of AJAX as Web 2.0.
Certainly other broadband enabled user content sites was a second component of the resurgence.
But some posted they thought it took both together to be Web 2.0, and as you have indicated, it isn't.
rd
Maps is not (modulo the Maps API).
This is just ridiculous. Google Maps was the original buzz on Web 2.0. The kiddie content stuff also (Myspace / Youtube), but Google Maps was the epitome of the future in Web 2.0 press.
rd
Oh Btw, the big problem isn't Iraq, that's just causing a gradual slide, it's the retirement of the baby boomers, we should start to see the effects fairly soon.
How many will be able to afford to retire?
rd
I thought Web 2.0 was supposed to be about user driven content using ajax and a load of other eye candy crap...
Two different aspects being referred to. The user driven content mostly doesn't even use AJAX. A more interactive browser experience (AJAX) from site driven content was supposed to be the other.
At least as far as popular technical buzzword press goes.
rd
Review your history of the term.
I am fully aware of the history of the term and technology. My statement of its basis for Web 2.0 in the technical press stands as I posted.
rd
If so, I can only assume that you have no understanding of economics if you think we're so much worse off now.
Last 6 years has run up triple the debt of the 80's (3 trillion versus 1 trillion).
We're now paying for both the 80's and 2000's.
The only thing keeping us going is China and Saudis loaning us money so we can keep buying their stuff, and run that debt higher.
The only reason everyone won't bail at once is they don't want their dollar holdings to collapse, but they will be "diversifying" in greater and greater numbers.
The only thing that will drive home how much we owe is when there's a borrowing crisis, which will happen when enough "diversification" takes place.
Our children and grandchildren will be none too pleased. Already 18% of federal budget is for interest on all those loans. That's just interest.
And that doesn't even count all the Social Security "borrowed" that has to be paid back.
OP was being too kind.
rd
High-skill jobs do go unfilled because the requirements to fill the job are unrealistic. i.e. someone with 10 years experience in .Net with a master's degree who will work for under $40k per year. If the job really needed to be filled, the market would make it happen by paying the right price.
Although I agree with everything else you said, not this statement which is frequently made. It implies that there are people who can fill these technical jobs making more in a non-tech career and $40k isn't worth their trouble for the tech job.
Excluding those people who can fill the job but are making more elsewhere, because if they leave, their previous position has to be refilled, there is very little out there for a tech career person where even $40k can be made doing something else.
In other words, if the pay were raised to $80k I personally don't think there is this reserve of people who could fill the job making greater than $40k but less than $80k who would say, oh, ok, now it's worth my trouble to quit real estate or whatever.
I think the requirements and pay are based on outsourcing specs, and the employer has no expectation whatsoever of filling it with an American without outbidding someone else for an employee, so they'd prefer cheap in India.
If others real world experiences are different than this, I'll change my opinion on this.
rd
If you think Web 2.0 has something to do with AJAX, you need to read more sites than just /.
I read more sites than slashdot, and while content providers such as you list are the first to come to mind for Web 2.0, AJAX is referred to fundamentally as the basis of Web 2.0 in the technical press.
Not that the technical press ever did anything but write about buzzwords.
rd