Debugging Hardware Problem

Today, I boot the PC. The boot process goes smoothly until the windows trying to load. Suddenly a blue screen appear and the computer restarted.

If you ever have a pc for 3 years or more, you may experience similar situation as well. PC unable to boot, sudden restart in middle of work, or something like that may happen due to hardware failure.

An experienced one already know that hardware problem can be happened in many parts of hardware, such as CPU, RAM, hard disk, VGA, motherboard, power supply, etc. Similar with software debugging, finding a part of hardware which is the root cause can be a trouble. I find the debugging hardware problem is similar with one in software.

During the booting after my PC restarted, I try to run the windows in safe mode. Strangely, it can run well. Some common applications such as office and browser can be run normally, with the minus of good display and network support due to safe mode.

Normally, you cannot even able to boot at all when the CPU or RAM get any trouble. From this point, I believe that the RAM and CPU is still in good shape, eliminating two error possibilities. Troubled power supply normally cannot affort to boot the system too and not causing blue screen error. So, we get another parts eliminated, leaving both motherboard and VGA alone.

Both parts become the "possible root cause" which cause the error. From this forward, I begin to test the "possible root cause" to be proven. This step is meant to prove whether the possibility is actually the real root cause.

Luckily, my possibility is being strengthened by windows error message in safe mode, showing bcc code 116. After simple searching in Google (thanks Google), I can easily found some article mentioning bcc code 116 related to video graphic error. Now only one thing to prove: whether the system will boot up without using the graphic card.

So I start to reach device manager, disabled the display adapter, and begin restarting the PC. The result is, viola! The system successfully loaded. The application runs well, the browser connected to the internet, and nothing has problem except a poor - low resolution display. And a little lag because the rendering are not being done in graphic card anymore.

The suspect left to motherboard or VGA, which I haven't found the cause yet. That is because I do not has spare change for it. But the bigger suspect is VGA, because it is older than the motherboard.

Conclusion

Finding the cause of hardware error is very similar with debugging software. It is started by finding the possible root cause, proving the possibility, and then fixing the problem. Experience and knowledge also help in both cases, to speeding the discovery of possible root causes. And for both cases also, you need to know how the system behave / working, or you will need additional time to find how the system work.

Not All Architecture is Fit for Your Apps

I had an interesting discussion over stackoverflow with L-Three in this question. I realized that it is quite an interesting situation there, so I think it need to be blogged. I'm not yet experienced enough in Dependency Injection, so my statements may be mistaken though.

In short, he is advising to use a well structured architecture. That architecture is using some several good techniques, like dependency injection and comand-query separation. Ad a moderate programmer, I can say that the structure is good, clean, easy enough to test and extendable. But I don't like it. No, not because the design is good, but I have some conditions where the architecture can't be applied.

Interface Programming: Entity Wrapper to Handle Dynamic Source Object

Background

During working with legacy code, I have found that many people used DataTable/DataSet instead of strongly typed objects. They are using some code like

string id = row["id"].ToString();

instead of

string id = request.Id;

It is becoming a maintenance hell because of several reasons:

• I do not know the data type from database, so I need to debug into database procedure
• I do not know whether the data is nullable or not, again I need to debug into database
• When I need to change the data type, I need to search for every implementation, change it and make sure it does not break 

And last but not least, if I want to make enhancements or modifications, I have been faced with 2 options:

• Keep  the same programming style, using the DataTable, with the risk that you add another more maintenance hell object
• Refactor it, with the risk of breaking is higher

I want to use Dependency Injection (DI) for my further development. Lack of strongly typed entities are of course prevent me from using DI. So I need to change the DataTable to strongly typed object before using the DI implementation.

Design, don't Code Yet

 Why - Risk at Development

As a programmer, sometimes I doubt whether I should wasting time to think and design about the application that I will develop or not. As a single programmer-architect, there are some self-defined projects where I usually start by code first or by design first. Logically, they should have produced the same result, thinking that the developer and the architect is the same person. Practically, I'm surprised that the project started with code first is tend to have more risk and more likely to be stopped than the one by design-first.

So, logic does not apply here? Yes it is. The reason is basically that the developer is human. and they will likely get bored because of several reasons:

• The project does not has exact requirement and scope
• The project does not has exact release strategy
• The project is most likely isn't needed by the user

The project does not has exact requirement and scope

Once, I have tried to create a so-called "ideal-best" application. The application should be able to handle many kind of business process. That application will be free of bug, easily extendable and has good architecture foundation. And the application can work as both transaction handling or event high level management reporting tools.

It sounds like a good plan at the beginning, however with such a big regards I need to drop the development because I got bored during developing it. It has no exact scope, no exact plan about what I must develop, what I must validate, how is the process after doing this and that, etc. The scope is growing and growing each day I think about the application, and the development cannot follow the planning growth. You have not target to accomplish, and caused you to loss interest in the development.

