rmurphey3

Front-End Systems Engineer | Indeed.com | Austin, TX or Seattle, WA (ONSITE)

Join a small, talented team that’s focused on radically changing how we approach front-­end application development at Indeed. As an early team member, you’ll have significant input and influence on projects like a shared component library for UI development; tooling to make it easy for engineers to spin up and build new client­-side applications; common systems for measuring and monitoring application performance; and more. You’ll evangelize front­-end best practices to teams around the world, help them incorporate those practices into their development workflow, and take your learnings back to the front­-end systems team to develop new tools. You’ll also help identify and mentor individual developers throughout the organization who will be the ultimate source of the front­-end systems team’s success. Your work will increase the velocity of every developer who touches client­-side code; it will impact hundreds of millions of job seekers around the world; it will — quite literally — change the face of Indeed.

---

The interview process will include a screening exercise and, for successful candidates, a day of on-site interviews. The process will focus specifically on identifying candidates with the required technical and communication skills necessary for the role; expect to talk about vanilla JS, maintainable CSS, client-side performance, testing client-side applications, designing and developing front-end systems to be used across projects, and communicating effectively with technical and non-technical audiences.

---

More information: http://www.indeed.jobs/career/JobDetail/Front-End-Engineer-S...

Comments like this make me so excited to write more posts. Thanks.

Thanks for the suggestion. Look for it in a future version!

I won't address the rest of your comments, but please note that I said "tools like UglifyJS or Closure Compiler" -- if the RoR asset pipeline is taking care of this for you, then good! The point is that good front-end devs should be aware of the need for tools that address the various high-level topics I listed -- I just mentioned some tools that fill those needs for me.

My fear with doing that is that if the functions file is separated from the tests file, then it becomes difficult to see at a glance what the function needs to do in order to make the test pass. That said, I agree that what you're supposed to do could be more clear -- would you care to open an issue so we can discuss it on the repo?

I definitely want to add more tests to the set -- if you have ideas for other tests, please open an issue or a pull request on the repo!

Thanks for the great feedback -- it occurred to me that people could simply hard-code the "right" answers into their function. However, if I am using this to assess a candidate, I plan to actually read the code that they write :) And if a person is using this to assess their own skills, I trust that they know that an answer like the one above hasn't taught them anything.

Your guess about why I chose something that involves a little bit of setup is right on target, too. Being able to follow the instructions in a readme and get a simple project like this set up is a key skill to have, too.

The exact set of skills that one needs in order to do one's job will of course vary from person to person. What I have tried to point out in this post is that these topics are ones that anyone who calls themselves a front-end developer will need to be familiar with; if they are not familiar with them, then they risk being unable to keep up with the new information that is being shared about the front-end dev profession. This is based on my observations as much as my beliefs -- the set of things that you're expected to know in order to actively participate in the open-source front-end dev community is growing and changing, and this is my attempt to catalog those things in a way that I wish someone had done for me in the past.

I hope I gave due credit to the possibility that part of what's changed is me when I said in the next sentence: "Maybe it’s the result of people starting to take front-end dev seriously, maybe it’s browser vendors mostly getting their shit together, or maybe it’s front-end devs – again, myself included – coming to see some well-established light about the process of software development."

I do think the profession of "front-end development" has grown up a whole lot in the last couple of years. There have been front-end pros since long before I was even in the business, but I think the profession as a whole is being taken more seriously, and a set of baseline expectations for people in the profession is solidifying.

You are right, all of this can be done via makefile ... assuming you know how to set up a makefile and take the time to do so. Part of the goal of grunt, as I understand it, is to make it so developers have fewer excuses for not doing this -- setting up a project of a certain type becomes a one-liner. To me, that feels a whole lot simpler than suggesting that developers create the makefile you propose. More often than not, such suggestions result in projects that have no makefile at all -- and thus no tests, no minification, no linting, etc. If grunt helps developers integrate those best practices more easily, that feels like a good thing to me.

Much love for Alex Russell and for efforts to move the web forward as a serious development platform, but this was among the more content-free stories I've read in a long time. If you'd like to actually learn about "model-driven views," the component system the article mentions, head over to http://code.google.com/p/mdv/.

Yes, the point of the post was that it had a lot more to do with being a kid with a computer than with being male or female. The point of the title was that it was a story of ... a girl and her computers :)

