MongoDB - A Document-Oriented database (Part 1)

MongoDB is a powerful, flexible and salable data store. It have some features such as secondary indexes, range queries, sorting as well as built in support for MapReduce-style aggregation.
MongoDB is a document oriented database, not a relational one.
Document oriented database have more features than relational databases. The basic idea is to replace the concept of a 'row' with more flexible model 'document'.  Also mongodb is schema free database, No joins and lot easier to handle data.

  • Document is basic unit of data in MongoDB, like row in a relational database.
  • Collection is like a table in relational database.
  • MongoDB comes with a simple but most powerful Javascript shell .
  • Every documet has a special key called "_id".

Setup MongoDB
  • Download the appropriate version :
    • Windows version
      • Extract downloaded zip file. (Ex: C:\my_mongo_dir)
      • Go to bin directory and start the mongodb server by double clicking  the mongod.exe (Before that create data/db folder inside the C:\ drive) 
      • After that start the mongo shell by double clicking the mongo.exe (It will start a shell and you can type commands)
    • Linux Version
      • Extract downloaded tar file.
      • Create /data/db in root path.
      • ./mongod to start the mongo server.
      • ./mongo to start the mongo shell.

In the next part I'll show some basic commands such as creating, remove and update documents and collections in mongoDB.

Top 7 Programmers bad habits

1. The All code is crap, except mine, attitude.
I have bad news for you buddy, all code is crap. No matter how much effort you put on it, there is always a majority of programmers who are going to think that your code sucks and that they could have done it 10 times better. I have already covered this topic in previous posts, you can find more information of what exactly I mean when I say that all the code is crap here and here.

How to fix it : Don’t criticise others people code, it could be yours the one in the spotlight, try to make objective and professional observations instead, but don’t judge. Be humble and try to learn from everyone around you, hopefully then your code won’t be so bad.

2. The “I fix that in a second” catastrophe.
Taking shortcuts is very tempting, everyone has done it. There are actually situations where they are necessary, but in overall, they are dangerous, very dangerous and should be avoided. A shortcut which goes wrong may save you a few hours, but may cause months of pain.

How to fix it : Don’t trust yourself when carrying delicate activities. Ask someone else to review what you are doing. Make sure that if you are about to take a shortcut, you make very clear to the stakeholders what the reasons and the risks are. Try to get a manager to sign off every time you are about to take a shortcut.

3. The “That will only take a second” misconception.
Being Barcelona my hometown, I am very proud of the Sagrada Familia Cathedral, which is very well know for its beautiness, and also for the time is estimated it will take to complete, (in construction since 1882), but that’s probably because they didn’t ask a programmer to estimate, otherwise the estimate would probably have been somewhere around 2 weeks.

How to fix it : For starters, is important to understand that accurate estimations in software development for non trivial solutions are impossible, we can only guess. Also remember that is very likely that you will find so many things which you didn’t foresee when you start developing that is worth multiplying the estimate to cover for those, I usually go with 1.5 or 2.

4. The ego spiral

Many programmers discussions look more like rooster fights than human discussions. This usually happens in design and architectural meetings. It is actually quite easy to detect this ego spirals, you just have to substitute most of what the contenders are saying with COC! COC! COCOCOOCCC! COOC!

How to fix it: Leave your ego at home. Big egos are one of the biggest non technical issues for any programmer. Keep in mind some basic considerations when making decisions.

5. “It wasn’t me!”

In my opinion, other bad habit from most programmers is the lack of accountability. We always have an excuse… It’s like if we were saying that under normal conditions we would never make a mistake, which honestly is quite hard to believe.

How to fix it: No need to cry, or to perform seppuku, (aka harakiri), when we make a mistake. Having a healthy attitude where we can you just say something like: “yeah, sorry, now we need to do this to fix this issue, my fault” is a very professional attitude, and it will help you to build a reputation and to be better considered by your colleagues.

6. The demotivated genius.
Repetitive and simple tasks are not the best motivators, but they need to be done, programmers tend to get demotivated and very unproductive when they need to complete them.

How to fix it: Discipline. Unfortunately, there isn’t any other remedy I can think of.

7. The premature programmer.

If programming was sex, there would be a lot of unsatisfied computers. You can just not go in, do things halfway through and then fall sleep. One of the concepts that I find most programmers struggling with is the concept of “Done”. Remember that done means: tested (and not only unit tested), documented, committed, merged…

How to fix it: This one is tricky, the complexity of non apparent necessary tasks to fully complete some functionality is quite high and usually requires discipline and training. Probably the two easiest ways to help a programmer understand if some code is done are peer reviews and demos.

Original Source :

Apache Shiro is not just another security framework...