DEV Community: Paresh

RDBMS or NoSQL: The question that pops up with every new project!

Paresh — Wed, 22 Jan 2020 05:48:42 +0000

Barun is starting his next software development assignment soon, but his biggest worry is - SQL or NoSQL and he is pondering about these questions:

Which database to use for this new project?
Should I use relational database or NoSQL?
MongoDB is nice, it is schema-less and it does not require creating tables and normalize the structure, should I just select it for this project?
Or whether I just use cloud-native databases like Amazon DynamoDB or Cosmos DB?
No wait, I heard Redis can also be used for persistence and it is a key-value pair so that may also fit well here! The choices are endless...

Have you ever come across these questions or a debate on which database is right for your project? The decision depends on number of factors and there are dozens of articles available over internet explaining pros and cons of different options. I am not going to repeat them here. I am rather interested in documenting what some of the popular internet apps are using as their data store. I'd done this exercise in the past, but lost the record. While doing this exercise again, I thought this could be useful for wider #DEVCommunity.

It would be interesting to know from you if you have gone through the process of making decision on choosing the right data store for your application. Feel free to add your comments to build this knowledge base.

Twitter - Twitter was built on MySQL and everything was stored in a single instance of database. However, as platform evolved, it is using number of different database technologies - MySQL, PostgreSQL, Vertica, Blobstore, Graph store, Hadoop. You can read more information about this here
Facebook - MySQL, Memcached, Haystack (for photo storage), Hadoop and Hive. Read more about complete technology stack used by Facebook here
Youtube - MySQL, Bigtable
LinkedIn - traditionally used Oracle and key-value stores such as Voldemort. But then moved to distributed data store, Espresso.
Instagram - Instagram mainly uses two database systems: PostgreSQL and Cassandra.
DEV.together - PostgreSQL as primary datastore and Redis for cached data.

Note: this information is collected from different forums, engineering blogs and Q&A sites, if you think anything is incorrect, feel free to point out, I will be happy to update the post.

Mistake #3 - Not thinking about alternatives

Paresh — Mon, 18 Nov 2019 10:03:06 +0000

It's been few weeks since a new post was published in the series of learning from mistakes. In the first two posts, we went through what could go wrong if you jump into coding without understanding the problem statement and start making too many assumptions.

The next thing on the list is a very common mistake that even experienced programmers make—and that is—not thinking about alternative solutions.

Once you have a clear understanding about the problem statement, you start designing a solution around it. I've seen that quite often, programmers start implementing the first solution they derived for the problem. I've to admit, I've been into this category for initial years in my career, until one day where I had to fill in design document template where there was section titled—rejected alternatives—and that helped me understand that I am doing something wrong.

Thinking about alternative solutions enables you to reduce the chances that you may fail to notice something important—as you will be thinking about different options in the given context, and asking questions to get more details. It also helps you figure out what is important to the end user. For example, in some cases—UI design is less important for end of day batch jobs, but focus needs to be on performance of processing data.

It could also help you avoid reinventing the wheel and you may just need to integrate with some existing component, it all depends on the context though. My point here is to try thinking about alternative solutions, ask questions, talk to people who are experienced in that domain— be it a technical or functional.

It also helps your stakeholders understand why the solution you are proposing is best fit as compared to other alternatives.

Have you been making any of these mistakes?

Hello DEVs, have you received your hacktoberfest swag?

Paresh — Wed, 13 Nov 2019 04:38:33 +0000

It was mentioned that it could take 2-4 weeks to get the kits shipped to non-US address. Just checking with fellow DEVs if they received their kits?

When your hard-work pays off

Paresh — Fri, 08 Nov 2019 06:26:55 +0000

There will be obstacles, there will be mistakes, but with hard work there is no limit on what you can achieve. There are times when software developers' hard work pays off. You experience feeling of the happiness that words can't explain.

You have been assigned a critical production issue on Friday and you start thinking that your weekend will be at office now! You start understanding the root cause of the issue. And follow number of actions to get to the solution:

You read through the issue description and get more details from the user.
You then try and get hold of production environment (which you will not get).
You try to replicate the issue on other environment where you have access. You use same artifacts which are deployed on production server.
You try and get a copy of the production database.
You try and follow exactly same steps as user to reproduce the issue locally, but no luck.
You then try and find out whether there has been any change recently deployed to production server.
You drill down commit details between two versions, and figure out if there has been any change in the area where bug is reported.
You try and follow many other actions from your checklist and see if you can find the root cause of the issue. The actions listed here seems easy, but it can take days to accomplish them and one day you will be able to pin point the knock-on change.
You then roll up your sleeves and try debugging the application and see what could possibly go wrong. Ah! It was a null reference exception at line 320! You start celebrating and want to explain your findings to someone. You feel like you should be awarded Kudos for this. However, it is 11 pm and you are only one in the office!

Finally, 2 weeks of hard work, no code review comments and your solution works on UAT and Production environment. That happiness can't be explained to anyone and then you start singing 'Bug Fix Hua'.

What was your happiest moment while fixing bugs?

Does Dapr fits your need? Then do not reinvent the wheel

Paresh — Wed, 30 Oct 2019 05:31:18 +0000

What is Dapr?

Distributed APplication Runtime. An event-driven, portable runtime for building microservices on cloud and edge.

Why should you use Dapr?

Are you writing distributed applications?
Are you looking to build resilient, microservice applications and building your own internal mini-frameworks to make this happen?
Do you have your services written in multiple programming languages or frameworks?
Do you find it difficult to implement state handling, pub/sub messaging, which enable event-driven, resilient architectures?

Dapr enables developers using any language or framework to easily write microservices, providing industry best practices to solve distributed systems problems.

Checkout the git repo. If it fits your need then do not reinvent the wheel.

dapr / dapr

Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.

Any language, any framework, anywhere

Dapr is a portable, serverless, event-driven runtime that makes it easy for developers to build resilient, stateless and stateful microservices that run on the cloud and edge and embraces the diversity of languages and developer frameworks.

Dapr codifies the best practices for building microservice applications into open, independent, building blocks that enable you to build portable applications with the language and framework of your choice. Each building block is independent and you can use one, some, or all of them in your application.

We are a Cloud Native Computing Foundation (CNCF) incubation project.

Goals

Enable developers using any language or framework to write distributed applications
Solve the hard problems developers face building microservice applications by providing best practice building blocks
Be community driven, open and vendor neutral
Gain new contributors
Provide consistency and portability through open APIs
Be platform agnostic across cloud and edge
Embrace…

View on GitHub

What sort of questions would you ask to 12 years experienced developer

Paresh — Thu, 24 Oct 2019 08:19:47 +0000

Very recently I appeared for an interview with a small product development company that builds healthcare software products.

I was expecting questions based on my experience which is mostly developing back-end systems using .NET and .NET Core. However, interview started with the questions you generally find online via Google (SQL interview questions, ASP.NET interview questions).

Maybe I was under prepared and I did not get shortlisted for next round. However, I felt that I did not get opportunity to showcase my experience.

As an interviewer what sort of questions, would you ask to 12+ years experienced candidate?

Mistake #2 - Too many assumptions

Paresh — Sat, 19 Oct 2019 14:01:24 +0000

Translating the problem statement into working software is not a magic. It is a journey and the very first step is to understand the requirements. Often the details of the problem statement aren't clear and as a developer you start making assumptions and build a working solution. This is a good quality of a software developer; however, things go wrong when you start making too many assumptions.

This is a common mistake I noticed in entry level programmers and one of the reasons I found is they are afraid of asking questions. Maybe they are not comfortable to reach out to their colleagues or they feel their questions are not important.

