Patrick Crosby's Internet Presents

JavaScript Error Logging Service using Go and jsErrLog

2014-03-28T00:00:00+07:00

In a “standard” web application where nearly all the work is done on the server, it’s fairly straightforward to track errors. They happen on your servers, you can log them, you can send emails when they happen, whatever you want.

But with web apps where more and more of the functionality is in client-side JavaScript, the errors on the server disappear. The app developers have no idea they are happening unless users notify them.

It’s no surprise that there are a lot of services to help with this problem. Paul Irish compiled a list of some of them. Some only do JavaScript errors, some track all kinds of errors, some are based on window.onerror, some on catching exceptions.

I wanted something simple to start. I just want to know that an error occurred. While a stack trace would be nice, right now I’m ok without it. So I’m trying out jsErrLog. It binds a function to window.onerror and sends any error information to a web service. There is a free service you can use that’s running on AppEngine, but I chose to send the data to our servers. All the window.onerror solutions can only send the URL, file, line number, error message, and some newer browsers include the column number.

I wrote a small web service to receive the data from the jsErrLog script. I had a few requirements for it: send errors periodically via email, don’t store them anywhere else, don’t send duplicates, don’t use too much memory.

Here’s the structure that holds the data from jsErrLog:

type entry struct {
        url      string
        filename string
        line     string
        col      string
        errmsg   string
}

There’s a map that uses the entry struct as a key. You could change the bool to an int if you care about how many times an error occurred. I’m using a sync.RWMutex to protect the map.

var dedupe map[entry]bool
var lock sync.RWMutex

The init function creates the initial map and starts the dump goroutine.

func init() {
        dedupe = make(map[entry]bool)
        go dump()
}

The request handler function:

func ErrLog(w http.ResponseWriter, r *http.Request, s *bingo.Session) {

It starts by getting the form values into an entry:

        var e entry
        id := r.FormValue("i")
        e.url = r.FormValue("sn")
        e.filename = r.FormValue("fl")
        e.line = r.FormValue("ln")
        e.col = r.FormValue("cn")
        e.errmsg = r.FormValue("err")

Then it checks to see if it already has this error. It read-locks the mutex before the check.

        lock.RLock()
        _, exists := dedupe[e]
        lock.RUnlock()

If it doesn’t exist, it write-locks the mutex and puts the error info in the map. It checks to make sure there aren’t too many elements already in the map as a safeguard.

        if !exists {
                lock.Lock()
                if len(dedupe) < 1000 {
                    dedupe[e] = true
                }
                lock.Unlock()
        }

The jsErrLog script wants JavaScript returned to it, including a special call to remove a script that it inserts.

        w.Header().Set("Content-Type", "text/javascript")
        fmt.Fprintf(w, "jsErrLog.removeScript(%s);", id)
}

Finally, the dump function just loops forever. It sleeps for five minutes, then checks to see if there’s anything in the dedupe map. If there is, it emails it to a system account and clears the map.

func dump() {
        for {
                time.Sleep(5 * time.Minute)
                lock.Lock()
                if len(dedupe) > 0 {
                        sendmail()
                        dedupe = make(map[entry]bool)
                }
                lock.Unlock()
        }
}

It’s pretty simple, but it does everything we want. If we need stack traces, we’ll give Airbrake a try.

Responsive SVG

2014-03-26T00:00:00+07:00

Many of the charts on StatHat are changing from server-rendered PNGs to browser-rendered SVGs. There are a lot of reasons for this, but one is that we’d like the charts to be more responsive to different screen sizes and retina displays.

Since SVG stands for Scalable Vector Graphics, it should be a piece of cake to scale them. If you just put an svg with a width and height in an HTML page:

<body>
<svg width="940" height="280">......</svg>
</body>

and resize your browser, it will always stay at 940x280 pixels.

Remove the width and height and use viewBox and preserveAspectRatio:

<body>
<svg viewBox="0 0 940 280" preserveAspectRation="xMinYMin meet">......</svg>
</body>

Now you can resize your browser, look at the page on any device, and it will fill the browser window, the lines will be nice clean vectors.

There’s just one issue. For some reason, the svg element is square. So anything that you’d like to put after the svg is pushed way down the page. A CSS trick that I found on Dudley Storey’s blog solves this issue.

Add a container div, and a class for the svg:

