screw it. !important

dev-practices:

(via @alex_morrison)

Sass Variable Architecture

Sass Variable Architecture

Sass Variable Architecture

Using Sass is helpful when authoring and maintaining CSS. One of its many advantages is being able to define variables that can be reused again and again. Creating a scalable and easy to use variable structure has been something I’ve been working on and researching for quite some time now. Below are a few of my findings.

1. Use Auto-Complete Friendly Terms

Many IDE including Sublime Text offer an autocomplete when you start typing a word or function. Autocomplete allows you to work more efficiently, by not having to remember each of your variable variations. When you’re working in the CSS, you probably know from working within the PSD that the item you’re trying to style is supposed to be blue. In the first example, this works great with autocomplete. You start typing “$blu” and you’ll get all the results from the first list. This isn’t the case for the second least and can become confusing if you use the same name convention for the other colors in your scheme ($lightYellow, $lightRed).

Do – Start with the Color

$blue: ###;
$blueLight: ###;
$blueDark: ###;

Don’t – Start with the Variant

$blue: ###;
$lightBlue: ###;
$darkBlue: ###;

2. Utilize User Friendly Terms

As the author of the CSS, you might have been provided a style guide with brand colors for the project. It’s important to name these colors as they relate to the interface rather than an arbitrary hierarchy. I’ve found that there are typically 3 main colors in designs. A primary color for primary actions like an “add to cart” or some other main call to action, a secondary color for secondary action, and an alt color for unique cases where the other two don’t apply. Then there tends to be variants on those three colors. By creating this relationship and standardizing a naming convention, you create a direct relationship with the interface and your variables. This will also help future developers to be able to easily understand and relate which color goes with which variable.

Do – Abstract Color Names

$primary: $blue;
$primaryLight: $blueLight;
$primaryDark: $blueDark;
$secondary: $yellowDark;
$secondaryLight: $yellowDark;
$secondaryDark: $yellowDark;

Don’t – Abstract Ambiguous Color Names

$brand-1: $blue;
$brand-2: $yellow;
$brand-3: $blueLight;
$brand-4: $blueDark;
$brand-5: $yellowLight;

3. Use a Calc Function and a Font Size Mixin

The REM unit is still not well supported and there may be other situations where you want to change the root body element font size. If you’re using EM based CSS, changing that value can have a big impact on your layout and design. By setting a $base-font-size variable and using it as the basis for all your root EM base calculations, you can make sure your CSS remains fluid. The $base-font-size variable also comes in handy to reset the font-size on inline-block elements whose parents’ font-size is set to 0 in order to overcome the inline-block white-space shortcoming.

Do – Use Calc and Font Size Mixins

.selector {
    margin-bottom: calc-target(10,14);
    line-height: calc-target(20,14);
    @include font-size(14);
}
$base-font-size: 16 !default;

// ==========================================================================
// calc target
// ==========================================================================

@function calc-target($target, $context: $base-font-size, $unit: 1em) {
    @return $target / $context * $unit;
}

// ==========================================================================
// @mixin font-size
// ==========================================================================

@mixin font-size($targetSize, $base: $base-font-size) {
    font-size: $targetSize / $base * 1em;
}

4. Create a Default Architecture with Overrides

From project to project, some things change, but many stay the same. Whether it’s the path to your image directory, the color of error text, or the different samples of grey you use, keep these things constant for every project and refine them over time with your base CSS architecture. Keep these defaults in one file, and in a separate file, create project specific overrides. Now in your compilable Sass file, call the default variable file first, and the project overrides afterward. Much like using plugins in JS, this keeps your project separate from the core architecture and is easier to update/upgrade to newer versions.

Do – Use !default Values

//system
$imagePath: '/resources/images' !default;
$fontPath: '/resources/fonts' !default;

//greys
$greyWhite:         #fff !default;
$greyLightest:      #fafafa !default;
$greyLighter:       #f2f2f2 !default;
$greyLight:         #ddd !default;
$grey:              #ccc !default;
$greyDark:          #666 !default;
$greyDarker:        #444 !default;
$greyBlack:         #222 !default;

// system colors
$ui-yellow:         #c09853 !default;
$ui-yellowLight:    #fcf8e3 !default;
$ui-red:            #b94a48 !default;
$ui-redLight:       #f2dede !default;
$ui-green:          #468847 !default;
$ui-greenLight:     #dff0d8 !default;
$ui-blue:           #0484cb !default;
$ui-blueLight:      #d9edf7 !default;

