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 see what you did there. If I had any mod points, I'd give one to you.

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.

No, faith is a belief in something which is either not understandable or for which no evidence exists. Trust is, in part, a belief in something you don't understand. The two should not be confused - they are not synonymous.

I don't have faith in the scientific process; I trust it. I don't trust it to be infallible, but I do trust it to be self correcting and to trend towards generating increasingly accurate models of the issues under study.

I have known preachers and ministers whom I trusted. They were good people, earnest in their beliefs. I did not and do not share their faith in religion, but that doesn't stop me from trusting them as individuals.

No, it isn't. They're a government entity, not a private entity and courts, including the SCotUS, have already ruled that public employers have limits to what rules they can enforce.

http://www.workplacefairness.org/retaliationpublic

Banning "anything negative or embarrassing" would include many things that are of "public concern" and be over the legally established lines of what public employers may do.

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!