Nettuts+

10 Things I Learned While Interning at YUI

Tilo Mitra — Fri, 25 May 2012 19:54:57 +0000

For eight months, I had the opportunity to intern with the YUI Team at Yahoo, while I was completing my engineering degree. Today, I’d like to share the top ten things that I learned from my experience with YUI.

A Bit of Background

The YUI Team is primarily responsible for the development and maintenance of the YUI Library. The library is a collection of user-interface components, class management tools, and utilities written in JavaScript and CSS that make it easier for developers to create web applications. Unlike other libraries, YUI is not just about DOM manipulation; it has a rich set of class management tools and a robust event system that makes it easier to develop in JavaScript.

Apart from that, the YUI Team is also responsible for YUI Theater, a very popular resource for web developers, along with a myriad of smaller tools such as YUI Builder, YUI Compressor, YUI Test and more.

My role at the team was to primarily help develop components for the library, although I helped out a little bit with YUI Theater as well.

1. Understanding the Library

When I walked into Yahoo on my first day, I had zero real-world experience with YUI. I was familiar with JavaScript, jQuery, HTML/CSS and PHP, but that was basically it when it came to web programming. I’m sure many of you are or have been in the same boat as me.

My first task was to learn the syntax and architecture behind YUI3. Fortunately, I had a good understanding of raw JavaScript, and this helped immeasurably. A lot of front-end engineers know certain libraries really well, but many don’t know how they works under the hood. To build plugins or modules on top of a library (such as YUI3 or jQuery), it’s useful to have a fundamental understanding about how that library works, and in this case, how JavaScript as a language works.

What I learned: Having a fundamental understanding of raw JavaScript (no libraries) forces you to understand the language better and makes you a better developer in the long run.

Think about it. Each JavaScript library is different and has its own idiosyncracies. The only commonality is that they are rooted in JavaScript. Doesn’t it make sense to understand the idiosyncracies of JavaScript first? Take some time out to build something small without using a library. You’ll be glad you did.

Js Fundamentals Links

2. Using Git in a Team

The YUI Team relies on Git as their primarily version control system and the project is hosted on Github. Previous to my internship at YUI, I used Git for my own small projects, and this generally consisted of the following steps:

git pull origin master
git add "<insert a large number file>"
git commit -m "<insert some general comment>"
git push origin master

I’m sure many of you have done what I just described. Generally, as the project time gets longer, the commits get harder to understand! However, in a large team with a dozen developers, this method breaks down really fast. Firstly, master in YUI3 (and many other large projects) is considered to be stable code that has been unit-tested, so commits generally do not go there until a later stage. Generally, each developer works on a separate branch and merges into master once they are confident in their code.

What I learned: You don’t have to be a guru, but understanding the basics of Git (branching, merging, reverting and solving merge conflicts) can go a long way to keeping your repos clean and organized.

A lot of things are possible to do with Git and I’ve found that, rather than learning them ahead of time, it’s more useful to research when you need to do something in particular. More importantly, my experience has taught me to be careful when experimenting with Git. It’s better to ask someone when trying a new command or trying it on a mock repo instead of messing up the commit history of the live repo. :)

Git Basics Links

3. Modular Architecture for Web Apps

Separating code into different JavaScript files to maintain a modular architecture can be painful for new developers. As a result, we often see large JavaScript files with hundreds of lines of code in them.

<DOCTYPE html>
<html>
    <head>
    <script>
        //My entire application's JS right here in one single spot. Uh oh.
    </script>
    ...

This introduces tight coupling between objects and isn’t good practice when it comes to object-oriented programming. Even worse, you may have global variables that makes your app fail in unexpected ways. We’ve all been guilty of this in the past. Luckily, libraries like YUI can help you with this.

What I learned: When writing an entire web application in JavaScript, it’s very important to have well-organized code; maintaining a spaghetti-coded project will only cause you headaches and nightmares.

One of the most important aspects of YUI3 is its modular nature. As a developer, you only pull down the code that you need. This reduces coupling, keeps file sizes small, and improves your code’s readability.

For instance, you could do this in a file called counter.js:

