QA and UAT are review processes that are done during a web development project to ensure design and functionality requirements are met prior to a production release.

When you spend weeks, or even months, on a project only to wind up with a handful of QA issues (that you should have caught the first time around), it is easy to feel discouraged. You can receive QA feedback for scenarios you did not even think about the first time around. The person performing QA isn’t intending to discourage the developers. QA and UAT are intended to find the obvious issues, and the most nit-picky annoying ones that no one thought to test.

The goal of QA and UAT is to break the site… the code.

Self-QA

A major part of the QA process during development is doing it yourself. Remember that you, as the developer, are responsible for being the first set of eyes reviewing your code. Unfortunately, you can code a feature for so long that you become blind to obvious issues.

Slow down. We do have deadlines to meet, but a quick break from your code can really help. Taking a lunch break, stepping away from the screen for a few minutes, or even working on another task for a bit can get you refreshed for self-QA. You’ll be able to see the little things you can clean up, fix, or completely change for clarity, because you’ve taken a quick break from your code.

Another method of self-QA is to take the feedback you received at the end of your last project and apply it to new code. Do you consistently receive the same feedback on issues when a formal QA is done? If so, keep track of that feedback and include it as part of your initial development.

Peer Review

When you need a second pair of eyes, use your peers. If you’re building a large feature, using a new skill set, or just want some additional feedback on a task before turning it in for final review, grab a peer to review your code. If you’re working with a team, lean on them to make your code better and expect them to do the same with you. We should all have the same goal, produce the best possible product by writing the best possible code. 

Here at WebDevStudios, we have a system in place for our peer reviews. A developer will work on a feature and pass it to a senior developer for the initial round of code review. If everything passes their checklist, they pass it onto the a lead developer for final review and scrutiny.

A senior or lead developer may not have all the skills to get your code up to par. This industry changes so rapidly that no single developer can truly know everything. If you see code that a senior or lead developer can improve upon, let them know; and hope that you work in an environment, like WebDevStudios, that encourages knowledge sharing.

Formal QA and UAT

Once self-QA and peer review has been completed on individual tasks within a project, it’s time to do a full project QA and UAT review. This process will most likely be unique to your company or team structure. The general process is that an individual, or team of developers, reviews the entire site to perform visual and functional QA.

Visual QA and functional UAT processes may be completely separate from one another. Comparing a page in the browser to the mock-up, and running through a specific set of functionality, like new user registration, are two entirely different things. It is critical to perform both QA visual review and functional UAT.

As a freelancer or company, you also need to define your own pass/fail scenarios on visual QA. Do you want to strive for absolute pixel perfection, or is it okay for the placement of something to be off by two pixels? Will it be important to the client to take the time to take screenshots, write up a task, have it assigned out, worked on, and finally reviewed?

What isn’t subjective, though, is whether or not a thing actually works. This is where a strong-handed UAT comes into play. Before you can have a solid UAT process, you need to have a solid process for documenting how something should work. This can be either with user stories defined by the client in the project plan itself, or documentation written as the project progresses. If user stories are in place from the beginning, that means each developer knows exactly what they need to do in order to complete their work. Providing user stories can be a major cornerstone along the QA and UAT process.

Client QA

Once an internal formal QA and UAT is completed, it’s time to hand off the completed project/site to the client so they can run through their review and testing process. Each client is unique and will have their own QA and UAT review processes to ensure their site is functioning as expected, per the proposal, prior to a production release.

Clients are typically able to find bugs when they run their QA. Clients have very specific ideas about how things should look, function, and how they should be able to interact with elements on the site. Certain features or functionality may not have been conveyed in static mock-ups. For example, the way images or links hover, or how unique sets of content resize for small screens. This is where user stories can help to eliminate some of that disconnect between static mock-ups, and a fully functioning website. When clients find bugs or issues based on expected functionality, we consider this a learning experience. We have the opportunity to improve our processes so that we can improve on assumptions for the next project.

Conclusion

There are so many methodologies around what we do and how to do it more efficiently – whether it’s making sure your code is as clean as possible, or that your functions do just one thing. These are hallmarks of being a solid developer. But, if you’re writing clean, smart code and testing it in different scenarios, you’ll wind up with fewer issues in the various stages of QA down the line.

QA is not a single process run at the end of a project. In reality, QA happens at several points along the way, starting with the developer working on the task and performing self-QA, peer reviews with senior and lead developers, onto the person running internal QA, and finally in the client’s hands. The earlier an issue is caught, the better it is for everyone along the path of review. It’s so important to be able to reflect on your previous projects and apply the knowledge you’ve learned at the earliest stage possible.

What are your methods for QA-ing your work on a site from start to finish? Do you have suggestions or tips on how others could possibly benefit from your own workflows? If so, share them in the comments and let us know!

The post The Importance of QA and UAT appeared first on WebDevStudios.

We got bored with having to make our coffee in the morning, so some brilliant mind created an automatic coffee maker with a timer so we could tell that machine when to make our coffee and how much of our coffee it should make.

We grew weary of the painful necessity of talking to actual human beings in order to have food arrive at our front doors, so the greatest pizza scientists in the world made it possible to order a lovely cheese pizza–just for me–by texting a single emoji. ?

We became so incensed at our watermelons constantly rolling away from us that the top watermelon doctors on the planet engineered square watermelons.

…Yes, the first milestones in human advancement that I can think of are all related to food and I will make no apologies for that.

When I’m not eating food or thinking about eating food, though, I’m probably working on a fabulous WordPress website using my editor of choice, Sublime Text 3 (ST).

ST is simple, yet robust, and offers countless packages to help speed along your development process. In addition to offering fully-developed packages for mass consumption, ST also offers the opportunity to craft custom snippets to take the legwork out of the things you type over and over again from day to day. In this post, we’ll show off a handful of examples we’ve picked up along the way as well as some that we’ve crafted for our specific uses at WDS.

What are snippets?

Snippets are a quick, shorthand way to type out a longer or more elaborate string or output. As you’ll see in our examples below, snippets can be extremely robust and can be customized to fit your needs.

How do I make a snippet?

ST3 makes it super easy to create a snippet. You simply select Tools > Developer > New Snippet from the toolbar menu and you’re off to the races!

ST3’s website offers some great information on snippets and how they are setup.

In order for a snippet to be used later on, it must be saved in the proper place. ST3 will typically place you in the proper directory when you save your new snippet, but if it does not you will need to look for User > Library > Application Support > Sublime Text 3 > Packages > User and save your snippets there with the .sublime-snippet file extension.

Comment Snippets

Comments are key. They let the person coming after you know what you were doing and why; they also let you know what you did and why when you come back to your code in six months. They are the trail of breadcrumbs leading you back to the genesis of your reasonable thought process. If there are no comments, how are we to know why you coded something a certain way?

WDS is a big proponent of docblocks and inline comments throughout our PHP, JS, and Sass files. We should make our files easy to understand and leave no question as to why we chose to do things This Way rather than That Way.

