# Sensible Team sensible.io blog This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## SSH Tunnel - Local and Remote Port Forwarding Explained With Examples DevFeed: [SSH Tunnel - Local and Remote Port Forwarding Explained With Examples]() Original publisher: [Read original article]() Author: sensible.io team Published: 2014-05-17T17:57:00Z Content type: tutorial Language: en Sources: [Sensible]() Topics: [ssh](), [OpenSSH](), [Database](), [PostgreSQL](), [Firewall](), [Rails](), [SockTz]() Tags: [browser](), [database](), [examples](), [firewall](), [local](), [nat](), [network](), [port](), [postgresql](), [rails](), [remote](), [security](), [server](), [ssh](), [syntax](), [tutorial]() ### AI overview A tutorial explaining SSH local and remote port forwarding through examples, including access to blocked web resources, databases behind firewalls, and locally hosted applications without public IP addresses. ### Source excerpt 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. $ ssh -L 9000:imgur.com:80 user@example.com The key here is -L which says we're doing local port forwarding. Then it says we're forwarding our local port 9000 to imgur.com:80, which is the default port for HTTP. Now open your browser and go to http://localhost:9000. The awesome thing about SSH tunnels is that they are encrypted. Nobody is going to see what sites you're visiting, they'll only see an SSH connection to your server. Connecting to a database behind a firewall Another good example is if you need to access a port on your server which can only be accessed from localhost and not remotely. An example here is when you need to connect to a database console, which only allows local connection for security reasons. Let's say you're running PostgreSQL on your server, which by default listens on the port 5432. $ ssh -L 9000:localhost:5432 user@example.com The part that changed here is the localhost:5432, which says to forward connections from your local port 9000 to localhost:5432 on your server. Now we can simply connect to our database. $ psql -h localhost -p 9000 Now let's stop here for a little bit an explain what is actually going on. In the first example the 9000:imgur.com:80 is actually saying forward my local port 9000 to imgur.com at port 80. You can imagine SSH on your server actually making a connection (a tunnel) between those two ports, one on your local machine, and one on the target destination. If we however say something like 9000:localhost:5432, it means localhost ## Don't just dump code into your models DevFeed: [Don't just dump code into your models]() Original publisher: [Read original article]() Author: sensible.io team Published: 2014-04-19T16:05:00Z Content type: opinion Language: en Sources: [Sensible]() Topics: [mvc](), [Code](), [Ruby](), [Development](), [Testing](), [API]() Tags: [api](), [code](), [controllers](), [development](), [mvc](), [ruby](), [test]() ### AI overview The article argues that the "skinny controllers, fat models" rule should not lead to oversized model classes. It presents MVC as a starting point for separating concerns and recommends introducing appropriate abstractions for services such as mailing-list subscriptions, improving configuration, testability, and dependency handling. ### Source excerpt A few years ago there used to be a motto saying Skinny controllers, fat models. It was good at the time, because people thought all of the application code belonged into the controllers, and it helped them realize that it's good to have just a simple controller layer and push things down. The problem with this motto is that it's wrong. Just because you should have skinny controllers it doesn't mean you should have fat models. In fact, none of your classes should be fat. The reason we have MVC is that it is a good starting point for separating the concerns in your application. It makes it more obvious where you should put your code when you're starting out with your application. But this doesn't mean your application should be limited to just these three layers, quite the opposite. Every time you need to add a new service to your application, you should think about how you're going to be using it, and then build a sufficient abstraction on top of that. For example let's say that your application needs to automatically sign up newly registered users to a mailing list. You've even chosen a provider, say AWeber or Mailchimp, as both of these have a nice Ruby gem wrapping up their API, allowing you to subscribe the user with only a few lines of code. Here's how the naive solution might look like class User after_create :subscribe_to_mailchimp def subscribe_to_mailchimp list_id = ENV["MAILCHIMP_LIST_ID"] Mailchimp.new(ENV["MAILCHIMP_API_KEY"].subscribe(list_id, self.email) end end If you happen to like YAML files more than environment variables, you might write something like this instead def subscribe_to_mailchimp config = SomeGlobalYamlConfigReader.mailchimp Mailchimp.new(config["api_key"].subscribe(config["list_id"], self.email) end While this might make sense the first time you try this, there are actually many things wrong with this approach. Let's list a few: If the Mailchimp API is unavailable during the time you decide to create a new user, your after_save callbac ## Getting started with Ember App Kit DevFeed: [Getting started with Ember App Kit]() Original publisher: [Read original article]() Author: sensible.io team Published: 2014-03-07T00:00:00Z Content type: tutorial Language: en Sources: [Sensible]() Topics: [Ember](), [Tutorial](), [JavaScript](), [ECMAScript](), [Development]() Tags: [cli](), [component](), [es6](), [getting-started](), [git](), [how-to](), [install](), [javascript](), [modules](), [npm](), [port](), [svg](), [web-browser]() ### AI overview A tutorial for building a simple Ember.js app that logs daily water intake using Ember App Kit. It covers creating a project, installing Grunt, Bower, and Loom, starting a development server, generating routes and controllers, and building a bottle component with an SVG-based water-level display. ### Source excerpt In the following tutorial we'll create a simple Ember.js app for logging your water intake. Besides learning the basics of Ember.js, you will also learn how to use Ember App Kit. You can see the final application right below: Link to Demo About Ember App Kit EAK is the basic building block of your app. It helps you to rapidly start the development with features such as the ES6 module transpiler, automatic reloading, the Grunt task runner, the Bower package manager... EAK uses ECMAScript 6 Modules, which means you can keep your namespace clean and only import objects you need to the current scope. Thanks to es6-module-transpiler you can use the current ES6 module syntax and it will be automatically compiled into today's JavaScript. Creating a project Create your project by cloning EAK ➤ git clone git@github.com:stefanpenner/ember-app-kit.git waterize ➤ cd waterize Optionally you can get rid of the Git history and start fresh ➤ rm -rf .git ➤ git init Install required node binaries This only needs to be done once. Install Grunt, Bower and Loom (if you want to use generate command to easily generate controllers/models etc.). ➤ npm install -g grunt-cli bower loom Starting a development server Install the required node packages and start the server ➤ npm install ➤ grunt server Finally open our project in the web browser (port defaults to 8000). open http://localhost:8000 Generating basic routes and controllers We'll use day controller for storing our water intake per that day. Now let's generate an object controller with Loom In Ember.js, controllers allow you to decorate your models with display logic. In general, your models will have properties that are saved to the server, while controllers will have properties that your app does not need to save to the server. Ember.js guide - Controllers ➤ generate controller day Select o since we want an object controller, then generate a route for the controller When your application starts, the router is responsible for displaying ## 4 Tips for Working with Dates in PostgreSQL DevFeed: [4 Tips for Working with Dates in PostgreSQL]() Original publisher: [Read original article]() Author: sensible.io team Published: 2013-08-26T11:47:00Z Content type: tutorial Language: en Sources: [Sensible]() Topics: [PostgreSQL](), [Rails]() Tags: [documentation](), [operator](), [postgresql](), [rails](), [time](), [timezone]() ### AI overview A tutorial on working with dates and times in PostgreSQL. It explains current-time functions such as now() and clock_timestamp(), time intervals and arithmetic, date-part extraction, and timezone-aware operations, with SQL examples. ### Source excerpt 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 always returns current value (clock_timestamp()) 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; postgres=# SELECT now(); now ------------------------------- 2013-08-26 12:17:43.182331+02 postgres=# SELECT now(); now ------------------------------- 2013-08-26 12:17:43.182331+02 postgres=# SELECT clock_timestamp(); clock_timestamp ------------------------------- 2013-08-26 12:17:50.698413+02 postgres=# SELECT clock_timestamp(); clock_timestamp ------------------------------- 2013-08-26 12:17:51.123905+02 As you can see, clock_timestamp() changes every time the statement is executed, but now() always returns the same value. It's also worth noting that both of these functions take timezone into account. Time interval, aka 3.days.ago You can easily create time intervals using the interval operator, for example interval '1 day' interval '5 days' interval '5 days' + interval '3 hours' interval '5 days 3 hours' As you can see, we can do simple math using the interval operator, which makes it very easy to construct things like 3.days.ago just by doing the following postgres=# SELECT now() - interval '3 days'; ?column? ------------------------------- 2013-08-23 12:23:40.069717+02 Extracting the day of the week and more Sometimes you just want to know the day of the week for a given date, or the century, or just the day. PostgreSQL has an extract() function which does just this. Just to put this into context the examples were executed ## PostgreSQL Sequences and Array Column Types DevFeed: [PostgreSQL Sequences and Array Column Types]() Original publisher: [Read original article]() Author: sensible.io team Published: 2013-08-24T14:21:00Z Content type: tutorial Language: en Sources: [Sensible]() Topics: [PostgreSQL](), [Databases](), [web applications](), [Rails]() Tags: [arrays](), [database](), [postgresql](), [rails](), [web-applications]() ### AI overview This tutorial explains PostgreSQL sequences and array column types. It demonstrates creating a posts table with an array column for tags and querying posts by tag, while also discussing PostgreSQL sequences for generated identifiers. ### Source excerpt This article is a sequel to our PostgreSQL series, which is aimed to teach you how to get the most out of your database. You might have been led by Active Record (or Rails in general) that it is a good idea to completely abstract away the database, but that it's hardly ever possible. If you plan on switching databases on any larger-than-small application, you're going to have to do some manual work anyway. Every database is special and you should use it as such, instead of just settling for the lowest common denominator. There are many features in PostgreSQL that can help you develop web applications, such as the array & json column types, hstore, PostGIS and much more. In this article we're going to take a look at arrays. Every one of us remembers the moment when you first learned about databases and you were told that if you want to store multiple values in one column you have to split that in a 1:N relationship, because each column can only hold one value. Well, that's not true in the world of PostgreSQL. You are free to create array columns with arbitrary length. You can even perform array-like queries on them. But first we need to start by creating a table. We'll do this with the most obvious example - posts with multiple tags. Each post has a title, content and an arbitrary number of tags. We also want to be able to select all posts with a specific tag. Let's first create a new database so that we can play around and drop it at the end of out session, keeping our machine clean. $ psql -U darth postgres postgres=# CREATE DATABASE test TEMPLATE template0; CREATE DATABASE postgres=# \c test; Now we can create our posts table. CREATE TABLE posts ( id SERIAL PRIMARY KEY, title VARCHAR(255) NOT NULL, content TEXT NOT NULL, tags VARCHAR(255)[] DEFAULT '{}' ); test=# \d posts Table "public.posts" Column | Type | Modifiers ---------+--------------------------+---------------------------------------------------- id | integer | not null default nextval('posts_id_seq'::re