YUI.add("counter", function(Y) {

    //Write code specific to my counter object

}, '1.0', {requires: ['node']); //Say what my counter object code needs to run. YUI will pull these in first.

And then in a separate JS file, such as app.js:

YUI_config = {
    modules: {
        'counter': { fullpath: 'path/to/counter.js', requires:['node'] }
    }
};

YUI().use('counter', function(Y) { //Pull down my counter module.
    var counter = new Y.Counter({…}); //Create a counter instance
});

Instead of having one big file called app.js, we’ve split it up based on functionality into counter.js and app.js.

4. NodeJS and YUI on the Server

The growing popularity of NodeJS made me want to start building some stuff with it. Being a front-end engineer, I like being able to use JavaScript on the server. Although NodeJS is not suitable for everything, it’s worth learning.

JS on the server does not have the same limitations as client-side JS because there is no DOM, but a library such as YUI can still help you with software architecture on the server – things such as class and object management, and custom events.

What I learned: YUI 3 is not all about DOM manipulation — it also contains a robust set of class/object management tools, not to mention our powerful custom events. All of these tools are immediately useful in server-side programming.

Being on the YUI Team, I was able to explore Dav Glass’ NodeJS-YUI3 module, which wraps up YUI functionality for use in a NodeJS environment. Remember that, apart from web sites, NodeJS is a useful tool for creating command-line utilities as well. Having good software architecture is always a big plus!

It comes down to code management

If you aren’t a YUI3 user, I still recommend finding a set of tools to help organize your JavaScript on the server. Due to the inherent async nature of JavaScript and its propensity for callbacks, you need to be careful or you’ll quickly end up with spaghetti-code.

5. Hacking Using YUI

What I learned: Stay focused and keep hacking.

Hacking is one of my favourite things to do when I am trying to learn something new. When trying to learn a new tool, there’s nothing like sitting down and building something with it.

Similar to jQuery, YUI3 has a distinct set of widgets, utilities and CSS frameworks. On one of the Yahoo Hack Days, I had the chance to sit down and try some of these out. As I’m a fan of cricket, I made a mobile web app called Crictainment. Let me outline some of the parts of YUI that I found to be particularly useful for hacking.

Y.ScrollView

Hacking a web app using YUI is pretty straightforward. For example, if you want a scrollview that is flickable with your fingers:

YUI().use("scrollview", function(Y) {

    var scrollview = new Y.ScrollView({
        srcNode:"#scrollable",
        height:"20em"
    });

});

And in the HTML:

<div id="scrollable" class="yui3-scrollview-loading">
<ul>
    <li>AC/DC</li>
    <li>Aerosmith</li>
    <li>Bob Dylan</li>
    <li>Bob Seger</li>
    ...
</ul>
</div>

The scrollview module figures out whether it should be horizontal or vertical based on the width and height of its container. More information on the YUI3 scrollview is here.

Y.Anim

Another useful utility when hacking something is the Animation utility. It helps to spruce up your application with some nice animation that leverages CSS on capable browsers, and defaults to JS timer-based animations on older browsers.

var myAnim = new Y.Anim({
    node: '#demo',
    to: {
        width: 0,
        height: 0
    }
});

myAnim.on('end', function() {
    myAnim.get('node').addClass('yui-hidden');
});

Y.YQL

Another really important tool that is great for hacking is YQL – Yahoo Query Language. I’m sure most of you have used it, but for those who haven’t, think of it as a way to access a whole host of different APIs using a standard syntax. YUI and YQL work really well together through the Y.YQL module. For instance, here we are getting the recent activity from Vimeo:

YUI().use('yql', function(Y) {

    Y.YQL('select * from vimeo.activity.everyone where username="basictheory"', function(r) {
        //r now contains the result of the YQL Query
    });

});

Try out this query here. I use YQL regularly to access different APIs in a consistent manner.

Regardless of whether you are using YUI, jQuery, or any other library, building something with it is a great way to become familiarized with your development toolbox. When hacking, don’t worry too much about the technical details – just set a time limit and just build it!

6. YUI App Framework

One of the newer additions to YUI has been the App Framework. It’s similar to Backbone.js, but with YUI’s sophisticated event infrastructure under the hood. The App Framework made it easy for me to build MVC-style web applications.

Just like any other tool, I built something with the App Framework to understand how it worked. Once again, I can’t stress the benefits of hacking on products. For the App Framework, I built TopForty with a friend of mine.

The Model

The YUI App Framework is built on the MVC design pattern. Let’s start with the model. If you aren’t familiar with MVC, take a look at this tutorial.

For TopForty, we were able to get a large JSON array of the most talked-about songs from Twitter. Each object in the array looked like this:

{
    "title": "PayPhone",
    "position": 1,
    "video_id": "5FlQSQuv_mg",
    "song_id": 627,
    "artist": "Maroon 5",
    "duration": 232,
    "images": […]
}

We wrapped this up in a Y.Model subclass called Y.SongModel. Here’s the class definition:

Y.SongModel = Y.Base.create('songModel', Y.Model, [], {

    initializer: function (config) {
        ...
    }
}, {
    ATTRS: {
        title: {},
        artist: {},
        images: {
            value: []
        },
        nowPlaying: {
           ...
        }
        ...
    }
});

This allowed us to listen for events whenever one of the ATTRS in the model changed and take appropriate action. For example, if the current song being played was changed:

//When the model's isPlaying attribute changes, call the handleIsPlayingChange function.
this.model.after('isPlayingChange', this.handleIsPlayingChange, this);

The View

Each model was represented visually by a View, which is essentially just HTML. For TopForty, we had a SongView that looked something like this:

<div class="song yui3-u" id="songModel_2">
            <img class="song-img" src="...">
            <div class="song-desc">
                <div class="song-number">2</div>
                <div class="song-movement">
                    <img class="movement-icon" src="...">
                </div>
                <div class="details">
                    <h4 class="song-name">Turn on the lights</h4>
                    <p class="artist-name">Future</p>
                </div>
            </div>
</div>

We wrapped this up in a Y.View subclass called Y.SongView. Each View requires a render() method that is called when displaying the view on the page, and a initializer() method where events are subscribed. If you want, you can establish a relationship between your view and a Model or Model List instance by attaching event handlers to them in a custom initializer() method like we see below:

Y.SongView = Y.Base.create('songView', Y.View, [], {
    initializer: function (config) {
            var model = this.get("model");
            model.after('change', this.render, this);
            model.after('destroy', this.destroy, this);
    },
    render: function() {
        ...
    },

    destroy: function() {
        ...
    },

    showSongOverlay: function() {
        ...
    }
},{
    ATTRS: {
        container: Y.one("#songContainer")
    }
});

By doing this, we were able to have songview specific methods such as displayNowPlayingIndicator() and showSongOverlay() on the Y.SongView instance rather than as separate functions.

The Router

The Router, formally known as the Controller, is what makes everything connect and work. Remember that in classical MVC, all user actions traditionally go through the controller. In web apps, the router uses HTML5 history to change URLs and controls the state of the application.

For example, in TopForty clicking on a song changes the URL to the song’s ID. The URL change is picked up by the router, which loads the YouTube video for the song in question:

Y.AppRouter = Y.Base.create('appRouter', Y.Router, [], {
  // Default route handlers inherited by all CustomRouter instances.
  index: function (req) {
    // ... handle the / route, load up the UI, etc.
  },

  loadSongFromUrl: function (req) {
    // ... handle the /song/:songId' route ...
    //Get the youtube video from the model with an id of :songId and play it.
  }
}, {
  ATTRS: {
    // The specific routes that we are interested in listening to:
    routes: {
      value: [
        {path: '/',    callback: 'index'},
        {path: '/song/:songId'', callback: 'loadSongFromUrl'}
      ]
    },
  }
});

What I learned: Leveraging the MVC design pattern can help you create anything from simple non-interactive views to rich applications.

I hope I have been able to give you a taste of what is possible with the YUI App Framework. For a more thorough walkthrough, I recommend the following links. If you aren’t a fan of the App Framework, I recommend you look into the equivalent jQuery alternatives. Backbone.js in particular has a large following with good documentation.

7. Test Driven Development and YUI Test

For developers, writing code is often the easy and fun part. The hard part is figuring out how old, buggy code works and trying to fix past errors. To minimize this, a lot of organizations including Yahoo emphasize the importance of Test Driven Development (TDD). With TDD, you write the tests first, then add the functionality until all your tests pass. Want to add a new feature? Write a new test, then code the feature.

I was new to TDD when I joined the YUI team. Unfortunately, JS does not have the best testing suite. User interactions in particular are hard to test. Furthermore, we have to test in all the major browsers.

One of the primary ways we conduct unit-testing is through YUI Test.

What I learned: Following test-driven development principles makes you more productive as a programmer.

YUI Test is a complete testing framework for JavaScript and Web applications. You can use the simple JavaScript syntax to write unit tests that can be run in web browsers or on the command line, as well as functional tests to be run in web browsers.

Here’s how you set it up:

// Create a new YUI instance and populate it with the required modules.
YUI().use('test', function (Y) {
    // Test is available and ready for use. Add implementation
    // code here.

});

Now, we can start writing some unit tests!

var testCase = new Y.Test.Case({

    name: "TestCase Name",

    //---------------------------------------------
    // Setup and tear down
    //---------------------------------------------

    setUp : function () {
        this.data = { name : "Tilo", age : 23 };
    },

    tearDown : function () {
        delete this.data;
    },

    //---------------------------------------------
    // Tests
    //---------------------------------------------

    testName: function () {
        Y.Assert.areEqual("Tilo", this.data.name, "Name should be 'Tilo'");
    },

    testAge: function () {
        Y.Assert.areEqual(23, this.data.age, "Age should be 23");
    }
});

YUI Test supports equality assertions (areEqual()) which uses ==, sameness assertion (areSame()) which uses ===, special value assertions such as isFalse(), isNotUndefined(), mock objects and more.

After writing our tests, we can run it as shown below. The results of the test can be outputted as XML, JSON, jUnitXML, or TAP.

Y.Test.Runner.add(testCase);
Y.Test.Runner.run();

Don’t forget to test, regardless of what you use.

If you don’t use YUI Test, that’s fine. However, I want to stress the importance of testing your code. I’m guilty even today of writing code without writing tests and it’s probably okay if it’s your own small personal project. All of us cut corners sometime. However, if you’re programming for a client or an organization, following TDD principles will save you (and your clients) from a headache.

8. Minifying and Linting Your JavaScript

Serving up JavaScript files without any minification or lint step can be risky. Minification can often compress the file-size by over 30%, making your page load faster for the end-user. Linting is a good way to ensure your JavaScript follows good coding practices so that errors are minimized.

During my time at Yahoo, we used YUI Compressor and YUI Builder to compress and build our code. The build step includes concatenation and linting through JSLint. I’m sure most of you have used JSLint at some stage, and I do believe it helps improve your coding style.

What I learned: Ask yourself if a certain practice reduce your possibility of errors and if so, follow it.

Now, I’m not going to talk in depth about YUI Compressor and Builder because those may not be the tools of your choice. Usually for my own projects, I use the JSLint NPM Module to check my code.

What I want to stress on is the need to perform these steps prior to pushing code out to production. As JavaScript does not have a compilation step, many developers are accustomed to pushing their JavaScript out to production, comments and all included. Again, this is okay for small projects, but perhaps you should consider minifying and linting your code to ensure users get the best experience.

Additional Reading

9. Coding with the User in Mind

The YUI Team has a great following of friendly, active, and knowledgable developers just like most large open-source projects. As developers working on open-source software, I learned that I can’t sit under a rock and code all day, even if I want to. Developing is as much about writing code as it is about making sure the code you write is actually helping someone solve a problem.

This took me a while to learn, but it’s an important lesson. When writing software, the goal isn’t to use the coolest technology or the latest stack or the hottest language. It’s about the user. When writing OSS, the users are often other developers who build on top of your product. Small things such as weekly updates, tweets, and IRC communication can actually help you more than hours of coding.

What I learned: It’s not about the technology or the stack or the language, it’s about the user.

In my first month of interning at YUI, I wrote about 500 lines of code which I had to scrap because most of it was repetitive and did not address the end goal. I was guilty of coding too early without figuring out the requirements of the project. A good rule is to spend a third of your time gathering requirements, a third of your time writing tests and the final third implementing your software.

10. “When all you have is a hammer, everything looks like a nail.”

I want to conclude by sharing the most important thing that I think I learned in my internship. I consider it to be more important than any technical knowledge that I gained. By working on a library that is not the most popular, I realized the importance of diversifying my skills and being flexible as a developer. I’ve seen how much work it takes to maintain an open-source project and have gained a lot of respect for everyone who release their well-written code for free.

What I learned: Choose a library because it’s the right one for the job, not because it’s your favourite. Understand that different pieces of software serve different purposes, and sometimes understanding the difference is tough.

Coda 2: Reviewed

Jeffrey Way — Thu, 24 May 2012 15:00:38 +0000

Well, it happened; Panic finally released the long-awaited version two of their popular code editor, Coda. But does it live up to the hype? Well, that depends on what type of coder you are. Read the full review after the jump!

The Good

It's Beautiful

When Panic initially unveiled the tour video for their new editor, I was taken aback. The massive file icons only appeal to a very specific type of coder – and I'm not that person. I, as well as many others, found them to be considerably unattractive. Perhaps they'd be appealing, if you exclusively work on static designs, but as someone who stares at an image-less, black background for the better part of each day, these icons only take up space.

Luckily, they can easily be reduced to simple text, at which point the editor becomes infinitely more attractive. The icons are a gimmick.

Helpers

Clearly, Coda is playing to its core audience: PHP developers. While you can certainly code in any language, PHP receives the bells and whistles.

As a PHP developer myself, I won't deny that "WAT" is scattered throughout the language. Even after years and years, I still frequently refer to the PHP.net documentation to remember which order a function's parameters should be passed.

Do I set the haystack as the first or second parameter, when using stristr?

This is one area where Coda shines. It provides instant documentation in the sidebar as you type.

What's unfortunate is that this feature is limited to, essentially, front-end developers: HTML, CSS, JavaScript, and PHP. Why?

Nonetheless, it's a helpful resource, though I'll note that, despite the fact that Panic lists JavaScript as being supported, it only offers to link me to the book documentation. A bug perhaps?

Clippings

Coda's native clippings feature has received a substantial upgrade as well. Rather than the awkward floating bar from Coda 1, the new version rests as its own panel in the sidebar.

Notable additions include multiple (tab separated) insertion points, and the ability to assign both tab triggers and keyboard shortcuts.

Sites

The standard "Sites" layout is back in Coda 2, which allows you to assign either local or remote directories to one click icons. No notes here; it's helpful, and the new ability to group sites into “lists” (or categories) is very much welcomed.

CSS Helpers

In Coda 1, the CSS GUI was available via its own tab, or panel; however, with this new version, it's baked into the editor. For instance, as you type background, the option to use a GUI to create a gradient will be provided, though I must admit that setting values and percentages wasn’t overly intuitive.

Note: did you notice in the image above that Coda only adds a single Webkit prefix? Yeah, we'll cover that shortly! :/

This same functionality is available for other properties too, such as box-shadow and padding.

Honestly, these aren't features that I'd ever imagine using; they'd only slow me down. But still, for newcomers, I'm sure they'll prove to be helpul.

Quick Open

It's nothing new, but, if you need to quickly switch between files, you can press Control + Q, and type in the name of the file. It's not nearly as fast (or responsive) as Sublime Text's implementation, but will get the job done.

Built-In Transmit

The popular Transmit engine is essentially baked into the editor. This provides you with a full file browser for, not only your local files, but also through FTP, SFTP, WebDAV, and S3.

This is a huge plus for some, though, for me, I don't remember the last time that I uploaded files to my server with (S)FTP. Still a nifty feature, though, and the ability to publish a project with a keystroke is handy!

Terminal

Introduced in the first release of Coda, the Terminal panel is back. If you’re not the type of coder who has Terminal open at all times, accessible through a keyboard shortcut, then this will be a welcomed feature.

The Bad

Multiple Cursors

Really? No multiple cursor support? Coda provides a "block edit" functionality, but it's confusing, and not nearly as intuitive as Sublime Text's implementation.

In this editor's opinion, it was a massive mistake to not make multiple cursor support a top priority. I can't imagine using an editor that doesn't give me this ability.

Odd CSS Support

From a distance, Coda's CSS support appears to be fantastic. Auto-completion for the new CSS3 properties, a GUI for creating gradients and box-shadows, etc. What more could you want?

Well, yes that would be true, if those implementations were flawless – but they're not. For example, remember the nifty documentation functionality that I noted above?

It's very helpful…and limiting at the same time. You might be surprised to find that, if I type the official transform property, nothing shows up in the sidebar (there's also no auto-completion for the property). The documentation only registers if I specificially use -webkit-transform. Yep, the official version doesn't work – and neither does -moz-transform (or any of the other versions, for that matter).

Oh, and as for Opera and Microsoft prefixes (-o and -ms, respectively), you can forget about it. Zero auto-completion support. They might as well not even exist.

Webkit Love Affair

There's no denying that Coda's Webkit-based support is fantastic. It makes sense; the live preview uses the Webkit engine, so they need to ensure that the gradients (and other CSS3 properties) that the GUI produces will render correctly.

But, particularly when considering the huge debates that have centered around CSS and Webkit in the last half year, Panic's decision to seemingly endorse Webkit-exclusive CSS3 properties is a terrible one. Why will it auto-complete -webkit-animation, but not any of the others (ms, o, moz)? Why does it render a Webkit gradient, but not for the other vendors?

When questioned (on Twitter), Panic noted that it's incredibly simple to manually add the other prefixes. True; no one is denying that. But why should we have to? Do it for us.

If convenience were the only downside, that would be one thing, but the problem is that their decision to only provide Webkit generation and auto-completion endorses the notion (especially for newcomers) that it's okay to tailor designs specifically for one engine. Note: a smattering of Mozilla prefixes are provided, but not nearly as many.

I Wish…

If, behind the scenes, Coda would maintain a list of every CSS3 property, along with its required prefixes, that would be huge. Don't make me memorize whether or not Microsoft now provides its own prefix for gradient support. Be a good role model, and do it for me. Sheesh, don't make me build a tool, like Prefixr, to get around this.

Git

Git integration in Coda 2 is certainly not a minus, but more of an "ehh." The previous version of Coda provided Subversion support (while the community moved to Git). So, sure, adding a UI for Git was a smart move.

It very well might be helpful to those who aren't entirely comfortable in the Terminal, but, still, I wonder how many of these folks are truly using version control. Do they understand what a branch, stage, or commit is? My instinct is that, if you do, then you'll absolutely prefer to perform these sorts of commands in the Terminal – likely using your own custom aliases to speed things up.

Nonetheless, it's a feature that might be helpful to some – just not me.

Command Palette

Considering the fact that Sublime Text 2, in barely a year, has become the golden editor amongst web developers, you would think that Coda might adopt some of the most touted features in that editor.

Why isn't there a helpful command palette that allows me to specify which action to execute with text? I can't always remember the keyboard shortcut for creating a split; why can't I pull up the command palette, and type "split"?

At this point, I consider a command palette to be essential in my workflow, yet Coda is missing one entirely.

Installing Plugins

We're still in the early days of Coda 2; as such, there currently aren't any plugins available on Panic's website. Hopefully, once some are released, there will be an easy, Package-Control-esque method for installing them. Please don't make me manually download and install these.

In Sublime Text, if I want CoffeeScript syntax highlighting, I can literally have it in ten seconds, without leaving the editor. Will Coda provide this same convenience? My instincts point to "no," which is not a good sign. The success of an editor has more to do with the community’s involvement than anything else.

The success of an editor has more to do with the community’s involvement than anything else.

Vi-Mode Option

Remember when I noted that Coda was made for a very specific type of coder? Yeah, well that type of coder likely doesn't use Vim (or Git-based deployment). For me, though, it's the difference between using Coda and not. I'm heavily dependent upon these keyboard commands, but Coda has left me in the dark. Why? Sublime Text offers Vi (Vintage) support; even Chocolat does.

I'd imagine that, at some point in the near future, support will be provided through a plugin, but, nonetheless, when considering the resurgence of Vim in the last few years, shouldn’t support should be baked in as an option? Maybe so, maybe not; the truth is that the huge majority of Coda users have no interest in this feature, so I won’t knock Coda too much for this!

Only Four Color Schemes

I grant you that this is petty, but why does Coda only provide four color schemes for the editor? Why not offer a dozen or so? We coders love our themes, but will now have to resort to scouring the web for custom skins. Or, when considering the fact that Solarized is one of the most popular, cross-editor themes on the web, why not provide that as a built-in choice? Chocolat does.

Admittedly, things like this are small annoyances, but, still, they're just that… annoying.

Update – here’s a plugin that provides lots of alternative color scheme options.

A Great Sidebar…But

Clearly, Panic spent a great deal of time on the new sidebar functionality. With all of these helpful features, though, why I am limited to just one view at a time? Maybe I want a file browser on top, and the documentation viewer below? It would be far more convenient if I could stack these panels.

Configurability

Sublime Text is sometimes criticized because its configuration options page is essentially a JavaScript object.

The irony is that I consider this to be one of its best features! I have control over everything! Need to change the tab-width, font-size, or a keyboard shortcut? Easy – it takes five seconds. What about on a per-file basis? That’s doable too. With Coda, though, I virtually have no clue how to configure it to my preferences – beyond the basic settings that are provided in the Preferences pane.

Closing Thoughts

The updates aren’t indicative of today’s modern developer.

As I proof this article, I realize that it has come across as somewhat critical. The truth is that Coda 2 is a solid editor – much better than its predecessor. While it does have some bugs, it was just released. Give the amazing Panic team time to listen to community input and release updates/patches. And, certainly, missing functionality can often be provided, via plugins.

I'm only capable of reviewing an editor based upon on my own needs. Personally, I'm most concerned with speed, convenience, and Vi support. Instead of Panic focusing on what will make me more efficient at my job, it sort of feels as if they’ve tacked on a lot of eye candy that doesn’t necessarily help me much. The updates also aren’t indicative of today’s modern developer. Where is Less, HAML, or CoffeeScript syntax highlighting? So yes, it’s a solid editor, but, at the same time, it’s not one that was tailored for more serious developers.

When considering Coda's stand-out features:

File Icons - It’s a gimmick; do people really want massive file icons?
FTP Integration - Helpful, but in a modern world, where we deploy websites and applications with Git (whether to Heroku or PHPFog), I'll very rarely make use of it.
Built-in MySQL - Again, helpful, but you'll likely find yourself resorting to more powerful dedicated apps, such as Sequel Pro or Querious. It feels tacked on for eye candy.
Git Support - I'll stick with Terminal. You likely will too. (But hey, Coda has a built-in Terminal panel.)

I wish that they had instead focused more on speed – not necessarily the speed of the editor, but the speed of my workflow.

How can I accomplish my daily tasks more quickly?

From this perspective, Coda 2 doesn’t provide anything new.

While I've only had a day with Coda, I must admit that something feels a bit…off. It doesn't feel as intuitive as I would have expected from Panic. Frequently, I find myself confused over how to execute simple operations. "Oh, I have to double-click to open this file." There's also no denying that the following is initially very confusing:

So we have a sidebar of files, then another panel in the middle for files, and then, lastly, remote files. This is what I was greeted to after opening Coda for the first time.

I've since learned that you have to get away from the notion that the traditional sidebar is specifically for displaying files. In the image above, it just happens to be set to the "Files" tab, which accounts for the doubled-files issue. Nonetheless, it took me a moment to come to grips with this.

Will I Switch to Coda 2?

There’s this part of me that wants to use Coda. It’s beautiful and feels modern. But, then again, the simple fact is that I’m far more efficient in Sublime Text 2. After years of waiting, I was hoping for more. Bells and whistles are great, but, when you get down to it, there’s nothing overly innovative here. But that’s just me; what do you think?

You might be wondering why I haven’t mentioned the new Air Preview feature. Well, I’d very much like to, but haven’t yet been able to get it to work. I’ll update this article once I do!

3 Key Software Principles You Must Understand

Chris Peters — Wed, 23 May 2012 15:57:55 +0000

If you’re in software development, new techniques, languages and concepts pop up all of the time. We all feel those nagging doubts every now and then: “can I keep up with the changes and stay competitive?” Take a moment, and sum a line from my favourite movie, Casablanca: “The fundamental things apply, as time goes by.”

What’s true for love, is true for code.

What’s true for love, is true for code. The fundamental things will always apply. If you have an understanding of the underlying ideas of software development, you will quickly adjust to new techniques. In this tutorial, we will discuss three basic principles and mix them with many more. They provide a powerful way of managing the complexity of software. I’ll share some of my personal opinions and thoughts, which, hopefully, will prove useful when it comes to applying them to code and real-world projects.

Principle – Don’t Repeat Yourself

A basic strategy for reducing complexity to managable units is to divide a system into pieces.

This principle is so important to understand, that I won’t write it twice! It’s commonly referred to by the acronym, DRY, and came up in the book The Pragmatic Programmer, by Andy Hunt and Dave Thomas, but the concept, itself, has been known for a long time. It refers to the smallest parts of your software.

When you are building a large software project, you will usually be overwhelmed by the overall complexity. Humans are not good at managing complexity; they’re good at finding creative solutions for problems of a specific scope. A basic strategy for reducing complexity to managable units is to divide a system into parts that are more handy. At first, you may want to divide your system into components, where each component represents its own subsystem that contains everything needed to accomplish a specific functionality.

For example, if you’re building a content management system, the part that is responsible for user management will be a component. This component can be divided into further subcomponents, like role management, and it may communicate with other components, such as the security component.

As you divide systems into components, and, further, components into subcomponents, you will arrive at a level, where the complexity is reduced to a single responsibility. These responsibilities can be implemented in a class (we assume that we’re building an object-oriented application). Classes
contain methods and properties. Methods implement algorithms. Algorithms and – depending on how obsessive we want to get – subparts of
algorithms are calculating or containing the smallest pieces that build your business logic.

The DRY principle states that these small pieces of knowledge may only occur exactly once in your entire system.

They must have a single representation within it.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Note the difference between the piece of knowledge, and its representation. If we’re implementing the database connection in our CMS, we will have a code snippet that will initalize the database driver, pass the credentials, and save a reference to the connection in a variable. The code snippet is part of the knowledge, it’s about how something is achieved. The variable with the reference to the connection is the representation of that knowledge – and this can be used by other parties. If the database credentials change, we will have to change the snippet – not its representation.

In a perfect application, every small piece of business logic encapsulates its knowledge in a representation, namely a variable or a class property.
This variable itself is encapsulated in a class that can be described as a representation of a responsibility. The class is encapsulated in a component that can be described as a representation of functionality.

This can be proceeded until we reach the top level of our software project – that is, a stack of representations with increasing complexity. This way of looking at the complexity of software is called modular architecture, and DRY is an important part of it.

Software architecture is about managing complexity.

Achieving DRYness

DRY is a philosophy that packages logic into representations.

There are many ways of achieving DRYness. Hunt and Thomas suggested (among other things) code generators and data transforming. But, essentially, DRY is a philosophy that packages logic into representations.

As every part of your application can be seen as representation, every part exposes specific fragments of your underlying logic: The user management exposes access to registered users of the CMS, the user class represents a single user and exposes his properties (like the username). It retrieves the properties, via the representation of the database.

DRY and modular architecture require good planning. To achieve a representational hierachy from bottom-up, divide your application in a hierarchy of logically separated smaller parts and let them communicate with each other. If you have to manage larger projects, organizing them into components and using DRY within the components is a good idea. Try to apply the following rules:

Make a visual hierarchy of your software application and map the main components to it. Complex projects may require a dedicated map for each component.
If you’re arriving at a level of connected responsibilities, you may want to switch to UML diagrams (or similar).
Before writing a chunk of code, name its hierarchy in your software project. Define what it’s representing, and be sure you know its role in the surrounding component.
Define what the representation should expose to other parties (like functions to execute SQL in a database driver) and what it should hide (like the database credentials).
Ensure that representations do not rely on representations of another complexity level (like a component that relies on a class in another component).

The database driver is a simplified example, as there are many more layers involved in the real world (such as a specific database abstraction layer), and there is much more you can do to encapsulate logic – especially diving into design patterns. But even if you’ve just started with coding, there’s one thing to keep in mind:

When you find yourself writing code that is similiar or equal to something you’ve written before, take a moment to think about what you’re doing and don’t repeat yourself.

In the real world, applications that are a 100% DRY are hard, if not impossible, to achieve. However, applications that are unDRY to an unacceptable degree – and therefore hard to maintain – are quite common. Hence, it’s not surprising to learn that more than 50% of all software projects fail – if you’re taking a look at the code.

Many people tend to think that bad code is produced by bad coders. In my experience, this is very much an exception. More often than not, bad code is produced by bad account managers and an overall misconfiguration of process management in companies.

Bad code is rarely produced by bad coders.

An Example

DRYness is achieved by good planning.

As an example, say you’re hired as a technical consultant by a company that has problems with code quality and maintenance. You review the source and you see hacks and code duplication – the code is not DRY. This is a symptom of bad code quality, it’s not the reason. If you take a look at the version control system – aka the history of the code – chances are that you may find hacks that were introduced at times near deadlines and milestones. Take the time to review what changes are made, and you will likely be confronted with a change in requirements.

As noted above, DRYness is achieved by good planning. Forced changes on a tough deadline are forcing developers to implement dirty solutions. Once the code is compromised, the principle of DRY is likely to be sacrificed completely upon further changes.

There’s a reason why the most successful corporations in the IT business were founded by people with very good technical understanding – or even coders themself: Bill Gates, Mark Zuckerberg, Steve Wozniak, Steve Jobs, Larry Page, Sergey Brin and Larry Ellison know (or knew) what efforts are needed to implement something. Contrary, many companies tend to lay the requirements for engineering into the hands of account managers, and the conceptual part in the hands of business consultants…people who have never implemented anything.

Hence, many technical concepts work only in Powerpoint, Photoshop, and on 27″ widescreen displays. This may have been a successful approach in the days of, more or less, static websites, but it’s not nowadays – with interactive applications on multiple devices. Because coders are the last in the line, they are the ones who have to apply quick fixes on errors in the concept. If this is accompanied by an account manager, who can’t stand up to a client that likes to make last-minute changes, plans are thrown in the garbage, and something quick and dirty is implemented. The code becomes unDRY.

This example is a bit extreme (nevertheless, I have witnessed such scenarios), but it demonstrates that DRY is a theoretical concept, which is challenged by various parties in the real world. If you’re working in a company that forces you to work in this manner, you might suggest some changes to the process (like introducing technical expertise at an earlier stage of technical projects).

If you have a hands-off approach, keep reading! The You ain’t gonna need it principle will come to the rescue.

Principle – Keep it Simple Stupid

The simplest explanation tends to be the right one.

In the late 19th century, physicists struggled to explain how gravity, magnetism and optics interact, when it comes to large distances – like the distances in our solar system. Hence, a medium named aether was postulated. It was said, that light is traveling through this medium, and that it’s responsible for effects that couldn’t be explained otherwise. Through the years, the theory was expanded with assumptions that adjusted the aether postulate to the results of experiments. Some assumptions were arbitrary, some introduced other problems, and the whole theory was quite complex.

An employee of the swiss patent office, Albert Einstein, suggested to get rid of the whole aether theory when he introduced a simple, yet revolutionary idea: All the oddness in calculating with large distances would fade away if we’d accept that time is not a constant; it’s relative. This incredibly of out-of-the-box thinking to come to the simplest explanation with the fewest assumptions to select between competing scenarios is referred to as Ockhams’s Razor.

There are similar concepts in many areas. In software development (and others), we refer to it as KISS. There are many variants for this acronym, but they all mean that you should strive for the simplest way of doing something.

Substantial progress in the history of mankind was achieved by lateral thinkers.

HTTP

The Hypertext Transfer Protocol is widely considered to be a perfect example for a simple solution: designed to transfer hypertext based documents, it is the backbone of highly interactive and desktop-esque applications nowadays. Maybe we have to find solutions for limitations in the protocol, and maybe we have to replace it someday. However, status quo is: based on a few request methods (like GET and POST), status codes and plain text arguments, HTTP has proved to be flexible and robust. That’s why HTTP has been repeatedly pushed to the limits by web developers – and is still standing.

We take this approach for granted, but the history of software development and standardization is full of overly complex and half-baked solutions. There’s even a dedicated made-up word for it: bloatware. Software like this is also described to be DOD, dead on arrival. I have a theory that is very similar to my theory of unDRY code, when it comes to bloatware … However, the success of the internet can be described as a success of simple, yet efficent solutions.

So what’s required to come to the simplest solution possible? It all comes down to maintainability and comprehensibility in software development. Hence, KISS kicks in during the phase of requirements engineering. When you think about how to transform a client’s requirements to implementable components, try to identify the following parts:

Functionality that has an inappropriate ratio between benefit and efforts.
Functionality that is highly dependent on other functionality.
Functionality that is likely to grow in complexity.

There are many people involved in the conceptual process, who do not have the technical expertise to make a reliable cost-benefit analysis

I was once working on a project, where the client wanted to import Excel spreadsheets into his crew management software. This was a clear match. Excel is a proprietary software with a complex document format. The format is complex, because it’s feature-rich: You can add graphs and other things to it – features that were not needed by the client. He was simply interested in the numbers. Thus, implementing the Excel import would require the implementation of a lot of unnecessary functionality. On top of that, there are multiple versions of Excel versions, and Microsoft fires off another release each year. This would have been hard to maintain, and it comes with additional costs in the future.

We ended up implementing a comma-separated-value import. This was done with a few lines of code. The overhead of the data was really small (compare an Excel sheet to it’s CSV equivalent) and the solution was maintainable and future-proofed. Excel was ready to export CSV anyway (as well as other programs that the client might want to use in the future). Since the solution was low-priced as well, it was a good application of the KISS principle.

To sum up: try to think out-of-the box if a task looks complicated to you. If someone is explaining to you his requirements, and you’re thinking that it’ll be tough and complex to implement, you’re right under almost any circumstances. While some things are just that – hard to implement – overcomplicated solutions are quite usual. This is the case because there are many people involved in the conceptual process, who do not have the technical expertise to make a reliable cost-benefit analysis. Hence, they don’t see the problem. Double-check the requirements whether they are really stripped down to the essence that the client needs. Take the time to discuss critical points and explain why other solutions might be more suitable.

Principle – You “Ain’t Gonna Need It

Coding is about building things.

When Google+ launched, Mark Zuckerberg – founder of Facebook – was one of the first who created an account in the social network that was aiming to take his own down. He added just one line to the About me section: »I’m building things.«. I honestly think that this is a brilliant sentence, because it describes the pure essence of coding in a few simple words. Why did you decide to become a coder? Enthusiasm for technical solutions? The beauty of efficiency? Whatever your answer is, it may not be »building the 1.000.001th corporate website with standard functionality«. However, most of us are making money that way. No matter where you are working, you’ll likely be confronted with boring and repetitive tasks every now and then.

80% of the time spent on a software project is invested in 20% of the functionality.

The You ain’t gonna need it principle (YAGNI) deals with these tasks. It basically translates to: If it’s not in the concept, it’s not in the code. For example, it’s a common practice to abstract the database access in a layer that handles the differences between various drivers, like MySQL, PostgreSQL and Oracle. If you’re working on a corporate website that is hosted on a LAMP stack, on a shared host, how likely is it that they will change the database? Remember that the concept was written with budget in mind.

If there’s no budget for database abstraction, there’s no database abstraction. If the unlikely event of a database change does occur, it’s a natural thing to charge for the change request.

You may have noticed the difference between You ain’t gonna need it and DRY-driven modular architectures: The latter is reducing complexity by dividing a project into manageable components, while the former is reducing complexity by reducing the number of components. YAGNI is similar to the KISS principle, as it strives for a simple solution. However, KISS strives for a simple solution by trying to implement something as easily as possible; YAGNI strives for simplicity by not implementing it at all!

Theodore Sturgeon, an American sci-fi author, stated the law: »ninety percent of everything is crap«. This is a very radical approach, and not overly helpful in real-world projects. But keep in mind that “crap” can be very time consuming. A good rule of thumb is: roughly 80% of the time spent on a software project is invested in 20% of the functionality. Think about your own projects! Everytime I do, I am surprised by the accuracy of the 80:20 rule.

80% of the time spend on a software project is invested in 20% of the functionality.

If you’re in a company that is notorious for tight deadlines and imprecise concepts, this is a powerful strategy. You won’t be rewarded for implementing a database abstraction layer. Chances are that your boss does not know what a database abstraction layer even is.

While this concept may sound simple, it can be hard to differ the necessary from the unnecessary parts. For example, if you’re comfortable with a library or a framework that uses database abstraction, you won’t save much time in dumping it. The key concept is another way of looking at software: we’re trained to write future-proof and maintainable software. This means that we are trained to think ahead. What changes may occur in the future? This is critical for bigger projects, but overhead for smaller ones. Don’t think into the future! If a small corporate website does fundamental changes, they may have to start from scratch. This is not a significant problem compared to the overall budget.

Planning a Project

When you’re preparing your to-do list for a project, consider the following thoughts:

Achieve lower complexity by reducing the level of abstraction.
Separate functionality from features.
Assume moderate non-functional requirements.
Identify time consuming tasks and get rid of them.

Let’s go a little bit into detail! I already provided an example for the first item in the list: don’t wrap a database driver around a database abstraction layer. Be suspicious of everything that adds complexity to your software stack. Notice that abstraction is often provided by third party libraries. For example – depending on your programming language -, a persistence layer, like Hibernate (Java), Doctrine (PHP) or Active Record (Ruby) comes with database abstraction and object-relational mapping. Each library adds complexity. It has to be maintained. Updates, patches and security fixes have to be applied.

We implement features everyday, because we anticipate them to be useful. Hence, we think ahead and implement too much. For example, many clients want to have a mobile website. Mobile is a term of wide comprehension; it’s not a design decision. It’s a use case! People who are using a mobile website are, well, mobile. That means they may want to access other information or functionality than a user who visits the site laid back at his desktop. Think of a cinema site: Users on the bus will likely want to access the starting time of upcoming movies, not the 50 MB trailer.

Bad concepts can often be identified by the lack of non-functional requirements.

With an appropriate budget, you would perform a dedicated analysis of the requirements for mobile. Without this analysis, you will simply provide the same information as is on the desktop site. This will be just fine for many circumstances! Because mobile browsers are very clever in adjusting desktop sites to their display, a radical YAGNI approach might be to not write a mobile site at all!

Non-functional requirements do not describe behaviour of a software, they describe additional properties that can be used to judge the quality of software. Since describing software quality presumes knowledge about software, bad concepts can often be identified by the lack of non-functional requirements. Maintainability, level of documentation, and ease of integration are examples for non-functional requirements. Non-functional requirements should be measurable. Hence, »The page should load fast.« is too inconcrete, »The page should load in two seconds max during an average performance test.« is very concrete and measurable. If you want to apply the YAGNI principle, assume moderate non-functional requirements if they are not mentioned in the concept (or if they are mentioned, but inconcrete). If you are writing the non-functional requirements yourself, be realistic: A small corporation with 20-50 page visits a day does not require three days of performance tweaking – as the page should load fast enough because the server is not busy. If the corporation can increase the number of daily visits, a better server or hosting package shouldn’t be too expensive.

Last, but not least, remember the 80:20 rule-of-thumb!

Last, but not least, remember the 80:20 rule-of-thumb! We have to identify the time consuming parts. If a part is absolutly necessary, you have to implement it. The question should be: how will you implement it? Does it have to be the latest framework with a small community? Do you need to switch to the just-released version of a library if the documentation is not up to date? Should you use the new CMS, when not all extensions are available? How much research will be necessary to do so? »That’s the way we have always done it.« is not an exciting approach, but it’ll get the job done without surprises.

It’s important to understand that all of this does not mean that you can start writing dirty code with hacks along the way! You’re writing a lightweight application, not a messy one! However, You ain’t gonna need it is a practical approach. If it would cause many lines of code to reduce a few lines of code duplicates, I personally think that you may relate efforts to budget and some unDRYness is ok. It’s a small application. Hence, the added maintenance complexity is acceptable. We’re in the real-world.

Let’s come back to the inital thought: we like building things. When Beethoven wrote the Diabelli Variations, it was contract work. I don’t think he made compromises on budget. He ran the extra mile, because he did not want to write average music; he wanted to write a perfect composition.

I’m certainly not implying that we’re all geniuses, and that our brilliance should shine through every line of code, but I like to think of software architecture as compositions. I’m a passionate developer, because I want to build perfect compositions, and I want to be proud of the things I’m building.

If you want to be an experienced and business-proofed developer, you have to master the You ain’t gonna need it principle. If you want to keep your passion, you have to fight against it every now and then.

Summary

Software principles are a way of looking at software. To me, a good principle should be based on a simple concept, but it should evolve to a complex construct of ideas when confronted with other techniques and philosophies. What are your favourite software principles?

SSH: What and How

Jonathan Cutrell — Tue, 22 May 2012 21:10:32 +0000

Many web developers use SSH (“Secure Shell”) on a daily basis to manage their servers, back up files, work remotely, and a myriad of other tasks. Today, I’ll explain what SSH is, do a brief history review, and, lastly, teach you how to set it up on your remote server or even your local network. Let’s get started!

A Starting Explanation

If you’re reading this, it’s likely that you’re at least somewhat acquainted with Terminal (or on Windows, something like Cygwin). If so, then you will understand this quick functional explanation of SSH.

SSH is essentially using a network connection to get into Terminal on another computer.

If you aren’t familiar with Terminal, there are a lot of explanations and beginner’s guides to Terminal, both here on Nettuts+ and elsewhere. The power of SSH is reliant on its simplicity; by offering you access to the Terminal of another machine, SSH cuts to the chase and gives you full control over a remote machine. If you understand the power of Terminal and its direct connection to the inner workings of your local machine, then you understand the power of SSH!

A Brief History

SSH was developed in its infant state in 1995. The primary developer, Tatu Ylonen, developed it as the first secure way to administrate a remote UNIX system. Previous to SSH, the only tools that existed sent information like passwords in clear text.

So, How Do I Use It?

There are a million guides out there on how to get set up with SSH. We will specifically cover one method today. First things first, you’ll want to make sure you have SSH on your system.

Mac – A version of OpenSSH comes preinstalled.
Windows – Follow a guide like this one or this one to get Cygwin and the “openssh” package installed.
Linux – OpenSSH is highly likely to be installed already, but if it isn’t, you can follow the same guide to get it installed.

To determine if SSH is installed, run `which ssh`. If Terminal returns something along the lines of /usr/bin/ssh, then you’re good to go! Otherwise, follow one of these guides to get it installed.

In this article, I will assume the version you are using is OpenSSH; there are some configuration differences that depend on your version of SSH. We will be explaining how to set up a Mac to connect to a MediaTemple server through a single SSH command. Once you have SSH installed on your machine, you will need to make sure your target host has SSH enabled. SSH runs over port 22 by default; you can use a command line tool like nmap to ping your server to determine if port 22 is accepting incoming connections, like this:

sudo nmap -sS hostname.com

Of course, you probably have access to the administrative interface for the server. Make sure you look through the options and enable SSH. On a Mediatemple server, this configuration is located under the Server Control panel. Mediatemple SSH is accessible by using root@primarydomain.com. You can add users to the account, but for the sake of keeping things simple, we will use root@primarydomain.com.

Once SSH is enabled (and you have set a root password in your server admin), you can run the following line to SSH into your server.

	ssh root@primarydomain.com

…where primarydomain.com is your MediaTemple primary domain. You will then be prompted for your password (which is the root password you set in the control panel). If you are not using MediaTemple, you can SSH directly to the IP address of your server as well.

If using shared hosting, it is likely that you will not be logging in as root. Instead, you will log in with a user account name. For example, if you are using a service like Site5, you may log in with a username at a subdomain, like this:

	ssh username@malta.site5.com

Ultimately, these configurations will depend on your specific web server company. Refer to your host’s documentation for more information.

Once you are “shelled in”, you can execute commands and traverse the file system within Terminal. Depending upon on your level of access, you may be able to install things on your server using apt-get or wget commands. You can manage your Apache server, edit configuration files with a Terminal-based text editor, view error logs, clear caches, view files directly on a server to make sure they are the correct version, and plenty of other lower-level system administration tasks. Now, what if you wanted to do more, faster with SSH?

How Do I Use It… Better?

There are a ton powerful things that SSH opens you up to. We will skip a few of them (as quite a few are more sysadmin-related, like tunneling). But we will go over a few useful tricks.

Super-quick Log-in

You’re thinking to yourself, “seems like there should be a faster way to do this.” You’re right. And there is. Instead of having to remember your domain, password, and username for every server, you can set up a few configurations that will allow you to speed up the process to something along these lines.

	ssh myserver

With the right configuration, you could run this, and without having to enter any passwords, IP addresses, or long domain names, you’re in! Again, we will assume you are logging into a MediaTemple server. First, we will generate ssh keys. This is basically a set of encrypted keys that live in ~/.ssh on your local machine. You have a “public” key and a “private” key. So, first things first, open a new Terminal window and create the .ssh folder in your home directory.

	mkdir ~/.ssh

Next you will generate your keys with the following line. (This comes directly from MediaTemple’s documentation.)

	ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -C "Comment about your key goes here."

This line will generate an ssh key of type rsa, with 2048 bits (for security), at the file location specified, with the comment specified. You will be promprted for a password, but it isn’t mandatory or necessary; not providing a password will enable you to automatically log in. The RSA type is for SSH protocol version 1. Type DSA is for protocol version 2. Check with your web server to find out which version they are using. Once your keys are generated, you will then run this to make sure your SSH configurations are set to the right permissions.

chmod 700 ~/.ssh && chmod 600 ~/.ssh/*

Next, you will upload your public key to your server. There are quite a few ways to do this; this way comes from MediaTemple’s docs as well.

cat ~/.ssh/id_rsa.pub | ssh root@example.com 'cat - >> ~/.ssh/authorized_keys'

This code is echoing your id_rsa.pub through a `|` (pipe) into the next command, which is an SSH into root@example.com, where you will run an echo and concatenation of what you piped in the first command. It sounds a bit complicated, so there are a few alternative ways to handle this. Essentially, you are going to want no line breaks and your public key on its own line in a file, called authorized_keys on your server in the ~/.ssh/ directory. So, if this is the first or only key you want on your server, you could run this command to copy it directly to that location.

scp ~/.ssh/id_rsa.pub root@example.com:.ssh/authorized_keys

This line is essentially saying, “copy this first file through SSH to the server at this location relative to my current home directory.”

Once your authorized_keys contains your public key, you can attempt to login to the server with ssh username@example.com. If you put your public key in the root user directory’s SSH configuration files, you will be able to login directly to root. You will be asked about a rsa fingerprint; go ahead and allow this action. It adds the server you are connecting to to a known_hosts file. This file can be used for a lot of different things, but particularly to secure yourself against what is called a “man-in-the-middle” attack. If you’d like to read a little more about this, check out this explanation.

If you can successfully log into your server, as if you had entered a password, your keys are working properly. The next step is to add a couple of lines for a shortcut to a configuration file on your machine . Open ~/.ssh/config in your favorite text editor (create it if it doesn’t exist) and add the following:

Host shortname
HostName somehost.com
User username

Where “shortname” is a nickname for the server you want to log into. For instance, “Host myserver” would allow me to do ssh myserver. The HostName is your server location, and of course the User is your username. You may have User root at this spot. Once this file is saved, you should be able to run a simple command to log into your server, like this:

ssh shortname

Git Without a Hub

Please Note: this section requires a bit of familiarity with Git.

You can use SSH to set up your own Git repos on your server! This is useful for companies who don’t want to expose their code on GitHub for whatever reason, and it’s great to be able to push directly from a local machine to a Git repo on your own server.

To set this up, make sure Git is installed on both the host and your local machine. You may have to go through your web server company to have Git installed. Next, run git init on your server in the location that you want your Git repo to be. Of course, you can do this a hundred different ways, but if you prefer to not have a bare repository, you can use branches to push to from your local machine. Here is a common workflow.

	ssh user@example.com
	cd /path/to/repo
	git init
	git checkout -b staging
	git checkout master
	# disconnect from shell session using ctrl-d
	cd /local/repo
	git init
	git add .
	git commit -am "some message"
	git remote add origin user@example.com:/path/to/repo
	git checkout -b staging
	git push origin staging
	ssh user@example.com
	cd /path/to/repo
	git merge staging

Essentially what is happening here is you are logging into the server, changing to the desired repo path, creating a repository and adding a “staging” branch which you can push to from your local machine. Then, you are creating your local repo and a corresponding “staging” branch on your local machine, and adding files to track to the repo. Next comes an initial commit. You are then adding the remote repository as an alias of “origin”. Next, you are pushing the local staging branch to the “origin” alias’s staging branch. Finally, you are ssh’ing back into the server and merging the “staging” branch with the default “master” branch.

SFTP > FTP

You can also use SSH-powered FTP (file transfer protocol), which is essentially a more secure (encrypted) version of FTP that runs over port 22 (rather than the default FTP port 21). Most FTP clients support SFTP as well. FileZilla (for Windows) and Fetch (for Mac) are two popular (and free) SFTP/FTP clients.

Easy Access to Your Server Almost Anywhere

As long as you are around a computer that is connected to the internet, has a Terminal, and has SSH installed (any Mac connected to WiFi, for instance), you can get access to your server, via SSH. That’s the best part. You don’t require any configuration (assuming you haven’t set up any restrictions that require a matching pubkey), you can log in with your username and password from practically anywhere. There are even SSH clients for iOS and other mobile devices. This is a very powerful feature of SSH that is only paralleled in portability by browser-based applications.

A Local Code Repo

Hopefully you can see the power of SSH in a daily development cycle.

Let’s imagine that you and a few buddies are working on some code together. Let’s also say you have a local computer that you have full control over that you use as a development LAMP server with a few VM’s installed on it. You can use SSH locally to move files to and from your computer and the development machine. You can even set up a local Git (or svn, or Mercurial) repo, powered by SSH to keep everything in check. Perhaps you could even make the development machine the only machine that is connected to the remote server via SSH, so that the code has to go through a specific staging process before it can be put into production. The backbone of all of these actions is SSH!

Hopefully you can see the power of SSH in a daily development cycle, especially for teams using version control. As I noted previously, there is plenty of documentation and a myriad of other network-level tools based on or reliant upon SSH that will give you more control and power over your development process and your server. Who knows? Maybe, one day, you could double as a sysadmin after all!

Some Other Helpful Links

Here are some other helpful links to get you started with SSH. It’s been around for a while, so there is plenty of documentation floating around.

Thanks for reading!

Diving into CanJS

Curtis Cummings — Mon, 21 May 2012 19:10:54 +0000

If you haven’t heard, there’s a new kid in town: CanJS. What better way to dive into what this new framework offers than to build a contacts manager application? When you’re done with this three-part series, you’ll have all the tools you need to build your own JavaScript applications!

Choosing the Right Tool

Building a JavaScript application without the right tools is difficult. While jQuery is great at what it does, a DOM manipulation library doesn’t provide any infrastructure for building applications. This is specifically why you need to use a library, like CanJS.

CanJS is a lightweight MVC library that gives you the tools you need to build JavaScript apps.

CanJS is a lightweight MVC library that gives you the tools you need to build JavaScript apps. It provides all the structure of the MVC (Model-View-Control) pattern, templates with live binding, routing support and is memory safe. It supports jQuery, Zepto, Mootools, YUI, Dojo and has a rich set of extensions and plugins.

In part one, you will:

Create a Control and View (client-side template) to display contacts
Represent data using Models
Simulate ajax responses using the fixtures plugin

Excited? You should be! Now let’s get coding.

Setting Up Your Folders And HTML

You’ll need to create a folder for your application. Inside this folder, you need four sub-folders: css, js, views and img. Your folder structure should look like this when you’re done:

contacts_manager
- css
- js
- views
- img

Save this as index.html:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>CanJS Contacts Manager</title>
    <link rel="stylesheet" href="css/bootstrap.min.css">
    <link rel="stylesheet" href="css/contacts.css">
  </head>
  <body>
    <div class="container">
      <div class="row">
        <div class="span12">
          <h1>Contacts Manager</h1>
        </div>
      </div>
      <div class="row">
        <div class="span3">
          <div class="well">
            <nav id="filter"></nav>
          </div>
        </div>
        <div class="span9">
          <div id="create"></div>
          <div id="contacts"></div>
        </div>
      </div>
    </div>
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.js"></script>
    <script src="js/can.jquery.min.js"></script>
    <script src="js/can.fixture.js"></script>
    <script src="js/contacts.js"></script>
  </body>
</html>

At the bottom of the page, we load jQuery, CanJS, the fixture plugin and your application code (contacts.js).

The CSS and images for this tutorial are in included in the source files, which can be downloaded above.

Building Your UI With Views

Views are client-side templates that are used to render parts of your app. CanJS supports multiple templating languages, but this tutorial will be using EJS (Embedded JavaScript), which is packaged with CanJS and supports live binding.

EJS templates look like HTML but with magic tags where you want dynamic behavior (using JavaScript). There are three types of magic tags in EJS:

<% CODE %> runs JavaScript code,
<%= CODE %> runs a JavaScript statement, and writes the escaped result into the resulting HTML,
<%== CODE %> runs a JavaScript statement and writes the unescaped result into the resulting HTML (used for sub-templates).

Templates can be loaded from a file or script tag. In this tutorial templates will be loaded from EJS files.

Displaying Contacts

To render contacts, you’ll need an EJS template. Save the following code as contactsList.ejs within your views folder:

<ul class="clearfix">
  <% list(contacts, function(contact){ %>
    <li class="contact span8" <%= (el)-> el.data('contact', contact) %>>
      <%== can.view.render('views/contactView.ejs', {
        contact: contact, categories: categories
      }) %>
    </li>
  <% }) %>
</ul>

contactLists.ejs will render a list of contacts. Let’s examine the template code here in more detail:

<% list(contacts, function(contact){ %>

The EJS list() helper invokes a callback function on each contact in the list. When used with an observable list, the list() helper will use live binding to re-run anytime the length of the list changes.

<li class="contact span8" <%= (el)-> el.data('contact', contact) %>>

The code above uses an element callback to add the contact instance to the data of the <li>. Everything after the arrow is wrapped in a function that will be executed with el set to the current element.

<%== can.view.render('views/contactView.ejs', {
  contact: contact, categories: categories
}) %>

This code renders the contactView.ejs sub-template for each contact. can.view.render() takes a template and data as its parameters and returns HTML.

Rendering A Single Contact

Sub-templates are an excellent way of organizing your views into manageable chunks. They also help simplify your templates and promote DRY (Don’t Repeat Yourself). Later in this tutorial, you’ll re-use this template to create contacts. Save this code as contactView.ejs in your views folder:

<a href="javascript://" class="remove"><i class="icon-remove"></i></a>
<form>
<div class="row">
  <div class="span2">
    <img src="img/contact.png" width="100" height="100">
  </div>
  <div class="span3">
    <input type="text" name="name" placeholder="Add Name"
      <%= contact.attr('name') ? "value='" + contact.name + "'" : "class='empty'" %>>
    <select name="category">
      <% $.each(categories, function(i, category){ %>
        <option value="<%= category.data %>" <%= contact.category === category.data ? "selected" : "" %>>
          <%= category.name %>
        </option>
      <% }) %>
    </select>
  </div>
  <div class="span3">
    <label>Address</label>
    <input type="text" name="address"
      <%= contact.attr('address') ? "value='" + contact.address + "'" : "class='empty'" %>>
    <label>Phone</label>
    <input type="text" name="phone"
      <%= contact.attr('phone') ? "value='" + contact.phone + "'" : "class='empty'" %>>
    <label>Email</label>
    <input type="text" name="email"
      <%= contact.attr('email') ? "value='" + contact.email + "'" : "class='empty'" %>>
  </div>
</div>
</form>

Each property of a contact is placed in an <input> tag. These will be used to add and update a contact’s information.

Making Your Views Live

Any time EJS encounters attr() while processing a template, it knows that the surrounding code should be turned into an event handler bound to that property’s changes. When the property is changed elsewhere in the app, the event handler is triggered and your UI will be updated. This is referred to as live binding. EJS Live binding is opt-in. It only turns on if you use attr() to access properties.

Let’s look at one of the <input> tags from the contactView.ejs to see how this works:

<input type="text" name="name" placeholder="Add Name"
  <%= contact.attr('name') ? "value='" + contact.name + "'" : "class='empty'" %>>

The code in the magic tags will become an event handler bound to the contact’s name property. When we update the name property, the event handler is run and the HTML will be updated.

Organizing Application Logic Using `can.Control`

can.Control creates an organized, memory-leak free, stateful control that can be used to create widgets or organize application logic. You create an instance of a Control on a DOM element and pass it data your control will need. You can define any number of functions in your Control and bind to events.

When the element your Control is bound to is removed from the DOM, the Control destroys itself, cleaning up any bound event handlers.

To create a new Control, extend can.Control() by passing it an object containing functions you want to define. In part two, event handlers will be passed in as well.

There are a few important variables and functions present in every Control instance:

this – A reference to the Control instance
this.element – The DOM element that you created the instance on
this.options – An object containing any data passed to the instance when it was created
init() – Called when an instance is created

Managing Contacts

Add the following snippet to your contacts.js file to create the Control that will manage contacts:

Contacts = can.Control({
  init: function(){
    this.element.html(can.view('views/contactsList.ejs', {
      contacts: this.options.contacts,
      categories: this.options.categories
    }));
  }
})

When an instance of Contacts is created, init() will do two things:

Uses can.view() to render contacts. can.view() accepts two parameters: the file or id of the script tag containing our template code and data. It returns the rendered result as a documentFragment (a lightweight container that can hold DOM elements).
Inserts the documentFragment from can.view() into the Control’s element using jQuery’s .html().

Representing Data Using Models

A Model abstracts the data layer of an application. Two models are needed in this application: one for contacts and one for categories. Add this code to contacts.js:

Contact = can.Model({
  findAll: 'GET /contacts',
  create  : "POST /contacts",
  update  : "PUT /contacts/{id}",
  destroy : "DELETE /contacts/{id}"
},{});

Category = can.Model({
  findAll: 'GET /categories'
},{});

A model has five static methods that you can define to create, retrieve, update and delete data. They are findAll, findOne, create, update and destroy. You can overwrite these functions to work with any back-end, but the easiest way to define a Model is using REST service, as exemplified in the code above. You can safely omit any static methods that won’t be used in an application.

It’s important to point out here that the model instances in CanJS are actually what we call ‘observables’. can.Observe provides the observable pattern for objects and can.Observe.List provides the observable pattern for arrays. This means you can get and set properties using attr() and bind to changes in those properties.

The findAll() method returns a Model.list, which is a can.Observe.List that triggers events when an element is added or removed from the list.

Simulating a Rest Service Using Fixtures

Fixtures intercept AJAX requests and simulate their response with a file or function. This is fantastic for testing, prototyping or when a back-end isn’t ready yet. Fixtures are needed to simulate the REST service the models in this application are using.

But first, you’ll need some sample data for the fixtures to use. Add the following code to contacts.js:

var CONTACTS = [
  {
    id: 1,
    name: 'William',
    address: '1 CanJS Way',
    email: 'william@husker.com',
    phone: '0123456789',
    category: 'co-workers'
  },
  {
    id: 2,
    name: 'Laura',
    address: '1 CanJS Way',
    email: 'laura@starbuck.com',
    phone: '0123456789',
    category: 'friends'
  },
  {
    id: 3,
    name: 'Lee',
    address: '1 CanJS Way',
    email: 'lee@apollo.com',
    phone: '0123456789',
    category: 'family'
  }
];

var CATEGORIES = [
  {
    id: 1,
    name: 'Family',
    data: 'family'
  },
  {
    id: 2,
    name: 'Friends',
    data: 'friends'
  },
  {
    id: 3,
    name: 'Co-workers',
    data: 'co-workers'
  }
];

Now that you have some data, you need to wire it up to fixtures so you can simulate a REST service. can.fixture() takes two parameters. The first is the URL we want to intercept and the second is a file or function that is used to generate a response. Often URLs you want to intercept are dynamic and follow a pattern. In this case, you should use templated URLs. Simply add curly braces to the URL where you want to match wildcards.

Add the following to contacts.js:

can.fixture('GET /contacts', function(){
  return [CONTACTS];
});

var id= 4;
can.fixture("POST /contacts", function(){
  return {id: (id++)}
});

can.fixture("PUT /contacts/{id}", function(){
  return {};
});

can.fixture("DELETE /contacts/{id}", function(){
  return {};
});

can.fixture('GET /categories', function(){
  return [CATEGORIES];
});

The first four fixtures simulate the GET, POST, PUT and DELETE responses for the Contact model, and the fifth fixture simulates the GET response for the Category model.

Bootstrapping the Application

Your application has Models for your data, Views to render contacts, and a Control to hook everything up. Now you need to kickstart the application!

Add this to your contacts.js file:

$(document).ready(function(){
  $.when(Category.findAll(), Contact.findAll()).then(
    function(categoryResponse, contactResponse){
      var categories = categoryResponse[0],
        contacts = contactResponse[0];

      new Contacts('#contacts', {
        contacts: contacts,
        categories: categories
      });
  });
});

Let’s take a closer look at what is happening in this code:

$(document).ready(function(){

Wait for the DOM to be ready using jQuery’s document ready function.

$.when(Category.findAll(), Contact.findAll()).then(
  function(categoryResponse, contactResponse){

Call findAll() on both models to retrieve all of the contacts and categories. Since findAll() returns a Deferred, $.when() is used to make both requests in parallel and execute a callback when they are finished.

var categories = categoryResponse[0],
  contacts = contactResponse[0];

Get the list of model instances from the response of the two findAll() calls. The responses are arrays, with the first index being the list of model instances retrieved.

new Contacts('#contacts', {
  contacts: contacts,
  categories: categories
});

Create an instance of the Contact Control on the #contacts element. The list of contacts and categories are passed into the Control.

When you run your application in a browser, you should see a list of contacts:

Wrapping Up

That does it for part one of this series! You’ve been introduced to the core of CanJS:

Models abstract the data layer in your application
Views are templates that turn data into HTML
Controls wire everything up.

In the next lesson (to be published May 28th), you’ll create a Control and View to display categories and use routing to filter contacts. Hope to see you there!

Questions? Ask away below!

Quick Tip: What Exactly is Web Hosting?

Jeffrey Way — Sat, 19 May 2012 10:00:20 +0000

Tired of the “techie” trying to explain to you what web hosting is all about from his bedroom-recorded Skype video? Ever get confused with all the funny terms they drop, like “Shared Hosting” and “Dedicated Servers”? We’ve all been there at one point or another! Well, the guys over at InMotion Hosting created a quick, visual guide that will get you up and running with the jargon in no time!

By InMotion Hosting

Conclusion

If you’re still new to this world, and have questions about the hosting world, leave a comment below, and one of us will do our best to help!

Ticksy: A Support Story

Justin Scheetz — Fri, 18 May 2012 15:05:33 +0000

When I started designing and developing themes and templates for the ThemeForest marketplace five years ago, customer support was easy. I’d get an email or two a day, answer them, and move on.

But as sales picked up, things became complicated. One or two emails turned into five, which turned into ten, which turned into twenty! I’d respond to a question, and get another question in response. Emails were lost. Customers were frustrated. It was all a big mess.

Email was no longer a tenable support solution.

Two years ago, I decided that enough was enough. Email was no longer a tenable support solution. I needed to find a better way.

So I did some digging around for a support solution. And believe me, there are plenty out there. Some are free — mostly poorly designed, buggy DIY scripts to install and run on your own server. Some aren’t — prettier, feature-rich … and expensive. Fifty bucks a month? For a guy like me, forget it.

Simply put, there was nothing out there that appealed to someone doing well — but not getting rich — selling online. So I decided to build one. Something simple. Something with the features I needed, and nothing else. And something that played nice with the Envato API.

Two years later, I finished Ticksy — and I love it. It’s sleek, easy to use and getting some great reviews.

Most importantly, it’s doing a great job handling my support requests — the reason I built it in the first place!

Designing Ticksy

As any developer knows, simple on the outside invariably means complicated on the inside. And, while Ticksy was a labor of love, building it was anything but easy.

Naming it? That’s a different story. Support ticket system. “Tick.” “Sy.” Ticksy. Get it?

I spent roughly three months designing the UI – buttons and form fields on the login screen, tabs and dropdowns in the app and more. Product management had to be spot-on, too. The initial Envato integration made it possible for me to tie every ticket directly into one of my products in the marketplace. Eventually, I worked product verification into the mix — only actual owners (not pirates) of my themes could submit tickets.

They liked it. No more email!

I developed the first, basic version of Ticksy using PHP and MySQL in about five months — continuing to support customers via email in the meantime (yuck). Finally, by the end of 2010, I was able to deploy the system for my own business. Customers started using it. They liked it. No more email! I felt great; a huge load was off my shoulders.

The original Ticksy dashboard, circa 2010

Then, something unexpected — and pleasant — happened. People started asking me about the system. The customers actually enjoyed using it as much as I did and wanted to know how they could use it in their businesses. I had no answer at the time. This was my system. I built it for me. Were there other people like me that would use something so simple?

Turns out there were. People wanted Ticksy. So I was back to the drawing board.

Ticksy For All

Two partners and I redesigned the UI and backend to allow for multiple systems, added social sign-in buttons (Facebook and Twitter), got feedback from friends and family and added a few other features. I essentially redesigned/developed the entire Ticksy system, and launched a beta build in early 2011.

I had around ten beta users using it full-time, and they loved it. Months went by, bugs were squashed, the UI was refined and I let it get some good use for a long time. If I was going to release this to the public and expect people to pay for it, it had to work well. I let it go for a year before deciding to release it to the public. My product was polished. Ticksy was ready for the limelight.

After many months of testing, developing a marketing site (powered by WordPress), creating a marketing video (with the help of VideoHive’s own Bryan Drake) and planning everything to the last detail, we launched Ticksy to the public in March.

The Ticksy dashboard, 2012

If you’re a designer, you know the feeling of taking a product live. It’s amazing. But it’s also a bit scary. What if people don’t like it? What if it doesn’t sell?

Thankfully, with Ticksy, my fears were quickly assuaged. The initial group of users loved it, talking up its simplicity, its reliability and even its price point. Like me, they were freed from the headaches of email-based support — without having to turn to a cheaply built free solution or an expensive, bloated “do-it-all” app.

As a designer, it was supremely validating. And it was a reminder to keep working.

More to Come

A developer’s work is never done. And despite the project’s success, that’s certainly been true for Ticksy.

As initially released, Ticksy was an intuitive, bloat-free, web-based customer support solution that could be customized to match any existing brand. After months of work, it’s still that — and more. Now, end users can label their tickets “public” or “private,” bringing an element of the traditional community forum to support. Search functionality for customers is enabled. And enhanced FAQs, notification systems and better Envato integration are on the way soon. (You can check out our roadmap here.)

Summing it Up

Ticksy has been a two-year journey of discovery and hard work.

For me, Ticksy has been a two-year journey of discovery and hard work. But it’s been worth it.

What started as a project to simplify my own work has taken on a life of its own. I never expected Ticksy to see the light of day outside my office. But it’s incredibly vindicating to check the growing list of users and read their feedback. Really, it’s every developer’s dream. Ticksy has truly arrived. And, with each user, it’s making web-based customer support just a little bit simpler.

The process of taking an idea from sketch to launch is a significant achievement. If you have any, more specific, questions about the process (such as the tools we used for reporting bugs, version control, etc.), let me know in the comments, and we’ll talk!

Diving Into CSS Regions

Umar Hansa — Thu, 17 May 2012 17:20:11 +0000

This tutorial will cover the basics of CSS regions, which allow us to flow content within various sections of the page. Confused? You probably are; read on!

Demo View It Online

CSS Region Support

At the time of this writing, the CSS Regions specification is a working draft and things may change! Techniques mentioned in this tutorial might change in implementation. The aim of this tutorial is to give a basic understanding of CSS Regions and what might be coming to a browser near you.

Check out caniuse.com for a list of browsers which have some support for CSS Regions. This tutorial will only use webkit/non-vendor-prefixed examples for simplicities sake.

If you find the demo is not working for you it may be because CSS Regions needs enabling, here are instructions for Chrome (should work for Chrome, Chrome Canary & Chromium )

Navigate to chrome://flags/ (or about:flags)
Find “Enable CSS Regions” and enable it.
Restart your browser and verify that the demo is working.

A Simple Example

Demonstrating CSS Regions in a simple manner actually requires very little code!

To get into the flow of things lets go through a quick example of how to use CSS Regions.

First, we need some dummy text which is contained within the paragraph tag, below that you’ll notice two empty divs each with a class of “regions”. Using CSS Regions we will allow our “example-text” to flow into the region divs.


<p class="example-text">"Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua."</p>

<div class="regions"></div>
<div class="regions"></div>

.example-text {
	-webkit-flow-into: example-text-flow;
	padding: 0;
	margin: 0;
}

.regions {
	-webkit-flow-from: example-text-flow;
	border: 1px solid black;
	padding: 2px;
	margin: 5px;
	width: 200px;
	height: 50px;
}

If you try viewing the code above in a Webkit browser that supports CSS Regions, you should see something like:

All styling (apart from -webkit-flow-from) which has been applied on the “regions” class is only there to make it evident where the regions are, the two lines of CSS that we really care about are:

-webkit-flow-into: example-text-flow;

-webkit-flow-from: example-text-flow;

These will be discussed in more detail below

The `flow-into` Property and Named Flows

The flow-into property accepts an identifier as its value, once we apply the flow-into property onto an element and pass it an identifier, that element then becomes part of a “named flow”. As soon as an element becomes part of a named flow it is taken out of its usual flow – this essentially means the element will not be rendered on the page, for example:

<p class="example-text">I will not be rendered on the page</p>

.example-text {
	-webkit-flow-into: example-text-flow;
}

There are some exceptions to this however, if the flow-into property is given the value ‘none’ the element will not be part of a named flow and thus be subject to usual rendering on the page. As you might have guessed, another case where an element which is part of named flow will be displayed is when it has a valid region associated with it.

Multiple elements can be put into the same named flow:

#example-1 {
	-webkit-flow-into: my-named-flow;
}

#example-2 {
	-webkit-flow-into: my-named-flow;
}

If there is an associated region for “my-named-flow”, an attempt will be made to flow the two elements (#example-1 & #example-2) into their corresponding region chain.

It’s not just simple bits of text which can be put into a named flow, we can put images too! Having the ability to put all sorts of HTML elements into named flows is a powerful thing. For example, let’s say we had two individual lists but from a presentation point of view we wanted to show them together. One way to go about this is to use CSS selectors to target only the portions we need and put them into a named flow, example (extract of code):

<article id="css3">
  <header><h4>CSS3</h4></header>
  <ul>
    <li>Media Queries</li>
    <li>Text Shadows</li>
    <li>3D Transforms</li>
  </ul>
</article>

<article id="html5">
  <header><h4>HTML5</h4></header>
  <ul>
    <li>Canvas</li>
    <li>Drag-and-drop</li>
    <li>Web Storage</li>
  </ul>
</article>  

<div id="buzzwords-region"></div>

/* Only put the list within the article into a named flow */
#css3 > ul {
-webkit-flow-into: buzzwords-flow;
}