<body>
<div class="svg-container">
  <svg viewBox="0 0 940 280" preserveAspectRation="xMinYMin meet" class="svg-content">......</svg>
</div>
</body>

The CSS that fixes it all up:

.svg-container {
    display: inline-block;
    position: relative;
    width: 100%;
    padding-bottom: 30%;
    vertical-align: middle;
    overflow: hidden;
}

.svg-content {
    display: inline-block;
    position: absolute;
    top: 0;
    left: 0;
}

The tricky thing is that you need to set the padding-bottom of the container to the aspect ratio of the SVG element. In this case it’s (280 / 940) * 100, which is just about 30%. So if you have SVG elements with different aspect ratios, you would need a class for each one with the padding-bottom value adjusted accordingly. All the charts on StatHat have the same aspect ratio, so this wasn’t an issue.

View an example chart

I really like this solution. It’s simple, there’s no JavaScript required. Unfortunately, due to the interactive features of the StatHat charts, we’re going to have to do more and use JS to update certain UI elements. Also, the resizing of the text in this solution makes it difficult to read the axes on small screens.

syntax off

2014-03-25T00:00:00+07:00

As an experiment, I turned off syntax highlighting a week ago. Now it seems weird to see it.

With syntax highlighting on, my eyes focus on the highlighted text: keywords, strings, numbers, built-in types and functions, and comments. The types I create aren’t highlighted. My function names get no special treatment. Visually, you have to fight through the colors to get to your own code.

An argument for syntax highlighting would be that it helps you find errors while you are editing. The errors that it might make more clear, however, are basically typos. There are so many tools that continuously build, format, lint, and test your code that any of those errors can be caught immediately by tools that know the language.

Syntax highlighters often make mistakes. They are not language parsers. For example, string is a perfectly valid function name in Go. Yet it is highlighted differently than timestwo in this example:

Without syntax highlighting, I find code more readable. We don’t read books or articles with different colored words, why is code different? But I could be weird: I still print out code on paper sometimes to really read it and analyze it.

401 vs. 403

2014-03-24T00:00:00+07:00

In a “standard” web application, if a user requests a page and their login session doesn’t exist or has expired, they get redirected to a sign in page.

In a more dynamic web application where all the updates are done via AJAX and full page loads are rare, something else needs to be done. Handling a 302 redirect status code with jquery is possible, but it takes just as much (or more) code as any other status code. When developing the next web interface for StatHat, we made the server code as dumb as possible. It doesn’t know what the interface wants to do if the user is not signed in: it could redirect to a sign in page like the original version, it could show a modal dialog, whatever.

So we decided to return a 4XX status code and let the JavaScript client decide how to handle it. The question is, which one?

403 Forbidden is often used. But look at the spec:

403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

It clearly states that authorization will not help. The other main contender is 401 Unauthorized:

401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8)…

This sounds perfect except for the WWW-Authenticate junk. We aren’t going to support HTTP basic/digest authentication, but it seems like we are still honoring the intention of the spec to use 401, so we we went ahead with it and just ignored the WWW-Authenticate part of it.

We could have created our own error code, but that’s breaking the spec even more.

iPhone/iPad UISearchBar and UISearchDisplayController Asynchronous Example

2010-04-27T00:00:00+07:00

All of the Apple examples and almost everything I could find on the net showing how to use UISearchBar and UISearchDisplayController operated on an existing set of data in a data structure in the application. I want to search either a database locally on the iPhone/iPad or make a remote search request to an internet API. Here are my notes on how to get this working.

First it is necessary to understand the elements involved. UISearchBar is the user interface widget. The bar with the text field with rounded sides. You can use this by itself and connect its delegate to something that implements UISearchBarDelegate.

But, beginning with iPhone OS 3.0, there is a purportedly better way: UISearchDisplayController. There’s no need to subclass it, just use it out of the box. It is the glue between various parts of the search process. You initialize it with a UISearchBar and a “contentsController”. While the Apple docs state that the contents controller is usually a UITableViewController, it doesn’t have to be, and I think it’s simpler to understand what’s going on if you just use a UIViewController.

The UISearchDisplayController becomes the delegate for the UISearchBar. You need to wire up a few more connections: a UISearchDisplayDelegate, a UITableViewDataSource that provides the search result data, and a UITableViewDelegate for handling selecting the search result table cells.