Recently we upped our Sass partial comment game by making it a standard to add a comment after the closing bracket to indicate what is being closed. This helps with any Sass partial where are a parent selector contains a lot of information within it; we no longer have to scroll up the page to see where the selector is opened. This became tedious for me, though. I kept having to manually click down to the closing bracket, type a double // and then my comment. Oftentimes, ST would adjust the indentation of my closing bracket forcing me to take another step before I was ready to click inside of my selector, tab in, and begin my actual work.

Exhausting!

So, I created this handy little snippet:

<snippet>
    <!-- Type `bracket` and hit tab to open a bracket with a closing comment. -->
    <!-- Type the class for the element you are styling and it is placed at the top and in the comment after the closing bracket -->
    <!-- Hit tab a second time to put your cursor into a beautifuly tabbed spot within the bracket -->
    <content><![CDATA[
${1:this} {
    $2
} // ${1:this}
]]></content>
    <!-- Optional: Set a tabTrigger to define how to trigger the snippet -->
    <tabTrigger>bracket</tabTrigger>
    <!-- Optional: Set a scope to limit where the snippet will trigger -->
    <scope>source.scss</scope>
</snippet>

Not only do we strive for clear comments in our theme files, but look at those comments in the snippet itself – you know exactly what it does without me having to explain it! Nonetheless, here is a snappy little gif so you can see it in action:

It was only then that I took a step back and began to look at the rest of the partial. What about a quickly utilized comment block at the top of the partial itself, or even one when we begin to style a parent element? Well, you’re in luck!

Here’s a snippet that will output a comment block at the top of a Sass partial:

<snippet>
    <!-- Type `partialcomment` or `pcomment` and hit tab to output a comment block. -->
    <!-- Type a short description of your partial and you're good to go! -->
    <content><![CDATA[
//--------------------------------------------------------------
// ${1:Partial Description}
//--------------------------------------------------------------
]]></content>
    <!-- Optional: Set a tabTrigger to define how to trigger the snippet -->
    <tabTrigger>partialcomment</tabTrigger>
    <tabTrigger>pcomment</tabTrigger>
    <!-- Optional: Set a scope to limit where the snippet will trigger -->
    <scope>source.scss</scope>
</snippet>

And a modified version of the above for a smaller comment block above a parent selector:

<snippet>
    <!-- Type `selectorcomment` or `scomment` and hit tab to output a comment block. -->
    <!-- Type a short description of the element you are styling and you're good to go! -->
    <content><![CDATA[
//-----------------------------------------
// ${1:Selector Comment}
//-----------------------------------------
]]></content>
    <!-- Optional: Set a tabTrigger to define how to trigger the snippet -->
    <tabTrigger>selectorcomment</tabTrigger>
    <tabTrigger>scomment</tabTrigger>
    <!-- Optional: Set a scope to limit where the snippet will trigger -->
    <scope>source.scss</scope>
</snippet>

So easy! One great thing you’ll notice in the snippets above is the <scope> setting. This is a great list of available scopes to be used with snippets. In our examples above source.scss guarantees that our snippet will only be available when editing a .scss file, so we don’t need to worry about any unexpected results while working in a PHP or JS file.

There is also a great package called DocBlockr which simplifies and expedites the process of writing docblocks above your functions. One of the settings I really love is the ability to set your name as the author of the function to eliminate any additional typing. Not only that, but it sniffs out any values being passed into your function and allows you to tab through and add additional details:

Sass Snippets

Comments are beautiful and important, but there is also so much more we can do with snippets inside of a Sass partial. We use Bourbon Neat at WDS in our wd_s starter theme, so it only makes sense to use some snippets specific to the wonderful things available thanks to Neat.

Let’s start with one of the cornerstones of Neat: ridiculously simple columns. While putting these columns into place is easy as pie, that’s no reason to give up on making it even easier to use. Check out our span-columns snippet below:

<snippet>
    <!-- Type `span-columns` and hit tab to output the span-columns() mixin. -->
    <!-- The cursor will be placed inside of the mixin's parenthesis for ease of entering a column size. -->
    <content><![CDATA[
@include span-columns(${1:8});
]]></content>
    <tabTrigger>span-columns</tabTrigger>
    <description>Set a column width using Neat</description>
    <scope>source.scss</scope>
</snippet>

Of course, there is a chance we’ll want to change the size of this column at a larger breakpoint. It’s a good thing we have a quick little snippet for that, too!

<snippet>
    <!-- Type `media` and hit tab to output the media() mixin. -->
    <!-- The cursor will be placed inside of the mixin's parenthesis for ease of entering a breakpoint. -->
    <content><![CDATA[
@include media(${1:\$tablet-landscape}) {

}
]]></content>
    <tabTrigger>media</tabTrigger>
    <description>WDS Media Query</description>
    <scope>source.scss</scope>
</snippet>

Sometimes we need something a bit more simpler, though. Adjusting margins and paddings on an element are no huge task, but there are going to be times when we just need a fresh reset on the margin and padding of an element to zero. Why manually type out the values for margin and reset when we can type a single word, hit a single key, and have a beautifully simple element free of margin and padding? The answer is “Don’t manually type it out,” ya big turkey!

<snippet>
    <!-- Type `margin reset` and hit tab to output the margin-padding-reset mixin. -->
    <content><![CDATA[
@include margin-padding-reset;
]]></content>
    <tabTrigger>margin reset</tabTrigger>
    <description>Reset the margin and padding</description>
    <scope>source.scss</scope>
</snippet>

PHP

We work in and love WordPress, so most of our snippets are WP-centric. However, that doesn’t mean that we don’t have some more generalized snippets for good ole PHP. These mostly help us debug issues or print data to the front-end for testing purposes. I make frequent use of an echoprintr snippet first shared with me by Justin Sternberg:

<snippet>
    <!-- Type `echoprintr` and hit tab to output the print_r function wrapped in xmp tags mixin. -->
    <!-- The cursor will be placed inside of the print_r function. -->
    <!-- Hitting tab will palce the cursor before the colon inside the opening xmp tag for the addition of helper text. -->
    <content><![CDATA[
echo '<xmp>${2}: '. print_r( ${1}, true ) .'</xmp>';$0
]]></content>
    <tabTrigger>echoprintr</tabTrigger>
    <scope>source.php</scope>
</snippet>

Need to view the contents of an array or an object? Give this sweet little var_dump snippet a whirl and let it brighten your day:

<snippet>
    <!-- Type `echovardump` and hit tab to output the print_r function wrapped in xmp tags mixin. -->
    <!-- The cursor will be placed inside of the var_dump function and inside of the preceding <strong> tags. -->
    <content><![CDATA[
echo '<strong>${1}:</strong><br>', var_dump( ${1} ), '<hr>';
]]></content>
    <tabTrigger>echovardump</tabTrigger>
    <scope>source.php</scope>
</snippet>

WordPress Snippets

