Nettuts+

The Right Way to Retinafy Your Websites

Allan Berger — Tue, 21 May 2013 14:55:30 +0000

Making your website ready for Retina display doesn’t have to be a hassle. Whether you are building a new website or upgrading an existing one, this guide is designed to help you get the job done smoothly.

Make it Retina First

The easiest and most time-saving way to add Retina support is to create one image that is optimized for Retina devices, and serve it to non-Retina devices as well.

By now, every modern browser uses bicubic resampling and does a great job with downsampling images. Here’s a comparison of downsampling in Photoshop vs. Google Chrome, using an image from our Growth Engineering 101 website.

There are two ways to let the browser downsample images for you: img tags or CSS background images.

You can have img tags serve the Retina-optimized image, and set the width and height attributes to half of the resolution of the actual image (e.g. 400×300 if the image dimensions are 800×600).

<img src="http://www.example.com/Retina-image-800x600-2x.png" width="400" height="300">

If you use images as CSS backgrounds, you may use the CSS3 background-size property to downsample the image for non-Retina devices.

<div class="photo"></div>

.photo {
    background-image: url(Retina-image-800x600-2x.png);
    background-size: 400px 300px;
    background-repeat: no-repeat;
    display: block;
    width: 400px;
    height: 300px;
}

In both cases, be sure to use even numbers in both dimensions to prevent displacement of pixels when the image is being downsampled by the browser.

When Downsampling is Not Good Enough

Usually, browser downsampling should work quite well. That said, there are some situations where downsampling in the browser might make images blurry.

Here we have a bunch of 32px social icons.

And here is how they will appear, when downsampled to 16px by Photoshop’s as well as Google Chrome’s bicubic filter. It seems that we get better results from Photoshop in this case.

To get the best results for our users, we can create two versions of the same image: one for Retina devices, and another one that has been downsampled by Photoshop for non-Retina devices.

Now, you can use CSS media queries to serve Retina or non-Retina images, dependent upon the pixel density of the device.

/* CSS for devices with normal screens */
.icons {
    background-image: url(icon-sprite.png);
    background-repeat: no-repeat;
}

/* CSS for high-resolution devices */
@media only screen and (-Webkit-min-device-pixel-ratio: 1.5),
only screen and (-moz-min-device-pixel-ratio: 1.5),
only screen and (-o-min-device-pixel-ratio: 3/2),
only screen and (min-device-pixel-ratio: 1.5) {
    .icons {
        background-image: url(icon-sprite-2x.png);
        background-size: 200px 100px;
        background-repeat: no-repeat;
    }
}

If you use a background color for small icons, on the other hand, downsampling by the browser works rather well. Here is the same downsampling example with a white background.

Polishing Your Downsampled Images

If you’re still not satisfied with the results from Photoshop’s downsampling, you can go the extra mile and hand-optimize the non-Retina version to get super crisp results.

Below are some examples of images from the Blossom product website that I hand-optimized for those who are still on non-Retina devices.

Borders and Strokes

Here’s an example of downsampling issues with hairlines, where I re-draw the lines of the downsampled image.

View the Retina Version of this Image on Dribbble.

Text

Next, we come to an example of downsampling issues with text. In this case, I manually re-wrote the text “Feature Pipeline” to make the result as crisp as possible.

Retina Version

When details, crisp fonts, and clean hairlines are important, you might want to go the extra mile.

Try to Avoid Images

The main disadvantages of rasterized images are their considerable file size and that they don’t scale well to different sizes without affecting the image quality. Great alternatives to rasterized graphics are CSS, Scalable Vector Graphics (SVG), and Icon Fonts.

If you have any chance to build the graphical elements for your website in CSS, go for it. It can be used to add gradients, borders, rounded corners, shadows, arrows, rotate elements and much more.

Here are a few examples of interaction elements in Blossom that are implemented in CSS. The subtle gradient is powered by CSS gradients, and the custom font in use on this button is Kievit, served via Typekit. No images.

In the following screenshot, the only two images used are the user avatar and the blue stamp. Everything else – the circled question mark, the dark grey arrow next to it, the popover, its shadow and the arrow on top of it – is pure HTML and CSS.

Here, you can see how projects in Blossom appear. It’s a screenshot of a project’s website used as cover on a stack of paper sheets. The paper sheets are implemented with divs that are rotated using CSS.

Also, the circled arrow in the right-hand side of the screenshot below is pure CSS.

Tools

Here are some awesome tools that will help save time when creating effects with CSS.

CSS Generator: Cross browser CSS3 syntax by @RandyJensen.
CSS Arrows: CSS for tooltip arrows by @ShojBerg.
Generating CSS for Sprites: Sprite Cow helps you get the background-position, width and height of sprites within a spritesheet as a nice bit of copyable css. It’s built by TheTeam, and is a real time saver – definitely worth a try.

The primary advantage to SVG is that, unlike rasterized graphics, they scale reasonably well to various sizes. If you’re working with simple shapes, they typically are smaller than PNGs. Often, they are used for things like charts.

Icon Fonts are frequently used as a replacement for image sprites. Similar to SVG, they can be scaled up infinitely without any loss of quality and are usually smaller in size, when compared to image sprites. On top of that, you can use CSS to change their size, color and even add effects, such as shadows.

Both SVG and Icon Fonts are well supported by modern browsers.

Retina-Ready Favicons

Favicons are really important for users who need an easy way to remember which website belongs to which browser tab. A Retina-ready Favicon will not only be easier to identify, but it will also stand out among a crowd of pixelated Favicons that haven’t yet been optimized.

To make your Favicon Retina-ready, I highly recommend X-Icon Editor. You can either upload a single image and let the editor resize it for different dimensions, or you can upload separate images optimized for each size to get the best results.

How to Make Existing Images Retina-Ready

If you want to upgrade a website with existing images, a bit more work is required, as you’ll need to re-create all images to make them Retina-ready, but this doesn’t have to waste too much time.

First, attempt to identify images that you can avoid by using alternatives like CSS, SVG and Image Fonts, as noted previously. Buttons, Icons and other common UI widgets usually can be replaced with modern solutions that don’t require any images.

In case you actually need to re-create rasterized images, you’ll of course want to return to the source files. As you might assume, simply resizing your rasterized bitmap images to be twice as big doesn’t get the job done, because all of the details and borders will become pixelated.

No need to despair – image compositions which mostly contain vectors (i.e. in Adobe Photoshop or Illustrator) are quite easy to scale up. That said, don’t forget to verify if your Photoshop effects in the blending options, such as strokes, shadows and bevels, still appear as you intended.

In general, making Photoshop compositions directly out of vectors (shapes) and Photoshop’s Smart Objects will save you a great deal of time in the future.

How to Optimize the File Size of Images

Last, but not least, optimizing the file size of all images in an application or website could effectively save up to 90% of image loading times. When it comes to Retina images, the file size reduction gets even more important, as they have a higher pixel density that will increase their respective file sizes.

In Photoshop, you can optimize the image file size, via the “Save for Web” feature. On top of that, there is an excellent free tool, called ImageAlpha, which can reduce the size of your images even more with just a minor loss of quality.

Unlike Photoshop, ImageApha can convert 24-bit alpha channel PNGs to 8-bit PNGs with alpha channel support. The icing on the cake is that these optimized images are cross-browser compatible and even work for IE6!

You can play around with different settings in ImageAlpha to get the right trade-off between quality and file size. In the case below, we can reduce the file size by nearly 80%.

When you’re finished setting your desired compression levels, ImageAlpha’s save dialog also offers to “Optimize with ImageOptim” – another great and free tool.

ImageOptim automatically picks the best compression options for your image and removes unnecessary meta information and color profiles. In the case of our stamp file, ImageOptim was able to reduce the file size by another 34%.

After we updated all assets at Blossom.io for high resolution displays and used ImageAlpha and ImageOptim to optimize the file size, we actually ended up saving a few kilobytes in comparison to the assets we had before.

Save Time, Read This Book

If you want to learn more about how to get your apps and websites ready for Retina displays, I highly recommend “Retinafy your web sites & apps”, by Thomas Fuchs. It’s a straight-forward step by step guide that saved me a lot of time and nerves.

Awesome Retina-Ready Sites on the Web

http://kickoffapp.com/

http://www.layervault.com

http://www.apple.com

http://www.panic.com

Thanks for reading! Any questions?

How to Create a PyroCMS Theme

Zac Vineyard — Mon, 20 May 2013 16:00:33 +0000

Like most content management systems, PyroCMS uses front-end themes. Though PyroCMS themes are built a bit differently than what you might be used to from other systems, they’re still quite easy to create. They’re so easy, in fact, that very little PHP experience is required to assemble them!

The Folder Structure

PyroCMS themes consist of HTML, images, CSS, and JavaScript, arranged into the following supported folders:

css
img
js
views
views/layouts
views/partials
views/modules

While these folders will no doubt look familiar to you, the "views" folder makes the most sense within the context of MVC. When building a theme for PyroCMS, you are really building the views (including assets) of a MVC patterned application. These views consist of a master layout file and multiple partial files (i.e. a header.html or footer.html) that shares presentation logic between different layouts. We’ll discuss this more shortly.

Getting Started

To get started building your first PyroCMS theme, create the supported folder structure in one of the two places that themes may reside within an instance of PyroCMS:

addons/shared_addons/themes (for themes available to all sites)

Or:

addons/[site-name]/themes (for themes available to only one specific site)

Once you have the base theme folder containing the supported folder structure created, the first file that you'll want to add to your theme is theme.php.

addons/shared_addons/themes/[my-theme-name]/theme.php

This theme.php file contains all essential details for your theme, including its name, author, version, etc. In a way, this file is similar to the comment block found at the top of a WordPress theme's style.css file. Here’s a basic example of a theme.php file for your PyroCMS theme:

<?php defined('BASEPATH') OR exit('No direct script access allowed');

class Theme_Foo extends Theme
{
    public $name = 'Foo';
    public $author = 'Zac Vineyard';
    public $author_website = 'http://zacvineyard.com';
    public $website = 'http://example.com/themes/foo';
    public $description = 'The antithesis theme to your Bar theme.';
    public $version = '1.0';
}

 /* End of file theme.php */

Please take note that this file extends a PyroCMS class, called Theme. Also, because you are declaring a PHP class in this file, you'll need to make sure that the name of the folder containing your theme is used in the class declaration. So, if the folder housing your theme is called, "foo," the class created in your theme.php should be named, Theme_Foo (instead of Theme_Custom, as shown in the example within PyroCMS' documentation).

Once you have created your theme.php file, you can login to your PyroCMS control panel and view your theme listed in the Themes module.

Layouts

All layouts files for a PyroCMS theme exist in one of two locations:

addons/[site-ref]/themes/[my-theme-name]/views/layouts/

Or:

