This is a motto I carry when architecting/coding for my business.

Don’t experiment on a live environment .
Production is not a sandbox.

It may sound obvious when writing it out in words like this, but I come across many cases, and I myself am guilty of this too.
People many times try new things - whether it is using a new library/middleware, trying a new design pattern, or even trying a new way of structuring your classes - on the production environment, before being confident enough with the code.
This kind of behavior is especially prevalent when jumping on a bandwagon of a new, hip software (back in the early days of node.js, for example).

I don’t mean people write code INSIDE the production environment.
I mean, for whatever service or application you are providing to your users, you shouldn’t try anything new on those users, in terms of engineering.
It’s a great idea to experiment a lot on your users, in terms of business and UI. But for engineering, I don’t believe that that’s the case.

Engineering is a tool to achieve some sort of goal; Most times a business goal towards your users. As engineers, we have to be perfectly confident with the type of technology we use in order to achieve these goals.
Experimenting with new technologies and new engineering methods in a situation where we are supposed to be confident with our technology, is NOT a good idea.

–

Two big reasons will be:

1. Maintainability

Obviously. If you aren’t confident with your code (or middleware/library you use), chances are you will run into problems in the future. And chances are, you won’t be able to deal with those problems. Or you may want to run away to an alternative, but the switching cose may be too high.

A code-base is not a “write once and it’s over” type of game. We live with our code.
We have to treat code like an asset, not a submission.

2. Opportunity Cost

Most engineering problems have more than one answer. If you aren’t confident with the option you are choosing, there is a high possibility that you are missing out on a far more effective alternative solution to the problem.
Analyzing each and every solution to a problem thoroughly not only prevents this kind of opportunity cost, but it also allows you to understand the problem itself deeper.

###“Well then how do we innovate on engineering?”
Conduct experiments in a sandbox. Try things, throw away things, measure performances - do all those things BEFORE you decide to marry yourself to a particular solution.
That’s all. That’s what sandboxes and devleopment environments are for. That’s why the industry is coming up with efficient scrap-and-build environments like Docker and Vagrant.

–

So I finally finished my course on Hardware/Software Interface on Coursera!

https://class.coursera.org/hwswinterface-002

It was an awesome course, much more than I expected.
It went into learning simple Assembly language, understanding different CPU architectures, the real difference between 32 and 64 bit word sizes, and even up to memory allocation.

I got a good introductory knowledge about the real depths of programming, and it’s pretty exciting.

I just bought a book on Linux Kernels, so this knowledge should help me soldier through that book…

I’ve been tuning our production MySQL server (RDS), and I had to refresh some of my memory about how to analyze the EXPLAIN. Reading and understanding this correctly can really help improve your MySQL performance.

Here’s a sample output:

mysql> explain select * from tablea where id = 10;
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table  | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | tablea | const | PRIMARY       | PRIMARY | 4       | NULL | 1    | Using where |
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------------+

select_type

In our case, we hardly use subqueries or joins on our production application, so out select_type will most likely be SIMPLE. Other select_types can be found here.

type

The type tells us how the rows are being fetched. const is one of the best cases, where only one row is found. In our case we are using where id = 10, where the id is our primary key. Selecting for an exact comparison on primary keys usually get you a const type.

possible_keys

This lists all the possible indexes which the engine can use. We shouldn’t care for this too much, because what matters is what ACTUALLY is used.

key

The actual key used. This will be only one of the possible_keys, or even not included in them. What key is used can change according to the size of the data, so don’t count on the result of this being idempotent just because you have the same table schema.

ref

I don’t worry about this too much when I am not joining or doing anything fancy.

rows

This lets us know how many rows are estimated to be examined. This is a really important number; A large number of rows can mean trouble.

So, what I would do is, I would look at the type. If that’s an index or an ALL, it’s usually not good. I then look at the key to see that an appropriate index is being used.
Lastly I look at rows to see the number of rows being examined.

We want to fiddle with different indexes, and different query patterns, in order to see what query would have the best EXPLAIN. Many times it can mean adding an extra where clause to narrow down the condition or to nudge the engine to use a particular index.
Other times, you will need to design and add an index. (doing ALTER TABLE to add index can be extremely expensive, so be very careful with doing this on a live database).

–

This can be a quick reminder for how to deal with query optimizations.