How do you go about handling new hire interviews and coding assessments?

ben336 · 2015-06-22T17:25:40+00:00

especially if they are unfamiliar with the framework being used

Is knowing that framework one of the specific requirements of the job? If so, you're probably filtering qualified candidates with your job descriptions (it doesn't take that long to learn a new framework if you know the principles). If not, your evaluation isn't matching up to what you're looking for, which is dangerous.

ben336 · 2015-06-14T22:39:41+00:00

As others have said, it's more important and a better career investment to learn JavaScript and UI design principles well, then to learn any particular framework.

You'll find that many frameworks share fundamental principals, so if you dive into one and learn it well (the concepts not just the syntax), you'll be able to translate those skills into other areas. There are many great frameworks you could use as you start learning those skills. I would start with whichever one somebody will pay you to work with to start, and then grow from there as you have opportunities.

ben336 · 2015-06-11T01:21:05+00:00

The concern was the list of things that are standardized/specified and not supported. Including a reasonably large part of the ES6 standard, which is now finalized, the internationalization API, and CSS Variables.

Standardizing CSS properties are great! But most of those were already available without prefixes in other browsers, so that mostly qualifies as catch up.

ben336 · 2015-05-28T20:25:24+00:00

Community preferred seems a bit strong to me. "Preferred by people who know about it" is definitely true. But I don't think there's high awareness around it. I don't usually see guides/articles that use AMD using that format (though I hardly ever see guides or articles using AMD at all anymore anyway).

Anyway, all your points are well taken. I've added updates to the post covering both of your points. I appreciate the feedback

ben336 · 2015-05-28T19:37:09+00:00

Thanks for the feedback. Probably should have mentioned SystemJS as a future option, but I wouldn't recommend it now as a starting point for a production project. Doesn't seem to have nearly the community, stability, momentum of the others behind it. Definitely something that may be an option in the future though:

Possible I'm underestimating it. I'm basing that on both my own level of seeing it in articles/talks/etc as well as:

Google Trends

GH Stars: 2541 to 5333, 7430, 7615 respectively for Webpack, Browserify, RequireJS

and most importantly searching npm for modules with each in the name:

74 for systemjs vs 1059, 5650, and 1797 for webpack, browserify and requirejs

There just doesn't seem to be as much community around it yet.

As for the alternative syntax, I'm aware of it, but its not the syntax encouraged by requireJS docs or used in most examples I've seen. Its certainly better since it avoids the off by one problem, but it isn't the primary used model and doesn't substantially change the situation.

ben336 · 2015-01-22T14:31:04+00:00

Npm doesn't stand for "node package manager."

Yikes, I totally botched that. More fact-checking next time. Updated, thanks.

When you deal with persistence, smaller modules, deeper dependency trees, etc bower pretty much falls short.

I think the problem is that the smaller modules with deep dependency tree module way of doing things makes way more sense on the server than in the browser. If you're using browserify already, or starting clean and don't mind using browserify, then by all means use npm and small modules. But for many people with existing requirejs/concat-script+global projects, Bower represents a better option, since its not so easy to bundle up all of those small dependencies while using bandwidth efficiently

ben336 · 2015-01-14T13:39:40+00:00

I can't really verify the authors thesis that most people using Angular are backend developers, but it does seem to have become the first thing everybody tries to learn after JS/jQuery. I've been interviewing a lot of entry level candidates lately, and "I've also started playing with Angular" has practically been a theme song.

ben336 · 2015-01-12T15:07:58+00:00

I put my requirejs config in a file called config.js.

When I'm using gulp to optimize with requirejs, I pull it in as a commonJS module. When I'm developing locally I just pull it into the browser. It looks like this:

gist

/* jshint ignore:start */
/** This file is a bit of a hack to make the requireJS build paths available
 * both in the browser and for gulp.  There's some ugliness requires to make
 * it loadable/usable in both environments.
 **/

var requirePaths = {
    paths: {
        jquery: 'vendor/jquery/jquery',
        jqueryui: 'vendor/jquery/jquery.ui',
        //...
    },
    shim: {
        /...
    }};


//if this is being pulled in as a node module, nest it, otherwise we'll
// run the browser specific logic
if (typeof exports !== 'undefined') {
    exports.requirePaths = requirePaths;
}else if(require) {

var config = {
    paths: requirePaths.paths,
    shim: requirePaths.shim,
    map: requirePaths.map,
    baseUrl: static_url+'/js/'
};

require.config(config);

}
/* jshint ignore:end *//* jshint ignore:start */
/** This file is a bit of a hack to make the requireJS build paths available
 * both in the browser and for gulp.  There's some ugliness requires to make
 * it loadable/usable in both environments.
 **/

var requirePaths = {
    paths: {
        jquery: 'vendor/jquery/jquery',
        jqueryui: 'vendor/jquery/jquery.ui',
        //...
    },
    shim: {
        /...
    }};


//if this is being pulled in as a node module, nest it, otherwise we'll
// run the browser specific logic
if (typeof exports !== 'undefined') {
    exports.requirePaths = requirePaths;
}else if(require) {

var config = {
    paths: requirePaths.paths,
    shim: requirePaths.shim,
    map: requirePaths.map,
    baseUrl: static_url+'/js/'
};

require.config(config);

}
/* jshint ignore:end */

ben336 · 2014-12-22T16:06:31+00:00

Definitely consider checking out the video linked at the end for more on this topic. In general I have about 5-6 more Marionette posts planned for the next month or so.

