I recently faced a tough technical problem at work. We had an issue with a custom MySQL plugin that provoked a crash during reboots. The problem was introduced with a major change in our build system and development environment. It was kind of a big deal and a great stopper for a couple of weeks, during which we didn't know the solution, not even if the solution was in our hands. We had a lot of work to rollback if we wouldn't find the cause of the problem, so a lot of people got nervous. But we finally found the solution: we introduced a bug in our build scripts (more details).
Once it was solved, QA people asked to have a reboot test in our regression suite to prevent similar problems in the future, and immediately put hands on to create the test and include it in our regression.
I found that to be a bad idea, it would make our regression take longer time. It is the test suite we use to validate every change to the codebase, and it is already quite bloated. We are struggling to keep its coverage but reduce the time it takes for it to run. It is a priority target to improve time for the feedback loop. And now we will have a single test case rebooting our system, which will take around 5-10 minutes more.
Then I thought why it took us that long to find the bug in the build scripts for MySQL plugins. We would have found the source of the problem much faster if we had checked for dynamic linkage dependencies in two versions of the plugin binary: one compiled using the former build scripts and the new one. But we did perform that check by visual inspection of ldd command output, and we had around 50 items in both lists that looked the same at first sight.
The thing is our plugin actually needed just 10 out of those 50 dynamic linkage dependencies, and it would have been far easier to locate the offending libraries in a list of 10 items. So there was a lot of noise in ldd output, which was preventing us to locate potencial errors. It's a similar situation as when you don't care about compiler warnings and your compilation output gets filled with hundreds or thousands of warning messages that no one ever reads. You will eventually face the situation of finding a bug after several days or weeks of debugging and testing and then realize that there was a warning message for the very same code line you changed to fix the bug.
So quality assurance (QA) is not just bloating your regression test suite with one more test case every time a new, unforeseen scenario pops up. QA is also keeping the house clean and quite so that there is little place for bugs to hide. And that, my friends, is something beyond the scope of testing.
Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts
2014/03/11
2013/12/09
The code protection smell
I like the concept of code smell. It recalls the idea of identifying something that you dislike, but cannot tell exactly why. You don't have a good reason, but just a feeling that it's wrong.
I recently found a new type of code smell at work. One of my colleagues - a highly skilled developer who I respect and enjoy working with -, told me he was taking a concrete design decision pursuing that other programmers could not later misuse it. He was implementing a C++ class hierarchy and he wanted to prevent others to freely instantiate objects using operator new.
We discussed technical options to achieve what he wanted but I had a weird feeling during the conversation. In the end I recommended him to discard the idea and simply don't implement what I then called a bad programmer protection. I call it simply code protection now. Second thoughts on the matter led me to identify a twofold kind of code smell.
First, it is a pure technical smell in the sense that you are writing code in order to implement what is not a business requirement. One may argue here that proper code formatting is not a business requirement but accepted to be good practice. Code readability might not be a business requirement itself, but it is important for maintainability, and that is (or should) always be a business requirement.
The other side of the smell is organisational. Even if you implement your design in a way that makes it hard for others to misuse it, you cannot prevent others to rewrite it in a way that protection gets nullified or just removed. So it is an indicator that you doubt about your co-workers capability and good judgement.
I recently found a new type of code smell at work. One of my colleagues - a highly skilled developer who I respect and enjoy working with -, told me he was taking a concrete design decision pursuing that other programmers could not later misuse it. He was implementing a C++ class hierarchy and he wanted to prevent others to freely instantiate objects using operator new.
We discussed technical options to achieve what he wanted but I had a weird feeling during the conversation. In the end I recommended him to discard the idea and simply don't implement what I then called a bad programmer protection. I call it simply code protection now. Second thoughts on the matter led me to identify a twofold kind of code smell.
First, it is a pure technical smell in the sense that you are writing code in order to implement what is not a business requirement. One may argue here that proper code formatting is not a business requirement but accepted to be good practice. Code readability might not be a business requirement itself, but it is important for maintainability, and that is (or should) always be a business requirement.
The other side of the smell is organisational. Even if you implement your design in a way that makes it hard for others to misuse it, you cannot prevent others to rewrite it in a way that protection gets nullified or just removed. So it is an indicator that you doubt about your co-workers capability and good judgement.
2011/10/10
Syntax Highlighting II
The first time I looked up for a method to include code snippets into my blog entries, I came up with a solution based upon using the service provided by the site tohtml.com. I blogged about it.
This approach had a couple of drawbacks:
Using this approach overcomes the first and third drawbacks. And the second is not a serious problem since now code snippets appear enclosed into a text box, so even if I would change the background to a dark color, snippets will still look good.
The only disadvantage is that I lose the possibility of highlighting parts of the code snippet (e.g. using a bold font or yellow marker style for just one line), but I certainly like it much more the way code snippets look in the blog now.
This approach had a couple of drawbacks:
- Highlighting is based upon HTML tags. Hence code edition is a cumbersome task since the easiest way to do it is to take te code snippet back to tohtml.com, edit it, generate the HTML code again and replace it in the post.
- The generated HTML code doesn't use CSS. So customizing it is hard and changing its style requires to generate the code again.
- The code snippet is part of the articles text so its width is limited. This affects readability and requires some custom line breaking.
Using this approach overcomes the first and third drawbacks. And the second is not a serious problem since now code snippets appear enclosed into a text box, so even if I would change the background to a dark color, snippets will still look good.
The only disadvantage is that I lose the possibility of highlighting parts of the code snippet (e.g. using a bold font or yellow marker style for just one line), but I certainly like it much more the way code snippets look in the blog now.
2011/05/07
Selecting the right key value for the Muenchian method
I have recently faced the problem of element grouping using XSLT. So I had to learn and understand what the Muenchian method is about, since it seems to be the de facto solution for grouping in XSLT due to its good performance (or the bad performance of alternate solution).
I had to transform a Subversion XML verbose log to get a list of changed files for a given issue. Here is a sample document:
One issue may comprise several SVN revision which could (and usually do) affect the same files. The file above illustrates this situation. A simple template matching the issue log entries and copying all the path nodes ends up with a list having repeated items.
The transformation used:
Transformation's result using 'ISSUE-2' as value for 'ticket' parameter:
So the Muenchian method solved the repeated items problem.
Transformation using Muenchian method to create just one entry for each path:
Transformation's result using 'ISSUE-2' as value for 'ticket' parameter:
No repeated items in list, right. But there are missing files! Adding some debugging code to the transformation showed that the missing files where those which also appeared in previous logentries for other issues in input file. This is pretty clear in this example, but when working with real data and an larger input file, it took me some hours to realize what was actually going on.
The expression generate-id() = generate-id(key('path-key', text())[1]) evaluates to false for this nodes, since first node with the same key is out of the nodeset to which template is applied
Muenchian method does not work so simply for grouping child nodes of nodes filtered out using a transformation parameter. So the first approach to solve the problem was to use two transformations and writting a short shell script to call xsltproc twice in a piped chain.
First transformation takes a ticket parameter and copies just the interesting log entries:
Second applies the Muenchian method to get just unique entries for affected paths in log entries:
Transformation's result using 'ISSUE-2' as value for 'ticket' parameter for the first transformation:
This approach worked perfect, but I kept thinking on a possible solution using a single transformation, and eventually found it using a different, slightly complex key. The problem was that the actual key that identified the unique entries I was using had to consider the ticket as well as the path.
Here is the transformation:
I had to transform a Subversion XML verbose log to get a list of changed files for a given issue. Here is a sample document:
One issue may comprise several SVN revision which could (and usually do) affect the same files. The file above illustrates this situation. A simple template matching the issue log entries and copying all the path nodes ends up with a list having repeated items.
The transformation used:
Transformation's result using 'ISSUE-2' as value for 'ticket' parameter:
So the Muenchian method solved the repeated items problem.
Transformation using Muenchian method to create just one entry for each path:
Transformation's result using 'ISSUE-2' as value for 'ticket' parameter:
No repeated items in list, right. But there are missing files! Adding some debugging code to the transformation showed that the missing files where those which also appeared in previous logentries for other issues in input file. This is pretty clear in this example, but when working with real data and an larger input file, it took me some hours to realize what was actually going on.
The expression generate-id() = generate-id(key('path-key', text())[1]) evaluates to false for this nodes, since first node with the same key is out of the nodeset to which template is applied
Muenchian method does not work so simply for grouping child nodes of nodes filtered out using a transformation parameter. So the first approach to solve the problem was to use two transformations and writting a short shell script to call xsltproc twice in a piped chain.
First transformation takes a ticket parameter and copies just the interesting log entries:
Second applies the Muenchian method to get just unique entries for affected paths in log entries:
Transformation's result using 'ISSUE-2' as value for 'ticket' parameter for the first transformation:
This approach worked perfect, but I kept thinking on a possible solution using a single transformation, and eventually found it using a different, slightly complex key. The problem was that the actual key that identified the unique entries I was using had to consider the ticket as well as the path.
Here is the transformation:
2011/02/01
Smoke Tests
I learned what Smoke Tests are. A software smoke test would be the test or set of tests that are made to the software system first after a new build to assure the program performs some basic actions so it is ready for some other more stressful testing.
I've been thinking about it. In some development projects I've been involved, the testing team did not have any smoke testing. But the development team did perform some basic testing before handing a new build to the testing team: just run the program and check it displays basic data in screen when feeding test input.
In a different project, the development included unit tests that where compiled and run together within the build process, making the build process fail if tests do fail. Not performing a smoke test suite on a new build is not a big deal when there is a good set of unit tests compiling and running together with the application build.
Unit testing lowers the probability of a fatal failure on a new build, but it doesn't cancel it at all.
Funny why the name for these tests:
I've been thinking about it. In some development projects I've been involved, the testing team did not have any smoke testing. But the development team did perform some basic testing before handing a new build to the testing team: just run the program and check it displays basic data in screen when feeding test input.
In a different project, the development included unit tests that where compiled and run together within the build process, making the build process fail if tests do fail. Not performing a smoke test suite on a new build is not a big deal when there is a good set of unit tests compiling and running together with the application build.
Unit testing lowers the probability of a fatal failure on a new build, but it doesn't cancel it at all.
Funny why the name for these tests:
The phrase smoke test comes from hardware testing. You plug in a new board and turn on the power. If you see smoke coming from the board, turn off the power. You don't have to do any more testing.
Kaner, Bach, and Pettichord. "Lessons Learned in Software Testing".
Wiley Computer Publishing, 2002, p. 95.
2011/01/20
Syntax highlighting
In my last post, I included some C++ code snippets. I always wondered how to provide syntax highlighting when posting some code, so a quick Google search for html syntax highlighting headed me towards tohtml.com.
It's a really useful and simple web app for the occasional code blogger, since I was afraid of the possibility that I would have to manually edit the blog's template CSS to achieve it.
It's a really useful and simple web app for the occasional code blogger, since I was afraid of the possibility that I would have to manually edit the blog's template CSS to achieve it.
2011/01/16
Loops on STL containers
C++ and STL are my everyday working tools. I have get used to use the same construction to iterate through the elements in an STL container:
I've seen most people use a for instead of a while loop:
I find the following reasons to prefer the first over the second option:
I've seen most people use a for instead of a while loop:
I find the following reasons to prefer the first over the second option:
- The statement for the for loop is too large and usually need to be split into 2 (ugly) or 3 (same as while) lines.
- In the while option, operations are performed on the variable Object instead of the iterator itElement, yielding a cleaner and more readable coding style. This becomes a greater advantage when the container is a map instead of a vector.
- If some elements must be removed from the container, the for loop is simply not an option, whereas the while option is the way to go.
2011/01/03
C++ exceptions
I've been updating some library code to add new functionality lately. This involved some refactoring and moving classes through namespaces.
So I've been thinking about a clean way to use and manage exceptions. I like the approach of libxml++: it is clean, simple and functional. But I find it hard to emulate this approach when writing my own libraries.
These are my guidelines for code design regarding exception handling:
So I've been thinking about a clean way to use and manage exceptions. I like the approach of libxml++: it is clean, simple and functional. But I find it hard to emulate this approach when writing my own libraries.
These are my guidelines for code design regarding exception handling:
- Define a general exception class deriving from std::exception for the whole library.
- Derive a new exception class for each class whose methods may throw exceptions. These are declared and defined in the same header and definition files as the class throwing them.
- Derive a new class for each specific error type.
- Avoid throwing exceptions defined for member classes: members are implementation details, so are the exceptions they throw.
- Avoid adding extra data to exceptions such as stack info, this should be managed by throwing a different type of exceptions.
2010/12/15
xmllint and xsltproc
I've been recently developing XSL transformations. I've been implementing C++ code to edit XML files using XPath values too.
I had previously used xsltproc, the command line utility distributed together with libxslt to test and debug my XSL transformations.
I have also used xmllint to validate hand-written XML files in order to be both well-formed and valid against a given DTD or XSchema.
But I recently discovered a wonderful xmllint feature: the --shell option. It runs an interactive shell that allows the user to navigate within the XML document as in a file system. But navigating is not the most useful feature I found for the shell option: it's the xpath command.
It allows to quickly check what node-set will be obtained when applying an XPath expression to a given XML input file.
It's a really useful utility when writing complex XPath expressions or checking out results for XPath expressions on complex documents.
I had previously used xsltproc, the command line utility distributed together with libxslt to test and debug my XSL transformations.
I have also used xmllint to validate hand-written XML files in order to be both well-formed and valid against a given DTD or XSchema.
But I recently discovered a wonderful xmllint feature: the --shell option. It runs an interactive shell that allows the user to navigate within the XML document as in a file system. But navigating is not the most useful feature I found for the shell option: it's the xpath command.
It allows to quickly check what node-set will be obtained when applying an XPath expression to a given XML input file.
It's a really useful utility when writing complex XPath expressions or checking out results for XPath expressions on complex documents.
2010/12/01
License Gadget
In the last post, I wrote down the reasons for my choice of a Creative Commons By-Nc license. This post is about the details on how I managed to place the license text in the blog.
I checked the Creative Commons site (CC) to look up license types and details and found out - as I was expecting - that the site offers the service to generate the HTML code to be inserted into a web page in order to display a license text and link to the Commons Deed provided by CC.
Once I had the code for the license I chose I googled for instructions on how to publish the license text into a Blogger blog. All the information I found was either staled (talking about setting options which are no longer available) or suggested to manually edit the blog template.
I checked the blog settings provided by Blogger and tried to paste the license HTML code into the text box left for customisation of the 'Attribution' blog footer section.
It turned out that text size limit does not admit to include the whole license code. So after experiencing a slight frustration feeling I figured out there might be a Google Gadget to display the blog license, since Blogger seems to set up the blog layout based on Gadgets.
I found none and thought that it might not be too hard to create one that just displayed the copy/pasted license HTML code. So I decided to create my first Google Gadget. I found all the information I needed at the Google gadgets.* API Developer's Guide.
My knowledge on HTML, CSS and Javascript was quite forgotten. It's never been too much anyway, I just learned the basics in college. So I had to check out a couple of online tutorials.
First and more surprising issue I encountered was that I couldn't get the Google Gadget Editor (GGE) to work properly on the Chromium browser! Somehow, weird invisible characters were being inserted/removed when I saved changes so the Gadget's XML code failed to be parsed. So after a while trying to figure out what was going on, I gave up and assuming my perplexity, I tried out Firefox and it worked perfect.
Then I had issues dealing with Javascript code errors, which are annoyingly silent for someone like me, since I'm used to work with compiled languages and have that really nice help that are compiler errors.
But after struggling with the new development environment (GGE), languages with which I'm not familiar, and a tough testing environment (Google Gadget Checker helped), I finally managed to get a basic Google Gadget that displayed a Creative Commons license text and links. The Gadget allows the user to chose the kind of CC license to display. You can see how it looks at the bottom of this page.
I have submitted it to the Google Gadgets directory and it might be available there at some point. Meanwhile, it can be included in any Blogger blog using this URL: http://hosting.gmodules.com/ig/gadgets/file/115386175924349751853/cc.xml.
You can also include it in any webpage (not necessarily a Blogger blog) clicking here.
I checked the Creative Commons site (CC) to look up license types and details and found out - as I was expecting - that the site offers the service to generate the HTML code to be inserted into a web page in order to display a license text and link to the Commons Deed provided by CC.
Once I had the code for the license I chose I googled for instructions on how to publish the license text into a Blogger blog. All the information I found was either staled (talking about setting options which are no longer available) or suggested to manually edit the blog template.
I checked the blog settings provided by Blogger and tried to paste the license HTML code into the text box left for customisation of the 'Attribution' blog footer section.
I found none and thought that it might not be too hard to create one that just displayed the copy/pasted license HTML code. So I decided to create my first Google Gadget. I found all the information I needed at the Google gadgets.* API Developer's Guide.
My knowledge on HTML, CSS and Javascript was quite forgotten. It's never been too much anyway, I just learned the basics in college. So I had to check out a couple of online tutorials.
First and more surprising issue I encountered was that I couldn't get the Google Gadget Editor (GGE) to work properly on the Chromium browser! Somehow, weird invisible characters were being inserted/removed when I saved changes so the Gadget's XML code failed to be parsed. So after a while trying to figure out what was going on, I gave up and assuming my perplexity, I tried out Firefox and it worked perfect.
Then I had issues dealing with Javascript code errors, which are annoyingly silent for someone like me, since I'm used to work with compiled languages and have that really nice help that are compiler errors.
But after struggling with the new development environment (GGE), languages with which I'm not familiar, and a tough testing environment (Google Gadget Checker helped), I finally managed to get a basic Google Gadget that displayed a Creative Commons license text and links. The Gadget allows the user to chose the kind of CC license to display. You can see how it looks at the bottom of this page.
I have submitted it to the Google Gadgets directory and it might be available there at some point. Meanwhile, it can be included in any Blogger blog using this URL: http://hosting.gmodules.com/ig/gadgets/file/115386175924349751853/cc.xml.
You can also include it in any webpage (not necessarily a Blogger blog) clicking here.
Subscribe to:
Posts (Atom)