addons/shared_addons/themes/[my-theme-name]/views/layouts/

Every theme should have a layout file, named "default.html" in one of the locations listed above. Additional layout files are optional; I'll show you how to add more layout files in a moment. First, it’s important to review the contents of a layout file.

Layout files in PyroCMS are built using HTML and a tag parser, referred to as the Lex Tag Parser. This is what a very basic PyroCMS layout file looks like:

<!DOCTYPE html>
<html>
<head>
    <title>{{ template:title }}</title>
    {{ template:metadata }}
</head>
<body>
    <h1>{{ template:title }}</h1>
    {{ template:body }}
</body>
</html>

The special tags you see in this bit of HTML are Lex parser tags. If you've ever used Smarty templates in PHP, these may look somewhat familiar. The primary benefit to using Lex parser tags in your layout files is that you don't have to put PHP directly in your views (remember, we're using MVC), which gives you the best chance of creating PyroCMS themes that follow the don’t repeat yourself pattern.

The example that I've given above is simple, of course, but Lex parser tags are quite powerful. They can loop through data, work with attributes, and more. Learn more about the Lex Parser in the PyroCMS documentation.

A more complex PyroCMS layout file looks like this:

<!DOCTYPE html>
<html>
<head>
    <title>{{ template:title }}</title>
    {{ template:metadata }}
    {{ theme:favicon file="favicon.png" }}
    {{ theme:css file="style.css" }}
    {{ theme:js file="site.js" }}
</head>
<body>
    <div class="header">
        <div class="logo">
            {{ theme:image file="logo.jpg" alt="Your Cool Logo" }}
        </div>
        <div class="nav">
            {{ navigation:links group="header" }}
        </div>
    </div>
    <div class="content">
        <h1>{{ template:title }}</h1>
        {{ template:body }}
    </div>
</body>
</html>

You'll notice that this layout file, using Lex, includes assets, like CSS, JavaScript, and images. Using Lex tags and HTML allows PyroCMS developers to build layout files very quickly.

Partials

Partials in PyroCMS, which stands for partial layouts, allows you to break layouts into reusable parts or sections. These sections can then be loaded by different layout files. This keeps you from typing the same code (header, footer, etc.) into multiple layout files.

Depending on where you've placed your theme files, partials are created in one of two locations:

addons/[site-ref]/themes/[my-theme-name]/views/partials/

Or:

addons/shared_addons/themes/[my-theme-name]/views/partials/

Partials are loaded into layouts using this Lex tag:

{{ theme:partial name="partialname" }}

This Lex tag operates exactly like a PHP include statement – similar to one that you would find in WordPress or other themes. The code below is a simple example of a PyroCMS layout that takes advantage of partials.

{{ theme:partial name="header" }}

    <div class="content">
        <h1>{{ template:title }}</h1>
        {{ template:body }}
    </div>

{{ theme:partial name="footer" }}

The contents of the header.html partial and footer.html files are, of course, the HTML we'll need to reuse from the template in our previous code example above. One quick pointer: there is no limit to the number of partials that you can use in one layout. Additionally, partial files may contain any combination of valid HTML and Lex.

Multiple Layout Files

To add another layout to your instance of PyroCMS, create one more layout file in your theme's views/layouts/ directory. This file may receive any name, but it’s a good idea to name it as descriptively as possible – like about.html.

For added flexibility, you can make use of as many layout files as you'd like. When you edit or create a Page Type in your PyroCMS control panel (Control Panel→Pages→Page Types) and select your desired file from the dropdown, all the layouts in your theme's layout file will be available to use.

Mobile Layouts

PyroCMS is able to easily display separate layouts for mobile and desktops. To use this feature, move your layout files into a folder, called "web" within the views folder, so that your default layout will be located here:

[your-theme]/views/web/layouts/default.html

When a user accesses your site using a desktop browser, the primary layout files in this location will be used. If the user accesses your site using a mobile device browser, users will be supplied with the mobile layouts that you've created in this location:

[your-theme]/views/mobile/layouts/default.html

This feature works with multiple layout files.

Please take note of this warning found in the PyroCMS documentation: "PyroCMS does not consider the iPad a mobile device, so it will not load your mobile layouts if the user is accessing your site using an iPad." If, however, on your site, you'd like to make an iPad recognized as a mobile device, you can change the "user_agent.php" file within the config/ directory to make the iPad recognized a mobile device.

Finished!

Using this article as a guide, you can see how easy it is to create a theme in PyroCMS. The code examples provided are quite simple, so I encourage you to explore the PyroCMS documentation to become more experienced with layouts, mobile layouts, partials, and the Lex Parser in PyroCMS. Have fun!

The Linux Firewall

Patkos Csaba — Fri, 17 May 2013 18:00:48 +0000

There are several firewall applications for Linux, but what you may not realize is that, at the heart of all these programs is a single all-mighty application that is built right into the Linux Kernel: iptables. This is the Linux firewall. No matter which program you use to configure your firewall under Linux, it ultimately all comes down to iptables. All that these other programs do is configure it.

So, here comes the question: if those programs simply configure iptables, why not simply configure it directly yourself? Doing so is easier than you might think!

Networking Background

If you’re familiar with networking terms, like connections, IP, TCP, and Port, then feel free to skip ahead to the next step. Otherwise, if you’re new to networking, read on to familiarize yourself with the terms that you will need to understand, in order to follow along with this tutorial.

Please note that the terms and definitions below have been intentionally over-simplified. They’re meant for every-day users, not sysadmins. So if you are a seasoned sysadmin or you have a CCNA in you pocket, please excuse me for not entering into the details.

TCP/IP

TCP/IP is a protocol that allows computers to communicate with one another over Internet and Ethernet Networks.

Failure is the last resort.

Imagine an Ethernet Network as a small local network (LAN – local area network), like your home PC, laptop, and smart phone. It’s a small heterogeneous network that is isolated from the rest of the world. A network of such networks is what we all know as the Internet: a set of interconnected networks.

TCP/IP is a combination of two protocols working at different levels in the hierarchy of the network communication chain. We won’t delve into details about that hierarchy. TCP stands for Transfer Control Protocol, and its core responsibility is to ensure that communication is successful. It controls the correctness of the data sent, and ensures its success. It has different algorithms to perform sophisticated checksums, autocorrect, and retry. Failure is the last resort. The name, IP comes from Internet Protocol. You can best associate it with the “phone-number” of your PC. Each machine capable of communicating over the Internet must have an IP address – a unique phone number – so that communication packets can find their destinations. A packet is a small piece of data inside a communication stream, which is self contained and can be checked for correctness. Essentially, we can say that our computers send TCP packets over the Internet using the IP protocol.

Each network communication is bound to a specific port. Network ports range from 0 to 2^16 (65536). Each network connection has an outgoing port for the one who initiates it, and an inbound port for the one who is listening for other computers’ messages. There can be several connections between several computers over identical ports. A computer can, however, talk over several ports at once. So, basically, ports are good to identify services and define channels of communications, but they do not limit the amount of data or connections.

Some computers can have similar IP addresses. You may have observed that both your computer at home and at work have IP addresses that takes the form of something along the lines of 192.168.something.something, or 10.0.something.something, or 172.16.something.something. These are the so-called private IP addresses that can be used only inside your LAN. You can’t go out to the Internet with IP addresses like this. They are akin to interior numbers for your company’s phone network.

Gateway & Bridge

A Bridge is what computers with real (public) IP addresses pass to the Internet.

Essentially, these computers have the rights and capabilities to talk to one another on the Internet directly. But, since there are no direct connections between all the computers in the world (that would be quite hard to accomplish), bridges are responsible for connecting segments of the Internet.

Keeping our telephony analogy alive, you can imagine these bridges to be similar to the telephone centers in your town or neighborhood. If you make a call to another local number (the computers on the left in our schema), the communication could have been made directly by your telephone center by physically connecting your line with you neighbor’s. However, if you instead want to call your distant uncle Bob, your call would have to be redirected over several phone centers until your uncle’s phone could be connected. These form a bridge between your town and his town.

A Gateway is a way for computers from a private network (LAN with private IP addresses) to communicate with other computers on the Internet.

A private network is like your company’s private phone network. You can call interior numbers, but in order to call someone who is outside of your company’s network – like your wife at home – you must first dial a special number or prefix.

Computers actually function in a similar way. When you are on a private network, you have a so-called gateway computer. When your computer attempts to talk to another computer on the Internet, it will automagically contact the gateway first and request “a line” to the outside world. The gateway will do the talking to the computer found on the Internet, and will forward the message back to your computer. You, as an ordinary user, see no difference between a bridge and a gateway. Your computer will know how to deal with them.

Definition of a Firewall

A firewall is a program running on a Gateway, Bridge or PC/Laptop/Smartphone that is capable of filtering incoming, outgoing, and forwarded network packets. A firewall is essentially a tool that lets you restrict you or your network’s access to the Internet, and someone else’s access from the Internet to your network.

And yes, your cable router or home Wi-Fi is, in fact, a firewall for all your computers and gadgets that connect to the internet through it.

The Problem We Will Solve

To set the context, let’s imagine a very possible network architecture. I’ve seen many small companies running something similar to this.

What we have here is actually something quite simple:

A few computers and other network-connected devices – the green boxes
An e-mail server – the red box
A Microsoft Active Directory server – the blue box
A gateway, which is also a firewall, for our network running Linux – the black box
Between all of these is a simple network switch

In the following section, we will configure iptables on that gateway, so that it will allow all the devices in the network to connect to the Internet. It will allow us to connect to it, via SSH, and will allow external mail servers to reach the mail server inside our network – a computer that does not even have a public IP address; only a private one.

Iptables Components

Iptables’ name actually has a meaning in its functionality. It’s a set of tables of IP address and ports with some actions attached to them. In iptable’s terms, these tables are referred to as chains. An unconfigured, empty iptables might look like this:

csaba ~ # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

You can observe that there are three main chains:

INPUT – all incoming connections
FORWARD – connections passing through
OUTPUT – connections departing from this server

The term, “policy ACCEPT” in parenthesis means that ACCEPT is set as the default policy for that particular chain. So, when there is no match for a connection, that rule will be applied. There are three main concepts you can use when configuring your firewall:

default policy ACCEPT & deny selectively all you need to – it may be difficult to specify all that it is denied. I do not recommend this approach.
default policy DROP or REJECT & allow selectively all you need to – this is better, but it has a problem. If you make a mistake in your iptables configuration, you can easily remain with empty chains denying access to everything and everyone, including you. So, unless you always have physical access to your firewall server/computer, I recommend that you use the next approach.
default policy ACCEPT & an explicit policy to DROP all & then allow selectively all you need – this is a combined solution between the first two possibilities. It will use an ACCEPT default policy, so if something goes wrong, you can log back over SSH or whatever remote connection you use for your firewall. At the same time, an explicit DROP rule for any unmatched connections ensures that you are safe. Allowing only what you know about and actually need to use offers the best possible protection.

Adding Rules to Iptables

There are two ways to add a new rule to iptables. One is to insert it at the begining of a chain. The other option is to append it to the end of a chain. Why does it matter in which order the rules occur?

Important: iptables check the rules in a chain from top to bottom. It will stop its search at the first match.

You must design your rules in such a way to consider the above mentioned behavior of iptables. After the first match of a rule, iptables will take the actions specified by the rule, and then cease the search. If no rule matches the connection that is checked, the default policy applies.

Inserting a New Rule

Let’s say that we want to add a rule to our iptables that will allow anyone to connect to port 22 on our firewall. Port 22 is the port for the SSH protocol. Of course, a good server admin will change this port to something unexpected for obvious security/obscurity reasons, but that’s another story for another tutorial. We will stick with 22.

csaba ~ # iptables -I INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
csaba ~ # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh

I presumed that the IP address facing the Internet with the public IP on it is on the network interface, called eth0. Let’s dissect this command:

-I – stands for insert the rule
INPUT – specifies the desired chain
-i – stands for network interface – in our case, eth0
-p – is for protocol (tcp or udp)
–dport 22 – is for destination port 22 – it has a corresponding --sport version for source port verification
-j – actually comes from “jump,” and is followed by an action -in our case, the action to accept the connection

However, you may have already guessed that this rule has little effect at this time. Our default policy is ACCEPT, so accepting something explicitly does not offer us any extra functionality. Now, remember the third recommended way to set up our firewall: the explicit rule to deny everything not matched. Let’s add that rule.

Appending Rules

We want to append a rule that blocks incoming traffic. But be careful: we only want to block what could be harmful. If we block everything, we will not be able to do anything, because the replies to our requests will be rejected. For example, when you browse a web page, you make a request, then you receive an answer. This answer comes into your computer, so, on the INPUT chain, we must have a rule to allow it.

First, we will append a rule to accept incoming traffic for already established connections, such as responses to requests.

csaba ~ # iptables -A INPUT -i eth0 -m conntrack  --ctstate ESTABLISHED,RELATED -j ACCEPT
csaba ~ # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Now that we’ve safeguarded our existing connections and the replies to the connections we initiated, we can deny everything else that wasn’t matched.

csaba ~ # iptables -A INPUT -i eth0 -p tcp -j DROP
csaba ~ # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DROP       tcp  --  anywhere             anywhere

We’ve appended another line, with a rule to DROP all connections that match. Remember: this rule will only apply if none of the previous ones actually match.

There are two ways to refuse a connections.

You can use DROP, which is equivalent to dialing a non-existent phone number with the difference that, after some time, the network connection times out. With a phone number, a robot informs you that the number does not exist. But the end result from the point of view of the caller is the same: it thinks that the destination does not exist.
The second way to refuse the connection is with the rule, REJECT, and an optional message. This is analogous to the number you are trying to call being busy. You may know that there is a number, you know it can be called, but it simply refuses to take your calls. Optionally, you can provide a message with a REJECT rule; the default is “ICMP port unreachable” or something similar.

Allow Computers to Access the Internet

At this point, we have some basic rules for the INPUT chain. But we have a network of computers having private IP addresses. We need to provide a gateway to the Internet. This is also done by iptables: the firewall.

Network Address Translation (NAT)

Likely, you’ve already heard this term: NAT. This refers to the procedure of translating one network address to another and forwarding the information between the two. It’s most frequently used in architectures like our own. The gateway has to do NAT in order to translate any computer’s IP from the LAN into its own public IP and then back.

Routing is the procedure by which a system can figure out on what network interfaces and toward what gateway it can communicate to reach its destination. Each computer has a routing table of its own to determine this. Iptables can hook into this routing procedure at two different points: before and after the procedure has occurred.

Nating with Iptables

csaba ~ # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 89.72.31.243

This command adds a rule as POSTROUTING to the NATing table (-t nat). POSTROUTING essentially means that the packets first pass the routing mechanism on the gateway, and, only after that are they modified. The rule -j SNAT means Source NAT; the source address of the packets will be changed to the address on the interface specified by -o eth0 – in our case, to the IP address specified by the option, --to-source. So, anyone contacted by a computer in your network will assume that it is talking directly to your gateway. It will have absolutely no clue about the fact that the packets are destined for some different computer. The gateway, using iptables, will keep an internal list of all the translated IP addresses, and, when a reply comes, it will revert the change and pass the answer to the computer inside the network.

Allow Client from the Internet to the Email Server

Another problem that we face is what to do when we have a server that is behind a firewall. We need to allow the clients, coming from the Internet, to communicate with our server in some way. This is the case with our mail server. When an email arrives that has to be delivered to a mail account on our server, the sending email server will have to connect to our receiving one.

But our mail server only has a private IP address. There is no way that an external computer could connect to it directly. On the other hand, our gateway has an external IP that anyone could connect to. The solution? Open a port on our gateway so that a request from the Internet to that port will actually go to our email server. The answer, of course, will travel through the gateway back to the client. The trick is to use a different type of NAT here, called Destination NAT. This changes the packets destination and then reverts them back when the response occurs. Think of DNAT as the reverse of SNAT.

Tip: You may know this feature as “Virtual Server,” if you’ve ever played around with small home routers.

csaba ~ # iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 25 -j DNAT --to-destination 192.168.1.2:25

So, what is happening here? A packet comes in to our gateway at the port 25 (the port used for SMTP, the email protocol the whole Internet uses). The rule above catches this packet because of the --dport 25 option, which basically says, “Match anything that goes to this port on the interface specified by -i eth0. Now that the packet is matched, change its destination from the current machine (the gateway) to the one specified by --to-destination.” Please note that you can specify the port explicitly after the IP address by separating it with a colon.

Finally, note that this is in the PREROUTING hook. The destination has to be changed before the routing actually takes place. Otherwise, the packets would end up on the gateway and find no way to the mail server.

Persisting iptables Configuration

The rules you insert or append to iptables are in memory. After a reboot, spoof: everything is gone! To save your configuration, you should dump it into a file, like so:

csaba ~ # iptables-save > /some/directory/my_rules.fw

The file’s name doesn’t matter, nor does its extension. To restore the rules, run this command when your computer starts.

iptables-restor < /some/directory/my_rules.fw

If you take a look at the saved content, you’ll see that they’re the same parameters that we used with the iptables commands. There are some minor differences, but you can easily understand the saved file, and could even write your own such files by hand and load them.

Final Thoughts

In closing, here are some thoughts on when and when not to use a firewall with a Linux computer.

Use a firewall on Linux when you configure a server (like a gateway in our example), or when you have a computer with important information on it that is directly exposed to the Internet. Before you jump on to configure your iptables, consider the potential danger. Ask yourself: is my computer known on the Internet? There are a few billion computers out there. If yours is just one, the chance of being targeted is incredibly low. Are there people directly interested in your information? Hackers don’t waste time stealing random data in the hopes that they might find something. They usually know what they are looking for, and then target the computers containing the desired information. Of course, there are countless attacks against random computers that attempt to install some kind of worm or virus, but on Linux, you are immune by design.

Don’t waste your time with configuring a firewall on Linux when it is a computer that is alway behind a firewall, such as your home PC behind your home router, or when you have no particularly important information on your laptop. If you keep the services that listen on the network to a minimum and have a decently secure password, you can forget your firewall. I personally have no personal computer, laptop or smartphone with a firewall running. I have, however, a home router with a well-configured firewall.

I think you can safely apply these ideas to Mac OSX as well. If you’re a Windows user, sorry: a firewall is your first line of defense. For Linux or MacOSX, though, a firewall is your last line of defense. A carefully selected password and not running useless services should handle the bulk of your computer’s protection.

Thanks for reading. Questions?

Tuts+ Premium Cash Back Offer: 3 Days to Go

Joel Bankhead — Fri, 17 May 2013 17:00:56 +0000

This offer ends soon! Act now and don’t miss out on cash back when trying a monthly Tuts+ Premium subscription.

At $19 a month, Tuts+ Premium is fantastic value. But it’s even better when we hand your first $19 right back to you!

For a limited time, we’re offering $19 cash back to new Tuts+ Premium monthly subscribers when signing up via PayPal. If you’ve been thinking about checking out our extensive library of courses, tutorials, eBooks and guides there’s never been a better time to join up and dive in.

This offer ends at noon on the 20th of May AEST, so act fast.

Become a Tuts+ Premium Member and take your creative & technical skills to a new level.

What can you learn on Tuts+ Premium? Glad you asked! Currently, more than 15,000 members are sharpening their skills in a wide range of areas including web design, web development, Photoshop, vectors, video effects, and many more. With Tuts+ Premium you learn from expert instructors in every field.

Join now and get instant access to your very own library of courses, tutorials, and eBooks, available whenever you need them. Become part of a community of over 15,000 members and start getting better at the skills you care about. Our dedicated team adds new content weekly, so there’s always something fresh to sink your teeth into.

Join Tuts+ Premium

How to Write Testable and Maintainable Code in PHP

Chris Fidao — Wed, 15 May 2013 20:08:11 +0000

Frameworks provide a tool for rapid application development, but often accrue technical debt as rapidly as they allow you to create functionality. Technical debt is created when maintainability isn't a purposeful focus of the developer. Future changes and debugging become costly, due to a lack of unit testing and structure.

Here's how to begin structuring your code to achieve testability and maintainability – and save you time.

We'll Cover (loosely)

DRY
Dependency Injection
Interfaces
Containers
Unit Tests with PHPUnit

Let's begin with some contrived, but typical code. This might be a model class in any given framework.

class User {

public function getCurrentUser()
{
    $user_id = $_SESSION['user_id'];

    $user = App::db->select('id, username')
                    ->where('id', $user_id)
                    ->limit(1)
                    ->get();

    if ( $user->num_results() > 0 )
    {
            return $user->row();
    }

    return false;
}

}

This code will work, but needs improvement:

This isn't testable.
- We're relying on the $_SESSION global variable. Unit-testing frameworks, such as PHPUnit, rely on the command-line, where $_SESSION and many other global variables aren't available.
- We're relying on the database connection. Ideally, actual database connections should be avoided in a unit-test. Testing is about code, not about data.
This code isn't as maintainable as it could be. For instance, if we change the data source, we'll need to change the database code in every instance of App::db used in our application. Also, what about instances where we don't want just the current user's information?

An Attempted Unit Test

Here's an attempt to create a unit test for the above functionality.

class UserModelTest extends PHPUnit_Framework_TestCase {

    public function testGetUser()
    {
        $user = new User();

        $currentUser = $user->getCurrentUser();

        $this->assertEquals(1, $currentUser->id);
    }

}

Let's examine this. First, the test will fail. The $_SESSION variable used in the User object doesn't exist in a unit test, as it runs PHP in the command line.

Second, there's no database connection setup. This means that, in order to make this work, we will need to bootstrap our application in order to get the App object and its db object. We'll also need a working database connection to test against.

To make this unit test work, we would need to:

Setup a config setup for a CLI (PHPUnit) run in our application
Rely on a database connection. Doing this means relying on a data source separate from our unit test. What if our test database doesn't have the data we're expecting? What if our database connection is slow?
Relying on an application being bootstrapped increases the overhead of the tests, slowing the unit tests down dramatically. Ideally, most of our code can be tested independent of the framework being used.

So, let's get down to how we can improve this.

Keep Code DRY

The function retrieving the current user is unnecessary in this simple context. This is a contrived example, but in the spirit of DRY principles, the first optimization I'm choosing to make is to generalize this method.

class User {

    public function getUser($user_id)
    {
        $user = App::db->select('user')
                        ->where('id', $user_id)
                        ->limit(1)
                        ->get();

        if ( $user->num_results() > 0 )
        {
            return $user->row();
        }

        return false;
    }

}

This provides a method we can use across our entire application. We can pass in the current user at the time of the call, rather than passing that functionality off to the model. Code is more modular and maintainable when it doesn't rely on other functionalities (such as the session global variable).

However, this is still not testable and maintainable as it could be. We're still relying on the database connection.

Dependency Injection

Let's help improve the situation by adding some Dependency Injection. Here's what our model might look like, when we pass the database connnection into the class.

class User {

    protected $_db;

    public function __construct($db_connection)
    {
        $this->_db = $db_connection;
    }

    public function getUser($user_id)
    {
        $user = $this->_db->select('user')
                        ->where('id', $user_id)
                        ->limit(1)
                        ->get();

        if ( $user->num_results() > 0 )
        {
            return $user->row();
        }

        return false;
    }

}

Now, the dependencies of our User model are provided for. Our class no longer assumes a certain database connection, nor relies on any global objects.

At this point, our class is basically testable. We can pass in a data-source of our choice (mostly) and a user id, and test the results of that call. We can also switch out separate database connections (assuming that both implement the same methods for retrieving data). Cool.

Let's look at what a unit test might look like for that.

<?php

use Mockery as m;
use Fideloper\User;

class SecondUserTest extends PHPUnit_Framework_TestCase {

    public function testGetCurrentUserMock()
    {
        $db_connection = $this->_mockDb();

        $user = new User( $db_connection );

        $result = $user->getUser( 1 );

        $expected = new StdClass();
        $expected->id = 1;
        $expected->username = 'fideloper';

        $this->assertEquals( $result->id, $expected->id, 'User ID set correctly' );
        $this->assertEquals( $result->username, $expected->username, 'Username set correctly' );
    }

    protected function _mockDb()
    {
        // "Mock" (stub) database row result object
        $returnResult = new StdClass();
        $returnResult->id = 1;
        $returnResult->username = 'fideloper';

        // Mock database result object
        $result = m::mock('DbResult');
        $result->shouldReceive('num_results')->once()->andReturn( 1 );
        $result->shouldReceive('row')->once()->andReturn( $returnResult );

        // Mock database connection object
        $db = m::mock('DbConnection');

        $db->shouldReceive('select')->once()->andReturn( $db );
        $db->shouldReceive('where')->once()->andReturn( $db );
        $db->shouldReceive('limit')->once()->andReturn( $db );
        $db->shouldReceive('get')->once()->andReturn( $result );

        return $db;
    }

}

I've added something new to this unit test: Mockery. Mockery lets you "mock" (fake) PHP objects. In this case, we're mocking the database connection. With our mock, we can skip over testing a database connection and simply test our model.

Want to learn more about Mockery?

In this case, we're mocking a SQL connection. We're telling the mock object to expect to have the select, where, limit and get methods called on it. I am returning the Mock, itself, to mirror how the SQL connection object returns itself ($this), thus making its method calls "chainable". Note that, for the get method, I return the database call result – a stdClass object with the user data populated.

This solves a few problems:

We're testing only our model class. We're not also testing a database connection.
We're able to control the inputs and outputs of the mock database connection, and, therefore, can reliably test against the result of the database call. I know I'll get a user ID of "1" as a result of the mocked database call.
We don't need to bootstrap our application or have any configuration or database present to test.

We can still do much better. Here's where it gets interesting.

Interfaces

To improve this further, we could define and implement an interface. Consider the following code.

interface UserRepositoryInterface {
    public function getUser($user_id);
}

class MysqlUserRepository implements UserRepositoryInterface {

    protected $_db;

    public function __construct($db_conn)
    {
        $this->_db = $db_conn;
    }

    public function getUser($user_id)
    {
        $user = $this->_db->select('user')
                    ->where('id', $user_id)
                    ->limit(1)
                    ->get();

        if ( $user->num_results() > 0 )
        {
            return $user->row();
        }

        return false;
    }

}

class User {

    protected $userStore;

    public function __construct(UserRepositoryInterface $user)
    {
        $this->userStore = $user;
    }

    public function getUser($user_id)
    {
        return $this->userStore->getUser($user_id);
    }

}

There's a few things happening here.

First, we define an interface for our user data source. This defines the addUser() method.
Next, we implement that interface. In this case, we create a MySQL implementation. We accept a database connection object, and use it to grab a user from the database.
Lastly, we enforce the use of a class implementing the UserInterface in our User model. This guarantees that the data source will always have a getUser() method available, no matter which data source is used to implement UserInterface.

Note that our User object type-hints UserInterface in its constructor. This means that a class implementing UserInterface MUST be passed into the User object. This is a guarantee we are relying on – we need the getUser method to always be available.

What is the result of this?

Our code is now fully testable. For the User class, we can easily mock the data source. (Testing the implementations of the datasource would be the job of a separate unit test).
Our code is much more maintainable. We can switch out different data sources without having to change code throughout our application.
We can create ANY data source. ArrayUser, MongoDbUser, CouchDbUser, MemoryUser, etc.
We can easily pass any data source to our User object if we need to. If you decide to ditch SQL, you can just create a different implementation (for instance, MongoDbUser) and pass that into your User model.

We've simplified our unit test, as well!

<?php

use Mockery as m;
use Fideloper\User;

class ThirdUserTest extends PHPUnit_Framework_TestCase {

    public function testGetCurrentUserMock()
    {
        $userRepo = $this->_mockUserRepo();

        $user = new User( $userRepo );

        $result = $user->getUser( 1 );

        $expected = new StdClass();
        $expected->id = 1;
        $expected->username = 'fideloper';

        $this->assertEquals( $result->id, $expected->id, 'User ID set correctly' );
        $this->assertEquals( $result->username, $expected->username, 'Username set correctly' );
    }

    protected function _mockUserRepo()
    {
        // Mock expected result
        $result = new StdClass();
        $result->id = 1;
        $result->username = 'fideloper';

        // Mock any user repository
        $userRepo = m::mock('Fideloper\Third\Repository\UserRepositoryInterface');
        $userRepo->shouldReceive('getUser')->once()->andReturn( $result );

        return $userRepo;
    }

}

We've taken the work of mocking a database connection out completely. Instead, we simply mock the data source, and tell it what to do when getUser is called.

But, we can still do better!

Containers

Consider the usage of our current code:

// In some controller
$user = new User( new MysqlUser( App:db->getConnection("mysql") ) );
$user->id = App::session("user->id");

$currentUser = $user->getUser($user_id);

Our final step will be to introduce containers. In the above code, we need to create and use a bunch of objects just to get our current user. This code might be littered across your application. If you need to switch from MySQL to MongoDB, you'll still need to edit every place where the above code appears. That's hardly DRY. Containers can fix this.

A container simply "contains" an object or functionality. It's similar to a registry in your application. We can use a container to automatically instantiate a new User object with all needed dependencies. Below, I use Pimple, a popular container class.

// Somewhere in a configuration file
$container = new Pimple();
$container["user"] = function() {
    return new User( new MysqlUser( App:db->getConnection('mysql') ) );
}

// Now, in all of our controllers, we can simply write:
$currentUser = $container['user']->getUser( App::session('user_id') );

I've moved the creation of the User model into one location in the application configuration. As a result:

We've kept our code DRY. The User object and the data store of choice is defined in one location in our application.
We can switch out our User model from using MySQL to any other data source in ONE location. This is vastly more maintainable.

Final Thoughts

Over the course of this tutorial, we accomplished the following:

Kept our code DRY and reusable
Created maintainable code – We can switch out data sources for our objects in one location for the entire application if needed
Made our code testable – We can mock objects easily without relying on bootstrapping our application or creating a test database
Learned about using Dependency Injection and Interfaces, in order to enable creating testable and maintainable code
Saw how containers can aid in making our application more maintainable

I'm sure you've noticed that we've added much more code in the name of maintainability and testability. A strong argument can be made against this implementation: we're increasing complexity. Indeed, this requires a deeper knowledge of code, both for the main author and for collaborators of a project.

However, the cost of explanation and understanding is far out-weighed by the extra overall decrease in technical debt.

The code is vastly more maintainable, making changes possible in one location, rather than several.
Being able to unit test (quickly) will reduce bugs in code by a large margin – especially in long-term or community-driven (open-source) projects.
Doing the extra-work up front will save time and headache later.

Resources

You may include Mockery and PHPUnit into your application easily using Composer. Add these to your "require-dev" section in your composer.json file:

"require-dev": {
    "mockery/mockery": "0.8.*",
    "phpunit/phpunit": "3.7.*"
}

You can then install your Composer-based dependencies with the "dev" requirements:

$ php composer.phar install --dev

Learn more about Mockery, Composer and PHPUnit here on Nettuts+.

For PHP, consider using Laravel 4, as it makes exceptional use of containers and other concepts written about here.

Thanks for reading!

Real Time Chat With NodeJS, Socket.io and ExpressJS

Krasimir Tsonev — Tue, 14 May 2013 17:57:14 +0000

NodeJS gives me the ability to write back-end code in one of my favorite languages: JavaScript. It's the perfect technology for building real time applications. In this tutorial, I'll show you how to build a web chat application, using ExpressJS and Socket.io.

Setup Environment

Of course, the first thing to do is get NodeJS installed on your system. If you are a Windows or Mac user, you can visit nodejs.org and download the installer. If you instead prefer Linux, I'd suggest that you refer to this link. Although I won’t go into further details on this, if you encounter any installation issues, I’m happy to help; just leave a comment below this post.

Once you have NodeJS installed, you’re ready to setup the needed instruments.

ExpressJS – this will manage the server and the response to the user
Jade – template engine
Socket.io – allows for real time communication between the front-end and back-end

Continuing on, within an empty directory, create a package.json file with the following content.

{
    "name": "RealTimeWebChat",
    "version": "0.0.0",
    "description": "Real time web chat",
    "dependencies": {
        "socket.io": "latest",
        "express": "latest",
        "jade": "latest"
    },
    "author": "developer"
}

By using the console (under Windows – command prompt), navigate to your folder and execute:

npm install

Within a few seconds, you’ll have all the necessary dependencies downloaded to the node_modules directory.

Developing the Backend

Let’s begin with a simple server, which will deliver the application's HTML page, and then continue with the more interesting bits: the real time communication. Create an index.js file with the following core expressjs code:

var express = require("express");
var app = express();
var port = 3700;

app.get("/", function(req, res){
    res.send("It works!");
});

app.listen(port);
console.log("Listening on port " + port);

Above, we’ve created an application and defined its port. Next, we registered a route, which, in this case, is a simple GET request without any parameters. For now, the route’s handler simply sends some text to the client. Finally, of course, at the bottom, we run the server. To initialize the application, from the console, execute:

node index.js

The server is running, so you should be able to open http://127.0.0.1:3700/ and see:

It works!

Now, instead of "It works" we should serve HTML. Instead of pure HTML, it can be beneficial to use a template engine. Jade is an excellent choice, which has good integration with ExpressJS. This is what I typically use in my own projects. Create a directory, called tpl, and put the following page.jade file within it:

!!!
html
    head
        title= "Real time web chat"
    body
        #content(style='width: 500px; height: 300px; margin: 0 0 20px 0; border: solid 1px #999; overflow-y: scroll;')
        .controls
            input.field(style='width:350px;')
            input.send(type='button', value='send')

The Jade's syntax is not so complex, but, for a full guide, I suggest that you refer to jade-lang.com. In order to use Jade with ExpressJS, we require the following settings.

app.set('views', __dirname + '/tpl');
app.set('view engine', "jade");
app.engine('jade', require('jade').__express);
app.get("/", function(req, res){
    res.render("page");
});

This code informs Express where your template files are, and which template engine to use. It all specifies the function that will process the template's code. Once everything is setup, we can use the .render method of the response object, and simply send our Jade code to the user.

The output isn’t special at this point; nothing more than a div element (the one with id content), which will be used as a holder for the chat messages and two controls (input field and button), which we will use to send the message.

Because we will use an external JavaScript file that will hold the front-end logic, we need to inform ExpressJS where to look for such resources. Create an empty directory, public, and add the following line before the call to the .listen method.

app.use(express.static(__dirname + '/public'));

So far so good; we have a server that successfully responds to GET requests. Now, it’s time to add Socket.io integration. Change this line:

app.listen(port);

to:

var io = require('socket.io').listen(app.listen(port));

Above, we passed the ExpressJS server to Socket.io. In effect, our real time communication will still happen on the same port.

Moving forward, we need to write the code that will receive a message from the client, and send it to all the others. Every Socket.io application begins with a connection handler. We should have one:

io.sockets.on('connection', function (socket) {
    socket.emit('message', { message: 'welcome to the chat' });
    socket.on('send', function (data) {
        io.sockets.emit('message', data);
    });
});

The object, socket, which is passed to your handler, is actually the socket of the client. Think about it as a junction between your server and the user's browser. Upon a successful connection, we send a welcome type of message, and, of course, bind another handler that will be used as a receiver. As a result, the client should emit a message with the name, send, which we will catch. Following that, we simply forward the data sent by the user to all other sockets with io.sockets.emit.

With the code above, our back-end is ready to receive and send messages to the clients. Let's add some front-end code.

Developing the Front-end

Create chat.js, and place it within the public directory of your application. Paste the following code:

window.onload = function() {

    var messages = [];
    var socket = io.connect('http://localhost:3700');
    var field = document.getElementById("field");
    var sendButton = document.getElementById("send");
    var content = document.getElementById("content");

    socket.on('message', function (data) {
        if(data.message) {
            messages.push(data.message);
            var html = '';
            for(var i=0; i<messages.length; i++) {
                html += messages[i] + '<br />';
            }
            content.innerHTML = html;
        } else {
            console.log("There is a problem:", data);
        }
    });

    sendButton.onclick = function() {
        var text = field.value;
        socket.emit('send', { message: text });
    };

}

Our logic is wrapped in a .onload handler just to ensure that all the markup and external JavaScript is fully loaded. In the next few lines, we create an array, which will store all the messages, a socket object, and few shortcuts to our DOM elements. Again, similar to the back-end, we bind a function, which will react to the socket's activity. In our case, this is an event, named message. When such an event occurs, we expect to receive an object, data, with the property, message. Add that message to our storage and update the content div. We’ve also included the logic for sending the message. It’s quite simple, simply emitting a message with the name, send.

If you open http://localhost:3700, you will encounter some errors popup. That's because we need to update page.jade to contain the necessary JavaScript files.

head
    title= "Real time web chat"
    script(src='/chat.js')
    script(src='/socket.io/socket.io.js')

Notice that Socket.io manages the delivery of socket.io.js. You don't have to worry about manually downloading this file.

We can again run our server with node index.js in the console and open http://localhost:3700. You should see the welcome message. Of course, if you send something, it should be shown in the content's div. If you want to be sure that it works, open a new tab (or, better, a new browser) and load the application. The great thing about Socket.io is that it works even if you stop the NodeJS server. The front-end will continue to work. Once the server is booted up again, your chat will be fine too.

In its current state, our chat is not perfect, and requires some improvements.

Improvements

The first change that we need to make is to the identity of the messages. Currently, it's not clear which messages is sent by whom. The good thing is that we don't have to update our NodeJS code to achieve this. That's because the server simply forwards the data object. So, we need to add a new property there, and read it later. Before making corrections to chat.js, let’s add a new input field, where the user may add his/her name. Within page.jade, change the controls div:

.controls
    | Name: 
    input#name(style='width:350px;')
    br
    input#field(style='width:350px;')
    input#send(type='button', value='send')

Next, in code.js:

window.onload = function() {

    var messages = [];
    var socket = io.connect('http://localhost:3700');
    var field = document.getElementById("field");
    var sendButton = document.getElementById("send");
    var content = document.getElementById("content");
    var name = document.getElementById("name");

    socket.on('message', function (data) {
        if(data.message) {
            messages.push(data);
            var html = '';
            for(var i=0; i<messages.length; i++) {
                html += '<b>' + (messages[i].username ? messages[i].username : 'Server') + ': </b>';
                html += messages[i].message + '<br />';
            }
            content.innerHTML = html;
        } else {
            console.log("There is a problem:", data);
        }
    });

    sendButton.onclick = function() {
        if(name.value == "") {
            alert("Please type your name!");
        } else {
            var text = field.value;
            socket.emit('send', { message: text, username: name.value });
        }
    };

}

To summarize the changes, we’ve:

Added a new shortcut for the username's input field
Updated the presentation of the messages a bit
Appended a new username property to the object, which is sent to the server

If the the number of messages becomes too high, the user will need to scroll the div:

content.innerHTML = html;
content.scrollTop = content.scrollHeight;

Keep in mind that the above solution will likely not work in IE7 and below, but that’s okay: it’s time for IE7 to fade away. However, if you want to ensure support, feel free to use jQuery:

$("#content").scrollTop($("#content")[0].scrollHeight);

It would also be nice if the input field is cleared after sending the message:

socket.emit('send', { message: text, username: name.value });
field.value = "";

The final boring problem is the clicking of the send button each time. With a touch of jQuery, we can listen for when the user presses the Enter key.

$(document).ready(function() {
    $("#field").keyup(function(e) {
        if(e.keyCode == 13) {
            sendMessage();
        }
    });
});

The function, sendMessage, could be registered, like so:

sendButton.onclick = sendMessage = function() {
    ...
};

Please note that this isn’t a best practice, as it is registered as a global function. But, for our little test here, it’ll be fine.

Conclusion

NodeJS is an extremely useful technology, and provides us with a great deal of power and joy, especially when considering the fact that we can write pure JavaScript. As you can see, with only a few lines of code, we managed to write a fully functional real time chat application. Pretty neat!

Want to learn more about building web apps with ExpressJS? We’ve got you covered!

Mass Assignment, Rails, and You

Arun Srinivasan — Mon, 13 May 2013 18:00:20 +0000

Early in 2012, a developer, named Egor Homakov, took advantage of a security hole at Github (a Rails app) to gain commit access to the Rails project.

His intent was mostly to point out a common security issue with many Rails apps that results from a feature, known as mass assignment (and did so rather loudly). In this article, we'll review what mass assignment is, how it can be a problem, and what you can do about it in your own applications.

What is Mass Assignment?

To begin, let's first take a look at what mass assignment means, and why it exists. By way of an example, imagine that we have the following User class in our application:

# Assume the following fields: [:id, :first, :last, :email]
class User < ActiveRecord::Base
end

Mass assignment allows us to set a bunch of attributes at once:

attrs = {:first => "John", :last => "Doe", :email => "john.doe@example.com"}
user = User.new(attrs)
user.first #=> "John"
user.last  #=> "Doe"
user.email #=> "john.doe@example.com"

Without the convenience of mass assignment, we'd have to write an assignment statement for each attribute to achieve the same result. Here’s an example:

attrs = {:first => "John", :last => "Doe", :email => "john.doe@example.com"}
user = User.new
user.first = attrs[:first]
user.last  = attrs[:last]
user.email = attrs[:email]
user.first #=> "John"
user.last  #=> "Doe"
user.email #=> "john.doe@example.com"

Obviously, this can get tedious and painful; so we bow at the feet of laziness and say, yes yes, mass assignment is a good thing.

The (Potential) Problem With Mass Assignment

One problem with sharp tools is that you can cut yourself with them.

But wait! One problem with sharp tools is that you can cut yourself with them. Mass assignment is no exception to this rule.

Suppose now that our little imaginary application has acquired the ability to fire missiles. As we don't want the world to turn to ash, we add a boolean permission field to the User model to decide who can fire missiles.

class AddCanFireMissilesFlagToUsers < ActiveRecord::Migration
  def change
    add_column :users, :can_fire_missiles, :boolean, :default => false
  end
end

Let's also assume that we have a way for users to edit their contact information: this might be a form somewhere that is accessible to the user with text fields for the user's first name, last name, and email address.

Our friend John Doe decides to change his name and update his email account. When he submits the form, the browser will issue a request similar to the following:

PUT http://missileapp.com/users/42?user[first]=NewJohn&user[email]=john.doe@newemail.com

The update action within the UsersController might look something like:

def update
  user = User.find(params[:id])
  if user.update_attributes(params[:user]) # Mass assignment!
    redirect_to home_path
  else
    render :edit
  end
end

Given our example request, the params hash will look similar to:

{:id => 42, :user => {:first => "NewJohn", :email => "john.doe@newemail.com"}
# :id - parsed by the router
# :user - parsed from the incoming querystring

Now let's say that NewJohn gets a little sneaky. You don't necessarily need a browser to issue an HTTP request, so he writes a script that issues the following request:

PUT http://missileapp.com/users/42?user[can_fire_missiles]=true

Fields, like :admin, :owner, and :public_key, are quite easily guessable.

When this request hits our update action, the update_attributes call will see {:can_fire_missiles => true}, and give NewJohn the ability to fire missiles! Woe has become us.

This is exactly how Egor Homakov gave himself commit access to the Rails project. Because Rails is so convention-heavy, fields like :admin, :owner, and :public_key are quite easily guessable. Further, if there aren't protections in place, you can gain access to things that you're not supposed to be able to touch.

How to Deal With Mass Assignment

So how do we protect ourselves from wanton mass assignment? How do we prevent the NewJohns of the world from firing our missiles with reckless abandon?

Luckily, Rails provides a couple tools to manage the issue: attr_protected and attr_accessible.

`attr_protected`: The BlackList

Using attr_protected, you can specify which fields may never be mass-ly assignable:

class User < ActiveRecord::Base
  attr_protected :can_fire_missiles
end

Now, any attempt to mass-assign the can_fire_missiles attribute will fail.

`attr_accessible`: The WhiteList

The problem with attr_protected is that it's too easy to forget to add a newly implemented field to the list.

This is where attr_accessible comes in. As you might have guessed, it's the opposite of attr_protected: only list the attributes that you want to be mass-assignable.

As such, we can switch our User class to this approach:

class User < ActiveRecord::Base
  attr_accessible :first, :last, :email
end

Here, we're explicitly listing out what can be mass-assigned. Everything else will be disallowed. The advantage here is that if we, say, add an admin flag to the User model, it will automatically be safe from mass-assignment.

As a general rule, you should prefer attr_accessible to attr_protected, as it helps you err on the side of caution.

Mass Assignment Roles

Rails 3.1 introduced the concept of mass-assignment "roles". The idea is that you can specify different attr_protected and attr_accessible lists for different situations.

class User < ActiveRecord::Base
  attr_accessible :first, :last, :email             # :default role
  attr_accessible :can_fire_missiles, :as => :admin # :admin role
end

user = User.new({:can_fire_missiles => true}) # uses the :default role  
user.can_fire_missiles #=> false  

user2 = User.new({:can_fire_missiles => true}, :as => :admin)  
user.can_fire_missiles #=> true

Application-wide Configuration

You can control mass assignment behavior in your application by editing the config.active_record.whitelist_attributes setting within the config/application.rb file.

If set to false, mass assignment protection will only be activated for the models where you specify an attr_protected or attr_accessible list.

If set to true, mass assignment will be impossible for all models unless they specify an attr_protected or attr_accessible list. Please note that this option is enabled by default from Rails 3.2.3 forward.

Strictness

Beginning with Rails 3.2, there is additionally a configuration option to control the strictness of mass assignment protection: config.active_record.mass_assignment_sanitizer.

If set to :strict, it will raise an ActiveModel::MassAssignmentSecurity::Error any time that your application attempts to mass-assign something it shouldn't. You'll need to handle these errors explicitly. As of v3.2, this option is set for you in the development and test environments (but not production), presumably to help you track down where mass-assignment issues might be.

If not set, it will handle mass-assignment protection silently - meaning that it will only set the attributes it's supposed to, but won't raise an error.

Rails 4 Strong Parameters: A Different Approach

Mass assignment security is really about handling untrusted input.

The Homakov Incident initiated a conversation around mass assignment protection in the Rails community (and onward to other languages, as well); an interesting question was raised: does mass assignment security belong in the model layer?

Some applications have complex authorization requirements. Trying to handle all special cases in the model layer can begin to feel clunky and over-complicated, especially if you find yourself plastering roles all over the place.

A key insight here is that mass assignment security is really about handling untrusted input. As a Rails application receives user input in the controller layer, developers began wondering whether it might be better to deal with the issue there instead of ActiveRecord models.

The result of this discussion is the Strong Parameters gem, available for use with Rails 3, and a default in the upcoming Rails 4 release.

Assuming that our missile application is bult on Rails 3, here's how we might update it for use with the stong parameters gem:

Add the gem

Add the following line to the Gemfile:

gem strong_parameters

Turn off model-based mass assignment protection

Within config/application.rb:

config.active_record.whitelist_attributes = false

Tell the models about it

class User < ActiveRecord::Base
  include ActiveModel::ForbiddenAttributesProtection
end

Update the controllers

class UsersController < ApplicationController
  def update
    user = User.find(params[:id])
    if user.update_attributes(user_params) # see below
      redirect_to home_path
    else
      render :edit
    end
  end

  private

  # Require that :user be a key in the params Hash,
  # and only accept :first, :last, and :email attributes
  def user_params
    params.require(:user).permit(:first, :last, :email)
  end
end

Now, if you attempt something like user.update_attributes(params), you'll get an error in your application. You must first call permit on the params hash with the keys that are allowed for a specific action.

The advantage to this approach is that you must be explicit about which input you accept at the point that you're dealing with the input.

Note: If this was a Rails 4 app, the controller code is all we'd need; the strong parameters functionality will be baked in by default. As a result, you won't need the include in the model or the separate gem in the Gemfile.

Wrapping Up

Mass assignment can be an incredibly useful feature when writing Rails code. In fact, it's nearly impossible to write reasonable Rails code without it. Unfortunately, mindless mass assignment is also fraught with peril.

Hopefully, you're now equipped with the necessary tools to navigate safely in the mass assignment waters. Here's to fewer missiles!

Master Developers: Addy Osmani

Rey Bango — Fri, 10 May 2013 15:09:13 +0000

A bright star in the JavaScript community, Addy Osmani has skyrocketed to prominence not only for his fabulous JavaScript articles and open source contributions but for also being one of the friendliest and approachable developers around.

His blog is a treasture trove of front-end knowledge and well-worth the visit. In this post, we'll chat with Addy about how he got his feet wet in JS and bring up some tough topics relating to his work in developer relations at Google.

Q You took to JavaScript like a fish to water. How'd you get so entrenched in the JS world?

JavaScript was going to play a large role in making this possible.

I wrote some of my first JavaScript back when Netscape Navigator was the dominant browser. Dynamic front-end development was only slowly starting to becoming more popular at the time, but the idea of being able to write something with just HTML/CSS/JS and have it work everywhere was powerful. I got hooked on to that idea and have been ever since. Some of my first creations were little things you would laugh at today – calculators, password generators, nothing too amazing.

As a language enthusiast, I liked that JavaScript was prototype-based and weakly typed, so I decided to continued learning it alongside other languages like C++. Back in the early 2000's, I tried bridging the languages by writing a little interpreter on top of SpiderMonkey (Mozilla's JavaScript engine), which let me write logic for my desktop apps in JS and define UI components using C++. It was a silly idea, but I learned a lot about JavaScript engine internals in the process.

I spent a lot of time building small hobby sites, but when I was in my last year at high-school, I decided to really get stuck into the world of browser internals. I wrote a lightweight rendering engine, basic HTML 4.01/CSS 2.1 parsers and wrapped all of these parts into my own little browser. The project was a nightmare to get working reliably, in part due to how lax web developers were with standards-compliance in their pages – it's funny being on the other side of the fence now! The larger challenges were spec-compliance, rendering large tables and maintaining performance, whilst loading up video plugins (anyone remember good ol' ActiveX?).