The project does not has exact release strategy

 What I mean about the term of release strategy here is a strategy about how to deliver the application. It consist of release date, the audience and the platform target. It may has more details than that such as how to replace the current running application without breaking, or how to not breaking other applications which is dependent to it; but it's regarding what kind of application that want to be delivered.

Having no release date deadline (target) can affect the development scope, since you will think like "I have unlimited time to develop this" or "I can add this and that feature before delivering the application, since the release date isn't being decided". 

Lack of audience target can also affect the scope, because you will try to create an application that can be used by any level of management (transaction level or event advanced-level ad-hoc reporting).

Lack of platform target can demoralize your development. You will be haunted by thoughts such as "will it works well in firefox, chrome, or IE?" or "will it works in other-windows operating system?". Thoughts like that will drag your development, because you will be bugged by how you will check them each time you make a modification. Don't be bugged by it!

The project is most likely isn't needed by the user

Any project needed by the user should has estimated release date. In terms of user, the faster the deliver date, the better. Sometimes you may think that this kind of application/enhancement will not be needed by the user. It can be because you can do manipulation to the database directly. This kind of thought can demoralize the development, since you don't know exactly how your application can give good benefits to the user. Don't develop any kind of application which won't be needed. Or if it will, don't ever think that the workaround (direct manipulation) can be the replacement of the application.

Conclusion

Always design your application first before do code. No matter how skillful programmer you are, the risk of not having the application designed beforehand is high. It can makes your effort go waste, and you got nothing from it, except wondering why this is happening. If you cannot do the design, as someone who is good at it. Asking experts in each field, for example accountant during finance application design or a headmaster during education application design. It can give you clear vision about what kind of application you want to develop, and the functionality.

Separation of Model in Design Pattern

Before talking about model, you can read about what is the "model" thing in MVC design pattern explanation. The simple explanation about model (my interpretation, don't use it in exams) is something which represent the structure of data, and possess the logic to get and/or modify the data.

Usually, model's logic can be integrated with the controller (or view model), and the structure itself can be represented using data sets (for database, or xml documents for xml). So in most cases, developers really can ignore model and integrated it with the controller itself. So why is it needed to separate the model?

If we said about small application, it will be okay to ignore model, and integrate it with the controller at all. But what if we talk about large applications? It will be hell if we use data sets or xml documents itself. A slight change with the data structure, and you must search for every controller which used that data. Yeah I already said every controller, and if the application has so many controller, it will be a pain.

Not only that, in additional model can hold some logic that bound to data, so every controller used the data can have same behavior of the logic. Let's say that a request has some mechanics like discounts or so. Instead of put the logic in controller or database, we can put it in model. So in summary, I will say that the model is quite a handy tool for data management.

The Popular MVC Design Pattern

If you need reason(s) why the desin pattern are needed in software programming, you can read mw previous post.

Honestly, at the first time I learnt this design pattern, I find it was a bit confusing. Moreover, I find it useless to separate model with the controller, even I can immediaetly find the importance to separate the view an controller. However after try to create a php project using codeigniter framework, I find the requirement are somewhat important.

Before talking further about MVC, let me tell you the basis of MVC. The view, to be simple are the user interface. It is related to everything what user sees, what user input, what user choose and logics of the UI to communicate with controller (in this case, form tag and ajax call are considered a view.

Controller on the contrary, receiving input from view, processing it with logics (if else, loop, mathematical logics, etc), getting the data from model, sending the data to model, and even choose what view will be displayed after all the process done.

Model is the object that you use in controller. Model which data will be displayed in view, which hold the logic to modify the data in storage (can be database, xml, pure text files, encoded file, etc), getting the data from storage, and hold the structure of data.

From that explanation, we can see that it is obvious to separate view with controller, in order to separate business logic with UI logic. But why is it needed for model to be separated with the controller, instead just handle the model (get and modify the data) in controller? We can get the explanation in this post.

Design Pattern, How Important is it

Design pattern is usually be used in software application programming. There are some design pattern which is used widely by enterprise, or insividual programmer. But how important is this design pattern 'thing'?

The main purpose of design pattern is to separate the application interface (UI) with the business logic. Why is it needed to do such thing?

In my latest job, there was a project which need to be handed over to me. The project are using Asp.Net webform. The structure of the project are using event-driven structure, as the basis of Asp.Net webform design.

The business logic (lets say that as the logic to submit a request, validate the form or updating the request) are being done in code behind of aspx.cs form. To be worse, the business logic sometimes handled in asmx webservice and being triggered by jquery ajax, making it harder for me to decrypt it.

Well, the pain did not stop there. The design are making it harder to be modified. A little modification can cause errors in other places, and more effort are needed to unify the change in other places as well. This is, are contrary with principal of object oriented, which is encapsulation and reuseability.

So how can a design pattern be used to solve these usually founded problems? I will try to describe it in my future posts.