[BLANK_AUDIO]

My name is Ian Carrico.

I'm a backend and frontend developer at Four Kitchens

meaning I write backend code for my frontend developers.

Lots of drupal work.

My drupal user name, if you use drupal.

On Twitter I am iamcarrico, on the GitHubs and the rest of the internet,

I am ChinggizKhan, because I like making sure that people can't spell my usernames.

[LAUGH] so,

first of all who here is Ruby developers?

Two. [LAUGH]

>> No love for Ruby? >> What?

>> No love for Ruby?

>> Who here realizes that Sass is Ruby? [LAUGH] Okay, we're good.

Love Ruby.

Love it.

so, one of the biggest pains of working with Sass is

the fact that it's Ruby, and Ruby is weird,

especially if you're used to other program languages or worse.

If you're a frontend developer and

don't really understand programming languages like this.

So Ruby has many, many versions in it. So, all of

Macs right now have 1.87 p something, something, something.

And each one of those have small changes in them.

Each Rubygem that comes out are updated by their own maintainers,

and each one of those have their own versions number in there.

And for example, if you use Breakpoint Breakpoint version one

and Breakpoint version two are not compatible with each other.

So if you're working with Breakpoint version one and you update,

all of sudden all of your code is going to start breaking.

Like respond to, does something weird and a whole bunch of other

things and it's, it's weird, it's hard, and all of a sudden

your entire site's breaking and you're freaking out and you're supposed to

deploy something that day and your boss is screaming over your shoulder.

This has happened to me.

[LAUGH] It's weird.

The other reason why this is hard is for most people.

Do most people here use Macs, generally?

Linux is awesome.

On your Mac, generally people use the system Ruby.

Which means that it is, you have to use pseudo to update anything.

So which means you have to go in and pseudo-update every single

version of your gem, and that gets frustrating and annoying and hard.

And there's, you know, different Rubygems for projects.

You need to know which one goes where.

It gets very frustrating very quickly.

so, luckily there are ways of making this easier, a lot easier.

The problem is it's really painful to even set up the system to make it easier.

Once it's set up, everything works really great.

It's just the setting it up is hard.

So we're having a painful morning to make all of

the Sass developments open in the future so pretty much,

much, much easier.

So first of all the easiest thing you can do is type in to your command line if

you're using a Mac, this command echo 'gem: NO-RDOC.

>> Does it have to be all caps like that?

>> [LAUGH]

>> Actually no. The gemrc should be lower-case.

This

what happens when I use slides, on the internet.

So what this does is, every time you install new

gems, it will not install a documentation along with it.

Which means that your gem installation time

will go from five minutes to 30 seconds.

[LAUGH] I'm still not entirely certain why we have to

have all the documentation there, but it's lots of no fun.

This is the quickest and dirtiest thing you can do.

[BLANK_AUDIO]

We got it? Kay.

>> Is my command line supposed to tell me anything?

>> No. >> Okay.

>> [LAUGH] So all this is doing, it's creating

your within your home directory, a file called gemrc.

Which has your gem settings in there.

And then this line right here tells your gem,

your gems, to not download the rdoc or the ridocs.

Which is your documentation when it downloads a gem.

So,

the easiest little thing solves everyone's problems so quickly.

Second thing, okay.

So this is the portion of the presentation which

you may or may not want to actually do.

As I said Ruby has many versions.

One of the ways of solving for that is by installing a Ruby version manager.

There are three

of these that I know of. There's RVM, RBENV and

chruby. I have, most my Ruby friends use RBENV.

RV, RVM is more common in tutorials, but it

installs a bunch of crap that you don't want.

And it's far more of a system than you will ever need.

The problem with

RBENV is it's really hard to install, unlike RBN.

But once it's installed, it's far easier.

So who here who's using a Mac has Homebrew installed already?

Fantastic for you all, this is the easiest thing in the world.

For those who do not have Homebrew installed,

it's documented online. >> [LAUGH]

>> There's actually a lot of great tutorials

I'm not gonna go over today and you guys

can kind of take a nap and go on Facebook for five minutes while I explain this.

It's not needed to use RBENV. It's definitely useful if you

are going to be using different versions of Ruby it's needed.

If you are just doing

Sass developments, and you're a frontend developer, I would say don't do this.

Ignore these next five minutes.

Yes?

