Remember, the government has been using document-oriented NoSQL databases for some 40 to 50 years with MUMPS, the database in VistA, the Veterans Administration EMR. NoSQL databases have been a go-to technology solution for government healthcare projects for decades.
MUMPS is more like Mongo, but yes... both MarkLogic and MUMPS are document-oriented databases. The MUMPS record, in my opinion is a bit more like JSON than XML, but it's the same basic concept.
Remember, the government has been using document-oriented MUMPS databases for some 40 to 50 years in VistA, the Veterans Administration EMR. NoSQL databases have been a go-to technology for government healthcare applications for decades.
The problem, of course, being that MUMPS has some serious flaws with regard to it's integrated language M, and they don't want to *actually* use MUMPS for any new projects. What they were doing was betting on a NoSQL technologies to replace MUMPS. They were hoping to find something that had all the benefits of MUMPS, but not the drawbacks and problems. Unfortunately, XML was probably not the answer.
I'm keeping my fingers crossed that JSON and MongoDB will be the eventual successors of MUMPS.
Remember, the government has been using document-oriented MUMPS databases for some 40 to 50 years in VistA, the Veterans Administration EMR. NoSQL databases have been a go-to technology for government healthcare applications for decades.
Actually, the government has been using document-oriented NoSQL databases for some 40 to 50 years with MUMPS, the database in VistA, the Veterans Administration EMR. The US has been running NoSQL MUMPS healthcare systems for 40 years for the US Military.
Hey, now.:)
Don't be hating on MongoDB. It's actually got all the good points of MUMPS, without any of the baggage. It's liable to be a big hit in healthcare and EMR systems in the future. Remember, the government has been using document-oriented NoSQL databases for some 40 to 50 years in VistA, the Veterans Administration EMR. They've been running NoSQL MUMPS systems for 40 years.
Actually, the government has been using document-oriented NoSQL databases for some 40 to 50 years in government run EMR systems, by way of MUMPS. Specifically, check out VistA which is run by the Veterans Administration, and is considered by many to be the largest and oldest healthcare network in the US.
Mongo's console is a javascript interpreter. The folks at 10gen seem to have been the first (only?) modern NoSQL development group to have the blindingly obvious realization that javascript would be the ideal interpreter language for their database. The rest has been history....
I think there's a good chance it will. Just remember that Javascript is based on Actionscript, based on Scheme, based on Lisp. It's actually got a a much better pedigree than most people realize. It implements the lambda calculus wherever there is a web browser. That's pretty much exactly what it needs to do to 'win the wars'. Be ubiquitous and support the lambda calculus. Everything else is just syntax.
In all seriousness, this is an insightful comment. I tend to make the analogy that LAMP stacks are like prop propeller airplanes, whereas Javascript/Mongo frameworks (like Meteor) are akin to Jet Turbines. If you want to break the sound barrier, a propeller airplane simply won't do the job. But a jet can.
Overrated. Most use cases don't need proper relational theory. Convergence to consistency is sufficient for most people's needs. Denormalized DRY data is less important now that memory is plentiful. Speaking as somebody who was an SQL admin for 10+ years, and am happy to have made the leap to Map/Reduce and won't ever be looking back.
That's changing rapidly. Lots and lots of active development with REST libraries, and a number of packages providing that functionality becoming mature.
I'm a Meteor developer, using full-stack Javascript 100% of the time... Node.js, MongoDB, and jQuery are my stock in trade. If you're not familiar, Meteor is basically 'Javascript on Rails'. And, in my experience, everything in the article is spot on. As to the jaw-dropping abilities...
- developing in a unified language has increased my productivity 5x to 10x. I get done in a weekend what used to take me a month or more to do in PHP or C#. That's jaw dropping from a business sense, and has allowed me to completely change my business structure and approach. Frameworks like Meteor and Derby are going to win out on productivity gains alone. I can go from an initial client meeting to launching a beta of a multi-user application in a weekend.
- remember that javascript is based on actionscript, based on scheme, based on lisp. When you have your client, server, and database all using a functional language, you can start creating UI elements as monad operations on datastore elements. No objects ever on the heap. Just chained functions from database to server to client to UI. Among other things, this allows for things like reactive templates, demonstrated in the following screencast:
- besides the reactive templates, sharing of libraries between client and server makes every Meteor application theoretically capable of becoming a peer-to-peer distributed application. No PHP or Ruby or C# web application can do that. In theory, you could bundle the node.js libraries themselves into the client, and have each served client become a new peer-to-peer node.
- this allows mesh networking functionality, with monad operations defining computations between and through nodes. Think of it like routing protocols, but with computations. Lots of distributed computing possibilities here, obviously. More importantly is bandwidth usage, offline data synchronization, and the like. Instead of going to a data center to get the latest package updates, applications will be able to query neighbor nodes. Think IPv6 functionality, mesh networking, and being able to query data states from intermediary peers. The people in the Meteor dev community are actively working on things ranging from meters for smart energy grids to real-time bee pollination tracking.
Those technical details aside, the underlying reason why pure javascript can result in jaw-dropping applications is because, at it's core, javascript is a functional language, in the manner of lisp (if you know how to use the lambda calculus). It's lisp for the web (or scheme for the web, if you prefer). And putting it on both the server and client and database allows developers to do crazy monad calculations and method chaining. The monads will update and recalculate themselves in real time, as the underlying data changes. The end result is reactive templates and data-driven animations and UI elements.
If you want a better understanding how this is going to play out, check out the D3 visualization library here:
Exactly. Some of us are already programming applications with this in mind. I've normalized my virtual servers at... 256mb disk size; the websites are reactive layouts that adjust from 320x480 pixel cellphone sized displays to 3 megapixel thunderbolt displays and more; navigation is tied to keyboard shortcuts that can be mapped to haptics... be it mouse clicks, taps, swipes, or sign language.
Now days, my travel kit includes my iPad, a wireless bluetooth keyboard (solar), and an HDMI adapter. I go to friends houses, and simply connect to their HDMI hi-res television. If I want to do mobile development on the go, I grab my Mac Mini and do the same thing. HDMI is the best connector *ever*, and anybody who doesn't have an HDMI connector and wireless keyboard for their tablet is simply not groking the ergonomics of tablet portability.
Recently went through this myself. Despite having used a kanban board, used version control, commented code, written unit tests, etc, some junior devs thought the code sucked. My takeaway was that there were still too many barriers to entry. Too many passwords, not enough installation instructions, etc.
Somewhere in the process of learning to write production ready code, it occurred to me that it was necessary to work the process backwards. Begin a project by setting up your hosting or distribution environment before starting to code. Write unit tests before starting to code. And so forth.
Getting other people to contribute to your project requires the same kind of thinking. Set up a project page before you start to code. Write a vision statement before you start to code. Write installation instructions, coding style guidelines, and operations support instructions before you start to code. That way, as you proceed in the project, you have clearly build up the documentation that other people are going to need to join your project. These things shouldn't be started after the fact.
If you can't point a new dev to a website and say 'download the source and instructions' here, it's probably too complicated and will meet resistance.
What does the flow into and out of science have to do with anything? Migration is one of the four basic mechanisms of evolutionary change, along with natural selection, mutation, and genetic drift. Ideas flowing into and out of science is perfectly consistent with migration and Cultural Evolution models.
As for memes, I kindly recommend memegenerator.net, in all it's lowest-common-denominator glory, and the iPhone and Android app stores. Memes, like genes, are ubiquitous. The reason they don't seem to exist is because they're everywhere.
Wrote my senior thesis on Kuhn, positivism, etc nearly 10 years ago. My take away was that scientific and theoretical advances get disseminated throughout society. Ergo, a population undergoes memetic evolution. Drawing on biology, the obvious model is one of punctuated equilibrium. Once one reconciles the ideas of paradigm shifts with punctuated equilibrium, it becomes pretty evident how technology evolves, science is disseminated, differing rates of change in different fields, etc. All one has to do is look at the iPhone, iPad, and Leap to see modern paradigm changes in action. (Protip: The language we use to describe the punctuated equilibrium changes of the human species is that of stock markets, marketing, and market analysis.)
I don't buy it. The package is addressed to 1101 East 58th Street. That's the UChicago Administration and Admissions office address. No way. It's obviously a College application. And a good one too! Somebody has a sense of aesthetics. Probably someone wanting to go into Art Preservation or Museum Curratorship. Maybe Egyptology or Paleontology.
Performance art? It's obviously an application to the College (received in December, duh). Among some alumni, bets on the declared major range from Art Restoration & Museum/Library Curation to Archeology, Egyptology, & Paleontology. I almost went into Paleontology. One of my best friends has a B.A. in Egyptology. I have a half-dozen acquaintances I know who focused in various Museum/Library curator positions. It could be any.
As a UChicago grad, I think the answer is obvious. It was delivered to the Admissions office during the month of December. It's an application to the college. The Admissions office would just like to know who it's from!:)
It's daring, if somewhat obvious. But to my knowledge, it hasn't actually been done before. It was bound to happen eventually, however. I'm just kind of surprised it took this long, in fact. Whoever sent it will obviously get in if they have a modicum of academic ability or talent. It's exactly the kind of nerdy stunt, with an appreciation for aesthetics, that UChicago appreciates.
I see it differently. I see it as an issue of encapsulation. The issue is whether one is going to encapsulate the parallelism inside of a thread, or inside a machine, or inside a network. From an operations perspective, a thread is usually an opaque black-box, with few controls for the operations team to manage whether they want to scale a process up or down, add extra resources, migrate to different hardware, do disaster recovery fail over testing, etc. And having been in operations for many years, I like to expose controls in my application designs that allow operations to manage those parallelism features. And so, when it comes to encapsulation, I tend towards encapsulating parallelism with a hypervisor, rather than with a thread.
The idea isn't to just scale *hardware* (although that's one way of doing things). Rather, scale the virtual nodes within a hypervisor environment. Then, if you're using a 32 core server, run 31 virtual node servers, with each node server running on one core, and with one optimized dedicated thread per CPU. The last core gets used by the hypervisor itself to manage inter-node infrastructure. The end result is a virtual network running on a multi-core server, and is essentially just this generation's version of a mainframe architecture.
There are, of course, pros-and-cons to this approach. Some things you gain, while others you loose. But as far as scaling goes, one doesn't need to scale hardware to use parallelism. Just need to have a hypervisor with some micro-sized virtual machines. I like to keep my virtual machines running node.js at about 256mb of disk space. But when the time comes to go parallel with hardware, everything is already set up to.
Slashdot Mirror
Remember, the government has been using document-oriented NoSQL databases for some 40 to 50 years with MUMPS, the database in VistA, the Veterans Administration EMR. NoSQL databases have been a go-to technology solution for government healthcare projects for decades.
http://en.wikipedia.org/wiki/Mumps [wikipedia.org]
http://en.wikipedia.org/wiki/VistA [wikipedia.org]
MUMPS is more like Mongo, but yes... both MarkLogic and MUMPS are document-oriented databases. The MUMPS record, in my opinion is a bit more like JSON than XML, but it's the same basic concept.
5 years? The government has been using document-oriented NoSQL MUMPS databases for some 40 to 50 years in VistA, the Veterans Administration EMR.
http://en.wikipedia.org/wiki/Mumps
http://en.wikipedia.org/wiki/VistA
Remember, the government has been using document-oriented MUMPS databases for some 40 to 50 years in VistA, the Veterans Administration EMR. NoSQL databases have been a go-to technology for government healthcare applications for decades.
http://en.wikipedia.org/wiki/Mumps
http://en.wikipedia.org/wiki/VistA
The problem, of course, being that MUMPS has some serious flaws with regard to it's integrated language M, and they don't want to *actually* use MUMPS for any new projects. What they were doing was betting on a NoSQL technologies to replace MUMPS. They were hoping to find something that had all the benefits of MUMPS, but not the drawbacks and problems. Unfortunately, XML was probably not the answer.
I'm keeping my fingers crossed that JSON and MongoDB will be the eventual successors of MUMPS.
Remember, the government has been using document-oriented MUMPS databases for some 40 to 50 years in VistA, the Veterans Administration EMR. NoSQL databases have been a go-to technology for government healthcare applications for decades.
http://en.wikipedia.org/wiki/Mumps
http://en.wikipedia.org/wiki/VistA
Actually, the government has been using document-oriented NoSQL databases for some 40 to 50 years with MUMPS, the database in VistA, the Veterans Administration EMR. The US has been running NoSQL MUMPS healthcare systems for 40 years for the US Military.
http://en.wikipedia.org/wiki/Mumps
http://en.wikipedia.org/wiki/VistA
Hey, now. :)
Don't be hating on MongoDB. It's actually got all the good points of MUMPS, without any of the baggage. It's liable to be a big hit in healthcare and EMR systems in the future. Remember, the government has been using document-oriented NoSQL databases for some 40 to 50 years in VistA, the Veterans Administration EMR. They've been running NoSQL MUMPS systems for 40 years.
http://en.wikipedia.org/wiki/Mumps
http://en.wikipedia.org/wiki/VistA
Actually, the government has been using document-oriented NoSQL databases for some 40 to 50 years in government run EMR systems, by way of MUMPS. Specifically, check out VistA which is run by the Veterans Administration, and is considered by many to be the largest and oldest healthcare network in the US.
http://en.wikipedia.org/wiki/Mumps
http://en.wikipedia.org/wiki/VistA
Mongo's console is a javascript interpreter. The folks at 10gen seem to have been the first (only?) modern NoSQL development group to have the blindingly obvious realization that javascript would be the ideal interpreter language for their database. The rest has been history....
I think there's a good chance it will. Just remember that Javascript is based on Actionscript, based on Scheme, based on Lisp. It's actually got a a much better pedigree than most people realize. It implements the lambda calculus wherever there is a web browser. That's pretty much exactly what it needs to do to 'win the wars'. Be ubiquitous and support the lambda calculus. Everything else is just syntax.
Word. +1
Some people like riding a chopper. :)
In all seriousness, this is an insightful comment. I tend to make the analogy that LAMP stacks are like prop propeller airplanes, whereas Javascript/Mongo frameworks (like Meteor) are akin to Jet Turbines. If you want to break the sound barrier, a propeller airplane simply won't do the job. But a jet can.
Overrated. Most use cases don't need proper relational theory. Convergence to consistency is sufficient for most people's needs. Denormalized DRY data is less important now that memory is plentiful. Speaking as somebody who was an SQL admin for 10+ years, and am happy to have made the leap to Map/Reduce and won't ever be looking back.
+1 Wish I had mod points.
That's changing rapidly. Lots and lots of active development with REST libraries, and a number of packages providing that functionality becoming mature.
Why would you deploy the back-end to the users??????
Peer-to-peer networking applications.
I'm a Meteor developer, using full-stack Javascript 100% of the time... Node.js, MongoDB, and jQuery are my stock in trade. If you're not familiar, Meteor is basically 'Javascript on Rails'. And, in my experience, everything in the article is spot on. As to the jaw-dropping abilities...
- developing in a unified language has increased my productivity 5x to 10x. I get done in a weekend what used to take me a month or more to do in PHP or C#. That's jaw dropping from a business sense, and has allowed me to completely change my business structure and approach. Frameworks like Meteor and Derby are going to win out on productivity gains alone. I can go from an initial client meeting to launching a beta of a multi-user application in a weekend.
- remember that javascript is based on actionscript, based on scheme, based on lisp. When you have your client, server, and database all using a functional language, you can start creating UI elements as monad operations on datastore elements. No objects ever on the heap. Just chained functions from database to server to client to UI. Among other things, this allows for things like reactive templates, demonstrated in the following screencast:
http://meteor.com/screencast
- besides the reactive templates, sharing of libraries between client and server makes every Meteor application theoretically capable of becoming a peer-to-peer distributed application. No PHP or Ruby or C# web application can do that. In theory, you could bundle the node.js libraries themselves into the client, and have each served client become a new peer-to-peer node.
- this allows mesh networking functionality, with monad operations defining computations between and through nodes. Think of it like routing protocols, but with computations. Lots of distributed computing possibilities here, obviously. More importantly is bandwidth usage, offline data synchronization, and the like. Instead of going to a data center to get the latest package updates, applications will be able to query neighbor nodes. Think IPv6 functionality, mesh networking, and being able to query data states from intermediary peers. The people in the Meteor dev community are actively working on things ranging from meters for smart energy grids to real-time bee pollination tracking.
Those technical details aside, the underlying reason why pure javascript can result in jaw-dropping applications is because, at it's core, javascript is a functional language, in the manner of lisp (if you know how to use the lambda calculus). It's lisp for the web (or scheme for the web, if you prefer). And putting it on both the server and client and database allows developers to do crazy monad calculations and method chaining. The monads will update and recalculate themselves in real time, as the underlying data changes. The end result is reactive templates and data-driven animations and UI elements.
If you want a better understanding how this is going to play out, check out the D3 visualization library here:
https://github.com/mbostock/d3/wiki/Gallery
Then, imagine all those visualizations used to create applications like in Processing:
http://processing.org/exhibition/
That's the direction this stuff is headed in. If you want to see some real examples in action, consider the interactives on the New York Times
http://www.nytimes.com/interactive/2012/05/17/business/dealbook/how-the-facebook-offering-compares.html?_r=0
http://www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html
Exactly. Some of us are already programming applications with this in mind. I've normalized my virtual servers at... 256mb disk size; the websites are reactive layouts that adjust from 320x480 pixel cellphone sized displays to 3 megapixel thunderbolt displays and more; navigation is tied to keyboard shortcuts that can be mapped to haptics... be it mouse clicks, taps, swipes, or sign language.
Now days, my travel kit includes my iPad, a wireless bluetooth keyboard (solar), and an HDMI adapter. I go to friends houses, and simply connect to their HDMI hi-res television. If I want to do mobile development on the go, I grab my Mac Mini and do the same thing. HDMI is the best connector *ever*, and anybody who doesn't have an HDMI connector and wireless keyboard for their tablet is simply not groking the ergonomics of tablet portability.
Recently went through this myself. Despite having used a kanban board, used version control, commented code, written unit tests, etc, some junior devs thought the code sucked. My takeaway was that there were still too many barriers to entry. Too many passwords, not enough installation instructions, etc.
Somewhere in the process of learning to write production ready code, it occurred to me that it was necessary to work the process backwards. Begin a project by setting up your hosting or distribution environment before starting to code. Write unit tests before starting to code. And so forth.
Getting other people to contribute to your project requires the same kind of thinking. Set up a project page before you start to code. Write a vision statement before you start to code. Write installation instructions, coding style guidelines, and operations support instructions before you start to code. That way, as you proceed in the project, you have clearly build up the documentation that other people are going to need to join your project. These things shouldn't be started after the fact.
If you can't point a new dev to a website and say 'download the source and instructions' here, it's probably too complicated and will meet resistance.
What does the flow into and out of science have to do with anything? Migration is one of the four basic mechanisms of evolutionary change, along with natural selection, mutation, and genetic drift. Ideas flowing into and out of science is perfectly consistent with migration and Cultural Evolution models.
As for memes, I kindly recommend memegenerator.net, in all it's lowest-common-denominator glory, and the iPhone and Android app stores. Memes, like genes, are ubiquitous. The reason they don't seem to exist is because they're everywhere.
Wrote my senior thesis on Kuhn, positivism, etc nearly 10 years ago. My take away was that scientific and theoretical advances get disseminated throughout society. Ergo, a population undergoes memetic evolution. Drawing on biology, the obvious model is one of punctuated equilibrium. Once one reconciles the ideas of paradigm shifts with punctuated equilibrium, it becomes pretty evident how technology evolves, science is disseminated, differing rates of change in different fields, etc. All one has to do is look at the iPhone, iPad, and Leap to see modern paradigm changes in action. (Protip: The language we use to describe the punctuated equilibrium changes of the human species is that of stock markets, marketing, and market analysis.)
As Gibson put it, "The future is already here — it's just not very evenly distributed." I also highly recommend Hulls "Science as a Process".
http://www.amazon.com/Science-Process-Evolutionary-Development-Foundations/dp/0226360512
I don't buy it. The package is addressed to 1101 East 58th Street. That's the UChicago Administration and Admissions office address. No way. It's obviously a College application. And a good one too! Somebody has a sense of aesthetics. Probably someone wanting to go into Art Preservation or Museum Curratorship. Maybe Egyptology or Paleontology.
Performance art? It's obviously an application to the College (received in December, duh). Among some alumni, bets on the declared major range from Art Restoration & Museum/Library Curation to Archeology, Egyptology, & Paleontology. I almost went into Paleontology. One of my best friends has a B.A. in Egyptology. I have a half-dozen acquaintances I know who focused in various Museum/Library curator positions. It could be any.
As a UChicago grad, I think the answer is obvious. It was delivered to the Admissions office during the month of December. It's an application to the college. The Admissions office would just like to know who it's from! :)
It's daring, if somewhat obvious. But to my knowledge, it hasn't actually been done before. It was bound to happen eventually, however. I'm just kind of surprised it took this long, in fact. Whoever sent it will obviously get in if they have a modicum of academic ability or talent. It's exactly the kind of nerdy stunt, with an appreciation for aesthetics, that UChicago appreciates.
I see it differently. I see it as an issue of encapsulation. The issue is whether one is going to encapsulate the parallelism inside of a thread, or inside a machine, or inside a network. From an operations perspective, a thread is usually an opaque black-box, with few controls for the operations team to manage whether they want to scale a process up or down, add extra resources, migrate to different hardware, do disaster recovery fail over testing, etc. And having been in operations for many years, I like to expose controls in my application designs that allow operations to manage those parallelism features. And so, when it comes to encapsulation, I tend towards encapsulating parallelism with a hypervisor, rather than with a thread.
The idea isn't to just scale *hardware* (although that's one way of doing things). Rather, scale the virtual nodes within a hypervisor environment. Then, if you're using a 32 core server, run 31 virtual node servers, with each node server running on one core, and with one optimized dedicated thread per CPU. The last core gets used by the hypervisor itself to manage inter-node infrastructure. The end result is a virtual network running on a multi-core server, and is essentially just this generation's version of a mainframe architecture.
There are, of course, pros-and-cons to this approach. Some things you gain, while others you loose. But as far as scaling goes, one doesn't need to scale hardware to use parallelism. Just need to have a hypervisor with some micro-sized virtual machines. I like to keep my virtual machines running node.js at about 256mb of disk space. But when the time comes to go parallel with hardware, everything is already set up to.