I continued learning and using JavaScript as a freelance web developer while in college, slowly writing more complex sites and playing around with Dojo. It wasn't, however, until I got an invitation to GMail in 2006 that it occurred to me that the browser was going to be the next platform for building rich applications. JavaScript was going to play a large role in making this possible and I decided to walk away from desktop app development permanently.

Since then, I've been trying to continue learning and where I can, push the front-end community forward through my writing and contributions to open-source. JavaScript is virtually everywhere today, and it's one of the reasons why I love the language. If I want to teach one of my kids how to author JavaScript, I can just pop-open my browser DevTools and show them. No additional compilation steps needed – there's something really special about that.

Q You produce a LOT of content; I'm sure people are wondering how you do it. Can you share your secrets for not only generating this content, but actually understanding what you're writing about?

If you leap into any non-trivial topic with that mindset, it's necessary to break it down into simple, more easily digestible steps

The secret is that I consider myself to be somewhat stupid. Really. If you leap into any non-trivial topic with that mindset, it's necessary to break it down into simple, more easily digestible steps in order for it to make any semblance of sense.

It's this perspective that I think makes my writing feel accessible – I try to make sense of those concepts or tools that can initially feel quite daunting to the average developer. It's important to be able to apply this to articles and especially documentation. So, keep it simple. This helps make articles more focused. How do I generate so much content whilst understanding the material?. Well, I make understanding a prerequisite.

