It is a badge of pride for hipsters to have things that are "retro" and "ironically hard to use."
I used to have a roommate who had a fixed gear bike. He loved it because he used clips, and thus when he'd have to stop at lights, he could balance without unclipping.
You sound like an old geezer from the 1960s whining about hippies!
We have this crazy idea over here that a person's right to emergency services shouldn't be based on how much money they're making, and shouldn't be removed through poor luck or illness.
Americans believe that too, but no one wants to pay for it here. No one understands just how much our lifestyle depends on government services, and instead look at the typical American tax rate of 1/3rd as highway robbery.
It's like in the US, no one understands that taxes are like homework. Go gotta do your homework, and you gotta pay your taxes. If you don't do your homework, you end up uneducated, and if you don't pay your taxes, society falls apart.
In the video, the robot drew boobs on the girl and a penis on the guy! Given the nature of the drawing, I suspect that the robot is really just remotely-controlled arms with an artist looking through the video camera.
two-part version of J. R. R. Tolkien's The Hobbit early next year
The Hobbit was the shortest book in the series. It was a much easier read then the actual Lord of the Rings series. Why does it need to be TWO movies? I bet I could read The Hobbit in less time then it'll take to watch this movie!
I'm getting so sick of Jackson's super-extended movies that I think I'm just going to pass on this one. I don't need to watch Bilbo fly on the back of a bird for 20 minutes because Jackson just can't bear to cut any frames out.
That article is 100% on the mark when it talks about Mercurial's forking problems. I've been bitten by that issue, but it wasn't until after I became comfortable with the tool and knew that I could still get my data out.
Perhaps my original post came off too much as being yet another Mercurial vs. git post; which wasn't my intention. What I was replying to is the sort of "xxx MUST be better because it's 100% open source" attitude. Even though I like the concepts behind open source, I find the "it's better because its open source" attitude silly if I just want to get something done. Sure, Mercurial isn't 100% open source, but I always have access to my entire history, which is really what's important. (For example, I dumped BitBucket because they had some horrible downtime problems earlier this year.) As long as I can get my data out of the five copies of my repository, I don't really need to worry if I can compile my own custom version of hg.
But isn't Git easy to install and use -- for free, even if your project is proprietary and secret, not open source and public? Whatever.
Give me a break. When I was looking for a repo for ObjectCloud, I listened to a one-hour video of Linus rambling about how wonderful Git and distributed SCM are. I tried Git for about two days until I got stuck in a situation where I realized I'd have to spend at least an hour "problem solving" by crawling lots of well-meaning, but difficult-to-read, forum posts. I've never had such a confusing experience with an SCM before in my life.
At that moment I switched to Mercurial. It works, and it's easier to learn. I have hit some messes, but it took me a month or so before I got stuck, which is long enough to become comfortable figuring out how to dig out of newbie mess.
Aside from a few glaring typos on the page (what's a walthrough?), I want to address this point.
I must admit that I quickly threw those pages together a year ago, and then hopped back into coding. We're getting ready for another pass at the site that will hopefully simplify things. It's going to be done as part of a refactoring project that gives ObjectCloud a better UI.
break that subsystem off into a separate project. The more people using that subsystem, the more secure it will be. You want the portions of your code that do the actual security enforcement to be as thoroughly reviewed as possible, and this means making them more generally applicable
Yes, the design of the system is like that, although I keep everything in one repository so I can keep my sanity. In general, the source code has a code generator for ORM, the security / web handling layer, interfaces, web framework / socket handling, and then a reference implementation that's based around SQLite and flat files.
I could put the security / web handling and interfaces into another repository; but that would complicate things. I see that as a good long-term approach; and it's how I keep a proprietary (scalable + more features) version separate from what's open source.
I'm going to assume that most of these use HTTP redirects. This is where the server returns a 3xx result that tells the browser where to go, as opposed to rendering a full page and using Javascript to redirect.
The nice thing about HTTP redirects is that a service like Twitter can just follow the HTTP redirects for you and cut all of the middlemen out of the chain. Even forthcoming server-side Javascript interpreters could parse out Javascript-based redirects.
I'm surprised that Diaspora has these kinds of bugs. I've been working on ObjectCloud, an open-source web server with some distributed social networking features, since November of 2008. One of the reasons I didn't court high-profile publicity is that I didn't want to be under the gun to deliver a shoddy product.
A core part of my design is security. Operations have security enforced at a layer lower then what performs the operation. While I won't pretend that it's bug-free, my design attempts to minimize obvious things like users screwing with each others profiles. Likewise, I designed a powerful ORM system in C# that parameterizes user input so that the risk of SQL injection is unlikely and easily fixable.
Furthermore, I didn't release my code until I spent almost a year in private development, and I'm still keeping a low profile until I'm ready for high levels of attention.
This is why I'm shocked that Diaspora has these kinds of bugs. With all of the attention that we're giving to security these days, it's a shame that Diaspora isn't designed from the beginning to be secure.
Notebooks need protection in public networks like coffee shops and airplanes.
Someone can still bring a virus onto a network through a download, USB key, or a rouge device.
(Now, I didn't read TFA.) It's important that devices on a network have some form of resiliency. A firewall will certainly prevent DDOSes and can help prevent malicious behavior from entering a network, but there's so many ways to get around a firewall that it just can't be the only solution. For example, "anti-virus" on a firewall might block sites known to spread viruses, but it still won't prevent someone from downloading a random zip file with a virus.
If you are a young academic, who might spend six months preparing a great article on Thomas Aquinas, you're not going to publish in a place where anyone can come along and change this."
Wikipedia doesn't allow original research; it seems that something that takes six months to write would belong in a personal journal and then cited on Wikipedia.
So basically, if you're dealing with a large set of persistant data, everyone has to know how to work with a database. Avoid programmers who don't know how to use a database, or isolate them to a GUI.
(I'd welcome other advice from simulationists too; I've never had an advisor who was particularly programming-savvy, even though programming was always a large part of my research, and so I always had to make it up as I went along.)
One of my tasks in my first job out of school was to load an XML definition of long-running chemistry experiments. These experiments, I learned, could run for many years. Needless to say, I wrote the strictest XML loader I could. It drove a few people nuts, but then they thanked me after I saved them months of debugging time.
Today, now that storage is cheap, the best advice is to never throw any data away. If you use an inefficent schema; so be it, you can always improve the schema later. But, if you never collected the data, then it's gone forever. You might want to consider some form of a database that allows for a flexible schema, like Mongo, because it can easily adapt to minute changes that occur as your program and research evolve.
Be weary of toolkits and APIs that claim to solve difficult problems. They might solve it in the best way for small-scale deployments, but won't scale to fit your needs. ORM is a good example of being careful when choosing an API that claims to solve a difficult problem. Hibernate can quickly complicate traversing foreign-key relationships if it's used as a replacement for knowing how to use a database. In contrast, a team that knows how to do database programming might be happier with a much simpler ORM API.
Following up on the ORM example: A popular ORM technology is no replacement for good database design and a team member (or members) who know how to program a database. Even if you're using an embedded database that'll grow to 40 gigabytes, someone on the team needs to be comfortable programming with it.
Stick with tools that "do one thing and do it well." If the tool does many things, there should be a decent ecosystem that developed the "many" things. jQuery is a great example. It nicely abstracts browser differences and gives a helpful wrapper for dynamic HTML. There's also a healthy ecosystem of community plugins.
Avoid tools that get in the way of how you normally program, except in confined areas that can be refactored without starting from scratch. Spring.Net's aspect-oriented programming plugins for C# can leave lots of layers of auto-generated code on the stack trace, and require lots of additional work outside of normal C# in order to get it to work. Node.js's asynchronous approach is getting a lot of attention, but if your program crashes, you won't have a usable stack trace, and it's difficult to do a try-catch-finally around a non-blocking IO call. In both cases, when new technology brings akwardness, limit its use to one-off utilities or a small part of a larger whole. This way if the new technology proves too immature, your risk is minimized.
Code generators can be useful timesavers, but their scope should be limited to one or two layers of a program. Code generators that hit all layers of a program can become too inflexible to handle changing needs outside of what were originally anticipated. Likewise, code generators can become so complicated that it's easier to avoid using the generator altogether.
Runtime code generators need to be simple and well-tested. (These typically implement.Net or Java interfaces at runtime, or inherit from classes at runtime.) Bugs in code generators can be difficult to find and fix, because you'll have an incomprehensible stack trace that doesn't lead back to the bytecode generator, and because bytecode programming is quite time consuming.
Don't be afraid to write one or two utilities yourself, even if there are pre-existing libraries. As long as you have a good justification, it's a helpful learning experience.
There's a reason why many different APIs exist that appear to do the same thing..Net has three different XML handling APIs; each is optimized for something different and introduces valid tradeoffs. Choosing between APIs, utilities, or libraries often isn't a matter of which one is best, but instead is a matter of which will meet the design needs of your program.
I don't see 2D television going away any time soon as 3D isn't exactly an obvious improvement. It will probably become a niche, like vinyl in the audio world.
A few days ago a had the pleasure of seeing an autostereoscopic (no glasses) 3D TV. The advantages were very obvious, and it certainly had the "whoa, cool" effect that 3D with glasses doesn't have.
Color TV had an obvious and significant benefit and didn't require you to wear silly glasses all the time. 3D is a gimmick that only works well in a limited amount of footage that I've seen, and does require you to wear silly glasses all the time.
The first American color TV wasn't compatible with black-and-white, and relied on a spinning color wheel and a very high frame rate. Later, once NTSC was standardized, you could buy a spinning color wheel that would synchronize itself with the TV's refresh rate.
Yesterday I had the pleasure of seeing an autostereoscopic (no glasses) TV for the first time. I was shocked at how good it looked. I think 3D-TV will take off when there's more decent 3D content and autostereoscopic TVs are in Best Buy. Well-produced 3D content on autostereoscopic TVs will have an "obvious" benefit, much like when color TV technology worked out its bugs.
Give the creative types a few years and 3D TV will look very differently. Heck, it may even work without those awful glasses........
Yesterday I had the pleasure of seeing an autostereoscopic TV for the first time. I was shocked at how good it looked. I think 3D-TV will take off when there's more decent 3D content and autostereoscopic TVs are in Best Buy.
I used to use a Mac Pro on my TV, which is very quiet. It had no problem with 1080p video. I later bought a mac mini for my TV. I bought whatever they were selling in July 2009, It can do pretty much anything, although 1080p video is a bit of a stretch because the mini's CPU isn't as powerful as the pro. Specifically, it tends to skip in high-motion scenes. I really wish I spent the extra money for the faster CPU.
If you have a budget slightly over $1000, the Mac Mini with the fastest CPU will probably handle 1080p. Just remember this: The extra $1000 you spend for a general-purpose computer will buy lots and lots and lots of BluRay disks and iTunes rentals.
So, remember, NoSQL means that's anything but SQL. It's not a standard; rather, it's an honest effort to try to experiment with different database techniques where traditional SQL just isn't meeting an industry need. Key-value databases aren't going to satisfy the "give me how many widgets we sold in June to evil inventors in the tri-state area" need; but they do satisfy the scalability need for sites that have millions of concurrent users.
Regarding Mongo, the NoSQL database that I use, it can answer the "give me how many widgets we sold in June to evil inventors in the tri-state area." Basically, instead of having 100 tables with foreign key relationships, you'll have 10 collections of "documents," which are really just data structures. You can query deeply into data structures and return partial data structures.
Let's assume I have an "invoices" collection. Each invoice has an array of "line items", and each item has a count. I can do the following in Mongo:
Again, NoSQL isn't a standard. It's basically experimenting with different ways of having a database with the hopes of finding one that's easier to work with. Mongo is a lot closer to SQL then things like Key-Value databases.
The data belongs to the business, not to the application. The data should be structured and stored in a way that it will still be readable years after your program has become obsolete.
Which is why breaking everything into tables is a PITA. Tables often have logical groupings of rows, which MongoDB is excellent at handling. You can still extract partial documents from the database if you need don't need all of the relationships.
NoSQL is not really about scalability, it is about modelling your data the same way your application does.
I 100% agree. Earlier this year I created a moved a prototype application built around SQLite and flat files to MongoDB. MongoDB is SQL-like in its ability to have queries and indexes; but it stores its data in a way that doesn't require me to deconstruct all of my data structures into tables. This dramatically reduced complexity in code that used to deal with 5-6 SQLite tables. In the case of MongoDB, I was able to replace 5-6 tables with a single collection of structured documents. MongoDB lets me write queries against data that's deeply-nested, yet it can return the full data structure so I don't have the performance hit (and programmer time hit) of running (and writing) many queries to hydrate data structures around foreign key relationships.
The other advantage to MongoDB is that its schemaless approach makes it much easier to handle inheritance. I can have documents with common parts for base classes, and varying parts for child classes. This is much harder in SQL, because I either need to design a super-table that can handle all variations of the base class, or I need to use a multi-join around all potential classes that I can query. MongoDB's document-based approach, as opposed to SQL's table approach, lets me write a single query that can handle future subclassing of the data, and future variations of the data.
So I'm not an aviation engineer, but couldn't someone combine a jetpack with some wings so that naturally-occurring lift could be used to reduce fuel consumption once the person was above trees and buildings? Perhaps two 5-foot wings that could be folded and stored in a closet? Would you need 2-3 minutes of fuel in order to take off, stop, and land safely?
I think this would really add some color to the statement "Big Brother is watching you."
Honestly, just buy a bunch of iPhones and use Facetime. I've gotten really sick of Skype interrupting me when I'm using my computer for work. There is this thing called privacy, and I don't think you want to look at your computer to see your parents getting nasty on the kitchen table. Likewise, I don't think you want your parents seeing you stumbling home drunk with some slut that you picked up at the local bar.
On the other hand, maybe you actually do want to see your parents get nasty on the kitchen table while you get it on with the slut that you just picked up at the local bar. To each his own!
So, apparently the backstory of C# /.Net is that Microsoft wanted to add some features to Java that Sun nixed. As a result, we ended up with a VM and language that's Java-like, (C#/.Net) but has some pretty cool features that weren't in Java at the time. These include AppDomains, improved garbage collection, better reflection, multicast events, delegates (similar to function pointers,) foreach (later copied in Java,) support for pointers in "unsafe" code, support for manual memory management, and an ability to directly call lower-level libraries..Net on Windows even has a very nice ability to consume COM libraries and export itself as a COM library, thus making it very easy to interoperate with legacy systems.
What's my point? Multiple competing VMs are a good thing if the new VMs bring needed features.
Slashdot Mirror
It is a badge of pride for hipsters to have things that are "retro" and "ironically hard to use."
I used to have a roommate who had a fixed gear bike. He loved it because he used clips, and thus when he'd have to stop at lights, he could balance without unclipping.
You sound like an old geezer from the 1960s whining about hippies!
We have this crazy idea over here that a person's right to emergency services shouldn't be based on how much money they're making, and shouldn't be removed through poor luck or illness.
Americans believe that too, but no one wants to pay for it here. No one understands just how much our lifestyle depends on government services, and instead look at the typical American tax rate of 1/3rd as highway robbery.
It's like in the US, no one understands that taxes are like homework. Go gotta do your homework, and you gotta pay your taxes. If you don't do your homework, you end up uneducated, and if you don't pay your taxes, society falls apart.
In the video, the robot drew boobs on the girl and a penis on the guy! Given the nature of the drawing, I suspect that the robot is really just remotely-controlled arms with an artist looking through the video camera.
two-part version of J. R. R. Tolkien's The Hobbit early next year
The Hobbit was the shortest book in the series. It was a much easier read then the actual Lord of the Rings series. Why does it need to be TWO movies? I bet I could read The Hobbit in less time then it'll take to watch this movie!
I'm getting so sick of Jackson's super-extended movies that I think I'm just going to pass on this one. I don't need to watch Bilbo fly on the back of a bird for 20 minutes because Jackson just can't bear to cut any frames out.
That article is 100% on the mark when it talks about Mercurial's forking problems. I've been bitten by that issue, but it wasn't until after I became comfortable with the tool and knew that I could still get my data out.
Perhaps my original post came off too much as being yet another Mercurial vs. git post; which wasn't my intention. What I was replying to is the sort of "xxx MUST be better because it's 100% open source" attitude. Even though I like the concepts behind open source, I find the "it's better because its open source" attitude silly if I just want to get something done. Sure, Mercurial isn't 100% open source, but I always have access to my entire history, which is really what's important. (For example, I dumped BitBucket because they had some horrible downtime problems earlier this year.) As long as I can get my data out of the five copies of my repository, I don't really need to worry if I can compile my own custom version of hg.
But isn't Git easy to install and use -- for free, even if your project is proprietary and secret, not open source and public? Whatever.
Give me a break. When I was looking for a repo for ObjectCloud, I listened to a one-hour video of Linus rambling about how wonderful Git and distributed SCM are. I tried Git for about two days until I got stuck in a situation where I realized I'd have to spend at least an hour "problem solving" by crawling lots of well-meaning, but difficult-to-read, forum posts. I've never had such a confusing experience with an SCM before in my life.
At that moment I switched to Mercurial. It works, and it's easier to learn. I have hit some messes, but it took me a month or so before I got stuck, which is long enough to become comfortable figuring out how to dig out of newbie mess.
Aside from a few glaring typos on the page (what's a walthrough?), I want to address this point.
I must admit that I quickly threw those pages together a year ago, and then hopped back into coding. We're getting ready for another pass at the site that will hopefully simplify things. It's going to be done as part of a refactoring project that gives ObjectCloud a better UI.
break that subsystem off into a separate project. The more people using that subsystem, the more secure it will be. You want the portions of your code that do the actual security enforcement to be as thoroughly reviewed as possible, and this means making them more generally applicable
Yes, the design of the system is like that, although I keep everything in one repository so I can keep my sanity. In general, the source code has a code generator for ORM, the security / web handling layer, interfaces, web framework / socket handling, and then a reference implementation that's based around SQLite and flat files.
I could put the security / web handling and interfaces into another repository; but that would complicate things. I see that as a good long-term approach; and it's how I keep a proprietary (scalable + more features) version separate from what's open source.
I'm going to assume that most of these use HTTP redirects. This is where the server returns a 3xx result that tells the browser where to go, as opposed to rendering a full page and using Javascript to redirect.
The nice thing about HTTP redirects is that a service like Twitter can just follow the HTTP redirects for you and cut all of the middlemen out of the chain. Even forthcoming server-side Javascript interpreters could parse out Javascript-based redirects.
I'm surprised that Diaspora has these kinds of bugs. I've been working on ObjectCloud, an open-source web server with some distributed social networking features, since November of 2008. One of the reasons I didn't court high-profile publicity is that I didn't want to be under the gun to deliver a shoddy product.
A core part of my design is security. Operations have security enforced at a layer lower then what performs the operation. While I won't pretend that it's bug-free, my design attempts to minimize obvious things like users screwing with each others profiles. Likewise, I designed a powerful ORM system in C# that parameterizes user input so that the risk of SQL injection is unlikely and easily fixable.
Furthermore, I didn't release my code until I spent almost a year in private development, and I'm still keeping a low profile until I'm ready for high levels of attention.
This is why I'm shocked that Diaspora has these kinds of bugs. With all of the attention that we're giving to security these days, it's a shame that Diaspora isn't designed from the beginning to be secure.
(Now, I didn't read TFA.) It's important that devices on a network have some form of resiliency. A firewall will certainly prevent DDOSes and can help prevent malicious behavior from entering a network, but there's so many ways to get around a firewall that it just can't be the only solution. For example, "anti-virus" on a firewall might block sites known to spread viruses, but it still won't prevent someone from downloading a random zip file with a virus.
If you are a young academic, who might spend six months preparing a great article on Thomas Aquinas, you're not going to publish in a place where anyone can come along and change this."
Wikipedia doesn't allow original research; it seems that something that takes six months to write would belong in a personal journal and then cited on Wikipedia.
So basically, if you're dealing with a large set of persistant data, everyone has to know how to work with a database. Avoid programmers who don't know how to use a database, or isolate them to a GUI.
(I'd welcome other advice from simulationists too; I've never had an advisor who was particularly programming-savvy, even though programming was always a large part of my research, and so I always had to make it up as I went along.)
One of my tasks in my first job out of school was to load an XML definition of long-running chemistry experiments. These experiments, I learned, could run for many years. Needless to say, I wrote the strictest XML loader I could. It drove a few people nuts, but then they thanked me after I saved them months of debugging time.
Today, now that storage is cheap, the best advice is to never throw any data away. If you use an inefficent schema; so be it, you can always improve the schema later. But, if you never collected the data, then it's gone forever. You might want to consider some form of a database that allows for a flexible schema, like Mongo, because it can easily adapt to minute changes that occur as your program and research evolve.
Be weary of toolkits and APIs that claim to solve difficult problems. They might solve it in the best way for small-scale deployments, but won't scale to fit your needs. ORM is a good example of being careful when choosing an API that claims to solve a difficult problem. Hibernate can quickly complicate traversing foreign-key relationships if it's used as a replacement for knowing how to use a database. In contrast, a team that knows how to do database programming might be happier with a much simpler ORM API.
Following up on the ORM example: A popular ORM technology is no replacement for good database design and a team member (or members) who know how to program a database. Even if you're using an embedded database that'll grow to 40 gigabytes, someone on the team needs to be comfortable programming with it.
Stick with tools that "do one thing and do it well." If the tool does many things, there should be a decent ecosystem that developed the "many" things. jQuery is a great example. It nicely abstracts browser differences and gives a helpful wrapper for dynamic HTML. There's also a healthy ecosystem of community plugins.
Avoid tools that get in the way of how you normally program, except in confined areas that can be refactored without starting from scratch. Spring.Net's aspect-oriented programming plugins for C# can leave lots of layers of auto-generated code on the stack trace, and require lots of additional work outside of normal C# in order to get it to work. Node.js's asynchronous approach is getting a lot of attention, but if your program crashes, you won't have a usable stack trace, and it's difficult to do a try-catch-finally around a non-blocking IO call. In both cases, when new technology brings akwardness, limit its use to one-off utilities or a small part of a larger whole. This way if the new technology proves too immature, your risk is minimized.
Code generators can be useful timesavers, but their scope should be limited to one or two layers of a program. Code generators that hit all layers of a program can become too inflexible to handle changing needs outside of what were originally anticipated. Likewise, code generators can become so complicated that it's easier to avoid using the generator altogether.
Runtime code generators need to be simple and well-tested. (These typically implement .Net or Java interfaces at runtime, or inherit from classes at runtime.) Bugs in code generators can be difficult to find and fix, because you'll have an incomprehensible stack trace that doesn't lead back to the bytecode generator, and because bytecode programming is quite time consuming.
Don't be afraid to write one or two utilities yourself, even if there are pre-existing libraries. As long as you have a good justification, it's a helpful learning experience.
There's a reason why many different APIs exist that appear to do the same thing. .Net has three different XML handling APIs; each is optimized for something different and introduces valid tradeoffs. Choosing between APIs, utilities, or libraries often isn't a matter of which one is best, but instead is a matter of which will meet the design needs of your program.
I don't see 2D television going away any time soon as 3D isn't exactly an obvious improvement. It will probably become a niche, like vinyl in the audio world.
A few days ago a had the pleasure of seeing an autostereoscopic (no glasses) 3D TV. The advantages were very obvious, and it certainly had the "whoa, cool" effect that 3D with glasses doesn't have.
Color TV had an obvious and significant benefit and didn't require you to wear silly glasses all the time. 3D is a gimmick that only works well in a limited amount of footage that I've seen, and does require you to wear silly glasses all the time.
The first American color TV wasn't compatible with black-and-white, and relied on a spinning color wheel and a very high frame rate. Later, once NTSC was standardized, you could buy a spinning color wheel that would synchronize itself with the TV's refresh rate.
Yesterday I had the pleasure of seeing an autostereoscopic (no glasses) TV for the first time. I was shocked at how good it looked. I think 3D-TV will take off when there's more decent 3D content and autostereoscopic TVs are in Best Buy. Well-produced 3D content on autostereoscopic TVs will have an "obvious" benefit, much like when color TV technology worked out its bugs.
Give the creative types a few years and 3D TV will look very differently. Heck, it may even work without those awful glasses........
Yesterday I had the pleasure of seeing an autostereoscopic TV for the first time. I was shocked at how good it looked. I think 3D-TV will take off when there's more decent 3D content and autostereoscopic TVs are in Best Buy.
I used to use a Mac Pro on my TV, which is very quiet. It had no problem with 1080p video. I later bought a mac mini for my TV. I bought whatever they were selling in July 2009, It can do pretty much anything, although 1080p video is a bit of a stretch because the mini's CPU isn't as powerful as the pro. Specifically, it tends to skip in high-motion scenes. I really wish I spent the extra money for the faster CPU.
If you have a budget slightly over $1000, the Mac Mini with the fastest CPU will probably handle 1080p. Just remember this: The extra $1000 you spend for a general-purpose computer will buy lots and lots and lots of BluRay disks and iTunes rentals.
So, remember, NoSQL means that's anything but SQL. It's not a standard; rather, it's an honest effort to try to experiment with different database techniques where traditional SQL just isn't meeting an industry need. Key-value databases aren't going to satisfy the "give me how many widgets we sold in June to evil inventors in the tri-state area" need; but they do satisfy the scalability need for sites that have millions of concurrent users.
Regarding Mongo, the NoSQL database that I use, it can answer the "give me how many widgets we sold in June to evil inventors in the tri-state area." Basically, instead of having 100 tables with foreign key relationships, you'll have 10 collections of "documents," which are really just data structures. You can query deeply into data structures and return partial data structures.
Let's assume I have an "invoices" collection. Each invoice has an array of "line items", and each item has a count. I can do the following in Mongo:
Again, NoSQL isn't a standard. It's basically experimenting with different ways of having a database with the hopes of finding one that's easier to work with. Mongo is a lot closer to SQL then things like Key-Value databases.
The data belongs to the business, not to the application. The data should be structured and stored in a way that it will still be readable years after your program has become obsolete.
Which is why breaking everything into tables is a PITA. Tables often have logical groupings of rows, which MongoDB is excellent at handling. You can still extract partial documents from the database if you need don't need all of the relationships.
In the last 20 years I've seen the "news" business go from fact driven reports to "newstainment".
Yellow Journalism is nothing new, according to the Wikipedia article, it's been going on since the later part of the 19th century.
NoSQL is not really about scalability, it is about modelling your data the same way your application does.
I 100% agree. Earlier this year I created a moved a prototype application built around SQLite and flat files to MongoDB. MongoDB is SQL-like in its ability to have queries and indexes; but it stores its data in a way that doesn't require me to deconstruct all of my data structures into tables. This dramatically reduced complexity in code that used to deal with 5-6 SQLite tables. In the case of MongoDB, I was able to replace 5-6 tables with a single collection of structured documents. MongoDB lets me write queries against data that's deeply-nested, yet it can return the full data structure so I don't have the performance hit (and programmer time hit) of running (and writing) many queries to hydrate data structures around foreign key relationships.
The other advantage to MongoDB is that its schemaless approach makes it much easier to handle inheritance. I can have documents with common parts for base classes, and varying parts for child classes. This is much harder in SQL, because I either need to design a super-table that can handle all variations of the base class, or I need to use a multi-join around all potential classes that I can query. MongoDB's document-based approach, as opposed to SQL's table approach, lets me write a single query that can handle future subclassing of the data, and future variations of the data.
So I'm not an aviation engineer, but couldn't someone combine a jetpack with some wings so that naturally-occurring lift could be used to reduce fuel consumption once the person was above trees and buildings? Perhaps two 5-foot wings that could be folded and stored in a closet? Would you need 2-3 minutes of fuel in order to take off, stop, and land safely?
I think this would really add some color to the statement "Big Brother is watching you."
Honestly, just buy a bunch of iPhones and use Facetime. I've gotten really sick of Skype interrupting me when I'm using my computer for work. There is this thing called privacy, and I don't think you want to look at your computer to see your parents getting nasty on the kitchen table. Likewise, I don't think you want your parents seeing you stumbling home drunk with some slut that you picked up at the local bar.
On the other hand, maybe you actually do want to see your parents get nasty on the kitchen table while you get it on with the slut that you just picked up at the local bar. To each his own!
So, apparently the backstory of C# / .Net is that Microsoft wanted to add some features to Java that Sun nixed. As a result, we ended up with a VM and language that's Java-like, (C#/.Net) but has some pretty cool features that weren't in Java at the time. These include AppDomains, improved garbage collection, better reflection, multicast events, delegates (similar to function pointers,) foreach (later copied in Java,) support for pointers in "unsafe" code, support for manual memory management, and an ability to directly call lower-level libraries. .Net on Windows even has a very nice ability to consume COM libraries and export itself as a COM library, thus making it very easy to interoperate with legacy systems.
What's my point? Multiple competing VMs are a good thing if the new VMs bring needed features.