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.
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.
...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 imgur.com 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.
Trackets Blog$ ssh -L 9000:imgur.com:80 [email protected]
The key here is -L which says we’re doing local port forwarding. Then
it says we’re forwarding our local port...
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...
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...
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.
There are many ways of getting a current time, but first we need to distinguish between two types
clock_timestamp())now())Let’s take a look at an example
postgres=# BEGIN...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
Password:
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 databases...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.
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:
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.