First do it, then do it right, then do it better.

Einstein has this great quote: "If you can't explain it simply, you don't understand it well enough" and it's true. You cannot teach about or claim a framework, tool or best practice, unless you've actually taken the time to use it yourself. Finding this time is easier in my current role, but back in my days as a 9-5 engineer, I would spend time over breakfast and lunch actively using what I would later write about on the weekend.

Finding time to get everything done is always a challenge. For the past few years, I have this mantra that I try to apply to every task – “First do it, then do it right, then do it better” – it's all about setting realistic goals for yourself and iterating fast as soon as you have something that just works. It won't be the most eloquently written article, nor the most beautiful code, but it's a simple baseline you can build on.

You can then share this first iteration with your peers and get a feel for whether you're going in the right direction or the idea is worth pursuing. To me, that makes a great deal more sense than spending weeks on a draft or prototype before asking for input.

Q You were at AOL before. What are the differences in the culture there versus Google, and how has it impacted your views on software development?

There's something special about being a part of a company with such high standards.

Both AOL and Google are companies with terrific engineering teams, and any of my reflections of culture aren't about any specific groups, more a general observation.

The engineering culture at Google is such that we care a lot about polish and shipping things when we feel they're just right. There's something special about being a part of a company with such high standards.

At AOL, I was proud of any of the products or applications we completed, but due to the fast-paced nature of business and competition, delaying launches or releases for polish wasn't always feasible. I think that's a reality for many businesses, despite any desire they may have to change that culture.

