If you deploy your application to a staging environment, chances are that it will eventually get picked up by Google and other search engines. This is undesired for many reasons, from other people discovering your unfinished work to bad SEO from duplicate content.
"Inuit.css is a powerful little framework designed for serious developers." says the first sentence in a README file.
The biggest advantage of Inuit over other frameworks is modularity and focus on abstractions. It doesn't enforce how elements should look. Instead, it gives a set of tools which speed up your work and allow to test new things faster.
Migrating databases from one host to another can be a boring and time consuming task. Usually you need to make a database dump on the host A, compress it, transfer it to the host B, uncompress it and finally load it into the database. Things get even more complicated when we want to transfer database to a different database engine, say from MySQL to PostgreSQL.
Fortunately there is taps. It's a tool for migrating databases. From this post you will learn how to use it, how it works and how to resolve its most common problems.
What is SSL/TLS?
Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are cryptographic protocols designed to provide secure connection between a server and a client, typically a web server and a browser or a mail server and a mail client.
This post will show a fast and easy way to add search to your Rails application. We will use Elasticsearch, an open source search engine, and Searchkick, an easy-to-use gem that integrates Elasticsearch with Rails.
Bower is an open source software created by Twitter, which simplifies dependencies management and updating of front-end packages (like gridism or normalize). In general it is the same thing for HTML/CSS/JS what Bundler is for Ruby. Not so long time ago version 1.0 has been released and the current stable version is 1.2. Let's take a look at how to use it and integrate with a Rails app.
When working on web applications we take a lot of supporting technology for granted. We build our code on top of a multi-layered network stack with HTTP as the glue. Each user interaction with our app may cause several HTTP requests that are routed and handled separately, often in parallel. Most of the time developers don't have to care how exactly this magic works. Sometimes though, performance requirements force them to dig deeper. We at Shelly Cloud want to empower our users, that's why we decided to share details of our internal architecture.
Today we're going to describe what route an HTTP requests takes, from the moment it leaves the browser up to the moment a response gets back from the server.
Second part of this article builds upon this knowledge and describes multiple failure scenarios.