>> Is this, like, a, a way to sort of localize all your Ruby stuff?

Does this keep projects separate, all your versions and all that?

>> So this is a way it will

install different versions of Ruby into your home directory.

So that means, one, you can install gems without needing Pseudo.

and, two, it means that if you have one project

with Ruby 1.8.7, and the other project was Ruby 2.0.

You can keep those separate and it will

maintain which versions of Ruby you're actually using.

So, why should you not use system Ruby

if you're not using a different version of Ruby?

This is a fun one.

The next version of OS X is not going to

be using the same version of Ruby you're using now.

[SOUND] Yeah, lots of fun. Lots of fun.

It's going to upgrade to Ruby 2.0 as opposed to 1.8.7.

1.8.7 was the current, was a very, very stable branch.

Now, 2.0 is, so they're using that.

For most Sass development, this shouldn't matter.

Much.

[LAUGH] Much. There are

some things that might happen in Compass that

will require 2.0, but that won't happen for another

year at best because it needs 2.0 and

not everyone should be upgrading it because it's weird.

[COUGH] so, we allowed different versions of Ruby.

But, Ruby installs into your user directory.

Requires Homebrew.

So if you don't have Homebrew, you'll need this to install RBENV.

You can do this at home

later, if you want, you don't need to do it right now.

If you do have RB Homebrew installed make sure you

do a brew update so that you have the latest brews.

I don't know what to actually call them. [LAUGH] And then you just type in brew

install RBENV and ruby-build, and this will install RBENV, and the same developer

has a another Homebrew called ruby-build that will build different

versions of Ruby for RBENV, so it will allow you to quickly install.

[BLANK_AUDIO]

You already have RBENV? >> Yeah.

>> Nice.

Well done. Why are you even here?

You, you've got this! >> [LAUGH]

You might want to reinstall it depending on when you installed it.

The most recent version has version two, ruby version 2.0.0-p247.

>> [UNKNOWN] >> 030?

I mean the Ruby version.

>> Oh.

>> Which I started using just because it's what the next version of what

the OSN will use and I'd rather start testing in advance, just in case.

So the other thing you have to do, if you're using Mac, once you install RBENV,

you run echo, eval, that stuff, bash_profile.

And what that does is on, when you turn on the

terminal, make sure you're actually using RBENV instead of system Ruby.

I thought people pause more doing this.

Feel free if there's any questions throughout this.

Don't look at me with confusion, just ask.

>> I thought I saw something on Twitter about Compass, about

Ruby 2 like not being compatible with Compass due to some dependencies.

Do you know something about that? >> There shouldn't be.

I've been using Ruby 2 for the past three or four months,

and I haven't had any issues.

>> I think it is something Bryan Jones tweeted out.

Saw him and Chris have some exchange. I'll ask Chris.

>> I'll, I can ask Chris afterwards, but as, as far as I know,

there are some things that will improve Compass if Ruby 2 is used more often.

And it's mainly the listen functionality.

That can be improved dramatically if we can use Listen 2, which requires Ruby 2.

But yeah, I, I can talk to Chris.

Nice thing about this is you can install whatever versions you want.

So I do have installed on my system

1.8.7 and 2.0 for, in case something bad happens.

I haven't had anything bad happen so far.

>> Just if for some reason you're using Drupal Aurora.

Yeah.

>> Grunt's tag, this is just irrelevant to that or does this help that?

Helps that.

>> Helps that? >> Helps that.

This is purely Ruby, although the Grunt stack is

the very last thing we're going to go over.

Love me some Grunt.

Okay.

Can I click it?

Actually, I'm going to pause quickly and do this as well.

I forgot, I also should tell you all this.

If you go there, bitly.com or bitly/painfulSass.

This has my slides, as well as example files.

[CROSSTALK]

What?

>> Yeah there we go. Yeah, I keep everything on the GitHubs.

And it will be there forever and ever. Amen.

>> [LAUGH]

>> So yeah, painfulSass.

It has all these commands so you can copy and

paste them as well as example files that we're gonna use a little later.

Okay. So once you

have RBENV installed, to install a new version of Ruby all you do

is RBENV install and whatever version of Ruby you want.

So the example here is the version that will be on OS 10

2.0.0-p247.

That will take a few minutes to run. So this is

fun throughout this workshop.

Half of the time it's just sitting there watching your computer think.

