A software engineer based in the heart of the Himalayas, Nepal.
I write about technology, travel, and life lessons from my journey.
Currently building scalable applications at Truemark Software Solutions.
View My Resume
A software engineer based in the heart of the Himalayas, Nepal.
I write about technology, travel, and life lessons from my journey.
Currently building scalable applications at Truemark Software Solutions.
View My Resume
A while back, when I was just starting to get more hands-on with AWS and infrastructure, I ran into a performance issue that took me longer than I鈥檇 like to admit to figure out. At the time, we were upgrading one of our Rails applications to a newer version. Instead of upgrading the existing EC2 instance, we decided to provision a new one and deploy the application there. It felt like the safer approach since we could leave the old server untouched until we were confident everything was working as expected. ...
One of the first performance issues I learned to look for in Rails applications is the N+1 query problem. It鈥檚 surprisingly easy to introduce. The code usually looks clean, everything works as expected, and during development you probably won鈥檛 notice anything wrong. Then the application starts getting more data. Pages become slower, API responses take longer, and the database suddenly starts doing a lot more work than it needs to. ...
I was recently working on a small Sinatra application that used Tailwind CSS for a few internal pages. The application itself was deployed using Kamal, and the deployment process was pretty smooth. The only annoying part was that after every deployment, I had to SSH into the server and run: bundle exec rake tailwind:build It isn鈥檛 a difficult command to run. The problem is remembering to run it. After forgetting a couple of times and wondering why my UI changes weren鈥檛 showing up, I figured this was exactly the kind of repetitive task that should be automated. ...
I was working on a Rails application that used two PostgreSQL databases. The primary database was owned by our application, so we could create it, run migrations, and modify the schema whenever we needed to. The second database was different. It belonged to another application, and our application only connected to it for reading data. We didn鈥檛 own its schema, and we weren鈥檛 responsible for running migrations against it. Everything worked perfectly on my local machine, so I didn鈥檛 think much about it. ...
I was working on a Rails application that integrated with Slack. The integration had two main responsibilities. The first was allowing users to map their Slack accounts with their profiles in our application. The second was sending notifications to users or channels whenever certain events occurred. Everything worked well while we were developing locally, but once the application reached staging and production, we started seeing an issue that hadn鈥檛 shown up before. ...