    
|
|
|
Our new course on CSS frameworks was just released! In Framework Basics, you’ll learn how to build websites using two of the most widely used Frameworks in the industry: Bootstrap and Foundation.
First, you’ll build a prototype using each framework’s common CSS features, components, and JavaScript plugins. Then, put everything learned about Bootstrap and Foundation into practice by building a simple marketing website for the Ribbit iOS and Android app.
By the end of the course, you’ll have all the tools necessary to build a website or app of any size using a CSS framework. You’ll also understand how frameworks can be useful when used properly, and which one might be best suited for your project.
Edit: A new stage titled “What’s New in Foundation 5″ is set to be released early January!
The post Learn CSS Frameworks on Treehouse appeared first on Treehouse Blog.
]]>The following is a guest post by Florian Motlik. Florian is CTO of Codeship, a hosted Continuous Integration and Continuous Deployment platform. What the heck is that, you might ask? It's kind of a philosophy and toolset for working on websites. That is perhaps a bit too simplified, so I'll let Florian explain.
A great development workflow will make your good developers great, and your great developers exceptional. A bad workflow will take your best engineers productivity down to a junior level and make wish he worked elsewhere.
It is critically important for every team and especially the leaders of those teams to get their development workflow in order. Two best practices that have gained a lot of traction over the last few years are Continuous Integration and Continuous Deployment. Here's some quick definitions.
Continuous Integration is the practice of testing each change done to your codebase automatically and as early as possible.
Continuous Deployment follows the testing that happens during Continuous Integration and pushes changes to a staging or production system. This makes sure a version of your code is accessible at all times.
First, we will take a close look at Continuous Integration and show you how to get started with testing. Then we will move on to Continuous Deployment which is the next logical step.
With both in place, your development team will be orders of magnitude more efficient.
Automation is a cornerstone of a great development workflow. Every task that can be done by a machine should be. Automation gives you the time to focus. Testing is one such task.
Through testing, you can be sure that the most important steps your customers will take through your system are working, regardless of the changes you make. This gives you the confidence to experiment, implement new features, and ship updates quickly.
Good testing begins with viewing the app from a user’s perspective. What are the typical workflows? What features and steps do users go through often?
Then start testing with those in mind. Use tools like Selenium or PhantomJS to make sure those important workflows work.
A great way to determine the most critical workflows is by getting everyone in your team to write down a list of them and then combine those lists. You can read an in-depth guide to this technique in one of our blog posts.
Here is a list of tools that you can use to start testing UI:
From this strong base of tests that make sure the workflows are working, you can go deeper and start unit testing different parts of your site. But beware: Your customers want your UI to work, so make sure it does with every change!
With all those tools in hand, the single most important step you can take for testing is getting started. It pays off immediately, and not just from a tech perspective. You can read about the business advantages of Continuous Integration in this blog post by Joe Green.
Humans make mistakes. Sometimes people consider a change so small it can’t possibly break the app, so they don’t run tests. Then your product goes down and nobody knows why.
Automated tests can only show their true power when you run them continuously and for every change. They have to be run on an automated and separate system to prevent the ‘It works on my machine’ syndrome. Only if the Continuous Integration infrastructure tells you the tests pass, the tests pass.
The advantage of running all tests immediately for every change is that you know right away if something broke. Consider working on a 2 week sprint. On day two of the sprint, one of your developers changes something that breaks a test. If you don’t continually run all of your tests, there is a chance nobody detects the problem. People keep working, and at the end of the sprint, you run the whole test suite again. The test fails. It now has been 2 weeks since the breaking change was committed. Finding the change that broke the tests is incredibly hard, as there now have been a lot of commits since then.
Lots of teams are on way longer cycles than 2 weeks. This is incredibly wasteful and can be easily prevented by running all your tests every time one of your developers pushes code to the repository. Any failures can be fixed right away.
Continuous Integration is the first, but very important step in Continuous Deployment.
If you'd like to learn more about it, Martin Fowler has released a great and very in-depth article about Continuous Integration on his blog
Code rots if it doesn’t run somewhere. External dependencies are updated, server packages installed, API’s change or operating systems replaced. Often we do not have the ability to control every part of our infrastructure. We rely on other products and companies to maintain parts of our stack. All of these changes can break your app without you realizing it.
This is why Continuous Deployment is incredibly important. Whenever the main development branch in your repository passes all the tests, you should push your code at least into a staging environment or in the best case into production. Your development or QA team can then review the latest version of your application and give feedback. Furthermore you can run tests against that staging system to make sure it works in a production-like environment.
This helps you find problems early and fix them while it is still cheap. An important concept to understand when starting with Continuous Deployment are deployment pipelines.
A deployment pipeline defines all steps necessary to go from your codebase to the production website. Automating these steps is crucial to have fast deployments. But often, deployment pipelines also include manual steps, like a product manager signing off on a new release.
Deployment pipelines have to be easy to follow and replicate. This allows you to push new changes regularly. Especially when you need to ship a fix, predefined steps can save you from bringing more harm to your site.
Once you set up a Deployment Pipeline and automate the steps, you are in a position to ship small changes quickly, get feedback from your customers, and iterate on your product. This is a major competitive advantage to other companies who need a long time to react to customer feedback. Intercom did a great blog post about this.
It’s amazing how much lower the cost of bringing a new software product to market has gotten in last couple of years. It has never been easier or cheaper to build great software. This levels the playing field between you and your competition. You need to ship new features faster than your competition while delivering better and stable long term quality. Continuous Deployment is one of the techniques that will help you to get there.
After interviews with dozens of companies and the feedback from thousands of developers using our product we’ve identified several steps you can take to get started with Continuous Deployment.
Testing is the first step that needs to be taken. You need to get to a point where you can change almost any part of your system and be sure you didn’t break any other feature because your tests will catch those errors. Once you are at this point, it liberates you from having to think about impacts this change might have. You can now experiment with your product and iterate to build exactly what your customers want and pay for.
Tests are not there to make your developers happy. They are there to build a stable and high quality product for your users. They are a tool to keep your users happy and introduce changes without destroying their experience. Building a product without properly and automatically testing (as your users would use it) means working with the hands tied behind your back. You might get new features out there, but you will never be as fast and good as you could be.
Testing is the basis on which Continuous Deployment is built. Tests make software as Clemens, one of our developers, explained in his blog post.
This script tests Google Translate to make sure it translates "good morning" from German to English:
#Run with casperjs test translate.coffee
casper.start 'http://translate.google.com/', ->
@.sendKeys('#source', 'Guten Tag');
@.then ->
@.click '#gt-submit'
@.waitForText('Good day')
@.then ->
@.test.assertSelectorHasText '#result_box', 'Good day'
@.then ->
@.capture 'output.png'
casper.run ->
@.test.done(1)CasperJS helps you to start testing your application quickly, and it will scale up to test more complex scenarios as you need.
Every step in your deployment should be automated. Once set up, you should never have to think about which steps need to be taken. Every choice and every manual task leads to possible mistakes, so you simply do it less often. By automating every part of your deployment you can push new features, but more importantly, push fixes very quickly. Continuous Deployment works because of automation, so don’t skip this step.
When pushing quickly you also want to be able to go back to an earlier state easily. Otherwise you won’t feel safe enough to do as regularly as you should be.
Automated Rollback includes your codebase as well as your database. Make sure you regularly backup your database and use those backups to recreate your system on test machines. If you don’t regularly restore your backups you can’t be sure they will work when you desperately need them.
Create a staging environment and push your master branch or main line of development into that Staging application any time changes are made. This Staging application is your first line of defense and helps to review all changes before going into production. You can even run automated tests against Staging to make sure it works as expected.
If you use your product in your daily work, use your Staging and not your Production server. As you push changes continuously to Staging, you will see first hand when something is broken as it immediately impacts your team. "Eating your own dog food" makes all of your developers aware when the quality drops.
As a final step, continuously deploy to your Production environment. This will truly change the way your organization works. There will be no more fear in changing your site. This means you can iterate quickly on new features, but if you ship a bug, you can quickly ship a fix as well. You are not tied to arbitrary cycles that slow down your team.
Moving to Continuous Deployment will change your development dramatically. It will make you more productive and lead to a more stable and better product. There are steps like automated testing that you need to get started with first. Automated testing is not a tool to build better software, but a process to build a better product for your users. Once set up, you can then reap the benefits of deploying new versions several times a day.
Please let us know if any questions come up or if there is anything else we can help with either here in the comments or send us a tweet to @codeship . We’ve also recently released a free eBook that walks you through our development workflows and dives deeper into Continuous Deployment. You can grab the book here.
Ship long and prosper!
Why You Should Use Continuous Integration and Continuous Deployment is a post from CSS-Tricks
]]>As a front-end developer, I’m writing a lot of CSS and using pure CSS is not the most efficient way nowadays. CSS preprocessors are something which have helped me a lot. My first impression was that I finally found the perfect tool. These have a bunch of features, great support, free resources and so on. This is all true and it still applies, but after several projects, I realized that the world is not so perfect. There are two main CSS preprocessors – LESS and SASS. There are some others, but I have experience with only these two. In the first part of this article I’ll share with you what I don’t like about preprocessors and then in the second part I’ll show you how I managed to solve most of the problems that I had.
No matter which CSS preprocessor is involved, there is always setup required, like, you can’t just start typing .less or .sass files and expect to get the .css file. LESS requires NodeJS and SASS Ruby. At the moment, I’m working mostly on HTML/CSS/JavaScript/NodeJS applications. So, LESS seems like a better option, because I don’t need to install additional software. You know, adding one more thing to your ecosystem means more time for maintenance. Also, not only do you need the required tool, but all of your colleagues should now integrate the new instrument as well.
Firstly, I chose LESS because I already had NodeJS installed. It played well with Grunt and I successfully finished two projects with that setup. After that, I started reading about SASS. I was interested in OOCSS, Atomic design and I wanted to build a solid CSS architecture. Very soon I switched to SASS, because it gave me better possibilities. Of course I (and my colleagues too) had to install Ruby.
A lot of developers don’t check the produced CSS. I mean, you may have really good looking SASS files, but what’s used in the end is the compiled .css file. If it is not optimized and its file size is high, then you have a problem. There are few things which I don’t like in both preprocessors.
Let’s say that we have the following code:
// LESS or SASS
p {
font-size: 20px;
}
p {
padding: 20px;
}
Don’t you think that this should be compiled to:
p {
font-size: 20px;
padding: 20px;
}
Neither LESS nor SASS works like that. They just leave your styles as you type them. This could lead to code duplication. What if I have complex architecture with several layers and every layer adds something to the paragraph. There will be several definitions, which are not exactly needed. You may even have the following situation:
p {
font-size: 20px;
}
p {
font-size: 30px;
}
The correct code at the end should be only the following:
p {
font-size: 30px;
}
I now know that the browser will take care and will find out the right font size. But, isn’t it better to save those operations. I’m not sure that this will affect the performance of your page, but it affects the readability for sure.
Combining selectors which share the same styles is a good thing. As far as I know, LESS doesn’t do this. Let’s say that we have a mixin and we want to apply it to two classes.
.reset() {
padding: 0;
margin: 0;
}
.header {
.reset();
}
.footer {
.reset();
}
And the result is:
.header {
padding: 0;
margin: 0;
}
.footer {
padding: 0;
margin: 0;
}
So, these two classes have the same styles and they could be combined into one definition.
.header, .footer {
padding: 0;
margin: 0;
}
I was wondering if this is actual performance optimization, and I didn’t find an accurate answer, but it looks like a good thing. SASS has something called place holders. It’s used exactly for such situations. For example:
%reset {
padding: 0;
margin: 0;
}
.header {
@extend %reset;
}
.footer {
@extend %reset;
}
The code above produces exactly what I wanted. The problem is that if I use too many place holders I may end up with a lot of style definitions, because the preprocessor thinks that I have something to combine.
%reset {
padding: 0;
margin: 0;
}
%bordered {
border: solid 1px #000;
}
%box {
display: block;
padding: 10px;
}
.header {
@extend %reset;
@extend %bordered;
@extend %box;
}
There are three place holders. The .header class extends them all and the final compiled CSS looks like this:
.header {
padding: 0;
margin: 0;
}
.header {
border: solid 1px #000;
}
.header {
display: block;
padding: 10px;
}
It looks wrong, doesn’t it? There should be only one style definition and only one padding property.
.header {
padding: 10px;
margin: 0;
border: solid 1px #000;
display: block;
}
Of course, there are tools which may solve this, having the compiled CSS. But as I said, I prefer to use as less libraries as possible.
While I was working on OrganicCSS, I met a lot of limitations. In general, I wanted to write CSS as I write JavaScript. I mean, I had some ideas about complex architecture, but I wasn’t able to achieve them, because the language which I was working with was kinda primitive. For example, let’s say that I need a mixin which styles my elements. I want to pass a theme and border type. Here is how this should look in LESS:
.theme-dark() {
color: #FFF;
background: #000;
}
.theme-light() {
color: #000;
background: #FFF;
}
.component(@theme, @border) {
border: "@{border} 1px #F00";
.theme-@{theme}();
}
.header {
.component("dark", "dotted");
}
Of course I’ll have a lot of themes and they should also be mixins. So, the variable interpolation works for the border property, but not for the mixin names. That’s a simple one, but it is currently not possible, or at least I don’t know if it is fixed. If you try to compile the above code you will get Syntax Error on line 11.
SASS is one step further. The interpolation works with placeholders, which makes things a little bit better. The same idea looks like this:
@mixin theme-dark() {
color: #FFF;
background: #000;
}
@mixin theme-light() {
color: #000;
background: #FFF;
}
%border-dotted {
border: dotted 1px #000;
}
@mixin component($theme, $border) {
@extend %border-#{$border};
@include theme-#{$theme};
}
.header {
@include component("dark", "dotted");
}
So, the border styling works, but the theme produces:
Sass Error: Invalid CSS after " @include theme-": expected "}", was "#{$theme};"
That’s because the interpolation in the names of the mixins and extends is not allowed. There is a long discussion about that and will probably be fixed soon.
Both LESS and SASS are great if you want to improve your writing speed, but they are far from perfect for building modular and flexible CSS. Mainly, they are missing things like encapsulation, polymorphism and abstraction. Or at least, they are not in the form which I needed.
I fought several days with those limitation. I invested a good amount of time reading documentation. In the end, I just gave up and started looking for other options. What I had wasn’t flexible enough and I started thinking about writing my own preprocessor. Of course, that’s a really complex task and there are a lot of things to think about, such as:
So, I thought about it a bit and found a solution. There is no need to invent a new language with a new syntax. It’s already there. I could use pure JavaScript. There is already a big community and a lot of people may start using my library immediately. Instead of reading external files, parsing and compiling them, I decided to use the NodeJS ecosystem. And of course, the most important thing – I completely removed the CSS part. Writing everything in JavaScript made my web application a lot cleaner, because I didn’t have to deal with the input format and all those processes which produces the actual CSS.
(The name of the library is AbsurdJS. You may find this name funny and it is indeed. When I share my idea with some friends they all said, writing your CSS in JavaScript – absurd. So, that was the perfect title.)
To use AbsurdJS you need NodeJS installed. If you still don’t have this little gem on your system go to nodejs.org and click the Install button. Once everything finishes you could open a new console and type:
npm install -g absurd
This will setup AbsurdJS globally. This means that wherever you are, you may run the absurd command.
In the JavaScript world, the closest thing to CSS is JSON format. So, that’s what I decided to use. Let’s take a simple example:
.content {
padding: 0;
margin: 0;
font-size: 20px;
}
.content p {
line-height: 30px;
}
This is pure CSS. Here is how it looks like in LESS and SASS:
.content {
padding: 0;
margin: 0;
font-size: 20px;
p {
line-height: 30px;
}
}
In the context of AbsurdJS the snippet should be written like this:
module.exports = function(api) {
api.add({
'.content': {
padding: 0,
margin: 0,
'font-size': '20px',
p: {
'line-height': '30px'
}
}
});
}
You may save this to a file called styles.js and run:
absurd -s .\styles.js
It will compile the JavasSript to the same CSS. The idea is simple. You write a NodeJS package, which exports a function. The function is called with only one parameter – the AbsurdJS API. It has several methods and I’ll go through them later, but the most common one is add. It accepts valid JSON. Every object defines a selector. Every property of that object could be a CSS property and its value or another object.
Placing different parts of your CSS in different files is really important. This approach improves the readability of your styles. AbsurdJS has an import method, which acts as the @import directive in the CSS preprocessors.
var cwd = __dirname;
module.exports = function(api) {
api.import(cwd + '/config/main.js');
api.import(cwd + '/config/theme-a.js');
api.import([
cwd + '/layout/grid.js',
cwd + '/forms/login-form.js',
cwd + '/forms/feedback-form.js'
]);
}
What you have to do is write a main.js file which imports the rest of the styles. You should know that there is overwriting. What I mean is that if you define a style for the body tag inside /config/main.js and later in /config/theme-a.js use the same property, the final value will be the one used in the last imported file. For example:
module.exports = function(api) {
api.add({
body: { margin: '20px' }
});
api.add({
body: { margin: '30px' }
});
}
Is compiled to
body {
margin: 30px;
}
Notice that there is only one selector. While, if you do the same thing in LESS or SASS you will get
body {
margin: 20px;
}
body {
margin: 30px;
}
One of the most valuable features in preprocessors are their variables. They give you the ability to configure your CSS, such as define a setting somewhere in the beginning of the stylesheet and use it later on. In JavaScript, variables are something normal. However, because you have modules placed in different files you need something that acts as a bridge between them. You may want to define your main brand color in one file, but later use it in another. AbsurdJS offers an API method for that, called storage. If you execute the function with two parameters, you create a pair: key-value. If you pass only a key, you actually get the stored value.
// config.js
module.exports = function(api) {
api.storage("brandColor", "#00F");
}
// header.js
module.exports = function(api) {
api.add({
header: {
color: api.storage("brandColor")
}
})
}
Every selector may accept not only an object, but also an array. So this is also valid:
module.exports = function(api) {
api.add({
header: [
{ color: '#FF0' },
{ 'font-size': '20px' }
]
})
}
This makes sending multiple objects to specific selectors possible. It plays very well with the idea of mixins. By definition, the mixin is a small piece of code which could be used multiple times. That’s the second feature of LESS and SASS, which makes them attractive for developers. In AbsurdJS the mixins are actually normal JavaScript functions. The ability to put things inside storage gives you the power to share mixins between the files. For example:
// A.js
module.exports = function(api) {
api.storage("button", function(color, thickness) {
return {
color: color,
display: "inline-block",
padding: "10px 20px",
border: "solid " + thickness + "px " + color,
'font-size': "10px"
}
});
}
// B.js
module.exports = function(api) {
api.add({
'.header-button': [
api.storage("button")("#AAA", 10),
{
color: '#F00',
'font-size': '13px'
}
]
});
}
The result is:
.header-button {
color: #F00;
display: inline-block;
padding: 10px 20px;
border: solid 10px #AAA;
font-size: 13px;
}
Notice, that there is only one selector defined and the font-size property has the value from the second object in the array (the mixin defines some basic styles, but later they are changed).
Ok, mixins are cool, but I always wanted to define my own CSS properties. I mean using properties that don’t normally exist, but encapsulate valid CSS styles. For example:
.header {
text: medium;
}
Let’s say that we have three types of text: small, medium and big. Each of them has a different font-size and different line-height. It’s obvious that I can achieve the same thing with mixins, but AbsurdJS offers something better – plugins. The creation of the plugin is again via the API:
api.plugin("text", function(api, type) {
switch(type) {
case "small":
return {
'font-size': '12px',
'line-height': '16px'
}
break;
case "medium":
return {
'font-size': '20px',
'line-height': '22px'
}
break;
case "big":
return {
'font-size': '30px',
'line-height': '32px'
}
break;
}
});
This allows you to apply text: medium to your selectors. The above styling is compiled to:
.header {
font-size: 20px;
line-height: 22px;
}
Of course the library supports media queries. I also copied the idea of the bubbling feature (you are able to define breakpoints directly inside the elements and AbsurdJS will take care for the rest).
api.add({
'.footer': {
'font-size': '14px',
'@media all and (min-width: 320px) and (max-width: 550px)': {
'font-size': '24px'
}
},
'.content': {
'@media all and (min-width: 320px) and (max-width: 550px)': {
margin: '24px'
}
}
})
The result is:
.footer {
font-size: 14px;
}
@media all and (min-width: 320px) and (max-width: 550px) {
.footer {
font-size: 24px;
}
.content {
margin: 24px;
}
}
Keep in mind that if you have the same media query used multiple times, the compiled file will contain only one definition. This actually saves a lot of bytes. Unfortunately LESS and SASS doesn’t do this.
For these, you just need to pass in valid JSON. The following example demonstrates how to use pseudo CSS classes:
module.exports = function(api) {
api.add({
a: {
'text-decoration': 'none',
':hover': {
'text-decoration': 'underline'
}
}
});
}
And it is compiled to:
a {
text-decoration: none;
}
a:hover {
text-decoration: underline;
}
AbsurdJS works as a command line tool, but it could be used inside a NodeJS application as well. For example:
var Absurd = require("absurd"),
absurd = Absurd(),
api = absurd.api,
output = "./css/styles.css";
api.add({ ... }).import("...");
absurd.compileFile(output, function(err, css) {
// do something with the css
});
Or if you have a file which acts as an entry point:
var Absurd = require("absurd");
Absurd("./css/styles.js").compileFile("./css/styles.css", function(err, css) {
// do something with the css
});
The library also supports integration with Grunt. You can read more about that on the following Github page.
There are three parameters available:
For example, the following line will start a watcher for a ./css directory, will grab ./css/main.js as an entry point and will output the result to ./styles.css:
absurd -s ./css/main.js -o ./styles.css -w ./css
Don’t get me wrong. The available CSS preprocessors are awesome, and I’m still using them. However, they came with their own set of problems. I managed to solve them by writing AbsurdJS. The truth is that I just replaced one tool with another. The usage of this library eliminates the usual writing of CSS and makes things really flexible, because everything is JavaScript. It could be used as a command line tool or it could be integrated directly into the application’s code. If you are interested in AbsurdJS, feel free to check out the full documentation at github.com/krasimir/absurd or fork the repo.
]]>Simple Stories: The Photography of Robert Houston, a curatorial project of the Museum Practice class (Art 427), was mentioned this week in an interview with the artist in City Paper and in the contemporary art blog, Bmore Art, as “best Baltimore art opening.”
Read the interview, “Images of Struggle,” at City Paper‘s website, or see which other exhibitions top the list of Bmore Art picks.
Simple Stories explores the work of photographer, Robert Houston whose photographic career documents half a century of portraits and everyday life, including his work for LIFE magazine and images of Dr. Martin Luther King, Jr.
Museum Practice is a course under the Art History/Museum Studies concentration in the Department of Visual Arts taught in the fall by Sandra Abbott, curator of collections & outreach at the CADVC. The course addresses professional museum and gallery practice, includes several visits to area institutions — such as the BMA, Homewood Museum and the Archaeological Museum at Johns Hopkins University — and then culminates in a student-curated exhibit at a Baltimore institution.
Simple Stories opened at the Creative Alliance at the Patterson December 6, and continues through December 14. Starting at 8:30 pm on Thursday, December 12, the Marquee Lounge will host “A Night with the Storyteller,” in which the artist shares accounts from his career of visually chronicling those from all walks of life. The Amalie Rothschild Gallery is open Tuesday through Sunday, 11 a.m. — 7 p.m.
]]>|
|
JSHint is a tool that can help you to write more reliable and consistent JavaScript code. The tool works by checking your code for a number of common errors. If you’ve ever spent half an hour trying to debug your code only to find that you missed a comma somewhere, you’ll understand how useful JSHint can be.
As well as catching errors in your code, JSHint can be used to enforce coding conventions and style guides. This is really useful if you work on a team as it helps to keep your codebase consistent and easily readable.
In this post you’re going to learn how to set up and use JSHint. You’ll be taking a look at some plugins that are available for popular text editors, as well as some example JSHint configurations.
JSHint is available through the node package manager (npm). If you don’t have npm installed, go to the node.js website and download a copy of node for your OS. This will install both node.js and npm.
Once you have npm installed, open up terminal and type:
npm install -g jshintThe -g flag means that jshint will be installed globally on your system. This allows you to access the executable from any directory.
Now that you have JSHint installed let’s test a file. You can either download the demo file or test a file that you already have on your hard drive.
Open up terminal and navigate to the folder that contains your JavaScript file. Then run the following command to test the file:
jshint demo.jsIf you used the demo.js file you should see two errors as shown below.
JSHint Errors
If JSHint doesn’t find any problems with your code nothing will be output into the terminal window. Open up the demo.js file in your favorite text editor and add the two missing semi-colons. Running JSHint again should now return no errors.
One of the best things about JSHint is that it can be configured to meet the needs of you or your team. This configuration can also be easily shared amongst everyone working on a project, ensuring that all the developers are working against the same conventions.
You can define your configuration in two ways. Either by adding special comments to your code or by storing your configuration in a .jshintrc file. I prefer to keep my configuration separate from the code whenever possible, so in this section we’re going to focus on setting up a .jshintrc file.
An added advantage of using a dedicated configuration file is that you can use the same configuration to check all of the JavaScript files in your project. For this to work the .jshintrc file should be placed at the root of your project.
Lets take a look at a simple example:
{
"curly": true,
"eqeqeq": true,
"undef": true,
"globals": {
"jQuery": true
}
}A number of configuration options have been used here to specify coding conventions.
curly enforces that all code blocks should be surrounded with curly braces.eqeqeq prohibits the use of == and !=, instead developers should use === and !===.undef specifies that an error should be thrown if a variable has been used the was not declared.globals allows you to specify global variables that are defined outside the file being tested (document, window, jQuery…). The boolean value specifies if the variable is writeable. Setting the value to false (default) means the variable is read-only. The globals option should be used when the undef option is set to true.You can find a full list of configuration options in the documentation.
Note: Notice that the configuration options are specified using JSON. This is a requirement for all .jshintrc files.
If you’re curious, here are some links to JSHint configurations for popular projects:
The SublimeLinter JSHint plugin for Sublime Text
Running JSHint from the command line can become a bit tedious. Ideally you want to get real-time feedback about any errors as you write your code. There are a whole bunch of plugins available that can bring the goodness of JSHint directly into your favorite text editor. I’ve listed some of the most popular below.
Refer to the documentation for each of these plugins for install and configuration instructions.
Bonus: There’s a JSHint plugin available for grunt too!
JSHint has become a crucial tool in my development process. It’s saved me so much time by pointing out errors as I make them. I’ve also found that being able to enforce styling conventions has helped me to write much cleaner code.
I hope that this post has given you an insight into how JSHint can fit into your own development process. Take a minute to set up and configure this simple tool and you will never be caught out by trivial errors again.
The post Improving Code Quality with JSHint appeared first on Treehouse Blog.
]]>|
|