Of course, as mentioned above, WordPress is really our bread and butter here at WDS, and we love bread and butter. WordPress offers a ton of helpful hooks, filters, and template tags to customize your custom WP build to your heart’s desire. We’ll show off just a few snippets used during theme setup and throughout the entire theming process.

We know our website is going to have images. Your website is going to be some sweet combo of images and text, and we need to make sure we have the proper image sizes being served at the proper times for whatever use cases we need. Have a massive hero section at the top of your page and need an image sized and cropped to specific dimensions? Have a river of posts below that massive hero with smaller, yet just as important, featured images? Adding those image sizes in WordPress is easy peasy with add_image_size, but with a nifty snippet we can make that even easier peasier:

<snippet>
    <!-- Type `add_image` and hit tab to output the add_image_size function. -->
    <!-- The cursor will be placed inside of the function where you can enter the name of your custom image size. -->
    <!-- Hitting tab once will allow you to set the width of the image. -->
    <!-- Hitting tab a second time will allow you to set the height of the image. -->
    <!-- Hitting tab a third time will select the entire crop setting. This can be a boolean (true/false) or an array with more custom settings. -->
    <!-- If using the crop array, hitting tab again will allow you to specify the x-crop position. -->
    <!-- If using the crop array, hitting tab a final time will allow you to specify the y-crop position. -->
    <content><![CDATA[
add_image_size( '${1:foo}', ${2:300}, ${3:350}, ${4:array( '${5:left}', '${6:top}' )} );
]]></content>
    <tabTrigger>add_image</tabTrigger>
    <description>Register a new image size with WordPress</description>
    <scope>source.php</scope>
</snippet>

The power of WordPress lives within its loops. The loop is the life-force by which all posts exist. We need the loop to display our content, but we don’t need the loop to be a potentially confusing and hard to remember series of strings and if/else statements. The following loop assumes you have already established the $args for your new instance of WP_Query. Once those arguments are set, simply type loop, hit tab, and voila!

<snippet>
    <!-- Type `loop` and hit tab to output a simple WP_Query loop. -->
    <content><![CDATA[
<?php \$foo_query = new WP_Query( \$args ); ?>

<?php if ( \$foo_query->have_posts() ) : ?>

    <?php while ( \$foo_query->have_posts() ) : \$foo_query->the_post(); ?>

    <?php endwhile; ?>

<?php endif; ?>
<?php wp_reset_postdata(); ?>
]]></content>
    <tabTrigger>loop</tabTrigger>
    <description>A custom WordPress Loop</description>
    <scope>source.php</scope>
</snippet>

Now you’ve got a loop where you can pull in content and display it to the outside world. But, what happens when the people viewing your website come from different parts of the world? You want every person to be able to have the same experience no matter what language their preferred language, right? It sounds like you might need to internationalize your text strings! This is a key component of anything we develop at WDS; we always want to make sure that any text string in a theme or plugin is going to be easily translatable to other languages. If you haven’t hopped aboard the i18n train just yet, read up on what it is and why it’s so important. We’ll wait here.

…

All done? Good! Now you’re ready to use this slick ST snippet for ease i18n strings:

<snippet>
    <!-- Type `i18n` and hit tab to output a ready-to-use escaped and translatable string. -->
    <!-- The cursor will initially be placed where your text string needs to be entered. -->
    <!-- Hitting tab a second time will allow you to type your textdomain. -->
    <content><![CDATA[
<?php esc_html_e( '${1:some text}', '${2:textdomain}' ); ?>
]]></content>

    <tabTrigger>i18n</tabTrigger>
    <description>i18n a text string</description>
    <scope>source.php</scope>
</snippet>

jQuery

Last in our list but certainly not least is jQuery. While you may not always require any fancy jQuery for your project, it’s always nice to have an easy way to quickly create a JavaScript file from which wonderful jQuery goodness can bloom. With the help of JS Mastermind Camden Segal, the following starter script was created and later spun into an easy to use snippet. It provides us with sample variables, functions, and lots of great inline comments to help guide us along our way. It’s incredibly easy to extend and even easier to read–no jQuery Soup over here!

Take a look at the snippet itself, then see it in action below:

<snippet>
        <!-- Type `jquery-wds` and hit tab to output a ready-to-use jQuery function. -->
        <content><![CDATA[
/**
 * Foo Script
 */
window.Foo_Object = {};
( function( window, \$, that ) {

    // Private variable
    var fooVariable = 'foo';

    // Constructor
    that.init = function() {
        that.cache();

        if ( that.meetsRequirements() ) {
            that.bindEvents();
        }
    };

    // Cache all the things
    that.cache = function() {
        that.\$c = {
            window: \$(window),
            fooSelector: \$( '.foo' ),
        };
    };

    // Combine all events
    that.bindEvents = function() {
        that.\$c.window.on( 'load', that.doFoo );
    };

    // Do we meet the requirements?
    that.meetsRequirements = function() {
        return that.\$c.fooSelector.length;
    };

    // Some function
    that.doFoo = function() {
        // do stuff
    };

    // Engage
    \$( that.init );

})( window, jQuery, window.Foo_Object );
]]></content>
    <tabTrigger>jquery-wds</tabTrigger>
    <description>Insert a Javascript function - the WDS way</description>
    <scope>source.js</scope>
</snippet>

Wrapping Up

At this point, you’ve seen a handful of snippets which can save you time and headaches by taking almost all of the legwork out of building sometimes complex functionality. At the end of the day, saving time is key; as the adage goes, “Time is money.” When we can cut time off of our development schedule by automating standard processes, not only are we saving time and money but we also begin to look at our work from a completely different viewpoint. We can take a step back, look at the big picture, and pick out the trouble spots or redundancies in our work and find a way to chop those down dramatically.

Take a moment to think about the code you write and how much of it is used from project to project. Then, create your own snippet to save yourself some time when you’re in the trenches day in and day out. Share any snippets you’ve created to boost your workflow or any helpful snippets you’ve come across in the comments below!

The post Snippets Saved My Life: How Sublime Text 3 Snippets Changed Everything appeared first on WebDevStudios.

User Experience

Color Preview

As the name suggests, this handy extension provides you with a preview of the colors you’re using in your files in the gutter of the file. I’ve found it can sometimes be a bit buggy if you’re using a Sass variable in partial, but the initial variable declarations work perfectly.

Brackets Icons

Brackets Icons gives a quick visual cue of the file types in your project. Choose between Devicons or Ionicons.

Show Whitespace VS

By default, Brackets doesn’t give you any indication of indents or whitespace. Some may see this as a shortfall, but I love it because it means I get to choose how my tabs and spaces look. Show Whitespace VS displays whitespace the same way Visual Studio does (which I’ve never used!), and I like it because it’s simple and doesn’t get in the way of my code (plus, I can see all the whitespace).

Honorable mention: Indent Guides

Display Shortcuts

After using Brackets for three years, I finally figured it was about time to learn some keyboard shortcuts. This extension is great because allows sorting and filtering, so you can focus on mastering keyboard shortcuts one extension at a time. And of course, it has a shortcut! Hit Control + Alt(Option) + /

