Aaron Feng: Category thoughts

Philly Lambda

Aaron Feng — Wed, 27 Feb 2008 20:44:00 -0500

My company has hosted the last two Philly Lambda meetings. Toby DiPasquale gave the first presentation on Scala then Kyle Burton gave a presentation on Lisp. Both presentations were very interesting especially for a functional noob like me. There's a wealth of information amongst this group of people, so it's definitely a good experience.

Currently there are around 60 people on the mailing list. However, there's not much discussion happening on it right now. Hopefully it will pick up eventually. I'm definitely looking forward to seeing what's coming up next.

Goodbye ruby and path to a new language

Aaron Feng — Tue, 26 Feb 2008 22:45:00 -0500

Well, not in a forever way. Ruby is the language I use mostly on my own time. Since my free time is very limited, I need to shelf it for now. Making room for me to hack some lisp.

Like many people, my free time comes in small chunks. I have been using project euler as a way to learn new languages (also math). The code required to solve each problem is usually very short (30 lines or less). I can usually fit each problem into my small chunks of time very easily. It's a great way to get your hands dirty on the language you want to learn.

For those who follow my blog, you probably noticed that I have been posting project euler solutions in ruby. Since I'm trying to learn lisp now, I'll start to solve the problems using lisp. I'll post the rest of my solutions written in ruby in the following post.

Overall, I still enjoy using ruby. The lack of free time has forced me to make this hard decision.

Private method creep

Aaron Feng — Tue, 09 Oct 2007 05:53:00 -0400

Refactoring has been a buzz around the software industry for quite some time now. No matter what Editor you use, there are some kind of refactoring tools that will do all the dirty work for you.

The most common refactoring is probably the extract method. With a couple of clicks, a shiny new private method is generated with all the extracted code inside of it. This is where the problem creeps in. There's nothing wrong with private methods, but when you have a hand full of them it usually means that your class is carrying too much responsibilities. It should be split out into multiple classes.

Michael Feather recently had a post titled The Deep Synergy Between Testability and Good Design. In the post, Michael mentioned that the need to test private methods should prompt a redesign by breaking out the private methods into a new class. With the ease of the refactoring tools, redesign doesn't always come to mind since it does everything for you. Michael recognized that private methods are actually public interface of another class. As Michael said in his post, by removing private methods you are improving your design and increasing the testability of your code. Isn't that what we are all after?

Is Site5 Crash5?

Aaron Feng — Thu, 27 Sep 2007 10:16:00 -0400

Earlier this year I move my blog hosting to Site5. In less than a year, there were two hardware failures (that I know of) which caused my blog to go offline for a day or two. I'm bring this up because it just happened again last week. Site5 customer service has been very reponsive and helpful, however, I wish their servers wouldn't crash so often. Search for "Service Disruption:" on Site5's forum to see all the server crashes.

Don't fall in love with your theory

Aaron Feng — Mon, 13 Aug 2007 22:10:00 -0400

Over the weekend I was watching discovery channel, and a scientist said the following:

"Don't fall in love with your theory, be willing to modify it until it's proven."

People can have much more productive discussions when they don't fall in love with their theory.

Does your QA hate you?

Aaron Feng — Wed, 04 Jul 2007 23:28:00 -0400

DRY principal is probably the most fundamental philosophy in software development. It allows a programmer to flip a switch that takes effect across the whole system. While this is good for the programmer, it is bad for people in QA.

"You changed feature X, did that effect anything else in the app.", your QA asks. "Yeah, the whole app."

How should your application be configured?

Aaron Feng — Mon, 04 Jun 2007 22:16:00 -0400

Deployment is an important process of the software cycle. It needs the same level of care as the application itself in order to have a professional and successful product. Deployment needs to make a good first impression. After all, it is the first thing a customer sees.

Deployment itself is a big topic. In this post, I only want to focus on the actual deployment package. Since I'm working on a Windows platform, I will specifically be talking about the Windows Installer technology.

Beside the daily software development, I'm also involved with the direction of our deployment package. As our software matures, the required configuration also increases. The first intuition is to allow the MSI package to do all the configurations. This approachhas several draw backs. These draw backs might even ruin the professional feel of the application.

Let's start off with how one would allow the MSI to do all the fancy configurations. The only way to do it in the MSI world is to use CustomActions (CA). Anyone who has written a CA will tell you it is not trivial to build it reliably. There are several ways CA can be written, but the most robust way is to use unmanaged C++. This requires not only the knowledge of C++, but a solid understanding of the internals of the MSI. On top of that, the UI facility in the MSI is far less simple than standard Winforms. Complicated configurations might require a fancier UI. This will also not be easy to achieve.

Let's say in a perfect world, CA comes for free. The problem doesn't stop here. What if the customer needs to reconfigure the software? Since the configuration is embedded into the MSI, customers would have no choice but to uninstall and reinstall. Even worse, during the uninstall, some machine or user specific files might be lost since the uninstall removes all the files that came with the package. Sure, there must be some way to change the configuration manually right? If the MSI did it for the customerin the first place, I'm sure he/she might have no idea how to do it manually.

I would like to propose a different approach: External configuration tool that ships with the package. The MSI can even fire up the configuration tool after a successful installation. This would solve all the problems I described above, and the code base can be more homogeneous to the application (Assuming you are not building a C++ app). It will be much easier to build an intelligent external tool that can provide real time feedback on any configuration errors. The tool can even receive commandline arguments passed in from the MSI for slient installation.

One could make the argument that the configuration can be done inside the MSI via CAs and still have an external tool to configure the application. You may wonder who would want to duplicate this effort. If you are in the .NET world, you will have to support two different codebases that configures the application.

I think everyone would agree reducing the numbers of CAs can improve the reliability and the compatibility of the installation package.

I'm not saying CAs should be completely avoided, but use them wisely. What I'm saying is the application should be configurable outside of the deployment package.

Is Excel the ultimate business solution?

Aaron Feng — Sat, 02 Jun 2007 22:54:00 -0400

Sometimes I wonder why exporting to Excel is commonly found in software? It seems like the first requirement for all business-like software is the ability to export to Excel. This is also apparent from the development side since many UI controls right out of the box have this magical ability baked in, especially 3rd party controls.

I understand Excel is a powerful tool, and it solves problems for many. It's just ironic to me that we are building software that exports to some other format, so people can use an external tool to make sense of the data. Shouldn't the software itself help people to analyze the data?

I have actually seen software that has no real ability to analyze the underlying data. The only way to make sense of the data is to export to Excel then run some fancy macro in Excel.

The baked in exporting feature also creates another dilemma. If they are made by different vendors, they probably don't export the same way (maybe even from the same vendor) in terms of layout and formats. The facility to change the exporting behavior is usually limited or non-existant.

One could argue that Excel is just another format that allows people to share data, and they should be able to manipulate the data in Excel however they want. I'm totally fine with that. What I have a problem with is that exporting to Excel shouldn't be a replacement for real business value features. We shouldn't design the application around some magical control because it can export to Excel.