Every Second Counts

Several days ago, I downloaded Cygwin, which is a collection of tools, library, and API that provide Unix-like functionality on Windows platform. Installation is quite easy, we only need to download a small setup file, then run it to further select and download packages we need.

Using Cygwin, we can develop and build applications normally written for POSIX operating system, and run them on Windows from Cygwin shell. This is possible because Cygwin provides DLL that complements Win32 API with additional POSIX-like API, which is called Cygwin API.

I personally use Cygwin to run ProFTPD, because there’s a need for testing my program with Unix-based FTP server. I could have used linux, but I was just too lazy to install linux on my office PC

It is a phrase that Micheal Feathers uses in his preface to his book, Working Effectively with Legacy Code, when he describes the start of his passion for programming. As a software developer, I’d also like to share with you how I got into this programming world. I was in 6th grade of elementary school when my older brother got his first PC. It was Intel 8088 (so-called PC XT at that time). At first, I used that PC for playing games when my brother went to the college. Yea, playing games was very interesting at that time, although the graphics look archaic if we compare it with current games.

Later on, I read my brother’s book about programming in BASIC language. Well, since childhood, I was always interested in reading books related to science and technology. My intention when reading the book was that I wanted to know how to make all interesting things happened on a computer, like all the games I had played. Then it began. I immediately got very excited about programming. I don’t really remember what my first program was, but I still remember that feeling, the joy of making things work on a computer. One of my early programs was a plain arcade game showing two helicopters shooting each other, one controlled by the player, and the other one by the computer.

When I went to junior high, my interest in programming was still intense. I started to learn Pascal and structured programming. I also learned about pointer and all the things made possible by the use of pointer concept. It was very hard for me at that time, to break the habit of using the infamous GOTO statement. Only after some exposures to structured programming, I was finally able to write somewhat large programs without GOTO. My greatest achievement in Pascal programming was a tennis game, that was quite enjoyable to play (for me, at least). Well, I was still a youngster, so it was not unusual if many programs I created were games and the like.

My first experience with Test Driven Development (TDD) was about 2 years ago, when I worked on a project to develop h.264 codec at my previous company. At first, the notion of creating the test before writing the code seemed confusing. How are we supposed to test the code that we haven’t written yet ? That was the first question that popped into my mind when my co-worker explained the process.

After I actually applied TDD, the idea became more obvious to me. In TDD, because the test was written before the code, it will obviously fail. Our next step is to write the code that will make the test pass. After all the tests pass, it’s time to add another feature, that we state in new tests. These new tests will pass after we write the code for the new feature. This process will repeat until we implement all of the features in our program.

In TDD, this test is called unit test, which verify the correctness of one module or class. This unit test should not be confused with acceptance test, which verify the behaviour of the whole application. Unit tests will grow as we add new class and functionality, and should be run every time we build the application.

One of the advantage of TDD is, as we add new code, we will be informed quickly if the newly added code break the functionality of previous code, indicated by failed test(s). TDD will also help the programmer to think about how the interface of the new class or module should look like. To make the class or module easy to test, it should be made modular and less coupled, which in turn, will improve the design of the whole application.

Di blog ini saya akan menulis dalam bahasa Inggris maupun bahasa Indonesia, tergantung topik yang hendak saya sampaikan. Untuk topik - topik yang berkaitan dengan profesi saya sebagai software developer (bahasa indonesia : pengembang perangkat lunak), saya lebih suka menggunakan bahasa Inggris. Sedangkan untuk topik - topik lain yang sifatnya umum saya mencoba untuk menulis dalam bahasa Indonesia.

Dalam bidang ilmu komputer dan pengembangan perangkat lunak, banyak sekali istilah yang belum ada padanannya dalam bahasa Indonesia, walaupun sekarang telah ada usaha untuk menerjemahkan istilah - istilah tersebut ke dalam bahasa Indonesia yang baku. Contohnya, istilah polymorphism, ada yang menerjemahkan menjadi polimorfisme. Namun, apakah polimorfisme merupakan bahasa Indonesia yang baku ? Contoh lain, salah satu prinsip dalam Object Oriented Design (desain berorientasi obyek ?) adalah prinsip Open-Closed. Kalau diterjemahkan bebas, mungkin menjadi prinsip Terbuka - Tertutup. Namun saya merasa kurang pas dengan istilah tersebut. Contoh lain lagi, salah satu Design Pattern (pola desain ?) ada yang bernama Abstract Factory pattern, jika diterjemahkan kata per kata menjadi pola Pabrik Abstrak, yang terasa janggal untuk digunakan.

Berbicara soal bahasa, sekarang sedang ramai dibicarakan rancangan UU Bahasa yang menurut kabar yang saya baca, memuat pasal tentang pelarangan penggunaan bahasa asing di tempat umum. Apakah benar begitu, saya belum tahu, soalnya saya belum membaca sendiri RUU tersebut. Mungkin pembaca blog ini ada yang dapat memberi konfirmasi ?

As a software developer, when I hear the word ‘legacy code’, what comes to mind is code from the past, with functions containing hundreds line of unstructured code which is very hard to understand. If there’s documentation, it usually makes us more confused because it’s never been updated since the first version of the code. In my opinion, understanding and maintaining legacy code is one of the most difficult tasks for software developers.

Although working with legacy code is difficult, it is something we can hardly avoid, because many working systems that we should maintain and enhance, are written as legacy code. Rewriting such systems may be not an option for most organizations we are working at. Clearly, we need some strategies and techniques that will help us conquer the complexity in legacy code. Unfortunately, there are not many books which talk about legacy code, compared to the number of books about designing and programming from the scratch.

When I browse around, I found a very good article from Michael Feathers, Object Mentor, which contained several strategies to work effectively with legacy code. You can find the article in Object Mentor website. From that article, I learn an interesting point that what distinguishes legacy code from non-legacy code is tests. If we write new code without adequate tests, actually we write legacy code. It’s a bit extreme actually, but if you are extreme programming follower, that idea should be familiar. That article then present techniques to add tests to legacy code, which is called test coverings. After that, the authour shows some strategies to make ’safe changes’ to legacy code by breaking some dependencies and add test for each change we make.

Hello world !

Actually this first post is automatically generated by blogsome, but I want to add some information about my self.
My name is Rulli, I work as a software developer. Before, I used to write in blogspot, so you may want to check it out to know a little more about me. I have abandoned that blog for several months, and I will start my new blog here.

I hope this blog will be useful as a medium of knowledge sharing between us.