I second processing. Also, if his project is going to be in HTML/HTML5, he should check out the javascript successor to processing.org, which is d3.js.

Oh dear. That seems like quite a muddled way to view web development. But who am I to say? If you wish to use a confused metaphor, that's your prerogative. :shrug: From my own experience, the HTML/CSS/Javascript translation as Model/View/Controller works like a charm, and helps me keep everything very orderly and organized. Are you using HTML5?

Also, probably too late for this overall conversation, but in case you're interested, it just occurred to me where the strongly typed data types are in the HTML5/Javascript paradigm... in the HTML5! There are specific data-type and data-role attributes you can give to tags in HTML5. So, if you need strongly typed variables in you web application, all you would need to do is write a single javascript function, probably using jquery selectors, to locate the 'data-type' and 'data-role' elements in the HTML5 tag, and perform whatever type checking you want. Then you just reuse that javascript function in all of your event code and callback code.

First, get thee Aptana for development.

Second, download thee jQuery. I would also recommend jQuery Mobile and jQuery.tools.

Third, dig around in jquery until you find qunit for unit testing.

Fourth, do a refresher on Lisp and functional languages. They say that javascript got it's fathers curly braces and it's mothers lexical scope. It may *look* like C/C++/Java, but under the hood is ActionScript ala Scheme ala Lisp. And it a very real difference which gets played out in copious usage of events and callback functions. As a refresher, the HTML5 paradigm is basically an MVC paradigm, where HTML is handling the Model, CSS is handling the View, and Javascript is handling all the controller functions. Phrased differently, the HTML is describing the What is displayed; CSS is describing How it should be displayed, and Javascript is describing When it should be displayed. And the When gets implemented as callbacks and events. And it just so happens that functional languages are ideally suited for that kind of work (ala lambda calculus, etc).

Lastly, if you're brave, check out Node.js.

Mod parent up! This is a strong move by Twitter to contain censorship, track it, and route around it. We should be glad for the work they've done!

Agreed. Twitter is taking a strong stance against censorship today and providing a checks-and-balances approach to censorship. They are containing censorship, rather than allowing global blackouts. They're actively tracking censorship and then routing around it. There is wide spread misunderstanding here.

Mod parent up! Twitter is making lemonade from lemons here.

Mod parent up! Cultural relativism is a fact. International groups can claim that human rights like free speech are universally applicable, but an Ebola outbreak, zombie apocalypse, nuclear holocaust, or a planet smashing comet is all that it will take to send us back to feudalism and might-makes-right morality. We may advocate for treating free speech as a universal right; but as long as other nations have the might to protect their borders and claim their own sovereignty, they can make their own laws. Including ones that involving censorship. The claiming that a free speech is universal is, itself, a morally and culturally relative act.

Mod parent up! This is a strong move *against* global censorship on Twitter's part; while at the same time respecting local laws and tracking censorship activities. They've made lemonade from lemons.

Mod parent up!

I'm sure Adam Bosworth is a nice guy and all, and is a very competent developer. But from what I understand, his claim to fame is being one of the pioneers of XML. That's nice and all; and from a storage perspective, it gives a company an approach to handling many different types of data. But from a clinical usability perspective, Bosworth and team simply didn't understand the needs of the patients or the marketplace. The UI of Google Health was, if possible, even worse than that of Centricity and Cerner. They simply had no idea what the UI challenges are of patient medical records; nor of the use cases and workflows between clinicians and patients.

The OSI 7 Layer Networking Model is very informative in this kind of product. Google Health was basically just a database layer technology. It had no presentation or application layer functionality. And a health record will live and die by it's presentation and application layers, because that's the UI by which the patient will interact with it.

Call 911, and ask that they send police to the location immediately. Report that you suspect a person or a group of people impersonating the TSA, and that you suspect a fraud or mugging is about to occur.

Now this I can agree with. User validation doesn't cut it. It's going to take a company with Apple like design skills and resources to show people what's possible. To say 'this is what you've always wanted, but just didn't know how to build'. That company hasn't come along yet. But when they do, they'll offer solutions to problems that people didn't know they had. And by that, I mean addressing things like how to visualize and interact with ontologies of 50,000+ choices in an intuitive manner. (My guess is mapping and cartography technologies, applied to human atlas/avatar; bundled with search and filtering technologies). People think that their problems are with 'user interfaces' and 'electronic medical records'; when, in hind sight, we'll say that the problems were with ontology mappings, taxonomy searches, medical renderings, longitudinal displays, and the like.

And you're totally right about the small frys on the other end of the spectrum. They're causing half the headaches, no doubt.

It's been about that long since I've worked with EPIC; more recently with Cerner. Nonetheless, I think we have substantially different expectations of what an EMR can and should be. Note that, by your own words, you admit that the UI of EPIC is as good and simple as the people who build it for the hospital want it to be. Not the people who work at the hospital want it to be. It seems to me that the EPIC UI is as good as the people who work at the hospitals will tolerate. The people at the hospital would prefer to have some Star Trek type EMR with tricorders and automated diagnostics. EPIC and Cerner are not that.

I have yet to see a modern EMR come bundled with an anatomical Atlas of the human body, which coregisters a patients scans, blood work, and medical history with a virtual avatar. Until we get to that point, all EMRs and PHRs are lacking and have shoddy interfaces. Google was half way there with Google Body, but they've since scrapped their Google Health product. That's a long story unto itself, involving having their XML expert design the health product, and not understanding their target market needs. But they recognized the need for the atlas to coregister data to, and that it will eventually be a primary interface to EMR and PHRs.

Not being able to add employees fast enough isn't necessarily a sign of a good system.

The story goes that Milton Friedman was once taken to see a massive government project somewhere in Asia. Thousands of workers using shovels were building a canal. Friedman was puzzled. Why weren't there any excavators or any mechanized earth-moving equipment? A government official explained that using shovels created more jobs. Friedman's response: "Then why not use spoons instead of shovels?"

The point being that adding laborers doesn't translate into a better product. In fact, not being able to add employees fast enough and turning away clients seems like a clear sign of scaling problems, training problems, and user interface problems. And just because they're first in the KLAS rankings doesn't mean that they're any good at improving patient health.

Now that's not to say that they fill their role as hospital practice management systems. But the fact of the matter is that hospitals are big money, and attract their own types of politics and special interests. And these KLAS rankings are about just that: politics, special interests, funding, sales, and so forth. Hospitals need practice management systems, and they need a way to evaluate different systems, and Cerner and Epic have put the most work into being on the top of the pile right now. But their systems are horribly designed.

And don't get me started on Cache. It's only redeeming quality is that it's not a relational database. But seriously? MUMPS? You're saying that we should continue deploying health care systems based off MUMPS? I'm sorry, but we've learned a few things in the past 40 years since M/MUMPS was originally created. Now then, I'll concede that object and document oriented databases are the way to go with regards to databases in healthcare. And in that regard, systems based off of Cache at least have that going right for them, and is why they've got the market share. But mark my words: a vendor is going to come along with a modern HTML5 product based off of a next-generation database, and it's going to be transformative. I don't know what that database will be... Cassandra, Hadoop, BigTable, Redis, or what. But when it finally happens, it's going to be the Facebook and Google of healthcare.