#html5 > ul {
-webkit-flow-into: buzzwords-flow;
}  

#buzzwords-region {
-webkit-flow-from: buzzwords-flow;
border: 1px solid green;
}

(Demo of the above.) If you look at the source code you’ll notice that our HTML5 & CSS3 lists have been merged into a new ~~buzzword~~ list. Take note of how the headers of those lists were not targeted in the CSS selectors and thus are not part of any named flow, they are therefore still rendered on the page and are not contained within a region.

The `flow-from` Property

The flow-from property is able to take a container, for example an empty div and turn it into a region. For it to turn into a valid region it must have an associated named flow. As discussed, named flows are created by using the flow-into property and then using an identifier as its value.

<div class="region"></div>

.region {
	-webkit-flow-from: my-named-flow;
}

Similar to flow-into property, we can assign the value of ‘none’ to the flow-from property, this makes the corresponding element nothing more than a container e.g. it will not act as a region.

When applying the flow-from property on an element, it will not have a height or width which is why you’ll need to set these in order to view the contents of the region. Regions may only act as region chains for a single named flow, so multiple elements may flow-into a single named flow however a region can only flow-from a single named flow. A region will maintain the styles of its source element; this means if the source element has the colour value of red the text will continue to appear red when rendered as part of a region.

The CSS Region specification has been considering using @region rules for specific region styling.

