Building a VPS with WordPress on a LEMP Stack

With site performance a key metric in Google’s ranking algorithms, more WordPress users are turning to dedicated, managed WordPress hosting such as WP Engine, Media Temple or SiteGround.

However, these can be expensive solutions for some, with costs starting at ~$30/site per month.

If you’re comfortable with basic server administration and WordPress, it’s possible to setup your own, inexpensive hosting for small WordPress websites, that matches the performance of managed WordPress hosting providers using a LEMP Stack (Linux, nginx, MySQL, PHP).

Creating a DigitalOcean Virtual Private Server (VPS)

This article uses DigitalOcean, but you can equally use services such as Linode, Vultr or a number of other providers. The other sections of this guide will equally apply, regardless of who you're using.

Continue reading %Building a VPS with WordPress on a LEMP Stack%

by Tim Carr via SitePoint

Debugging Android Apps with Facebook's Stetho

How to Build Multi-step Forms in Drupal 8

In this article, we are going to look at building a multistep form in Drupal 8. For brevity, the form will have only two steps in the shape of two completely separate forms. To persist values across these steps, we will use functionality provided by Drupal’s core for storing temporary and private data across multiple […]

Continue reading %How to Build Multi-step Forms in Drupal 8%

by Daniel Sipos via SitePoint

Ulemulem

'Ulemulem' is a responsive WordPress theme specifically built for announcing a wedding in One Page. The theme actually comes in 2 very different formats: Long page with a top/left navigation or a neat flipbook style One Pager. It has all the goodies you'll need for the build up - countdown timer, timeline story, map location, big image slideshow, gift registry and of course an RSVP form.

by Rob Hope via One Page Love

My Happy Challenge

'My Happy Challenge' is an introspective look at the Instagram challenge, #100HappyDays, taken by freelance designer and developer, Kim Goulbourne. Impressive adaption from a doughnut-shape infographic on desktop to a list view with number overlay on mobile.

by Rob Hope via One Page Love

Rapid Prototyping Compositions with Adobe Comp CC (iPad app)

Everything is moving towards speed and mobility. Many people, including designers are at least augmenting their desktop and laptop computers with mobile devices such as tablets. With this being said, more companies are focusing on apps you can use to increase your productivity.

Imagine sitting on the subway on the way back to your office and creating a mockup of a website along the way.

Imagine having an idea for a print poster, and getting the layout put together while you're in transit. When you get back, you can bring your idea into your more powerful devices for better design & development. In comes Adobe Comp CC, an app focused on creating quick prototyping on your iPad. Now, you can just right into your ideas and start fleshing them out.

Premade Layouts

The great thing about Adobe Comp CC is that it's free. Search for it on the App store, and download it without paying a penny. Then, install it and fire it up to get started immediately. When you start the app, you have three options to choose from. You can select Mobile, Print, or Web, and they have pre-made layouts set up for you.

Gestures

You can draw your layouts with simple gestures. Everything is simplified, to make it quick and easy to draw even complex shapes and useful design objects. For example, you can draw a square with a circle in one of the corners to create a rounded rectangle. A circle or a rectangle with an x over it creates an image box or a circular image box. You can see the list of gestures, shown in the screenshot above.

Options

The gear icon in the top right corner of the app gives you the option to choose from different document sizes. You don't have to simply remember common document sizes. Adobe has put together a lot of common options for you. You can start with a variety of iPhones, iPads, letters, and web sizes. It even lists the pt and pixel sizes below each option.

Editing Premade Layouts

Moving around the canvas is as simple as swiping, pinching to zoom, and spreading your fingers apart to zoom out, just like any other app. It's even more important in an app like this, because of the simple refines you'll need to make. You also may have small elements in your design that you need to edit. You can tap an element to edit it, and hitting the + symbol below a premade layout allows you to make a copy. I'd make a copy before making any edits.

Once you're into the layout, you have several different options. You can select elements simply by tapping. Also, you open up more options, such as shapes you can make, as well as text, and photos. These menus open up even more options to work with.

Shapes

You can choose from a collection of basic shapes such as circles, rectangles, and horizontal & vertical lines. You can also bring in any custom shapes libraries you have stored in the Creative Cloud.

Text

Just like a typical design program, you can have presets for type. You can control whether certain text is in headline format, sub headline and paragraph text.

Continue reading %Rapid Prototyping Compositions with Adobe Comp CC (iPad app)%

by James George via SitePoint

WebSockets in the Ruby Ecosystem

[caption id="attachment_109370" align="alignleft" width="300"] Ruby is learning to love WebSockets[/caption]

What the heck is a "WebSocket", exactly? Some of us have heard about the changes that are coming to Rails with regard to WebSockets (e.g. Action Cable in Rails 5) but it's a bit difficult to pinpoint exactly what WebSockets are meant to do. What problem do they solve and how do they fit into the realm of HTTP, the web, and Ruby? That's what we'll cover in this article.

Why?

Let's dial the time machine to the beginning of the web. Way back in the day, as we all know, websites consisted of static pages with a bunch of links between them. These pages are called "static" because nothing about them really changes on a per-user sort of basis. The server just serves up the same thing to every single user based on the path that the user requests. We quickly realized that this sort of thing was all well and good if all we wanted the web to be was the equivalent of an easily available book, but we could actually do a lot more. So, with input elements and CGI (Common Gateway Interface - a way for external scripts to talk to the web server), dynamic elements creeped into web pages.

Now, we could actually process input data and do something with it. As websites got busier, we realized that CGI was pretty terrible at scaling. Along came a slew of options such as FastCGI to remedy this problem. We came up with all sorts of frameworks to make writing back-ends a lot easier: Rails, Django, etc. All this progress happened, but at the end of the day, we were still serving up some HTML (through a variety of methods), the user was reading this mostly static HTML and then requesting some different HTML.

Then, developers realized the power of Javascript and communication with the server through AJAX. No longer were pages just blobs of HTML. Instead, Javascript was used to alter the content of these pages based on asynchronous communication with the server. Often, state changes that occurred on the server had to be reflected on the client. Taking a very simple example, maybe we want a notification to show up on the admin panel when the number of users on the server exceeds a certain limit. However, the methods used to do this sort of thing weren't the best. One common solution was HTTP long polling. With it, the client (i.e. Javascript code running in the browser) sends the HTTP server a request which the server keeps open (i.e. the server doesn't send any data but doesn't close the connection) until some kind of update is available.

You might be wondering: Why do we do this waiting stuff if the client could somehow just ask the server to tell the client when an update comes along? Well, unfortunately, HTTP doesn't really let us do that. HTTP wasn't designed to be a server-driven protocol. The client sends the requests, the HTTP server answers them. Period. Long polling isn't really a great solution since it causes all sorts of headaches when it comes to scaling, users switching between Wi-Fi and cellular, etc. How do we solve this problem of letting the server talk to the client?

Continue reading %WebSockets in the Ruby Ecosystem%

by Dhaivat Pandya via SitePoint