it seems almost unthinkable, but the npm registry is having issues.
yup, having some database problems. working on getting back up. sorry.
— npm (@npmjs) January 23, 2014
that can happen?? so what do you do when the main npm registry goes down? it turns out there’s an EU mirror.
|
1 |
npm --registry http://registry.npmjs.eu/ install |
worked for me in a pinch, i’ll have to remember that.
the world of front end development is rapidly changing and with the popularity of node.js, it seems that javascript is creeping up everywhere. one of the misconceptions about javascript is that it is a hacky language by nature and the code is always going to look hacky. another popular misconception is that because javascript is executed in the browser and best practice is to minify your javascript code, it doesn’t matter about maintaining a consistent style within your javascript. sadly, many front end developers believe this and it is these same front end developers who are now experimenting with node.js and writing crappy server side code.
the really sad thing here is that there are amazing tools available that solves this problem. as far as i’m concerned it is a solved problem, the barrier to adoption is very low, and there is no reason not to have style adherence in your code base. what i’m talking about here are static code analysis tools for javascript. these are tools that will analyze your code and tell you where there are potential code smells.
there are two that i use for javascript development: jshint and the google closure linter.
two seems like it may be a little overkill and though both tools do have some amount of overlap, they serve two different purposes for me.
jshint
for me, i use jshint to detect errors and potential problems in my code. i prefer jshint over jslint because it is a little less opinionated (or can be configured to be less opinionated) than jslint. jshint is a good tool to find problems in your code, but it also helps with writing code with best practices.
google closure linter
google closure linter does the same things jshint does, but it also enforce style conventions. this is amazing by itself, but google has gone one step further and they bundled a tool called fixjsstyle with their gjslint app. fixjsstyle will try to fix all of the problems that gjslint finds. this blew my mind. this tool makes style adherence insanely easy. there is no longer any excuse not to conform to the same style…and yes, it is google’s style convention, but i happen to agree with most of what they say.
so great, there are two tools that lints your code for you, but wait, there’s more!
it seems that javascript developers are all gravitating towards using sublime text editor as their IDE. there are two plugins that will lint your code in real-time so that you will never have to run your linters outside of your text editor: SublimeLinter and JSHint Gutter.
so how do you go about doing it? if you’re on a mac/linux system, you do:
Install jshint and create soft link
|
1 2 3 |
npm install -g jshint cd /usr/bin sudo ln -s /usr/local/bin/jshint |
Install gjslint and create soft link
|
1 2 3 |
sudo easy_install http://closure-linter.googlecode.com/files/closure_linter-latest.tar.gz cd /usr/bin sudo ln -s /usr/local/bin/gjslint |
Install Sublimt JSHint Gutter plugin
In Sublime Text: Command-Shift P, Package Control: Install Package
JSHint Gutter
You can optionally configure Sublime to lint on edit or save: https://github.com/victorporof/Sublime-JSHint#automatically-linting-on-edit-or-save
Install SublimeLinter
In Sublime Text: Command-Shift P, Package Control: Install Package
SublimeLinter
Configure SublimeLinter to use Google Closure Linter
Go to Sublime Text 2 => Preferences => Package Settings => SublimeLinter => Settings – Default
Copy the entire file that has been opened here
Go to Sublime Text 2 => Preferences => Package Settings => SublimeLinter => Settings – User
Paste contents into this file
Make the following edits:
“sublimelinter_gutter_marks”: true,
“sublimelinter_mark_style”: “none”,
“javascript_linter”: “gjslint”,
“gjslint_options”: [],
“gjslint_ignore”:
[
110, // line too long
220 // jsdoc supression
]
web development these days is great fun. there are many frameworks that help deal with all of the various browser quirks out there, but the only real true test to make sure that your site works in various flavors of internet explorer is still to run the actual version of internet explorer. sure, the browser mode setting does a pretty good job of getting things right and gives you access to some better developer tools, but sometimes you just need to see it in the native browser.
now suppose that you are developing on a pc and you have one version of internet explorer installed, but what about all of the other versions? traditionally, you’d have to set up virtualpc and make several VMs.
the situation gets more grim when you develop on a mac and don’t really have windows machines available to you. what do you do then what you do is run xdissent’s amazing ievms script which will download, setup, and snapshot VMs for IE6/7/8/9/10/11 right there on your local machine. you’re going to need a lot of hard drive space to install VMs for all of those browsers, but it is quite the handy script.
check it out: https://github.com/xdissent/ievms
ever wanted to see what are all the attached event listeners on a page? if the events were attached using some of the popular javascript libraries, there’s a cool little bookmarklet that will show you visually what parts of your page have event listeners bound to them.
I don’t really expect a whole lot from my shell. Sure, store some aliases, have the ability to do some basic color highlighting for my directory lists, and that’s about it, really. I spend a lot of time in the shell, but I have never really expected the shell to work for me, instead I have just learned to type faster over the years.
But it was just recently that I learned about the fish shell. Fantastically colorful, awesome auto-suggesting auto-complete, a pretty cool way to shorten current working directory, and did i mention that it has some pretty cool color? There’s just a kind of whimsical joy that it brings to working in the command line that I haven’t had in a long, long time.
I wish it was more bash-compatible, I did spend some time converting my .bashrc to its config.fish format, but it was well worth it. Geek out and be colorful.
I’ve gone through the documentation for CoffeeScript, played with some sample code and feel reasonably confident that if I really wanted to, I could write CoffeeScript. That brings me to the next project: a node.js project with CoffeeScript.
It turns out that node.js will allow you to use mixed code fairly seemlessly because the CoffeeScript compiler is written in JavaScript. Simply include the coffee-script module and then include coffee scripts. easy.
Lately, I’ve been playing with a lot of cool, shiny toys and I thought that it might be about time to document my journey as a front end developer. The landscape of a front end developer has changed dramatically over the last couple of years with exciting new technologies which has propelled the web from a collection of web pages to full blown apps.
I have the good fortune of working at a company which has embraced open source and is willing to explore and experiment with the latest technologies. But as an early adopter, one gets to navigate the uncharted territories of use cases that other people didn’t cook up with them open sourced the latest and greatest framework/widget/platform/whiz-bangy thing.
But first, some background: I started as a LAMP developer many, many years ago, before PHP was even en vogue. I was mostly a generalist learning just enough to accomplish the task at hand. System administration, Ops, DNS, Apache httpd, Apache httpd tuning, lighttpd/nginx/thttpd, haproxy…the list just goes on and on. It was only recently that I started to shift my focus and attention to front end development. I am, by far, still quite the novice, but I have a voracious appetite for all things client-side these days and I wanted to document my journey.
Many back end developers (and I was one of them) looked down on front end development. It’s just a bunch of HTML and CSS with some JavaScript, right? It’s tedious work, but not hard work, right? Who wants to bother with that? And worse yet, who actually thinks that this is its own discipline? These are all beliefs I naively held until the fateful day that I made the leap from a back end developer to the front end developer.
It has been a wild ride so far, but it is the most fun that I’ve had in years.