andrew ennamorato

Try to keep things that need to be updated atomically inside the same document, since making correctness guarantees across documents without real transactions is tedious and error-prone.
Ideally, have the 'unit of work' you're dealing with only touch a single document. In a web app, for example, this would mean that each page only loads a single document.

Those sound like great tips. We started with the mindset of 'put everything about a model/object in the same document' but invariably we split it out. Which has been just okay.

Anyway, thanks for the tips and Q&A this week, I look forward to reading the book.

10gen offers free online training around mongo: https://education.10gen.com
I haven't taken it but I assume it's pretty decent (the rest of their docs/tutorials/etc are usually pretty good).

Depending on what language/framework you want to use, you can probably find lots of "quick web site/service with ____ and MongoDB" blog posts. Especially node related, a la http://howtonode.org/express-mongodb and http://vimeo.com/38136668

I'd also recommend the 'Little MongoDB Book' (http://openmymind.net/2011/3/28/The-Little-MongoDB-Book/), even though it's a couple years old, for a quick run through of Mongo. I think he just has you type in some console/shell scripts and you get the feel of mongo pretty fast.

We have a couple web apps using MongoDB and in both cases we tried to sit and think about how we were modeling our data beforehand. Thanks to MongoDB's awesomeness, it's obviously pretty malleable, so we didn't spend too much time of that but figured "OK, this looks good" and dove in.

In both cases, we had to sort of "back out" our original design, tweak the documents (usually creating new collections), etc.

How could we have avoided this? It didn't bite us too bad but it could have I guess. Obviously, I think the book is meant for people like me, but I wanted to get in a question and see if there's any good suggestions on how to plan out your "schema" and test it, but without actually doing it...Or maybe the best suggestion is to go ahead and use a few tracer bullets/spikes to actually see what is like to work with the data in that fashion.

Thanks!

Thanks Bear.

I guess sometimes it feels a little overwhelming when looking at JS "best practices" so hopefully Secrets helps clear that up. It seems lately there are a lot of good resources but the more the better.

There are lots of ways to do things in JS, it seems. Just try a search for 'OO JS' on github.

How do the authors choose their approach when faced with a problem they're trying to solve? Do they use 'design patterns' they're familiar with using raw JS or do they pull in Underscore or Backbone?
I guess I could say I'm an intermediate level Javascripter, but lately it seems there's too many options to choose from - heck just the Constructor pattern itself has multiple options. I think something like TodoMVC is pretty cool, as it shows different approaches...but what is there for just JS the language and patterns itself? i.e. Do we need an 'Effective Javascript' book (there are actually is one: http://effectivejs.com) or is Secrets it?

In case you're not on 10gen's various marketing/mailing lists, 10gen announced free online training this week: http://education.10gen.com
'Classes' start in October and there's two tracks - one for developers and one for 'DBAs' (the nice thing about mongo IMO is that you don't have to be a DBA to get started).

Anyway just a heads up.

Sorry, late response but Dive Into Html5 (which was abandoned/deleted by the author but revived by others) is a good resource and it's free to look at online. There's a version of it published by O'Reilly that's useful if you need a physical copy.

I know...I have so many of them I can't even keep track (seriously, I've bought the same MEAP ebook at least twice ;) ).

jQuery rocks. I think we all know that.

Does the book talk about when it's appropriate to use jQuery & extend it versus writing a microjs lib (or maybe even a Zepto plugin, if that's possible)? Just wondering your take on the idea of small, single responsibility JS libs versus jQuery plugins. Obv, you like extending jQuery enough to write a book about it, but just wondering what thoughts you have or how you choose to approach it.

I've recently written some JS code that works with OpenLayers, the mapping lib. And it could easily be a jQuery plugin - it's just basic boilerplate for working with OL. But maybe it'd be better off as just a little "map helper" lib, a la Mapstraction. Anyway, just an example to discuss if needed.

thanks!

Cool! When in doubt, check the author's github for cool demos, haha.

I think a neat demo might somehow tie in something like D3 or Miso (http://misoproject.com/dataset/). Sorta like what Jos Dirksen did here: http://www.smartjava.org/content/threejs-tutorial-example-webgl-canvas-and-webworkers. And maybe tie in CrossFilter some how too: http://square.github.com/crossfilter/

I dunno, just random thoughts there.

Speaking of pools, Jos has a good post on his own little threadpool lib too: http://www.smartjava.org/content/html5-easily-parallelize-jobs-using-web-workers-and-threadpool

I think your book and more demos will be great (and help my own understanding of how to use these, too). So if anyone else has any good links, feel free to gather 'em up in this thread.

Web workers and web sockets are, IMO, the two most interesting changes/additions to the JS/html landscape in a while. (Canvas probably being a close 3rd...)

Unlike web sockets, though, web workers don't seem to have been given as much love - there aren't a ton of cool demos, there don't seem to be any abstraction libs (i.e. socket.io), etc.

Are web workers still too immature/unsupported? Is an abstraction library (I'm thinking thread-pool style libs available in other langs, or maybe even some sort of actor model for passing data across workers) unnecessary?

At any rate, glad to see a book out on the subject!

Wow, awesome answer, thanks!! (Although, you referenced an article from 2007, too ).

Looking forward to checking out the book.

Martin Fowler said "I don't see any compelling benefits for mockist TDD, and am concerned about the consequences of coupling tests to implementation." in his classic Mocks aren't Stubs post.

I agree somewhat, yet at the same time often find myself using a mock because it just seems to make sense. So I'm curious what Tomek's opinion of mocking in general is, and also how much time is devoted to that in the book (i.e. is Mockito just a few sections, or is mocking used throughout).

Thanks!

In our environment, the idea that "If we have enough Tiger teams, we can design the whole thing for a year, then release some Word Docs and PPT and Excel spreadsheets with requirements and then we're done" still reigns supreme. We end up taking requests and turning them into hideous spreadsheets/tables and "traceability matrices" that are basically outdated as soon as the first line of code actually gets written.

So the idea of BDD-style "requirements" seems to make a whole lot more sense - if I can check my 'requirements' into CM right along with my code, perhaps I can convince all these working groups that we can start building on day 1 (or at least day 15).

I guess my question is, how often have you seen Cucumber make the leap from developers-write-it to its-used-in-planning-by-architects-and-program-managers? That's obviously part of the ideals of the project, but how often does it become reality?

If what you are doing is ESB & SOAP-ish stuff, then you're probably on the right track (SoapUI, JMeter, etc). Maybe something like Apache Camel or some other workflow engine could be used to "script" tests that hit various services and cause data to flow through the products you mentioned?

If you're generating web pages/apps or RESTful services, there's lots of neat capabilities in things like Selenium/Geb, Jasmine, PhantomJS, etc. So maybe those are worth looking at, depending on what you need to test.