This time, my post has nothing to do with .NET but rather with an issue that seems to be common, according to my search on the net and I thought that my findings may help people who experience the same issue.
Yesterday morning, I started to have serious issues with my cell phone, a HTC Touch.
Here is the list of issues (that came all together on the same day):
When starting up, it was taking way too long compared to usually (the Windows Mobile 6.1 screen was taking ages before to display the home screen).
The touch screen as it was no longer responding to my orders! For a cell phone that does not have a keyboard, that is rather a serious issue.
My cell phone was no longer recognized by my computer and the 'cube' interface was no longer working.
When I tried to access the contacts, the screen was empty and whenever I typed a name it kept displaying "Matching..." and it never comes back with suggestions.
Here are the things I have done and it looks like it is working today... Hope for a long term.
1 - Removed the screen protector: In fact, when I bought it, I put a plastic screen protector. It started to be dirty anyway. As a result, the touch screen was responding intermittently only. All other issues were still there (and I did not expect the cell phone to start up faster just by removing the protector :)).
2 - I did a hard reset of the phone following the instructions on the site http://www.flickr.com/photos/ryjones/2193904710/
Well, I lost all my contacts eventually and everything else in my cell phone (notes, documents, photos etc...). I did not really have the choice cause the cell phone could not synchronize anyway and was unusable.
Once the hard reset done, it looks like the cell phone is back again and everything is working perfectly now. I just cross my fingers!
Hope that helps!
Friday, October 2, 2009
Wednesday, April 29, 2009
Do we need an architect in SCRUM?
Few months ago, I went through the SCRUM certification process and during the training, I have asked the question 'Do we need an architect or technical lead in a SCRUM team?'. The answer was that from a pure SCRUM definition perspective, we should not.
SCRUM puts a lot of emphasis on team collaboration and it suggests that all decisions must emerge from the team as a whole and not from one particular person. Most of design decisions can be taken with this approach however, not all.
Software design is not a deterministic activity; i.e. same problem can be solved by many different approaches and here comes the problem: In Agile, we do not a design phase prior to start the devleopment activities. We design as we progress and sometimes we look back and do some refactoring (very brief definition of the design in an Agile process). That is, the way we are going to implement different use cases is not defined in details and chances are that a developer will implement a functionality using an approach that differs from the overall design of the application. For instance, I have encountered developers who use extensively Design Patterns. I have nothing against DPs but if only the features implemented by one developer are coded using heavily design patterns then we will end up with a code that is a bit messy in the sense that it does not solve problems in the same way consistently.
For me, the philosophy behind a solution design is as important as the design itself. At the begining of a project, we choose an approach or philosophy (for instance, we decide not to use web services for certain reasons. We decide to use data classes - we decide to decouple some projects from the infrastructure....) and the whole team must stick with it. The issue is that when a developer, and especially those added in the middle of the project, does not agree and does not respect our coding rules, we end up with some philosophical discussions that are often endless. It is here where do need someone who have the power to stop the discussion in order to move forward.
What I am trying to say here is that the technical leader or the architect does not have the power to take a decision against all the team members, but to make some developers follow the line and get them on track without wasting hours of useless meetings. The team still takes most of design decisions anyway.
The architect can bring his point and try to convince the team to adopt it. If she is very diplomatic and collaborative, she will succeed. Trying to impose a decision will just kill the confidence of team members in the collaboration process which will probably even make your SCRUM implementation a failure.
As a conclusion, I strongly believe that SCRUM is an excellent process however, I believe that a software architect is still required even in Agile processes. She will not produce any thick documentation but guide developers and ensure that the team is on the right track all along the project lifetime.
SCRUM puts a lot of emphasis on team collaboration and it suggests that all decisions must emerge from the team as a whole and not from one particular person. Most of design decisions can be taken with this approach however, not all.
Software design is not a deterministic activity; i.e. same problem can be solved by many different approaches and here comes the problem: In Agile, we do not a design phase prior to start the devleopment activities. We design as we progress and sometimes we look back and do some refactoring (very brief definition of the design in an Agile process). That is, the way we are going to implement different use cases is not defined in details and chances are that a developer will implement a functionality using an approach that differs from the overall design of the application. For instance, I have encountered developers who use extensively Design Patterns. I have nothing against DPs but if only the features implemented by one developer are coded using heavily design patterns then we will end up with a code that is a bit messy in the sense that it does not solve problems in the same way consistently.
For me, the philosophy behind a solution design is as important as the design itself. At the begining of a project, we choose an approach or philosophy (for instance, we decide not to use web services for certain reasons. We decide to use data classes - we decide to decouple some projects from the infrastructure....) and the whole team must stick with it. The issue is that when a developer, and especially those added in the middle of the project, does not agree and does not respect our coding rules, we end up with some philosophical discussions that are often endless. It is here where do need someone who have the power to stop the discussion in order to move forward.
What I am trying to say here is that the technical leader or the architect does not have the power to take a decision against all the team members, but to make some developers follow the line and get them on track without wasting hours of useless meetings. The team still takes most of design decisions anyway.
The architect can bring his point and try to convince the team to adopt it. If she is very diplomatic and collaborative, she will succeed. Trying to impose a decision will just kill the confidence of team members in the collaboration process which will probably even make your SCRUM implementation a failure.
As a conclusion, I strongly believe that SCRUM is an excellent process however, I believe that a software architect is still required even in Agile processes. She will not produce any thick documentation but guide developers and ensure that the team is on the right track all along the project lifetime.
Sunday, August 3, 2008
Agile Design Artifacts
I recently got contracted by a company to be the technical lead for a web application development project. My first task was to come up with an architecture document for the application within 2 to 3 weeks. I rapidly realized that it was not realistic. I could eventually design the application, but I was convinced that it would not be efficient for the following reasons:
- I was promised to get the full requirements a week after I started. I did not get them and still now, after 3 months, there are still on going,
The web application was intended to connect to a back end bought from a third party provider. We did not know much about the API (actually, the API were planned to change – and still changing today after 3 months)
I always have been convinced that a too detailed architecture will be obsolete as soon as developers start to implement the functionality.
For these reasons, I told the team manager that I prefer not to spend my time drawing class diagrams or any sort of artifact that will be thrown away or, at best, be expensively kept up to date during the development process. What I suggested though was to:
Draw a high level design diagram; this diagram included all the providers and layers of the application.
Write few class stubs to give a direction to developers. The classes did not contain any implementation. They rather contained many “TODOs” with comments for developers; we also agreed with developers that the comments were there as a suggestion. They were allowed to go in another direction as long as they respect the overall design idea.
We focuse on only one type of artifact: the code itself. Well written code is the best artifact as it expresses the static view but also the dynamic view of the system (which is, from my point of view), the most important view to understand a system especially to support it.
We scheduled and took the necessary time to do few meetings with all developers to explain the design guidelines; this is far better than writing thick documents as developers came up with very interesting questions and suggestions from their past experiences. Once we agreed on the design, we started the development of what we called “the infrastructure” or the framework that will support the application.
During this phase, we decided to use SCRUM methodology; this was new to my client (they applied it partly in the past). I insisted on the fact that an iterative development process will help us to get things done and deliver high quality software.
We called this first phase the SPRINT 0; we did a lot of refactoring as the code was written and the application was growing in size. We decided that no interface (user interface) will be developed during this sprint; we wanted to focus only on the framework and the design.
Now, we are in the sprint 3. We delivered some functionality to the business and we had very positive comments so far. Even managers who first were skeptical regarding SCRUM methodology are now much more comfortable and confident that an iterative process can effectively help to deliver in time and with a high quality.
Monday, May 12, 2008
Visual Studio 2008 and .NET 3.5 SP1 Content
The link below is an article that details the new features and improvments of the Visual Studio 2008 and .NET 3.5 Service Pack 1.
Among other this service pack contains the following new features:
- ASP.NET Dynamic Data (ASP.NET Data Scaffolding)
- ASP.NET Web Routing Engine
- Support for SQL Server 2008
- ADO.NET Entity Framework and Linq to entities
Final release is planned for this summer and will be released as a free update according to this article.
Among other this service pack contains the following new features:
- ASP.NET Dynamic Data (ASP.NET Data Scaffolding)
- ASP.NET Web Routing Engine
- Support for SQL Server 2008
- ADO.NET Entity Framework and Linq to entities
Final release is planned for this summer and will be released as a free update according to this article.
Wednesday, March 26, 2008
Display .CHM Files content
If you download a Windows help file (.chm) and it does not display the content (all pages are empty), chances are that your file is simply blocked by Windows.
To solve this issue, simply right click on the file and click on the 'Unblock' button.
C# 3.0 Extension Methods
One of the new features in .NET 3.5 and C# 3.0 is extension methods. Extension methods, as their names state, let you extend any existing type by adding new methods without having to inherit from it.
For instance, one of the common issues we encounter when retrieving data from the database, is to check whether the value is DBNULL or not before we can use it. I used to write a DbReaderHelper class that actually implements ‘dbnull safe’ data retrieval methods. The syntax to declare an extension method is very simple. It is a static method which its first argument starts with the keyword “this” followed by the type we want to extend.
For instance, if I want to add a new method called “nGetInt32” which returns an Int32.MinValue if the field is dbnull otherwise the field value (an Int32), I should write it as follows:
public static Int32 nGetInt32(this DbDataReader reader, int index)
{
if (reader.IsDBNull(index))
return Int32.MinValue;
return reader.GetInt32(index);
}
How to use it?
The extension must be part of a static class (see the example at the end of this post). To use it, simply add the namespace the class belongs to as part of the “using” directives and that’s it. Even intellisense will take it into account;
If we want to extend the DataReader class to make it dbnull safe, we would have to inherit from one of its implementations and therefore would not be able to extend all inherited classes. The other advantage is the fact that you can extend any class (even those marked as “sealed”. On the other hand, extending a class has a limitation which is that the extension method can only use public methods and therefore there’s no access to the inner state of the object.
Methods resolution
- Instance methods have priority
- If the same extension method is declared more than once, the compiler raises an error.
- The compiler looks into the current namespace and all the namespaces included with the using directive.
For instance, one of the common issues we encounter when retrieving data from the database, is to check whether the value is DBNULL or not before we can use it. I used to write a DbReaderHelper class that actually implements ‘dbnull safe’ data retrieval methods. The syntax to declare an extension method is very simple. It is a static method which its first argument starts with the keyword “this” followed by the type we want to extend.
For instance, if I want to add a new method called “nGetInt32” which returns an Int32.MinValue if the field is dbnull otherwise the field value (an Int32), I should write it as follows:
public static Int32 nGetInt32(this DbDataReader reader, int index)
{
if (reader.IsDBNull(index))
return Int32.MinValue;
return reader.GetInt32(index);
}
How to use it?
The extension must be part of a static class (see the example at the end of this post). To use it, simply add the namespace the class belongs to as part of the “using” directives and that’s it. Even intellisense will take it into account;
Why using extension methods
If we want to extend the DataReader class to make it dbnull safe, we would have to inherit from one of its implementations and therefore would not be able to extend all inherited classes. The other advantage is the fact that you can extend any class (even those marked as “sealed”. On the other hand, extending a class has a limitation which is that the extension method can only use public methods and therefore there’s no access to the inner state of the object.
Methods resolution
- Instance methods have priority
- If the same extension method is declared more than once, the compiler raises an error.
- The compiler looks into the current namespace and all the namespaces included with the using directive.
C# 3.0 Anonymous types
With C# 3.0 you can declare a variable without typing it explicitly and its type will be inferred based on the right expression. This is different from the non typing in VB like languages (ASP, VB) as the resulting value is really typed and can no longer be assigned to a different type. Also, right after entering the line that declares the variable, intellisense becomes available.
We can see that actually the variable x is of an anonymous type with the two properties Name and EmployeeNumber plus the inherited properties from the Object class. If we declare another anonymous type variable with the same structure:
var y = new { Name = "Smith", EmployeeNumber = "199283" };
Then the new variable, y, is compatible with x. In another words, since it has the same properties with the same types (string, string) then C# compiler detects that x and y are of the same type even though we never declared it explicitly. In this case the instruction: x = y is correct and will result in affecting the value of y in x. However if we declare a third variable z:
var z = new { Name = "Buddy", Company = "Microsoft" };
and try to affect the value of z to x for instance, we will have a compilation error (and not a runtime error – typical for non-typed variables - ). Even though z has two members of string type, all like x and y, it is not compatible. The reason is that the second property has not the same name (company versus EmployeeNumber).
Some restrictions to anonymous types:
Anonymous types are only permitted for local variables. You cannot declare a class member with the var keyword. A method cannot return a var type neither can it has a var type parameter; all the following declarations won’t compile:
public int function(var x, int y)
public var function(int x, int y)
however returning a var variable value is permitted:
public int function(int x, int y)
{
var t = x + y;
return t;
}
The reason is simple : at the point of the ‘return’ statement, the compiler knows that ‘t’ is an integer and can be returned since the method must return an integer.
Why using anonymous types?
First, let’s calm down the spirits who think that this is a step back to untyped variables. As mentioned in this post, it is really an implicit typing and if you look at it closely, the variables are typed but the type is constructed ‘on the fly’ if we want. We can use it without declaring it.
This may open the door to poor programming if it is overused. However, the impact might be limited since the anonymous type has only the scope of the method where it is used. The main advantage of the anonymous types is in LINQ (beyond the scope of this post). I will post something on LINQ pretty quickly…
Well the only advantage I can see is to be able to manipulate temporary results in a collection of an anonymous structure and then do something with it without having to declare a very lightweight structure or class just to carry the results in one single method. I can see the usage in a data access layer class that has to process the result returned by a DataReader. But until today, we lived without it and never felt really a need for it.
As a conclusion, I believe that the real advantage is the LINQ query…. Which I will talk about in my next post.
We can see that actually the variable x is of an anonymous type with the two properties Name and EmployeeNumber plus the inherited properties from the Object class. If we declare another anonymous type variable with the same structure:
var y = new { Name = "Smith", EmployeeNumber = "199283" };
Then the new variable, y, is compatible with x. In another words, since it has the same properties with the same types (string, string) then C# compiler detects that x and y are of the same type even though we never declared it explicitly. In this case the instruction: x = y is correct and will result in affecting the value of y in x. However if we declare a third variable z:
var z = new { Name = "Buddy", Company = "Microsoft" };
and try to affect the value of z to x for instance, we will have a compilation error (and not a runtime error – typical for non-typed variables - ). Even though z has two members of string type, all like x and y, it is not compatible. The reason is that the second property has not the same name (company versus EmployeeNumber).
Some restrictions to anonymous types:
Anonymous types are only permitted for local variables. You cannot declare a class member with the var keyword. A method cannot return a var type neither can it has a var type parameter; all the following declarations won’t compile:
public int function(var x, int y)
public var function(int x, int y)
however returning a var variable value is permitted:
public int function(int x, int y)
{
var t = x + y;
return t;
}
The reason is simple : at the point of the ‘return’ statement, the compiler knows that ‘t’ is an integer and can be returned since the method must return an integer.
Why using anonymous types?
First, let’s calm down the spirits who think that this is a step back to untyped variables. As mentioned in this post, it is really an implicit typing and if you look at it closely, the variables are typed but the type is constructed ‘on the fly’ if we want. We can use it without declaring it.
This may open the door to poor programming if it is overused. However, the impact might be limited since the anonymous type has only the scope of the method where it is used. The main advantage of the anonymous types is in LINQ (beyond the scope of this post). I will post something on LINQ pretty quickly…
Well the only advantage I can see is to be able to manipulate temporary results in a collection of an anonymous structure and then do something with it without having to declare a very lightweight structure or class just to carry the results in one single method. I can see the usage in a data access layer class that has to process the result returned by a DataReader. But until today, we lived without it and never felt really a need for it.
As a conclusion, I believe that the real advantage is the LINQ query…. Which I will talk about in my next post.
Subscribe to:
Posts (Atom)