Prince Mishra

Search This Blog

Pages

Posts

If you believe in the greater fool theory, there is no other market as speculative and volatile as the crypto market today. We are perhaps living in the biggest bubble of our times. I am not bullish on this market in particular. I am bullish on the mania. 90% of the cryptos we see today will crash. They are just tokens with no tangible value generation capability. However, I believe that the mania and euphoria will stay.

Having said that, should one consider investing in this market? Certainly!
The risk/reward is lovely, potential upsides and margins are huge and with 3-5% of your net worth, the bet on the mania is worth it.

How does one choose where to invest?

If you follow the stock markets, you are expected to do thorough Fundamental Analysis before investing. Expect the same for the crypto market. I invest in large caps. I invest in index funds. And I invest over and over again. Markets rise, always. Extrapolating the same strategy - invest in indices - the top 10 tokens by perfo…

If you're coming from a compiled language context, using exceptions for flow control would look odd to you. But here's the thing - in the python world, exceptions are super cheap and using them for flow control is the "idiomatic python" way!
In fact, exception-driven flow control is built right into the language itself e.g. the "for" loop in python terminates when the iterable raise a "StopIteration" exception!

There is a lot of material on the internet already on the topic, so if there's one thing you take out of this post, it's this - in python, it's "Easier to Ask for Forgiveness than Permission"!

A recent fan of TDD, I set out to write tests for whatever comes my way. And there was one feature where the code would print messages to the console. Now - I had tests written for the API but I could not get my head around ways to capture these messages in my unittests.
After some searching and some stroke of genius, here's how I accomplished capturing stdout.

This holds true for developers, project managers, entrepreneurs, everybody who has shipped software to the real world. The biggest mistake one can make while shipping software is not shipping buggy code or half-baked features (and they are all easy to uncover given sufficient QA), or not planning for failure. The biggest mistake that folks make is - not planning for success.
Trust me - shit breaks loose when your app gets hot over the night! So here's a list of concerns one needs to plan for, before launching a site:

Caching
Cache everything - images, javascript, style sheets, html templates - everything. I use nginx at the frontend proxy layer and it does a full page caching for entire html pages. Works like a charm!
At the application layer, use Redis as a TTL-based cache.Deliver static content really fast
Images, JS, stylesheets - they need to be rendered by a specialized static files host - a CDN in essence. Use a managed service provider (Amazon CloudFront), or deploy nginx (…

Everyone needs a hobby. And some take it more seriously than others. Here's some cliched startup gyaan for someone wanting to take the plunge!Time is moneyHave a time table and follow it, specially if you have a day jobSharpen your toolsDon't spend time on anything you are not good at, because #1Automation is the key. if it can be automated, it should be automatedHealth comes firstDevelop to sell. If it cannot be sold, it should not be builtHave an exit plan and follow it. "I'll shut shop if I cannot get 10 paying customers in 6 months"You are the average of five people you spend most of your time withDon't stop having fun!
Cheers!

Only when you are the consumers of your own products, can you design the best ones! Same philosophies go for API design and programming in general.

This advice may seem counter-intuitive at first, but trust me, the best way to get better at backend programming is to spend some time doing frontend! It will teach you a lot about how your APIs are being used in the "real world". A first-hand experience of API consumption will tell you a lot about your design philosophies!

The last company I worked for, did have an office space, but the code was all on Github, infra on AWS, we tracked issues over Asana and more or less each person had at least one project they could call "their own" (I had a bunch of them ;-)). This worked pretty well. And it gave me a feeling that working remote would not be very different from this.

So when we started working on our own startup, we started with working from our homes. It looked great at first. I could now spend more time with Mom and could work at leisure. However, it is not as good as it looks like. At times it just feels you are busy without business, that you had been working, yet didn't achieve much. If you are evaluating working from home and are not sure of how to start, or you already do (then please review and add your views in comments) and feel like you were better off in the office, do read on. Remote work is great. But a physical office is better. So if you can, find yourself a co-working sp…