For information on how to use the API, please read the API information here.

New "Overview" page

Above is the new “Overview” page (you can experience it yourself by trying out the Bugify demo). The idea was to provide a brief overview of where you’re tracking both as an organisation, and as a user. We are pretty happy with it, and find it a vast improvement over the old “Overview” page.

To get the new “Overview” page, simply update your installation of Bugify, or if you don’t have it yet, download Bugify from bugify.com

/**
 * We need to use multiple touch events to handle a "tap" because
 * the google maps api doesn't natively support the touch event.
 */
//Prepare the overlay object so we can use its "fromContainerPixelToLatLng" method
var overlay = new google.maps.OverlayView();
overlay.draw = function() {};
overlay.setMap(this.map.map);

//Prepare the touch vars
this.touches = {
    startX  : 0,
    startY  : 0,
    currentX: 0,
    currentY: 0,
    reset   : function() {
        this.startX   = 0;
        this.startY   = 0;
        this.currentX = 0;
        this.currentY = 0;
    }
};

this.map.el.dom.addEventListener('touchstart', function(e) {
    /**
     * Only deal with single touches (not multi-touch) - when it is multi-touch,
     * the array of touches will have an item for each finger.
     */
    if (e.touches.length == 1) {
        //Remember that the user has started a touch
        this.touches.startX = this.touches.currentX = e.touches[0].clientX;
        this.touches.startY = this.touches.currentY = e.touches[0].clientY;
    }
});

this.map.el.dom.addEventListener('touchmove', function(e) {
    //Only track the current position if we know of the start position
    if (this.touches.startX > 0) {
        //Remember the current position of the finger
        this.touches.currentX = e.touches[0].clientX;
        this.touches.currentY = e.touches[0].clientY;
    }
});

this.map.el.dom.addEventListener('touchend', function(e) {
    //Only track the current position if we know of the start position
    if (this.touches.startX > 0) {
        //Make sure the user hasn't dragged their finger too much
        if (Math.abs(this.touches.currentX - this.touches.startX) < 4 && Math.abs(this.touches.currentY - this.touches.startY) < 4) {
            if (e.changedTouches && e.changedTouches.length > 0) {
                var touch = e.changedTouches[0];

                //Work out the coordinates on the map
                var x = (touch.pageX - this.map.el.dom.offsetParent.offsetLeft),
                    y = (touch.pageY - this.map.el.dom.offsetParent.offsetTop);

                var point  = new google.maps.Point(x, y),
                    latLng = overlay.getProjection().fromContainerPixelToLatLng(point);

                google.maps.event.trigger(this.map.map, 'tapped', {latLng: latLng});
            }
        }
    }

    //Reset the touches
    this.touches.reset();
});

//Allow click events also (for testing in desktop browser)
google.maps.event.addListener(this.map.map, 'click', function(e) {
    google.maps.event.trigger(this.map.map, 'tapped', {latLng: e.latLng});
});

google.maps.event.addListener(this.map.map, 'tapped', function(e) {
    //Add this point to the list of points
    this.routePoints.push({lat: e.latLng.lat(), lng: e.latLng.lng()});

    //Update the lines on the map
    this.displayRoute();

    //Calculate the distance etc
    this.calculateStats();

    //Save the current trip details (for page reloads)
    this.saveTrip();
});

The heart of the ga.js file is loading the __utm.gif image, with a number of parameters that Google then uses to generate your stats. Most websites just track page loads, but again, with a Sencha Touch (or any javascript-based app running locally) there is generally only one page load.

The best way to track usage with Google Analytics in a javascript-based app running locally – that I have found – is to use “events”. You must trigger these events for things that you want to track (e.g., in Sencha Touch you probably want to track the “cardswitch” event on your viewport). You can find more info about events with Google Analytics at http://code.google.com/apis/analytics/docs/tracking/eventTrackerGuide.html

It’s important to understand how “events” work with Google Analytics, so please read that page… now that you have read it, you need to know that you won’t be using the _trackEvent method. You don’t even need to include the ga.js script.

Back to how ga.js works for a moment: if you use _trackEvent on a normal website, every time you call it, another __utm.gif file will be loaded with the event parameters – that is how the event details get back to Google.

The way we can track events in a Sencha Touch app is to load the __utm.gif file with certain parameters. You can find the list of possible parameters at http://code.google.com/apis/analytics/docs/tracking/gaTrackingTroubleshooting.html (scroll down to the bottom of the page).

The way I have implemented event tracking in my apps is by queuing the events, then batch loading the __utm.gif file when it has either a maximum number of events in the queue, or after a set interval, or if the app was offline for a while, then when it comes back online it will process the queue. I have a simple-to-use method with 3 parameters (category, action, label – these are the main parameters for event tracking) that I call when I want to track another event.

Hopefully this brief intro into how you might implement event tracking gives you enough to create your own implementation. If you are having trouble tracking events in your Sencha Touch (or other js app) then let me know and I should be able to share some of my code with you.

Bugify is a simple PHP/SQLite (or MySQL) based issue tracker.  I have gone with SQLite as the default again (same as Inspectify) because it makes for a much easier installation process for everyone (but you can use MySQL if you prefer) – and performance is fantastic.  I’m very aware that there are already tons of issue tracking systems around, but the problem I found was that most of the good ones were hosted services – but I, along with many others, prefer to keep certain information out of the so called “cloud”.

I have used many different issue tracking systems before (both hosted and self-install) and from my experiences, I wanted something that met the following requirements (in no particular order):

• It has to look good – I spend a ton of time each day looking at issues, so I want it to look good.
• It has to be fast.
• It needs to have an API so I can get my data in and out.
• It must be self-hosted.
• It needs to be simple – a lot of issue trackers go overboard.

So, from there I came up with Bugify, and I think it’s pretty good.  Below are some of the other features that may make it into (or have already made it into) Bugify:

• Poll a mailbox for new issues.
• Detailed filtering.
• Save filters for easy access.
• Import from some other popular issue trackers (haven’t finalised which ones yet).

At this stage, I am using Bugify full-time, but it’s not ready to be released – there are a few features that haven’t yet been implemented.  But, I could use some testers if you’re interested (sign up at bugify.com).

Update: you can now play with a demo at demo.bugify.com.

Update 2: Bugify has been released. Find out more at bugify.com

“Seems like insane advice at first glance. I’m not sure many companies even understand why this would be a good idea, much less have the guts to attempt it. Raise your hand if where you work, someone deployed a daemon or service that randomly kills servers and processes in your server farm.”

via Jeff Atwood at Coding Horror

Cool!

The idea is that teams of developers want/need a simple way to ensure that their code gets reviewed by other people in their team (without having someone looking over your shoulder).  I think enough other people have talked about why we need code review (see below), but there hasn’t been a suitable, easy platform for doing it.

• https://www.owasp.org/index.php/Code_Review_Introduction
• http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html
• http://blog.nelhage.com/2010/06/i-hate-code-review/

There are a few hosted code review apps, but hopefully for commercial apps you have a policy to keep source-code in-house.  So we need an installable code review app, that automatically fetches commits from a repository, and provides a simple interface to do simple code review.

Inspectify is my answer to this problem.  It’s still a wee way off, but when it’s ready, you’ll be able to install it on a basic *nix box and start reviewing your Subversion-based code (support for other SCM’s may come later).

“Last week I wrote a piece called “Programmers: how to make the sysadmin love you“. The feedback has convinced me it needs a counterpart; something written from the perspective of the systems guy trying to get along with the dev team. Having offended all the programmers of the world (not to mention several Americans who don’t know what a fag packet is) it’s time to do the same for you systems folk.”

via mockyblog