When it is possible to delay releases to, as Google say, get it "right" I think it can make a world of difference to your users first impressions of your product.

Q What are you thoughts on the state of the JavaScript community and the direction the TC39 group is taking with respect to ES6?

I'm pleased with the direction TC39 have been taking over the past few years.

I'm pleased with the direction TC39 have been taking over the past few years, which in part has been helped with the involvement of Rick Waldron and Yehuda Katz from the jQuery project. They've paid close attention to the patterns and libraries developers have been heavily relying on, and investigating how these could be better solved using platform primitives. I won't comment on ES6 specifically, but I'm looking forward to seeing modules, classes, 'let' and Object.observe() available more widely.

On the JavaScript community: we're in a good place but the one thing I wish we would collectively do is spend less time creating new frameworks and more time investing in efforts to improve existing solutions. I think it's fantastic that developers are spending time learning how to solve problems on their own – it's one of the best ways to learn new things – but if it's an experiment, make that clear so that other developers don't expect you to maintain the project. That type of thing only adds to the noise, so please keep support in mind when releasing things!.

Q A lot of people view Google's forking of WebKit as a play to allow them to embed Dart into Chrome. Do you see Dart being Google's ideal over JavaScript?

One of the big myths out there is that it exists to replace JavaScript.

I was actually super curious to learn more about the goals Dart had when I first joined Google. One of the big myths out there is that it exists to replace JavaScript, but it turns out that this isn't quite true. Dart is targeted at those developers more familiar with Java, C++, C#, who are trying to build high-performance web apps; and so on that, have certain expectations around their tooling and language. I think that's a legitimate reason for something like Dart to exist.