Then you run RBENV rehash, and that just, RBENV will make

sure that it has all the right files in the right place.

And you can set RBENV global to the same

version that you're installed and that will make sure that

every time you run Ruby files in the command line,

it will always use the verse that you just installed.

Version is just set there.

>> Does it work like IBM that if you change

that then you've got a different gem set or different gem?

>> Yes, so, the big difference between RBM

and RBENV is that gem sets don't technically exist

in RBENV.

>> So if I installed gems while I was using one nine whatever

>> You have to re-install them for the second version.

Which is, slightly annoying.

At the same time it's really beneficial to make sure that

you do keep things separate and have the right versions and everything.

>> Do you have a quick way to like,

save that reference, the gems here just install the

same ones, even though.

>> I don't know of a quick way to do that.

I, I could think of a way of changing your gem path

to be in the same place, but that starts getting weird very quickly.

We're typing.

I'm gonna, unless someone yells at me I'm gonna move on.

Okay. So, Ruby version.

If you weren't paying attention before because you

don't want RBENV, come back to me now.

This is where we need to start paying attention again.

so, there is a file in all your projects that should be there called .RUBY-VERSION.

And what this is,

is it tells the project what Ruby version you're using, which is kind of important.

So if you are using RBENV, if you're using RBM, you're using CHRuby or if you're not

doing this at all, you should include this file so you know which version of Ruby.

>> [COUGH].

>> You started the project with.

And it will always just go if you have this file and

you are using RBENV it will always use the version of Ruby that

is saved in this file. So, all this is, is just a simple text

file called .ruby-version that just has the version number.

That is it.

If you look at my GitHub, you can see there's an example one in there.

So 1.8.7-p358. That is what is in OS X currently.

This is what's gonna be in the next version of OS X.

It's

10.9. Who knows what's gonna happen after that?

We're gonna have OS, X 11 no, it would

be a branding nightmare.

So doing this will allow people who are using any

sort of version management for Ruby to use the correct version.

And so that in the future, in case something changes,

you can go back and know, crap, it might have

been a Ruby issue, let me make sure I have

that exact version of Ruby to make sure everything's going okay.

>> Would you recommend the file [COUGH] goes on with production

environments as well if you're working, like, with distributed jump by staging.

>> Might as well.

It can't hurt to have it in there.

I mean its no different than having a getIgnore file in production.

It doesn't actually give any real information about the project anyway.

But yes, I would say, this should be in version control.

This should be where everyone can access it, cuz if you do have

something running on production, for example, you

want to make sure that they're using

the right version of Ruby. [SOUND]

>> So does the RBENV read that file or does something that loads your code?

>> so.

>> Or does it, is it functional or does it?

>> It is functional.

RVM, CHRuby, and RV all read that file when they're running something.

So, if that file is there, they will reference that first

and then, and then they'll reference your global if that file doesn't exist.

If you're using RBENV you can also just type in RBENV

local and your version number and that'll create the file for you.

Okay, that's. RBENV.

It's kind of weird.

I know, this whole thing is weird. I'm sorry.

Anyone have any questions about, like, why you should have RBM or benefits of it?

Anyone looking confused?

>> I, I, I think you may have just asked this, but I just want to clarify.

So that.

When does it get?

like, how, how does this version get switched?

>> So, depending on which if you're using

RBENV RBENV will it does some weird things

in your system, where, if the, I forget

the, the exact term, but when you run Ruby,

it actually runs RBENV.

And RBENV selects which version of Ruby you should actually run against.

>> Based on the gem, you kind of. >> Yes.

Based upon either your global setting or the Ruby version file in your

project directory. So I started using RBENV for two reasons.

One testing because since I manage sometimes extensions I want

to actually make sure it does work on different versions.

And two, it just makes my life easier if I'm not using system Ruby.

So much easier.

so, the second thing you need RBENV manages your Ruby,

now we need something to manage all of our gems.

And gems include Sass is a gem, Compass is

a gem any of Compass extensions are all gems.

Many of your Compass extensions are not always

backwards compatible.

Namely, the break point singularity. Not backwards compatible.

Cuz there's just so much development that happens on

them, it's very, very difficult to keep backwards comparability.

Aurora's gem isn't backwards compatible.

>> Neither is Early Suzy. >> Neither is Suzy, Early Suzy.

yeah. So, bundler's a Ruby

