Don't know about that... I was running Ubuntu, and right around Windows 7's public RC, Ubuntu did a release that included a borked intel driver (9.04 iirc)... I couldn't even play YouTube level video anymore, or run Frozen Bubble. Intel was in the middle of a rearchitecting of their Linux driver IIRC, but Ubuntu wouldn't let their release slip, or use an older driver... so 2/3 of the computers out there that happened to be running Intel graphics had a borked UX for anything needing accelerated or 3D rendering support. I know it was more about Ubuntu specifically than Intel, just the same just pointing out that Intel isn't a golden ticket experience necessarily.
I really liked a lot about OS/2 Warp... IMHO it's one of the last desktop oriented OSes that would run well on a 50mhz 486 with 8mb of ram (8mb being quite a bit for the time, but still). At some point we really just passed into bloat world. Don't get me wrong, I love having a multi ghz 8-core cpu... but there's something to be said for an OS that could do as much as OS/2 did, as well as it did. Shame that IBM kept it as walled off as it has. Wish that they'd Open-Source what they could from it (Warp 3), would be nice for learning. Next year it is 20 years old, so out of any patent protection at least... of course parts are Copyright (C) Microsoft.
I've often thought that apps should "register" with an update service in windows, so that windows can control update checking times, and simply call into the registered app for them to check on updates, and report any back into the windows UI... so that updates can happen through a regular interface... though I've thought this since around 2001.. but hey.. what do I know.
I would rather see said devices implement required points for API compatibility, then existing structures could work... ((touchscreen && accelerometer) || (analogStick && (buttons >= 4)) etc...
That's actually something I don't like in the Ouya... the touchpad is very sensitive, and hard to use... would rather have a switch that puts the left stick into "mouse mode"... That, and the buttons are super stiff.
For that matter, why wouldn't they just buy out Ouya? Get some horsepower behind the development effort on the UI, and clean it up a bit... Also, plan for a Tegra 4/5 based system late next year.
When it's semi-automatic, sure... I mean anything more than a breech loading musket is obviously a weapon of mass destruction. Damn self-cocking revolvers, slippery slope indeed...
I think the biggest advantage MongoDB has over other DBs in this respect is the console interaction for MongoDB is based on a JS REPL interpreter... that said, it really depends on your needs. If you need caching of data there's Memcached, if you want that with persistence and pub-sub there's Redis, if you care more about bigger storage there's Couch, if you want some hybrid SQL-like functionality there's MongoDB and RethinkDB... there's even column-based dbs and a lot of others.
MongoDB is probably the most natural fit for NodeJS for the most broad of use cases. It's isn't a one-size fits all problem solver, and neither is any SQL solution depending on your needs.
Not to be too pedantic, but the user can use an HTML app with only a browser (they likely already have) without a plugin (that they don't likely already have) and communicate to the server running the same language in said browser, and talk to the database, which you interact with using that same language.
MS-SQL uses T-SQL for interrogating the data, and though most interactions can be done via a GUI knowing almost nothing about the SQL language, is pretty limited without DB/SQL knowledge.
MongoDB happens to use a BSON protocol, which is kind of like protocol buffers or message-pack. That translates pretty well to JSON and other representations. The fact that the mongodb console interface uses a JS based interpreter makes this very transparent in use.
That said, NodeJS as a client to most non-sql based databases tends to be very transparent (Couch, Mongo, Redis, Raik etc)... Mongo's interface being JS based is a big advantage in Full-Stack JavaScript.
I think the worst environment I ever worked in for language context switching was an app that used a web front end (HTML+JS+CSS), that had an embedded Flash system (FLEX + ActionScript) talking to a backend in ASP.Net (VB.Net, not C#) which then used MS-SQL (T-SQL) for storage... I spent so much time switching languages I can't even explain how bad it was. I would get asked a question by a peer, and it would take me literally half a minute just to get out of the mode I was in, have them re-ask, then get into what they were into in order to help.. then another several minutes to get back into where I was working after... It was horribly stressful.
If you take a modular approach with your code NodeJS works out pretty well. There are more than a handful of test frameworks as well, and GruntJS is a really useful tool even for projects where the server code is in other platforms/languages.
Agreed, at my last job, roughly half my time was dedicated to NodeJS which wasn't even used for the front end web applications, though I did pretty easily add CORS & JSONP support to my web services, some didn't need authentication. It's been a great platform for data transforms and manipulation, far more straight forward than a lot of other things. Having libraries to read in an XML stream, convert it to object nodes, and manipulate it for output into another system is awesome. Creating JSON based services is a no brainer, and working with MongoDB is pretty seamless. I've honestly had far more (though relatively few) issues with NodeJS or MongoDB for that matter.
I'd be content spending most of my time on NodeJS work. Though my current job is in backend work for a large MS shop (it pays the bills, doesn't mean I think it is better).
And I (for one) used it... I also used it (JScript) with MS's classic ASP around 1996 or so. I was actually really saddened when MS dropped Managed JScript from the DLR (though they pretty much let that whole project along with IronRuby and IronPython all but die at this point). I was relatively happy to see a rise of support for NodeJS, MongoDB, etc.
I really hate discussions like this... the browser's DOM !== JavaScript... it's just that usage of the DOM was for a long time the primary interaction with JS... jQuery makes manipulation of the DOM easier. The language has always had a lot of nice features, and isn't very kludgy at all. I will say that string formatting and Dates are probably its' weakest points, but there are lots of languages with those problems.
Fair enough.. then again, JS was really the first language I used to any large extent... far more than the scripting/macro languages I'd used before it. Mainly was doing artwork and design for web applications in the mid 90's and wanted to do a couple things... learning HTML and JS were natural extensions. I used JS for Netscape server, and even in classic ASP (JScript)... I think I was the only non-MS person using JS for ASP (all the MS projects seemed to use it). It was really nice to reuse a lot of the same include files for logic client and server-side then. Though the DOM *REALLY* sucked back then, and it wasn't until around 2003-2004 or so when it started to be manageable (with prototype, later jquery, etc).
I always loved the flexibility that it brought out... and used it to a large extent. The pain of the DOM caused me to buy in to the ASP.Net callback model, and it wasn't until the rise of "Ajax" interactions (2004-2005) that I ran away from the callback/event system that ASP.Net used. Since then I've been far more in favor of light services/rpc on the server, pretty static rendering, and heavy JS.
With JS server-side some of that can swing back to the server for constrained channels and frameworks can come out that leverage a lot of the same logic on both in a straight forward manner, supporting phones to tablets and full-fledged desktop browsers.
Actually, this is probably a much better interpretation that would actually *FIT* under the interstate commerce clause than most other permissions extended since the 1830's
I find that this is most often the case when people will use "Enterprise Design Patterns" for small projects that do not inherently need them. Much of the time this makes things more complex with no real benefit.
"My 'respected opponent' happened to be travelling to/from the same destination nearly 4 days a week for over a year that a convicted transsexual prostitute used, and I have proof of that fact... you do the math."
---
Due to the inability of certain persons on this site to distinguish humor from genuine malice, I am claiming the above comment as a statement of satire not meant to resemble any person living or dead at any point in humanity's history, present or future.
It's worth noting that a lot of the Good Parts were around even in '98, though the DOM differences were hellish to support at that time, the language itself was always imho pretty decent (given it's rather large warts).
GruntJS has pretty much taken hold as the build environment for node based projects. Even in other platforms (.Net for me), I have a pre-build event in VS that will compile/minify/combine my various client-side assets. It's extremely useful. For libraries there's Bower which uses Node... It really does make web application development much nicer. The only thing that doesn't really sing to me is a good templating system that is very transparent in terms of being able to share client and server-side. There's a lot of recent work in this area though.
As far as sharing client and server-side JS, there's a lot there to support it.
Slashdot Mirror
Don't know about that... I was running Ubuntu, and right around Windows 7's public RC, Ubuntu did a release that included a borked intel driver (9.04 iirc)... I couldn't even play YouTube level video anymore, or run Frozen Bubble. Intel was in the middle of a rearchitecting of their Linux driver IIRC, but Ubuntu wouldn't let their release slip, or use an older driver... so 2/3 of the computers out there that happened to be running Intel graphics had a borked UX for anything needing accelerated or 3D rendering support. I know it was more about Ubuntu specifically than Intel, just the same just pointing out that Intel isn't a golden ticket experience necessarily.
I really liked a lot about OS/2 Warp... IMHO it's one of the last desktop oriented OSes that would run well on a 50mhz 486 with 8mb of ram (8mb being quite a bit for the time, but still). At some point we really just passed into bloat world. Don't get me wrong, I love having a multi ghz 8-core cpu... but there's something to be said for an OS that could do as much as OS/2 did, as well as it did. Shame that IBM kept it as walled off as it has. Wish that they'd Open-Source what they could from it (Warp 3), would be nice for learning. Next year it is 20 years old, so out of any patent protection at least... of course parts are Copyright (C) Microsoft.
I was thinking of the old Cyrix Cx5x86 series... they were an okay value, but hot as sin... "Chernobyl Chips" as my friend referred to them.
That's the main reason I bought mine as I anticipated it would be a great platform for emulators (I was right).
That would actually bring me to use my Ouya for more than just a legacy game emulator (Atari, NES, SNES, Sega Genesis/MD, etc).
I've often thought that apps should "register" with an update service in windows, so that windows can control update checking times, and simply call into the registered app for them to check on updates, and report any back into the windows UI... so that updates can happen through a regular interface... though I've thought this since around 2001.. but hey.. what do I know.
I doubt they are selling the Kindle line at a loss, given the pricing is comparable to similar devices from other mfg's.
I would rather see said devices implement required points for API compatibility, then existing structures could work... ((touchscreen && accelerometer) || (analogStick && (buttons >= 4)) etc...
That's actually something I don't like in the Ouya... the touchpad is very sensitive, and hard to use... would rather have a switch that puts the left stick into "mouse mode" ... That, and the buttons are super stiff.
For that matter, why wouldn't they just buy out Ouya? Get some horsepower behind the development effort on the UI, and clean it up a bit... Also, plan for a Tegra 4/5 based system late next year.
When it's semi-automatic, sure... I mean anything more than a breech loading musket is obviously a weapon of mass destruction. Damn self-cocking revolvers, slippery slope indeed...
/sarcasm
I think the biggest advantage MongoDB has over other DBs in this respect is the console interaction for MongoDB is based on a JS REPL interpreter... that said, it really depends on your needs. If you need caching of data there's Memcached, if you want that with persistence and pub-sub there's Redis, if you care more about bigger storage there's Couch, if you want some hybrid SQL-like functionality there's MongoDB and RethinkDB... there's even column-based dbs and a lot of others.
MongoDB is probably the most natural fit for NodeJS for the most broad of use cases. It's isn't a one-size fits all problem solver, and neither is any SQL solution depending on your needs.
Not to be too pedantic, but the user can use an HTML app with only a browser (they likely already have) without a plugin (that they don't likely already have) and communicate to the server running the same language in said browser, and talk to the database, which you interact with using that same language.
MS-SQL uses T-SQL for interrogating the data, and though most interactions can be done via a GUI knowing almost nothing about the SQL language, is pretty limited without DB/SQL knowledge.
MongoDB happens to use a BSON protocol, which is kind of like protocol buffers or message-pack. That translates pretty well to JSON and other representations. The fact that the mongodb console interface uses a JS based interpreter makes this very transparent in use.
That said, NodeJS as a client to most non-sql based databases tends to be very transparent (Couch, Mongo, Redis, Raik etc)... Mongo's interface being JS based is a big advantage in Full-Stack JavaScript.
I think the worst environment I ever worked in for language context switching was an app that used a web front end (HTML+JS+CSS), that had an embedded Flash system (FLEX + ActionScript) talking to a backend in ASP.Net (VB.Net, not C#) which then used MS-SQL (T-SQL) for storage... I spent so much time switching languages I can't even explain how bad it was. I would get asked a question by a peer, and it would take me literally half a minute just to get out of the mode I was in, have them re-ask, then get into what they were into in order to help.. then another several minutes to get back into where I was working after... It was horribly stressful.
I'd love to do full-stack all-JS development.
If you take a modular approach with your code NodeJS works out pretty well. There are more than a handful of test frameworks as well, and GruntJS is a really useful tool even for projects where the server code is in other platforms/languages.
Agreed, at my last job, roughly half my time was dedicated to NodeJS which wasn't even used for the front end web applications, though I did pretty easily add CORS & JSONP support to my web services, some didn't need authentication. It's been a great platform for data transforms and manipulation, far more straight forward than a lot of other things. Having libraries to read in an XML stream, convert it to object nodes, and manipulate it for output into another system is awesome. Creating JSON based services is a no brainer, and working with MongoDB is pretty seamless. I've honestly had far more (though relatively few) issues with NodeJS or MongoDB for that matter.
I'd be content spending most of my time on NodeJS work. Though my current job is in backend work for a large MS shop (it pays the bills, doesn't mean I think it is better).
And I (for one) used it... I also used it (JScript) with MS's classic ASP around 1996 or so. I was actually really saddened when MS dropped Managed JScript from the DLR (though they pretty much let that whole project along with IronRuby and IronPython all but die at this point). I was relatively happy to see a rise of support for NodeJS, MongoDB, etc.
I really hate discussions like this... the browser's DOM !== JavaScript ... it's just that usage of the DOM was for a long time the primary interaction with JS... jQuery makes manipulation of the DOM easier. The language has always had a lot of nice features, and isn't very kludgy at all. I will say that string formatting and Dates are probably its' weakest points, but there are lots of languages with those problems.
Fair enough.. then again, JS was really the first language I used to any large extent... far more than the scripting/macro languages I'd used before it. Mainly was doing artwork and design for web applications in the mid 90's and wanted to do a couple things... learning HTML and JS were natural extensions. I used JS for Netscape server, and even in classic ASP (JScript)... I think I was the only non-MS person using JS for ASP (all the MS projects seemed to use it). It was really nice to reuse a lot of the same include files for logic client and server-side then. Though the DOM *REALLY* sucked back then, and it wasn't until around 2003-2004 or so when it started to be manageable (with prototype, later jquery, etc).
I always loved the flexibility that it brought out... and used it to a large extent. The pain of the DOM caused me to buy in to the ASP.Net callback model, and it wasn't until the rise of "Ajax" interactions (2004-2005) that I ran away from the callback/event system that ASP.Net used. Since then I've been far more in favor of light services/rpc on the server, pretty static rendering, and heavy JS.
With JS server-side some of that can swing back to the server for constrained channels and frameworks can come out that leverage a lot of the same logic on both in a straight forward manner, supporting phones to tablets and full-fledged desktop browsers.
Actually, this is probably a much better interpretation that would actually *FIT* under the interstate commerce clause than most other permissions extended since the 1830's
I find that this is most often the case when people will use "Enterprise Design Patterns" for small projects that do not inherently need them. Much of the time this makes things more complex with no real benefit.
"My 'respected opponent' happened to be travelling to/from the same destination nearly 4 days a week for over a year that a convicted transsexual prostitute used, and I have proof of that fact... you do the math."
---
Due to the inability of certain persons on this site to distinguish humor from genuine malice, I am claiming the above comment as a statement of satire not meant to resemble any person living or dead at any point in humanity's history, present or future.
It's worth noting that a lot of the Good Parts were around even in '98, though the DOM differences were hellish to support at that time, the language itself was always imho pretty decent (given it's rather large warts).
GruntJS has pretty much taken hold as the build environment for node based projects. Even in other platforms (.Net for me), I have a pre-build event in VS that will compile/minify/combine my various client-side assets. It's extremely useful. For libraries there's Bower which uses Node... It really does make web application development much nicer. The only thing that doesn't really sing to me is a good templating system that is very transparent in terms of being able to share client and server-side. There's a lot of recent work in this area though.
As far as sharing client and server-side JS, there's a lot there to support it.