Archive for the ‘jsErrLog’ Category

Keeping a-head in the clouds

November 19, 2013

One of the great things about developing on today’s cloud platforms is elastic computing. You never know what the peaks are going to look like, but you don’t want to pay for hardware you’ll only use once in a blue moon. So you opt for a dynamically adaptive scalable solution.

If you’re read any of my posts about jsErrLog (or “jsErrLog posts” if it’s still down) you’ll know that’s what I did for that service. As I’m offering it for free to anyone with a reasonable load I needed something as cost effective as possible (ie free!). When I built it I looked at Windows Azure, Amazon’s EC2, a few smaller options, Virtual Private Servers and finally settled on Google AppEngine – in common with the others it offered a number of options for programming languages and data storage but the big bonus was a no-nonsense the free tier.

Sometimes however things don’t go quite as planned…

(more…)

jsErrLog: now alerts via XMPP

June 13, 2011

Although it’s nice to know that the jsErrLog service is sitting there recording errors that your users are seeing it does put the onus on developers to remember to check the report page for their URL to see if there have been any issues.

To make things a little more pro-active registered users can now connect to an XMPP (Google Chat) client (eg Digsby) and every time there’s a new error reported the bot will send you an alert.

Because you might get a flurry of messages if you deploy a version and there’s an error, or a 3rd party component has a problem the bot also listens to a set of messages so it’s easy to suspect the alerting (or turn it back on when the problem has been fixed).

At the moment there a few restrictions:

·         alerts have to match a specific URL

·         for a given user all alerts are turned off/on (no per URL granularity)

·         alerting is only available to users who’ve made a donation or promoted jsErrLog

The reason for the first one is a limitation with the way AppEngine lets me query data (unlike SQL the GQL query language does not support the CONTAINS or LIKE verbs)… I’m looking for a solution to that

The second is a feature that I plan to add soon depending on demand.

The third… at the moment it takes a little bit of setup to add new users so I’m adding it as the first freemium feature though this may change. If you want that enabled please let me know the URL you are monitoring and your Google Chat ID and I’ll let you know what else you need to do to enable it…

jsErrLog – now with XML

June 9, 2011

To help analyze data from jsErrLog – my Javascript Error Log service – I added a new feature today: An XML data feed for reports.

You can access a report as normal and view it in the browser, eg the sample report and on there you will now see a direct link to the XML version of the report.

If you know the name of the URL you want to report against then you simple access it via http://jserrlog.appspot.com/report.xml?sn=http://blog.offbeatmammal.com where the parameter after the sn is the URL you want to query.

Image001

Both the report and the XML show up to the last 500 results for the URL. I plan to add limits to the XML feed, and pagination to the HTML report in a future release (let me know in the comments what’s more important, and any other requests). I would like to implement a full OData feed for the data but haven’t found a good Python / App Engine sample out there yet…

One great thing about having the data available as an XML source is that you can add it as a Data Source in Excel and from there filter and sort to your hearts content

Image002

update: New version of the Javascript debugger

March 18, 2011

Although jsErrLog, my “Web Watson” has only been out a couple of days I had a great suggestion to let developers add some additional context to errors that are being trapped.

To support this I’ve added a new parameter jsErrLog.info that’s a string variable you can update at any time (after the library has been registered on your page of course) and the first 512 characters simply get passed through to the report database.

To use this new feature simply add a line that updates what you want passed through with the data you want passed and if the error handler gets called then the data will be transferred to the database

jsErrLog.info = “Populated the Info Message to pass to logger”;

Any other features you think are worth adding?

Watson for the web – trapping Javascript errors

March 16, 2011

A while ago I wrote a small piece of JavaScript code that I needed to be able to integrate into lots of different sites to help streamline the Silverlight experience, but it was important that I didn’t break anyone’s existing code.

While we did extensive testing with the partners before we deployed it there was always the worry that a combination of browser and OS and plug-in we’d not tested would cause a problem we’d not foreseen.

As websites get more complex, and HTML5 brings more of the heavy lifting back to rely on JavaScript to build really dynamic experiences so my little nagging concern was just going to keep on getting bigger.

While you can wrap every statement in a Try…Catch loop and deal with exceptions that way it’s not the most efficient, and if you’re integrating libraries from a  lot of different sources then it’s not really practical.

As luck would have it two of the browsers had already implemented the key to the solution… the humble JavaScript window.onError function. In IE and Firefox it allowed you to attach an event handler that would kick in whenever an un-trapped error occurred and allow you do to whatever you needed to manage the problem.

I took that functionality and build a small script that could be injected via a single line of JavaScript into the page you want to monitor that would catch any unhandled error condition and report back to a remote cloud service the script, the error, the browser and OS versions so a developer could quickly and easily re-create the test scenarios. The code is available at jsErrLog.

Then because Chrome, Safari and Opera didn’t support the onError function I rather shelved the project. Just a few days though with the release of Chrome v10 another browser could be added to the support matrix for remote error reporting (and as the fix is in the WebKit core we can only hope that a release of Safari greater than v5 will roll out support as well)

While I wait for Safari and hopefully Opera to catch up with this I’m making a couple of other small tweaks to the code to make it a bit more reliable, as well as adding some extra functionality to allow developers to pass additional information back to the reporting database to help with debugging their specific apps.

Check it out , kick the tires and let me know if you have any feedback…