Taskwarrior Taskwarrior is an OSS CLI (to make it fancier, let’s call it TUI - terminal UI) based task manager. I have been using it for sometime and it works great for my use case. My Earlier Post on setting GUI notifications I wanted some discipline in progressing with my side projects most of which are on github and here’s what I did: set up a script which overrides task warrior’s data directory to current directory if it’s a git repository, this is so that I can segregate my todo tasks

SQL Injection Starting off with one of my favorite xkcd comic SQL Injection is a way where a user is able to send some ‘code’ as part of the input data to the server all the way back to the database. (UI layer doesn’t sanitize/validate, API layer let’s the malicious ‘code’ reach the database because it’s not mindful in how to separate ‘query’ and ‘data’). Taking the example from xkcd:

Currying Currying is an idea of decomposing a function and making the expression more clearer. (Note: it’s just expression decomposition and not execution) Example In Go: package main import ( "fmt" "strings" ) func main() { fmt.Println(someComplexOperation("hello", "there", "programmer")) fmt.Println(someComplexOperation("hello", "there", "manager")) fmt.Println(someComplexOperation("hello", "there", "CEO")) // Currying this function // By looking at the fuction we see that it can be decomposed, first step of computing from first 2 arguments // can be done and reused.

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.