About the Author:

Why Use a Task Runner Like Gulp?

August 8th, 2015

There are a lot of tasks involved with creating and deploying a front-end application.  Common tasks include things like watching file changes, concatenating/minifying files, prefixing files for different browsers, and linting Javascript.  Before task runners like Gulp and Grunt existed, these tasks were often done using shell or bash scripts on the command line.

Javascript, for example, can be minified in many ways using the command line.  Let’s explore one way I found in a post called Minify JS from the command line. The steps involve installing Java (or checking the version already installed), installing Google’s Closure Compiler, and then running a script on the command line to minify a JS file: (more…)

About the Author:

The Office Door Effect

September 11th, 2014

Here at appendTo, we are a fully distributed company. We all work from home offices across the country and world, rarely connecting with one another in a physical space during the normal course of our work day.

The key to making this a success has been our perspective of translating the normal human interactions we are accustomed to in a physical office into the virtual environment.

One of the simplest habits we train every employee on is the Office Door Effect. When you work in a physical office, depending on the layout, humans observe when others enter or exit the building.

We replicate this by asking everyone to drop a message into a chat room when they arrive for work, when they leave, or when they briefly step away.  We’ve tried accomplishing this through chat status notifications, but it is never quite the same.

This creates a chat room with many small comments of, “Good Morning” or “Stepping away for a moment” which may seem like noise, but has had an incredibly positive impact on our culture.

It brings everyone together because it demonstrates commitment to our jobs by indicating whether we are focused on work at any given time or doing something else in front of our computers. It provides an easy and asynchronous way to discover where people are when they don’t immediately respond to a chat message.

The other important thing dropping a message into a room conveys is the duration of absence.  If you say, “Out for a few hours”, we know when to expect your return. If someone needs to connect with you, they can then decide whether to wait or proceed with other tasks until you return. If a client contacts us and needs access to a particular developer, it can also help us mitigate their need by giving them a specific availability time frame, or offering the services of a developer who’s immediately available.

We have a special “heads down” status that typically means someone is online for “emergency” purposes, but otherwise should not be disturbed because they are concentrating on a particular task or problem.

We use Slack as our platform to communicate all of the above, and love using it as our chat system. However, Slack is currently set up so that we have to manually type status messages into the chats. Adding an automated feature that would do this for us would make communicating on Slack a more seamless process. That said, we’ve recently submitted a feature request to Slack, to which they’ve been responsive and all around awesome.

How do you indicate presence in your organization?

About the Author:

Modern Web Conference 2014

August 22nd, 2014

We at appendTo recently hosted our inaugural Modern Web Conference. The two-day virtual conference for front-end web enthusiasts focused on the tools and technologies needed to build the modern web. We kicked off the first day with our Web Technologies track that was centered around web languages such as HTML, CSS, JavaScript other trending frameworks and libraries.

On day two, we delved into our Web Developers Workflow track during which we presented tips on which tools help to enhance workflow, increase code quality and let developers concentrate on true innovation without being bogged down by basic setup and ongoing maintenance. Here’s a breakdown of what was discussed during the event:

Day 1

The focus of day 1 was on sharpening your skills with the tools of the modern web, HTML, CSS, and JavaScript as well as any helper libraries or frameworks. Mike Hostetler, our former CEO and current Director of appendTo’s parent company Epic Creative, opened the day’s sessions with his presentation on the realtime MVC framework, Sails.js. Sails is a framework for building web applications built on Node and shares many common architectural patterns with Ruby on Rails, hence the name, “sails”. He went on to demo some of Sails’ great features such as web socket, HTTP-based controller routes, the ORM waterline for easily creating a data layer, as well as its flexible asset, pipeline. He also created a basic app showing off the power and ease of use it has similar to Rails.

Dave Methvin, president of the jQuery foundation, Dave Methvin, highlighted some of the features in jQuery that exist now. Dave showed us some really interesting features of jQuery and took a deep dive into the nitty gritty of older jQuery APIs.

Following Dave’s insightful jQuery presentation, Bess Fernandez, a front-end developer at Articluate, presented Bootstrap, one of the most popular HTML, CSS and JavaScript frameworks used today. Many people who were attending the conference who had not yet gotten a chance to see Bootstrap were very impressed and expressed their desire to go check out the framework after attending Bess’s inspiring session.

