Following my previous post about server setup for web applications, I have now moved this blog from Site5 to DigitalOcean.
I have been using a shared hosting account with Site5 since 3 years now and 2 days ago the cPanel account at Site5 got hacked compromising my blog and a few other client projects I was supporting.
Since I did not hear from Site5 and their support has been non responsive, I decided it was time to move this blog to DigitalOcean, a service I have been using and recommending quite a lot.
Not being great at customer support is no longer an option. I always wonder why more companies don’t invest resources in hiring the best support staff. Any response is better than no response at all.
I have been wanting to write about server setup’s for web application since a long time, but I found this article today written by DigitalOcean which does a better job at explaining common setups.
5 Common Server Setups For Your Web Application
Most of my setup’s today are Separate Database Server, but I am looking into adding a load balancer to the setup soon.
DigitalOcean is my recommended hosting provider. Do give them a try if you looking to setup a server for testing /production of your application. I am slowly moving all my projects there. Here is my affiliate link.
You’ve spent a week or two working on this feature. You’ve spent time testing it and everything seems to be working well. You have a launch date set and it’s finally the day to deploy.
You go over all the updates one last time and discover a few things which need to be updated. Last minute changes are almost never welcome. Do you hold the launch or launch it knowing that the feature is missing a few details?
Facing the exact situation yesterday, I decided to do the latter. Launch, knowing that the feature is missing a few details. If the changes were critical I would have delayed the launch but these were not critical changes.
The good part about software is that you can always roll out the next update the same day. I am updating the feature again today. All the issues from yesterday’s list are now fixed.
If you are building a B2B software application you are fighting against a current habit your target customer has. In most cases, it’s either email or excel sheet. These two tools can be used for a variety of purpose and are used every day by a lot of people.
Why would they want to switch from something they use every day to your tool? From something they are comfortable using and don’t have to spend time learning to learning how to accomplish a certain task in your tool? These questions are worth thinking about.
They are indeed looking to switch to something better, but as soon as they face any issues with the new way of working with your tool, they will be quick to move back to the tool which worked well. Email and excel have been around for more than a decade now.
When you say your software is better, makes it easier, helps streamline and provides a unified view, I hope you also consider making it really easy to get started with. As easy as email and excel.
Not sure when reviewing code became a habit, but it is now part of routine before deploying new code to production.
Git diff is really helpful and lets me know of the new code being pushed.
It always surprises me that during review I notice conditions or logging methods that I missed adding to the code. There are less surprises and errors in production environment.
I use Beanstalk to deploy code to production and would highly recommend using this, if you are still deploying code via drag n drop using a FTP client.
My research on successful professionals underscores that this experience is common: As you become more valuable to the marketplace, good things will find you. To be clear, I’m not arguing that new opportunities and connections are unimportant. I’m instead arguing that you don’t need social media’s help to attract them.
Quit Social Media. Your Career May Depend on It. - NYTimes.com
I have been thinking of quitting Facebook for a while and the article makes some valid points.
My facebook usage has gone down considerably. Too many articles / memes being shared rather than facebook answering the question of what my friends are upto.
Programmers are often said to be optimistic about how long a feature / software takes to develop. I am constantly reminded of how true this is.
This week I thought a lot about time estimates and why I am often wrong with my time estimates.
It comes down to the need to please the person asking for the estimate. The expectation that the person on the other end wants it done as soon as possible and giving a short enough time would make them happy. An approach I am going to rethink from here onwards.
In larger organisations, a project manager is usually involved in arriving at the final time estimate which includes some breathing room the programmer forgot to budget for. But even then most enterprise projects spill over time and over budget.
Here are some ways I am going estimate time from here on:
- Understand the scope of the feature / software you are asked to develop.
- List down all the small components of the feature / software to be developed.
- Is there a third party company involved? Budget for extra waiting time for when you need some information from them.
- Is there a new language/ tool you need to learn to get the work done? Budget for time to learn and for those moments when the new tool just refuses to work.
- Budget for life in general.
- Are you working on multiple projects? Budget for time when one project takes up a lot of your time, leaving you less time to work on the other project.
Scope changes are part of software development lifecycle. When there is a change in scope, communicate this with person on the other end about how it affects the previous time estimate rather than trying to get the extra work done in the same amount of time.
Working on a new feature is always a good learning experience. One of the learnings today was the need to set better default values.
Could the user accidentally stop a timer before 1 minute? Not many would want to record time less than a minute. Rather than display an error message, it would be better to automatically update the timer entry to a minute.
The default theme, font, text size and so many other decisions you take when building your product end up making a big impact on end user experience. Not many would look under settings to change these values. Good to have an opinion about the default choice you decide on.