Projects

This extension is particularly great if you’ve got the entire wp-content directory under version control because it gives you the ability to customize the name of your project. Hitting Opt + P on Mac brings up a project switcher to make it even easier to toggle between projects. ?

Front-End Development

Task Runners & Package Management

Brackets Bower

Terrified of the command line but want to use Bower to manage your front-end dependencies? No worries! Search the Bower directory, install your dependencies, and this extension will automatically add dependencies to your bower.json file, and you can easily manage where dependencies are installed by adding/editing the .bowerrc file.

Brackets Grunt

Need to run a Grunt task but don’t want to leave your text editor? No problem, simply double click the task you want to run, and boom, you’re gold. The status side of the panel lets you know whether your task completed successfully, or failed with errors.

Honorable Mention: NodeJS Integration which allows you to run Gulp tasks.

Time Savers

WordPress Hint

This extension is a must for any WordPress developer. This adds hinting and autocompletion for WordPress theme and plugin development, and also includes hints for Woo Commerce development.

Brackets Git

This is my absolute favorite, most-used Brackets extension. Even if you’re really comfortable using Git on the command line, this extension makes it really stupidly easy to follow the WDS motto: commit early and often. Changed files are added to the Git window, check the files to stage them, and click the commit button to commit. You can also fetch, pull, and push, and if you need it, there’s a shortcut to open the terminal.

Sass Hints

This extension adds autocompletion for Sass variables, and will save your sanity. No need to remember variable names, or search through files to figure them out. You can also see the value assigned to the variable to make sure you’re getting the right thing (which is also good for double-checking variables are only defined once!).

CSS Class Code Hint

This is really handy if you’re adding components to your site and want to utilize already-existing CSS classes.

Snippets (by edc)

I’m totally under-utilizing this extension, but it’s a necessity to help you save your sanity, and make your coding consistent. It’s especially useful for automating things like creating SCSS comment blocks, common WordPress function blocks, and CSS styles you find yourself reaching for constantly.

Align It!

Say goodbye to hitting your spacebar repeatedly, and hello to Align It! With a simple keyboard command, align all your associative arrays and variable declarations.

Sort Text

We love [alphabetical] order at WDS, and Sort Text makes alphabetizing SCSS properties a breeze. Simply select your properties, hit Cmd + on Mac, and hey presto! you have alphabetized styles.

FuncDocr