Perhaps one of the most mind blowing talks of the day was given by one of our Visual Design Engineers, Trevan Hetzel. The talk titled, CSS Can do THAT?, clearly had everyone watching while reeling in the awe of what CSS can do. He demo’d an entirely JavaScript-less page that used some amazing CSS hacks for doing things like page clicks, accordions, toggling content, and a navigation menu. It was pretty incredible to see what you can accomplish with nothing but CSS.

Doug Neiner, our Vice President of Products, gave a talk on events and messaging strategies in JavaScript. Starting off with the basic forms of events, he then continued to get increasingly deeper into architecting sites with messaging and events in JavaScript. He mentioned some client side messaging libraries such as [postal.js and monologue.js that can help build complex decoupled applications in JavaScript by separating references to parts of the application. By separating different systems of an application and communicating with messages, it’s possible to create a maintainable and testable application.

AngularJS is arguably the most popular client-side MVC framework around these days, so it’s no surprise that it made a presence at the Modern Web Conference as well. Burke Holland, a Developer Advocate at Telerik, entertained and enlightened us on AngularJS directives during his presentation. Angular, although popular, definitely has its complicated parts, and Burke really helped add clarity to some of the “computer sciency” things in Angular like scope, transclusion, and many others. His demos on creating reusable directives really inspired the viewers and clearly showed how powerful Angular can be once you get passed its initial learning curve.

Day one wrapped up with a presentation by Estelle Weyl. She capped off the day with a great talk on CSS3 animations. It was very cool once again to see the power of what CSS can do for a web application. She was able to demo some fairly complicated animations that require only a few lines of CSS and once again, the viewers of the conference were blown away by the things you can accomplish in CSS.

Day Two

The second day of the Modern Web Conference was all about tools that developers use to make our lives easier. Seven great talks were given on day two that showed the audience how to be more efficient when working with client side code.

Starting off the day was a highly informative talk on one of the most important tools of working on a team these days, Git. Jordan Kasper gave a very thorough run through of all that you can accomplish with the most popular DVCS (Distributed Version Control System). He demo’d getting started with Git all the way to connecting to GitHub, working with `Git bisect`, rebasing, and several other of Git’s built in tools. Everyone had a great time learning about Git and one viewer even said that Git was much less of a mystery to him now after having heard the talk.

I actually spoke during the second slot on day two about the importance of unit Testing your client side code. I covered the basics of why you need to unit test your code for things like bugs, design, and maintainability. I also talked about some of the different testing strategies that exist out there like TDD and BDD. TDD on the client side was definitely the biggest focus of my talk and I also discussed red/green/refactor while working with the simple test framework, QUnit.js. A few other tools such as Sinon.JS, plato, and Blanket.js were also presented. These tools can help ensure that bug free-ish code make their way into production and the time spent fixing bugs is lessened by focusing more on the code at the forefront of a project rather than after launch.

A lot of developers tend to spend the majority of their time in the Chrome developer tools, but Raymond Camden of Adobe aimed to prove that there are many great features of other browsers including IE11 that can also be a great help to developers by showing off the developer tools for Chrome, IE, Firefox, Safari, and Opera, and proved how each one can handle an error or some edge cases slightly differently. The audience was very surprised to see just how different the debugging experience can be from browser to browser, and was also enjoying the pictures Raymond had in his presentation as well as his awesome tattoos.

One of the most tedious parts of working with web applications is downloading and installing all the third party JavaScript files necessary for a modern web application. Starting with Backbone.js as the example since it requires both jQuery and Underscore as dependencies. Bob Yexley, a Senior JavaScript Engineer at appendTo gave a great overview of using Bower to manage an application’s dependencies. Rather than having to go to all the different third party sites, download everything, copy it into the right directories, etc etc, with Bower it’s as easy as `bower install backbone`. It’s much simpler to work with Bower because it works similar to NPM where you have a `bower.json` file that keeps track of the various libs that have been installed. This means you can keep your JavaScript dependencies out of your DVCS repo, and simply run `bower install` when you need them. He also exhibited how easy it is to add Bower to your library and make it usable by anyone.

It’s a good thing that there was a break after the Bower talk because Ryan Niemeyer, another Senior JavaScript Architect, stepped up to the plate and rocked it with a talk on Browser Memory Leak Testing. The “oohs and awws” were pouring in from the audience as Ryan de-mystified one of the most challenging tools in the developer tools of any browser, memory analyzing. He showed off and explained how to work with these tools, and how to prevent simple mistakes that can lead to memory leaks in your JavaScript code. Many of the things were as simple as removing event handlers as soon as an element is out of the DOM, which is something that is extremely common, but the browser clearly will hold on to memory if you’re not careful. He also showed off how NOT to use the delete keyword, but rather set variables to null to set them up for garbage collection.

No front-end application these days would be complete without some sort of automation. Whether it’s a library or a web app, it’s important to have something like Grunt or Gulp running tasks on your code such as testing, minifying, deploying, etc. Elijah Manor from Dave Ramsey in Franklin, TN showed off how easy it is to get started with Grunt. He showed off some of the popular plugins that you can easily implement in your build and also noted that there’s almost 3,000 plugins you can use with Grunt! This talk helped a few in the audience go from hearing about grunt to wanting to go try it out for themselves.

The final talk of the day was a very technical intro to a new vm tool known as Vagrant. Tim Ambler went straight into demoing this very cool new virtual machine system. He explained how you simply install VirtualBox, and Vagrant and can get started with a Vagrant setup file to tell vagrant to quickly and efficiently set up a virtual machine that latches on to your current system. There are many different images you can use from the Vagrant cloud or create your own Vagrant image to allow you to setup a server running Ngnix, Ruby, and Node in a matter of minutes. Vagrant looks like a great tool to manage a team of developers on different platforms because no matter what OS they are running, a VM will be created that the developers can easily connect to and run applications.

Conclusion

The first virtual Modern Web Conference was a great success and left me excited to go play with all of the new information I had amassed over just two days! There were so many new tools and frameworks presented that I couldn’t wait to try for myself. We’re looking forward to another Modern Web Conference next year to continue promoting how powerful the Modern Web is compared to techniques we were using not that long ago. It’s incredible to see how far we’ve come as web developers and designers and there’s no telling where we’ll be next.

About the Author:

Continuous Integration: A View into appendTo’s Process

August 14th, 2014

Recently appendTo has been leveling up many of our internal processes, procedures, and standards. This has been a long time coming, but has been given dedicated attention recently. One of these efforts, the focus of this article, is appendTo’s most recent upgrade to our continuous integration and deployment (CI/CD) procedure and systems. This is one big piece of a larger standards and practices effort that is ongoing within our organization, and which benefits both our customers as well as our staff. If you would like to read more about our general developer workflow, standard practices, and tools you should read Aaron Bushnell’s recent article titled “The Tools We Use“!

Unique Requirements

There are some unique challenges to solve in a professional services organization when it comes to project server management. Each client, and each project for those clients, inevitably has unique software requirements. One client may have a back end in Rails which requires a specific application and testing stack while another may use Node.js with MongoDB. Furthermore, we could have one client which needs to use Node.js 0.10.28 because 0.10.29 has some change that breaks their application. These widely varying requirements result in appendTo not being able to simply deploy all client applications to a single staging server, we have to have unique environments.

Unfortunately, we don’t typically have the freedom to assign a server administrator to each project, and even if we could, that would not be the best use of our time, and thus our client’s investment. The solution that appendTo has implemented balances the needs of our clients with ease of use for our developer staff. The system is highly automated, but allows for extensive customization of the entire build process by the developers through simple JSON configuration within the project repository. We use TeamCity for version control triggers, build step management, access control, and reporting and logging. On the other side of the process we use Digital Ocean (and their HTTP API) to dynamically generate virtual machines (droplets) when needed and host and serve application files.

Bridging the Gap

The biggest problem we had with TeamCity was the ability to integrate, in the way we needed to, with the Digital Ocean API and individual droplets. We needed to create new droplets on the fly, allow each application to configure them during provisioning, deploy the application files, test them, and of course serve them up for our clients to see. TeamCity is written in Java, and while it may have been nice to integrate directly with that piece of this puzzle, we decided to create a solution which abstracts us one layer from that tool. That drove our engineers to create a bridge application which accepts commands (in this case from TeamCity) and executes code in our deployment system (Digital Ocean droplets) via a set of Node.js scripts and libraries. The benefit is that if either TeamCity or Digital Ocean need to be replaced in our stack, our unique build and deployment process can be salvaged and reused in the new stack. Of course, one of our greatest strengths at appendTo is our deep knowledge of JavaScript, which made Node a natural choice for this bridge.

So what does this all look like? The diagram below identifies the big pieces, on the left we have Github, where all of our application code resides. TeamCity, on the server in the center of the diagram, will identify code changes in a repository and initiate a build process. The build process will send various commands, in a particular order, to the Node application which in turn interacts with the Digital Ocean HTTP API and directly with the droplets over ssh. The droplets are provisioned when necessary (usually on first run) from a standard image that gives projects access to commonly needed software (like Node). Finally, the Node scripts report the results of each action to TeamCity in order to create a single source for build logs and history.

ci-cd process diagram

Wrap It Up and Put a Bow On It

This setup works very well for our needs, but we wanted to make things easier on our developers. To that end we made each step of the build process configurable within the project itself. Many of our projects use Grunt to run tests, concatenate and minify files, and generally build a project for distribution. In order allow for the simplest integration of that process, the specific actions required for each build step are specified in the “scripts” block of the project’s package.json file (a Node artifact).

Here is what that might look like:

{
    "name": "my-project",
    ...,
    "scripts": {
        "provision": "apt-get install mongodb",
        "install": "bower install",
        "test": "grunt test",
        "stop": "forever stopall",
        "deploy": "grunt deploy",
        "start": "forever server/main.js"
    }
}

Each of the lines in this “scripts” block maps to a step (or part of a step) in the larger build process. They will all be executed within the code directory, meaning developers don’t need to worry about where the code is located and can focus on what needs to be done to make it work. Additionally, since each line is executed (essentially) on the command line over ssh, the developer could specify a shell script should their process be overly complex for a one-line statement. Note that using Grunt is not at all required, but this process simplifies using tools like it with continuous integration and deployment.

Sustainable Process

As we discussed earlier, the goal with this bridge application written in Node is portability. Should we need to transition to a new tool on either side of that diagram above, we can reuse what we have written and our existing projects will require no alterations. This makes our developers happy, our clients happy, and results in better solutions delivered faster.

By implementing better standards and practices, and properly vetting those through our development staff, appendTo is able to accomplish two simultaneous goals: rapidly deliver better solutions to our clients and make the lives of our developers easier. The first may seem obvious, better standards (and adherence to them) directly translates into cleaner, more manageable code. The second may not be as obvious, but it is just as important to us. We value our developers’ time as well as their opinions. That’s why we vet our standards through them. Any employee is able to submit a change to our standards and practices. This change will be discussed among the entire organization and ultimately is approved by an S&P board which is composed of upper level engineers.

About the Author:

The Tools We Use

August 12th, 2014

We develop with many different tools at appendTo. We have resources for everything from project management to preprocessing. While these tools change over time, we’ve found our current setup works well for us. In this post, I’m going to cover how we use Pivotal Tracker, GitHub, Grunt, Bower, and Stylus. I’m also going to mention a little bit about our deployment process.

(more…)

About the Author:

Your next CMS should be Craft or ExpressionEngine

August 11th, 2014

When it comes to content management systems there are hundreds of thousands of options. Even within a specific language like PHP there’s a vast array of different choices. I’m going to talk about two popular PHP CMS solutions: Craft and ExpressionEngine. I want to discuss why, I think their powerful data modeling, flexibility, and communities make them two of the best choices for a CMS. (more…)

About the Author:

Testing front-end code without the server

June 3rd, 2014

Our own Jordan Kasper, a Senior JavaScript Engineer, tackles the opaque subject of front-end testing in a fantastic blog post he put up last night. Specifically, Jordan breaks down how to test without relying on a server, making your tests easier to write and easier to manage.

The existence of a server does not determine the success of your front end testing strategy.

That is the basis, a thesis almost, for the rest of this post. The fact is that of the few of you actually doing front end testing, most are doing so with the “help” of a testing server that provides data from some pre-filled database. This is wrong.

This may not sit well with any of you, but my guess is that if you’re reading this post, then you are interested in making your front end testing better. So, let me repeat that point just to be clear: with few exceptions, using any pre-defined, pre-populated, pre-initialized server is not the best way to properly test your front end code.

Check out the rest of Jordan’s post over on his blog.

About the Author:

Replacing Common UI Icons with CSS

March 11th, 2014

Let’s be honest, dealing with images on the web is kind of a pain. They’re a pain to modify, load slowly and require all sorts of progressive techniques in a responsive environment. But, unfortunately, images are here to stay; there’s no better way to capture a moment in time than with an image. However, we can significantly reduce our use of images by using CSS to recreate elements. But how can we do this while still keeping our designs visually appealing?

With our powers combined

Modern browser technology is our best friend, namely the technology of CSS with its shape rendering capabilities. We can do some crazy stuff with CSS alone! So in this article, we’re going to start simple and see how we can replace common user interface icons with just CSS. No more loading custom icon fonts or exporting PNGs.

Explore CSS Courses

Let’s jump right in

We’re going to go through the creation of 5 fairly standard UI icons:

Hamburger icon

Mail icon

Heart icon

Home icon

Camera icon

I’ve chosen these mainly because they can be easily created with little code and with only one element.

A quick note on browser support: anytime I use the border-radius or transform properties, I’m not prefixing them with vendor prefixes, so you may want to add their proper prefixes for wider browser support. Also, all of the examples below work in all modern browsers, including IE9.

Hamburger icon

We see this hamburger-looking icon a lot in mobile navigation patterns. It’s a very simple one to create with CSS, as it’s just 3 rows with some space in between.

The markup for all of these icons will be the same. We’ll use the i element with a reusable icon class and a unique identifier class, like icon_hamburger.




.icon {
  position: relative;
  display: inline-block;
}

.icon::before,
.icon::after {
  content: "";
  position: absolute;
}

Notice I created rules for the ::before and ::after pseudo-elements and set the content property to an empty string and positioned them absolutely. We’ll be relying heavily on these pseudo-elements to get the job done (hence why we can create these icons with only one HTML element).

For the hamburger icon, we’ll start off by giving .icon_hamburger a width, height and background.

.icon_hamburger {
  width: 1.625em;
  height: .313em;
  background: black;
}

Hamburger icon step 1

Now to add in the top and bottom lines. We’ll use ::before for the top line and ::after for the bottom.

.icon_hamburger::before,
.icon_hamburger::after {
  width: 1.625em;
  height: .313em;
  background: black;
}

.icon_hamburger::before {
  top: -.625em;
}

.icon_hamburger::after {
  bottom: -.625em;
}

Hamburger icon step 2

That’s it! It’s so much easier than an image to maintain, too. Want to change the width? Just modify the pixel value; no Photoshop required! Want to change the color? Easy!

[cta id=”3126″ align=”none”]

Mail icon

The mail icon (envelope) is another item commonly seen in many UIs. To start out, we’ll set the borders to create a rectangle with a triangle notched out of the top. Joel Glovier wrote a great article a while ago on the appendTo blog explaining how CSS triangles work.

.icon_mail {
  border-top: 1.063em solid transparent;
  border-right: 1.25em solid black;
  border-bottom: .5em solid black;
  border-left: 1.25em solid black;
}

Mail icon step 1

Then to create the envelope flap, we’ll use the same technique again to create a triangle with a negative top and left value. The negative top value offsets it from the top just enough to provide the space between the flap and the actual envelope.

.icon_mail::before {
  top: -1.25em;
  left: -1.25em;
  border-top: 1.063em solid black;
  border-right: 1.25em solid transparent;
  border-left: 1.25em solid transparent;
}

Mail icon

Heart icon

Creating the heart shape involves rotating the pseudo-elements with the transform property, and applying a large border-radius to the top of each tilted rectangle. The main element itself needs no properties at all. First, we’ll create two rectangles out of our ::before and ::after pseudo-elements.

.icon_heart::before,
.icon_heart::after {
  width: 1em;
  height: 1.563em;
  background: black;
}

.icon_heart::after {
  left: .375em;
}

Heart icon step 1

Then we’ll rotate them.

.icon_heart::before,
.icon_heart::after {
  width: 1em;
  height: 1.563em;
  background: black;
}

.icon_heart::before {
  transform: rotate(135deg);
}

.icon_heart::after {
  left: .375em;
  transform: rotate(45deg);
}

Heart icon step 2

And lastly, add a border-bottom-radius to the ::before pseudo-element (because it’s rotated upside down) and a border-top-radius to the ::after.

.icon_heart::before {
  transform: rotate(135deg);
  border-bottom-radius: .5em;
}

.icon_heart::after {
  left: .375em;
  transform: rotate(45deg);
  border-top-radius: .5em;
}

Heart icon step 3

Home icon

Creating a home icon starts out by morphing the main element into a triangle.

.icon_home {
  border-bottom: .938em solid black;
  border-left: .938em solid transparent;
  border-right: .938em solid transparent;
}

Home icon step 1

Then we’ll just create two vertical rectangles below the triangle and space them apart to give the impression of a door in the middle.

.icon_home::before {
  width: .563em;
  height: .625em;
  background: black;
}

.icon_home::before {
  margin: .938em 0 0 -.688em;
}

.icon_home::after {
  margin: .938em 0 0 .125em;
}

Home icon step 2

Camera icon

The camera icon, like the mail icon, starts out as a rectangle with a small border-radius.

.icon_camera {
  width: 1.938em;
  height: 1.375em;
  margin-top: .813em;
  background: black;
  border-radius: .125em;
}

Camera icon step 1

Then we’ll use the ::before pseudo-element to create a flash on top of the camera, in the shape of a trapezoid. The trapezoid shape is defined similarly to the way we create triangles, except we need to add a width.

.icon_camera::before {
  height: 0;
  width: .938em;
  margin: -.313em 0 0 .313em;
  border-bottom: .313em solid black;
  border-left: .188em solid transparent;
  border-right: .188em solid transparent;
}

Camera icon step 2

And finally we’ll add the lens to the front of the camera, using a circle with a border.

Explore CSS Courses

.icon_camera::after {
  width: .438em;
  height: .438em;
  margin: .125em 0 0 .5em;
  border: .25em solid white;
  border-radius: .438em;
}

Camera icon step 3

Taking it further

As you hopefully saw, creating CSS icons is really not that difficult and doesn’t require a ton of code. I’ve created a CodePen with all of these icons plus a few more. Feel free to play around with it!

Browser support

As mentioned above, all of these examples work in all modern browsers, including IE9. Some of the new CSS3 properties require vendor prefixes, so make sure you use the proper prefixes. In my CodePen, I’m using Compass @includes, which automatically adds in the proper vendor prefixes. If your project requires IE8 support, you unfortunately might want to rethink the use of solely CSS icons, or at least stay away from icons that require border-radius and transform. My suggestion for a fallback would be to use Modernizr to detect which browsers don’t support border-radius and transform, and provide a background image as a fallback.

Explore CSS Courses

About the Author:

EdisonJS – Organized Routing for Complex Single-Page Applications

February 11th, 2014

Over the past few years, “single-page applications” have steadily grown in popularity within the web development industry. As developers have grown accustomed to placing the bulk of the responsibility for rendering these “thick client” apps within the browser, new libraries that provide repeatable patterns for solving frequently encountered issues when using a client-heavy approach have flourished. Chief among these new libraries – JavaScript routers.

(more…)

About the Author:

ScreenCast: Speed up image spriting with Compass

February 4th, 2014

Creating image icon sprites is a common development practice to save some file weight and reduce HTTP requests. But there’s one pitfall to using sprites: maintenance. Adding more icons to sprites or editing them is a real pain and takes valuable time away from writing code, especially when you have to recalculate the positions of the icons within your sprite and update your CSS accordingly.
(more…)