Maria Antonietta Perna, Jun 14

Faster WordPress Theme Development with the Beans Framework

In this tutorial, Maria Antonietta Perna covers how to build a WordPress theme super-fast, using the Beans Theme Framework.
Craig Buckler, Jun 14

7 PostCSS Plugins to Ease You into PostCSS

Are you confused by PostCSS? Are you worried about complicating your build process? Don't be - Craig reveals how and why you should use it.
Simon Codrington, Jun 14

Custom Android Layouts with Your Own ArrayAdapter

If you need a custom layout for your Android App, then you need your own ArrayAdapter. Simon Codrington shows you how to create and use them in your apps.
Design & UX
Alan Dargan, Jun 14

5 Things Every Designer Needs to Know About Conversational UIs

Conversational UIs are becoming more and more common but designing them requires a whole new skillset – more scriptwriter than graphic designer.
Design & UX
Angela Molina, Jun 13

Let's Talk about Sketch, Baby! With Sketch Guru, Daniel Schwarz

 We think it's important to connect you with subject matter specialists and give you a chance to say hello and ask them a question. Last week, we caught up with Daniel Schwarz for a chat about Sketch 3.
Daniel Schwarz, Jun 13

7 Excellent Collaboration Tools for Remote Teams

Keeping a remote team engaged and productive can be a challenge. Daniel Schwarz looks at the tools that can help you get the best results for your startup.
James Hibbard, Jun 13

A Round up of Online Code Playgrounds

James Hibbard looks at some of the more popular online code playgrounds and examines which are good for hosting demos involving a server-side components.
Chris Coyier, Jun 13

10 Cool Things You Can Do with CodePen and JavaScript

Tips ad tricks aplenty with Chris Coyier as he shows you a bunch of cool stuff you can do with CodePen and JavaScript.
Francesco Malatesta, Jun 13

Laravel Doctrine - Best of Both Worlds?

Francesco introduces Laravel Doctrine, and builds a sample app with it - come learn about this powerful ORM + Framework mix!
Ilya Bodrov-Krukowski, Jun 13

Make Easy Graphs and Charts on Rails with Chartkick

Ilya Bodrov-Krukowski shows you just how easy it is to make beautiful, interactive charts and graphs in your Rails app. Your users will love this.
Elio Qoshi, Jun 11

How to Scale from Freelancer to Founder with the Salami Technique

Elio Qoshi describes his approach to breaching the earnings limitations of freelancing by gently scaling into a larger services operation.
Hugo Giraudel, Jun 10

The Importance of Code Reviews

Hugo discusses the importance of code reviews, and how to get them happening within your development team.
Chris Ward, Jun 09

What Do Apple's App Store Changes Mean for Developers?

Chris Ward looks at Apple's forthcoming changes to the App Store, and whether they will be successful in improving revenue.
Jeff Mott, Jun 09

JavaScript Object Creation: Patterns and Best Practices

Jeff Mott guides you through a step-by-step approach to JavaScript object creation—from object literals, through factory functions, ending with ES6 classes.
Lukas White, Jun 09

How to Modernize a Booking System with Acuity Scheduling

Lukas White shows you how to bring a driving instructor's booking system into the 21st century using the Acuity Scheduling API.
George Martsoukos, Jun 09

Quick Tip: How z-index and Auto Margins Work in Flexbox

George Martsoukos looks at Flexbox and how to use z-index and auto margins in your CSS layouts.
Sally Wood, Jun 09

Even More WordPress Plugins for Writers

Sally Wood covers a few more WordPress Plugins designed to make the lonely, angst-ridden life of the online writer just that smidgen easier.
Design & UX
Maria Antonietta Perna, Jun 09

20 Inspirational, Free Tools For Better Typeface Pairing

We have access to a wider set of web fonts than ever before, but choice can be a tyranny. Luckily Antonietta has 20 tools to help you better pair type.
Devdatta Kane, Jun 09

Expose Your Rails CRUD to the Browser with Databound

Devdatta Kane explores using Databound to expose the RESTful CRUD interface of a Rails app directly to javascript in the browser. 
Design & UX
Alex Walker, Jun 08

Conversational UIs, R2-D2 and Avoiding the Uncanny Valley

What was the first 'killer phone app'? I'm talking about first non-voice offering that had droves of people buying mobile phones for the first time just to use it?