If you are just making a start of your career as a software developer, I would like to tell you that your questions are important! While training new members of the team, I deliberately keep some details missing from the assignments. This is to help me understand whether those individuals are coming back with questions. It may be the case that you have too many questions to ask and you are not sure where to start? I suggest ask question with an answer and validate whether your understanding is correct.

I personally believe asking questions is a way better than making "too many" assumptions.

What are your thoughts?

There is a small exercise at end of embedded video which you may want to try to test your ability of asking questions.

Mistake #1 - Code First Approach

Paresh — Mon, 30 Sep 2019 13:53:52 +0000

“Mistakes are a fact of life. It is the response to error that counts.” - Nikki Giovanni

Everyone make mistakes and learn from it. However, it is also important to learn from others.

“Learn from the mistakes of others. You can’t live long enough to make them all yourself.” - Eleanor Roosevelt

My journey of becoming professional software developer started in 2007, and I have to admit that I have made mistakes throughout my career progression. A good thing is that I learnt from those errors. This series of posts is to highlight these mistakes as well as some of my observations when training fresh graduates. I hope this will help beginner and intermediate level developers, who are making their mark into the industry, to avoid repeating these mistakes.

The very first mistake that I am going to talk about is, Mistake #1 Code First Approach.

Programming is the process that takes an algorithm and put it into code that computer can understand and execute. We make use of programming languages to make this happen. In the growing world of technology inventions, you can literally automate any manual process.

A common mistake that I observed in an entry level programmer is that they don't work through the problem statement manually. This problem statement could be a programming assignment, developing a software application from scratch or adding a new feature to an existing software product. It is important that before you jump into coding, you need to make sure that you understand the requirements.

what sort of input will be required?
what is the expected outcome?
what will be the execution workflow?

There are dozens of other questions that should pop up in your mind. The very first step is to read and understand the problem statement and ask these questions to yourself, try figuring out answers to these.

You may get to the solution by simply jumping into the code, but remember it may take more iterations to the final solution. Using the right language construct is important, but it is more important that you have understood what you need to implement.

Looking forward to hear your observations on this topic.

Learning by making mistakes and not duplicating them is what life is about.

Keep learning!

For vs Foreach

Paresh — Fri, 27 Sep 2019 06:14:20 +0000

You may think this is a superfluous post as there are already many posts out there on web discussing about performance measures when using For or Foreach. Some of them are:

For vs Foreach Performance.
Which loop is faster for or foreach.

and many more…

for (int i = 0; i < collection.Count; ++i)
{
    // Work on a collection[i].
}

foreach (var item in collection)
{
    // Work on an item.
}

By looking at title of the post, if you think I’m going to get into same debate here, then wait! I’ve something else to say. It’s still for vs foreach. However, rather than comparing inherent performance of for vs foreach, I’m going to discuss how things could go wrong when a programmer incorrectly uses language construct for the given context.

Recently I’ve been reviewing a piece code doing some complex work on a collection:

foreach (var element in collection)
{
    int firstIndex = collection.IndexOf(element);
    int secondIndex = 0;
    foreach (var anotherElement in collection)
    {
        if (secondIndex > firstIndex)
        {
            // Use element and anotherElement for some operation.
        }

        ++secondIndex;
    }
}

You’re a reviewer of this code – now without reading this article further, check what’s wrong with this code snippet.

I was just wondering what is this code doing for a while. At first, only optimization I could think of was to avoid executing ++secondIndex once secondIndex > firstIndexexpression is true i.e. secondIndex will always be larger for subsequent iterations. Just after few seconds I said, ah – this is wrong! horrible code. There is another hidden loop here which is nothing but a call to IndexOf. It is a linear search over the collection and time complexity of the algorithm is O(n). Using for loop here will be much faster and much more readable.

for (int i = 0; i < collection.Count; ++i)

{

    for (int j = i + 1; j < collection.Count; ++j)

    {

        // Use collection[i] and collection[j] here for some operation.

    }

}

Conclusion

Never use foreach when you really need to use for. That is if you need to access indexes of the collection always use for.