Rust Lang in a nutshell

StackOverflow's developer surveys have shows Rust to be the most loved language in the last couple of years. Infact, Deno is written in Rust!
Read more

Rust Lang in a nutshell

StackOverflow's developer surveys have shows Rust to be the most loved language in the last couple of years. Infact, Deno is written in Rust! Here's why:

  • Rust is a statically typed but intelligent enough to decipher types of variables where they aren't explicitly typed.

  • Immutable variables by default. This ensures that data cannot be changed by functions unless you specially mark the variable as such.

  • Ownership and borrowing of variables is the most important concept in Rust. It's also what leads to a higher learning curve. Each value is "owned" by the variable that is destroyed when it goes out of scope.

  • When a new variable is assigned to the old one, the old reference is destroyed. Let's take a look at an example

    let s1 = "Hello world".to_string();
    let s2 = s1;
    

    s1 will cease to exist. The value of s1 gets transferred to s2.

  • A variable can also borrow the value from the owner. Borrowing is simply a pointer reference to the original data. Strict rules govern this act. For example, the borrower cannot outlive the owner in scope.

  • While this concept is a little weird, it prevents null pointer exceptions, dangling pointers and buffer overflows.

Given it's type safety and emphasis on data security, I think Rust will be the language to look out for in the next 5 years, or till another language is invented to take it's place.

Full Post here, 20 mins read

What is Deno and will it Replace NodeJS?

For the past 2 years, Ryan Dahl has been speaking about the shortcomings of NodeJS. He is now attempting to resolve those problems with NodeJS.
Read more

What is Deno and will it Replace NodeJS?

JS Programming Language
Courtesy: Toggl

For the past 2 years, Ryan Dahl has been speaking about the shortcomings of NodeJS. He is now attempting to resolve those problems with NodeJS. Let's take a look at some of the promises made by Deno:

  • Security is integrated into the language. Via CLI arguments you can enable/disable access to a filesystem or network resources to a Deno script. This is a huge boon for operations folks.
  • Unlike NodeJS, the standard library for Deno is more featureful and works well independently. You only require dependencies for complex tasks.
  • Typescript is a first-class citizen and requires no extra tooling for it to work in Deno. No more tranpilation!
  • Bid farwell to node_modules/. To me, this is the biggest advantage of Deno. All dependencies are part of the binary itself and don't require an external folder as a cache.
  • Better tooling all around. An improved debugger (which is essential), test runner and file watcher are just a few of the things.

This is an exciting new development in the programming world. We are all looking forward to see how Deno performs against real-world production use-cases.

Full Post here, 6 mins read

10 Tips for Debugging in Production

This is an interesting story of how this team solved a tricky bug. What followed was a checklist of things we can all follow to debug production code.
Read more

10 Tips for Debugging in Production

Heisenbugs
Courtesy: Geek and Poke

This is an interesting story of how this team solved a tricky bug. What followed was a checklist of things we can all follow to debug production code.

  • Eliminate all the improbable scenarios immediately. In order to do this, it's perfectly fine to add temporary debug code to your production deployment.
    Just remember to remove it after.
  • Don't be afraid to ask co-workers for advice. It's likely that they've seen something like this before. Experience trumps everything when you're stuck.
  • Read, read and then re-read the logs. In my personal experience, lot's of people simply skim the logs and miss out important details in the logs.
  • Don't ignore dependent libraries as potential sources of problems. After all, that is code written by another human.

Lastly, The fact that you had to debug in production means that you couldn't reproduce the error on your local machine. Once all fires are extinguished, spend time fixing this problem.

Full Post here, 15 mins read

Distributed Logging Architecture in the Container Era

Logging is a cross-cutting concern in any application.
Read more

Distributed Logging Architecture in the Container Era

  • Logging is a cross-cutting concern in any application. For distributed application, it's better to have shared logging technology across all the services. Log aggregators are a solution for polyglot systems as they have connectors to most languages.
  • Logging infrastructure must be searchable. What's the point of logging everything without being able to answer queries like "Which service throws the most errors?"
  • Using a single correlation ID across services allows you to filter log messages from all the sources. This makes debugging a lot easier if you can view all the code paths that a request touched.
  • Include a lot more context in each log message. Data such as username, service name, timestamp etc are very handy to scan through logs quickly.
  • Network failure is an inevitability when dealing with log aggregators. Some of the ways to handle this are using local disk to log or a fallback service.
  • With privacy and GDPR in full force, be careful to not log personally identifiable information.

Full Post here, 9 mins read

The Myth of Advanced TDD

This is an excellent post around using tests to drive design decisions. TDD is a much touted, much hated and much loved paradigm in the software world.
Read more

The Myth of Advanced TDD

This is an excellent post around using tests to drive design decisions. TDD is a much touted, much hated and much loved paradigm in the software world. This post shows how using mock objects in a test case allows us to expose design flaws in our codebase.

  • Listen to the test cases to refactor and improve your code design.
  • Mock objects and test doubles expose design risks early. If the code seems very tightly coupled to the test case, then change the design.
  • If the test has duplicate assertions for the same field, that points to a missing abstraction.
  • In your code flow if a lot of code seems inter-connected, consider using event sourcing to reduce the coupling. It'll make the tests also easier to write.
  • Advanced TDD is indifferentiable from diligent TDD.

I've been trying to incorporate more TDD in my professional projects. This post was the trigger to be more conscious and diligent about it. Do you practise TDD in your daily flow? Any other resources I should read on this topic to get better?

Full Post here, 13 mins read