gem in and of itself, that will manage your Ruby gems for you.

So, once you install a version of Ruby op.

You just do, gem install bundler.

If you're using system Ruby you do have to use sudo.

How, how can I check a version on bundler to see if I have it?

>> Check the version of bundler or check the version of a gem?

>> Of bundler.

>> If you type in bundle//version, it'll say you have it or not.

>> Okay, cool.

>> Yeah, and as long as you have it you're golden.

>> I just wanna.

Like it's working for me for reals, but not if I do bundler.

>> Not if you type in bundler?

>> Mm-hm.

>> Bundler registers the command bundle, not bundler.

Yes, of course. >> Because that makes sense.

>> Exactly.

I'm fairly certain that Ruby developers are out there just to make my life hell.

>> It was why Ruby was invented, right? >> Sorry, you two.

[LAUGH] Okay.

So now that you do that, bundler's ready to use.

All you need.

It's glorious.

So what bundler does is, in a project directory you can create a gem file,

and a gem file just has a list of all the gems that you're using.

And then you run bundle install.

And it will install of your gems from that gem file and create a Gemfile.lock.

The Gemfile.lock takes all those gems that it downloads,

and well, the Gemfile can say, we need at

least version 12 of Compass.

We need at least version one of Sass, what have you.

Gemfile.lock saves the exact version that it's using of every

single gem, and if both of these are saved in

version control that means I can start a project, create

my Gemfile, create my Gemfile.lock, and have the exact version numbers.

And my co-worker can start the project and run bundle install on his computer, and

it will download the exact same versions of each gem that I was using.

In a local directory?

Or? >> We'll get to that in a second.

>> [LAUGH] What, sorry what if it's installing

like a newer version than you've already got?

>> so, if it's installing a newer version I've already got

it will not install a newer version if I have the Gemfile.lock.

But if I'm just using the Gemfile it could, and it will save that information

in the Gemfile.lock or whichever version I have.

So, an

example Gemfile. I'll head back over here.

Say, don't worry about copying this.

It's all in the one, it's all in bundler's

documentation, and two it's all on that GitHub repo.

But it's really simple.

You just have a source so I use

RubyGems.org, cuz that's where all my Ruby gems are.

And then, command gets gem, the compass the gem name, comma,

and whatever version it needs to be. So, you have

this little tilde arrow. It says it needs to be at least version

was it 0.12, but no more than version 1.

Or, where it comes to Aurora, it needs to be

at least version 3, but it cannot be version 4.

So it can be 3,

3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, not four.

>> And not lower than what's specified?

>> And not lower than what's specified, yes.

You can also have exact versions of your gem file.

For example, I had some GitHub things on here.

GitHub now has actually made this even easier for me.

They have a gem that just does this.

But it's really simple.

So this is a optional thing, sort of.

If you're using system Ruby, you have to do this.

If you're using RBENV, you don't technically have to do this.

But you can if you want to.

So you can install you can have all

of your gems installed to your project directory.

So you have the exact version of each gem in that directory you're using.

If you have just a couple of projects, I kinda prefer this,

because it means that everything I'm using is all in one little directory.

My, everything.

but, and if you're using system Ruby, you have to do this, because

you don't want to have to go in and pseudo-install every single gem version.

And I'll say why you have to do that in a second, but you have to

make the directory.bundle, and I don't know why

this is capitalizing everything, that should not be capitalized.

[SOUND]

[BLANK_AUDIO]

So we want to run make directory.bundle all lowercase.

Silly style sheets.

Actually.

>> Can't you do like a. >> No, it's cuz it's an H4.

Yeah, I was told to make sure that my slides were really big.

So I just did header for everything as opposed to, I don't know, knowing CSS.

>> [LAUGH]

>> If only someone here new CSS. >> I know,

right? I'm sorry, guys.

I really am a frontend developer. >> [LAUGH]

>> Okay. So what this is, is creates in your

home directory there we go that's the command.

It creates a directory in your home directory

called bundler, which all your bundler settings goes into.

And then, this will create a file called,

bundle config.

And then this line will say, to put all of your gems into vendor/bundle.

So in your directory, you'll have, all

your Sass files then one file called vendor,

and in that vendor file, the bundle folder,

that will have all of your gem information.

So I'll leave that up for a second.

[BLANK_AUDIO]

Should probably mention. Yes.

