December 2018 Shopping Spree

Last month was a shopping month for me. I’ve spent somewhere around one hundred thousand baht for stuffs. One reason is I went to Japan where something is a little bit cheaper there. One other reason is … end of year sales I guess (especially on Steam)

And below is what I bought in the last month.

1. Virtual Reality

My focus of the last month is VR. I bought two VR headset: HTC Vive and PlayStation VR. I bought both of them because there are games that available exclusively on each platforms.

Personally I don’t find much differences between the two. May be because I only have different games on different platforms, I couldn’t make comparisons. Comfort-vise, I think PSVR is better. However, Vive is better on specs, and it also supports room-scale VR (which I don’t have enough space to try).

2 Drawing Tablet

Last year I bought the Intuos Pro M, and it works pretty well. This year I found that the Cintiq Pro was on sales (with ~12000 yen discount), so I get one of them. Since the Cintiq is also a screen, it’s much easier to use than the Intuos.

3 Software

I was trying out a number of 3D graphics applications. One of the software I bought is Marvelous Designer 8. Basically it’s a cloth designer software for 3D models. This one is made popular by Hideo Kojima and his team at Konami, as it was used in the Metal Gear Solid series since the 3rd installment I believe. With MD8, clothing looks much more realistic than modelling each cloth by hands, as it uses the actual clothing pattern, and it simulates cloth in realtime very well.

Asides from Marvelous Designer, I’ve also got Marmoset Toolbag and Substance Painter+Designer suite.

Well, to be honest, I’m not a graphics designer/modeller. I’m a programmer. The reason I get thses software (along with the Cintiq above) is to learn what the graphics people do in their real life. I think that would give me insight on how should I talk with them at least.

4 Game

I bought a few VR games, eg. Summer Lesson, Beat Saber, VR Kanojo, Doom VFR. VR to me feels very new, everything is so near and I feel like I’m in the situation. Sometime it can be scary.

Configuration Management

Most application, services, app, program, whatever has some kind of configurations. Some of the them are visible to the user, some of them are only available to the provider, some of them might be derived from other settings.

In larger applications, like web services and stuffs, configurations play a huge role. No one wants to recompile the whole program when there are needs to move the log file location, for example. Well-implemented applications provides numbers of configuration, so they are flexible enough to handle different environments and usages.

Below is what I think it should be taken in consideration when designing configuration management.

Configuration implementation is ‘details’.

There are multiple way to keep and to read the configuration. It could be an in-memory objects, SQLite, SQL server, No-SQL server, Redis, or even a configuration server. Regardless, this should be considered as a ‘detail’. The application should not aware of how these operations work. It should be able to query the configuration through an interface which is opaque to it.

The application should be able to switch between implementations without much change down in the application code. If the architecture is designed well, switching between implmentation should not takes more than 10 LOC changes, excluding the interface implmentations.

It might be a plus to be able to switch the implementations without changing code. However, this usually come with complications (eg. another separated set of configuration in another configuration implementation). Consider the complication and choose wisely wheter or not it needs to be that flexible. Usually applications do not need to change the configuration implementation very often.

Treat Configuration separately from Data.

Configuration should not be treated like a data. It controls how the application work, as opposed to data which the application operated on.

By its nature, data is incrementally changed over time. After application is used for quite some time, amount data will grow. Configurations, in the other hand, does not get increased as much. Most of the time it stay the same, and occasionally updated to accomodated business need. Configuraions only increases when there is a new capability added to the application.

Because of how often the data is updated, its not advisable to keep every single version of data. It just simply too many. What can be done is to log the operations made to the data, which can be later traced by developer when something bad happens. Also having a snapshot periodically helps to quickyly restore the data back to the proper state.

However, since configuration is rarely changed, it’s quite easy to track every single version of the configuration. For instance, we can put the configuration source in an version control system.

Keep number of the configuration sources low.

Configuration is needed to be loaded in some kind of source. Here, I’ll call it a configuration source. It could be simply a configuration file, or may be a configuration server. Again, the implementation is just a detail.

Anyway, one thing to consider is there should not be too many sources. In best case scenario, one universal source is prefered. This source should keep every single configuration, as it is easier to track changes.

In some scenario, there might be needs for ‘configuration overide’ which settings from one source override another. Be mindful about designing the policy. There should not be too many level of override, as it creates ‘dependencies’ between them. From my personal experience, 2-3 level is acceptable, larger than that it might be too many. Also having multiple source of truth creates confusions in the developers and operator. It will hurt everyone in the team in the long run.

Having multiple sources that incrementally change the configuration is unadvisable. The reason is it creates multiple level of dependency. Configuration sources have to be load in an correct order, otherwise the configuration will be incorrectly loaded.

When there’s no one paying, everyone pays.

One of the argument I’ve heard the most is “Yeah, it’s nice to have, but no client is going to pay for this”. That reasoning seems to be right on spot, not every clients are going to appreciate everything you did for them.

In software development, there are things that the client will get directly from us, and something else that is not direct benefits for them. The client would not see any benefit from that latter, so do some of the developers and some of the management. They all care about deliverable. Things that does not ship means nothing to them.

But, is that really the case ?

Let says, I have a product, written in-house, accompanied with a pocketbook size of build instruction. It takes the developer busy for at least 3 hours to setup. Imagine you have a team of 20 developers who have to do their own build. That’s already 3×20 = 60 hours of the waste of time. And I’m not saying that everyone will do their build only once for their lifetime :).

Oh, did I mention … “at least”?

And who is paying for that 60 hours? The client, of course. However, it will quickly returns back to the company. Having the developer spending time on the build means they take more time to response to the change, or may be the production issues. Slower to response means less client satisfaction, that leads to clients leaving. That’s the last thing you’d hoped for.

Also the developer would not happy about this. In worst case, they will leave the company. For milder cases, they are going to cheat. Personally I think most people like challenges, but don’t like difficulties. They will cheat, for sure.

In my example, I found that many people keep using the same build for many work item and for many years. Using the same builds on a items that based on the same product version is OK, of course. However using it all the time is considered a very bad practice, as software evolves as time goes by. I have seen a guy who use the 3 years-old code to work on a very recent item. How can we know that that code will have the same behavior as the most recent one ?

One more epic example, some people I know refused to work for that product at all. They said it’s to difficult for them. I’m not blaming them, though, it’s indeed very difficult. Some of us just happens to have more endurance. Well anyway, that results in resource starvation. The backlog list will get longer and longer as day goes by. Will the client happy about that ?

Ideally, all code base should takes one step to build. That’s the suggestion made by many gurus, and I heartfully believe in it. I mean, things that can be automated, should be automated.

Anyway all the change we do is to make sure to serve the client the best service, in timely manner, to win the client satisfactory. Some changes are directly beneficial to the client, and it’d be acceptable for them to pay. Some are not, and for that it’s up to company to consider investing in. At the end of the day it will save more than we’d spend.

I’m not going to say that every changes will be beneficial, or even worth the investment. However I believe that any idea, any suggested improvement should be reviewed and considered. There are too many good idea discarded just by the word “no one is going to pay for it”.