“An @region rule contains style declarations specific to particular regions.”

This could allow for CSS syntax (similar to that of media queries) such as:

/* A regular style on all paragraph tags */
p {
	font-weight: normal;
}

@region #my-region {
	/* When text from the p element is flowing into #my-region, use the styling below */
	p {
		font-weight: bold;
	}
}

Being able to do this would allow region specific styling to be applied on the source, currently, setting for example “font-weight: bold” on a region will not cause content displayed within it to be bold – the styling must be applied on the source element.

JavaScript API

At the time of this writing, there is some support in Webkit-based browsers to access CSS Region information through JavaScript. Using JavaScript, we can pick out a flow according to its identifier and find out what regions are associated with it. We can even find out the status of a particular region, there may be a use case where empty regions need specific handling, using JavaScript we can accomplish this.

Accessing a flow by name

A named flow can be accessed in JavaScript using document.getFlowByName(‘identifier’) (You can try these in the developer console in the demo.)

var flow = document.webkitGetFlowByName('example-1-text');

The returned object is something called a WebkitNamedFlow. flow.contentNodes will contain an array of HTML Elements which are being used as the source for the flow being accessed.

Discovering which regions belong to which content node

The ability to detect which content belongs to which regions can prove useful in various situations.

var flow = document.webkitGetFlowByName('example-4-text');
var main_content = document.querySelector('#example-4 .main_content');
flow.getRegionsByContentNode(main_content);