>> How does, how does Ruby, or RBM [COUGH] know about vendor/bundle?

>> Ruby does not, bundler does. >> Okay.

>> Hm. >> I love questions.

They're, just, like, hold on, just wait two minutes.

But no, that's a great question.

I should probably mention that all of this comes out of

Four Kitchens, the the company I work for has no Ruby developers.

So when we started using Sass, we started running into huge issues

very quickly and spent months trying to figure out, what is this doing?

And you have to like go into Ruby documentation to figure that out.

Tsk, tsk, tsk, okay.

>> And should we do this for every project that we initiate?

>> So, this is a onetime setting. Okay, so it's in your home directory.

Once it's done, it's done.

The only thing that's per project that we've done so

far is the Ruby version file.

Everything else is just a setting that happens and you, your done.

>> Just make sure everyone on the team uses bundler?

>> Yes, and they should be. Trust.

>> You can probably do a lot of, you know,

have a script or something that does all these things.

[CROSSTALK]

>> Yeah.

You could have vagrant do something or, and there's

a bunch of things that could just create a script.

Let me find it.

So, now in your directory, all you do is run bundle install

and that will install all of your gems, in the right version.

Sometimes you might think, hey, if you're using

system Ruby I have to use sudo right?

Don't do this.

Never ever, ever, ever, ever run sudo bundle install.

This is a great way to break things very quickly.

the, the short explanation on why is bundler doesn't just

save settings to like it doesn't just download gems, it also

changes some local settings to your user, and if you do

pseudo-bundle install, it'll change it for the root user, not your user.

And it's weird, it's funky, but it's like big no-no.

Do not run sudo bundle Install. Bundle install.

>> Just bundle? >> Just bundle.

>> What if you may have run sudo bundle

Install in the past what symptom could you have experienced?

[LAUGH] Your entire computer will blow up in 30 minutes.

no, it, it, it's not terrible it just, it changes how bundlers should work.

So if you use RBENV all that issues will go away.

But yeah, or whenever you update your Mac the Ruby shit will change

>> If we bundle install now, what bundles is it going to install?

So, if you do this in your project directory, that's, it will

take a look at the gem file and install all those gems.

If you just do it in a regular directory, nothing will happen.

And now instead of running compass compile, you just run bundle exec

compass compile, and that will, bundler will then get all the right gems.

It will go to wherever your gems are stored,

whether it's in the local directory or the right directory

with RBENV, and it will use the exact versions

in the Gemfile.lock file to run all of your commands.

And now all of a sudden you don't have to go through dependency hell with Ruby gems.

>> So this, so one time, a one time thing?

>> No.

This is whenever you run compass compile or compass watch.

You just run bundle exec compass watch.

Yes.

>> So then what you're saying that avoids dependency help, but like

if you just use compass compile then you don't really have any issues.

Is it just, if you're not having issues, its cuz you're not using enough of the.

>> So, this is what happened to us at Four Kitchens.

We were using just compass compile, compass watch for months.

And then one of our gems that we used on pretty

much every one of our projects updated, and we didn't realize it.

So, we were just running things and all

of a sudden, all of our projects before broke.

And nothing would compile correctly, we're getting errors.

But if we just had our gem file and Gemfile.lock in that we knew what

this was, then we could just go back and say, oh, we were using this version.

We just run bundle exec compass watch, and

all of our problems are solved, and yes it's

very frustrating to have to write up and

bundle exec compass watch, but that's the next step.

Getting rid of even that. >> So, if I understand what this does,

right? >> Mm-hm.

>> Is it that now we're gonna use the bundle version controlled version of gems.

>> Yup. >> To do complex.

>> Mm-hm. >> Regular.

>> Yes.

>> Most recent Compass. >> Yes.

>> Okay.

>> Or whatever is most recently installed onto your system.

>> Okay.

Cool. >> Yeah.

>> And then if your operating singularity or whatever.

>> Mm-hm.

>> Just change the number of the gem file.

>> You can either change the number of the gem file or there's

a command, it's just bundle update singularity GS, and

that will then update your Gemfile.lock in your Gemfile

>> And this isn't just for companies to compile, this is for anything.

>> This is for anything with Ruby, yeah.

Yeah, so if, for some reason you decide that you wanna become

a Rails developer in the future Rails developers all use this too.

Mainly Ruby development.