The post Sass Variable Architecture appeared first on Pete Schuster.


from Sass Variable Architecture

virginiagentlenerd:

Still goddamn hilarious

(Source: nedstarksillegitimateson)

architectureofdoom:

A climbing plant peels off a brick building, in an effect reminiscent of a snake shedding a layer of skin

architectureofdoom:

A climbing plant peels off a brick building, in an effect reminiscent of a snake shedding a layer of skin

(Source: malformalady)

when the client wants major changes near the deadline

thecodinglove:

image

/* by olorapino */

Email Q&A: Becoming a Front End Developer

Email Q&A: Becoming a Front End Developer

This past week I received an email from a designer looking for some advice on breaking into front end development professionally:

Hi Pete, hope you’re doing well. I was hoping you could help me out with some questions I’ve been having lately. Recently I’ve been toying with the idea of a career change into full time front end development. I’ve been working in the graphic design field for the last 8 years. The last 2, I’ve really been drawn to front end development. One thing I love about it, is constantly learning new things and taking advantage of modern workflows. i.e. sass, gruntjs, git / bitbucket, and the general open source community.

The design world can be “unforgiving”.. we’ll say. You could spend 20 hours designing something you think is perfect and the client can shut it down in all of 5 minutes, then it’s back to another round of 20 hours of work. It’s also very subjective. What looks good to one person will look bad to another. Unless you work for yourself, you most likely won’t be designing things you want to in an agency/firm setting. So far my experience with programming has been very black and white, which i consider a good thing. Theres only one way to write.

I’ve only done front end development in a freelance setting, never at a firm or agency. They’ve all been generally pretty simple sites. I’ve never had to use angular or a js framework with my sites. Probably a good thing because I don’t know them yet!

So, finally my questions.
1. Can the programming world be unforgiving? For example do you find yourself re-programming the same thing 10-20 times a day and working late because of it? Are you asked to program an entire site in 1 day?

2. From what I can tell, the pay is generally higher for web programmers vs designers. Do you have any thoughts on that?

3. If there was one spot I’m still lacking in, it’s javascript and js frameworks like angular or backbone. Honestly, I’m still learning vanilla javascript. Do you use these? Are they important to the daily life of a front end dev?

4. Are you always rushed, constantly stressed out?

5. If you could pick the hardest or most stressful thing about working full time as a programmer, what would it be?

6. Everyone has their own opinions of front end vs back end. Are you required to manage servers, change dns settings, purchase the domain names, transfer databases, move wordpress sites to a new host, that kind of thing?

7. What are your thoughts on the current job market for front end devs?

Well if you’re reading this far, thank you so much. I know I wrote a lot, but I would really appreciate and value your thoughts and opinions on these questions. And if theres anything else you’d like to mention about your experience thus far, please do.

thanks!

Here is my response to his questions:

1. Can the programming world be unforgiving? For example do you find yourself re-programming the same thing 10-20 times a day and working late because of it? Are you asked to program an entire site in 1 day?

The programming world is very forgiving. There are a lot of ways to accomplish the same thing in the programming world, and the resources online are plentiful to help you out if you need it. When it comes down to it, the best way to program something is to make it maintainable, easy for another person to understand, and that it runs quickly in the browser.

2. From what I can tell, the pay is generally higher for web programmers vs designers. Do you have any thoughts on that?

I would say pay is higher for programmers. The design world is kind of in flux right now. Designers are starting to learn HTML/CSS and design in the browser now rather than use static PSDs. Because of this, the line between front end and design is growing thin. Some people are still holding onto the past, mainly because their background is in print design, but that will soon be a thing of the past. I think with your design skills AND your programming skills, you are a really great candidate for a high paying position.

3. If there was one spot I’m still lacking in, it’s javascript and js frameworks like angular or backbone. Honestly, I’m still learning vanilla javascript. Do you use these? Are they important to the daily life of a front end dev?

JS is definitely part of my daily workload, but its rarely anything more than simple DOM manipulation with jQuery. Tech like backbone and angular have their place, but unless you’re building a custom app from the ground up, they are rarely used in practice. Vanilla JS is a great thing to learn, but jQuery has also become the industry standard. I wouldn’t worry so much about JS unless you find its something you really want to do. It can be a rabbit hole of the latest and greatest frameworks from week to week. If you don’t want to pursue more JS, I’d suggest leaning more toward User Experience.