In the code above, we first find our flow on the page using the flow name, then using the Selectors API we access a piece of content on the page and pass it as an argument to getRegionsByContentNode(), this returns a list of elements which are being used as regions for that particular piece of content.

Finding out whether or not a piece of content fits inside a region

We can very quickly determine the status of a region in regards to how content inside it fits.

//This is not a very efficient selector, see https://developers.google.com/speed/docs/best-practices/rendering#UseEfficientCSSSelectors
var region7 = document.querySelector('#example-4 .regions > div:nth-child(7) ');
region7.webkitRegionOverflow //"fit"

element.regionOverflow will return different values depending on how it’s handling the source content. There are four possible values: ‘overflow’, ‘fit’, ‘empty’ and ‘undefined’

overflow: The content does not fit in the specified region and will overflow to the next region if it’s available
fit: The region has successfully contained the content and no overflow is necessary.
empty: There is no content inside of the selected region and therefore it is empty (as will normally be the case with a region whose previous region returns ‘fit’ for regionOverflow)
undefined: The element is not a valid region.

You can try this out using developer tools in Chrome, on the demo page, right click on one of the blue boxes (a region) and select ‘Inspect Element’. You may find the source element is selected rather than the region div. Try to find the nearest div with the class of ‘regions’ and select one of the child divs (they should appear empty). At this point you can hit the Escape key on your keyboard which should bring up the console; now as a handy shortcut you can type $0 into the console to access the selected element. Now try typing:

$0.webkitRegionOverflow //'overflow', 'fit', 'empty' or'undefined'

A Few Notes and Opinions

Hello! Thanks for reading this tutorial, here are some extra bits of information you may be interested in.

Browser implementation for CSS Regions isn’t great right now and even when it does improve browser implementation may vary. For example Internet Explorer only allows flow-into to be set on an iframe.
CSS Regions can let developers and designers offer a more improved experience on the web, especially on mobile/tablet devices.
Modernizr can detect support for CSS Regions, it’s what the demo uses.
Adobe have taken a great initiative on CSS Regions. Be sure to check out their demos!
Chris Coyier of CSS Tricks has come up with a cool and practical use for CSS Regions.

Meet Crockford’s JSCheck

Andrew Burgess — Wed, 16 May 2012 20:50:33 +0000

There are dozens of JavaScript testing frameworks, but most of them function in, more or less, the same way. However, Douglas Crockford’s JSCheck is considerably different from most. In this tutorial, I’ll show you how it’s different and why you should consider using it!

Crockford describes JSCheck as a “specification-driven testing tool.

Crockford describes JSCheck as a “specification-driven testing tool.” When using the frameworks you’re used to, you would write a test for a given piece of functionality, and, if that test passes, declare that the given functionality is working correctly. However, it’s possible that you might miss some of edge cases or exceptions that your tests don’t cover.