It just kinda sucks that being frontend developers we kinda have to do it too now.

But yeah, the, the biggest thing I, if I can impress by anyone is make sure you

do create Gemfile, and Gemfile.lock for the day that

when everything breaks, you can fix it very quickly.

Instead of where we were, in which, I actually was like calling

up Sam, going Sam, what did you do to break everything I did?

>> Is the Gemfile.lock, isn't that auto, automatically generated?

>> Yes. So, yeah, you created gem file.

Gemfile.lock is created by bundler.

>> Is that gem file, is it case sensitive to the file name?

Or can it just be?

>> It is case sensitive.

And I believe it's, yeah. Capital G and everything else.

>> So the gem file is when you're developing a ruby gem?

>> Gem file is just in any of your project that you're using Sass.

Just create a gem file.

List the gems that you're using.

So if you're using, obviously, Compass, will be one of them, Sass

will be one of them and then any other Ruby extensions you're using.

So, Compass, Breakpoint Singularity Toolkit Aurora, love me some Aurora.

And all of the non-Drupal developers looking a bit confused.

>> One more thing.

>>

Yeah.

>> I hope you didn't say it while I was out.

I'm using in a project a lot of start up scripts which include all those commands,

like or write the a script server, a script compile and stuff like that.

>> Mm-hm.

>> Integrate the files on things and take care of,

every time the server is started the bundle command, this command.

>> Yeah.

>> Because, sometimes people

really forgot to do this and people who are all the development takes longer.

I don't care about this.

[LAUGH] It's basically from problems about people who don't know about relief.

>> Mm-hm.

>> And [SOUND] the rehash is just one

command, type and script server, and you're done.

>> Yeah.

yeah. So, what we do for that is

we use Grunt.js. Who here knows what

Grunt.js is? Fantastic.

This is, this is my favorite part. so, Grunt.js is I forget

the exact term they use, it does simple tasks for you.

So you can create, it runs off of Node.js if you're familiar with that, so it's all

JavaScript based.

And it will run a bunch of tasks every time that you want it to.

So we had projects where Grunt.js runs all our bundles and all our bundle

execs, all our compass compile and will do all of our Watt tasks for us.

And we also have like a deployed task that it does, which it will do all that.

It will lint all our job description, it will lint

all our CSS, it will minify all of our images, and

it then it will compile all our Sass in compressed

form, and then we can commit that to our master branch.

So it's kind of like a, a wonderful, magical tool that saves a lot of time.

Per usual, kinda sucks to start.

[LAUGH] Luckily, grunt is a lot easier than it looks in the first place.

So, you have to install node.js on your computer, which there's

a helpful installer online.

Just go to the node.js site, download it, install it, easy as pie.

Compile your Sass and more. >> [INAUDIBLE]

>> Bower and Grunter, two completely different things.

So, Bower is a frontend package manager.

And that

will, download any frontend dependency that you need.

Grunt just does tasks.

>> Just does the tasks.

>> Yes. [SOUND] so once you have Node installed

you can go to the Grunt documentation for this

as well, but it's just NPM install with one or two G

>> [BLANK_AUDIO]

Does node just like in brew, just install node?

>> So the dash?

Okay.

>> [INAUDIBLE] No, I guess you know it, but I guess you need Afghan for Grunt.

>> Yeah, but isn't MPM?

>> Mpm is bind to the node now.

so, again, you can take a look at the documentation for this.

Don't worry if. >> Errors happened.

>> Errors happened? >> Yeah, I get the same one.

>> You probably have to run it in sudo.

>> Yeah, run it in sudo. >> Oh, okay.

[LAUGH] Every, every time that I run MPM install I run sudo, pretty much.

[NOISE]

>> Do you have these slides posted somewhere online?

>> Yes.

>> Yeah? >> Yes.

Yes, they are.

[BLANK_AUDIO]

So things that Grunt.js can do, once, once you have it installed.

Can do livereload for you, magically.

You can do it on your server, so if you are developing on a

development server you can have a livereload

run over here and still work locally.

Yeah, that's by far the coolest thing it does.

Image minification, so it will take all of

your images and optimize them without loosing any quality.

You can easily save 30, 40% of image size just by running that.

JavaScript linting, JavaScript minification, Jekyll integration

if you use that et cetera.

It can really do anything.

I'm gonna be working this afternoon to see if I

