Archive for April, 2008

Sony Ericsson K800i Sudden Death

Monday, April 28th, 2008

I wonder how many people have gone through the same experience as I had. Last month, I was still using my Sony Ericsson K800i which I had bought 2 years ago. It is a decent mobile phone with leading camera feature when it was launched and as IT geek I am satisfied with all the features of the phone. I have stored crucial data in my phone including important contact numbers, and suddenly I could not turn on the phone after I change the SIM card.

I was on my trip in Singapore and I used local SIM card, since my Australian SIM card does not work there. Just before I board the plane to go back to Melbourne I replace the SIM card quickly. I turned off the phone, took out the battery, took out the SIM and put my Australian SIM card. Voila, I could not turn on the phone anymore although I have just charged the battery to its full capacity. When I tried, it just showed blinking red light near the infrared port of the phone.

As IT geek and ex-mobile phone expert (I used to flash and modify the software of my mobile phone), I didn’t give up. I tried to look through the internet for a solution. I found out many people get the same situations, and some of them successfully revive the phone by rewriting the EROM (equivalent of BIOS in PC). No luck, I could not recover my K800i. Next thing, I tried to bring it to customer service centre, but again they refused my phone because it was purchased outside Australia (They are not allowed to put Australian software/flash into my phone).

Well, this is an expensive experience. I have learnt two things. Firstly, always backup your mobile phone regularly. There is lots of hand phone backup software out there or if you used smart phone you can just connect it to your PC and copy your organizer data to your Outlook. Secondly, do not cut out the power abruptly when turning off your Sony Ericsson mobile phone. It looks like Sony Ericsson mobile phone writes some data into the EROM when turning on and off and if we cut out the power the EROM will be corrupt. When you break your EROM, your phone won’t be recognized by your PC, you cannot charge the battery, and etc. It just death.

CSS: Gap between two DIV elements

Monday, April 21st, 2008

When I wrote stylesheet for my website (www.ferolen.com) couple weeks ago, I encountered some errors. One of the CSS problems is a gap that mysteriously appears between DIV elements. Most of the time we would like to has two div elements to stick together smoothly especially if we use it to contain background image. You have set the padding and margin to 0, but it does not help. However, if you apply border around the DIV, magically the gap disappear. These symptoms usually occur when you have element with margin inside the DIV. How could we get rid of the gap but without the border? The answer is by applying 1px padding to the DIV element or set the margin of the child element of the DIV to 0.

For Example, the following case could be solved by adding “padding:1px” to #div2 or set the margin of “p” in div2 to 0;

.css: gap between DIVs css gap source code

XP Vs Scrum

Tuesday, April 15th, 2008

Two of the most well known agile methodologies are XP (extreme programming) and scrum. Both of these practices have similarities and differences. As agile software development techniques, they have same characteristics which are relatively short development time and consist of several iterations. In this blog, the explanation of both practices will be discussed as well as the strengths and weaknesses of each method.

XP which is also known as extreme programming is an agile software development approach which consists of several practices and values. Many articles stressed the values of communication, simplicity, feedback, and courage in XP. Communication value is where team member uses verbal communication to other team member over formal written document. The team members in XP project includes developers and customer representatives who should understand the domain and know what is needed. XP also emphasize simple design and solution to fulfill customer requirements. In development process, feedback from customer, system testing, and other team members are important. XP also encourage the developers to write code only for current requirements in pair and do code refactoring if needed in the future.

People often think that scrum is same with XP. Scrum is a subset of agile software development techniques. It is an iterative process to develop or manage certain project and it will produce shippable product which can be presented to the customer at the end of iteration. Unlike XP, scrum emphasizes the management side of a project and does not define a detail engineering practice. Iteration in scrum is called sprint which will deal with certain features defined by customer in a backlog. After the team chooses the most risky feature in backlog they will develop it. A sprint usually takes thirty days and can be decreased to one week if the system is simple and easy to develop. During a sprint, team will have a meeting each day to discuss what has been done, what the obstacles are, and what will be done.

XP specify the software engineering practices such as test-driven development, refactoring, pair programming, simple design, etc. On the other hand, scrum focuses on the management side which quite general so that it can be implemented on other project beyond software development project. For example, scrum does not specify pair programming or test driven development, but it specify how we manage the requirements or requested features. Scrum can be seen as a wrapper for existing engineering practices. Scrum requires self organizing team which cannot be disturbed by requirement changes once they started the sprint. If the customer wants to change the feature, they have to wait until the iteration finished and then introduce the change. In contrast, extreme programming is more acceptable to change during iteration which usually only last for two weeks.