Was it Google Maps? Maybe the YouTube app? Bejewelled? Facebook?

No - as important as they were, I think the original killer app has to be SMS (or texting). Sending little notes to each other doesn't sound very innovative or exciting, but from the early 90's onwards, SMS drove the adoption of cellphones and provided an obscenely lucrative revenue stream to phone network providers.

People seemed to like SMS for three reasons.

  1. It was private
  2. It was simple
  3. It felt familiar

We all probably passed notes in class and stuck them on the refrigerator door. SMS just let us pass them across the world.

Many of the first big online services for desktop computers used the same chatty approach - ICQ, Yahoo IM, AIM, and MSN Messenger.

Even today Facebook Messenger, Whatsapp Twitter, and Slack have billions of users every day tapping out short text messages to each other.

What can we say? Humans really like this format.

Birth of the Conversational User Interface

The last two years have seen the rise of a new kind of user interface. Slack were one of the first companies to realize that this 'human-to-human' chat format might work just as well for human-to-app interactions.

Instead of using a standard account creation sign-up form, Slack used their 'Slackbot' like a welcoming hotel concierge.

Slackbot sign-up

And it made so much sense. They want you to chat - why not start chatting from the first moments you use the app? The idea has been reproduced many times since.

Quartz: Chatty News App

Quartz is a new news app (currently iOS only) that takes the idea of conversational UIs to a new level.

While Slack was a chat client just expanding where it chatted, Quartz jams news events into an SMS-like format. It's a bit like having a friend SMSing you newspaper snippets to read on the train. You can ask your friend for more detail on the story or tell them to move on.

Quartz in action

While I'm not totally convinced yet that Quartz is a winner, it is a brilliantly original way to think about presenting news. It's loose and informal and easily the most clutter-free news UI you've ever seen. Each time you read a new message and make a yes/no decision - Quartz handles the rest. Interesting.

One interesting little UI touch is the 'typing' indicator that appears just before Quartz posts a new message to screen – three drumming dots inside a speech bubble (see the animation below).

We're all familiar with this idea. In real world conversations, we can signal with body language that we're about to speak. In chat apps from ICQ in 1996 to Slack today, we get a visual indicator that the other person is in the act of replying. It's a useful protocol.

But this is an app speaking to us - not a friend or colleague.

Quartz Conversational UI

Now let's be frank: We all implicitly understand that this is all 'UX theater' for our benefit. Even my 10-yo daughter immediately picked it. There's nobody banging away at a real keyboard.

So, how do we feel about that?

I'm not sure about you, but I've been surprised by my own gut reaction. My designer brain tells me I should be dismissive and snarky. "Bah! How dare you slow down my experience with such feeble parlor tricks!" (yes, my designer brain sounds like Professor Moriarty)

But my UX-self started grudgingly liking it - and I couldn't understand why at first.

Shaumik Daityari, Jun 08

Jump Start Git: Branching in Git


The following is a short extract from our book, Jump Start Git, available for free to SitePoint Premium members. Print copies are sold in stores worldwide, or you can order them here. We hope you enjoy this extract and find it useful.

In Chapter 1, I talked about my one-time fear of trying out new things in a project. What if I tried something ambitious and it broke everything that was working earlier? This problem is solved by the use of branches in Git.

What Are Branches?

Creating a new branch in a project essentially means creating a new copy of that project. You can experiment with this copy without affecting the original. So if the experiment fails, you can just abandon it and return to the original—the master branch.

But if the experiment is successful, Git makes it easy to incorporate the experimental elements into the master. And if, at a later stage, you change your mind, you can easily revert back to the state of the project before this merger.