4. Are you always rushed, constantly stressed out?

At my current job, no. In the past, I worked at smaller agencies that created brochure sites with picky clients with little experience on the web. Now, at my current job, WebLinc, I work in a small team at a larger company. In that small team, we work on a set of client sites, working with their e-commerce directors and marketing teams to tweak and promote their site to users. It’s like a different world when you’re working to refine a product vs rushing to spit out a site to meet a deadline.

5. If you could pick the hardest or most stressful thing about working full time as a programmer, what would it be?

I don’t really have many stresses at work. If I had to pick something, I would probably say pushing code live and worrying that it might break while I’m asleep or something and the client could be losing money. With all the QA and code review we do, plus all the monitoring we have in place, it doesn’t affect me that much.

6. Everyone has their own opinions of front end vs back end. Are you required to manage servers, change dns settings, purchase the domain names, transfer databases, move wordpress sites to a new host, that kind of thing?

No, we have a whole department that takes care of that stuff. I work only within the front end HTML/CSS code. Although I like to understand what the other branches of the company are doing, I would never do it on my own.

7. What are your thoughts on the current job market for front end devs?

The current job market for front end is amazing. Every meetup I go to, people are always making announcements that they are hiring for front end. Personally, I’m constantly being bombarded with recruiters trying to entice me away from my job. And here at WebLinc, we are always hiring front end developers as well.

The post Email Q&A: Becoming a Front End Developer appeared first on Pete Schuster.


from Email Q&A: Becoming a Front End Developer

When your caffeine level and playlist align perfectly to get work done

dev-practices:

(via @alex_morrison)

when I come back from holidays and read the intern’s released code

thecodinglove:

image

/* by trafz */

2013 In Review

2013 In Review

Years come and go and so do the yearly turn outs of end-of-the-calendar retrospectives. Here’s my look back on 2013.

New Job

In Janurary of last year, I began a new job as a Front End Developer at WebLinc in Old City, Philadelphia. What a difference a new job and a new perspective on the modern workplace can be. The past year at WebLinc has turned out to be such a tremendous experience, I couldn’t be more thrilled with the direction of the company, the level of talent I’m surrounded with daily, and overall community the management team has built. We’re continuously growing and hiring new people, as well as upholding the tight-knit culture and camaraderie of a smaller boutique company.

weblinc

Within my first year, I moved from a support team member to a team leader, in charge of the front end development of several large accounts. I’ve also gained management experience, as I deal out work to the other members of my team and my own support team member. I’ve even taken steps to move into more of a User Experience (UX) role. 2013 was a good year for my career and my future and moving to WebLinc is a huge part of that.

New Car

car

My wife, Shannon, and I got a new car! We traded in both of our older cars for a new Hyundai Accent. We love our Hyundai and are super happy to have a car that works, drives great, and smells good!

New Bathroom

bathroom

After many hard weeks, Shannon and I finally (semi)-completed our bathroom remodel. It was the first major remodel we’ve undertaken in the 3 years we’ve been at the house, and we learned A LOT. We’re excited to finally be rid of the ugly 80′s blue ceramic everything and proud of our awesome white throne room.

Shannon’s New Business

2013 marked a huge step forward in Shannon’s career as well. She left her previous job and started working for herself full-time as a wedding photographer. I’m very proud of all of the work she puts into the business on a daily basis. She even received an award from WeddingWire for being a favorite vendor.

Baby Paul

baby-paul

In July, I became an uncle for the first time. My sister gave birth to my nephew Paul on July 1st. Since then, he has commanded the attention of every family member as we watch him grow into a little person.

Childhood Home Sold

My parents moved out of my childhood home that I lived in for 23 years and into a new home not too far away. It’s a pretty big change and kind of bittersweet, but the pool table in the new house’s basement makes up for it.

Brotherly Weddings

In the spring and the fall, my oldest and older brother respectively got hitched. They both somehow landed some pretty awesome gals and now the entire Schuster clan is all married and grown up.


from 2013 In Review

PM’s mentality when telling them there’s a 2% chance of success

devopsreactions:

by Sion