Hi.
Júlio Neves wrote a shell script that draws a Christmas Tree decorated with Christmas lights.
He wishes "muito suSHELLso em 2009" that means in a free translation "much sucSHELLcess in 2009".
It is very funny. I hope you like it.
You can see the source code here: http://www.dicas-l.com.br/cantinhodoshell/cantinhodoshell_20081222.php.
Merry Christmas to Everyone.
Note: The site is written in Brazilian Portuguese, but you can just pick the code.
terça-feira, dezembro 23, 2008
quinta-feira, dezembro 04, 2008
I am not afraid anymore
Have you ever been afraid of changing some code? Even one that you've developed?
I have. Many times. Why this happened to me? Well, that is because I could not be 100% confident that my changes would not break any other part of the program.
My life changed when I learned the Test Driven Development methodology (aka TDD).
The idea behind TDD is that you must write automated tests before writing your code. This methodology will not only help you design better software by catching bugs at the same time you are coding, but (IMHO) it is also a great way to assure your code will keep working after maintenances.
Managers love to say they want you to deliver fully tested software. They even say that TDD is a wonderful idea. But things change when you need to fix a bug or insert new features into a product that do not have automated tests. At this moment, managers complain that there is no time to let you write a test suite to cover the entire software.
To be totally honest we need to agree that being able to fix problems and / or insert new features into your company's products in a timely manner is essential in the global market competition.
- I can not write an entire test suite to the program, and take the risk to not deliver it in a time it must be delivered. And if I do not write tests how can I assure that everything will keep working after I put my hands in it?
In this case I write tests to the part of the software that I will alter. Moreover, whenever I have a bug to fix I write tests to fully cover that part I'm working on.
Yes, I know that to be considered effective, tests must cover 100% of the program, but you must have a fresh view about it:
This approach significantly reduces the number of tests I should write to be able to check if my changes did not affect anything else. So, it will take less time and effort than the ideal situation (which my manager probably would not allow let me to do).
I will be able to write them little by little, during my development activities. The product did not have any test at all so if I write a little number of tests each time that I am working on it is better than nothing.
What you think? Is my approach good? I would like to listen to your opinion.
I have. Many times. Why this happened to me? Well, that is because I could not be 100% confident that my changes would not break any other part of the program.
My life changed when I learned the Test Driven Development methodology (aka TDD).
The idea behind TDD is that you must write automated tests before writing your code. This methodology will not only help you design better software by catching bugs at the same time you are coding, but (IMHO) it is also a great way to assure your code will keep working after maintenances.
Managers love to say they want you to deliver fully tested software. They even say that TDD is a wonderful idea. But things change when you need to fix a bug or insert new features into a product that do not have automated tests. At this moment, managers complain that there is no time to let you write a test suite to cover the entire software.
To be totally honest we need to agree that being able to fix problems and / or insert new features into your company's products in a timely manner is essential in the global market competition.
- I can not write an entire test suite to the program, and take the risk to not deliver it in a time it must be delivered. And if I do not write tests how can I assure that everything will keep working after I put my hands in it?
In this case I write tests to the part of the software that I will alter. Moreover, whenever I have a bug to fix I write tests to fully cover that part I'm working on.
Yes, I know that to be considered effective, tests must cover 100% of the program, but you must have a fresh view about it:
This approach significantly reduces the number of tests I should write to be able to check if my changes did not affect anything else. So, it will take less time and effort than the ideal situation (which my manager probably would not allow let me to do).
I will be able to write them little by little, during my development activities. The product did not have any test at all so if I write a little number of tests each time that I am working on it is better than nothing.
What you think? Is my approach good? I would like to listen to your opinion.
Assinar:
Postagens (Atom)