So a branch in Git is an independent path of development. You can create new commits in a branch while not affecting other branches. This ease of working with branches is one of the best features of Git. (Although other version control options like CVS had this branching option, the experience of merging branches on CVS was a very tedious one. If you've had experience with branches in other version control systems, be assured that working with branches in Git is quite different.)

In Git, you find yourself in the master branch by default. The name “master” doesn't imply that it's superior in any way. It's just the convention to call it that.

Note: Branch Conventions

Although you're free to use a different branch as your base branch in Git, people usually expect to find the latest, up-to-date code on a particular project in the master branch.

You might argue that, with the ability to go back to any commit, there's no need for branches. However, imagine a situation where you need to show your work to your superior, while also working on a new, cool feature which is not a part of your completed work. As branching is used to separate different ideas, it makes the code in your repository easy to understand. Further, branching enables you to keep only the important commits in the master branch or the main branch.

Yet another use of branches is that they give you the ability to work on multiple things at the same time, without them interfering with each other. Let's say you submit feature 1 for review, but your supervisor needs some time before reviewing it. Meanwhile, you need to work on feature 2. In this scenario, branches come into play. If you work on your new idea on a separate branch, you can always switch back to your earlier branch to return the repository to its previous state, which does not contain any code related to your idea.

Let's now start working with branches in Git. To see the list of branches and the current branch you're working on, run the following command:

[code language="bash"]git branch [/code]

If you have cloned your repository or set a remote, you can see the remote branches too. Just postfix -a to the command above:

[code language="bash"]git branch -a [/code] [caption id="attachment_131959" align="alignnone" width="264"]Command showing the branches in the local copy as well as the origin branch Command showing the branches in the local copy as well as the origin branch[/caption]

As shown above, the branches that colored red signify that they are on a remote. In our case, we can see the various branches that are present in the origin remote.

Create a Branch

There are various ways of creating a branch in Git. To create a new branch and stay in your current branch, run the following:

[code language="bash"]git branch test_branch [/code]

Here, test_branch is the name of the created branch. However, on running git branch, it seems that the active branch is still the master branch. To change the active branch, we can run the checkout command (shown below):

[code language="bash"]git checkout test_branch [/code] [caption id="attachment_131988" align="alignnone" width="300"]Creating a new branch and making it active Creating a new branch and making it active[/caption]

You can also combine the two commands above and thereby create and checkout to a new branch in a single command by postfixing -b to the checkout command:

[code language="bash"]git checkout -b new_test_branch [/code] Create and checkout to a new branch in a single command

The branches we've just created are based on the latest commit of the current active branch—which in our case is master. If you want to create a branch (say old_commit_branch) based on a certain commit—such as cafb55d—you can run the following command:

[code language="bash"]git checkout -b old_commit_branch cafb55d [/code] [caption id="attachment_131995" align="alignnone" width="575"]Creating a branch based on an old commit Creating a branch based on an old commit[/caption]

To rename the current branch to renamed_branch, run the following command:

[code language="bash"]git branch -m renamed_branch [/code]

Delete a Branch

To delete a branch, run the following command:

[code language="bash"]git branch -D new_test_branch [/code] [caption id="attachment_131996" align="alignnone" width="300"]Deleting a branch in Git Deleting a branch in Git[/caption]

Note: Don't Delete Branches Unless You Have To

As there's not really any downside to keeping branches, as a precaution I'd suggest not deleting them unless the number of branches in the repository becomes too large to be manageable.

The -D option used above deletes a branch even if it hasn't been synchronized with a remote branch. This means that if you have commits in your current branch that have not been pushed yet, -D will still delete your branch without providing any warning. To ensure you don't lose data, you can postfix -d as an alternative to -D. -d only deletes a branch if it has been synchronized with a remote branch. Since our branches haven't been synced yet, let's see what happens if we postfix -d, shown below:

Deleting a branch in Git using the -d option

As you can see, Git gives you a warning and aborts the operation, as the data hasn't been merged with a branch yet.

Branches and HEAD

Now that we've had a chance to experiment with the basics of branching, let's spend a little time discussing how branches work in Git, and also introduce an important concept: HEAD.

As mentioned above, a branch is just a link between different commits, or a pathway through the commits. An important thing to note is that, while working with branches, the HEAD of a branch points to the latest commit in the branch. I'll refer to HEAD a lot in upcoming chapters. In Git, the HEAD points to the latest commit in a branch. In other words, it refers to the tip of a branch.

A branch is essentially a pointer to a commit, which has a parent commit, a grandparent commit, and so on. This chain of commits forms the pathway I mentioned above. How, then, do you link a branch and HEAD? Well, HEAD and the tip of the current branch point to the same commit. Let's look at a diagram to illustrate this idea:

[caption id="attachment_132000" align="alignnone" width="609"]Branches and HEAD Branches and HEAD[/caption]

As shown above, branch_A initially is the active branch and HEAD points to commit C. Commit A is the base commit and doesn't have any parent commit, so the commits in branch_A in reverse chronological order (which also forms the pathway I've talked about) are C → B → A. The commits in branch_B are E → D → B → A. The HEAD points to the latest commit of the active branch_A, which is commit C. When we add a commit, it's added to the active branch. After the commit, branch_A points to F, and the branch follows F → C → B → A, whereas branch_B remains the same. HEAD now points to commit F. Similarly, the changes when we add yet another commit are demonstrated in the figure.

