If you want to learn the theoretical differences between these terms, you are better off checking it out on the web. Just do a search and you'll find a lot of hits.

But, if you want to get a sense of the more practical differences, and how you should apply it in the context of your specific project, then you may want to give this podcast a listen.

#projectmanagement

Manage your projects on https://snowpal.com. Keep it simple.

Pitch has always supported a Linking feature that allows you to structure your content any which way you want (aka, create content once, use it any number of times). Relations is a new feature that is another feather on the cap, and it works beautifully whether you use it with Linking, or simply by itself.

If you are starting to build a native mobile app and are a little unsure of how to proceed, this podcast (the first in this series) might offer you some guidance.

Even if you've decided to build a cross-platform native mobile app, there are still a few decisions to be made. In this podcast, I discuss a tiny bit about React Native and Flutter (2 very popular frameworks).

If you are using MongoDB and an Object Data Modeling library like Mongoose, or Mongoid, you may find yourselves in situations where your queries are taking a little too long. Come Aggregations to your rescue!

Say, your team is working on a number of features, and there is a steady stream of Pull Requests at any given time. The likelihood and complexity of merge conflicts depends both on the size of your team, and the scope of your features. In this podcast, I discuss a few options to mitigate merge conflicts.

If you want complete control over your servers, you would choose (something like) Amazon EC2 and start with creating a new Machine Image. But, what if your interest primarily lied in building your app, and solving your user's problems ASAP, and you didn't want to spend much, if any, time on setting up and configuring servers?

When you get started on a new project, it is natural to feel a tad overwhelmed. After all, it may be a new team, new technology stack, new processes, and new business problems - so it is alright to feel a little restless. But there is a way to feel at home by the end of Day 1.  

If it takes you 5 minutes to test 10 lines of code, there is a problem. If it takes you 3 minutes to bounce your (local) server, and that's the only way for you to test your code, there is another problem. 

Whether you are joining a new team, or a new developer is joining your team, the expectation is quite the same - "a good quality codebase that will help us understand the product without having to bug the rest of the team". How can we work towards building such a codebase?