|
Where do you guys find these people? They are awful
|
#
?
Apr 1, 2015 22:09
|
|
|
|
| # ? Jun 6, 2024 11:33 |
|
|
^^^ god they're everywhere yolandi posted:I went with knockout as I wanted something fairly unobtrusive that I could use with all the existing stuff, and its working pretty nicely now, thanks! Yeah, that's why I use it. I can do quick and dirty OR put a little more oomph into it (like separating the ajax calls from the VM as a storage class) without having to bend my will to a framework. PlaneGuy fucked around with this message at 23:08 on Apr 1, 2015 |
|
#
?
Apr 1, 2015 23:06
|
|
|
I have to give a presentation to 40 devs tomorrow on script loading and module patterns. What a cluster-gently caress front-end dev has become, sheesh.
|
|
#
?
Apr 1, 2015 23:21
|
|
|
an skeleton posted:Where do you guys find these people? They are awful Let me tell you about nearly every interview where the candidate can't tell me what this code does: code:
|
|
#
?
Apr 2, 2015 00:11
|
|
|
I really hope that's for junior devs...
|
|
#
?
Apr 2, 2015 00:27
|
|
|
Helicity posted:I really hope that's for junior devs... I wish. It's almost always senior devs or "architects" that hop consulting agencies every year. Yesterday it was a tech manager role. Normally I wouldn't expect much from a manager, but he talked up a big game and literally listed JavaScript first under "primary languages" on his resume. I should find some goons to hire, but I don't want to say where I work after all this trashing 
|
|
#
?
Apr 2, 2015 00:37
|
|
|
So what do the people that you interview think that does?
|
|
#
?
Apr 2, 2015 00:38
|
|
|
not gonna lie, I had to double-check. this scoping is one of the most confusing things for me learning JS (protip: it gets worse in ES6) edit: i think most people get away with it by assigning this to a variable at the scope they want it to be in their mind and forget about it.
|
|
#
?
Apr 2, 2015 00:42
|
|
|
SuicideSnowman posted:So what do the people that you interview think that does? It's always a long pause, lots of staring at the ceiling, and then a bunch of wrong guesses. Almost nobody ever admits to not knowing. I would respect the honesty. PlaneGuy posted:not gonna lie, I had to double-check.
|
|
#
?
Apr 2, 2015 01:27
|
|
|
PlaneGuy posted:edit: i think most people get away with it by assigning this to a variable at the scope they want it to be in their mind and forget about it. Not going to lie, I usually write out a kajillion lines of Javascript (edit: without putting more than a few seconds of thought into the scope), run it, see an undefined error and go "oops" and immediately know I need to go back and add a code:
|
|
#
?
Apr 2, 2015 01:42
|
|
|
PlaneGuy posted:this scoping is one of the most confusing things for me learning JS (protip: it gets worse in ES6) Eh, learning that this is auto-bound in arrow functions isn't as bad as what I learned when porting some code over to Babel, which is that arguments in an arrow function is actually the same as the parent function's: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-arrow-function-definitions-runtime-semantics-evaluation I don't understand why this decision was made, other than to actively gently caress with new coders Thankfully, arguments can be considered deprecated in ES6 anyways, and replaced with spread operator (e.g. (...args) => {...}) abraham linksys fucked around with this message at 01:48 on Apr 2, 2015 |
|
#
?
Apr 2, 2015 01:42
|
|
|
geetee posted:Let me tell you about nearly every interview where the candidate can't tell me what this code does: I had to guess, but at least I guessed right- and I am a senior dev. I would argue that it's a poor interview question, though - because it doesn't really address anything real-world. When I interview devs I want to know they understand flow and logic. Syntax you can look up in a book. The most I would want to see out of a question like this is that if they don't know the answer they know enough to fire up the console in Chrome and check.
|
|
#
?
Apr 2, 2015 01:59
|
|
|
abraham linksys posted:I don't understand why this decision was made, other than to actively gently caress with new coders That's why. They want to remove arguments entirely, but to avoid breaking bc are only doing so for functions defined using the new syntax, and binding the parent context's arguments is what would happen if it was just a normal variable in the containing scope.
|
|
#
?
Apr 2, 2015 02:00
|
|
|
HaB posted:I would argue that it's a poor interview question, though - because it doesn't really address anything real-world. Knowing how this works is pretty important for writing real-world JS in any way other than changing random poo poo until your code appears to work.
|
|
#
?
Apr 2, 2015 02:02
|
|
|
Plorkyeran posted:Knowing how this works is pretty important for writing real-world JS in any way other than changing random poo poo until your code appears to work. I don't disagree, but I'd rather see an actual real-world block of code that exhibits the problem and see if they can figure out what's wrong with it.
|
|
#
?
Apr 2, 2015 02:04
|
|
|
Helicity posted:I have to give a presentation to 40 devs tomorrow on script loading and module patterns. What a cluster-gently caress front-end dev has become, sheesh. You're not kidding. I'm working on a stupid little side project and decided to embrace "modern" practices. It's just a skin for my site. But, I thought I'd use it as an opportunity to put together a build system with asset compilation, use a "package" "manager" (Bower) for front-end stuff, and keep things under version control. I'm trying to do everything with NPM scripts, because after a few days I realized I was spending a lot more time on Grunt than it was saving. For a collection of static pages that I am using to write my CSS, I need the following: 1) Autoprefixer and 2) LESS for stylesheets, along with 3) HTTP-server, 4) live-reload, and 5) watch for live reloading. On top of that, I am using Bower for 6) normalize.css, 7) Font Awesome, and 8) Retina.js. To make that work, I have to maintain a 9) package.json file, which cannot contain comments, because beep boop I am a robot. Bower wants a 10) bower.json too, with its own required version. Luckily, I found 11) versiony-cli so I can automate package.json -> bower.json version synchronization. Of course, I had the audacity of wanting to change where Bower puts its poo poo, so that requires a separate 12) .bowerrc file. And now I have a bunch of junk I don't want to commit so I have to edit my 13) .gitignore file. To save time, I added NPM and Bower poo poo to 14) ~/.gitignore_global. Unfortunately I don't understand git, so I use SourceTree, which uses 15) ~/.hgignore_global. All that for HTML and CSS. It still breaks at the drop of a hat. Watch dies whenever I switch branches because the files are temporarily deleted. Parallelshell is an ugly hack and the live-reload process often dies but doesn't exit cleanly, so the port it uses stays in use until I manually kill the process. (I added a bash script to do that.) Autoprefixer sometimes requires magic comments in my code to tweak behavior. Linters do too, or they want their own dot files. My node_modules directory is over 100 Mb right now. Any time NPM dies, it drops a nice, stinking poo poo of 16) an npm-debug.log file in my project directory. Worst of all, I just tried to hook up a module loader, Browserify (17) and the whole thing fell apart. My choices are to either type out require("../../../../vendor/package/random/git/structure/module.js") or install 18) debrowserify, which never works properly because, surprise surprise, random bower.json files on Github are often broken. I don't know how you people do this professionally.
|
|
#
?
Apr 2, 2015 02:10
|
|
|
I think it distills down a pretty realistic scope scenario to the minimal amount of code.
|
|
#
?
Apr 2, 2015 02:19
|
|
|
I take the last three major production issues, distill them down to the basics, and ask them what they think the code does and if there's anything they would change. Even if they don't identify the problem at first glance I pay attention to their reaction when I tell them, and ask them how they'd deal with it. Busting their brain on syntax stuff is something I only do to gauge their level of knowledge after breaking the ice, or if they're being especially smarmy and showing a lack of respect and I want to see what happens when they're in situations where they don't know the answer. How they arrive at an answer or deal with not knowing the answer is way more interesting to me than rote memorization. I probably make people cry after my interviews 
|
|
#
?
Apr 2, 2015 02:54
|
|
|
Kobayashi posted:I don't know how you people do this professionally. Doing all that for simple HTML/CSS is probably overkill. On the other hand, I can't imagine trying to organize a large application with 100s of .JS files without something like Browserify would be more of a nightmare than spending a few hours setting it all up to begin with. Since setting my application up this way in the beginning I've had to do very little to maintain it. I simply make code changes and run a Gulp task and I'm done. All my external libraries are contained in a separate minified JS file so unless I'm adding another external library I don't touch it for months at a time. Yes, it was a little daunting in the beginning getting it all working together but after the initial setup it makes continued development of my application a breeze. Of course I'm using .Net/IIS for all the backend stuff so my application requires a little less fussing around than a person that also needs to build server side JavaScript.
|
|
#
?
Apr 2, 2015 02:59
|
|
|
geetee posted:It's always a long pause, lots of staring at the ceiling, and then a bunch of wrong guesses. Almost nobody ever admits to not knowing. I would respect the honesty. To be fair, that type of question is notoriously difficult for clever developers to answer because they're assuming there's some catch in the question. In other words it's not that they don't know what the answer should be, it's that they then doubt their own thoughts on it.
|
|
#
?
Apr 2, 2015 03:24
|
|
|
The Wizard of Poz posted:To be fair, that type of question is notoriously difficult for clever developers to answer because they're assuming there's some catch in the question. In other words it's not that they don't know what the answer should be, it's that they then doubt their own thoughts on it. I'm very sensitive to these types of concerns because I'm terrible at white boarding exercises and being put on the spot. I make it extremely clear up front that there is no catch, and I'm not concerned with the exact output (since it varies with environments). I just want to know what "this" refers to in this context. This is not some ha-ha-you-missed-the-trick-fizz-buzz puzzle or contrived example you'll never see in reality. Unless you're just farting out simple jQuery DOM manipulation, I don't understand how you can get by without knowing this kind of stuff.
|
|
#
?
Apr 2, 2015 03:58
|
|
|
geetee posted:I'm very sensitive to these types of concerns because I'm terrible at white boarding exercises and being put on the spot. I make it extremely clear up front that there is no catch, and I'm not concerned with the exact output (since it varies with environments). I just want to know what "this" refers to in this context. This is not some ha-ha-you-missed-the-trick-fizz-buzz puzzle or contrived example you'll never see in reality. Unless you're just farting out simple jQuery DOM manipulation, I don't understand how you can get by without knowing this kind of stuff. Fair enough, if you're upfront about the "no-trickery" thing then I agree that it should be a fairly straight forward exercise for even a barely competent JS dev.
|
|
#
?
Apr 2, 2015 04:25
|
|
|
I've never really met anyone good at white boarding fwiw interviewee or interviewer because it's designed to suck I think. I just like seeing people be able to a) have thoughts on how to solve something b) express their thoughts to a real live human without relying on autocomplete and syntax highlighting. Both of those are skills that are much more valuable than perfect syntax use.
|
|
#
?
Apr 2, 2015 05:40
|
|
|
Helicity posted:I've never really met anyone good at white boarding fwiw interviewee or interviewer because it's designed to suck I think. I just like seeing people be able to a) have thoughts on how to solve something b) express their thoughts to a real live human without relying on autocomplete and syntax highlighting. Both of those are skills that are much more valuable than perfect syntax use. Agreeing with this. I think the problem with whiteboarding code is that you are starting out of "context" so to speak. Writing longhand isn't the same as typing for starters, so after years of typing everything I know that handwriting is something I actually have to think about to do. If I have someone whiteboard during an interview I usually tell them straight out to just talk me through using pseudocode, so I understand their logical approach. I realize I am violating my own point about "real world" examples, but if someone isn't nailing any real-world issues, my softball question is "talk me through how you would write a function to determine if a string is a palindrome". If they don't start immediately talking about a for loop, or checked the end of the string vs the beginning, it's basically over with.
|
|
#
?
Apr 2, 2015 15:38
|
|
|
HaB posted:Agreeing with this. I'm the same way. I don't want to hire someone who will write perfect code on a whiteboard because it's pretty obvious that they practiced for a whiteboarding section and there's nothing there that actually illustrates skill. I'd much rather have a candidate that mixes language conventions and generally writes pseudocode while whiteboarding as long as they talk it through. Part of an interview is presenting your case to the people who are interviewing. I want someone to present the answer rather than just writing it out.
|
|
#
?
Apr 2, 2015 15:55
|
|
|
Blinkz0rz posted:I'm the same way. I don't want to hire someone who will write perfect code on a whiteboard because it's pretty obvious that they practiced for a whiteboarding section and there's nothing there that actually illustrates skill. Honestly, as far as interviews where I was the interviewee go, my favorite ones have been actual coding tests: Here's a Service. Write a small app that does ________. You can google, you can use a book, whatever. I prefer this because that's how I would ACTUALLY code. I think for senior devs this is good because I have met a LOT of devs who can fix things, add on to things and modify things, but simply can NOT start with a blank page.
|
|
#
?
Apr 2, 2015 16:16
|
|
|
geetee posted:I think it distills down a pretty realistic scope scenario to the minimal amount of code. It's a good test. Keep it. I'd rather watch a guy give the "oh poo poo. this." look and acknowledge how tricky it can be (and hopefully still be right) than watch a guy pour over code looking for the semicolon you didn't leave out.
|
|
#
?
Apr 2, 2015 16:48
|
|
|
HaB posted:so after years of typing everything I know that handwriting is something I actually have to think about to do. To be honest, I have a difficult time handwriting anything nowadays relative to when I was in, say, highschool in the early 90s. I find myself switching from small caps to lower case mid-sentence, forgetting how to write a letter in cursive, and generally there's just a lot more of a cognitive load with getting my thoughts from my head into the medium than when I'm typing.
|
|
#
?
Apr 2, 2015 16:58
|
|
|
HaB posted:Honestly, as far as interviews where I was the interviewee go, my favorite ones have been actual coding tests: My first "real" job gave me a test similar to that and I really thrived on that. I really appreciated that the company had a very broad type of "test" and that they gave the information to me about a week in advance. It totally took the pressure off me and made the whole interview experience a positive one.
|
|
#
?
Apr 2, 2015 23:48
|
|
|
Whats the go-to React/Flux tutorial for someone entirely new to it? Looking to convert a largish, multi-page Angular app.
|
|
#
?
Apr 3, 2015 17:04
|
|
|
more like dICK posted:Whats the go-to React/Flux tutorial for someone entirely new to it? Looking to convert a largish, multi-page Angular app. My co-workers said the official Flux tutorial was good. They didn't like the official React tutorial, because it was too "copy, paste, refresh, repeat". I personally got more mileage out of it because I was building something else, and just using the tutorial as a general guide to the basics.
|
|
#
?
Apr 3, 2015 17:46
|
|
|
I have two webpack configuration files - one to run over code for the server, and one for the client. At the top of a javascript file which is shared for both server and client I have: code:With the server config file, I could also do this again, however I want webpack to just ignore the "./test.less" module, so I don't use the extract-text plugin. Unfortunately the following line is generated in the output js for the server config, which will cause an exception when run: code:Looking around I have found recommendations to use IgnorePlugin or NormalModuleReplacementPlugin, however I can't get these to work. Inside these plugins they hook into a "before-resolve" event, however "./test.less" is never passed into it...
|
|
#
?
Apr 5, 2015 03:36
|
|
|
Dreadrush posted:I have two webpack configuration files - one to run over code for the server, and one for the client. I'm not sure if this will work, but maybe you can tell webpack to use the null-loader for .less files? edit: VVV Awesome! geetee fucked around with this message at 19:08 on Apr 5, 2015 |
|
#
?
Apr 5, 2015 04:53
|
|
|
geetee posted:I'm not sure if this will work, but maybe you can tell webpack to use the null-loader for .less files? Thanks - this works just fine 
|
|
#
?
Apr 5, 2015 06:51
|
|
|
Kobayashi posted:I don't know how you people do this professionally. An ec2 micro instance has barely enough memory (1GB) to run "npm install ember-cli" I had some services running in the background and it failed ("Killed" was the extent of the error message). I stopped the services (which used maybe 100-200 MB of memory) and npm was able to finish after a long-rear end time. There was some jobs=1 configuration option I put somewhere because some guy on the internet recommended it, but this being javascript development, I sure as hell couldn't find any documentation for it.
|
|
#
?
Apr 7, 2015 12:59
|
|
|
Kobayashi posted:You're not kidding. I'm working on a stupid little side project and decided to embrace "modern" practices. It's just a skin for my site. But, I thought I'd use it as an opportunity to put together a build system with asset compilation, use a "package" "manager" (Bower) for front-end stuff, and keep things under version control. I want to quote this whole thing because I've never seen such a perfect distillation of why front-end development just plain sucks right now. We're in an awful, awful period but I have faith that once these ideas are well cemented into place we'll start to get good tooling for them. The concepts as they apply to front-end web development are relatively new and untested and we're caught in the middle while it all shakes out.
|
|
#
?
Apr 8, 2015 05:26
|
|
|
I can't wait to see how the future simplifies things. I have trouble imagining it now because of the full blown Stockholm syndrome.
|
|
#
?
Apr 8, 2015 06:49
|
|
|
To help you imagine it, do a project where you only use NPM packages and browserify or webpack. It's not great, but it cuts down some of the bullshit when you don't have to work with grunt and bower and gently caress all.
|
|
#
?
Apr 8, 2015 07:06
|
|
|
I must be in full-blown Stockholm syndrome right now because I'm considering switching from JSHint to ESLint and I'm about to do that in the project's Gulpfile. Related question: You guys think the ES6 modules could help us un-gently caress front-end dev a tiny bit? I'm on the fence about using that plus Babel or Traceur to make that poo poo slightly retro-compatible.
|
|
#
?
Apr 8, 2015 07:14
|
|
|
|
| # ? Jun 6, 2024 11:33 |
|
|
Yeah, but it results in a deep wasteful dependency tree, what with node_modules just being a giant recurse of dependencies. I'd really like to see someone take a stab at reducing that, I mean, we have semver, there some foundations there for it. Edit: for browserify I mean, just makes for a massive app-bundle if you're not careful.
|
|
#
?
Apr 8, 2015 07:17
|
|