XP and scrum has subtle different. They emphasize on different side of a software development project. It will be great if we can combine both of them to manage our agile software project.

Is pair programming painful?

Tuesday, April 15th, 2008

Pair programming has become popular word among software developers recently. As the name suggests, pair programming is a software development activity (writing code) which is done by two programmers. There will be only one of them writes the code and the other programmer thinks whether the code written satisfy their goals. The idea is similar with rallying where in one car there are two people. They are the driver and co-driver. The driver will drive the car and the co-driver will guide the driver to drive accurately.

Pair programming is a programming technique adopted by extreme programming or any agile software development methodologies. Some people argue that this method is a good practice. On the other hand, there are many people say that it is sorrowful. In this blog, the benefits and drawbacks of pair programming will be analyzed, to understand whether pair programming is painful or not.

Some benefits of pair programming are efficiency and increase in performance. In term of efficiency, we can cut the number of workstations as well as software licenses since we need only one workstation every two developers. However, the main advantage that people looking for in this programming approach is an improvement in developer performance. This includes an increase on the number of line of codes and reduced number of bugs or defects in the written code. This can be achieved, because one of the programmers can concentrate to write the code and another one analyzes the code which is written on the screen. If there is something wrong with the code, there is a big chance that it will be spotted during the development phase.

Although pair programming promises wonderful benefits for developers, it has some drawbacks. I believe most people will feel awkward, if they are watched by someone else when they are working. That is why we can find cubicles in many working places. Some people find that it is hard to work under tight supervision. The other problem is every human has their own style and way of thinking. This is also applied in coding style and logical flow within our source code. In my opinion, it is difficult to understand other programmer’s code or adopt their styles, especially if there is a big different in the experience and programming skills.

All of the drawbacks of pair programming are most likely caused by unmatched programmer being paired. I believe this can be solved if both programmer can get a long together and have the same level of programming skills. It will be better if both programmers come from the same programming language background since there is a big probability they will have same programming styles. It is not an easy task to pair up developers in a project.

Is pair programming painful? This issue is debatable since there are advantages and disadvantages. However personally, I would say that pair programming is not painful. There are some precautions that we can do to minimize or eliminate the pains in this programming approach.

Limitations of user stories

Tuesday, April 15th, 2008

User story is one of the ways to communicate software requirements from user to the developers. User story is used for requirement gathering in agile software development project such as extreme programming. In general user story is a short goal oriented story on how a user will perform certain tasks with the system. Commonly, a user story contains the context of certain task, condition which triggers this user story, and script which illustrate how user do the tasks on step by step basis. User story should be flexible and free from any decision making such as user interface design choice. This user story will act as an agreement between the user and developers on the software being developed.

User story is a simple way to express the behavior or characteristics that user needs. It hides all of the complexity and focus on how a certain task can be performed. User story looks fit into agile software development practices. That is why it is used to specify requirements in extreme programming. However, user story is not a perfect tool. It has some limitations. This blog will discuss what the limitations are and show any solution to minimize the constraints.

One of the main limitations of user story is that it opens for many interpretations. User story is simple and contains scripts which focused on a functional goal. It does not state the detail of the user interaction with the system. Our customer may have different understanding with the team. As a result, it is hard to use user story to act as an agreement between the user and developers. That is why it is suggested that the customer or end user is part of the team, so that we can communicate and clear any doubts through face to face communication.

For example, if we have user story on a manager who want to send out a survey to his staff. The first story or first action in the script will be the manager would select the option to survey staff. One developer might implement this user story with a button to choose the survey staff, and other developers might use drop down list. As we can see that user story is straightforward, plain and free from any design (decision making). It will focus on capturing user requirements and try to be free from any user interface design, so that it can be implemented in many ways. We can solve this problem by discussing the design with other developers and sketching user interface design before we implement a user story.

The simplicity of a user story also causes another limitation. It lost the performance requirement detail. Often, user story which becomes the basis of user acceptance test will only test the business logic of our application. It will not test the performance or our database layer such as database response time. To overcome this limitation, developers or testers need to pay attention to other documents such as product attributes and system constraints when building the test case. Therefore, developers and users have to develop these documents carefully as it will accompany the user stories.