For more details on the conference consult the web page.
Free entrance
See you there!
Thursday, December 10, 2009
BLUG*OS*CON - 12 December 2009
We like to welcome you to BLUG*OS*CON, a Linux/FLOSS conference that will take place at the Politehnica University of Bucharest (AN010 lecture room), starting at 10 AM(EET), on the 12th of December 2009.
For more details on the conference consult the web page.
Free entrance
See you there!
For more details on the conference consult the web page.
Free entrance
See you there!
Friday, November 20, 2009
Romanians, go out and vote! You have no excuse!
Advices:
Don't complain that nothing can be done!
Don't say that everything is lost!
Participate actively to a decision!
Be reconciled that you did everything you could do!
Don't criticise things you weren't involved in!
Document yourself before making a decision!
Be responsible!
[Most Romanian people agree with all the statements above when it comes to daily activities ... but not voting]
Voting is once 4/5 years. It takes less than 15 minutes. Make the effort and consider it as part of your responsability. Be responsible. It is not a big effort, but a decision can influence your life. It is probably more important than most of the things you do on a daily basis.
Go and vote! Express you opinion, no matter what you opinion is! Because your opinion counts, no matter how insignificant you think it is!
Please, go and vote! The rest is irrelevant.
Don't complain that nothing can be done!
Don't say that everything is lost!
Participate actively to a decision!
Be reconciled that you did everything you could do!
Don't criticise things you weren't involved in!
Document yourself before making a decision!
Be responsible!
[Most Romanian people agree with all the statements above when it comes to daily activities ... but not voting]
Voting is once 4/5 years. It takes less than 15 minutes. Make the effort and consider it as part of your responsability. Be responsible. It is not a big effort, but a decision can influence your life. It is probably more important than most of the things you do on a daily basis.
Go and vote! Express you opinion, no matter what you opinion is! Because your opinion counts, no matter how insignificant you think it is!
Please, go and vote! The rest is irrelevant.
Thursday, October 29, 2009
Unit tests - how not to do it
While at work I found myself in the situation of making some manually written unit-tests to work with a new version of software. Beside the fact that the tests were manually written they were written also without using any framework like cunit/cppunit/cpptest ... [I'm talking about c++ code] (yes it is stupid but wait ... there's more).
After I finished this task I saw that:
- some function changed its body but the functionality was the same
- the function's prototype was the same
This means that tests for that particular function need no modification in order to be run - which was correct.
The dilemma:
- tests for the previous version of function passed
- the same tests didn't pass this time although it was clearly that the function did *the same thing* (had the same functionality)
Why?
The test actually consisted in *also* couting the number of calls to several procedures invoked by the tested function (by stub-ing those invoked procedures and using some barbarian global variables).
You guessed it - the updated function made more/less calls to those stub-ed procedures, scrambling this way the number of calls expected.
Conclusions:
People confuse "unit testing" with "code coverage". Unit testing refers to the logic of the functions, *not* what procedures it calls or what parts of the code are run. That is another measure in testing called "code coverage".
The fact that usually the software helping you making tests also provides tools for showing the "code coverage" is not an excuse for this confusion; "code coverage" has nothing to do with "unit testing".
As a general rule: when you change/optimize a function's algorithm without affecting the functionality and the prototype is the same -> unit tests that previously worked *should* work with the new procedure.
Is it more important just to deliver something, instead of delivering something good? Where is the respect for the customer?
After I finished this task I saw that:
- some function changed its body but the functionality was the same
- the function's prototype was the same
This means that tests for that particular function need no modification in order to be run - which was correct.
The dilemma:
- tests for the previous version of function passed
- the same tests didn't pass this time although it was clearly that the function did *the same thing* (had the same functionality)
Why?
The test actually consisted in *also* couting the number of calls to several procedures invoked by the tested function (by stub-ing those invoked procedures and using some barbarian global variables).
You guessed it - the updated function made more/less calls to those stub-ed procedures, scrambling this way the number of calls expected.
Conclusions:
People confuse "unit testing" with "code coverage". Unit testing refers to the logic of the functions, *not* what procedures it calls or what parts of the code are run. That is another measure in testing called "code coverage".
The fact that usually the software helping you making tests also provides tools for showing the "code coverage" is not an excuse for this confusion; "code coverage" has nothing to do with "unit testing".
As a general rule: when you change/optimize a function's algorithm without affecting the functionality and the prototype is the same -> unit tests that previously worked *should* work with the new procedure.
Is it more important just to deliver something, instead of delivering something good? Where is the respect for the customer?
Monday, October 26, 2009
Evolution
For as long as I know I always wanted to make things work well. Even if it was a small plug that needed some new wires and isolation, or some stuff related to plumbing I always tried my best to make it as good as possible. And most of the time I succeeded. I always thought that this is a good way to evolve.
Now I'm an software engineer and my basic way of thinking is not too different from the one I had before, which I consider to be a good thing.
What happens when I'm somehow forced to choose a solution that does not satisfy me, that is recognized not to be a (very?) good choice, but it is the only one given the constraints (time being the no. 1 constraint most of the time)?
I know that compromises have to be made but given the fact that I develop software for safety critical equipments [public transportation to be more precise] I consider these kind of compromises trully life threatening. Since when time-to-market is more important than human life?
Is it that money rule everything and people just don't care enough about anything else?
I accept that I'm payed for doing that job and that's it, but there is some part of me telling that I can/should do more.
I may be exagerating or software engineering is not the choice that I should've made. Time will tell.
Now I'm an software engineer and my basic way of thinking is not too different from the one I had before, which I consider to be a good thing.
What happens when I'm somehow forced to choose a solution that does not satisfy me, that is recognized not to be a (very?) good choice, but it is the only one given the constraints (time being the no. 1 constraint most of the time)?
I know that compromises have to be made but given the fact that I develop software for safety critical equipments [public transportation to be more precise] I consider these kind of compromises trully life threatening. Since when time-to-market is more important than human life?
Is it that money rule everything and people just don't care enough about anything else?
I accept that I'm payed for doing that job and that's it, but there is some part of me telling that I can/should do more.
I may be exagerating or software engineering is not the choice that I should've made. Time will tell.
Subscribe to:
Posts (Atom)