Error Tracking Made Easy

Catch and fix every error in your application. Sign up for free

Tips for building a Single Page Application

Everyone’s building single page applications (SPA) these days. We’ll take a look at some of the challenges and best practices for building JavaScript heavy applications. Some of the things might not be so obvious at first glance, but it definitely helps to think about this up front. After all, it’s quite a big decision to go JavaScript all the way.

Read more…

Unit Testing JavaScript with QUnit

There are many testing frameworks available these days, most of which offer some very cool features, such as automated cross browser testing, etc. But today we’ll take a look at something much simpler, QUnit, which is our all time favorite at Trackets.

Why? Having 50 different testing frameworks to choose from actually isn’t so good, since you’ll be constantly arguing with everyone else about which framework is the best one, and what is the right way to test things. There are also many ways to run the unit tests, many different build frameworks, and just a huge number of choices in general when it comes down to creating a new JS project.


Read more…

SSH Tunnel - Local and Remote Port Forwarding Explained With Examples

There are two ways to create an SSH tunnel, local and remote port forwarding (there’s also dynamic forwarding, but we won’t cover that here). The best way to understand these is by an example, let’s start with local port forwarding.

Imagine you’re on a private network which doesn’t allow connections to a specific server. Let’s say you’re at work and is being blocked. To get around this we can create a tunnel through a server which isn’t on our network and thus can access Imgur.

$ ssh -L

The key here is -L which says we’re doing local port forwarding. Then it says we’re forwarding our local port...

Read more…

Why should you care about JavaScript errors?

Most of the websites on the internet aren’t just static pages anymore. Half of the internet is using jQuery, and with the growing popularity of single page applications we have even more JavaScript in our apps.

This however leads to completely different problems which aren’t present in standard server-only architecture. When something goes wrong on your backend, it’s usually just a single request that failed and you have all the context available.

The problem with JavaScript is that the applications usually live for more than just a single request. One thing might silently fail and cause an error a few minutes later in a completely different...

Read more…

Giving a meaning to stacktraces

We’ve all been there, something goes wrong, you look at a stacktrace and have absolutely no idea what the hell is going on. If only there was something that would give you more context, for example a list of all the actions a user had taken before the error occurred.

In order to make the whole bug-hunting process less painful we’ve decided to record all events that lead up to unhandled exceptions. When a new error pops up, you can just look at the event log and instantly see what happened. Maybe the user clicked a button 4 times in a row instead of just once. That sort of thing would never appear in a stacktrace, but it might as well cause...

Read more…

4 Tips for Working with Dates in PostgreSQL

Those of us who come from Rails aren’t surprised when we see something like 5.weeks.from_now or 3.days.ago + 2.hours, which makes working with dates much easier. But PostgreSQL got your back on this as well, you can just use the builtin functions and get most of the same functionality.

Current Time/Date/Timestamp

There are many ways of getting a current time, but first we need to distinguish between two types

  1. always returns current value (clock_timestamp())
  2. always returns current value, unless in a transaction, in which case it returns the value from the beginning of the transaction (now())

Let’s take a look at an example

postgres=# BEGIN...

Read more…

PostgreSQL Basics by Example

Connecting to a database

$ psql postgres     # the default database
$ psql database_name

Connecting as a specific user

$ psql postgres john
$ psql -U john postgres

Connecting to a host/port (by default psql uses a unix socket)

$ psql -h localhost -p 5432 postgres

You can also explicitly specify if you want to enter a password -W or not -w

$ psql -w postgres
$ psql -W postgres

Once you’re inside psql you can control the database. Here’s a couple of handy commands

postgres=# \h                 # help on SQL commands
postgres=# \?                 # help on psql commands, such as \? and \h
postgres=# \l                 # list...

Read more…

Strong Parameters by Example

Rails has always had a nice way of sanitizing user input coming from ubiquitous forms. Up until Rails 3, the solution was to list accessible fields right in your models. Then Rails 4 came along and introduced a different solution - strong_parameters, allowing you to take a greater control over the sanitizing process. The following text should serve as a light introduction to the topic and also as a cookbook for solving more complex tasks.

Let’s start by taking a look at how strong_parameters actually work. On a superficial level, every request wraps its params in ActionController::Parameters, which allows you to whitelist specific keys.

Read more…

A Vision of Better JavaScript Error Tracking

Developing JavaScript applications is hard, but things get even harder when you launch them into production. Every one of your users will have a different environment, a different browser and different extensions that might be interfering with your application. Things get even harder if you are brave enough to develop single page applications, as one thing can easily lead to another and cause problems which are next to impossible to reproduce in development.

Let’s take a look at some more possible issues:

  • Internet connection or the API server goes down for a couple of seconds while the user is using your app.
  • User is “too fast” or does two...

Read more…

How to write a login form that doesn't suck, using Ember.js

When using frameworks such as Ember.js, we often find ourselves forgetting the main reason why we chose to use the framework. We don’t do it because it’s cool, or at least we shouldn’t. We don’t do it because somone told us we have to use Ember (unless your boss doesn’t have much brains). We do it because want to make the user experience better. I won’t go into details about server side implementation, this is purely about UX.

Read more…

Next page