While uncovering edge cases isn’t the express purpose of JSCheck, it is a nice side benefit. The main idea behind JSCheck is this: the specification you write will actually describe how the code you are testing should work. Then, JSCheck will take that specification (called a claim in JSCheck-lingo), and generate random tests to prove the claim. Finally, it will report the results to you.

Sounds interesting? Read on! Sounds familiar? You might have used the Haskell testing tool, QuickCheck, on which JSCheck was based.

Some Code to Test

Of course, before actually writing our claim, we’ll want to have some code to test. Recently, I wrote a mini-password scorer, similar to the functionality on HowSecureIsMyPassword.net. It really isn’t fancy: you just pass the function a password and get a score back. Here’s the code:

passwordScorer.js

(function () {
    var PasswordScorer = {};

    PasswordScorer.score = function (password) {
        var len = password.length,
            lengthScore = 0,
            letterScore = 0,
            chars = {}

        if      (len >= 21) { lengthScore = 7; }
        else if (len >= 16) { lengthScore = 6; }
        else if (len >= 13) { lengthScore = 5; }
        else if (len >= 10) { lengthScore = 4; }
        else if (len >=  8) { lengthScore = 3; }
        else if (len >=  5) { lengthScore = 2; }

        var re = [ null, /[a-z]/g, /[A-Z]/g, /\d/g, /[!@#$%\^&amp;\*\(\)=_+-]/g];

        for (var i = 1; i < re.length; i++) {
            letterScore += (password.match(re[i]) || []).length * i;
        }

        return letterScore + lengthScore;
    };

    (typeof window !== 'undefined' ? window : exports).PasswordScorer = PasswordScorer;
}());

It’s pretty simple code, but here’s what’s going on: the score is made up of two sub-scores. There’s a starting score, that’s based on the length of the password, and then an additional score for each character, 1 point for each lowercase letter, 2 points for each uppercase letter, 3 points for each number, and 4 points for each symbol (from a limited set).

So, this is the code we’re going to test: we’ll randomly generate some passwords with JSCheck and make sure they get an appropriate score.

Writing our Claim

Now we’re ready to write our claims. First, head over the JSCheck Github page and download the jscheck.js file. I like to run my tests in the terminal, via NodeJS, so add this single line to the very bottom of the file:

(typeof window !== 'undefined' ? window : exports).JSC = JSC;

This won’t affect the way the file behaves in the browser at all, but it will make it work as a module within Node. Notice that the jscheck.js file exposes JSC as the single global variable for the whole library. If we weren’t making this adjustment, that’s how we’d access it.

Let’s open passwordScorerSpec.js and start things:

JSC = require("./../vendor/jschec";).JSC;
PasswordScorer = require("./../lib/passwordScore";).PasswordScorer;

Since I’m running these tests in NodeJS, we’ll have to require the modules we want. Of course, you’ll want to make sure that paths match your file locations.

Now, we’re ready to write our first claim. Of course, we use the JSC.claim method. This method accepts three parameters, with an optional fourth. The first parameter is just a string, a name for the claim. The second parameter is called the predicate: it’s the actual testing function. Very simply, this function should return true if the claim is true, and false if the claim is false. The random values that JSCheck will generate for the test will be passed as parameters to the predicate.

But how does JSCheck know what type of random values to hand the predicate? That’s where the third parameter, the specifier comes into play. This is an array, with an item for each parameter for predicate. The items in the array specify what types to give the predicate, using JSCheck’s specifier functions. Here are a few of them:

JSC.boolean() returns either true or false.
JSC.character() takes a min and max character and returns a single character from that range. It can also take a single character code and return that character.
JSC.integer() will return a prime number. Or, pass it a single parameter to get an integer (whole number) between 1 and the parameter, or two parameters for an integer in that range.

You get the idea. There are other specifiers, and we’ll use some now as we write our first claim.

JSC.claim("All Lowercase Password";, function (password, maxScore) {
  return PasswordScorer.score(password) <= maxScore;
}, [
  JSC.string(JSC.integer(10, 20), JSC.character('a', 'z')),
  JSC.literal(26)
]);

Our first parameter is a name. The second is the testing function: it receives a password and a max score, and returns true if the score for that password is less than or equal to the max score. Then, we have our specifier array. Our first parameter (the password) should be a string, so we use the JSC.string() method: it can take two parameters, the number of characters in the string, and value for those characters. As you can see, we’re asking for a password between 10 and 20 characters. For the value, we’re using the JSC.characters() method to get random characters between ‘a’ and ‘z’.

The next value is our maxScore parameter. Sometimes, we don’t want the randomness that JSCheck offers, and this is one of those times. That’s why there’s JSC.literal: to pass a literal value the predicate. In this case, we’re using 26, which should be the max score for any all-lowercase password between 10 and 20 characters.

Now we’re ready to run the test.

Running our Claim

Before we actually run the claim and get the report, we have to setup the function that will receive the report. JSCheck passes the report to a callback function of JSC.on_report. Hence:

JSC.on_report(function (str) {
  console.log(str);
});

Nothing fancy. Now, all that’s left is to call JSC.check(). Now, we can head to our terminal and run this:

node path/to/passwordScorerSpec.js

Behind the scenes, JSCheck runs the predicate 100 times, generating different random values each time. You should see your report printed out.

All Lowercase Passwords 100 of 100
 pass 100

They all passed, but that’s not much of a report, eh? Well, if any of our tests had failed, they would have been included in the report. However, you can adjust the level of output with the JSC.detail function: pass it a number between 0 and 4 (inclusive) to get anything for no output to all the test cases. The default value is 3.

Adding a Classifier

Remember how I said that JSC.claim could take a fourth parameter? It’s called a classifier, and it receives the same parameters that the predicate receives. Then, it can returns a string to classify, or group, our test cases. I’ll admit I wasn’t really sure where this would be useful until I was creating the above example claim. See, I made a mistake in the predicate and compared the score to the maxScore with the < operator instead of the <= operator, so any passwords that scored 26 points were failing. I was seeing reports that looked something like this:

All Lowercase Passwords 96 of 100
 FAIL [12] ("vqfqkqqbwkdjrvplkrx";,26)
 FAIL [21] ("nhgkznldvoenhqqlfza";,26)
 FAIL [62] ("eclloekuqhvnsyyuekj";,26)
 FAIL [78] ("rvrkfivwtdphrhjrjis";,26)
 pass 96 fail 4

It’s still not entirely obvious why some tests are failing. So I added a classifier function that grouped the test cases by score: like I said, the function takes the same parameters as the predicate, and it returns a string. Every test case that gets the same string back from the classifier will be grouped together in the report.

function (password, maxScore) {
	return PasswordScorer.score(password) + " points";;
}

This function should be the last parameter of our claim. Now, you’ll get a report that’s something like this:

All Lowercase Passwords 96 of 100
 FAIL [4] 26 points:("illqbtiubsmrhxdwjfo";,26)
 FAIL [22] 26 points:("gruvmmqjzqlcyaozgfh";,26)
 FAIL [34] 26 points:("chhbevwtjvslprqczjg";,26)
 FAIL [65] 26 points:("kskqdjhtonybvfewdjm";,26)
14 points: pass 8
15 points: pass 5
16 points: pass 12
18 points: pass 10
19 points: pass 12
20 points: pass 11
22 points: pass 12
23 points: pass 8
24 points: pass 10
25 points: pass 8
26 points: pass 0 fail 4

You can see how the tests are grouped by how many points the passwords are worth. Now, it’s easy to see that the only passwords that fail the tests are the passwords that score 26 points. And while the problem here was with the test, and not the code, it still shows how it can be useful to add a classifier function to your claims.

Final Thoughts

So, at the end of the day, it JSCheck worth using? Here’s what I think: it’s not something you’re necessarily going to use with every code base, but sometimes you’ll find it useful to be able to create random test cases that will rigorously test a given piece of code. When that’s what you want to do, I haven’t seen a tool better for that than JSCheck.

JSCheck has a few other options and a bunch of specifiers that we haven't reviewed in this tutorial; head over to JSCheck.og to read about those. Otherwise, I’d love to hear your thoughts about JSCheck in the comments!

How to Super-Scale Magento in the Cloud

Jed Galbraith — Tue, 15 May 2012 17:31:25 +0000

This tutorial will help you prepare a Magento install for high traffic, better load times, and simpler ongoing site management. Ready?

Requirements

You can download the finished code for this tutorial, or launch the “magento-basic” Quickstart from your Pagoda Box account to test a working site.

A Pagoda Box Account (free)
A functional local Magento Install
Local Development Software (MAMP or WAMP)
Git Installed (Can use SFTP)
The Pagoda Terminal Client Installed

Fair Warning: This tutorial may change your life. Pagoda Box is not traditional hosting. The teachings in this article will not only help scale Magento, but it also lays the groundwork for a progressive development-to-production workflow.

Step 1: Set Up Git Locally (SFTP will work as an alternate)

Note: If you already use Git, you can skip this section. If not, the guide Setting Up Git provides specific instructions for creating an SSH Key, as well as links for downloading and installing Git (also below).

While it is possible to use just SFTP on Pagoda Box, the officially recommended (and most efficient) workflow integrates Git into your daily development. Git enables features like collaboration, uniform code distribution, deploys, deploy history and rolling back code. While most of these features are available to FTP users, using Git makes integration seamless.

If you want to fully take advantage of Pagoda Box, download Git, and Learn the Basics. Depending on your operating system, set up may vary slightly. Regardless of your OS, the commands are identical once Git is installed.

Using Git to manage collaboration and version control may involve a brief learning curve. However, there are generally only three commands we’ll use on an ongoing basis to commit changes locally, then deploy to Pagoda Box:

git add . – Adds local files to your repository
git commit -m "some message about what you've done" – Commits your changes
git push pagoda --all – Pushes changes to Pagoda Box Repository (auto-deployed by default)

We’ll use these later.

Step 2: Install the Pagoda Box Terminal Client


                             *
                           /   \
                         /       \
                     +_/ / / | \ \ \_+
                         ||*|||*||
                         |+||*||+|
                         /       \
                     +_/ / / | \ \ \_+
                         ||*|||*||
                         |+||*||+|
     ____   _    ____  ___  ____    _    ____   _____  __
    |  _ \ / \  / ___|/ _ \|  _ \  / \  | __ ) / _ \ \/ /
    | |_) / _ \| |  _| | | | | | |/ _ \ |  _ \| | | \  /
    |  __/ ___ \ |_| | |_| | |_| / ___ \| |_) | |_| /  \
    |_| /_/   \_\____|\___/|____/_/   \_\____/ \___/_/\_\

       Welcome To Your Pagoda Box Terminal Client.
      -----------------------------------------------
          -----------------------------------------
             ---------------------------------
                          Enjoy.

Pagoda Box provides a Terminal Client that lets you clone, create, deploy, destroy, rename and rollback an application from the command line. Later in this tutorial, we’ll use the client to create a secure tunnel to the live Magento database with Sequel Pro (the process is similar for other database managment tools like HeidiSQL).

The Pagoda Box Terminal Client is a rubygem, so installation is pretty simple. First off, Ruby needs to be installed. Installation is different for each operating system.

Mac – Ruby and RubyGems come pre-installed on Mac OSX. As long as you are running v10.5 or later, you should be good to go.
Windows – There are a couple of different ways to install Ruby in Windows. We recommend this auto-installer. If it doesn’t work for your set-up, a Google search will give you a pretty good list of installation walk-throughs.
Linux – Use your preferred package manager to download the Ruby package. For Ubuntu users, the gem is available through getdeb.net.

Install and Verify Terminal Client

Once Ruby is installed, simply run the following command to install the Pagoda RubyGem:

On Mac or Linux:

$ sudo gem install pagoda

On Windows:

$ gem install pagoda

Then, to verify you have the Pagoda Gem installed properly, run:

$ pagoda list

If this is the first time you’ve used the Gem, it will ask for your Pagoda Box Username and Password. After you’ve entered those, expect to see a list of your Pagoda Box applications. If you haven’t created any applications, the list will be blank.

If you get an error, it’s most likely invalid credentials. You can verify or change which credentials the gem uses by editing the file located on your local computer at ~/.pagodarc. Make sure to exactly match the credentials you use in your Pagoda Box account. (Note: this is a hidden file, so you’ll need to enable hidden files or open via the terminal. Also note that the file stores your credentials twice, so edit both if needed.)

Step 3: Install Magento Locally

Note: Skip this step if you already have a working local Magento install.