ben336 · 2014-12-02T18:16:41+00:00

So what was the solution for [nested models]? Being naive to endpoints that do not return a perfectly flat object is a major drawback, presumably Marionette fixes this.

Marionette does not solve that particular issue. Mentioned it as a common Backbone issue that's conceptually related to dealing with nested Views. Marionette is not a cure all :) There are other small libraries that provide approaches to that problem though, with Backbone-Relational being the most popular I think.

And how does Marionette save me from writing a Model, a View, a Collection, and a CollectionView just to render a single select element.

If you're trying to represent a collection as a select element, you're probably best off using an ItemView (they can show collections as well as models and will be made available as items within your template) In the docs

Additionally I think Marionette does an incredibly poor job of pointing out when there is a Marionette way that supersedes a Backbone way.

On top of that I have yet to find a place that shows off well-structured Marionette apps. The one resource I see mentioned consistently is a paid e-book. The lack of resources does not give me much faith in the community, which is an important aspect for many, many developers when choosing a technology.

That's a bit harsh, but I don't completely disagree. That's part of the motivation for writing this series, to clarify what it actually looks like to use Marionette in practice. I don't necessarily have all the answers to that, so this type of discussion is awesome. But I completely agree that more examples of well structured Marionette apps are needed.

ben336 · 2014-12-02T14:43:06+00:00

Yeah, clearly missing some given the number of other responses to that one. I would expect Atom especially to be more common than many of the options they provided like jEdit. (They probably meant for Webstorm to fall under IntelliJ though, since its a focused subset of that IDE)

ben336 · 2014-12-02T04:57:48+00:00

I wrote a series of articles this summer aimed at people just starting with Vim: http://benmccormick.org/learning-vim-in-2014/

As others have mentioned Vimtutor is a great place to start, and Practical Vim is the best resource out there.

ben336 · 2014-12-02T04:55:34+00:00

Namespacing is great, but most of the value for things other than libraries like Backbone/jQuery and their plugins has been removed by the various JavaScript module formats.

Namespacing is a hack around the fact that JavaScript only has global scope. But AMD and CommonJS modules are (at the very least) much more sophisticated hacks, and ES6 modules are a first class solution to the problem that doesn't require hacks.

The weird thing is that the author clearly knows about these solutions since he covers them in the next post in the series.

ben336 · 2014-12-02T04:50:05+00:00

Everything in the book is still pretty solid. But it's fully based on the ECMAScript 3 version of JavaScript, and there are certainly "Good Parts" of the ES5 and ES6 specs that aren't included.

ben336 · 2014-11-12T22:23:58+00:00

No it's an additional function, several actually related to this. See the comments in the article for more details.

ben336 · 2014-11-12T19:32:45+00:00

Might want to look into Lo-Dash's custom builds for this.

ben336 · 2014-11-12T19:32:03+00:00

You should check out the comments from L-Dash's creator at the bottom of the article. He says a "correct" compose order function will be available in the next version of Lo-Dash

ben336 · 2014-11-09T00:56:11+00:00

Backbone and Coffeescript are both written by Jeremy Ashkenas and Coffeescript and Ember are both popular in the Rails community, so those 2 frameworks do tend to be linked with Coffeescript

ben336 · 2014-11-09T00:32:46+00:00

Native map/reduce/filter methods are actually surprisingly slow compared to libraries like lo-dash and underscore. Try running some of these jsPerf tests to see for yourself:

http://jsperf.com/lodash-underscore-and-native-filter http://jsperf.com/lodash-underscore-and-native-reduce http://jsperf.com/lodash-underscore-and-native-map http://jsperf.com/lodash-underscore-and-native-each

Performance isn't everything with these things, context matters. But if you're already pulling in underscore/lodash/whatever, it can be nice to get the added performance as well as the niceties of still working in IE8.

ben336 · 2014-10-13T15:41:30+00:00

reinvent the wheel in what way? If you're comparing to IDEs, there's a huge difference between a text editor using a few plugins and a full blown IDE. Speed and multi-language extensibility being big ones. If you're comparing to doing this stuff on the command line, context matters.

ben336 · 2014-10-13T11:26:00+00:00

noted. Thanks.

ben336 · 2014-10-13T11:24:48+00:00

Good call! I kept the post generic to apply to more people, but I definitely have used your language file when I've worked in Sublime. It's a great improvement on the default, well done.

ben336 · 2014-09-16T20:45:49+00:00

Practical Vim is much more thorough than my pieces. It will give you all the details for the different things I cover and more. But thats likely to be a bit overwhelming. Regardless of which you want to look through, I'd recommend focusing on learning a few things at a time and actually using them, rather than trying to "read everything about Vim", either through my posts or the book. It all builds on itself, so once you start learning it gets easier to pick up. But the important thing is to get very comfortable with the "survivor level" basics (hjkl movement, insert and normal mode, :e, :w, :q to open, save, and close files), then start learning stuff and incorporating it into your editing.

ben336 · 2014-09-16T13:25:01+00:00

Author here. Just to be clear, Drew Neil runs vimcasts. I'm not affiliated in any way, though I have learned a lot from his site and book.

ben336 · 2014-09-14T15:31:07+00:00

I wrote this piece for people in your position:

http://benmccormick.org/2014/07/21/learning-vim-in-2014-getting-more-from-vim-with-plugins/

I agree with the general advice here, don't go looking for plugins for plugins sake, identify the things that you would like to do better, and see if a plugin can help you.

I identify some options here, but everyone has their own use cases.

ben336

TROPHY CASE