No Duplication for a Good Code and Good Life

More things in life does not always leads to a good quality life. If the things is duplicated, its function is already done by something else, it's existence is a clutter and use up unnecessary energy. The duplication is bad in code too, it is a nightmare to maintain the same logic that scattered on several places. One changes on one place need to be repeated on the other ones that use similar logic, otherwise you'll break the code.

Having enough things is not just about living a minimalistic lifestyle, it also a way to stay sane, to not use things unnecessarily. If we can simplify things internally, we can achieve more complex meaningful things with much ease.

Bootstrap : Programmer's Friendly Web Front-end Framework

I had task recently to port some web content into a mobile App. I translated some web-navigation navigation into native mobile one. For example, some section listing is translated into TableView in iOS. However, for the content pages itself I need to basically put the HTML content into an offline-bundled resources within the App.

Below is some problem with the task :

• The Desktop version link to various online Javascript and CSS resources
• The layout is for desktop and need to be made more mobile-friendly

It will be time consuming to try to proceed without some kind of reusable solution. After some research I settled with using Bootstrap to help with the it. It's a web front-end framework that bundle some Javascript and CSS into a convenient package. My plan is to offload the script/style to it so I can focus on porting the content.

The content of bootstrap pretty much suffice for the current typical need for multi-device HTML rendering. At least with it I can port the existing Desktop-based content pretty quickly for offline mobile consumption. The styling and layout is already fit out-of-the box to my need. I can strip the existing Javascript and CSS references and make the content use things from Bootstrap. There is still some labor work on the porting but doing on top of a good foundation makes it more manageable.

JEdit : One Text Editor to Rule Them All (Functions and Platforms)

Any programmer would say his favorite text editor is the best one so I won't bother saying which one is best :). However, I do use one text editor, JEdit, for quite a long time already and find it a really useful text editor. Below is some of the reason :

• It does "everything" I can think of and more. It has a rich plugin list and so far I haven't find any of my needs that is has not met. Apart from coding which I do mainly on IDE, I use JEdit for the rest. Editing and Viewing binaries with it's Hex editing plugins, Editing XML even using it as a full-fledged IDE for some language e.g: Ruby, Python.
• It runs on all Platform. One of my main priorities of text editor is it needs to to be able to run on OS that I use. I did works on Windows, Mac and Linux so having text editor that can run on all of them is a big requirement for me. It saves a lot of time to be familiar with one advanced text editor and can run it on all system. The time you spend customizing the configuration, learning the shortcuts will pay off really well.

There is one situation that I can't use JEdit though and that is the time when I am working on command-line/shell. When that happens, VIM is my friend. So, I guess, JEdit doesn't really rule everything yet.

Code for your future self

It's quite annoying to work on existing code that you find hard to navigate and understand. It makes you spend some significant time first to understand the existing structure before you can finally add the feature or fix bug you intend to do in the first place. It does not have to be the code written by someone else, even your own code can give you some hard time when you revisit it again at the later time.

That is why the importance of writing good code is not just so the features runs well and the code looks good to your peer. It is also for your own benefit to have the code done in a well-designed and intuitive way at the moment you wrote it.

There will be temptation to code something quickly when deadline is approaching or you just feel lazy to extract those abstraction that you find. For your own sake, resist them and write code properly in the most natural and the most obvious way you can think of it. Your future self with start with that kind of intuitive thinking before he jump into specialize cases, workarounds and other tricks.

Here is an example of the things you can do to minimize the pain of your future self coding session :

• Choose good naming. This is simple and highly essential but easy to break at the time when you feel lazy or under pressure
• Have all the dependencies locally and self-contain whenever possible. For all dependencies that you can not put locally, put detailed documentatio on how to get it
• Automate and simplify the build system. Again document unscrypted steps extensively
• Make notes and diagram on general architecture. Give high level diagrams and don't forget to update them when it no longer reflect the actual code. Do not go into too much detail on this. Focus on  describing the big picture of architecture on the notes and diagram and let the code speak for itself whenever it can

Think of yourself when coding. He will thank you greatly later when he has to work on it again in the future.You know, even your current self will appreciate it too. It's much more fun to make a good code than to make a hasty/sloppy/buggy one.

Focus on Personal Workflow and System, Not Gadget and Apps

Gadgets and Apps are abound today and the discussions that runs mostly are about what Gadgets can do this and that. I think many times the focus are misplaced. Gadgets are just tools and what is most important is the personal system workflow that a person has. Without that, gadget has no context and will just be a distraction with each additional feature. However, when you have system, each feature on the gadget can use to improve certain aspect of that system.

When you have a workflow involving calendar and reminder, a good calendar app can make that part of your system more optimal and in turn will make the overall system runs better. However, when you don't have need for calendar in your personal workflow (which is not a sin, BTW :) ) it will be just a toy to try a little bit and never used again or worse you keep keep wasting time using it without adding any benefit to your system.

So, I guess what matters is what system that you have and what combinations of gadgets and apps that can make it runs better. Researching new gadgets and apps can be useful if you use it to see how you can improve your existing system with it.

Winforms C# : Prefer initialization in constructor instead of Form_Load event handler

On Windows Forms, I have been doing initialization of values on Form_Load event handler. I use constructor mostly for make instances of member variables and setting basic/default values. I did the rest of the settings e.g: config, last state, on Form_Load. It turns out that it's not actually a best practice to do so.

I've just stumbled upon this discussion on Stack Overflow that explain that it is actually better to minimize the use of Load. In summary, here's the guideline on Constructor vs. Load issues :