Here’s what UISearchDisplayController does in a typical search scenario:

The user taps the UISearchBar. UISearchDisplayController activates the search interface, brings up the keyboard. It creates a table view for the results.
The user enters text to search for. UISearchDisplayController informs the UISearchDisplayDelegate of this. The UISearchDisplayController asks the delegate if it should reload its table (the default is YES).
When the UISearchDisplayController wants to reload the table, it asks the UITableViewDataSource for the number of rows and the cells for each row it wants. It displays the results table view on top of the existing controller.
If a user selects one of the rows in the table view owned by the UISearchDisplayController, it lets the UITableViewDelegate handle it.

The key point (at least for me) to understand here is that UISearchDisplayController creates its own UITableView. It puts it on top of the contentsController when there are search results. With all the examples I found, the contentsController was itself a UITableViewController and had its own UITableView that it was displaying.

The basic examples all work like this: there’s a UITableViewController with 200 rows of data. There’s a UISearchBar and a UISearchDisplayController. All of the delegates for the UISearchDisplayController connect to the UITableViewController. When the search is done, the UISearchDisplayController overlays its table with a filtered set of the original rows on top of the existing table of 200 rows. When the search interface is dismissed, the overlay table is removed and the original table is available.

Clearly these basic examples don’t work for a large database or an internet search API. You can’t load all the results into a table data source before the search and just filter them for the search results. You need to make a request for the search results, and to keep your app responsive, you should make that request asynchronously.

Apple hints at how to do this in their documentation for UISearchDisplayDelegate in the searchDisplayController:shouldReloadTableForSearchString: and searchDisplayController:shouldReloadTableForSearchScope:.

You might implement this method if you want to perform an asynchronous search. You would initiate the search in this method, then return NO. You would reload the table when you have results.

For this example, I’ll create a new project in xcode, an iPad Split-view based application. Open MainWindow.xib in Interface Builder, remove the RootViewController. It’s a table view controller and doesn’t need to be for this example. Drag a standard view controller into its place.

Back in xcode, go ahead and trash RootViewController.m and RootViewController.h. Remove references to it in the app delegate and the details controller. Add a new file, a UIViewController subclass with “Targeted for iPad” checked. Name it GenericViewController.

In interface builder, change the class of the view controller you added to GenericViewController. Add a view to GenericViewController. Drag the “Search Bar and Search Display Controller” to fit underneath the view. Doing this in Interface Builder makes it automatically connect the search display controller to the GenericViewController for all its delegates. This is fine for this example, but feel free to change this wiring if you want.

You can build it now, it will compile without errors and run. But if you try to search for anything, it will crash. This is because GenericViewController is set to be the delegate for all kinds of things for the search display controller, but none of the required protocols are implemented. Start by adding the protocols to the interface in GenericViewController.h:

@interface GenericViewController : UIViewController <UISearchDisplayDelegate, UITableViewDataSource, UITableViewDelegate> {

}

And in the implementation, paste this in for now (copied from the RootViewController default):

- (NSInteger)numberOfSectionsInTableView:(UITableView *)aTableView {
        // Return the number of sections.
        return 1;
}

- (NSInteger)tableView:(UITableView *)aTableView numberOfRowsInSection:(NSInteger)section {
        // Return the number of rows in the section.
        return 10;
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

        static NSString *CellIdentifier = @"CellIdentifier";

        // Dequeue or create a cell of the appropriate type.
        UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
        if (cell == nil) {
                cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
                cell.accessoryType = UITableViewCellAccessoryNone;
        }

        // Configure the cell.
        cell.textLabel.text = [NSString stringWithFormat:@"Row %d", indexPath.row];
        return cell;
}

Now you can build it and when you search, it always returns the same “Row 1 - 10” data, but you can see UISearchDisplayController doing its work and overlaying a table view of results.

Enough synchronous stuff. Start the asynchronicity! For the purposes of this demo, we’re going to fake a slow search by using an NSTimer. Here’s the crucial method to add to GenericViewController:

- (BOOL)searchDisplayController:(UISearchDisplayController *)controller shouldReloadTableForSearchString:(NSString *)searchString
{
        [NSTimer scheduledTimerWithTimeInterval:2 target:self selector:@selector(mockSearch:) userInfo:searchString repeats:NO];
        return NO;
}

By returning NO, the search display controller won’t reload its data. The timer calls mockSearch after a two second delay. Here’s mockSearch:

