I remember using that feature back in the netscape 4 days to write a web-based annotation tool. Some of the heavy lifting in the UI had to be done by java applets, and these were driven from javascript. Thinking back, it's amazing how much potential there was in the browser tech of the day, and how little of it was realized until the great browser hibernation forced web developers to look at what browsers already did that could let them build better apps.
No, ERP in waste management means scheduling when each garbage truck will do which round, and who is going to be on it. Are you really going to schedule that on paper? What happens if you have a run of the flu, and 10 percent calls in sick? Believe me, a well-run organization uses software for this.
They probably had to reduce their planning department to save costs, and couldn't get the job done without software.
This happens all the time in the specialized software business.
Usually the needs are so particular that there's nothing in the market that does exactly what they want. So, you get approached by someone who knows you don't sell what they need, but they hope you can build/adapt something quickly.
The surprising thing is that if you press for exact specs at the beginning of the project, the entire project is often derailed. The realization by the customer that they don't know what they want is often enough to scare them away from buying a solution for their problem. Sales will put a lot of pressure on development in the form "just give us a general quote, we'll figure it out once they sign". For sales, every signature is a win. For the business as a whole, some projects are money losers.
The company I work for also sells waste management solutions. The first time we sold it, we took a planning tool meant for building maintenance (repairing light bulbs and the like) and repurposed it. Even today the garbage trucks still have to be entered into the system as employees.
So, yeah, this is pretty common.
Then again, the users are very positive about our solution, which is apparently one of the easiest to use in the market. That says a lot about just how bad the niche enterprise software business is in general. People think those special-purpose apps are well-crafted, but because they're special purpose they usually are held to a much lower standard than consumer apps.
The most embarassing "enterprise" niche software product I've seen was a solution for patient transport in hospitals. It was written by a hobbyist, and I could have done a better job at 15 than that guy did. Still, they sold it for thousands of dollars a seat, and were apparently one of the key players in the patient transport business. Scary.
I think the OS constraints of the early windows years were probably prohibitive in doing that. Using GDI to drive the printer was probably something that bore out of necessity, not out of intent.
I had a debian system that upgraded without issues across three major releases. Debian stable afaik is the only distro that actually handles major release upgrades without a hitch.
The only caveat with debian stable is that you're years behind the times. When they ship it it's already a cycle behind everyone else. Still, if it does what you need...
That's like saying there's no problem with architects that don't know how to lay down bricks, because they never have to themselves. What happens when they get a shoddy bricklayer and they don't realize the house is going to collapse soon after it is built because on the plans everything's designed correctly?
Relying on layers you depend on means it's just a matter of time until you get horribly blocked on flaws or limitations in those layers.
I'm a web developer, but I understand the layers below mine, and it has helped me a lot. I've had to redesign algorithms to perform better on the actionscript VM, taking into account its design limitations. I've had to trawl through PHP's C code when the documentation stopped just short of what I needed. I've had to write parser/generators to convert one format into another. I've had to design floating point calculations to transform from one curve notation to another, within a specified size of error. I've had to look at wireshark network dumps to debug issues related to the IE / IIS communication. And so on, and so forth... If I took the attitude that knowing PHP, javascript and html was all I needed, I wouldn't have been able to do any of that stuff.
At the end of the day, problems need to get solved, and you're right that often quick and dirty with a minimal skill set gets the job done. Often, but not always.
Web apps run locally, they just run on a different API than "local apps". With google gears offline support, you don't even need an internet connection to run "remote" apps. Users can't tell the difference between local and remote because there barely is any.
The paradigm shift here consists of two things: - wherever you are, your apps and data are waiting, you don't need to take your hardware with you. - apps are always up to date and installed, without you having to bother with software maintenance.
From a user friendliness perspective, "the cloud" is inevitable. Why do we force users to manage installation of applications, when we can build stuff that manages itself?
Now, you would be right in saying the web platform isn't where it needs to be at yet. Still, if you saw the firefox 3.1 demo of multi-threaded motion detection in live video using nothing but javascript and the canvas element, you might see the potential.
Not possible. If someone takes a debian system, and modifies it, they need to be able to redistribute it. Even if mozilla grants a license to debian, they can't grant a license to all debian users without just granting a license to the world, at which point you'd get spyware makers making "optimized" builds of firefox, fooling tons of non-technical users. Since the mozilla foundation's mission is improving the internet for everyone, that would run contrary to their goals.
My car is still slow, and now once I get to point 'b' I have no car to get around.
The analogy is flawed. In this case, using the "sleep" function of the laptop doesn't take away any of the laptop's functionality. In fact, using the sleep function is probably the best advice, since any fast-booting OS will probably be less capable than the OS it has right now.
Every day we see more and more JavaScript exploits out in the wild,and yet the only thing anyone seems to be concerned with is speed?
Those aren't javascript exploits, they're security issues in other parts of the code that are easiest to trigger via javascript, and that you will resolve with proper sandboxing, which all browser makers are working on. Exploits in pure javascript are pretty rare.
I think we're talking about a trade-off between usefulness and security anyway. Disabling javascript to gain security is a bit like putting foam on the end of a hammer to avoid hurting your thumb. It sort of misses the point.
I had to do this, because JavaScript is single-threaded.
With google gears workers you can run multiple javascript threads easily (synchronized with message passing). Google gears is integrated by default in chrome, and just a plugin install away on other browsers.
Your specific problem sounds related to bad 3rd party code, not due to a lack of threading.
Re:It's not the "Web's evolving needs" ...
on
Chrome Vs. IE 8
·
· Score: 2, Insightful
The corporate world is begging for more web applications. They're tired of the intricacies of client-installed software. Installation, maintenance and configuration of native apps is a nightmare when you're talking about rolling stuff out on thousands of desktops. Turning it into a web app solves the problem.
Besides, how silly is it that documents and applications are tied to physical locations? Applications and documents should follow the user wherever they go, not the other way around.
Chrome does let you edit css on the fly, it's just not as in your face as some other browsers. I'd also like to say that editing styles and attributes on the fly is one of the most useful debugging tools a browser can provide to a web developer, so not providing that guarantees that your browser will be more difficult to support.
Exactly, corporate portals are meant to guide you to productivity tools that you need, while entertainment portals are meant to led you to products you don't want. I build an enterprise portal product as well and we keep getting questions to make it do more from our customers.
Re:Firefox Damage Control Is More Than Enough
on
Chrome Vs. IE 8
·
· Score: 1
Lots of people dislike Coolbar immensely and they've just been told "tough" by FF devs.
They've been told tough because they, like me, don't understand why people don't like it. Can you give me a reasoned argument why it's less capable than the old location bar? For me it has been a major productivity boost, and I hate going back to the old location bar, because it feels so weak.
Re:Firefox Damage Control Is More Than Enough
on
Chrome Vs. IE 8
·
· Score: 1
So, you hate the awesome bar in firefox, but you don't mind the omnibar in chrome? Despite that the omnibar is basically the awesome bar with google search added to it?
Re:Firefox Damage Control Is More Than Enough
on
Chrome Vs. IE 8
·
· Score: 1
FF 3 feels like a native application written by someone who didn't have a clue about the platform human interface guidelines (or about HCI in general)
Huh? What major UI differences between Safari and FF3 make it not conform with HCI guidelines? I've got both of them open side by side and they look like twins to me.
Launch chrome, browse to a site, right-click on an element, select "Inspect Element". You've got your DOM view, and on the resources tab you've got a page profiler. There's a javascript console hidden somewhere in the menu's as well.
Slashdot Mirror
itunes is compatible with a number of players not made by apple: http://support.apple.com/kb/HT2172
The catch is that these can only sync music, which is probably why palm had to fake being an ipod.
I remember using that feature back in the netscape 4 days to write a web-based annotation tool. Some of the heavy lifting in the UI had to be done by java applets, and these were driven from javascript. Thinking back, it's amazing how much potential there was in the browser tech of the day, and how little of it was realized until the great browser hibernation forced web developers to look at what browsers already did that could let them build better apps.
No, ERP in waste management means scheduling when each garbage truck will do which round, and who is going to be on it. Are you really going to schedule that on paper? What happens if you have a run of the flu, and 10 percent calls in sick? Believe me, a well-run organization uses software for this.
They probably had to reduce their planning department to save costs, and couldn't get the job done without software.
This happens all the time in the specialized software business.
Usually the needs are so particular that there's nothing in the market that does exactly what they want. So, you get approached by someone who knows you don't sell what they need, but they hope you can build/adapt something quickly.
The surprising thing is that if you press for exact specs at the beginning of the project, the entire project is often derailed. The realization by the customer that they don't know what they want is often enough to scare them away from buying a solution for their problem. Sales will put a lot of pressure on development in the form "just give us a general quote, we'll figure it out once they sign". For sales, every signature is a win. For the business as a whole, some projects are money losers.
It means "crappy software with a big name so we can ask you for a big pricetag". How they got it to spell out ERP I'll never know.
The company I work for also sells waste management solutions. The first time we sold it, we took a planning tool meant for building maintenance (repairing light bulbs and the like) and repurposed it. Even today the garbage trucks still have to be entered into the system as employees.
So, yeah, this is pretty common.
Then again, the users are very positive about our solution, which is apparently one of the easiest to use in the market. That says a lot about just how bad the niche enterprise software business is in general. People think those special-purpose apps are well-crafted, but because they're special purpose they usually are held to a much lower standard than consumer apps.
The most embarassing "enterprise" niche software product I've seen was a solution for patient transport in hospitals. It was written by a hobbyist, and I could have done a better job at 15 than that guy did. Still, they sold it for thousands of dollars a seat, and were apparently one of the key players in the patient transport business. Scary.
Actually, the word "fuck" does in fact derive its meanings (even the non-sexual ones) from its sexual reference.
For a detailed explanation, I'll refer you to this detailed study of swear words:
http://www.youtube.com/watch?v=hBpetDxIEMU&feature=channel_page
I still remember though the impression of people when I did extra redundant reboot and Win9x network was magically coming to life.
I managed to inspire awe at my arcane geek knowledge when I fixed someone's internet connection by typing comma's in an edit field.
I think the OS constraints of the early windows years were probably prohibitive in doing that. Using GDI to drive the printer was probably something that bore out of necessity, not out of intent.
I had a debian system that upgraded without issues across three major releases. Debian stable afaik is the only distro that actually handles major release upgrades without a hitch.
The only caveat with debian stable is that you're years behind the times. When they ship it it's already a cycle behind everyone else. Still, if it does what you need ...
That's like saying there's no problem with architects that don't know how to lay down bricks, because they never have to themselves. What happens when they get a shoddy bricklayer and they don't realize the house is going to collapse soon after it is built because on the plans everything's designed correctly?
Relying on layers you depend on means it's just a matter of time until you get horribly blocked on flaws or limitations in those layers.
I'm a web developer, but I understand the layers below mine, and it has helped me a lot. I've had to redesign algorithms to perform better on the actionscript VM, taking into account its design limitations. I've had to trawl through PHP's C code when the documentation stopped just short of what I needed. I've had to write parser/generators to convert one format into another. I've had to design floating point calculations to transform from one curve notation to another, within a specified size of error. I've had to look at wireshark network dumps to debug issues related to the IE / IIS communication. And so on, and so forth... If I took the attitude that knowing PHP, javascript and html was all I needed, I wouldn't have been able to do any of that stuff.
At the end of the day, problems need to get solved, and you're right that often quick and dirty with a minimal skill set gets the job done. Often, but not always.
In dutch they call it "informatica". "Informatics" would probably be a better term in english too, if it existed.
Web apps run locally, they just run on a different API than "local apps". With google gears offline support, you don't even need an internet connection to run "remote" apps. Users can't tell the difference between local and remote because there barely is any.
The paradigm shift here consists of two things:
- wherever you are, your apps and data are waiting, you don't need to take your hardware with you.
- apps are always up to date and installed, without you having to bother with software maintenance.
From a user friendliness perspective, "the cloud" is inevitable. Why do we force users to manage installation of applications, when we can build stuff that manages itself?
Now, you would be right in saying the web platform isn't where it needs to be at yet. Still, if you saw the firefox 3.1 demo of multi-threaded motion detection in live video using nothing but javascript and the canvas element, you might see the potential.
Not possible. If someone takes a debian system, and modifies it, they need to be able to redistribute it. Even if mozilla grants a license to debian, they can't grant a license to all debian users without just granting a license to the world, at which point you'd get spyware makers making "optimized" builds of firefox, fooling tons of non-technical users. Since the mozilla foundation's mission is improving the internet for everyone, that would run contrary to their goals.
Having written an outlook add-in, I can assure you that outlook is a pile of shit from every angle as well.
My car is still slow, and now once I get to point 'b' I have no car to get around.
The analogy is flawed. In this case, using the "sleep" function of the laptop doesn't take away any of the laptop's functionality. In fact, using the sleep function is probably the best advice, since any fast-booting OS will probably be less capable than the OS it has right now.
Every day we see more and more JavaScript exploits out in the wild,and yet the only thing anyone seems to be concerned with is speed?
Those aren't javascript exploits, they're security issues in other parts of the code that are easiest to trigger via javascript, and that you will resolve with proper sandboxing, which all browser makers are working on. Exploits in pure javascript are pretty rare.
I think we're talking about a trade-off between usefulness and security anyway. Disabling javascript to gain security is a bit like putting foam on the end of a hammer to avoid hurting your thumb. It sort of misses the point.
I had to do this, because JavaScript is single-threaded.
With google gears workers you can run multiple javascript threads easily (synchronized with message passing). Google gears is integrated by default in chrome, and just a plugin install away on other browsers.
Your specific problem sounds related to bad 3rd party code, not due to a lack of threading.
The corporate world is begging for more web applications. They're tired of the intricacies of client-installed software. Installation, maintenance and configuration of native apps is a nightmare when you're talking about rolling stuff out on thousands of desktops. Turning it into a web app solves the problem.
Besides, how silly is it that documents and applications are tied to physical locations? Applications and documents should follow the user wherever they go, not the other way around.
Chrome does let you edit css on the fly, it's just not as in your face as some other browsers. I'd also like to say that editing styles and attributes on the fly is one of the most useful debugging tools a browser can provide to a web developer, so not providing that guarantees that your browser will be more difficult to support.
Exactly, corporate portals are meant to guide you to productivity tools that you need, while entertainment portals are meant to led you to products you don't want. I build an enterprise portal product as well and we keep getting questions to make it do more from our customers.
Lots of people dislike Coolbar immensely and they've just been told "tough" by FF devs.
They've been told tough because they, like me, don't understand why people don't like it. Can you give me a reasoned argument why it's less capable than the old location bar? For me it has been a major productivity boost, and I hate going back to the old location bar, because it feels so weak.
So, you hate the awesome bar in firefox, but you don't mind the omnibar in chrome? Despite that the omnibar is basically the awesome bar with google search added to it?
FF 3 feels like a native application written by someone who didn't have a clue about the platform human interface guidelines (or about HCI in general)
Huh? What major UI differences between Safari and FF3 make it not conform with HCI guidelines? I've got both of them open side by side and they look like twins to me.
2. Developer extensions
3. Debugger (Firebug)
Launch chrome, browse to a site, right-click on an element, select "Inspect Element". You've got your DOM view, and on the resources tab you've got a page profiler. There's a javascript console hidden somewhere in the menu's as well.