Do you feel like you’re working all the time? You have that feeling of constant pressure to do more and more? Are you having trouble sleeping? Perhaps, you wonder what it’s all for and are considering quitting your job?
These are just some of the signs that you might be suffering from burnout.
Fear not! With these 3 healthy habits, you can banish burnout from your life.
To relaunch the blog, I chose Hexo as the framework to use to statically generate the new site. In this article, I’ll detail the steps to get everything set up and ready to publish new posts.
Recently, I decided to revive my blog which, like many blogs, had gone defunct for a while. Watching a talk by Scott Hanselman reminded me and helped clarify the reasons for having blog and writing regularly. So I dusted off the backup I had and got to work setting up a new iteration of the blog. This post will be the first in a series to document what was involved in setting up this blog.
Many of us are very good at putting our heads down and cranking out code. We even are really good at stepping back and thinking about how a particular portion of the system should be designed at a higher level.
Every once and a while, it’s useful to step up even further and think about your software system as a whole and think about the path forward. One way I’ve been thinking about this lately can be summed up as the four M’s: Monolith, Modularity, Microservices and Monitoring
Over the past few years, we’ve been building the frameworks and libraries that will enable us to move our application infrastructure to a microservice based architecture. So what, exactly is a microservice?
Open source software is a way of life for developers these days. It would be almost impossible to write a modern day application without using at least some third-party open source tool or library. With all this code getting pulled into your application, it is incredibly important to learn how to read other people’s code. The ability to quickly understand and follow the inner workings of a third party library will make you extremely productive as a developer.
There are a dizzying array of technology choices out there. Need a message queue? Do you use Kafka, RabbitMQ, or Redis (just to name a few). How about a data store? Maybe MySQL? Postgres? One of the plethora of NoSQL offerings out there? How do you choose the right technology? This is a question I’ve faced many times in my career. I’ve found that if you break the problem down into three main steps, you’ll usually make the right choice.
It was a dark and stormy night. At least, that’s how it can feel when a deployment to production goes horribly wrong. Problems don’t just affect the support staff, it can affect the bottom line of the company. Putting new code into production is inherently risky. Any time you change the state of the production system, there’s a chance of something going wrong.
So how do you reduce this risk? Here are three ways to reduce the risk of production deployments:
Do you want to learn a new language? Spanish? Chinese? Ruby? Maybe Python? The cognitive benefits of learning a second language are well documented. While it’s not clear if learning programming languages impart the same mental benefits, it is still helpful to have a repertoire of languages. Some languages are great for processing text, others work best on embedded or mobile devices. Different languages lend themselves to solving different problems.
Have you thought about your threads lately? No, I’m not referring to how stylish your clothing looks. Have you thought about how you execute the asynchronous operations in your application? Splitting off tasks into separate threads is often a great way to improve performance or reduce the response times. But if you don’t give any thought to how those tasks are organized and managed, things can blow up quickly.