It's been long since I got excited about a web site. I have to say, I'm very impressed with the idea, creativity, innovation and the intuitive interface of this web site/project. It's based on the idea that you don't need to click to navigate.. they strongly suggest that you don't click at all!
Check it out here: http://www.dontclick.it/. Check out the whole web site, all pages to get the real fun.
I feel like pulling out the buttons of my mouse :P.
Monday, August 18, 2008
Sunday, July 6, 2008
C++: What's the difference between class and struct?
What's the difference between class and struct?
A beginner would say:
"There are a lot of differences, class is a C++ element and struct is a C one. We can have functions, virtual functions, inheritance, different access modifiers private, protected, public in a class but probably not in a struct. A struct generally holds member variables only."
(Just to clarify, the above statement is completely wrong.)
Intermediate and most advanced C++ programmers would say:
"class and struct do not have any difference, except the fact that class members are by default private and struct members are by default public. The keywords class and struct are interchangeable."
The above statement is correct to some extent and would satisfy most questioners, however, there are some special cases where class and struct are not interchangeable.
Consider the following code which compiles well in a C++ complier:
template <class T>
void fn()
{
}
Now replace the keyword 'class' with 'struct' and compile it..
template <struct T>
void fn()
{
}
It gives a compiler error! According to MSDN's definition of the template keyword:
"The template-parameter-list is a comma-separated list of template parameters, which may be types (in the form class identifier, typename identifier, or template < template-parameter-list > class identifier) or non-type parameters to be used in the template body."
So the template parameter list doesn't take the keyword 'struct'!
The template mechanism itself was introduced in later phase of the C++ evolution, some years later than the first version of C++. The 'struct' keyword was probably ignored when defining template which was considered to be an advance feature of C++.
"Another reasonable use of the C struct in C++, then, is when you want to pass all or part of a complex class object to a C function. This struct declaration serves to encapsulate that data and guarantees a compatible C storage layout. This guarantee, however, is maintained only under composition." said Stanley B. Lippman, author of several C++ books.
A beginner would say:
"There are a lot of differences, class is a C++ element and struct is a C one. We can have functions, virtual functions, inheritance, different access modifiers private, protected, public in a class but probably not in a struct. A struct generally holds member variables only."
(Just to clarify, the above statement is completely wrong.)
Intermediate and most advanced C++ programmers would say:
"class and struct do not have any difference, except the fact that class members are by default private and struct members are by default public. The keywords class and struct are interchangeable."
The above statement is correct to some extent and would satisfy most questioners, however, there are some special cases where class and struct are not interchangeable.
Consider the following code which compiles well in a C++ complier:
template <class T>
void fn()
{
}
Now replace the keyword 'class' with 'struct' and compile it..
template <struct T>
void fn()
{
}
It gives a compiler error! According to MSDN's definition of the template keyword:
"The template-parameter-list is a comma-separated list of template parameters, which may be types (in the form class identifier, typename identifier, or template < template-parameter-list > class identifier) or non-type parameters to be used in the template body."
So the template parameter list doesn't take the keyword 'struct'!
The template mechanism itself was introduced in later phase of the C++ evolution, some years later than the first version of C++. The 'struct' keyword was probably ignored when defining template which was considered to be an advance feature of C++.
"Another reasonable use of the C struct in C++, then, is when you want to pass all or part of a complex class object to a C function. This struct declaration serves to encapsulate that data and guarantees a compatible C storage layout. This guarantee, however, is maintained only under composition." said Stanley B. Lippman, author of several C++ books.
C++: Accessing the virtual table directly
This post is not intended for beginners. To understand the content of this topic, you need to have basic understanding of what virtual functions are.
We know that the run time binding or virtual function mechanism is implemented by a virtual table. If a class has at least one virtual function a virtual table will be created for that class. To be specific, 'only one' virtual table will be created for all of the instances/objects of that class. Each of the instances and objects will have a pointer to the virtual table.
The same thing is true for a class hierarchy. Meaning, if class Z derives class Y and class Y derives class X, only one virtual table will be created for all instances/objects of class X, Y and Z. Each of the instances and objects of X, Y and Z will have a pointer to the virtual table.
===============
Added on July 14, 2008:
The virtual tables for each of class X, Y and Z share common information but they are not necessarily the same table for each of these classes. The scenario is complex for multiple and virtual inheritance. I would like to discuss them in future posts.
===============
A pointer is 32 bit/4 bytes in a 32-bit architecture and 64-bit/8 bytes in a 64-bit architecture. So all instances/objects of a class or class hierarchy, where we have a virtual table, will have additional 4 bytes in them and 8 bytes in case of a 64-bit architecture.
This pointer is called virtual table pointer, sometimes 'vptr'. In VC++ compiler, the objects will have a pointer named '__vfptr' in them and in some other compiler it's '__vptr_X', where X is the class name.
Now __vfptr is not directly accessible from your code. For example, if you write the following code you'll get a compiler error as the __vfptr is not available for your use.
However, if you debug the code in VC++, you can see the 'a.__vfptr' in the variable watch windows. Interesting ha?
Okay, now we'd like to see how we can access the virtual table even if the compiler doesn't want us to. Let's have class X with a virtual function fn() which simply prints a member variable and we want to access the virtual table of class X to call the function fn() using it. The following code does that.
In line 26, we have:
The first entry of the virtual table is the function pointer of the virtual function 'fn'. We can access the first entry using vptr[0] (as this is just an array). So, in line 37, we just call the function using the function pointer. But wait, you might be asking why the following assembly line is there before that function call.
When we call the function fn() in this way: obj->fn(), the compiler does the job for us and sets 'obj' as 'this' before calling the function. But in line 37, we couldn't specify anything to the function fn() saying it is called for the object 'obj', so the function won't find out where to get the value of 'n' from. This is why we expicitly need to set the 'obj' as 'this' before we call the function fn() in line 37. We did that in line 33, in the assembly code. This line is again VC++ specific. In VC++, 'this' pointer is set in the register 'ECX'. Some other compiler may handle that differently.
If we had more virtual function, we could have access them using next indexes of vptr: vptr[1], vptr[2], etc.
We have learned some interesting facts about the virtual functions and the virtual table. We may not have any use of this kind of code where we need to directly access the virtual table in our general applications but this helps when you want to know more about C++ internals.
Enjoy!
July 12, 2008:
We assumed here that the vptr is placed in the beginning of the class object. here's a note on that:
Traditionally, the vptr has been placed after all the explicitly declared members of the class. More recently, it has been placed at the beginning of the class object. The C++ Standard allows the compiler the freedom to insert these internally generated members anywhere, even between those explicitly declared by the programmer.
We know that the run time binding or virtual function mechanism is implemented by a virtual table. If a class has at least one virtual function a virtual table will be created for that class. To be specific, 'only one' virtual table will be created for all of the instances/objects of that class. Each of the instances and objects will have a pointer to the virtual table.
The same thing is true for a class hierarchy. Meaning, if class Z derives class Y and class Y derives class X, only one virtual table will be created for all instances/objects of class X, Y and Z. Each of the instances and objects of X, Y and Z will have a pointer to the virtual table.
===============
Added on July 14, 2008:
The virtual tables for each of class X, Y and Z share common information but they are not necessarily the same table for each of these classes. The scenario is complex for multiple and virtual inheritance. I would like to discuss them in future posts.
===============
A pointer is 32 bit/4 bytes in a 32-bit architecture and 64-bit/8 bytes in a 64-bit architecture. So all instances/objects of a class or class hierarchy, where we have a virtual table, will have additional 4 bytes in them and 8 bytes in case of a 64-bit architecture.
This pointer is called virtual table pointer, sometimes 'vptr'. In VC++ compiler, the objects will have a pointer named '__vfptr' in them and in some other compiler it's '__vptr_X', where X is the class name.
Now __vfptr is not directly accessible from your code. For example, if you write the following code you'll get a compiler error as the __vfptr is not available for your use.
1 X a;
2 cout << a.__vfptr;
However, if you debug the code in VC++, you can see the 'a.__vfptr' in the variable watch windows. Interesting ha?
Okay, now we'd like to see how we can access the virtual table even if the compiler doesn't want us to. Let's have class X with a virtual function fn() which simply prints a member variable and we want to access the virtual table of class X to call the function fn() using it. The following code does that.
1 #include <iostream>Please note, this code is compiler dependent and may only work on VC++ compilers and it'll work correctly when you'll run it in 'Release' mode. Here goes some explanation of the code.
2
3 using namespace std;
4
5 //a simple class
6 class X
7 {
8 public:
9 //fn is a simple virtual function
10 virtual void fn()
11 {
12 cout << "n = " << n << endl;
13 }
14
15 //a member variable
16 int n;
17 };
18
19 int main()
20 {
21 //create an object (obj) of class X
22 X *obj = new X();
23 obj->n = 10;
24
25 //get the virtual table pointer of object obj
26 int* vptr = *(int**)obj;
27
28 // we shall call the function fn, but first the following assembly code
29 // is required to make obj as 'this' pointer as we shall call
30 // function fn() directly from the virtual table
31 __asm
32 {
33 mov ecx, obj
34 }
35
36 //function fn is the first entry of the virtual table, so it's vptr[0]
37 ( (void (*)()) vptr[0] )();
38
39 //the above is the same as the following
40 //obj->fn();
41
42 return 0;
43 }
44
In line 26, we have:
26 int* vptr = *(int**)obj;The virtual table pointer __vfptr is available in the first 4 bytes of the object. In this line, we get the value of the pointer __vfptr or the address of the virtual table as an integer pointer (say as a pointer to an integer array).
The first entry of the virtual table is the function pointer of the virtual function 'fn'. We can access the first entry using vptr[0] (as this is just an array). So, in line 37, we just call the function using the function pointer. But wait, you might be asking why the following assembly line is there before that function call.
33 mov ecx, objIf you take another look into the implementation of function fn(), you can see that it prints out the member variable 'n', which is only avaliable to object 'obj'. Inside the function fn(), 'obj' needs to be set as 'this' pointer, to give the function fn() access to all it's members.
When we call the function fn() in this way: obj->fn(), the compiler does the job for us and sets 'obj' as 'this' before calling the function. But in line 37, we couldn't specify anything to the function fn() saying it is called for the object 'obj', so the function won't find out where to get the value of 'n' from. This is why we expicitly need to set the 'obj' as 'this' before we call the function fn() in line 37. We did that in line 33, in the assembly code. This line is again VC++ specific. In VC++, 'this' pointer is set in the register 'ECX'. Some other compiler may handle that differently.
If we had more virtual function, we could have access them using next indexes of vptr: vptr[1], vptr[2], etc.
We have learned some interesting facts about the virtual functions and the virtual table. We may not have any use of this kind of code where we need to directly access the virtual table in our general applications but this helps when you want to know more about C++ internals.
Enjoy!
July 12, 2008:
We assumed here that the vptr is placed in the beginning of the class object. here's a note on that:
Traditionally, the vptr has been placed after all the explicitly declared members of the class. More recently, it has been placed at the beginning of the class object. The C++ Standard allows the compiler the freedom to insert these internally generated members anywhere, even between those explicitly declared by the programmer.
Saturday, June 28, 2008
C++: Avoid using assignments in constructors
In my post Coding better C++, I've suggested a list of techniques to improve C++ coding. I shall try to explain them one at a time in the future posts. In this post, I've talked about "4. Avoid using assignments in constructors, use initializer list to initialize members".
The initialize list is used to avoid double construction of a contained object. Take the following example:
As you can see the result of the step 1.a, string::string(), is discarded by step 3.a, string::operator=(const char *), the step 1.a is therefore redundant.
We can optimize this with the initializer list, in the following way:
Many optimizations require some kind of a trade-off. You often trade speed for clarity, simplicity, re-usability, or some other metric. But in this example, optimization requires no sacrifice at all. This constructor will generate the exact same Student object with the exception of improved performance.
The initialize list is used to avoid double construction of a contained object. Take the following example:
1We create an object of the Student, for example, in the following way.
2 Class Student
3 {
4 public:
5 Student ( const char *_name)
6 {
7 name = _name;
8 }
9 private:
10 string name;
11 };
Student s (“Abc”);The following executions take place:
1. string name is initialized
a. string::string() function is called
2. body of the Student::Student(const char *) constructor is called
3. the line name = _name is executed
a. string::operator=(const char *) function is called
As you can see the result of the step 1.a, string::string(), is discarded by step 3.a, string::operator=(const char *), the step 1.a is therefore redundant.
We can optimize this with the initializer list, in the following way:
1 Class StudentIn this way, the string 'name' is initialized only once and with the value of _name and it calls the string::string(const char *) function directly.
2 {
3 public:
4 Student ( const char *_name) : name (_name)
5 {
6 }
7 private:
8 string name;
9 };
10
Many optimizations require some kind of a trade-off. You often trade speed for clarity, simplicity, re-usability, or some other metric. But in this example, optimization requires no sacrifice at all. This constructor will generate the exact same Student object with the exception of improved performance.
Saturday, June 21, 2008
Project management thoughts - 3. Parallel development issues
This is a continuation of the "Project management thoughts" series. Please read the previous posts if you haven't already.
In this post, I shall talk about why the parallel development of prototype and real application is not a good idea in a case like ours.
Why prototype and real development should not be in parallel
The purpose of the prototype is to try out different brainstorming results of the client and solidifying requirements from it. Now, the scope of the new requirements and 'change requests' to already solidified requirements have no limits, officially.
Let's take a break and do some basic maths of project management. A project has three main key factors: Time (T), Material (M) and Resources (R). Time is proportional to material and inversely proportional to resources. This can be represented in the following way.
Meaning: 1. If your time is fixed and if you increase your material, you also need to increase your resources, 2. If your resources are fixed and if you increase your material, you also need to increase your time, 3. If you material is fixed and if you change your resources, your time will get changed, and so on.
I'm sure most of us know this in one form or another and I only described in details for the newbies.
Now back to the prototype, if the prototype continuously gives us new requirements through out the whole project time line, we need to have time open ended, according to the simple math that we done above, but that not an option in the first place. This is fixed time project.
Besides new requirements, the prototype will also yield a list of small and large changes (large, in terms of task volume). These changes need to get reflected in the already built features of the real application. The changes, of course, are materials (M) which requires more time (T).
The changes imposed from the prototype will virtually have no limits. If we have already implemented, for example, 20 features in the real application that were previously solidified, those may require complete or partial reworks in a very short time. Adjusting major changes in the requirements makes a solid codebase messy, making it more vulnerable to major bugs. Re-structuring, re-designing (the software design) and re-implementing are probably the last things a development team wants to do. If requirements get changed every now and then, which we cannot guarantee, may end up with unexpectedly weak software design and codebase.
There are also other factors of why it doesn't seem to be a good idea to run prototype and real application development in parallel. One of them is the time it takes to solidify requirements from the prototype. If we assume that we shall get requirements solidified from the prototype at a constant rate (or at a good rate) then it would be very wrong in real life. In practical scenarios we may get some or many of requirements solidified from the prototype and we may also need to wait a significant amount of time to get something solidified as it is very much dependent on client's decisions. 'Waiting' on a dependency for uncertain period of time for a 'fixed time and resources' project like ours (or in any project), is just one of the failure factors.
The better solution
Our proposed solution was to complete the prototype application first, with the effort of the full development team, solidifying requirements from it, and then working on the real application, again with the effort of the full development team.
This solves a lot of problems, the ones that I mentioned above. The only concern with this way is, can we really complete the prototype with all ideas of the client in time and then can we finalize requirements from the prototype in time? Well, it requires effort from both of the side, the team and the client. Both parties need to work aggressively towards one goal, which is to identify requirements within a given time frame.
To be continued.
Coming up soon: The team formation, the technologies, the tools used, the prototype phase, the software design phase..
[I shall continue to talk about my project management experiences and thoughts about this project in regular posts. I hope you shall find them interesting or useful].
In this post, I shall talk about why the parallel development of prototype and real application is not a good idea in a case like ours.
Why prototype and real development should not be in parallel
The purpose of the prototype is to try out different brainstorming results of the client and solidifying requirements from it. Now, the scope of the new requirements and 'change requests' to already solidified requirements have no limits, officially.
Let's take a break and do some basic maths of project management. A project has three main key factors: Time (T), Material (M) and Resources (R). Time is proportional to material and inversely proportional to resources. This can be represented in the following way.
T = M / R
or T x R = M
or T x R = M
Meaning: 1. If your time is fixed and if you increase your material, you also need to increase your resources, 2. If your resources are fixed and if you increase your material, you also need to increase your time, 3. If you material is fixed and if you change your resources, your time will get changed, and so on.
I'm sure most of us know this in one form or another and I only described in details for the newbies.
Now back to the prototype, if the prototype continuously gives us new requirements through out the whole project time line, we need to have time open ended, according to the simple math that we done above, but that not an option in the first place. This is fixed time project.
Besides new requirements, the prototype will also yield a list of small and large changes (large, in terms of task volume). These changes need to get reflected in the already built features of the real application. The changes, of course, are materials (M) which requires more time (T).
The changes imposed from the prototype will virtually have no limits. If we have already implemented, for example, 20 features in the real application that were previously solidified, those may require complete or partial reworks in a very short time. Adjusting major changes in the requirements makes a solid codebase messy, making it more vulnerable to major bugs. Re-structuring, re-designing (the software design) and re-implementing are probably the last things a development team wants to do. If requirements get changed every now and then, which we cannot guarantee, may end up with unexpectedly weak software design and codebase.
There are also other factors of why it doesn't seem to be a good idea to run prototype and real application development in parallel. One of them is the time it takes to solidify requirements from the prototype. If we assume that we shall get requirements solidified from the prototype at a constant rate (or at a good rate) then it would be very wrong in real life. In practical scenarios we may get some or many of requirements solidified from the prototype and we may also need to wait a significant amount of time to get something solidified as it is very much dependent on client's decisions. 'Waiting' on a dependency for uncertain period of time for a 'fixed time and resources' project like ours (or in any project), is just one of the failure factors.
The better solution
Our proposed solution was to complete the prototype application first, with the effort of the full development team, solidifying requirements from it, and then working on the real application, again with the effort of the full development team.
This solves a lot of problems, the ones that I mentioned above. The only concern with this way is, can we really complete the prototype with all ideas of the client in time and then can we finalize requirements from the prototype in time? Well, it requires effort from both of the side, the team and the client. Both parties need to work aggressively towards one goal, which is to identify requirements within a given time frame.
To be continued.
Coming up soon: The team formation, the technologies, the tools used, the prototype phase, the software design phase..
[I shall continue to talk about my project management experiences and thoughts about this project in regular posts. I hope you shall find them interesting or useful].
Friday, June 20, 2008
Project management thoughts - 2. The initial team and tasks
This is a continuation of the "Project management thoughts" series. Please read the previous posts if you haven't already.
In this post, I shall mostly talk about the initial tasks of the project TP and my thoughts about it.
The initial team
Even though the project now have 20 engineers, it began only with 2 engineers. The primary goals of the initial team were to understand high level requirements of the project and to estimate required resources for the project. The initial team members were:
The initial plan
The client wants to identify the detailed requirements with a prototype project. The prototype project will follow agile development method and needs to have a weekly build on which the client would like to try out a few different ideas and solidify detailed requirements as the builds go on. Basically the prototype project will be a brain storming ground for the client and requirements capturing ground for us (ReliSource).
The client wants a separate development project to run in parallel to the prototype project and the solidified requirement sets should be sent to the development project team for real implementation.
The idea is to test different things on the prototype, solidifying them and to build them in the real application. Both of the prototype development and real application development needs to go in parallel and the project, actually the first release, needs to be completed within six months.
Sounds doable? Well, not exactly. I shall post about 1. why not, 2. how we proposed a different strategy which was doable and also made the client happy, in my next post.
In this post, I shall mostly talk about the initial tasks of the project TP and my thoughts about it.
The initial team
Even though the project now have 20 engineers, it began only with 2 engineers. The primary goals of the initial team were to understand high level requirements of the project and to estimate required resources for the project. The initial team members were:
- A senior engineer with around 2 years of experiences, skilled in C#, Java and PHP
- Myself
The initial plan
The client wants to identify the detailed requirements with a prototype project. The prototype project will follow agile development method and needs to have a weekly build on which the client would like to try out a few different ideas and solidify detailed requirements as the builds go on. Basically the prototype project will be a brain storming ground for the client and requirements capturing ground for us (ReliSource).
The client wants a separate development project to run in parallel to the prototype project and the solidified requirement sets should be sent to the development project team for real implementation.
The idea is to test different things on the prototype, solidifying them and to build them in the real application. Both of the prototype development and real application development needs to go in parallel and the project, actually the first release, needs to be completed within six months.
Sounds doable? Well, not exactly. I shall post about 1. why not, 2. how we proposed a different strategy which was doable and also made the client happy, in my next post.
Friday, June 13, 2008
Project management thoughts - 1. Introduction
I'm currently working with a team of size 20. I'm playing a dual role of project manager and technical lead at the same time. I'll try to share my experiences with this relatively large team and my thoughts on project management. The age of the project is two and half months and is currently scheduled for four more months.
I'm planning to blog about this live project as it goes on which I believe is a courageous step. I shall try to maintain the privacy and not to disclose sensitive project information here.
The team
The team has 20 engineers, including me, with the following distribution.
All development engineers are good problem solvers, strong in C++ or C# or Java, strong in OOP and are dedicated. One of them even went to ACM world finals.
So, overall, it's a brilliant team.
The project
The project is a medium scale web application. I cannot disclose the description of the project but the type of the project is to build and manage networks between two groups of people.
The project is fresh development from the scratch where we do not need to work on existing codebase. Let's call the project 'The Project' or TP in short ;).
TP has two sub projects, let's call them:
The project is targeted towards massive user groups, say several thousand from the first user group and hundreds of thousands from second user group will use the application within a year of lunching the application. The project will have rigorous database transactions for most of the features and functionalities.
Professional and rich user experience is very important in this project. The project will have good looking UI components, for which we have a dedicated graphics designer.
To be continued.
[I shall continue to talk about my project management experiences and thoughts about this project in regular posts. I hope you shall find them interesting or useful].
I'm planning to blog about this live project as it goes on which I believe is a courageous step. I shall try to maintain the privacy and not to disclose sensitive project information here.
The team
The team has 20 engineers, including me, with the following distribution.
- 14 developers
- 9 developers have 1 year of experiences on average
- 5 developers have 2 years of experiences on average
- 4 SQAs
- 1 release engineer/SQA lead, with 3+ years of experiences
- 3 engineers with 1 year of experiences of average
- 1 graphics designer
- 2+ years of experiences
- 1 project manager
- that's me with 5+ years of experiences
All development engineers are good problem solvers, strong in C++ or C# or Java, strong in OOP and are dedicated. One of them even went to ACM world finals.
So, overall, it's a brilliant team.
The project
The project is a medium scale web application. I cannot disclose the description of the project but the type of the project is to build and manage networks between two groups of people.
The project is fresh development from the scratch where we do not need to work on existing codebase. Let's call the project 'The Project' or TP in short ;).
TP has two sub projects, let's call them:
- TPX - which is for the first user group
- TPY - which is for the 2nd user group
- TPZ - which is for administrator users
The project is targeted towards massive user groups, say several thousand from the first user group and hundreds of thousands from second user group will use the application within a year of lunching the application. The project will have rigorous database transactions for most of the features and functionalities.
Professional and rich user experience is very important in this project. The project will have good looking UI components, for which we have a dedicated graphics designer.
To be continued.
[I shall continue to talk about my project management experiences and thoughts about this project in regular posts. I hope you shall find them interesting or useful].
Empowerment of SQA
This has probably become a hot topic recently. The 'scope of the empowerment' really needs to be defined. What 'powers' does empowerment include and what not? Whatever we say it 'includes', does it apply to all projects? even of different types?
SQA team, if empowered, needs definition of what they can do and what not. There can be some serious do's. For example, can they stop a software release which has many bugs? If so, can your team, your company or the client effort it? What is the real intention of this action, better quality even if it hampers project timeline and the business of the client?
There can be some less serious do's of SQA empowerment, for example: SQA team suggests to improve usability (a simple example of this: a numeric textbox takes all characters and validates and shows error later on if the input is not a number. SQA team suggests that the textbox should allow only number keystrokes in the first place). Now this sort of details may not be mentioned in the spec and so, in general, the developers argue with the SQA (may be because they feel lazy). According to empowerment do's, should the SQA be able to insist the developers to follow the suggestion?
If you want to empower SQA and try to draw some lines on their do's and don'ts then you're most likely to rediscover a simple fact.
In most of the companies, SQA teams are so much dominated by the development team that they (SQA) cannot raise their voices even if they see something is terribly wrong. It's the problem with a developer's perspective of the SQA team. In general, a developer feels much superior to a similar ranking SQA and feels he (developer) know much more and his work is the most important thing in the project's success.
So, now the empowerment is needed to make the developers feel that SQAs have some power too (!!) and a developer cannot just overlook their suggestions(?). Is this the main reason behind empowerment of SQA? if so, then let's look at the origin of the issue again. Is it again a developer's mindset and his careless or superior attitude towards a SQA? Can this be fixed? And is the officially declared 'SQA empowerment' the only way?
In Bangladesh, most of the SQA engineers cannot do programming or understand mature coding and the 'white box' is just too much for them. Some seriously lack knowledge of latest technologies, techniques and advance skills (for example, only few SQAs have ever built and installed a software on Linux command prompt, unless it's a project-specific task). So, SQAs, in general, fall behind technical capabilities of developers. This should be addressed and SQAs need much improvement in the technical areas to make a good impression with rest of the team.
Developers should learn the importance of others' comments. One developer sometimes doesn't value the suggestions of other good developers, let alone the SQAs. Horribly some seniors do that as well! This issue needs to be handled by the Project Manager or above. Developers should receive a 'clear message' saying: not to overlook other's suggestions and comments and to strongly collaborate with the SQA team.
If you can handle the root of the problem, 'empowerment' or other 'forceful' ideas might not be needed. Peaceful solutions are good for the project health and the forceful ones might not be so, rather they can introduce chaos.
SQA team, if empowered, needs definition of what they can do and what not. There can be some serious do's. For example, can they stop a software release which has many bugs? If so, can your team, your company or the client effort it? What is the real intention of this action, better quality even if it hampers project timeline and the business of the client?
There can be some less serious do's of SQA empowerment, for example: SQA team suggests to improve usability (a simple example of this: a numeric textbox takes all characters and validates and shows error later on if the input is not a number. SQA team suggests that the textbox should allow only number keystrokes in the first place). Now this sort of details may not be mentioned in the spec and so, in general, the developers argue with the SQA (may be because they feel lazy). According to empowerment do's, should the SQA be able to insist the developers to follow the suggestion?
If you want to empower SQA and try to draw some lines on their do's and don'ts then you're most likely to rediscover a simple fact.
In most of the companies, SQA teams are so much dominated by the development team that they (SQA) cannot raise their voices even if they see something is terribly wrong. It's the problem with a developer's perspective of the SQA team. In general, a developer feels much superior to a similar ranking SQA and feels he (developer) know much more and his work is the most important thing in the project's success.
So, now the empowerment is needed to make the developers feel that SQAs have some power too (!!) and a developer cannot just overlook their suggestions(?). Is this the main reason behind empowerment of SQA? if so, then let's look at the origin of the issue again. Is it again a developer's mindset and his careless or superior attitude towards a SQA? Can this be fixed? And is the officially declared 'SQA empowerment' the only way?
In Bangladesh, most of the SQA engineers cannot do programming or understand mature coding and the 'white box' is just too much for them. Some seriously lack knowledge of latest technologies, techniques and advance skills (for example, only few SQAs have ever built and installed a software on Linux command prompt, unless it's a project-specific task). So, SQAs, in general, fall behind technical capabilities of developers. This should be addressed and SQAs need much improvement in the technical areas to make a good impression with rest of the team.
Developers should learn the importance of others' comments. One developer sometimes doesn't value the suggestions of other good developers, let alone the SQAs. Horribly some seniors do that as well! This issue needs to be handled by the Project Manager or above. Developers should receive a 'clear message' saying: not to overlook other's suggestions and comments and to strongly collaborate with the SQA team.
If you can handle the root of the problem, 'empowerment' or other 'forceful' ideas might not be needed. Peaceful solutions are good for the project health and the forceful ones might not be so, rather they can introduce chaos.
Friday, May 30, 2008
Black boxes are not black
As the name itself suggests, 'Black boxes' in commercial airplanes are black by most people's assumptions, as the case was with me. But I recently learned that black boxes are not black, rather they are bright orange or red in most commercial airplanes.
Interestingly, in Boeing 747, the black boxes (there are two) are bright red and all other aviation electronic boxes are black :). The unique bright color helps locating the 'black box' quickly in case of an accident.
You can verify at: http://www.howstuffworks.com/black-box.htm
Interestingly, in Boeing 747, the black boxes (there are two) are bright red and all other aviation electronic boxes are black :). The unique bright color helps locating the 'black box' quickly in case of an accident.
You can verify at: http://www.howstuffworks.com/black-box.htm
Sunday, March 16, 2008
Coding better C++
I've prepared a short guideline for writing better codes in C++. I've prepared the list from my C++ experiences and studies. Each item of the list needs good amount of explanation which is outside of the scope of this post. I'll try to explain them in the future posts in my blog. For now, if you need more information on an suggested item, you can look up on the internet or in the books.
Here it goes:
Once you get used to all of the suggested points, you'll find that your code is much much better than many others and of course, more optimized and less error prone. Let me emphasize, 'these are golden suggestions, try to follow them'.
Happy coding :).
Here it goes:
- C++ is not C. Stop mixing C and C++ unless it is required. Start thinking in C++.
- Have a C++ coding standard defined or follow the coding standard defined for your project or organization.
- Design from outside, design the interfaces first.
- Avoid using assignments in constructors, use initializer list to initialize members.
- Know the need of copy constructor and define when needed.
- Use virtual destructor when your class is used as a base class.
- Never call a destructor (unless you're using a placement new). If you do, you may need to revise your software design.
- Avoid using placement new.
- Avoid using Macros for functions. Use Inline functions instead.
- Avoid using Array, unless you have to. Use standard library containers like Vector, etc.
- Avoid C style cast, use the C++ casts.
- Use references when you can and pointers when you have to.
- Use composition when you can and private inheritance when you have to.
- Use const for function parameters when you can.
- Be careful about static initializations, you might get unexpected behavior if the static variables/objects has dependencies.
- Be careful about multiple inheritance. Understand the 'dreaded diamond'.
- Be careful about floats and doubles. They may give you unexpected behaviors.
- Avoid constant literals in the code. Separate them in static inline functions or macros.
Once you get used to all of the suggested points, you'll find that your code is much much better than many others and of course, more optimized and less error prone. Let me emphasize, 'these are golden suggestions, try to follow them'.
Happy coding :).
How to begin web programming with PHP
I am often asked, 'how to begin web programming with PHP?'. Following is a response that I had given few weeks ago. Hope this will be useful for anyone willing to start learning PHP.
Things you need to know to begin web programming with PHP:
Here are the links to tutorials that may help you to accelerate your learning process.
Things you need to know to begin web programming with PHP:
- Good knowledge of HTML
- Some knowledge of CSS
- Some knowledge of JavaScript
- Good knowledge of MySQL Database, SQL (as most php applications are database driven)
- Good knowledge of PHP
- Using and configuring Apache
Here are the links to tutorials that may help you to accelerate your learning process.
- HTML:
- Very good short tutorial: http://www.w3schools.com/html
/html_intro.asp - Good tutorial: http://www.w3.org/MarkUp/Guide/
- Advanced tutorial: http://www.w3.org/MarkUp/Guide
/Advanced.html - CSS:
- Very good short tutorial: http://www.w3schools.com/css
/css_intro.asp - A good tutorial: http://www.w3.org/Style
/Examples/011/firstcss - A detailed tutorial: http://www.html.net/tutorials
/css/ - JavaScript:
- Very good short tutorial on JavaScript: http://www.w3schools.com/js/js
_intro.asp - Detailed tutorial: http://www.webdeveloper.com
/javascript/javascript_js _tutorial.html - PHP:
- Very good short tutorial on PHP: http://www.w3schools.com/php
/php_intro.asp - Very good detailed tutorial on PHP: http://devzone.zend.com/node
/view/id/627 (go through all the parts)
- Wamp Server (http://www.wampserver.com/en/download.php) which includes Apache web server, PHP and MySQL.
- Editor: Notepad++ (http://notepad-plus-plus.org/download).
- HTML Editor: DreamWeaver, FrontPage.
- References (must have): php manual.chm, mysql manual.chm, javascript referenece books.
- Keep the references handy/near to you.
- Search in Google for more tutorials
- Look into well known PHP frameworks (search for: top php frameworks).
- Look into open source projects to learn how real life applications are done.
- Practice well :)
Thursday, January 10, 2008
C# never made me anymore happier than today!
I wasn't anymore happier than today in ... hmm... in the last few months!
I have been working with a project where I need to convert a VB.Net project into C# one. The whole project contains 40 other C++ projects which are mostly libraries and plug-ins. The full project is huge.. only the source files (.cpp, .h, .vb) are probably 50+ MB.
Now there are freeware tools, both web based and desktop ones, to convert a chunk of VB.Net code to C# ones. There are some good articles on that as well. SharpDevelop, the open source C# development tool has a built in feature to convert VB.Net codes/solutions to C#. Some web based free conversion services are based on SharpDevelop. SharpDevelop does a average job in real life applications (like the one I'm working with) but it's far from being 'good'. It produces numerous amount of errors which of course we need to fix manually. It's really poor for converting VB's "implicit type conversion", "globals" and many other common stuff!
As our client suggested, I used a commercial conversion tool, it's from vbconversions.net. This one was not as fool as the open source or freeware ones but it yielded a lot of errors too. One funny thing with this tool is that it horribly masses up name spaces and some function parameters (which are not of intrinsic type or has name space), and of course it fails handling VB's implicit conversions too.
After fixing thousands of errors for almost a week we finally got our project compiling! Then the final moment arrived, we wanted to run it! We did.. and (as to my expectation).. it crashed horribly!
After one more week of debugging and tracing down the almost untraceable, horrible and ugly crashes.. I almost began to loose patients!
But today, some horrible thread related bugs were solved dramatically.. and guess what.. finally .. we got what we wanted... we got it running today! The project loads and shows the 3D models the way it should do.. well, even though there are a lot of bugs we need smash!
When the project ran and gave me the same output of the VB.Net project, it was a beautiful thing to see and a very interesting moment. It made me really happy.. :)
Now, it gives a lot of inspiration and stamina to fix the rest of bugs. I'll have a formal QA first on this stage of the project and then start fixing. So rest of the bugs, be aware.. here I come.. :)
By the way, the client of the project I am working for is one of the leading game development companies in the world, everyone knows their name and it's interesting to work for them.
I have been working with a project where I need to convert a VB.Net project into C# one. The whole project contains 40 other C++ projects which are mostly libraries and plug-ins. The full project is huge.. only the source files (.cpp, .h, .vb) are probably 50+ MB.
Now there are freeware tools, both web based and desktop ones, to convert a chunk of VB.Net code to C# ones. There are some good articles on that as well. SharpDevelop, the open source C# development tool has a built in feature to convert VB.Net codes/solutions to C#. Some web based free conversion services are based on SharpDevelop. SharpDevelop does a average job in real life applications (like the one I'm working with) but it's far from being 'good'. It produces numerous amount of errors which of course we need to fix manually. It's really poor for converting VB's "implicit type conversion", "globals" and many other common stuff!
As our client suggested, I used a commercial conversion tool, it's from vbconversions.net. This one was not as fool as the open source or freeware ones but it yielded a lot of errors too. One funny thing with this tool is that it horribly masses up name spaces and some function parameters (which are not of intrinsic type or has name space), and of course it fails handling VB's implicit conversions too.
After fixing thousands of errors for almost a week we finally got our project compiling! Then the final moment arrived, we wanted to run it! We did.. and (as to my expectation).. it crashed horribly!
After one more week of debugging and tracing down the almost untraceable, horrible and ugly crashes.. I almost began to loose patients!
But today, some horrible thread related bugs were solved dramatically.. and guess what.. finally .. we got what we wanted... we got it running today! The project loads and shows the 3D models the way it should do.. well, even though there are a lot of bugs we need smash!
When the project ran and gave me the same output of the VB.Net project, it was a beautiful thing to see and a very interesting moment. It made me really happy.. :)
Now, it gives a lot of inspiration and stamina to fix the rest of bugs. I'll have a formal QA first on this stage of the project and then start fixing. So rest of the bugs, be aware.. here I come.. :)
By the way, the client of the project I am working for is one of the leading game development companies in the world, everyone knows their name and it's interesting to work for them.
Subscribe to:
Posts (Atom)
Posts
