ok, I know it's fashionable to pile on mozilla these days, however, in this case, I hope you'll be pleasantly surprised to find that mozilla is working with the w3c and google to standardize the concept. The eventual api they have just started to work on is currently being called the "gamepad" api.
Speed the death of Flash and speed the adoption of HTML5+JS as the goto client-side software development platform for most things. The Joystick API is amongst the greatest things coming out of this effort:
Sigh... I wondered when the Java plugin was finally going to poop out on us design-wise. Darn thing is so creaky and stuck in web 1.0-mode. Maybe it's time to port CardMeeting to HTML5...
This is a great point. Opera doesn't have a public bugtracker. I didn't know my website was having trouble on Opera until I saw it mentioned in the release notes on Opera 11.10.
Maybe there was something I could do to test and workaround my site freezing Opera, had I known there was an issue at all...
Mozilla's running a public bugtracker is commendable, heck you don't even need to sign up for an account to search for bugs!
But, writing great software is REALLY HARD TO DO! The 10-year old unfixed critical bugs and thousands of unconfirmed bugs is common. Mozilla just wears all that egg on it's face rather than hiding the egg under the trenchcoat like the other guys do.
Ultimately, Firefox will need another complete redesign and rewrite because it collapses under its own weight. Technology and ideas will move past it's current architecture. Sad but true. And then the whole cycle of awesomeness and suckiness can start again.
Your trolling is legendary, sir, you've won and now I'm responding.
Java's better than C++. It's more popular. It's better looking. It's more important.
That's not gloating, that's not religion, it's just the market who decided that years ago. You can get angry about it. Fight it if you want. But at the rate you're going with the smug dismissals, you're not gaining any converts.
I'm going to paste all of Lord_Naikon's retort, as what he said is just the tip of the Java iceberg:
Why is it so hard to understand that Java, a language DESIGNED for portabilty, is more suitable for cross platform development than C++? You can throw any number of well designed cross platform C++ libraries at C++, it is still NOT part of the language, not part of the standard development platform and therefore it is harder to do cross platform C++ development than in Java. I can not comprehend why you think otherwise. Yes, the disparity in cross platform developement ease between the two may slowly fade in time, especially in the light of the new C++ release which makes a lot of features that you need from an API standard (threads for instance), but to say they are on par is simply an outrageous claim and definitely not a "simple fact".
Allow me to demonstrate some practical problems with C/C++ cross development between Windows & Unix) - Non standard build system (make / vc++), different systems used for different libraries. - Different linking process (.so vs.dll/.lib) - Wildly differing implementations of the standard C library (stdio in VC++ is severely broken). - No network API, so we will have to deal with either manual compatibily shims (more work) or 3rd party library (more work) - No GUI API, same as above
The uniformity in Java is what makes cross platform development such an easy task: - Everything is.JAR, build tools the same for all platforms (granted, you still need a Make equivalent, say ant, but the result of the build process is portable) - Linking is just throwing a bunch of JARs together - There is only one implementation of the standard library that everyone uses. - Network API is standard - GUI API is standard.
Now please enlighten me how exactly C++ crossplatform development is just as easy as in Java.
I tried to write a cross-platform C++ open source library once and be one of the good guys in your book. You know what a treacherous, expensive, and painful process that was? All the compilers did templates differently, it was a delicate dance on fiery coals to get my code working for all my users on all platforms.
The best cross-platform build system I could find at the time should give a clue on just how shallow the C++ ecosystem is: java running ant with a C++ compiler exec helper plugin. The C/C++ community couldn't even offer me one decent cross-platform build system that didn't require a master's degree to run. There's nothing there there in the C++ world, no promotion nor adherence to any standards.
Where's C++'s TCK? Where's its JCP? I know you don't care about those things, but I thought I might ask!
We don't have passengers in the cockpit flying our commercial airline planes. We have expert pilots flying our planes who have thousands of hours logged training. It's too important to have just anyone flying planes, lives are at stake.
When it comes to software, it's nonstop amateur hour. There is hardly any urgency about the lives at stake when it comes to software.
In my estimation, there is very little robust native code, written large, in the world. QNX, the JVM, maybe Apache HTTP (although that seems creaky to me and the config system is a hot mess.)
The linux kernel seems robust to me based on how it's maintained, but I am not an expert. All of the browsers have some varying degree of swiss cheese holes to them, with giant attack surfaces, and poorly written plugins (including Java's.) I pity the security teams on those products.
I don't trust your native code. I hear people tout their soup du jour language/vm as robust, sane, battle hardened. The more shared libraries and DLL's your code relies on, the less I believe you. If your favorite system easily/readily/commonly links in more native code as it rolls along, then I hope you understand that your battle hardened tank has cheese cloth armor that should never go to war.
I don't trust Microsoft code, especially their new products - a permanent bullseye is tattooed on their hineys. Yes, they've made security advances in recent years, they're still horribly vulnerable due to the legacy baggage which is core to their business. Microsoft code is bubbly poison at its deep, dark, dank core. IE is terrifying to me.
When it comes to me, I consider the code I write to have my name attached to it. Why wouldn't I give myself every opportunity to look good? A crash bug in native code to me is the most serious form of professional failure.
Maybe a lot of you just tinker and love your micro-optimizations in C and Assembly. Good for you, go spin that propeller on the beanie on your head, very neat. If you write for games or embedded systems and need the speed of native code, fair enough, but I'm dubious C# or Java isn't fast enough for most of that. Otherwise, please, PLEASE stay out of the native code cockpit when it comes to commercial/professional work unless you've got your thousands of hours of flight training. Lives are at stake.
We use Cassandra for all the user management and virtual file system storage at ClubCompy, It is so blazing fast compared to SQL for both read and writes, and it is very scalable. I've had a node of my storage cluster go down and whole system stays up with no data loss, and it can repair itself once I bring the downed node back up.
Coding to Cassandra is pretty challenging, you have to do all of your data modeling in code or use the new CQL to access the cluster. I wrote about my experiences recently, where I have started using Google's Protocol Buffer to give me more flexibility in how I store my data and describe my column families: Coding to Apache Cassandra with Google's Protocol Buffers
You want to know what is total crap? Productivity with the GUI on Linux if you avoid mousing. The out-of-the-box twisty tree control widget on Gnome is garbage. The standard keybindings and way it handles focus in and out -- now THAT is total crap!! Biggest complaint: left and right should expand and collapse where selected, GET IT?! Left-right gives me horizontal scrolling today on Gnome. Why? My keys on Gnome for expand/collapse: shift+left/right (and those bindings don't seem to work consistently across applications.) Why a modifier key?? Up and down work right in Gnome, that moves the selection up and down, which in turn can cause the control to scroll vertically, as needed. Why not be uniform in how to traverse? And I'm sure these infuriating defaults totally screw accessibility for people that have trouble with modifiers.
Quite honestly, I don't even care to have keyboard control over horizontal scrolling in a tree control; that's how Windows works and I usually fare okay with it. But, if you want to be a total geek and be different, you could make shift+left/right the new horizontal scroll and make left/right the new expand/collapse/traverse child and smooth out the behaviors a bit.
There's so many little UI nigglers I've run into like the darn tree control that just act badly or feel klunky on Linux that I hate to work on rich UI's there, it just doesn't flow. In that regard, for many of the small touches, I'd say windows is better and more productive; someone there cares (or cared long, long ago.)
You want an operating environment that goes beyond the command line and is productive enough to court away windows users who care? Then you need to deep dive on every geek legacy GUI design decision across the board and fix every klunky feeling part of the default widget set.
But no, I wager you don't really want new users on the GUI, do you? Just keep on thinking you're better and keep on boring everyone with that whole line, no need for humility, oh no.
P.S. Oh, and bring back Multiple Document Interface as a promoted standard UI design for apps, that was the productivity bomb. Sad to see that one go by the wayside in Microsoft circles. Alt+Tab to go between processes, Ctrl+Tab to go between child windows. Genius.
I'm more optimistic about kid's chances for learning with BASIC-like languages. BASIC programs tend to be small and spaghettified. Trying to build a large BASIC program usually yields something that will collapse under the weight of its own complexity. BASIC is something to chafe against and grow out of.
I can't tell you how often the alarmist/purist message of "GOTO is evil!!!!!!!!!1!!!!" reached my ears when I was a little guy. I got that message and processed it, and ultimately understood the wisdom of it. I trust the same thing would happen today if kids were in a similar situation. I just think we coddle our next generation that is SO primed for great things. If only we'd just challenge them.
I was the same way, brother. Type-in games in BASIC on the C64 were the draw because my family was too poor to buy Atari games, and that experience got me hooked. Of my own volition, I went straight to TurboPascal when I outgrew Basic and 6502 Assembly, then Quick C then C++ in college, and for career I was all set for systems-level C++ and later Java/Java EE. Got an enjoyable and profitable career out of the deal.
Tell me what the equivalent path is for kids today? Is drag and drop coding the way to get them hooked? I'm not yet sold on that... It's too flashy and too shallow. Hm, well, maybe not too shallow - that experience teaches good handling of media files, and there is a lot of value there these days. But as a programming tool, I find those systems de-emphasize the use of logic and the building of abstractions and the construction of data structures and of encouraging the development of problem solving, which is the whole point of learning to program. I feel like we're going to lose our edge and have less qualified replacements coming up - worldwide, not just here in the states.
So how about ClubCompy? It's got a BASIC-like language, nostalgic for us 8-bit veterans. The character generator is my favorite part to dink around with. Sprites are my second favorite now that the collision detection is working properly, and it's got 256 sprites instead of just 8!
Well, we're trying to produce a facsimile of your intro to programming at ClubCompy. The point of the site is to create a simple computer simulation coupled with a BASIC-like language that kids can pick up easily. And we are working on a monthly newsletter that will be a companion on the site. If you sign up for an account, you can even SAVE and LOAD your programs.
You can see an example of what it's capable of doing at the Real-World Benchmark, which gives some sample programs you can type in with the kiddos!
I hope you're happy, I hope you're satisfied. YOU WIN, you evil, evil man. I'm of course referring to the Double Team map in PixelJunk Monsters on Hardcore. I'm sure it's possible to beat, but I am not good enough, twitchy enough, clever enough, nor evil enough to get my G.D. double f'ing rainbow on that level!
Gar, I want that double rainbow, It's so mean to dangle that carrot just outta my reach.
It's not a fair comparison though that they're so much faster than us, our code runs out of a BASIC-like language called Tasty that runs ATOP JavaScript.
Re:Tomcat is as rock solid as it gets
on
Tomcat 7 Finalized
·
· Score: 1
I bring shame into it because you obviously get snippy when anyone comes close to hitting a nerve. If you've got the architecture of last resort or whatever and your clients are just so thankful they have what they have, good for you. I've encountered plenty of examples of people like yourself in my travels and a lot of 'em can just ride that wave for years until it crashes. Hang ten.
And I do know your business. Reporting, db's, Java, enterprise apps? It's like, uhm, I've been doing that for 12 years across 5 different industry categories for the consulting firm I work for. Ha, I'm dealing with retail right now! And, I've done POS and ecommerce for retail clients in the past.
If I produced a system that had performance characteristics like what you're describing, our clients would terminate our contracts. Before consulting, I was doing C++ and assembly systems-level stuff for another 6 years. So I know what brute force looks like, and I know what finesse looks like. Don't get cocky and think you have anything special or revolutionary there, there's no secret sauce anymore.
And I can't stand it... it's CACHING! Not cashing. Sorry, but I couldn't let that slide.
Re:Tomcat is as rock solid as it gets
on
Tomcat 7 Finalized
·
· Score: 1
Yeah, well, you took the bait and fed the trolls with all the cussing.
If an in-memory cache is too hard to work out, then just consider a "job" metaphor. To make a graph, you start a job. The list of currently running jobs is a global. If you detect that a job requests' parameters exactly match those of an in-flight job, you can just wait for that job to complete and return the results. Obviously, if the user changes his parameters for his second request, that would mean another job is fired off - in which case, you're in the same boat you're in now.
Whether it's your users resubmitting or a refreshing, doesn't matter: you're making your users wait too long and they think their connection has stalled so that's why they're trying again. I just hope you understand my main point, let it sink in: most users have expectations that a response should return in 1-4 seconds any click (you can thank Google for that.) Response time is a dragon you have to slay. I get that users give some apps some slack, and displaying a throbber helps, but at the outside, you should never make a user wait more than 15 or 20 seconds for any response.
But, if two or three concurrent requests can clog/kill your server, you're doing something wrong. Also, training your users that your webapp just "takes a long time" isn't a very effective approach - grumbly users will turn on you eventually. It's your job to keep users happy and keep your reputation spot-free.
I agree with the other poster, perhaps you need to invest in a BI solution. Or, take the graph generation process offline with queues and email if BI's out of your range. What you are describing does not sound workable; trust me, it's rethink time, and there's no shame in that because you're making things better.
Dave
Re:Tomcat is as rock solid as it gets
on
Tomcat 7 Finalized
·
· Score: 1
@roman_mir I'm sorry you got nasty responses to your post here. I've occasionally had to deal with the same kinds of issues, and I have come to terms with how to deal with the problem. As a rule of thumb, if a response takes time to generate and you're keeping your users waiting for more than 2 or 3 seconds, that's generally a sign that that work should be done as an asynchronous activity (like with a JMS queue for offline processing and the response going out to the user by email.) I don't think Threading tricks should be a regular weapon in your arsenal for this kind of problem, not worth the twizzling and inevitable bugs. Plus threading tricks don't scale up easily, and availability is probably the most important "-ility" we should be concerned with. Not to burst your bubble, try as you might, but IMHO brute force is usually not the answer.
Even so, there IS a class of problems on the web though that take a moderate amount of time to compute, so they can still be online activities, but consume a lot of CPU. I have to guard against users holding Refresh down and clobbering my Servlet worker threads. One strategy I employ is to use a distributed in-memory cache to store response payloads. If the user hits refresh, I don't go to the backend twice if I notice that the same request has already been launched and is in-flight to the cache - I just attach that response to the that entrant in the cache and put it to sleep.
If you're writing to a ServletOutputStream and you get a ClientAbortException, that means that you're writing to a socket that the user has closed (either they hit cancel or hit refresh). Do you ever see that? Perhaps there is something clever you can do with non-blocking extensions to decouple the servlet's socket handling from the backend processing to force TCP to tell you, while you're processing is still in-flight, that the user has canceled the request? I don't know if that's possible, because I've never tried it, but it might be something fun to experiment with.
Dave
Re:Tomcat is as rock solid as it gets
on
Tomcat 7 Finalized
·
· Score: 1
I disagree that Java's JVM is the sole reason Tomcat is the first choice for Java web containers. Look at some of the bug reports on the major commercial vendors' app servers, and you'll see just how complicated a situation it is to build out these JEE specs. Tomcat seems to avoid these kinds of exploits, and I think its a simple matter of: the team cares about security and they get massive feedback from the user base because they are so widely deployed.
Wow, you've had some problems with Tomcat! Truth be told, I haven't used plain Tomcat in years - I need JEE, so I run with Geronimo. But I wouldn't touch Geronimo with a 10 foot pole unless it ran atop Tomcat. Perhaps the way Geronimo embedded Tomcat fixed some issues with Tomcat when they embedded it? I've been doing NIO-based non-blocking servlets in my apps for years without failure. I run everything through the Http11NIOConnectorGBean, and all of my servlets got a massive performance increase just by configuring that.
As far as the code quality/architecture comments, I think you're probably right. Tomcat isn't the cleanest code. It's been so battle hardened, that I'll take it anyways. Tomcat is up there with JVM and Apache HTTPD in terms of trustiness for me.
Node.JS sounds interesting, and I agree JavaScript is a fun and productive language to write code in. I don't think I could deploy it however, the underlying binaries have a lot of new-ish moving parts which scare me away.
Dave
Tomcat is as rock solid as it gets
on
Tomcat 7 Finalized
·
· Score: 4, Interesting
Tomcat 6 has been a rock solid server for me for years. It's fast, it's easy to roll out, it can scale, and it's real tough to break. (Has it been cracked in the wild?) The non-blocking I/O extensions to the servlet spec were genius, and I wish other vendors had picked that feature up.
I look forward to much more goodness with Tomcat 7, sounds like there are tons of refinements to security and the codebase.
Oh, yes of course, in the Java Control Panel. You make a good point on controlling this from the browser. I recall a long time ago there was an "Enable Java" checkbox in the Firefox control panel alongside "Enable JavaScript", which is where I was coming from on that. Looking in my Firefox options panel, I see that checkbox is now gone. So, you are right, times two!:)
Seeing as how average users cannot be trusted to take care of themselves, I think disabling the default for users' granting permissions to applets would be the only responsible thing for Oracle to do!
My first attempt at a commercial website, CardMeeting, is built around a large, unsigned applet. Those "Grant, Deny?" dialog boxes are poison to anyone in the know, and I surely would never visit any site with them. Unsigned applets don't need any security warning dialog because they are untrusted and therefore will receive no privileged access to the user's system. Unsigned == heavily sandboxed. "Unsigned" sounds like a bad thing though, so that's something I could never tout to my users. But in reality, I was looking out for them!:D
I had a heck of a time figuring out how to get the CardMeeting applet jar packed up with scripts and making the applet "stream" data the way it does. Yeargh, I remember that pain. Anyhow, it makes me really sad that news like this may lead people to disable java applets; I think the unsigned form of applets is very powerful and much safer for average users than Flash ever was. I wish there was a way in the browser to disable only signed applets. Perhaps Oracle could bring the hammer down and go ahead and disable them by default in the next Java release.
My new website ClubCompy is 100% HTML+JavaScript. I wrote this whole simulated operating environment to teach kids to code with just the browser. I hope I don't start seeing people disable JavaScript on their browsers, then I'd be outta business!
ooh, that was not intentional, and is a bug. Very sorry, I honestly want IE9 to be great and was hoping to see scores for the new engine. I do not own windows 7 and msft refuses to backport to XP, so I haven't tested on ie9 beta. Again, sorry for the bug, didn't intend for there to be any bias.
Slashdot Mirror
ok, I know it's fashionable to pile on mozilla these days, however, in this case, I hope you'll be pleasantly surprised to find that mozilla is working with the w3c and google to standardize the concept. The eventual api they have just started to work on is currently being called the "gamepad" api.
Speed the death of Flash and speed the adoption of HTML5+JS as the goto client-side software development platform for most things. The Joystick API is amongst the greatest things coming out of this effort:
https://wiki.mozilla.org/JoystickAPI
Mozilla is doing good stuff here, buck up ppl!
Sigh ... I wondered when the Java plugin was finally going to poop out on us design-wise. Darn thing is so creaky and stuck in web 1.0-mode. Maybe it's time to port CardMeeting to HTML5...
This is a great point. Opera doesn't have a public bugtracker. I didn't know my website was having trouble on Opera until I saw it mentioned in the release notes on Opera 11.10.
Maybe there was something I could do to test and workaround my site freezing Opera, had I known there was an issue at all...
Mozilla's running a public bugtracker is commendable, heck you don't even need to sign up for an account to search for bugs!
But, writing great software is REALLY HARD TO DO! The 10-year old unfixed critical bugs and thousands of unconfirmed bugs is common. Mozilla just wears all that egg on it's face rather than hiding the egg under the trenchcoat like the other guys do.
Ultimately, Firefox will need another complete redesign and rewrite because it collapses under its own weight. Technology and ideas will move past it's current architecture. Sad but true. And then the whole cycle of awesomeness and suckiness can start again.
Your trolling is legendary, sir, you've won and now I'm responding.
Java's better than C++. It's more popular. It's better looking. It's more important.
That's not gloating, that's not religion, it's just the market who decided that years ago. You can get angry about it. Fight it if you want. But at the rate you're going with the smug dismissals, you're not gaining any converts.
I'm going to paste all of Lord_Naikon's retort, as what he said is just the tip of the Java iceberg:
I tried to write a cross-platform C++ open source library once and be one of the good guys in your book. You know what a treacherous, expensive, and painful process that was? All the compilers did templates differently, it was a delicate dance on fiery coals to get my code working for all my users on all platforms.
The best cross-platform build system I could find at the time should give a clue on just how shallow the C++ ecosystem is: java running ant with a C++ compiler exec helper plugin. The C/C++ community couldn't even offer me one decent cross-platform build system that didn't require a master's degree to run. There's nothing there there in the C++ world, no promotion nor adherence to any standards.
Where's C++'s TCK? Where's its JCP? I know you don't care about those things, but I thought I might ask!
We don't have passengers in the cockpit flying our commercial airline planes. We have expert pilots flying our planes who have thousands of hours logged training. It's too important to have just anyone flying planes, lives are at stake.
When it comes to software, it's nonstop amateur hour. There is hardly any urgency about the lives at stake when it comes to software.
In my estimation, there is very little robust native code, written large, in the world. QNX, the JVM, maybe Apache HTTP (although that seems creaky to me and the config system is a hot mess.)
The linux kernel seems robust to me based on how it's maintained, but I am not an expert. All of the browsers have some varying degree of swiss cheese holes to them, with giant attack surfaces, and poorly written plugins (including Java's.) I pity the security teams on those products.
I don't trust your native code. I hear people tout their soup du jour language/vm as robust, sane, battle hardened. The more shared libraries and DLL's your code relies on, the less I believe you. If your favorite system easily/readily/commonly links in more native code as it rolls along, then I hope you understand that your battle hardened tank has cheese cloth armor that should never go to war.
I don't trust Microsoft code, especially their new products - a permanent bullseye is tattooed on their hineys. Yes, they've made security advances in recent years, they're still horribly vulnerable due to the legacy baggage which is core to their business. Microsoft code is bubbly poison at its deep, dark, dank core. IE is terrifying to me.
When it comes to me, I consider the code I write to have my name attached to it. Why wouldn't I give myself every opportunity to look good? A crash bug in native code to me is the most serious form of professional failure.
Maybe a lot of you just tinker and love your micro-optimizations in C and Assembly. Good for you, go spin that propeller on the beanie on your head, very neat. If you write for games or embedded systems and need the speed of native code, fair enough, but I'm dubious C# or Java isn't fast enough for most of that. Otherwise, please, PLEASE stay out of the native code cockpit when it comes to commercial/professional work unless you've got your thousands of hours of flight training. Lives are at stake.
We use Cassandra for all the user management and virtual file system storage at ClubCompy, It is so blazing fast compared to SQL for both read and writes, and it is very scalable. I've had a node of my storage cluster go down and whole system stays up with no data loss, and it can repair itself once I bring the downed node back up.
Coding to Cassandra is pretty challenging, you have to do all of your data modeling in code or use the new CQL to access the cluster. I wrote about my experiences recently, where I have started using Google's Protocol Buffer to give me more flexibility in how I store my data and describe my column families: Coding to Apache Cassandra with Google's Protocol Buffers
Dave
You want to know what is total crap? Productivity with the GUI on Linux if you avoid mousing. The out-of-the-box twisty tree control widget on Gnome is garbage. The standard keybindings and way it handles focus in and out -- now THAT is total crap!! Biggest complaint: left and right should expand and collapse where selected, GET IT?! Left-right gives me horizontal scrolling today on Gnome. Why? My keys on Gnome for expand/collapse: shift+left/right (and those bindings don't seem to work consistently across applications.) Why a modifier key?? Up and down work right in Gnome, that moves the selection up and down, which in turn can cause the control to scroll vertically, as needed. Why not be uniform in how to traverse? And I'm sure these infuriating defaults totally screw accessibility for people that have trouble with modifiers.
Quite honestly, I don't even care to have keyboard control over horizontal scrolling in a tree control; that's how Windows works and I usually fare okay with it. But, if you want to be a total geek and be different, you could make shift+left/right the new horizontal scroll and make left/right the new expand/collapse/traverse child and smooth out the behaviors a bit.
There's so many little UI nigglers I've run into like the darn tree control that just act badly or feel klunky on Linux that I hate to work on rich UI's there, it just doesn't flow. In that regard, for many of the small touches, I'd say windows is better and more productive; someone there cares (or cared long, long ago.)
You want an operating environment that goes beyond the command line and is productive enough to court away windows users who care? Then you need to deep dive on every geek legacy GUI design decision across the board and fix every klunky feeling part of the default widget set.
But no, I wager you don't really want new users on the GUI, do you? Just keep on thinking you're better and keep on boring everyone with that whole line, no need for humility, oh no.
P.S. Oh, and bring back Multiple Document Interface as a promoted standard UI design for apps, that was the productivity bomb. Sad to see that one go by the wayside in Microsoft circles. Alt+Tab to go between processes, Ctrl+Tab to go between child windows. Genius.
I'm more optimistic about kid's chances for learning with BASIC-like languages. BASIC programs tend to be small and spaghettified. Trying to build a large BASIC program usually yields something that will collapse under the weight of its own complexity. BASIC is something to chafe against and grow out of.
I can't tell you how often the alarmist/purist message of "GOTO is evil!!!!!!!!!1!!!!" reached my ears when I was a little guy. I got that message and processed it, and ultimately understood the wisdom of it. I trust the same thing would happen today if kids were in a similar situation. I just think we coddle our next generation that is SO primed for great things. If only we'd just challenge them.
I was the same way, brother. Type-in games in BASIC on the C64 were the draw because my family was too poor to buy Atari games, and that experience got me hooked. Of my own volition, I went straight to TurboPascal when I outgrew Basic and 6502 Assembly, then Quick C then C++ in college, and for career I was all set for systems-level C++ and later Java/Java EE. Got an enjoyable and profitable career out of the deal.
Tell me what the equivalent path is for kids today? Is drag and drop coding the way to get them hooked? I'm not yet sold on that... It's too flashy and too shallow. Hm, well, maybe not too shallow - that experience teaches good handling of media files, and there is a lot of value there these days. But as a programming tool, I find those systems de-emphasize the use of logic and the building of abstractions and the construction of data structures and of encouraging the development of problem solving, which is the whole point of learning to program. I feel like we're going to lose our edge and have less qualified replacements coming up - worldwide, not just here in the states.
So how about ClubCompy? It's got a BASIC-like language, nostalgic for us 8-bit veterans. The character generator is my favorite part to dink around with. Sprites are my second favorite now that the collision detection is working properly, and it's got 256 sprites instead of just 8!
https://clubcompy.com
Check out the demos on the homepage and the benchmark page.
Disclaimer: I need to mention that ClubCompy's my site. ;)
Well, we're trying to produce a facsimile of your intro to programming at ClubCompy. The point of the site is to create a simple computer simulation coupled with a BASIC-like language that kids can pick up easily. And we are working on a monthly newsletter that will be a companion on the site. If you sign up for an account, you can even SAVE and LOAD your programs.
You can see an example of what it's capable of doing at the Real-World Benchmark, which gives some sample programs you can type in with the kiddos!
Dave
I hope you're happy, I hope you're satisfied. YOU WIN, you evil, evil man. I'm of course referring to the Double Team map in PixelJunk Monsters on Hardcore. I'm sure it's possible to beat, but I am not good enough, twitchy enough, clever enough, nor evil enough to get my G.D. double f'ing rainbow on that level!
Gar, I want that double rainbow, It's so mean to dangle that carrot just outta my reach.
Our Real-World HTML5 Benchmark at ClubCompy had a Julia set running in the browser a full month ago!
It's not a fair comparison though that they're so much faster than us, our code runs out of a BASIC-like language called Tasty that runs ATOP JavaScript.
I bring shame into it because you obviously get snippy when anyone comes close to hitting a nerve. If you've got the architecture of last resort or whatever and your clients are just so thankful they have what they have, good for you. I've encountered plenty of examples of people like yourself in my travels and a lot of 'em can just ride that wave for years until it crashes. Hang ten.
And I do know your business. Reporting, db's, Java, enterprise apps? It's like, uhm, I've been doing that for 12 years across 5 different industry categories for the consulting firm I work for. Ha, I'm dealing with retail right now! And, I've done POS and ecommerce for retail clients in the past.
If I produced a system that had performance characteristics like what you're describing, our clients would terminate our contracts. Before consulting, I was doing C++ and assembly systems-level stuff for another 6 years. So I know what brute force looks like, and I know what finesse looks like. Don't get cocky and think you have anything special or revolutionary there, there's no secret sauce anymore.
And I can't stand it ... it's CACHING! Not cashing. Sorry, but I couldn't let that slide.
Yeah, well, you took the bait and fed the trolls with all the cussing.
If an in-memory cache is too hard to work out, then just consider a "job" metaphor. To make a graph, you start a job. The list of currently running jobs is a global. If you detect that a job requests' parameters exactly match those of an in-flight job, you can just wait for that job to complete and return the results. Obviously, if the user changes his parameters for his second request, that would mean another job is fired off - in which case, you're in the same boat you're in now.
Whether it's your users resubmitting or a refreshing, doesn't matter: you're making your users wait too long and they think their connection has stalled so that's why they're trying again. I just hope you understand my main point, let it sink in: most users have expectations that a response should return in 1-4 seconds any click (you can thank Google for that.) Response time is a dragon you have to slay. I get that users give some apps some slack, and displaying a throbber helps, but at the outside, you should never make a user wait more than 15 or 20 seconds for any response.
But, if two or three concurrent requests can clog/kill your server, you're doing something wrong. Also, training your users that your webapp just "takes a long time" isn't a very effective approach - grumbly users will turn on you eventually. It's your job to keep users happy and keep your reputation spot-free.
I agree with the other poster, perhaps you need to invest in a BI solution. Or, take the graph generation process offline with queues and email if BI's out of your range. What you are describing does not sound workable; trust me, it's rethink time, and there's no shame in that because you're making things better.
Dave
@roman_mir I'm sorry you got nasty responses to your post here. I've occasionally had to deal with the same kinds of issues, and I have come to terms with how to deal with the problem. As a rule of thumb, if a response takes time to generate and you're keeping your users waiting for more than 2 or 3 seconds, that's generally a sign that that work should be done as an asynchronous activity (like with a JMS queue for offline processing and the response going out to the user by email.) I don't think Threading tricks should be a regular weapon in your arsenal for this kind of problem, not worth the twizzling and inevitable bugs. Plus threading tricks don't scale up easily, and availability is probably the most important "-ility" we should be concerned with. Not to burst your bubble, try as you might, but IMHO brute force is usually not the answer.
Even so, there IS a class of problems on the web though that take a moderate amount of time to compute, so they can still be online activities, but consume a lot of CPU. I have to guard against users holding Refresh down and clobbering my Servlet worker threads. One strategy I employ is to use a distributed in-memory cache to store response payloads. If the user hits refresh, I don't go to the backend twice if I notice that the same request has already been launched and is in-flight to the cache - I just attach that response to the that entrant in the cache and put it to sleep.
If you're writing to a ServletOutputStream and you get a ClientAbortException, that means that you're writing to a socket that the user has closed (either they hit cancel or hit refresh). Do you ever see that? Perhaps there is something clever you can do with non-blocking extensions to decouple the servlet's socket handling from the backend processing to force TCP to tell you, while you're processing is still in-flight, that the user has canceled the request? I don't know if that's possible, because I've never tried it, but it might be something fun to experiment with.
Dave
I disagree that Java's JVM is the sole reason Tomcat is the first choice for Java web containers. Look at some of the bug reports on the major commercial vendors' app servers, and you'll see just how complicated a situation it is to build out these JEE specs. Tomcat seems to avoid these kinds of exploits, and I think its a simple matter of: the team cares about security and they get massive feedback from the user base because they are so widely deployed.
Wow, you've had some problems with Tomcat! Truth be told, I haven't used plain Tomcat in years - I need JEE, so I run with Geronimo. But I wouldn't touch Geronimo with a 10 foot pole unless it ran atop Tomcat. Perhaps the way Geronimo embedded Tomcat fixed some issues with Tomcat when they embedded it? I've been doing NIO-based non-blocking servlets in my apps for years without failure. I run everything through the Http11NIOConnectorGBean, and all of my servlets got a massive performance increase just by configuring that.
As far as the code quality/architecture comments, I think you're probably right. Tomcat isn't the cleanest code. It's been so battle hardened, that I'll take it anyways. Tomcat is up there with JVM and Apache HTTPD in terms of trustiness for me.
Node.JS sounds interesting, and I agree JavaScript is a fun and productive language to write code in. I don't think I could deploy it however, the underlying binaries have a lot of new-ish moving parts which scare me away.
Dave
Tomcat 6 has been a rock solid server for me for years. It's fast, it's easy to roll out, it can scale, and it's real tough to break. (Has it been cracked in the wild?) The non-blocking I/O extensions to the servlet spec were genius, and I wish other vendors had picked that feature up.
I look forward to much more goodness with Tomcat 7, sounds like there are tons of refinements to security and the codebase.
Thank you Apache and thank you Tomcat team!
Dear Tim,
Please backport IE9 to Windows XP. My preciousss needs to run good on IE on XP, etc.
Thanks in advance,
Dave Woldrich
https://clubcompy.com/
Oh, yes of course, in the Java Control Panel. You make a good point on controlling this from the browser. I recall a long time ago there was an "Enable Java" checkbox in the Firefox control panel alongside "Enable JavaScript", which is where I was coming from on that. Looking in my Firefox options panel, I see that checkbox is now gone. So, you are right, times two! :)
Seeing as how average users cannot be trusted to take care of themselves, I think disabling the default for users' granting permissions to applets would be the only responsible thing for Oracle to do!
My first attempt at a commercial website, CardMeeting, is built around a large, unsigned applet. Those "Grant, Deny?" dialog boxes are poison to anyone in the know, and I surely would never visit any site with them. Unsigned applets don't need any security warning dialog because they are untrusted and therefore will receive no privileged access to the user's system. Unsigned == heavily sandboxed. "Unsigned" sounds like a bad thing though, so that's something I could never tout to my users. But in reality, I was looking out for them! :D
I had a heck of a time figuring out how to get the CardMeeting applet jar packed up with scripts and making the applet "stream" data the way it does. Yeargh, I remember that pain. Anyhow, it makes me really sad that news like this may lead people to disable java applets; I think the unsigned form of applets is very powerful and much safer for average users than Flash ever was. I wish there was a way in the browser to disable only signed applets. Perhaps Oracle could bring the hammer down and go ahead and disable them by default in the next Java release.
My new website ClubCompy is 100% HTML+JavaScript. I wrote this whole simulated operating environment to teach kids to code with just the browser. I hope I don't start seeing people disable JavaScript on their browsers, then I'd be outta business!
Dave
if you have chromeframe installed, then club compy will take advantage of that
so detailed! Merry christmas, indeed!
ooh, that was not intentional, and is a bug. Very sorry, I honestly want IE9 to be great and was hoping to see scores for the new engine. I do not own windows 7 and msft refuses to backport to XP, so I haven't tested on ie9 beta. Again, sorry for the bug, didn't intend for there to be any bias.
hah! My wife's macbook does the same thing ever since we upgraded her to snow leopard. Thanks for the fun story. :)