neurotech posted:

Can anyone share some good examples of resumes that they've seen? I'm particularly interested in hearing from people who hire web designers and developers. If not, any suggestions on where I could find some good examples?

Horn posted:

I have a react question that I've having a hard time googling and I'm hoping you fine gents could help me out. I'm writing an app that displays data, some of which is html. I've been using __dangerouslysethtml and things have been great (its scrubbed serverside). However, I'd like to replace some of the HTML with custom controls. IE someone might have a post that has something like <span>I love <span class="blue">react</span> <img src="www.facebook.com/react.png">. Is there a way to parse HTML and get back a collection of react components? For example, I'd like to be able to replace the img tags with a custom component.

All of this is loaded from a server so I don't believe I can use the clientside JSX renderer but I'd love to be proven wrong.

Helicity posted:

I've done probably two dozen interviews for interns up to architects in the last year. I look to hire people that are competent enough to not break poo poo requiring me to deploy code at 3am, work well on the team and with other people, and want to learn/get better. The last one is probably what I look for most.

1) Keep it short and relevant - two page resumes annoy me, three page resumes piss me off. I love one page resumes because it says to me that you value my time and you can say things succinctly and get to the point. I will ask about anything I'm interested in that you didn't put down.
2) Don't exaggerate - if you put down "C# (expert)" I will loving grill you on minutiae about memory allocation on the stack and other obscure things that I barely remember myself. If you say "I'm a lovely developer, but I'm less lovely every year" that's the perfect answer in my mind. Don't put down things that you've tried once, put down things that you have used at least several times but preferably on like a weekly basis at the least.
3) Be prepared to talk about poo poo you've done and problems you've solved. I don't care about whiteboarding or trivia (more on that later) - I care what problems you've faced and how you've solved them because it's unlikely you'll never need to implement a bubble sort or the fibonacci sequence in the real world. I don't care about "leading a team on 100 projects that created full stack synergy across silos blah blah blah". Can you make poo poo? Can you see problems and think of elegant solutions?
4) I love when people have personal Github pages even with stuff no one contributes to or personal sites with custom built stuff. I think I've hired everyone who said "I had a need, so I built this thing, here is what I built". That's way more useful to me than asking you to whiteboard something.

Regardless of what I said above, I usually do ask some trivia type questions and have people whiteboard. I do this to gauge their real world experience, their familiarity with their toolset, and see how they react when they don't know something or have a clean slate and no IDE to help them. Since my line of work is all about serving up lots of web pages using lots of services I love asking about caching, concurrency, and aggregation.

edit: I personally don't get hungup on which package manager you use or which MV* framework or whatever you picked. That's cool if you like Angular, Browserify, node, and LESS. I expect that you can verbalize your reasons for picking various aspects of a stack and also that you're happy to use something else if your personal preference isn't the right thing for the project, though.

obstipator posted:

I completely agree that motivation to learn is the key determining factor in whether or not I want you on my team. The last two guys that made it onto my team were junior guys that showed that they're interested in learning. Linking your github that shows you are interested in frameworks or solving problems or just plain contributing to things will prove that you would enjoy the job and are looking to improve, so in my eyes it is safe to assume that you won't end up like some slacker that does the bare minimum.

Maluco Marinero posted:

In


Inlining components to render really depends on your use cases, what goes in what. What you could do is one of two things:

Have a data structure which separates blocks of html and components, iterate over it, and keep the components as part of the render structure ie

code:

[{
  'type': 'html',
  'content': '<span>React is good</span>'
}, {
  'type': 'componentName',
  'props': {}
}]

This would require a wrapping element around each section of raw html, which may not be ideal.

Alternatively, render the lot as dangerous HTML, with intended components rendered like:

code:

<div data-component="componentName" data-props='{"inline": "json"}' class="reactComponent"></div>

Then after the component updates with the HTML, you iterate over it and mount components directly on instances of .reactComponent - however you'll lose those bindings every time the HTML needs to change so that may not fit the needs.

First approach is probably better if you can make it work.

Thermopyle posted:

I just spent a few hours doing something that made me super happy I've got great unit (and other types) test coverage.

I've got a project that has been sitting around without me working on it for about 6 months. It's got 18 libraries in "dependencies" and 22 in "devDependencies" (in package.json), and 90% of them had minor to major updates since I last touched the project. Of course, this being modern web development, only a couple of the libraries had useful changelogs listing breaking changes and the like.

Now, I could have just let well enough be and kept working with everything pinned at the versions I've got, but since I've got over 400 tests, I figured what the hell and started updating the version numbers in package.json one by one and fixing any errors that popped up when the unit tests ran.

It was actually a nice and straightforward process.

Remember your tests!

Flat Daddy posted:

So I've read that it's bad to use $scope now. Is the same true for $rootScope? I have a service that polls data and I want it to show up in the controller, so I'm using $rootScope.$broadcast in the service and listening in the controller. Looking through stack overflow and blog posts, it looks like I could also either (1) just use the observer pattern or (2) assign ctrl.theData = theService.theData when the controller is initialized. #1 feels like it'd be reinventing the wheel a bit, and #2 seems like it would have a performance penalty.

What's the best way to do this? Actually more important than this specific question is I'm looking for a good resource on what you should do in angular nowadays, rather than just what you can do. I use john papa's style guide already but I guess I'm looking for something broader.

Newf posted:

Does there exist any tool that parses a page's source to produce a report on the dependencies being used?

Eg, It'd be rad to have a brower plugin that can report to component X is rendered with react, that the page is styled with bootstrap, etc etc.

Lumpy posted:

What are you using for JS / React testing these days? I unit test my objective-C religiously, my python... not as much, but my JS...

The March Hare posted:

Wappalyzer for (at least) Chrome does this, though I'm not sure how good/accurate it is.

Flat Daddy posted:

So I've read that it's bad to use $scope now. Is the same true for $rootScope? I have a service that polls data and I want it to show up in the controller, so I'm using $rootScope.$broadcast in the service and listening in the controller. Looking through stack overflow and blog posts, it looks like I could also either (1) just use the observer pattern or (2) assign ctrl.theData = theService.theData when the controller is initialized. #1 feels like it'd be reinventing the wheel a bit, and #2 seems like it would have a performance penalty.

What's the best way to do this? Actually more important than this specific question is I'm looking for a good resource on what you should do in angular nowadays, rather than just what you can do. I use john papa's style guide already but I guess I'm looking for something broader.

HaB posted:

It's probably against "best practice" but I have been creating "state objects" which is basically a service that holds onto a set of values which get used by multiple controllers. I realize one of the style guides explicitly says "don't create a service just to hold a bunch of globals" but I have yet to hear a good alternative that doesn't involve a stupid amount of hoop jumping.

Skandranon posted:

I think this is warning against creating services which are just blobs of variables which anyone can modify. If you treat it like a data layer, with get/set methods, I don't see a problem with it.

spacebard posted:

That's reassuring. I have a Settings service in my chrome (and theoretically any browser) extension angular app that I use to get some config. for connecting to an arbitrary domain for this API. So I have a getter that wraps the browsers storage layer for extensions. Most of my controllers have it injected.
I was also thinking about using the same sort of service to store some arbitrary enumerated values from the API that I connect into. Basically I'm writing an extension to get around this project management tool's lovely front end

Kekekela posted:

In general, what is the process you guys go through to start a new project? (e.g. do you have a "boilerplate" template that you start from? use a scaffolding tool like yeoman? just start from an empty folder every time? other?)

Kekekela posted:

In this video Jafar Husain breaks down promises, observables, generators, and iterators and how they all relate in a way that even I was able to understand, which is frankly amazing. Also apparently ES6/ES7 are now ES2015/ES2016.

Thermopyle posted:

Maybe just testing that it acts on the DOM like you expect it to...like making sure that when a List component is mounted it creates some li's or whatnot.

Thermopyle posted:

Anyone have any thoughts about testing React components?

Helicity posted:

Don't write unit tests unless they save you headaches in the long run.

Helicity posted:

I read your original post about using like 4 frameworks or whatever and my first thought was "that's more complicated than my entire React app, and that's 2000 lines of Javascript."

Helicity posted:

I personally think 5-10 years ago no one did very good testing and then the pendulum swung in the opposite direction and now people spend more time writing and maintaining tests than they do making new things. With build/deploy CI being a common thing now, I can deploy a massive web site to two dozen instances across two data centers in two minutes if I screw up. Not that I want to be doing that frequently anyways, but the point is it's not hard for some types of development to correct mistakes quickly.

Everyone should be analyzing how many false errors your tests drudge up, how many real errors they prevent, and how many errors they miss. Sometimes more tests are just busy work, and you should automatically be wary of someone trying to push code coverage or line coverage checks in your build process.

Kekekela posted:

In this video Jafar Husain breaks down promises, observables, generators, and iterators and how they all relate in a way that even I was able to understand, which is frankly amazing. Also apparently ES6/ES7 are now ES2015/ES2016.

Thermopyle posted:

quote:

Catching/correcting mistakes is a very small part of the point of unit tests.

Helicity posted:

I look at having a lot of dependencies (especially ones written by individuals) and lots of modularity as being a threat to maintainability, and requiring several libraries to do simple unit tests is a huge turn off for me. Sure, I can figure it out, but I don't *want to* in this case. I'll keep my heavy business logic to a strongly typed language with well-vetted and commonly used testing suites, and use React more like a view engine. So my thoughts on testing React, to answer your question, are that React components should be light-weight and shouldn't require much testing.

I think that 2000 lines is a decent sized web app if you're consuming robust APIs, using concise syntax, and not over-abstracting everything like you're being paid by the line. Embracing the modularity of an ecosystem like NPM while saying 2000 lines of Javascript is "pretty small" is amusing to me. We're probably just operating in different environments with different circumstances and constraints, so my answer and my general outlook on architecture might not jive with yours I guess.


Unit testing is all about assuring the quality and functionality of the code, which an error/mistake would compromise. Is there a more important use of unit testing that I'm neglecting?

edit: this is honestly not me doing a typical programmer thing and arguing for the sake of arguing - I've never been happy with my viewpoint on tests and am actually interested in how others deal with them.

Plorkyeran posted:

PhantomJS gives you an actual browser engine so that you can test code that does stuff like DOM manipulation without mocking it or using a fake that may not behave like the real thing, but it adds a bunch of overhead and ideally most of your tests shouldn't need that. Broadly speaking you should run unit tests on node, and integration tests on PhantomJS.

Heisenberg1276 posted:

I'm not sure if this is the right thread for it so please redirect me if not.

I'm interested in learning how to better manage my CSS. I'm working on a project that's growing big and my structure is good except for the CSS which is becoming a bit of a mess. I'd like to sort it out before it becomes too difficult.

I know of the existence of OOCSS, BEM, and SMACSS and I'm sure there are plenty of other styles, but I don't really know much about them.

Which would people recommend me to learn? and what are the best resources for this? Mostly I've just seen a lot of separate wiki posts on occasional blogs about them - I'd prefer something a bit more substantial if it exists.