If you don’t have it already, ensure you are using local webserver and database management software. There are several options available, depending on your operating system. A common option for Mac is MAMP, or WAMP for Windows. Both are free and easily set up.

Once your local development environment is set up, go ahead and download Magento, then follow the official guide to install Magento locally.

Feel free to use Magento’s auto install script to set up the application in your local environment. However, due to Pagoda Box’s distributed cloud architecture, the script will not install Magento directly in your production environment. The Pagoda Box workflow and architecture requires you to make code modifications locally, commit, then deploy to production. This workflow accommodates collaboration and development > staging > production best practices.

Step 4: Configure PHP Using a Boxfile

Note: On Pagoda Box, a YAML Boxfile can be included in the root of your code repository. While the Boxfile is optional, it does provide advanced features, like manipulating your hosted environment on each deploy. We’ll use the Boxfile extensively in this Tutorial to simplify tasks, and to make the respository reusable on Pagoda Box.

Create a file named “Boxfile” in the root of your local Magento installation, then copy the following into your Boxfile (explanation below):

web1:
  name: mag-app
  shared_writable_dirs:
    - media
    - var
  php_version: 5.3.8
  php_extensions:
    - pdo_mysql
    - mysql
    - simplexml
    - mcrypt
    - hash
    - gd
    - dom
    - iconv
    - curl
    - soap

Create / Name the Web Cluster

This Boxfile serves several purposes. First, it creates a web1 component, then names it mag-app.

Shared Writable Directories

Second, the Boxfile identifies media and var as shared writable directories. This allows users to upload images, video, and other media to a distributed Magento cloud site without instances writing themselves out of sync.

When a directory is marked as writable, the contents are no longer deployed to Pagoda Box from your local repository. Any time local files need to be deployed to these directories, they must be manually copied via SSH or SFTP. You may also use SSH/SFTP to transfer files from Pagoda Box to your local machine as needed.

PHP Version and Extensions

The Boxfile also declares which PHP version and extensions will be included in your web instances as they deploy. This way, both the environment and the application are versioned together, so rolling back to a previous deploy includes the correct PHP version and extensions. The list of PHP extensions in this Boxfile was taken from Magento’s official system requirements.

Tip: Once Git is installed in your local environment, use the .gitignore file to ignore the writable directories specified in your Boxfile. Identifying these directories inside the .gitignore file helps reduce the size of your repo, and your deploy time. In addition to the writable directories, you can also add the downloader directory to the .gitignore file, since it’s used locally, and not on Pagoda Box.

Once you’ve installed Git and the Terminal Client, configured the Boxfile and finalized your local source code, you’re ready to launch on Pagoda Box.

Step 5: Create a Free Pagoda Box Account

If you don’t already have one, create a free Pagoda Box account. You will not need to enter a credit card to install Magento for testing.

If you have not already done so, follow this guide to Add an SSH Key in your Pagoda Box Admin panel. The guide will provide specific instructions for setting up an SSH Key on either Mac or Windows.

Step 6: Upload Magento to Pagoda Box

Once you’ve created a Pagoda Box account and set up an SSH Key, go to the Home Page in your new account and click the “New Application” button to create a new application.

Note: This tutorial names our sample application “magento”. The app name is also used for the Pagoda Box repository, the subdomain for the freshly deployed application (magento.pagodabox.com), and the username in SFTP mode. Replace “magento” with “your-app-name-here” where appropriate throughout the remainder of this tutorial.

Upload to an Empty Repo (recommended for this tutorial)

Next, choose from the 3 options to launch your Magento site. Since you already have a customized version of Magento locally, select ‘Empty Repo’ to deploy using SFTP or Git, name your application, and click “Launch Application”.

You’ll be asked to select your preferred deployment method (Git or SFTP). Click on your preference, and follow the instrutions on-screen.

Git Option

You can copy and paste the on-screen instructions from the Pagoda Box dashboard to your terminal after using Terminal to change directory (cd) to the root of your project.

The pasted commands do the following:

git init – Initialize your Magento project as a Git Repository
git add . – Add all files from the project to the repo
git commit -m 'your commit message' – Commit files with a message that allows you to quickly scan deploy history in the future, in case you need to revert or modify changes
git remote add pagoda git@git.pagodabox.com:magento.git – Add Pagoda Box as a remote (the specific git url for your application appears on both this screen, and in your app dashboard
git push pagoda --all – Push your local code to the Pagoda Box remote repository. As long as you’re on the “master” branch (which is the default), Pagoda Box will automatically deploy your code, and carry out the instructions we set in the Boxfile. Auto-deploy can be turned off in the Admin dashboard, or configured to deploy automatically from a Git branch other than Master.

SFTP Option

If you opted for SFTP, Pagoda Box will guide you through establishing credentials and a password. Connect via SFTP to Pagoda Box, and upload your Magento source code in the code directory.

Step 7: Create a Database

There are two ways to create a database on Pagoda Box. Each has benefits, explained below:

Create a DB in the Boxfile

The Boxfile will automatically create a database component on deploy, as long as that component (db1, db2, etc.) doesn’t already exist. Declaring the database in the Boxfile saves a bit of time now, and makes deploying multiple Magento sites from a standardized code base much simpler in the future. (Note: Only cloud DBs can be deployed from the Boxfile. If you need a larger, dedicated or redundant database, see the Dashboard option later in this Step.) Add the following to your Boxfile:

db1:
  name: mag-db
  type: mysql

Your updated Boxfile should look like this:

web1:
  name: mag-app
  shared_writable_dirs:
    - media
    - var
  php_version: 5.3.8
  php_extensions:
    - pdo_mysql
    - mysql
    - simplexml
    - mcrypt
    - hash
    - gd
    - dom
    - iconv
    - curl
    - soap
db1:
  name: mag-db
  type: mysql

Then commit changes to the updated file and push changes to Pagoda Box:

$ git commit -m "pagoda config"
$ git push pagoda --all

Alternate: Create a DB in the Dashboard

You can also create a database from the Pagoda Box Dashboard. This is where you add a larger, dedicated or redundant database.

First, click “Add Database” in the Dashboard.

Pagoda Box will step through a series of screens to configure your database, depending on your choices. If you’ve chosen the Dedicated option, you will be asked to size your database as follows:

Cloud databases usually deploy within minutes. If you chosen Dedicated, don’t get impatient. You may wait for up to 90 minutes for a big server to be provisioned to your specifications.

Step 8: Configure DB Credentials for Production

Your database automatically generates credentials when it’s created on Pagoda Box. We’ll use those credentials to configure Magento in production.

However, since Magento will be used in both local environments and in production, we need to supply different database credentials for each. We’ll use Deploy Hooks in the Boxfile to simplify this process by executing scripts or commands during deploy.

In the case of Magento, we’ll swap the local.xml file upon deploy. That way, without manually switching credentials, the app/etc/local.xml file will automatically have local database credentials in development, but production database credentials on Pagoda Box.

Create a local.xml for Production

First, create a directory named pagoda in root, then copy Magento’s app/etc/local.xml to the new directory.

Next, edit local.xml to include Pagoda Box database credentials from your account dashboard. Note that Pagoda Box uses 3 levels of authentication, so that even if your credentials are compromised, other users cannot access your database.

Swap local.xml Configs on Deploy

Add the following into your Boxfile, under the web1 section to create the Deploy Hook.

after_build:
  "mv pagoda/local.xml app/etc/local.xml"

Your updated Boxfile should look like this:

web1:
  name: mag-app
  shared_writable_dirs:
    - media
    - var
  php_version: 5.3.8
  php_extensions:
    - pdo_mysql
    - mysql
    - simplexml
    - mcrypt
    - hash
    - gd
    - dom
    - iconv
    - curl
    - soap
  after_build:
  - "mv pagoda/local.xml app/etc/local.xml"
db1:
  name: mag-db
  type: mysql

Then commit changes and push to Pagoda Box:

$ git add .
$ git commit -m "pagoda config"
$ git push pagoda --all

Step 9: Migrate the Database

With the same tools you use to manage a local database, you can securely manage a live database on Pagoda Box. We’ll use Sequel Pro for this example, but the process is similar for tools like HeidiSQL.

Export Your Local DB

When the Magento install script ran locally, it created several tables in the local database. Those tables need to be migrated to production.

First, export your local database using your database manager: File > Export.

Now choose a location, and Save the export.

Establish a Secure DB Connection

Now establish a database tunnel. Using the Pagoda Box Terminal Client, specify the app whose database you are trying to access, and the ID of the database component (e.g. db1), as in this example:

$ pagoda -a magento tunnel -c db1
--OR--
$ pagoda --app=magento tunnel --component=db1

Once the tunnel is established, use Sequel Pro (or similar) to connect to the database using the Host and Port provided by the Pagoda Terminal Client…

And the username and password in your Pagoda database credentials. These were automatically created with your database, and may be found in the Pagoda Box Dashboard under the database component (see example in Step 8).

Import and Update the Production DB

Next, import your database into production using Sequel Pro (or similar): File > Import. Now select the database export file, and Open.

Finally, since we ran the install script locally, it’s necessary to adjust the base url directly in the database before browsing the site. While you are still connected to the Pagoda Box database in Sequel Pro, navigate/filter to the core_config_data table and edit the value for the following paths:

web/unsecure/base_url
web/secure/base_url

The values for each should look something like this:

Step 10: Configure Mail

To protect your IPs from being flagged as spam, Pagoda Box uses the SMTP mail protocol to send email via third party mail provider SMTP credentials. In English, that means you need a company (like Gmail) that provides mail services.

Regardless of which mail provider you choose, enter account credentials from that provider in your Pagoda Box dashboard. It should look something like this:

Step 11: Cron Jobs (Optional)

A few recurring tasks in Magento (e.g. sending newsletters, log cleaning, customer notifications, etc.) need to happen periodically. The cron.php file located in Magento’s root will trigger these tasks. We’ll set up a Cron Job in the Pagoda Box admin panel to run cron.php every 15 minutes. (Note: To configure Magento specific tasks, see their Official Guide.)

Cron Jobs in the Boxfile

Cron Jobs can be added or updated via the Boxfile, then deployed to Pagoda Box. To schedule a task at 15 minute intervals, add the following to your Boxfile under the web1: component (change the “magento” to point to your own app name / subdomain):

  cron:
    - "*/15 * * * *": "curl -s -o /dev/null http://magento.pagodabox.com/cron.php"

Your updated Boxfile should look like this:

web1:
  name: mag-app
  shared_writable_dirs:
    - media
    - var
  php_version: 5.3.8
  php_extensions:
    - pdo_mysql
    - mysql
    - simplexml
    - mcrypt
    - hash
    - gd
    - dom
    - iconv
    - curl
    - soap
  after_build:
  - "mv pagoda/local.xml app/etc/local.xml"
cron:
    - "*/15 * * * *": "curl -s -o /dev/null http://magento.pagodabox.com/cron.php"
db1:
  name: mag-db
  type: mysql

Alternate: Cron Jobs in the Dashboard

In the Pagoda Box admin panel under the Cron tab, add the following (change the “magento” to point to your own app name):

Command: curl -s -o /dev/null http://magento.pagodabox.com/cron.php

Schedule: */15 * * * *

It should look like this:

Part 2 – Optimization: Redis, Scaling & Benchmarking

You’ve already gotten the heavy lifting out of the way. Your Magento application is scalable, and changes are easily deployed across all instances with $ git push pagoda --all.

In the follow-up article, we’ll optimize Magento, add a Redis cache, SSL and Domain aliases, then scale the application for benchmarking and production. See you soon!

Nettuts+

10 Things I Learned While Interning at YUI

A Bit of Background

1. Understanding the Library

Js Fundamentals Links

2. Using Git in a Team

Git Basics Links

3. Modular Architecture for Web Apps

4. NodeJS and YUI on the Server

It comes down to code management

5. Hacking Using YUI

Y.ScrollView

Y.Anim

Y.YQL

6. YUI App Framework

The Model

The View

The Router

7. Test Driven Development and YUI Test

Don’t forget to test, regardless of what you use.

8. Minifying and Linting Your JavaScript

Additional Reading

9. Coding with the User in Mind

10. “When all you have is a hammer, everything looks like a nail.”

Coda 2: Reviewed

The Good

It's Beautiful

Helpers

Clippings

Sites

CSS Helpers

Quick Open

Built-In Transmit

Terminal

The Bad

Multiple Cursors

Odd CSS Support

Webkit Love Affair

I Wish…

Git

Command Palette

Installing Plugins

Vi-Mode Option

Only Four Color Schemes

A Great Sidebar…But

Configurability

Closing Thoughts

Will I Switch to Coda 2?

3 Key Software Principles You Must Understand

Principle – Don’t Repeat Yourself

Achieving DRYness

An Example

Principle – Keep it Simple Stupid

HTTP

Principle – You “Ain’t Gonna Need It

Planning a Project

Summary

SSH: What and How

A Starting Explanation

A Brief History

So, How Do I Use It?

How Do I Use It… Better?

Super-quick Log-in

Git Without a Hub

SFTP > FTP

Easy Access to Your Server Almost Anywhere

A Local Code Repo

Some Other Helpful Links

Diving into CanJS

Choosing the Right Tool

Setting Up Your Folders And HTML

Building Your UI With Views

Displaying Contacts

Rendering A Single Contact

Making Your Views Live

Organizing Application Logic Using can.Control

Managing Contacts

Representing Data Using Models

Simulating a Rest Service Using Fixtures

Bootstrapping the Application

Organizing Application Logic Using `can.Control`

The `flow-into` Property and Named Flows

The `flow-from` Property