As a company, both JavaScript and Dart are technologies that we believe in and invest in. We participate in TC39, working on the future of JavaScript and also continue work on V8, the fast JavaScript engine. The Chrome engineers continue to work to push the web forward with new specs like Web Components. Meanwhile, the team that originally built V8 is now building the Dart VM.

Back to your original question – I believe forking WebKit was a lot more to do with the divergence of the multi-process architecture between both projects than trying to embed Dart into Chrome. Dart's a separate open-source project with it's own goals and you can still get Dartium today (the build of Chromium using the Dart VM).

Q Now that Blink is in the works, how do you think this help the web, and what do you feel are some new challenges that web developers will face with yet another rendering engine to think about?

When I first heard the news about Blink, I was concerned that we'd now have another browser to support.

The reality, however, is that there have already been so many differences between the various WebKit ports that this isn't going to negatively impact how you develop and test.

In fact, Blink allows us to give developers more of the tools, features and compatibility they need to get the most out of the web as a platform. Long-term it's going to let us prioritise features that will ease building the next generation of web apps and in the same way that V8 gave us a way to speed up JavaScript, I think Blink is going to let us innovate in ways that will benefit the whole platform.

Q Google is in an interesting position, where they're heavily vested in both native apps (Android) and web experiences. As you do developer relations at Google, how do you balance the business directives and priorities for both ecosystems?