It would have been great to see these improvements contributed back to PhoneGap/Cordova, which has an extremely permissive license and whose code is open-source. As it is, trigger.io comes with a restrictive license, I have to create an account to use it, I can't see the code, and they mandate that I include their branding with any free use of their product. Yay.

I saw a presentation on Enyo at CapitolJS, where I also announced that Toura would be open-sourcing Mulberry, and indeed, there are a lot of similarities. I too would like to get some clarity about what HP intends to do with it :)

Basically, Toura Mulberry uses PhoneGap as a wrapper around a "single-page" application that's powered by the Mulberry JavaScript/HTML/CSS framework. The command-line tools in Mulberry help you quickly scaffold the structure, content, and customizations for your app. The "builder" portion of Mulberry takes your content, prepares it to be consumed by the JS/HTML/CSS framework, and places it inside a PhoneGap project template so that it can be "built" for testing and submission to app stores.

This is all explained in a bit more depth here: https://github.com/Toura/mulberry/wiki/An-Overview-of-the-Mu.... Hope this helps :)

I learned a whole lot about Carl Fisher researching my Modern JavaScript presentation for JSConf (http://blip.tv/jsconf/jsconf2011-rebecca-murphey-5478159 & http://www.slideshare.net/rmurphey/modern-javascript). He and his fellow Good Roads enthusiasts have a lot to teach us for sure.

There is a screencast demo at http://toura.github.com/mulberry/ -- the code has not yet been released (soon!) so there unfortunately isn't yet any demo code to share, but a demo will be part of the release when that happens.

In a nutshell, Mulberry is more opinionated than Sencha -- by being opinionated, it makes it much easier to get an app up and running without worrying about the underlying architecture of the app.

Mulberry expects that you're creating a content-centric mobile app, and so it expects you to define your application in terms of nodes that have assets associated with them -- assets like images, videos, audios, feeds, and data. Nodes are the building blocks of a single-page application that Mulberry creates inside a PhoneGap wrapper. Nodes are displayed with templates, and templates consist of components. You can use the components that come built-in with Mulberry and write very little code; however, you can also create your own components to add custom functionality to your app -- this is where Mulberry's true power lies (see the blog post for details).

Speaking more generally, Mulberry is aimed at developers who aren't interested in spending time on the low-level architecture of their application -- things like data stores, views, etc. Instead, Mulberry is aimed at developers who want to create their content, create their assets, create their data, and then write simple JavaScript and CSS that presents that content and data in the ways they need.

Hope this helps :)

There is a total of 387k of JS (minified and excluding phonegap.js), but it's important to remember that all of the JS is shipped as part of the native app, so it all lives on device -- none of the JS is shipped over the wire except when the app is downloaded.

We could improve this number, but so far we haven't found that it significantly affects application performance. Mulberry is very conscientious about things that are more likely to affect performance, such as memory leaks as a result of improper component teardown. Apps with incredibly large data sets may experience slowdowns, but there are ways to mitigate that as well. Bottom line: in our year of use of the system, we've been fairly happy with performance, even with 387k of JS>

Since this was a rewrite of a system that just consumed the output of the CMS, the migration was not awful. One day, we just started exporting the new data format and using the new system to create apps. Users continued to use the same CMS to build their applications -- the CMS was the target of many improvements, but didn't get replaced wholesale. Thus the rollout of the new system wasn't really impacted by the number of users of the CMS. Though the Dojo/PhoneGap system in reality exists pretty independently from the CMS, you might think of it as the presentation layer of the CMS, so this rewrite really targeted a (significant) piece of a larger system.

The old system has been entirely decommissioned, and the team works entirely on the new system now.

It's just a video tag for me in Chrome.

One other question: are there Backbone examples small enough to digest but large enough to be more authentic than a to-do list? This is where I struggle to come up with good teaching examples -- a whole real-world app is simply too much to take in when one is trying to transition to a JS app mindset (and of course the code is usually minified/obfuscated), but examples like to-do lists are so simple that they don't show how a tool addresses actual real-world problems.

Thank you for these :) I admit the last time I went hunting was a while ago, it's good to see so many more. For various reasons, the templated widget part of Dojo made it the right choice for my current project, but I strongly suspect a Backbone project will be in my future, either for fun or profit.

