Hi everyone,
This seems oddly specific. If you've tried using the DateAxisRenderer in jqPlot with a single data point, or multiple data points with the same y value, you might have found yourself stuck with a browser crash.
For example, see this question on stackoverflow or the issue tracker.
Well, the problem has a partial fix which is now in the codebase. I believe there are still some cases where there might be a problem so it's being worked on.
Until its released, you can incorporate the changes into dateAxisRenderer.js by copying them from here.
Showing posts with label bug tracking. Show all posts
Showing posts with label bug tracking. Show all posts
Saturday, February 11, 2012
Monday, January 23, 2012
Finally getting around to more JavaScript
Hello everyone,
Well, as part of my senior design class for computer science, we are assigned teams of four and each team gets a different project. Our project looks like it will involve a lot of JavaScript. This is good, because I am a fan of JavaScript and don't know it nearly as much as I would like. Also, I'm sick of every class project being in Java (not because I hate Java, just because I'd like to see some variety). Anyway, we're going to be doing a few small web applications that will be using a Java backend (!). Luckily, most of the interesting stuff will be client side.
I took it upon myself to set up everyone's favorite tools like Jenkins. I also had to search out a bug tracker to install. I haven't installed a bug tracker before and I have to say, some of them are a real pain to install and have a lot of dependencies. So after trying out some popular ones and disliking the setup process, I went with one called YouTrack.
I like YouTrack because installing it consists of me deploying it on Tomcat (after the install program), and I'm a big fan of doing as little as possible. I haven't worked with it that much yet but so far it seems simple enough. So if you're looking for a bug tracker with a simple setup and running a windows server, go ahead and give it a try.
(disclaimer: I don't work for them!)
See you next time.
Well, as part of my senior design class for computer science, we are assigned teams of four and each team gets a different project. Our project looks like it will involve a lot of JavaScript. This is good, because I am a fan of JavaScript and don't know it nearly as much as I would like. Also, I'm sick of every class project being in Java (not because I hate Java, just because I'd like to see some variety). Anyway, we're going to be doing a few small web applications that will be using a Java backend (!). Luckily, most of the interesting stuff will be client side.
I took it upon myself to set up everyone's favorite tools like Jenkins. I also had to search out a bug tracker to install. I haven't installed a bug tracker before and I have to say, some of them are a real pain to install and have a lot of dependencies. So after trying out some popular ones and disliking the setup process, I went with one called YouTrack.
I like YouTrack because installing it consists of me deploying it on Tomcat (after the install program), and I'm a big fan of doing as little as possible. I haven't worked with it that much yet but so far it seems simple enough. So if you're looking for a bug tracker with a simple setup and running a windows server, go ahead and give it a try.
(disclaimer: I don't work for them!)
See you next time.
Wednesday, November 30, 2011
Use screencasts for your bug reports
Note: So finals are about to start, you might not see me for awhile.
Anyway,
On the project I'm on now, we're working directly with the client (the owner of a local business) on a web application. We took over the project from another company working on it and started with some bug fixes. In my experience the most difficult part of tracking and killing bugs reported by someone else is simply reproducing them.
Let's take a look at a bug report style you might have encountered (I certainly have):
Alright, this is actually a good one because at least they stuck a screenshot on it and they were nice enough to enumerate the steps they had taken (as opposed to "it just crashed").
Now you've just taken the project and you have no idea how the code works. So you try and reproduce it, but the SaveLotsOfMoney button works fine for you. Oops?
Turns out the actual problem was that during previous testing the reporter did something unrelated, data was changed, and the guy before you forgot to do a null check and now the browser has exploded. It doesn't happen for you because you're making your tests reproducible (of course).
How do you prevent this? Make them do it again? Now they can't reproduce it! They didn't know that what they did previously affected that test, because it's not their job to know the details, so of course they don't include it in their bug report.
The solution to this that our current client uses is to make screencasts of the bug in action. This is very important, because it means you can see everything that they were doing that caused the bug. It can vary, and in my case it was a detailed error message (a "foreign key violation -- big help") that was shown. In another case I was able to see signs of data they had previously changed, which led to reproducing it.
So: don't use those old crusty bug reporting methods, try making screencasts of them instead. The client mentioned uses a tool called Jing (disclaimer: I don't work for them) to record their screencasts and it looks good to me, though I have no personal experience with it.
Anyway,
On the project I'm on now, we're working directly with the client (the owner of a local business) on a web application. We took over the project from another company working on it and started with some bug fixes. In my experience the most difficult part of tracking and killing bugs reported by someone else is simply reproducing them.
Let's take a look at a bug report style you might have encountered (I certainly have):
Bug: Clicking on the SaveLotsOfMoney button causes the browser to explode
Login as Jim
Click "SaveLotsOfMoney" button
"Server error" is displayed right before the browser explodes and crashes
Attached: a screenshot of the browser exploding.
Alright, this is actually a good one because at least they stuck a screenshot on it and they were nice enough to enumerate the steps they had taken (as opposed to "it just crashed").
Now you've just taken the project and you have no idea how the code works. So you try and reproduce it, but the SaveLotsOfMoney button works fine for you. Oops?
Turns out the actual problem was that during previous testing the reporter did something unrelated, data was changed, and the guy before you forgot to do a null check and now the browser has exploded. It doesn't happen for you because you're making your tests reproducible (of course).
How do you prevent this? Make them do it again? Now they can't reproduce it! They didn't know that what they did previously affected that test, because it's not their job to know the details, so of course they don't include it in their bug report.
The solution to this that our current client uses is to make screencasts of the bug in action. This is very important, because it means you can see everything that they were doing that caused the bug. It can vary, and in my case it was a detailed error message (a "foreign key violation -- big help") that was shown. In another case I was able to see signs of data they had previously changed, which led to reproducing it.
So: don't use those old crusty bug reporting methods, try making screencasts of them instead. The client mentioned uses a tool called Jing (disclaimer: I don't work for them) to record their screencasts and it looks good to me, though I have no personal experience with it.
Subscribe to:
Posts (Atom)