Archive for October, 2010

[tweetmeme  source=”aabdulmoniem” only_single=false]

I have just finished “Beginning Silverlight 4 in C#” book written by Robert Lair from Apress and I would like to share my humble opinion about it.

Really and simply, it is a great book to grasp many concepts about Silverlight 4 in a just 400 papers. For me, I have finished the book in four days (3-5 hours / day) and of course there are some reasons for that, a couple of them are:

  1. I am not so beginner in this technology as I have used WPF before so I didn’t need any time to grasp multiple concepts quickly.
  2. I need to finish this book as quickly as possible to wrap most of the features and abilities of the new version of Silverlight. In fact my team is going to develop a business application using Silverlight and I was in real need to see the full picture of this technology.

Enough talking about myself, let’s talk about the book.

This book talks about:

  • Why we need Silverlight and how it fits in the RIAs? Really a good and brief introduction gives the reader why he is gonna read about such a new technology.
  • VS 2010 new features and how it supports Silverlight 4 and what you need to get started. BTW, there are some posts here in my blog about the new features of VS 2010 you can find it in “Cutting Edge” column.
  • Layout management in Silverlight. It mentioned some of layout controls and how you can use it to layout your applications like the Grid, WrapPanel, DockPanel, Canvas, and StackPanel.
  • Some of Silverlight controls and some basic examples about them like TextBox, Button, TextBlock … etc.
  • List controls like DataGrid and ListBox besides data binding mechanisms which is so so powerful in the world of XAML.
  • Silverlight toolkit, and what it contains.
  • How you can get access to data in Silverlight (WCF is recommended approach), how you can use Sockets for data access and network communications.
  • Navigation framework which is so similar to master pages and content place holders in ASP.NET. Also, how you can pass data between different pages, how you can map the URIs, and How you can route the URIs to custom ones.
  • Isolated storage and how you can use it for caching purposes, saving and retrieving files … etc.
  • Accessing computer devices like web cam and microphone from a Silverlight application easily.
  • Expression blend introduction and how it fits in the world of Silverlight.
  • How you can style your application in a very similar way to CSS in HTML pages.
  • How to animate objects easily and how to use Expression Blend for this purpose with some basic and nice examples.
  • How to create custom controls, although the book didn’t mention how to create user controls. It gives a very good example for building a custom control from scratch.
  • How Printing is so easy in Silverlight. You can print the screen as it is, or you can even customize the printable data to select portions of screen or even a whole new shape.
  • Finally, it talks briefly about important concepts and ideas you will need when you need to deploy a Silverlight application. It gives an idea about assembly cashing, out-of-browser mode, and elevated trust.

Really, I am recommending this book to any one who needs really to know what is the Silverlight about and what can do.

Thank you Apress for not wasting my time 🙂


    Read Full Post »

    [tweetmeme  source=”aabdulmoniem” only_single=false]

    Today, our product owner has sent me a document which contains some bugs as he said. I have opened the document to see what are the problems with our system, but I have found that most of the notes which were named bugs simply not bugs but they are new features.

    I have decided to hold a meeting with him afternoon to discuss him about those notes. I told him: “These are not bugs, they are new features.”. He said sadly: “No, No … They are bugs. I didn’t expect all these notes. Why this feature is like this? and why the other feature is not working as my expectations … etc.”

    The problem I am facing here is just we are not meeting his expectations, and the cause is very obvious, he didn’t write his expectations about each feature. In other words, he didn’t write acceptance criteria for each user story (Scrum is our process).

    Rule of thumb:

    Always, ask your stakeholders about their acceptance criteria before going to code.

    Let’s take an example from Software Estimation book by Steve McConnell to see what I am talking about here:

    Suppose you’re developing an order-entry system and you haven’t yet pinned down the requirements for entering telephone numbers. If I didn’t ask the product owner about what he is expecting while entering telephone numbers, I may implement it in another way which will not meet his expectation. Some questions may be:

    • When telephone numbers are entered, will the customer want a Telephone Number Checker to check whether the numbers are valid?
    • If the customer wants the Telephone Number Checker, will the customer want the cheap or expensive version of the Telephone Number Checker? (There are typically 2-hour, 2-day, and 2-week versions of any particular feature—for example, U.S.-only versus international phone numbers.)
    • If you implement the cheap version of the Telephone Number Checker, will the customer later want the expensive version after all?
    • Can you use an off-the-shelf Telephone Number Checker, or are there design constraints that require you to develop your own?
    • How will the Telephone Number Checker be designed? (Typically there is at least a factor of 10 difference in design complexity among different designs for the same feature.)
    • How long will it take to code the Telephone Number Checker? (There can be a factor of 10 difference—or more—in the time that different developers need to code the same feature.)
    • Do the Telephone Number Checker and the Address Checker interact? How long will it take to integrate the Telephone Number Checker and the Address Checker?
    • What will the quality level of the Telephone Number Checker be? (Depending on the care taken during implementation, there can be a factor of 10 difference in the number of defects contained in the original implementation.)
    • How long will it take to debug and correct mistakes made in the implementation of the Telephone Number Checker? (Individual performance among different programmers with the same level of experience varies by at least a factor of 10 in debugging and correcting the same problems.)

    As we can see, some questions like this will give us more explanations about what he wants? and the first dialogue will not happen again if we meet what he looks for.

    A really good lesson you have to learn and to teach.

    Read Full Post »

    %d bloggers like this: