I held a presentation at AS2010 about handling defects. The slides are up, unfortunately there is not text in the slides and there’s no audio track… but for those who wish to see my slides you can find the at:
With the success we had with EQATEC Analytics at RemoteX I started looking around for something similar, but for JavaScript. I didn’t find anything that satisfied my needs.
Thus I created my own error collecting and analysis tool, and named it JS-Analytics.
You use it similar to how you use Google Analytics, you add a few given script tags to your website and JS-Analytics will try to collect any unhandled JavaScript error that occurs, and send information about it back to JS-Analytics website.
JS-Analytics uses a combination of window events to collect errors. These events aren’t available on all browsers so JS-Analytics will use JQuery to provide cross browser support. This means that cross browser support is only available for JQuery code.
For more information about how it works I recommend this page.
Right now this JS-Analytics provides just some basic analysis. But I felt that it was better to announce it and hopefully get some feedback on it, than to carry on without any feedback.
I was working on performance tuning for the mobile client of RemoteX Applications when I found a tool called EQATEC Analytics. Six month later I added it to our clients for the first time.
EQATEC Analytics is quite interesting, for RemoteX it solves an interesting issue. Error reports are hard to collect from Compact Framework devices, especially since all error messages state that “we’re missing the translation pack to translate these errors, thus you get this crappy errors message instead”.
EQATEC Analytics captures all unhandled exceptions and report them back to a server application for analysis. This means that all crashes are reported so they can be analyzed by us, without involving the user in the information collection process. (no personal information is sent to the server)
The benefits of this enormous. We can see the quality trends of our applications (at least when it comes to crashes), and fix the errors that occur the most.
Traditionally the errors are fixed based on the information received by customers, manual error reports and what not. Relying on this type of information means that you fix the errors that most people report, or the errors you can reproduce. With EQATEC Analytics you, you can get an exact stack trace indicating the problem area, and depending on how you configure it to work you can also request information regarding what was happening during the crash.,
It also provides an excellent way to see if our efforts of improving the quality of the product is helping or not.
Now it also has features to collect information about what kind of system our applications are run on, and also collect statistics of which features are used in the applications.
We’ve used EQATEC Analytics in production since January 2010 and so far we are very happy with the results.
An interesting note here is that the next version of Shuffle will use a similar tool for Android, called Flurry.
I’m re-installing my environment, while doing so I’m fixing a few things I’ve been missing in my environment.
Running tests using Python is really fast, so I wanted to add something like Autospec but for my tests. So I did the following:
I was browsing around the issue lists on Google AppEngine, just some midnight light reading before going to bed…
I stumbled on the following issue, marked as critical:
http://code.google.com/p/googleappengine/issues/detail?id=1970
What’s interesting about it is that this is also what is causing all the problems with running Grails development on Windows machines. If this is fixed, then building Grails for GAE on Windows machines might work without any workarounds. Lets hope the Critical focus remains on this issue, and that it is resolved.
I’ve been playing around with the website grader by hubspot (nice toy), and there is one thing I never quite understood. That is the reason to list a site in the directory service DMOZ or similar directories. I mean how often do you go there and check for new interesting sites?
I spent some time looking at Yahoo’s Site Explorer, configuring my Morkeleb.com so that the siteindex.xml is published to Yahoo every time I update the post. From there I found a link explaining the reason.
Yahoo’s search engine wont index you if your not in DMOZ (or at least reduces the chance unless your not registered). Yahoo has their own directory service as well, that one costs 300 dollar per year. I hope they add the site to the index if you subscribe to their directory.
Looks like I signed up on Twitter just now, my account name is: “anshrak” if you wish to follow me. Top reasons, more playtime with my phone, cant sleep, and someone said I should.
Reasons I’ve been avoiding Twitter thus far?
Fear of Information overload. Since I have a limited amount of time to handle all the information I process, I’m selective in which information I subscribe too.
I also installed live writer to give it a test run, we’ll see how it goes.
Today they released a new version of the SDK for Google AppEngine.
Personally I’m very excited about the ability to recieve email.
Here is a link to the Java release notes. The blog post at Google only links to the python release notes.
http://code.google.com/p/googleappengine/wiki/SdkForJavaReleaseNotes
Roughly 1½ year ago I produce a plugin for team-system to allow me to report bugs quickly though as I’m working with the code. The idea behind it was from the Fogbugz intoruction video where I think its Joel Spolsky who says something along the lines of “it should take less than 30 seconds to report a bug, else the lazy developer wont do it.”
The resulting plugin was a short-command that started up a UI with a single textbox on it. I wrote the “bug”, and it created an bug item in Team System with my specified title. It also made sure to “record” the context of where I was in the code when I wrote the item. In this case, file and line-number.
In a previous post I discussed how to get things done with teams.
Consider having such a plugin to your IDE that will report the item generated to a central inbox, central for all developers. The item could be a bug, it could also be a suggestion for refactoring, request for more tests, idea for a new feature and much much more.
With such tooling in place, a team could quickly shed some light on issues that aren’t directly related for the delivery of the current iteration. But more related on the values of the team or the ongoing quality of the code product. The issues can be reviewed and managed during a weekly meeting, resulting in product backlog items, sprint backlog items, discussions, meetings. Or just a sense of common values within the team.
With this concept of quickly creating new tasks and with the GTD and How I work with code ideas. An idea for a new tool popped up in my head.
The tasks that I create based on working code, are cluttered with my own opinions. With the Getting Things Done approach we could have an inbox with Action times created as team members work with the code. In a Weekly review each item in the Inbox could be manage, prioritized, discussed. Some items result in items on a sprint backlog, others simply result in other team members explaining parts of the system to each other.
This weekly review could be conducted outside the normal delivery cycles, as they are partially meta tasks for achieving a common mindset of how and what should be developed. The result could be new features, refactoring, extra testing, reduced bugs etc.
