Showing posts with label Software Engineering. Show all posts
Showing posts with label Software Engineering. Show all posts

Wednesday, April 08, 2009

Disaster Recovery - If you fail to plan, plan to fail


The CuttingEdge Club will organize a two hours session about "Disaster Recovery". The session will be in Wednesday 8th April, 2009 - 5:30 PM, ITWorx - Free Zone. The speaker is Nahla Osman, Quality Team Leader, ITWorx.

CuttingEdgeClub is an ITWorx technical seminar club for technology enthusiasts. Its mission is to provide an easy gateway to pertinent and updated technology information for a growing audience in a simple, pragmatic and accessible way.


Saturday, March 01, 2008

Inversion of Control & Dependency Injection

In the last Thursday, 28th Feb. 2008, we had our internal demoday in SK. The day was really informative. We had many interesting topics in different fields. My topic was an introduction about the inversion of control and the dependency injection. You can download it from here:

Download: Internal_Demoday_28_2_08_IoC_DI.pptx

N.B: Most of the examples in the presentation use Sprint.NET as a DI framework.

If you want to go deeper in the topic, I recommend the following article: Inversion of Control Containers and the Dependency Injection pattern. The author is Martin Fowler - Chief Scientist, ThoughtWorks - and the article is considered to be the ideal reference for the topic.


Friday, September 29, 2006

Optimization Or Compatability ... Hard Choice!

I was reading an interview held with Shannon Hickey, the technical lead for the Swing toolkit team at Sun Microsystems. He was asked about his dream project which he would like to make one day. The answer was so impressive:

" ... As an engineer, I'd love to be able to clean up old and unused parts of the Swing toolkit and the Java programming language without having to worry about backward compatibility. It's just a dream though, because compatibility is very important to our customers and is something we take seriously. For instance, every time I fix a bug, even if I'm correcting completely wrong behavior, I must be careful not to break something for someone who is relying on that wrong behavior.

For example, I modified JTable a while back to ensure that the focused row was set to the first row whenever the table gained its first data and was then set back to -1 when the table became empty. The goal was to ensure that tables showed focus whenever possible but to correctly use -1 if they are empty. This solved numerous open bugs.

Unfortunately, within a couple of weeks, two bugs were filed against my change. It turned out that modifying the focused row fired events, and some existing client code wasn't prepared to deal with these events. Although I strongly want code to "do the right thing," I understood that we must try not to break existing code. Unfortunately, I had to pull this perfectly good code in favor of something less optimal. Now, the focused row always stays at -1, until either the developer or the user changes the selection. The funny thing is, I've seen bugs filed on this behavior since ..."

You see. It is really hard to take care of all this issues when you developing technologies others will widely use.

I like this Article - Digg it