We get caught up in the debate about native vs. web quite often these days, but don't talk as much about the need to put our users first. They're the focus. There are many cases where you can deliver a compelling experience for the web on desktop and mobile and it'll work fantastic. That said, there are others, where either the platform or mobile browsers still need work. As a business, you often need to make a call on what makes the most sense for your users. I think that, at present, it makes a great deal of sense to offer developers the best platforms possible for making a call on native vs web, and that's what we do, via Android and Chrome for Mobile.

Q Stripping away specific web technologies, what should developers be thinking about at a higher level when it comes to the future of the web?

Reusable components.

Reusable components. Traditionally, a lot of us have developed applications quite vertically, spreading a single concept (whether it be logic or UI) across a few different parts of the project. Not only does this make it harder to maintain the idea but it also makes it difficult to extract and reuse the idea in future applications without a great deal of effort. It also decreases our chances of being able to share the component with others.

Without referring to specific technologies, we're working on making it easier to define and package up components on the web platform side, and now is a great time to start thinking about how your own apps might be written, if they were broken down into specific components.

Q Staying on this track, what are the key technologies, end-to-end, that you feel are making the most impact to pushing the web forward? Why?

The front-end is seeing a revolution in tooling at the moment with an increasing number of developers starting to use Grunt and explore workflow tools around it like Yeoman. Developers are paying more attention to what they can automate and I think that this will help facilitate more time spending building better apps and less time on those manual processes in between.

Going back to the components idea, I think that between web components and front-end package management we have a huge opportunity to really shift the way we develop for the web. AngularJS (and Angular directives) have done a great job of re-introducing the idea of reusable blocks of functionality and things are really looking up on the package management side of things, through Bower.

Writing an app with lists you want to make sortable? Great. A few keystrokes at the command-line and you've got that. Want to make the items in that list persist when you're offline? No problem. A few more keystrokes and you're using a package another developer once had to write to get that capability. Want to turn your list into a reusable component anyone else can use? That's easy. That's the future we're working towards.

Q Yeoman is your new baby. Why did you feel the need to spin up such an ambitious effort when existing projects seemed to be filling the need?

We're fortunate to have a wealth of helpful tools at our disposal on the front-end these days â€“ tools that save us time and make our lives just a little bit easier. Abstractions like Sass and CoffeeScript, frameworks like Twitter Bootstrap, module loaders like RequireJS, a never-ending list of MVC and unit testing librariesâ€¦some would say we're spoiled for choice and it's interesting seeing how long it can take you to get a project started up.

Are you still manually refreshing your browser whenever you make a change to your app?

As much as these tools work exceptionally well on their own, it can be a tedious process getting them to work together, especially if you have to put together a workflow and build process where they all compile and get optimized succinctly. Even if you do manage to get a solid build process in place, you're often left having to spend a great deal of time writing out the boilerplate code for your application.

Even then, you have to ask yourself how well this fits in with your day to day workflow. There are several little steps we repetitively do while developing which can more easily be handed off to tooling. Are you still manually refreshing your browser whenever you make a change to your app to preview how they look? Still trying to figure out whether you're using the latest versions of all your dependencies? Wondering if there was just something that let you get on with coding and forget about a lot of the grunt work?

We were too, which is why we started looking at whether we could give developers a solution to many of these common problems. We tried solving them in a free, open-source project we recently released called Yeoman. Yeoman's official tagline is that we're a â€œrobust and opinionated client-side stack, comprised of tools and frameworks that can help developers quickly build compelling web applicationsâ€.

Practically, we're a series of tools and tasks that help you achieve automate some of the more tedious tasks in front-end development. We're composed of yo (the scaffolding tool), grunt (the build tool) and bower (for package management).

If you find that you're still writing boilerplate code for your application, manually managing the dependencies for your apps or putting together your own build system to work with the tools you love, you might find Yeoman a nice way to save yourself some headache.

Q When you launched Yeoman, Windows wasn't initially supported. What were the challenges you faced with supporting it, and how can the Windows developer community help in these circumstances?

The Windows developer community could really help us here.

Creating a command-line tool that works well cross-platform can be a delicate dance. One of the initial challenges with Windows support was that a lot of our team were used to using a *nix system and having access to homebrew/apt-get. We weren't however as well versed in using PowerShell or Chocolatey (the PowerShell-based Windows equivalent to apt-get) and needed time to understand how well these solutions compared to the tools we had available elsewhere.

It then took time to find (or get) all of the packages we required up on Chocolately as we needed git, phantoms, opting and many others. The situation there has greatly improved since our first release and Windows is now officially supported with Yeoman using the instructions on our homepage.

The Windows developer community could really help us here by advocating for more widespread adoption of tools like Chocolately and helping us reach parity with tools like apt-get. Other than that they've been fantastic and we've really appreciated the help and support the Windows developer community have offered us throughout our road to compatibility.

I've got to give a call out to Sindre Sorhus, Mickael Daniels and Paul Irish, all of whom really helped improve our Windows efforts in the early days.

Q Along those lines, I have a question based on totally selfish-motivation, since I use Windows. How can *nix and Windows developers collaborate more effectively so that everyone can contribute?

At the moment, there are a lot of (fantastic) development tools being written which are not just *nix, but Mac specific because making them cross-platform has it's own development costs and overhead. I would love to see more open-discussion and development of tools that can work everywhere, but this can't be done without the help of users.

If there's a tool you want for Windows that you just see on Mac, please be vocal about it – even better, submit a pull request!

Try to find out what it would take to bring it to Windows (and elsewhere) and who knows? Maybe the combined efforts of multiple communities would be enough to make something happen.

Q You've written excellent posts, published books and contributed to top OSS projects, like jQuery and Yeoman. Of all your professional accomplishments, is there one thing that really stands out as a proud moment?