I appreciate your feedback and understand that previous posts of mine have framed this as a jQuery vs. Dojo debate; I tried particularly hard not to do so in this post, and I think you'd be rather hard-pressed to say that this post was a "jQuery vs. Dojo" diatribe. Yes, it linked to my Berlin slides, but that's simply because a post in response to them is what got this whole post percolating in my head to begin with.

The fact is, though, jQuery and Dojo are the two libraries with which I am quite familiar, and so they are the two libraries I am most able to compare. Having used both, it is easy to see the weaknesses of ... both! I truly believe there is a "jQuery divide" -- there are people who think jQuery is what there is to know of JavaScript, and that it can solve all of their problems; then there are the people who know there is more, either because they have always known or because, like me, they've discovered it through some painful mistakes.

What I am asking for, in this post and in my Berlin talk, is for the people who know there is more to take some responsibility for bringing the others up to speed, to show people what can be done if you leave behind the "get some elements, do something with them" mentality.

None of this is to say that jQuery is not a useful tool, and the right tool in so many situations! I have used it, I have contributed to it, I have taught it, I have recommended it. Its API is seductive and its API is a huge contribution it has made to the JS landscape. The point, though, is that it's just an API -- an API that can be and has been be readily replicated. My experience has been that other libraries' APIs can have their own elegance, once you get used to them. The problem is that the appeal of jQuery's API I think is what can lead people to keep approaching problems in a DOM-centric way long after it makes sense. I do not fault jQuery for this, but I think as a wider JavaScript community we do well to discuss -- and not in an us v. them way! -- other viable approaches that exist.

Finally: Backbone is a viable entry in the field, and I am eager to see more complex examples (to-do list applications fall far short of this) that use it. I haven't used it personally, but I mostly like what I see and have heard good things about it. Unfortunately it had just come out right before my Berlin talk, and while I may have mentioned it in my actual talk, it isn't in the slides. (That said, I do cringe a tad that its examples suggest (http://documentcloud.github.com/backbone/#Model) that a "Sidebar" is a thing that should be a model.)

As a speaker, let me just say that I have yet to figure out how to handle this. When I'm presenting, I want people listening to me, not reading the slides. When people are consuming the slides online afterwards, they can quickly get misconstrued without the context of my spoken words. All of that said, I'll add a link to the video from the blog post :)

I'd encourage you to bear in mind the original audience of the presentation: the very small number of experienced JavaScript developers who managed to obtain a ticket to the 2010 JSConf.eu in Berlin.

The goal of this presentation wasn't to teach people how to write good JavaScript -- many of the people in the room that day can and do write circles around me. Rather, the goal was to urge them, the experienced JS devs who are inventing the answers to these questions, to take seriously the need for creating exactly the information you point out to be lacking, and to be intellectually rigorous and honest in discussions of various solutions.

I'd suggest that you pay extra attention to the presentation starting at slide 40, and especially to what I said on slide 60: "Sharing what we know is as important as making new things." That, in a nutshell, was the message I sought to convey to the audience in October.

I can't speak to what else you missed or didn't miss, but you do seem to have missed that he is a she, so ...

Backbone.js came out just a couple of weeks before I gave this talk in October 2010, and I just hadn't had time to look at it enough to feel comfortable mentioning it. It is definitely a powerful tool for bringing structure to an application, and I'd certainly mention it if I were to give the talk today.

I think this post is neither trolling nor calling on people to blindly switch to Dojo. It is pointing out a thing I see over and over and over again: people choosing jQuery for tasks to which it is simply not suited. Yes, if you know what you're doing you can make it work -- Alex Sexton makes this argument quite well in his post "On 'Rolling Your Own' Large jQuery Apps" (http://alexsexton.com/?p=106).

This post asks developers who blindly choose jQuery, based on its popularity and an often-misguided sense of self-assuredness, a straightforward question:

"Tell me how, exactly, you plan to solve these problems you haven't even thought about yet? If you proceed blindly with jQuery, then by the time you think about them, you will be effed. So, maybe you ought to ponder, for a solitary moment, that there might be things you haven't thought about yet, and consider a toolkit that's thought about JavaScript app development questions for years, rather than a library whose competencies are still and painfully limited to DOM, Ajax, events and effects."

I applaud the people who answer this question competently with jQuery as a base. What I take issue with is the people who aren't willing to consider for a second that, for all its popularity and simplicity, jQuery might not be the right tool for every JavaScript job under the sun.