First I’d like to thank you for being the main cause of letting me know about these 10gen MongoDB Courses via your twitter account (mine is @fabien7474). I have approximately the same background as yours and it was the first time I had the opportunity to practice some MongoDB stuff.

Concerning your feedback, I do agree with many of your points but not all.

1. “Thank you 10Gen for giving these free course” => Agree
2. “Course is very practical…” => Definitely
3. “The course is said to be “for Java Developers”. Unfortunately not…” => Yes your are right. This is not a course for Java developer but for any agnostic language developer who can follow this teaching without any difficulties

However I have to mitigate your two last points.

First, Java API is basic but, if you are about to use MongoDB in a Java application, you better not have using this API directly…the same way we don’t use JDBC API anymore in Database Relational space. Sylvain has pointed out some wrapper-like Java API. I will give you another awesome one : Gorm MongoDB plugin (http://grails.org/plugin/mongodb) that integrates the Mongo document datastore into Grails, providing a GORM API onto it. Simply awesome. You can use dynamic finder (ex: Person.findByName(“Bob”) or classical hibernate-like criteria query.
I do agree however, that the Java code given by these lessons so far is not a good practice for code safety and maintainability.

The only point I truly disagree concerns the Aggregation framework. It took me time to get familiar with the concept, but it is much more powerful that plain SQL code. The concept of transformation and pipelines is actually very natural, much more than SQL aggregation functions used in conjunction with GROUP BY where you end up with subqueries, temporary view/table and lot of left joins as soon as it gets complicated. Just figure out the answers for Week 5 homework if it was in plan old SQL ?
Until this Week5 course , I didn’t see any reason for myself to give up Relational Databases in a future project (except if performances or agile – promoted by schemaless style i.e. no schema migrations needed by domain model changes – are first-citizen and top priorities) but with aggregation framework, I found a practical reason for trying MongoDB in a much deeper sense.

Fabien.

And for me to collaborate on a project, I would need to be convinced by the product, which is far from being the case.

Cheers

1- You complain about doing too much shell. But you realized that the wrapper is the exact match of the shell commands. So what do you expect? Isn’t it more accessible to everyone to try your code directly in the shell rather than requiring you to compile java code at each trial ?
2- This course is about learning how to use MongoDB. Are you surprised you have to work on the concepts and basics?
3- The aggregation framework you criticize is, in my opinion, a strength for MongoDB. It provides a build in way to describe complex datas manipulations with small yet powerfull steps. Did you realize that those operations (in the homework) would be far more complex to code if you had a Map/Reduce operation to build?

Finally, if you do not like the Java driver … go and enhance it : it’s on github.
https://github.com/mongodb/mongo-java-driver
So every one can help improving it.
And please, do not try to compare Driver and Object Mapping framework, thath will never bo the same.

I hope I didn’t offence you.

classpath*:/META-INF/*AutoBeans.xml,classpath*:/META-INF/WebConfigurationBeans.xml,classpath:/META-INF/LayeredFileSystemBeans.xml,classpath:/META-INF/SiteResetOnChangeDetectBeans.xml,classpath:/META-INF/HeaderLanguageOverrideBeans.xml,classpath:/META-INF/ParameterLanguageOverrideBeans.xml,classpath:/META-INF/HtmlCleanupFilterBeans.xml,classpath:/META-INF/XsltMacroFilterBeans.xml,classpath:/META-INF/AvailabilityEnforcerBeans.xml,classpath:/META-INF/ProfilingBeans.xml

The first part (classpath*:/META-INF/*AutoBeans.xml) is static, and I’m using a naming convention so that everything that must be automatically activated is configured in a file that ends with “AutoBeans.xml”. The remaining part is appended before boot by reading a property file. This means that the application can be configured in multiple “personalities”. Of course, this is not as safe as OSGi, as you don’t have true modules which dinamically check for dependency consistency, but in simple cases it works and doesn’t bring in the OSGi complexity.

http://www.z2-environment.eu/home

[1] https://juju.ubuntu.com/

* You can enforce validation in the constructor of the EmailAddress class instead of validating the email address wherever it is used, i.e. when passing it to a method. This may result in big run time savings.

* Everywhere your use the EmailAddress class, you get compile time checking. Assuming the constructor of the EmailAddress class is correct, you can then rest assured that the parameter is a valid email address.

* Nobody needs a stinking framework to do a programmer’s job.

I personally prefer to type my String as an Email object and validate the object itself (with proper JSR-303 annotations). This is closer to the #DDDesign philosophy and even much more clear for API and documentation