Releasing my first book, Learning JavaScript Design Patterns (with O'Reilly) was probably the accomplishment that's given me the greatest satisfaction. It was my largest writing project, and I made the decision for it to be completely open-source from the start – a call I'll never regret. Making educational material available to anyone, anywhere whether they can afford it has the potential for a great deal of both good.

It also has the potential to increase your book's impact, so if you're an author – please consider doing it. You won't regret it!

Thanks so much to Addy for sitting down with it. If you have any of your own questions for him, I’m sure he won’t mind answering below in the comments!

Learn WordPress Plugin Development with Tuts+ Live Workshops

Joel Bankhead — Fri, 10 May 2013 15:00:17 +0000

We are excited to announce a fantastic new workshop led by Instructor Tom McFarlin: Introduction to WordPress Plugin Development

Are you an aspiring WordPress developer? Are you ready to take the next step and start building your own custom plugins for WordPress? Our newest Tuts+ Live Workshop is the perfect way to get started!

Tickets are a great investment at $99, but places are strictly limited so act fast to make sure you don’t miss out!

Introduction to WordPress Plugin Development

Our newest Tuts+ Live Workshop, Introduction to WordPress Plugin Development, teaches you everything that you need to know to start developing WordPress plugins; from setting up a local development environment, all the way through to building a WordPress plugin that’s ready for release into the WordPress Plugin Repository.

It’s led by Instructor Tom McFarlin, a self-employed WordPress developer who divides his time between running his own WordPress development shop, building plugins for WordPress, blogging every day about software development in the context of WordPress, and working for 8BIT (the team responsible for Standard Theme and WP Daily).

Each weekly workshop will last one hour, running over a five week period. You’ll have the opportunity to follow along with Tom, ask questions live during the workshop, and complete a weekly homework assignment. Not able to make it to the live recording? No problem! All of the workshop recordings will be made available online the day after the live workshop.

Learn more about Introduction to WordPress Plugin Development

Sign Up to Our Newsletter

If you’re interested in future workshops then definitely join the Tuts+ Live Workshops mailing list to stay posted on upcoming workshops and get notified as soon as they’re available, the Early Bird tickets for our previous workshops have all sold out, so it’s worth getting ahead of the game!

We’re really excited about new workshop, Introduction to WordPress Plugin Development, but places are strictly limited so act fast to make sure you don’t miss out!

10 Tips for Learning a New Technology

Pavan Podila — Thu, 09 May 2013 02:07:00 +0000

We live in a very exciting time. Never before has education been so cheaply available to the masses (if not free). The medium, itself, has made tectonic shifts from a classroom setting, to blogs, screencasts and complete university classes, as a set of videos and interactive forums. Given these resources, there’s absolutely no excuse not to dive in and learn. However, with such a wealth of resources, filtering through the options can often become overwhelming. In this article, I will outline a simple process to kick-start your education.

Although my suggestions will primarily pertain to software development, these principles are certainly applicable to other fields.

1. Overcoming Inertia

Learning something new always begins by first overcoming the inertia to make the first move. This is the same inertia you feel when you want to change the TV channel, but the remote isn't nearby! Thankfully, there are some simple techniques to get excited and motivated. One that has worked really well for me is the concept of Tiny Habits. Rather than becoming overwhelmed by the task at hand, take a tiny step and do something to get started. Using the "get the TV remote" example, start by wiggling your toes, then bend forward, then push yourself away from the couch. Next, try to fall off onto the floor, and finally get up. By following a series of tiny steps, you will overcome your inertia and the task won't seem as overwhelming. This same idea can be applied to learning new skills. It’s all about tiny steps.

2 - Watch the Pros

The first step, when picking up a new skill, is to determine what to learn. This could be anything you feel passionate about, and have a genuine interest in exploring further. It’s important to have this strong inclination, as it will provide you with the necessary fuel, during those low times. Once you decide what to learn, be it a new programming language, an application framework, or a tool, research inspiring work done by their respective communities. You may find it on YouTube, Vimeo, HackerNews, blogs or even from one of your Twitter friends. Reviewing what others have done will give you confidence that you, too, can do it!

3 - Let the Information Flow Begin

Once you cross the stage of convincing yourself about the thing you want to learn, it’s time that become a sponge, and start absorbing knowledge. Begin with some Google searching on "beginner tutorials" related to your topic. As you know, Nettuts+ offers hundreds upon hundreds of tutorials. Check here as well. StackOverflow is one place where you will surely find links to a plethora of resources. Alternatively, Quora is an excellent place to search for answers. Once you sift through these links, you may wish to take a more concentrated dose by looking for the best books on the topic. Personally I refer to Amazon for hunting down highly rated books.

4 - Listen and Watch

As you delve deeper into the pool of knowledge, you will want to add other forms of information – namely, podcasts and screencasts. I encourage you to browse through iTunesU, which offers complete classes on a variety of topics from some of the best institutions in the world. This is particularly helpful for those who prefer an academic setting.

These days, there are a handful of websites that offers online education. Look no further than our very own Tuts+ Premium. Hoping to learn PHP or JavaScript? There’s no better resource on the web. Alternatively, you might consider:

You can also watch conference presentations, such as Google IO on YouTube, or Confreaks for free!

5 - Time for Action

The best way to learn is by doing.

Okay, you’ve read countless tutorials, watched videos, and have a better understanding of the technology that you’ve been hoping to learn. What now? Well, it’s time to put your knowledge to the test. Ultimately, the best way to learn is by doing.

Pick a personal project that you can build using this new technology. Design some simple features and implement them. You will most definitely hit some stumbling blocks. When this happens, research the solution on StackOverflow or Google. You are now on a journey to become an expert in that technology. The more failures and road blocks you encounter, the wiser you will be. There is a saying that "the experts are ones who have made the most mistakes." It means they’ve tried crazy things and pushed the limits of a technology. As a result, they’ve acquired an intimate understanding of how it works. With such insight, they are able to bend the tech to their will and wield Jedi powers (for good, of course).

These powers are also within your reach.

6 - Blogging

As you embark on your journey, it’s helpful to chronicle the steps (or missteps) you took along the way. Blogs are easily the most popular form of expression in the tech community. It’s part of our DNA. When you put a pen to your learnings, you’re forcing yourself to become more cohesive in your thoughts, bringing some structure into the dispersed pieces of knowledge that you have accumulated. Who knows, in the process, you just might be educating someone else on the Internet. Pay it forward when you can.

If you’d like to take things a step further (as writers do every day here on Nettuts+), can take this a step further and create screencasts, which is preferred by most visual learners. Overall, blogging helps you build your communication skills, which is as important as the technology you are learning.

7 - Feel the Pulse

Technology matures when people do crazy and sometimes unthinkable things.

Social Networks have become a universal way of staying in touch and discovering new things. Twitter and Facebook are the primary suspects for information, but there are more focused websites, like the previously mentioned Quora, that have a wide-ranging set of topics, which people may vote and comment on. It’s a great place to find answers and opinions from well-known individuals with real-life experiences. In fact, a quick search on Quora for other perspectives on learning, reveals an interesting set of results.

Scanning the ever-growing set of questions on StackOverflow can also be a fun way to review the way in which others are pushing the limits of a particular technology. In fact, technology matures when people do crazy and sometimes unthinkable things with it.

If you want to feel the pulse of a technology, and determine whether it’s worth learning, try a search on StackOverflow to see the breadth and depth of the community. The Most Voted, Featured questions are excellent candidates for this sort of exploration. You can also carry out a similar exploration on GitHub.

8 - Meetups and Conferences

Although social networks are great, nothing can substitute real human connection. It is quite likely that you have a Meetup group in a place near you, where you’ll find several like-minded folks. You will learn about interesting projects that others are working on, while also getting some of your tricky problems solved!. On a related note, conferences, too, are a great place to share experiences and enrich your already growing skill-set.

9 - GitHub

GitHub is the iconic landmark for the world of open-source projects. It’s a treasure trove of knowledge and creativity, expressed in the form of code. Once you feel comfortable with a particular technology, your next step should be to explore GitHub to find interesting projects. Read the source code. Read as much as you can. In doing so, you can learn a variety of things, such as:

How to organize large projects
Interesting libraries that projects are using
Code patterns and overall design
Documentation style
Testing patterns
Solutions to odd issues, pointed out in the Issues section of the project

All of this knowledge is just waiting to be devoured. Interestingly, and to your benefit, it only comes with a simple price tag: curiosity.

10 - Concentrated Learning

If you worry that the process outlined above is too slow, you might also try a fast-track approach. You may have heard about the "Learn X in 24 hours", but that is not what I am referring to. A more pragmatic time-line is probably a few weeks. If that seems reasonable, you can try something like Seven Languages in Seven Weeks or Seven Databases in Seven Weeks. Although these books refer to languages and databases, you could do the same with other technologies.

A slightly different style would be to learn things the "hard way". The idea here is to accept upfront that nobody can master a skill unless it is practiced daily. So to gain expertise, you practice by working through countless exercises. In a similar vein, you also have Katas and Koans, that encourage solving problems in the language of your choice. These will introduce you to concepts and techniques that may initially be alien to you. That’s the point! If you really want to displace yourself from your comfort zone, give them a shot!

Learn an Orthogonal Skill

Your right-brain processes information in a very different fashion.

Programming is primarily a left-brain activity. It leverages the analytical part of the brain that looks for a step-by-step approach to solving problems. To appreciate the power of the right-brain, take up a creative activity, such as painting, 3D-modeling, origami, playing an instrument, or even building photo books out of your family albums. In fact, programming requires a great deal of creativity. You might have already experienced this, if you’ve ever found solutions to obtuse problems in your sleep. This is because your right-brain processes information in a very different fashion, and can compile ideas from all over the place. Andy Hunt, from the pragmatic bookshelf, wrote a book on this topic: Pragmatic Thinking and Learning: Refactor Your Wetware. If you want to be firing on all synapses, pick up a skill orthogonal to what you already do.

Summary

Acquiring a new skill is always exciting. It’s the start of a new experience that will shape your thinking. But first, you must overcome your inertia. Once you do, your journey to absorb knowledge from every facet of the web begins. I hope that the process outlined above has given you some ideas for approaching this long road.

If you have a different approach to learning, I’d love to learn more about it. Feel free to leave a comment, while I leave you with these inspiring links:

Nettuts+

The Right Way to Retinafy Your Websites

Make it Retina First

When Downsampling is Not Good Enough

Polishing Your Downsampled Images

Borders and Strokes

Text

Retina Version

Try to Avoid Images

Tools

Retina-Ready Favicons

How to Make Existing Images Retina-Ready

How to Optimize the File Size of Images

Save Time, Read This Book

Awesome Retina-Ready Sites on the Web

How to Create a PyroCMS Theme

The Folder Structure

Getting Started

Layouts

Partials

Multiple Layout Files

Mobile Layouts

Finished!

The Linux Firewall

Networking Background

TCP/IP

Gateway & Bridge

Definition of a Firewall

The Problem We Will Solve

Iptables Components

Adding Rules to Iptables

Inserting a New Rule

Appending Rules

Allow Computers to Access the Internet

Network Address Translation (NAT)

Nating with Iptables

Allow Client from the Internet to the Email Server

Persisting iptables Configuration

Final Thoughts

Tuts+ Premium Cash Back Offer: 3 Days to Go

How to Write Testable and Maintainable Code in PHP

We'll Cover (loosely)

An Attempted Unit Test

Keep Code DRY

Dependency Injection

Interfaces

Containers

Final Thoughts

Resources

Real Time Chat With NodeJS, Socket.io and ExpressJS

Setup Environment

Developing the Backend

Developing the Front-end

Improvements

Conclusion

Mass Assignment, Rails, and You

What is Mass Assignment?

The (Potential) Problem With Mass Assignment

How to Deal With Mass Assignment

attr_protected: The BlackList

attr_accessible: The WhiteList

Mass Assignment Roles

Application-wide Configuration

Strictness

Rails 4 Strong Parameters: A Different Approach

Add the gem

Turn off model-based mass assignment protection

Tell the models about it

Update the controllers

Wrapping Up

Master Developers: Addy Osmani

Q You took to JavaScript like a fish to water. How'd you get so entrenched in the JS world?

Q You produce a LOT of content; I'm sure people are wondering how you do it. Can you share your secrets for not only generating this content, but actually understanding what you're writing about?

Q You were at AOL before. What are the differences in the culture there versus Google, and how has it impacted your views on software development?

Q What are you thoughts on the state of the JavaScript community and the direction the TC39 group is taking with respect to ES6?

Q A lot of people view Google's forking of WebKit as a play to allow them to embed Dart into Chrome. Do you see Dart being Google's ideal over JavaScript?

Q Now that Blink is in the works, how do you think this help the web, and what do you feel are some new challenges that web developers will face with yet another rendering engine to think about?

Q Google is in an interesting position, where they're heavily vested in both native apps (Android) and web experiences. As you do developer relations at Google, how do you balance the business directives and priorities for both ecosystems?

Q Stripping away specific web technologies, what should developers be thinking about at a higher level when it comes to the future of the web?

Q Staying on this track, what are the key technologies, end-to-end, that you feel are making the most impact to pushing the web forward? Why?

`attr_protected`: The BlackList

`attr_accessible`: The WhiteList