can get some more Ruby stuff built in with it.

oh, I was skip the end.

So, here's my example on what Grunt

can actually do. Let me make this bigger.

I, in this directory, I have an example of gruntfile.js.

You can look at it.

I also have more examples on the GitHubs. But all I do is run Grunt.

[BLANK_AUDIO]

And now it's running my watch task. And I can go over to my Sass file.

Actually let me do this.

This, this is my webpage.

As you can tell I spent a lot of time on designing it.

>> [LAUGH]

>> But I can take a look at my

Sass file which has background color gold on it.

I'm just gonna refresh this quickly just to make sure it's running.

And I'm gonna change the background

color, green. Save.

And wait. There we go.

And it's green. >> Linting and.

>> Yeah.

So, this is what, for those of you who

are not familiar with livereload, it will, as you compile

your Sass, it will then push the assets to your

webpage and update the assets on your side without refreshing.

So like, if you're styling this thing within

a field group that is, like, three down, midway through the page,

you don't have to refresh the page and go back down every time.

It just does it.

It's magic.

I once tried to look at the script and

said, it's magic, I'll just leave it at that.

>> What if you get a linting error, how does it

>> So, if you get a linting error it will actually

just say, here linting error, and you can decide whether or not

you want that to actually stop compling.

>> Oh so, it'll, it'll flip through the command

line you have and say, no, I got it.

Yeah so, yeah I've had projects where like for deploy, it's strict.

It will not let you deploy without having full js linting, but during

development, it'll say, eh, you might wanna

fix this, but it'll still do everything.

So to give you an idea how easy it is actually work with Grunts

besides the fact that it's JavaScript, which is

weird this is all of the commands I need,

and this will do all of my optimization,

all of my minification, all of my Compass stuff

and a bunch of other things. And again, this example is online.

This is a simple one. But this also runs bundler, by default.

So you can see in my compassing bundleExec is true.

That even bigger.

So this means that instead of having to run

bundleExec compass compile every time, I just run Grunt.

And Grunt then handles my

compass watch. It handles my bundler stuff.

It handles all of my right versions for everything.

And it just does it.

This is, by far, the most useful thing I have ever learned in

the past year, because it means that I don't have to do anything.

And as with everything, we set it up once for project, which really

is we copy and paste the last project's Grunt file, and that's it.

And then

all of our developers are always using the right versions of all

our gems, all of our frontend developers don't have to do anything.

It's just simple and easy so, it goes from freaking out because

I don't have the right version of Ruby, my gems are freaking out to one command.

That's, that's the least pain I can give you.

As I said, it takes a lot of pain to get

to that point, but once you do, it feels so good.

So is anyone here, Drupal developers, Drupal developers?

Yeah, so [LAUGH] I'm, I'm a Drupal developer.

I love pain.

Love Drupal. >> [LAUGH]

>> Yeah.

So, the Aurora theme, has a Compass

extension that creates your sub-theme for you.

It also has Grunt integration built into it.

So if you go to Aurora documentation, you just run

it's like Compass installed of Aurora Grunt something.

It's a command.

It's, it's on the docs.

I always forget what it is and copy and paste it myself.

And that will install all of your Grunt integration for you.

It'll have a full Grunt file that we maintain for you.

And it, that also includes the livereload stuff.

So if you're using Aurora or the Magic Module on

Drupal livereload is just a setting that you turn on.

And it will handle all the JavaScript

for you. [SOUND] [CROSSTALK].

Yeah.

>> What in? One question.

actually, running that. If you kill the watch.watch.

>> Mm-hm.

>> Does it release the library load port?

>> It does. >> It does?

>> It should.

>> And if it doesn't? [LAUGH]

>> [LAUGH] >> You have other issues.

>> [LAUGH].

>> And all of the stuff that you're doing in like Sass, are you

just doing it like command and coalesce it and you're like editing

it and then as you save it, it saves a back up?

>> Mm-hm.

>> To your server. [CROSSTALK] Yep, yep.

>> Are you aware, I ran into issues that, if you had in that config

outlay, if you had a require, like. >> Mm-hm.

>> Sudo, in this case do you have, is that what

you put or is that just how the gem file config?

>> No.

You, you still have to have it in your Configure OB file.

>> Have you done a config OB that has more than one require?

>> Yeah.

>> And you haven't run into issues with Grunt.JS?

