dbcfd

It's less the match, and more what is returned by Mongo. If he matches comments.name, he wants the comments.text to go with it, not the entire document.

It becomes an issue when you have extremely large arrays in the document (e.g. thousands of comments).

Yeah, I think the comments by user, I had done using Foursquare's Rogue, so thought it was part of mongo natively.

At least they have tickets open for it.

I understand that you can use MongoDB in a relational fashion, but I don't get how this is showing why. The mongo docs have examples showing what this blog says can't be done.

http://www.mongodb.org/display/DOCS/Retrieving+a+Subset+of+F...

> t.find({}, {'x.y':1}) { "_id" : ObjectId("4c23f0486dad1c3 a68457d20"), "x" : { "y" : 1 } }

And the mongo docs even have an example pretty detailing what this page wants (paging of comments)

db.posts.find({}, {comments:{$slice: -5}}) // last 5 comments

So, what am I missing?

As both a developer and a bar owner, yes.

I had stayed away from buzztime due to the hardware requirements, however, the iphone app intrigues me. Not enough to put up the cash for buzztime, but intriguing nonetheless.

Trivia is a great way to bring patrons to a venue, but works best when prizes and some sort of mc are involved. The quiz alone is fun for patrons that are there, but doesn't necessarily draw significantly more patrons. The app would need two modes, a constant running game for leaderboard, and an event mode, which could allow managers to set start/stop times with prizes, localized to the venue. It'd be great if it could integrate with an mc, who can tailor questions based on venue crowd.

It's very feasible from a technology perspective. I've been working on another web based geo location app using Scala/Lift, and this isn't much of a stretch.

If you decide to go down this road, shoot me a message. Be more than glad to help from either a developer or restaurant owner perspective.

But if the programmers are running the show, what is management supposed to do? That's why there's a scrum master. Yes, you need a leader, but often that role gets pushed to a manager, who focuses too much on process. They should rename it the scrum playmaker, with each sprint focusing on a new playmaker, returning control to the team.

Managers also have a much different understanding of the word "competent" than the people on the team.

The devil is in the details. You still need competent people to determine and estimate tasks, and to implement those tasks. Implementation is the biggie. How do you design the implementation? How complete are your tests? What are the important requirements of the task?

There seems to continue to be this idea in management that process will take the place of skilled programmers. That you can then just plug any programmer in, and the process will produce a usable product.

It's amazing how most other skill based industries require certification exams, to verify that you truly do know how to build a bridge, prepare a legal defense, or perform a hip replacement. Software development is the only place where process is thought to replace skill and knowledge.

I've only used Rackspace so far, so just providing my feedback for that.

Rackspace is cheap, as far as on demand goes. It's very easy to load up a server, configure it how you want, then save off an image to restore later. At high traffic times, the creation and save seems to take a bit longer.

Latency seems to be a little on the high side. Simple comet js pushes take a bit longer than they should, and outgoing queries are also similarly slow (i.e. sending out a request to someone else's API). Inbound standard traffic seems speedy enough.

Yeah, that's why I said they can't be forced down by price. The supply/demand side is a whole other issue.

Medical school is entirely too expensive, which limits doctors going into general or emergency care, which causes further strain on the system.

The Liftweb docs show something similar to a cart system, and supports switching from the file database to mongodb fairly easily. Since mongo is nosql and uses Lift's mapper, it will work the same as the example application.

However, mongodb doesn't support transactions, but does have atomic operation support. If you keep your records small, it should perform well.

http://simply.liftweb.net/index-6.3.html#toc-Section-6.3

Price gouging is an aspect of capitalism. Demand goes up, price goes up. Without market interference, this should force demand down.

Health care can't be forced down by price (at least, life saving health care), so you either have to stop providing care to those that need it but can't pay, or pass along the costs to others.

The current healthcare model doesn't promote competition. Providers must inflate prices to cover costs, since they know they will be reimbursed by insurance based on the insurers pricing model, not their own.

Private healthcare would have to start providing actual costs to insurers, and insurers would have to accept that those costs include losses from people without insurance for competition to take effect.

Further obfuscation on the part of the medical industry to hide the cost of covering the uninsured. Hospitals need reimbursement, insurance only wants to pay for your procedures, not the cost of others receiving treatment without insurance.

Taxed as single payer or taxed as hidden costs, anyone with insurance is being taxed for those without insurance. At least with single payer, you know those receiving treatment are now kicking something in as well.

Nope, that's capitalism. Someone (the insurance) is willing to pay that price.

It'd only be fraud if the government was paying for it.

[Edit]Some hate against my comment. For those that fail to understand...

It isn't fraud if you go to a gas station that is charging $0.10 more a gallon, and fill up there. It's fraud if you pay for that gas, and its water. The insurance is still buying the same drug, they have just chosen to negotiate a price that is higher with one hospital than another. They have their own reasons for deciding that price.

Likewise it would be fraud if the government was paying for it, since they have set rates. To achieve a higher payment would require billing them for some other product.

The author isn't saying that you need a big customer, just that you need a customer. Once you identify a possible customer, the boot strap approach should be used to get your product up and running. Just make sure that the customer for your product is more than just you.

The internet also provides a false sense of security, due to the large level of feedback. You may incorrectly associate users with customers, developing a product that meets their demands, but does not meet the demands of the people who actually purchase.