Advanced Branching: Merging Branches

As mentioned earlier, one of Git's biggest advantages is that merging branches is especially easy. Let's now look at how it's done.

We'll create two new branches—new_feature and another_feature—and add a few dummy commits. Checking the history in each branch shows us that the branch another_feature is ahead by one commit, as shown below:

[caption id="attachment_132001" align="alignnone" width="546"]Checking the history in each branch Checking the history in each branch[/caption]

This situation can be visualized as shown below. Each circle represents a commit, and the branch name points to its HEAD (the tip of the branch).

[caption id="attachment_132005" align="alignnone" width="1024"]Visualizing our branches before the merge Visualizing our branches before the merge[/caption]

To merge new_feature with master, run the following (after first making sure the master branch is active):

[code language="bash"]git checkout master git merge new_feature [/code]

The result can be visualized as shown below:

[caption id="attachment_132007" align="alignnone" width="1024"]The status of the repository after merging new_feature into master The status of the repository after merging new_feature into master[/caption]

To merge another_feature with new_feature, just run the following (making sure that the branch new_feature is active):

[code language="bash"]git checkout new_feature git merge another_feature [/code]

The result can be visualized as shown below:

[caption id="attachment_132009" align="alignnone" width="1024"]The status of the repository after merging another_feature into new_feature The status of the repository after merging another_feature into new_feature[/caption]

Important: Watch Out for Loops

The diagram above shows that this merge has created a loop in your project history across the two commits, where the workflows diverged and converged, respectively. While working individually or in small teams, such loops might not be an issue. However, in a larger team—where there might have been a lot of commits since the time you diverged from the main branch—such large loops make it difficult to navigate the history and understand the changes. We'll explore a way of merging branches without creating loops using the rebase command in Chapter 6.

[caption id="attachment_132011" align="alignnone" width="551"]The status of branch new_feature after the merge The status of branch new_feature after the merge[/caption]

This merge happened without any “conflicts”. The simple reason for that is that no new commits had been added to branch new_feature as compared to the branch another_feature. Conflicts in Git happen when the same file has been modified in non-common commits in both branches. Git raises a conflict to make sure you don’t lose any data.

We’ll discuss conflicts in detail in the next chapter. I mentioned earlier that branches can be visualized by just a simple pathway through commits. When we merge branches and there are no conflicts, such as above, only the branch pathway is changed and the HEAD of the branch is updated. This is called the fast forward type of merge.

The alternate way of merging branches is the no fast forward merge, by postfixing --no-ff to the merge command. In this way, a new commit is created on the base branch with the changes from the other branch. You are also asked to specify a commit message:

[code language="bash"]git merge --no-ff new_feature [/code]

In the example above, the former (merging new_feature with master) was a fast forward merge, whereas the latter was a no fast forward merge with a merge commit.

While the fast forward style of merges is default, it’s generally a good idea to go for the no fast forward method for merges into the master branch. In the long run, a new commit that identifies a new feature merge might be beneficial, as it logically separates the part of the code that is responsible for the new feature into a commit.


What Have You Learned?

In this chapter, we discussed what branches are and how to manage them in Git. We looked at creating, modifying, deleting and merging branches.

What’s Next?

I’ve already spoken about how Git is beneficial to developers working in teams. The next chapter will look at this in more detail, as well as specific Git actions and commands that are frequently used while working in a distributed team.

Joel Falconer, Jun 08

Are You Prepared for an Automated Future?

The future of work has changed a lot over the past decade. It's going to change again - by disappearing.
Camilo Reyes, Jun 08

3 Ways to Work More Effectively in a Web Development Team

Camilo Reyes shares some important tips on working effectively in a team, growing as a programmer, and stepping up as a leader.
Dan Prince, Jun 08

10 Lodash Features You Can Replace with ES6

Dan Prince demonstrates 10 ways in which you can use native ES6 features (such as arrow functions & collection methods) to replace Lodash in your projects.