1. Initialize things on constructor 
2. Only use Load for code that needs valid windows handle e.g: code that requires the window size and location to be known
3. Override  OnLoad instead of using Form_Load event handler. This ensure more deterministic order of execution in relation to parents OnLoad call

I guess it's time to change the habit.

When You Know Better, Code Better (In the meantime, code it the best you know how at the moment)

There is a good, albeit very short, article on Lifehacker titled "When You Know Better, Do Better". The important take of the article is actuall the message "Do the best you can with what you know now".

There is always a better way to do anything. If we got preoccupied wondering if this is the best we can do right now we'll get paralyzed and nothing will get done. Even worse, when we finally decide to take action anyway, we might take less optimal approach due to self-doubts.

I think this is even more apparent in programming world. There are literally thousands of choices available for us to solve a programming problem. From libraries, frameworks, patterns, languages, text editor, diagram tools, we will probably won't do our best work if we agonize over what is the best that is available.

Referring to the advice above, we could focus our search for the best on what we know already at that time. We will learn new things along the way and at later moment we can do our best again with our knowledge at that time and repeat. I find this quite liberating and help a lot to minimize the noise on the head while coding. I can focus to produce the best work with what I know at the time. I'll do better when I know better.

Diagram Smell and Refactoring

My use of UML for reverse engineering the existing code perhaps the same amount as my use of it for designing codes to be written. They both server the same purpose though, to give me insights on  what to do next on the code. On reverse engineering case, it sometimes reveal certain connection that does not look right. There is a term Code Smell, so perhaps this could be named Diagram Smell.

The same as Code Smell where you see/feel something unpleasant on the code e.g: conditionals that looks like stairs, duplications everywhere, diagrams that is not pleasant to see and draw could hint part of the system that is not optimally structured.

Below is an example of diagram that looks suspicious :

Sometime, when I encounter the construct as above, there is a superclass that is waiting to be extracted. The code can then refactored that when reflected to diagram can be seen as below  :

Of course, visual can be subjective things. Some people might not like the picture above :). However, I think we can now "understand" the nature of Class A and Class B better. We can also see more naturally their connections with the related helpers. I like things that could add the understandability of the code, it will ease maintenance in the long run.

Bad-looking diagram does not always means bad code though. It just a hint for us to look more at the code in case there is potential problem to be fixed. It could be the code is already in good condition while we draw diagram from the wrong understanding of it.

Book Notes : Paradox of Choice by Barry Schwartz

I have recently finished reading "Paradox of Choice" by Barry Schwartz. Below is my personal notes of it.

The book is centered around reminding us on how the larger number of choices does not always means more happiness. It is true that low number of choice is limiting and certain number of choices can empower us. However, when the choices has grown large several factors started to come out that could limit our effectiveness to utilize those choices. Factors like regrets, opportunity costs can ruin our lifes as much as, if not worse than, the lack of choices.

Regarding the above issues, the book can be quite repetitive. It discuss the same matters several times although using different studies and perspective. I am already quite convinced that too much choices is problem by half of the book, so the additional facts add little to it although still quite informative. The book finally closes itself by summarizing some things we can do to manage the explosion on the number of choices to our advantage. It discusses the "trick" along the previous chapters but it gave one chapter to lay it out in a summarized format. It is useful for reviews and make some plan of action.

Below is some of what you can do when faced with choices so you can utilize it optmally :

• Choose when to choose. Decide on which area the choice is important and then spend time energy to make a good choice there. Still, limit the number of choice, so you can choose effectively. As for other areas, just stick to safe defaults.
• Be a chooser. Have time to reflect and not being pressured. Can choose to not choose and create new options and opportunity instead. Decide substantial goal and evaluate choice based on it
• Satisfice more and maximize less. Choose things that is "good enough", fulfill your needs and be happy with it, do not worry about loosing the ultimate best, it might not worth your time
• Think about opportunity cost of opportunity cost. Do not worry too much about what you miss
• Make decisions non reversible. You'll regret less
• Practice an “Attitude of Gratitude”
• Regret Less
• Anticipate Adaptation. Be aware that you will finally get used to what you choose. It might not get as exciting as you experience initially. Remind ourselves about the intrinsic quality of the choice that we have made
• Control Expectations
• Curtail Social Comparison
• Learn to Love Constraints. Choices within constraints is better then having none or having infinite one

Now that I think about it again, the above items might not have the same impact to the reader if the book does not repeat the ideas throughout the book on a different light. With all the books, blogs, news, apps, musics, movies, games, gadgets and with the current flood of "stuff" in our world today, this book can serve well as a reminder to not get carried away and lost ourselves and our sense of purpose in the middle of it.

Use Fody to Simplify INotifyPropertyChanged Implementation

I was looking for a way to simplify implementing INotifyPropertyChanged. The standard way was too noisy to my taste so it would be really nice if there is a way to simplify it. Early on the search I stumble upon PostSharp . However, it's quite expensive and seems to be a relatively big "framework" for just my simple needs.

I later found the PropertyChanged.Fody and it fits my needs nicely. It is free and works really well. You just need to install with the command below in NuGet's Package Manager Console

PM> Install-Package PropertyChanged.Fody

and you are good to go. NuGet will take care of installing the needed dependencies e.g: Fody.  Implementing INotifyPropertyChanged is now just a matter of adding  [ImplementPropertyChanged] attribute to a class. Very convenient.