Per Iteration Vs Per Loop In most of the languages, the loop variable (iterator) has a per iteration scope, meaning in each iteration a new copy of that variable is made. But in golang it’s the same variable that has the scope throughout the loop. All the changes (increments) apply to the same placeholder and if you are temporarily capturing them and spawning go routines or creating a function placeholder (for later execution) you start to see unexpected consequences.

Embeding a struct (just writing the type) creates a “has a relationship” with the parent. If the child implements any interface parent can directly invoke those methods. If there are more than one embedding and they implement a common method it’s okay as long as we don’t attempt to directly invoke it on parent (trying to do so results in compilation error - ambiguous selector) While encoding json (marshalling), encoder internally checks if the type implements json.

I have been using zsh (Z-shell) for a long time. Recently it came to my attention that opening a new terminal was taking about 2-3 seconds which is quite a long time. Just to rule out some other reasons, I switched my default shell to bash and saw if it was still slower and turned out that was not the case. Changing default shell chsh -s /bin/bash Normally all shells load up some configuration, aliases, etc while opening a session, .

Problem Recently I came across a scenario at work where I had to deal with real time updates of payment status in mobile which involved an asynchronous chain of events in the backend. Mobile would call the backend to initiate a payment request, backend would do basic validation - initialize the payment and return a token to the UI. Actual payment involved multiple API calls to some of the internal systems as well as third party systems.

DB Connections are expensive Normally following things happen when your backend service talks to a database: service initiates a connection to DB using the database driver db does the authentication and establishes a network session (tcp) if succeeded program/service performs some db operation (CRUD) which follows authorization (if user/role is allowed to perform the requested operation) Now if the service decides to close the connection, it has to do these all over again which is quite an expensive process.

We have pretty powerful modern IDE and tooling around debugging (including structured logging and so on). It’s so easy to yield to this paradigm of programming. Now I think it’s quite a bad thing. Here are my reasons: (disclaimer - my reasons against debugging only when considered as a primary approach to coming up with solution) too much reliance on debugging (if something goes wrong step through) takes away a key thing (thinking from first principles).

I have been working as a professional software engineer for over 4 years now and along the way I have picked up some heuristics about how should I take the task in hand. Clarification Getting a crystall clear clarity of what you are going to implement is of paramount importance. Pay as much attention to details as possible. It’s okay to conduct few more meetings with teammates on getting clarification rather than doing a root cause analysis for a misunderstood or a buggy code down the line.

AWS Cloudwatch cloudwatch allows to take a peek into your aws applications, their logs and other metrices. Apart from the centralized logging (kibana,loggly) where we limit retention duration (cost factor), cloudwatch provides a way to do pay-per-volume query operations. AWS CLI installation on mac configuration aws configure Setting up AWS keys Although cloudwatch comes with a nice GUI, we can leverage CLI to automate and ease up some tasks. Here is a use case for filtering logs and downloading them for further analysis.

up arrow key takes you to a list of recently used commands history command lists out the history of your commands (size as configured) you can search in your history by using (ctr-R), helpful if you know some keyword You can tag your commands with comments for ease with history search eg : some esoteric command #fixes-all (You can reverse search using fixes-all) all your commands in history are numbered

Concurrecy Vs Parallelism (Go-lang Example) This is the general understanding of concurrency vs parallelism. Parallelism: Having multiple threads do similar task which are independent of each other in terms of data and resource that they require to do so. Eg: Google crawler can spawn thousands of threads and each thread can do it’s task independently. Concurrency: Concurrency comes into picture when you have shared data, shared resource among the threads. In a transactional system this means you have to synchronize the critical section of the code using some techniques like Locks, semaphores, etc.