>> Hm-mm.

>> Okay.

Cuz I have problems with if I had more than

one, you had to, like, use the raw part of

>> Interesting.

>> The office.

He couldn't make it one of the options for Compass' raw [INAUDIBLE].

>> Yeah.

>> Because I have more than one.

>> That's weird.

I have not seen that before, but I'd be interested

in checking that out, seeing what could be causing that.

>> Yeah.

>> We actually had a very similar issue in my company where

it was, it was actually happening [INAUDIBLE] where, so our assets are

grouped in a sub-directory that's not part of our project directory, and

so because we were running Grunt from the project directory, it didn't work.

It's there was like a lot new expectations within

Grunt to then get Compass to run within the sub-directory.

And we, when we were able to figure

all that out, it solves those problems, actually.

>> Yeah, I actually. >> Yeah.

>> Actually, since resolving those same issues, I

haven't had a chance of putting an app [CROSSTALK].

>> Oh, sorry.

>> I think the issue I had was before I resolved those ones.

>> Oh, okay.

>> So I haven't tried performing another.

>> Mm-hm.

I feel like a Drupal site, if you wanna change

the image directory, put just sites all beams inside of that.

>> Yeah. so, what I do is,

this is all within my theme. So then all the directions are small.

One thing you can't see here, I actually have, in my config RB file, my images

directory is _img. And then in my distribution

it's IMG. And what this is, or why this is, is cuz

it will do my image minification, this is the best reason by you should be using

imageder and Compass, because on while I'm developing it uses

big versions of images, and then Grunt will minify everything,

put it in the image directory, and it'll automatically change

all of my CSS to use that directory for production.

Any other questions?

>> Yeah, sorry.

So you're not, you're not running a real app network, right?

>> Nope.

>> You're just running this kind of

separately just for your, like Sass images.

>> Yeah this is for, so, since we do all Drupal work.

This is all within my theme Drupal directory.

So this is all of my Compass, all of my images, Sass just frontend work.

And the nice thing about all these things

is it's not reliant on anything like Rails.

It's purely if you're doing WordPress, Drupal,

Joomla, your own thing, what have you. It applies to all of it.

>> I, I use Django, but I like Sass a lot, so.

>> Yeah.

One last thing, just going back to that [INAUDIBLE].

>> Mm-hm.

>> Being that sort of alias or shortcut for that longer one?

You're saying that, that resolves, if you upgraded one

of the gems, was that you're looking for using.

>> Yeah,

so if, if like in your system Ruby or, or you're base Ruby that you have

compass 13 or 0.13 and your project needs compass 0.12.

If you're, you're using bundler and using bundleExec, or a gem file

like this, it will always use the one two instead of the one three.

[BLANK_AUDIO]

Which, on one hand, it's like you're not

using the best, but you can always update it.

The other hand, one day, Sam [UNKNOWN] with update

your gem on you, [LAUGH] and everything will break.

>> [LAUGH] What do you think about just using the Sass, you

know, the source files direct, directly of whatever you want to use,

you know, to kind of cut that of out your equation, like

I use Suzy but I just said, you know, put, putting style sheets

in mind under a vendor sub-directory. >> I'd say you can do that.

and, I know, like, for Team Sass, we're trying to get

to a point where we're not using any Ruby on our codes.

But if you have a if you have a Compass extension that uses Ruby so for

example Compass has a lot of Ruby built into it, you would have to use Bundler.

But if like you're using like, the Compass normalized

gem, you can just copy those files. That's, that's not hard.

I know with the, the team Sass we're

trying to make it so that nothing uses Ruby.

I think Breakpoint still has one function in there that we have to have.

But that might, that should be coming out once it gets ported to Compass.

Any other questions?

>> Yeah, how, how much of this can we do on a Windows machine?

[LAUGH] >> So, what I need

you to do is go home, take that Windows machine, and put it in the trash can.

>> [LAUGH] >> Just kidding.

So bunder bundler and node all work on a Windows machine.

You just

have to get Ruby on a Windows machine and, which you'd have to

anyway for all of this but yeah, everything actually still works just fine.

I.

I know node.js can, but I haven't done that myself.

But yeah or, yeah, use, use Linux.

>> Yes! >> [LAUGH].

>> Yeah, why don't you running in a virtual machine?

>> Yeah.

[NOISE]