- (void)mockSearch:(NSTimer*)timer
{
        [_data removeAllObjects];
        int count = 1 + random() % 20;
        for (int i = 0; i < count; i++) {
                [_data addObject:timer.userInfo];
        }
        [self.searchDisplayController.searchResultsTableView reloadData];
}

The _data variable is an NSMutableArray member variable. It shoves a random number of rows containing the search string (in userInfo) into the array, then tells the search display controller’s table view to reload its data. I changed these methods to use _data for the rows:

- (NSInteger)tableView:(UITableView *)aTableView numberOfRowsInSection:(NSInteger)section {
        return [_data count];
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

        static NSString *CellIdentifier = @"CellIdentifier";

        // Dequeue or create a cell of the appropriate type.
        UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
        if (cell == nil) {
                cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
                cell.accessoryType = UITableViewCellAccessoryNone;
        }

        // Configure the cell.
        cell.textLabel.text = [NSString stringWithFormat:@"Row %d: %@", indexPath.row, [_data objectAtIndex:indexPath.row]];
        return cell;
}

So that’s about it. To use it in the real world, change the NSTimer call to some asynchronous network or database call. When it is done, reload the results table just like in mockSearch. One nice thing would be to also implement searchDisplayControllerDidBeginSearch: and searchDisplayControllerDidEndSearch: to display some sort of “Loading…” view on top of the results view until the results come in.

Update: By popular demand, here is the full source and xcode project for this example:

SearchExample.tar.gz

It’s for iPhone OS 3.2 and above only.

Vim Objective-C Colon Indentation

2009-10-02T00:00:00+07:00

Vim’s objective-c mode has an annoying indentation issue. It tries to line colons up on subsequent lines, like so:

[self performSelectorOnMainThread:@selector(finishLoad) 
                       withObject:nil 
                    waitUntilDone:NO];

That’s nice, but it has an annoying bug that makes it try to align the colons with a previous line that is unrelated:

if ([someVariable isEqualToString:@"blah"]) {
[self performSelectorOnMainThread:@selector(finishLoad) 
                       withObject:nil 
                    waitUntilDone:NO];
}

This all takes place in indent/objc.vim (full path on a MacPorts installation is /opt/local/share/vim/vim72/indent/objc.vim, for MacVim it is /Applications/MacVim.app/Contents/Resources/vim/runtime/indent/objc.vim).

There is probably a way to fix this in a .vimrc file, but I just edited objc.vim. At the bottom of the file is a function GetObjCIndent. Change the second if statement to match the following:

function GetObjCIndent()
    let theIndent = cindent(v:lnum)

    let prev_line = getline(v:lnum - 1)
    let cur_line = getline(v:lnum)

    if prev_line !~# ":" || cur_line !~# ":"
        return theIndent
    endif

    if prev_line !~# ";" && prev_line !~# "{"
        let prev_colon_pos = s:GetWidth(prev_line, ":")
        let delta = s:GetWidth(cur_line, ":") - s:LeadingWhiteSpace(cur_line)
        let theIndent = prev_colon_pos - delta
    endif

    return theIndent
endfunction

There are some refinements that could be made to fix it for more cases, but this one fixes the one that was driving me crazy.

Safari Keyboard Shortcuts To Switch Tabs

2009-09-10T00:00:00+07:00

Photo by wwarby

I am so used to the cmd-1, cmd-2, cmd-3, cmd-9 keyboard shortcuts in Firefox to switch to the first, second, third, and last tabs in a window. Whenever I try to use Safari and I instinctually use these shortcuts, it goes to bookmarks (1, 2, 3, and 9), which is incredibly annoying. Apple provides no way to change this.

With Leopard, I was using Safari Commander, but it stopped working with Snow Leopard. There are hints on twitter that a new version is coming out soon that will work, but it requires Safari to run in 32-bit mode. And Firefox seems to be slower than usual under Snow Leopard.

So the solution? Fastscripts. Thanks to this blog post by Justin Blanton, I now have scripts to switch to tabs one through five and the last tab. I modified his scripts to be for Safari instead of WebKit. They are each one line long, but in case you’re too lazy to type them in, here they are for you:

Put them in ~/Library/Scripts/Applications/Safari then assign them to the correct keys in the Script Shortcuts preferences pane in FastScripts.