Typing /** or Ctrl + Shift + D on mac before an existing function will scan the function and scaffold a comment with placeholders for a description, parameters, and returned information. Simply tab through the options to document the function. FuncDocr works with both JavaScript and PHP.

Bonus

Kitten Cat Dog Gifs for Relaxation

Because sometimes you need a break from writing code to look at adorable, fluffy creatures.

This list only scratches the surface of super helpful extensions available for Brackets. If you’re interested in getting started with Brackets, check out Stacy’s ode to Brackets where she outlines a bunch of other useful features and extensions. I also keep a running list of extensions I’m using in a Gist, and am constantly looking for new extensions to improve my workflow.

The post Brackets for WordPress: 2016 Edition appeared first on WebDevStudios.

I’ve known for awhile that I wanted to make Sketch3 part of my toolkit, but also that I will have to deliver PSDs for the foreseeable future. Creating a Sketch file concurrently with a PSD makes me hunch my shoulders in despair – I hate duplicating work (who doesn’t?). And I don’t really have a lot of time to spend on training myself on yet another product (who does?). Yet here are a few ways I’ve found that Sketch makes my life easier while also saving me time when I’m working with Photoshop.

START WITH PLUGINS

When I first tried Sketch I was dubious about using another vector program when I already had Illustrator available. Thanks to the work of designers before me, I quickly learned that the power of Sketch lies in its extensibility, and through the magic of plugins I created my own Sketch3 app that works the way I need it to – and is much more than a vector drawing app.

The master list of Sketch3 plugins available on GitHub.

The thing I like best about Sketch is that it doesn’t get in my way when I want to…sketch. Part of why I have clung to Photoshop for so long instead of moving to Illustrator or using another vector program for my interface sketches is that I have a lot of muscle memory invested in that old clunky PS interface and when I want to jot an idea down quickly, I do it in a random PSD file. It’s a bad habit, but it’s still a habit, and I wanted Sketch to replace it.

Now when I have an idea, I can draw shapes that pre-fill with random images. I can create a style guide artboard for typography and color palettes. I can export my color palettes and typography styles as Sass variables that plug right into my theme stylesheets. I can import text data from an existing WordPress-based site using JSON (so handy for redesigns!). I can group symbols so that editing one button modifies all of them, and I can create buttons that dynamically resize based on the amount of text they contain.

This has the power of turning my quick sketches into living designs that I can use as the foundation for a web or app interface project.

CREATE IN SKETCH, ASSEMBLE IN PHOTOSHOP

Sketch can export layers to EPS or SVG format, and Photoshop can link to EPS files as Smart Objects, so when I’m sketching, I try to think in terms of creating objects in Sketch that I can link to as Smart Objects in Photoshop.

If I’m drawing shapes and icons, I export SVG versions for immediate use in a theme, and export EPS versions for immediate use in a PSD.

My Sketch files look pretty close to the final Photoshop version, and the only work I duplicate is copy/pasting text from Sketch into editable Photoshop layers, using my Sketch style guide to quickly set up text styles in PS. I create icons, buttons, and gradients in Sketch and export them for final layout and alignment in Photoshop.

CHANGE YOUR THINKING

Instead of opening up Sketch with the goal of creating a final deliverable design, I use Sketch as my style guide creator with an eye toward quickly developing layouts, color palettes, typography styles and symbols that can be used to create a beautiful Photoshop file quickly, with the amazing benefit of having color and typography data immediately available for use in my theme stylesheet. Sketch becomes the glue between my PSD deliverable and the final product, and I’m saving time instead of spending hours in Photoshop creating bitmap data that I have to recreate in a stylesheet later.

If you want to use Sketch (or are already using Sketch!) but are required to deliver designs in PSD format, I hope this glimpse into my workflow helps you tailor Sketch with plugins to be the design tool you’ve always wanted.

The post Integrating Sketch3 Into Your Photoshop Workflow appeared first on WebDevStudios.

Take the Time

CBT-ing is not fun and there are slew of reasons why. One of the biggest is that it takes time…a lot of time. Add a deadline that you have to meet and both your stress level and heart rate will shoot through the roof!

There are many different setups when it comes to cross browser testing. WDS currently uses a service provided by CrossBrowserTesting.com. Even despite its rich feature set, testing can still be time consuming and at times a frustrating process. In this post, I will show you some cool tricks I’ve learned that to help you save time and streamline your testing process when using CBT.com. At the bottom of this post I’ve included links to the relevant resources for each feature we cover.

NOTE: My local dev environment runs on OSX and VVV.

Setup Local Testing

CBT.com has a local connection feature that allows you to test websites running in your local dev environment. Testing locally is usually quicker (depending how powerful your machine is) and it’s a good option if you need to periodically check your work while you dev.

Getting setup for local testing can be a bit confusing, but it’s definitely worth it. Here are the steps I used:

• Login to the test center
• Click ‘Enable Local Connection’ at the top right of the page. Doing so will display a popup with instructions to follow:

After you’ve installed Java and downloaded the app to a location on your machine, I’d recommend you add a command alias to your terminal profile so you can activate local testing with a simple command.

Here’s what my alias looks like:

alias cbt="cd ~/; java -jar cbttunnel.jar -authkey ‘your auth key’”

With the above alias setup, all you need to do is run cbt from your terminal and local testing will start automatically.

Handy Bookmarklet

Thanks to Allison Tarr for filling me in on using this nifty shortcut! CBT.com provides a bookmarklet that you can use if you want to run a quick live test on the current page. Using this in conjunction with local testing makes for a powerful combination.

Installing the bookmarklet is easy. Just login to the test center and scroll to the bottom of the page and check out the ‘Quick-Test Bookmarklet’ section.

Here’s an example using the bookmarklet along with local testing:

Login Profiles

Ever run into the situation where you are working on a website that has a protected page and it needs to be tested in ten different browsers? Before discovering the Login Profiles feature, I would manually test each protected page which was very time consuming and caused unneeded frustration.Setting up a login profile is pretty straight forward and the instructions that CBT.com have provided up are very good (you can find the instructions here).

After you get a login profile setup, you can configure a ‘Screenshot’ test and select the profile you want to use. That’s it!

Login Profile Tips

• Take the advice from CBT.com and test a login profile first with just one browser selected.
• If you find that the screenshots are failing, setting a screenshot delay may help (thanks to Cameron for the heads up on this!).
  
• There are times when walking through the Login Profile wizard that it won’t automatically select the input fields for username, password, and the submit button.

A quick shortcut for getting input details is to copy the XPath directly from devtools and use that.

Selenium Tests

Selenium tests are handy when you want to get screenshots of a page after some sort of interaction has taken place–like when a hover state of a menu has been activated. Initially, I knew that CBT.com had support for Selenium testing, but it was foreign to me and seemed really complicated to setup.

I was wrong.

They created Selenium Builder, which is a Firefox extension that can be used to record scripts. Just follow the installation instructions on CBT.com to get it setup, but be sure to read the tip below first!

Setup Tip:

When I was setting this up, there was one part of the setup that was confusing. Just know that after you install the Firefox extension, you can access the Selenium Builder by going to Tools > Web Developer > Launch Selenium Builder. From here, you will be able to access the other settings you need to adjust for setup:

You might be asking what this extension actually does. Basically, it records the actions you perform on a webpage and allows you to save it to a JSON file. Those ‘instructions’ can then be used when you are setting up your screenshot test on CBT.com.

Tip: When you launch a recording session, you may or may not want to record mouseover actions.

If you’ve never used Selenium testing, I encourage you to give it a try! After you record a session or two, the process becomes much easier.

Links:

Getting local connections setup
Setting up a Login Profile
Setting up and recording a Selenium test

Conclusion

Cross browser testing is neither fun or easy, but the service and set of features that CrossBrowserTesting.com provides is solid and can make the process slightly less painful.

Do you have another testing workflow that works well for you? Have you used CrossBrowserTesting.com? Let me know about it! I’m interested to hear what other people are doing to make this process easier.

The post Time Saving Tips For Cross Browser Testing appeared first on WebDevStudios.

It seems that there can be allegiances to editors that can really rile people up. I’ve always been hesitant to make the jump mostly because of the productivity death effect switching can have. Obviously, the learning curve and installation seem to be the biggest obstacles. Why should I switch when I’m comfortable, and can ship code just as quick as the next person? So it was not until I had family vacation and knew I would have some downtime to try out Atom, and gave it a try.

Extending Atom with packages

Atom comes with dozens of pre-installed packages, as well as a few themes which can be switched on-and-off and tweaked to your heart’s desire. There is also a library of community contributed packages and themes. Here are a few packages I’ve found useful in my daily coding practices:

minimap

The minimap package shows a preview of source code along the side of the current file you’re working on.

Minimaps has a growing library of other packages in which it integrates nicely. Pigments is one of them. Here is a full list.

Pigments

For anyone that does a lot of CSS, Less, or Sass, this is a must-have. The Pigments package sources your code for any colors, then displays and builds a palette.

It also comes with a lot of handy features, like Pigments: Show Palette, which can show the current project’s palette from the command palette (Cmd+Shft+P / Ctrl+Shft+P). Also, there is a contextual menu that allows you to convert Hex to RGB(A), and vice versa.

File-Icons

The file-icons package adds file type icons to the Tree View, Fuzzy Finder and Tabs. Just a simple nuance to help visually distinguish one file type from another, and who does not like icons?

Highlight-line

This is a simple tool to just highlight the current line, which can be customized as well.

Markdown Preview Plus (MPP)

Markdown Preview Plus provides a realtime preview of any markdown file you’re working on.

Color Picker

Right click and select Color Picker, or hit CMD-SHIFT-C/CTRL-ALT-C to open it. Currently reads HEX, HEXa, RGB, RGBa, HSL, HSLa, HSV, HSVa, VEC3 and VEC4 colors – and is able to convert between the formats.

It also inspects Sass and LESS color variables. Just open the Color Picker with the cursor at a variable and it’ll look up the definition for you. From there, you can click the definition and go directly to where it’s defined.

Gist-it

Atom has a nice way to save and deal with Snippets natively, but I sometimes prefer to share and save Gists. Gist-it allows you to easily post files (or current selection) from Atom to GitHub Gists.

Conclusion

So far I’m digging Atom editor. I’ve been using the Atom Material UI theme with some simple customizations. I’ve barely scratched the surface of what lies underneath, and look forward to where the project’s Roadmap leads.

Check out the helpful documentation and get started if you like. Ultimately, I believe a tool is a tool, and it is how you use it that is most important.

The post Helpful Packages for Atom Editor appeared first on WebDevStudios.

The quest for knowledge is never-ending. We all want to be masters in our respective fields, but we also know that there is, especially in the tech universe, an ever-expanding number of things to bone up on. So, how do we get there? How do we learn every single thing we need to know? Let’s find out!

Step One: Start nowhere

We can’t begin at the ending. That’s just a given. It’s hard to start, though, especially in an area where you want to excel. We want to be the best and to be able to showcase our talents and wares to the world if only for the fact that we don’t know a single thing about our new endeavor. Sometimes it’s a bit disheartening to start fresh with something; maybe something that you thought would be an easy pick-up is much harder than you expected and it’s a bit of a blow to your ego.

Let yourself get beaten up by your knowledge (or lack thereof). It’s not a bad thing! In fact, it may be better this way. If you start a new adventure of discovery fully aware that you know literally nothing about the subject into which you’re diving it’s fine to let your ego be squashed a little. It’s harder when you think you already know about a topic, sit down to learn more or bone-up on your old skills only to realize you’re suddenly in way over your head. Now you’ve lost something that you once had, and that can be a bit disappointing.

The main thing to consider as you begin a new quest for knowledge is that you’re learning. You’re taking the active steps needed to learn a new thing, whatever it is. Of course you’re not going to know everything right away. Of course there are going to be curveballs and surprises and speed bumps. Of course you’re gonna throw your hands into the air, sit back, and ask, “WHY AM I DOING THIS TO MYSELF?!”. Never fear, though–there are still good times ahead.

Step Two: Start somewhere else

Okay, so that first step wasn’t actually a step but more of a lesson. This step is where the starting really starts. There are countless numbers of resources out there from which to learn and it’s really up to your own discretion and taste as to how you choose to learn. I know people who listen to podcasts throughout the day, like Chris Coyier and Dave Rupert’s Shop Talk. Personally, I can’t do this. at. all. I can’t focus on something like a podcast, or any other learning experience, while working. I need to be able to “get in the zone” and typically tune out everything around me. I have music on throughout the day, but that’s easy to tune out because it’s not something I need to really pay attention to — it’s basically just background noise to drown out the vast emptiness of the universe.

Outside of my working hours at this WordPress agency, though, I’m definitely up for podcasts. I’ve just started to get into them recently as I try to separate work-life from life-life and want to give my brain much-needed hours to relax and think about other things, but there are invaluable resources to be snatched up out there and we’d be foolish not to take them.

In the same vein, there are several e-learning resources out there where you can watch tutorials and put those smarts to use in a sandbox environment. Here at WDS, we were #blessed to get a handful of accounts setup over at Treehouse for extended learning purposes. The topics covered at Treehouse are expansive and ever-growing, not to mention their inclusion of conferences and in-house programming. Whether you’re a novice or an expert, you can always find something to tickle your fancy over at Treehouse.

If you’re not into listening to other people talk about the cool things happening in the world in which we’ve immersed ourselves, then there are still some other options for you. We would be remiss if we were not to mention Google. I was a freelancer before beginning at WDS, and before that I was just doing web design as a hobby rather than a career. For someone in that position, Google can be one of your best friends. Hopefully there are some human ones sprinkled here and there, too, but that’s just a nice-to-have. You can find anything with Google, of course. You can almost guarantee that if you’ve got a question on how something works, ten other people have already posed that question to a group of like-minded individuals somewhere on the web. Google doesn’t discriminate or judge based on your questions or how much experience you may or may not have – you just dump your insane questions into The Google Machine and out pump the answers. Which leads us to our next resource…

Stack Overflow. This is usually where I wind up after I visit my Google friend mentioned above. Stack Overflow is such an insane resource that I almost can’t believe it’s an actual thing. It just makes sense! First, you get to post your question and have random strangers hit you up with responses which would be awesome enough in and of itself. This is the basic message board structure, right? You post a thing, then a handful of people post responses. What’s extra nice about Stack Overflow, though, is that other uses can vote whether or not a response is useful or not useful. That means, when researching a problem, you can get a very quick glimpse of whether or not a solution worked for others. This is supremely useful. In a normal message board experience, you may just have to rely on the latest response or the one that “looks” the best. With Stack Overflow, you can get actual feedback on each individual response without having to try every single potential solution. To note, there’s also a very cool WordPress Development Stack Exchange which, as the name would suggest, is specific to WordPress development. HOW QUAINT.

The final resource I’d like to mention here is one that may not apply to your particular situation. No matter how you’re working on the web, one of the above four solutions could 100% work for you. If you have this resource at your fingertips, don’t discount it; your teammates/co-workers could be the greatest resource that you may not have yet discovered. When first beginning work at a new job, I think it’s natural to feel unsure of yourself and that, perhaps, asking too many questions is going to expose you as a fraud. Why are you asking so many questions?! Weren’t you hired because you KNEW this stuff?? Well, I can assure you that as long your questions progress, show growth, and indicate that you are not only learning as you go but attempting to step out of your comfort zone then nobody is going to think you’re a fraud.

As a Design Lead, I have several folks who come to me with questions on a daily basis and I love being able to field those questions, to help squash bugs, and to lend a fresh pair of eyes when needed. Even before we split into teams here at WDS, though, our fellow co-workers were easily the greatest resource around. Everybody comes from such unique backgrounds; I would wager that you won’t find any two people at WDS, or probably any company in the same industry, who have an identical or even strikingly similar history. Me? I was a pro-wrestling referee turned college student turned print designer turned web designer. Along that entire time, I was always doing web design as a hobby or a side-job and my experiences in doing so are going to allow me to see problems in a different light than someone else on my team. So, don’t be afraid to ask questions early and often.

Step Three: Put it into action

This step usually works hand-in-hand with step two. Very rarely do you know all of the questions up-front, ask them, remember all of the answers, then dive into your project without having to go back and review those answers. Working through a project and asking questions are symbiotic with one another from the start of a project to that project’s end.

That’s not to say that there still aren’t resources out there for you to utilize when you’re feeling a bit stuck, or when something just doesn’t seem to be working properly within your theme. Maybe you’re working on a new feature or some fancy-pants styles and they just aren’t gelling, for some reason, with your theme. It could be something you’ve done dozens of times before, but suddenly now it’s just not falling into place. Before you go absolutely insane, take a step back and try to isolate the issue.

Maybe the best thing for you to do is to try your code outside of your project, whether it’s a theme, plugin, or something else all together. If you’ve got some code that you think should be working but, for some reason, isn’t then head over to CodePen where you can freely test your functionality outside of the scope of your project. CodePen is an awesome resource because it lets you widen that laser-focus with which you’ve been working thus far. I know we can all get a bit of tunnel vision while working on a project or task. We get so ingrained in what we’re doing that it’s hard for us to truly take a step back, look at things objectively, and assess what is the root of the problem. By setting up a workspace on CodePen, you eliminate all of the extra baggage of your project and can very easily focus on the one piece causing you grief.

What if your problem is more design-related, though? CodePen can still be a good resource, but there’s an even better one for those of us tasked with making things oh-so-beautiful every day. SassMeister is a way to stretch your Sassy legs all the live long day. Here, you can dump some Sass into one panel, see the compiled CSS in another, add your HTML in a third panel, and finally see your results in the fourth. How cool is that? Now, if you have some nutty experimental Sass that you want to test out small-scale, or if you have some Sass that seems to be colliding, you can break those examples out and fine-tune them without interference from the rest of your style magic.

Step Four: Admit when you’re in over your head

We’ve all been here before. There’s no shame in not knowing. We all used to know nothing, right? We were just soft little jelly babies rolling around and drooling all over everything. We didn’t know how to make websites! Somehow, though, we learned. We were carved from chubby little balls of play-doh into larger balls of play-doh who had better brains in their think buckets. It was hard but we did it, and we probably didn’t even really think about it. Going from a baby to where we are now is a long journey, so it’s a little harder to locate the pain points. Those pain points stick much harder when you’re in the weeds and trying to trudge through.

When working in a project there will always be hurdles. Heck, when working through a task there will typically be hurdles. Most of them you can jump yourself, but sometimes you just smash your shins into the hurdle and feel yourself falling face-first toward the ground. Nobody wants to fall face-first toward the ground. It’s gonna hurt. How do you avoid that seemingly inevitable face-plant? Call out for help, and call out for that help early! You don’t want to call for help after you’ve already smashed your gorgeous face up on the ground; you want to ask for help before you even get close to that point. So, the second you start to feel yourself falling is the second you should start thinking about getting some help.

Whether this comes in the form of Google, Stack Overflow, or teammates (as mentioned in step 3), make a point to look for help. I typically find that bouncing ideas off of my teammates is the best way to troubleshoot because I’m getting help from someone with a similar workflow and the same investment in the project as myself. That being said, if you don’t work in a team environment there are still a multitude of resources to lend you a hand.

One thing to remember is to not be afraid to break things in your local development process. This is the place to break them! If you try something new and white-screen your site, then you know that you need to do some more research. That’s when you start down the path of broadening your horizons and learning things you never even knew you wanted to learn. This is stepping out of your comfort zone, and it’s an essential building block to growth. To paraphrase something I said in a conversation the other day, “If I didn’t know the things I learned by breaking things or doing something wrong, I wouldn’t know about 80% of what I know.”

Just as there is no shame in not knowing, there’s no shame in breaking things or doing things wrong if you’re breaking things in a safe environment and then taking the steps to figure out why you broke it, why it was unsafe, and how you can do it the right way from this point forward. Learn by doing and by doing things that are just enough out of your reach to test yourself.

Step Five: Find your allies

Admitting you don’t have all of the answers is a big step, but you also need to know who you can count on for help. We’ve been through those steps above, but it’s important to marinate on this one a bit more.

Ask for advice. Even if you know how to do a thing, ask around for new or possibly better ways to do that thing. We can tend to get stuck in our old ways and do things out of habit. Here at WDS, we’re very intent on killing the hamburger nav icon and carousels. Why? Because they stink! Studies have shown that the hamburger icon itself lowers user retention on a site because not only are there people who still don’t know what that means, but also because you’re locking additional content behind another door. A user has to click on that button to earn access to more content, and it’s easy to breeze right by it. And carousels, well they just stink. They’re the worst. They’re past their prime.

We don’t always get to make those calls, though. A lot of the time you’ll have clients who want those specific elements, or even more out-of-fashion elements, in their site and there’s no talking them out of it. The client has gotten used to the way the web looks and doesn’t want to deviate from what they’re comfortable with. We can be the exact same way as designers, but the way we grow out of that is to educate ourselves on the newest, latest, and greatest advancements in the web and in design. In turn, it’s our job to educate our clients to those same advancements so we can work side by side with them.

An essential point to learning is to keep an open mind. You can’t be afraid to try something new even if it seems crazy or weird to you at first glance. There have been several times while working at WDS that we talked back and forth about workflow and what would be best for our team. Most of the time we don’t have everybody 100% on board with the same idea. There have been times that I, as a Design Lead, haven’t been fully on board with the idea of a new piece of workflow until I actually started using it. The idea sounded crazy, but the actual implementation turned out to be perfect and has become an integral part of my day.

It may seem important to work with people who think just like you, but it’s equally as important to work with people who don’t think just like you. These are the people are going to be ones to help build you up while you build them up as well. The cross-pollination of ideas and workflows is going to be what drives you, and your team, forward in the future–if you’re willing to step a bit out of your comfort zone.

The post How to Know Everything appeared first on WebDevStudios.

First, let’s review how Git Flow works.

Main Git Flow Branches

It all starts with two main branches: master (which is the stable version of the software) and develop (which is where all the development happens). The main idea here is that develop is constantly changing as new things are added, and when features are completed, they are merged into master.

In this scenario, develop is always going to reflect what’s going into the next production release.

Supporting Branches

There are also three different sets of supporting branches.

• feature branches are for new features being developed for future versions of the software. When creating feature branches, a hierarchy is added by prefixing the branch with feature/, for example feature/my-cool-feature. features branch from the develop branch.
• release branches are used to organize features and fixes going into the next major software release. Like feature branches, they have a hierarchy added, like release/1.0. Like features, releases usually branch off develop.
• hotfix branches work a little different. Hotfixes are for when there’s an issue in the production software out in the wild and you need to fix it now and make sure it doesn’t get reintroduced. These branch from master (where the bug is) and merge into both master and develop, to make sure that the bug doesn’t come back when the next version is released.

A theoretical workflow might look like this (note: all images in this section are taken from Vincent’s post):

The current production version of our software is 1.0. We would like to start development on the next major release, 1.1. At this stage, master and develop are at the same state; we’ll assume we just barely shipped the 1.0 version. So we start by creating a release branch for our next version:  release/1.1.

When I start on a new feature for the 1.1 version, I create a new feature branch off of develop, build my feature out, and then merge it into develop. When develop is in a state where it’s getting ready for release, develop merges into release. The idea behind the release branch is it serves as a place for final changes, bugfixes and other minor changes that need to be taken care of before the next version is shipped. Those bugfixes and changes would then get merged into develop because, at this point, we’ve switched to committing directly to the release branch.

Now, let’s say, as we’re working on 1.1, something comes up–something’s broken and we need to fix it ASAP. I’ll create a hotfix branch off master, hotfix/some-bug, finish that, and then merge the result into develop and master.  What gets merged into master becomes the 1.0.1 release, and we create a tag for that version because we need to ship it before the 1.1 release is done. Merging it into develop means that we can be sure that the bug isn’t reintroduced once the new features being worked on in the 1.1 release get merged into master.

All of these branches can (and probably will) exist concurrently as different people are working on different elements. If I want Camden to look at something on my feature branch, I can ask him to check out which branch I’m working on and he’ll pull that down to his local, test it, and maybe commit some changes of his own to that branch which I can pull down when they’re ready. We can both be working on the same branch simultaneously, too, although before we’re able to push anything, we’d need to make sure our working copy has any changes that were pushed to the repository.

Putting all that together, you have something that looks like this:

WDS GitFlow

On client projects, the release branch loses importance. So do tags (although maintaining an archive of “versions” is helpful for backups). Our process has evolved out of this Git Flow model, and it starts off similarly, but has some distinct differences.

Pre-launch

Before the site is launched, there’s really only one main branch and two supporting branches. Our main branch is master, because when you set up a Git repo, that’s the initial branch you have. But our master branch is our development branch. Our production branch is prod, not master. The supporting branches we use are feature, which branches from master and is used primarily for functionality additions (largely stuff handled by the back-end developers) and theme, which also branches off master, and is used for things that go into the theme for the site. At this point, our Git process looks like this:

We also have deployments set up, so that commits to master are auto-deployed to a live lab server we run and test on in addition to our local environments. When the site gets ready to launch, we create a the prod branch off the finished and stable master branch and that gets deployed to the production environment. This makes deployments to production more intentional; in order to push to the production site, you need to check out the prod branch and deliberately push your changes. This makes it so there should be no surprise when code is on prod.

Once on the production environment, we go into final QA mode. We will have QA’d things on our lab server, of course, but inevitably there will be slight differences in environments from our lab server and the production server or things won’t work quite the way they were expected when the client is testing. At this point we use the hotfix branches to address any issues that are in existence in production.

When all remaining issues are taken care of, the site is either handed off to the client or we get ready to start work on a Phase II of the project. And this is where our new Git Flow model really kicks in.

Release as a Staging Environment

The guiding theory behind the revised Git Flow model is to use the release branches as a staging environment, ideally with a staging server that mirrors the production environment. As an added component, we’ve most recently started experimenting with release sprints. These essentially act like releases in the existing Git Flow model, where you are pushing toward a specific version, but instead of development coming off of develop (or, for us, master), our feature and theme branches split off the release. master (our development branch) is downgraded to, primarily, a testbed that has the added bonus of deploying to a lab server. Branches are kept clean from each other by coming off the release branch for the sprint we are working on and only getting merged back into that release when the feature is done done and has been tested to be working on master.

When that particular release sprint is done, it is merged into prod and we start working on the next sprint. It’s important to note that, at any given time, we could have devs working on different release sprints and that these sprints could be happening independent of each other. Unless we’re making changes that affect specific components from other sprints or feature branches, code changes are isolated and don’t end up in merge conflicts and features are more or less grouped to go into a specific sprint to prevent the same file being changed by different people at the same time on different releases.

If a bug is identified after we’ve started working on a release, the hotfix will be merged into any release branches there might be as well as going into master and prod.

Using this model, if I was building a feature, I would start by creating a new feature branch off the release branch–something like feature/my-new-feature. I would push my code to my feature branch. When I was done, I would merge feature/my-new-feature into master which gets deployed to the development server and is available for testing. If that feature tests good, my feature branch is merged directly into the release branch; it already exists in the master branch. It’s important to note that the code doesn’t get merged into the release until after it’s been tested on the development server.

When a sprint release branch is merged into prod, we’ll tag it (we’re still working out a naming convention, since version numbers aren’t as significant as dates) to create an archive that’s easy to roll back to if there’s ever a problem later.

Advantages of using this model

Having a dedicated staging environment is a good thing. Once a site is live, you don’t want to push code to it and potentially break it. But your development environment might not match the production environment. This is especially true if, as is often the case for us, you are maintaining your own development server, but the production server is running on a different host with a different environment. Maybe the production environment is a Windows Azure server, but your development server is running Linux. That makes having a staging environment to make sure that all your code works in Azure pretty important.

This workflow builds the staging server into the process so you have a place to push code that’s ready to go while giving you a failsafe in case there were issues that weren’t accounted for in testing or if there are environmental differences between the production server and the development server.

For freelancers and agencies, the traditional Git Flow workflow often doesn’t make as much sense because you aren’t producing a single “product”. You’re often producing multiple products–a combination of custom plugins, themes, and possibly even specific, curated plugins that your specific custom functionality extends. But that doesn’t mean that Git Flow shouldn’t be used in those cases. Instead, adapting the workflow to what works best in your situation can be incredibly valuable and prevent issues down the road.

What do you think? Are you using Git Flow? What is your typical workflow for client project development? Let us know in the comments!

The post An Alternate Git Flow for Client Work appeared first on WebDevStudios.

I have been having a great time testing Brackets.io, the open source text editor by Adobe. Ever since switching from Espresso to Sublime Text, I have missed many of the preview features in Espresso…and then along comes Brackets.

Extract for Brackets (preview)

By far, this is my favorite feature and the one that makes it stand out from existing code editors. If you have a Creative Cloud account, your Creative Cloud Files folder is available in Brackets–which enables you to quickly extract the text properties, colors, dimensions, gradients, and more, and turn that into code within your CSS file. You can also extract image assets from the PSD file right within Brackets keeping you in one application for a more efficient workflow.

Live Preview

Live Preview enables you to make changes to a file and see them in the browser, similar to Live Reload. I am using a Grunt watch task here in order for the Sass to be compiled, which is why there is a lag. If I was coding straight HTML/CSS it would show up instantly.

Helpful Extensions

There are so many amazing extensions already available to make Brackets even better.

Below, I’ve included a list of the ones I have installed:

Extract for Brackets (Preview)

Like I described above, the Extract for Brackets extension provides the functionality of Extract right inside Brackets. Extract design information and assets from a design comp via contextual code hints for CSS.

Brackets Git

These days, I work within the terminal, but boy, does Brackets make it really easy to just check a few boxes and hit “Commit.” There are a surprising amount of Git commands you can run as well, such as creating and switching branches, setting up your own keyboard shortcuts and more. Definitely worth using for some quick commit and continue work.

Grunt for Brackets

Run a Grunt command with the click of a button. Grunt for Brackets makes it simple to select which command you’d like to run, as well as ending a watch command.

Monokai Dark Soda

Monokai Dark Soda color scheme is one of the most loved themes out there.

Brackets CSS Color Preview

Preview the colors within CSS file.

Brackets Dash

Adds Dash integration with Brackets. Requires Dash and OSX.

Brackets Font

This extension displays SVG, TrueType, OpenType and WOFF fonts.

Better quotes for Brackets

Make quotes work more like they do in Sublime. If text is selected and ‘ is pressed the selection will be wrapped in quotes.

Brackets Snippets (by edc)

Imitate Sublime Text’s behavior of snippets.

Brackets WordPress Hint

This extension will provide hints/auto-completing for writing WordPress Themes and Plugins.

colorHints

Show colors you used in your CSS file before as code hints.

Extension Highlighter

File extension colors in Brackets’ file tree.

Gist Manager

Create and view Github Gists within Brackets. (View > Show Gists Manager)

SASSHints

Autocompletion for SASS/SCSS variables.

Simple To-Do

Simple to-do list for Brackets. Tasks can be stored in text files or Trello.

SVG Preview

Live preview SVG files in an inline panel while you edit them. Click in SVG to jump to corresponding code.

ToggleCase

Toggle the case of the current word.

Time to Switch?

Maybe. I do have some items on the wish list including:

• Faster search (when searching more than 1 file)
• Split view option for Extract
• Extract to check to see if which variables exist, and use those first (some sort of variable settings/mapping)
• Color highlighting of variables used throughout the sass partials, and not just in the file declared.

It looks like they’ve been working on some great upcoming features. Using Extract and the built-in Grunt and Git has certainly saved me time from switching back and forth between applications. If you haven’t tried Brackets (since the 1.2 release), I definitely recommend spending a few weeks with it. You won’t be sorry.

The post Brackets.io, How I Love Thee appeared first on WebDevStudios.