Proper sprint planning, retrospectives, story point voting for issues etc.
You've got to realise guys - I've only ever read about these things online about good professional software development culture. I've never participated in them before.
This is so... overwhelming, but in a good way!
So the dream lives! Maybe I won't be an embedded dev forever!
its actually less than 2000 lines of typescript, it just performs so much work that safari lobs a molotov cocktail at the CPU anytime I try to open the debug console
+1
Options
gavindelThe reason all your softwareis brokenRegistered Userregular
Sort of bugs me when our objects don't have a consistent construction syntax. Is it new()? Maybe this one is Class::construct? Oh, wait, this one automagically populates!
What's that, ES6? You cache the "import blah from 'blah'" so when I use that multiple times and just do a "export default new blah()", that same object reference is given to all importers and I get singletons for free?
Thanks ES6, you're the best.
+1
Options
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
es6 is a pretty huge upgrade for sure.
hell es6 makes JS feel like almost a completely different language. especially if you use babel to implement some of the proposed es7 ideas.
it feels way too much like 'magic' to me. its really hard to understand wtf is going on at a glance.
I like that using classes has forced us to drop mixins though, which are even more magic.
It is really hard to grok I find at first yeah, but that's more in the "write them properly" sense. Using them is straight-forward, and my other dev is thankful that I sorted it out and am converting mixins to them for her instead of leaving it to her.
Also, I submitted an issue for Webstorm which will make me happy because it's the only thing that isn't fitting our code style now. :rotate:
0
Options
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
yeah classes at A++
mixins cause way too many problems the larger you go.
Yep, and decorators are just syntactic sugar for HOCs.
I think the only difference is that for the more verbose and explicit code of a HOC, you can see clearly the wrapping of components. It's not so obvious with a decorator, but the resulting object is identical.
Man, for a town that is supposedly desperate for devs, Portland sure has nothing open for a mid level talent. Just out of college? Great! Come fizzbuzz for 40k a year! Senior? Pick your position.
But smack in the middle and I can barely get a call back, let alone an in-person.
And it looks like it's recruiters or nothing - I haven't had a single company even acknowledge that I've sent them a resume. Dammit, save your company tens of thousands of dollars and freaking call me you lazy HR drones!
Any recommendations on recruiters? Mine is getting me a phone call per week, but really seems to want me to be a Sr. dev, so I'm always underqualified.
Nothing to say on recruiters, but what kind of work do you do?
I was doing web apps for about 4 years - .Net MVC and that ecosystem. Mostly internal stuff like building a CMS for our marketing site, but also some customer facing doodads. C#, SQL, EF, Jquery, Knockout.
I talk to the guys wanting Sr. devs, but so far I either lack team experience (I was a solo dev for 3.5 of 4 years) or I don't know one of their tools (usually because I went knockout over Angular).
0
Options
admanbunionize your workplaceSeattle, WARegistered Userregular
If you have a week, teach yourself angular and add it to your resume. It's not hard.
it feels way too much like 'magic' to me. its really hard to understand wtf is going on at a glance.
Decorators are awesome* as long as you are the one writing them. When you stumble upon a decorator that uses reflection** and does things to that innocent other class that make parent classes blush and you weren't the person that wrote it, you just want to stab people.
Looks like we're taking a stab at MEAN tomorrow/Friday for the hackathon.
Should be fun! (I hope)
Unfortunately I will only get 1 day with it since I will be off joining the 30-years-of-debt homeowners club Friday (wooohooooooo!)
Okay React question... Hate to call you out on this one @Nogs but I hope you can help. It's very simple:
I'm writing a page that displays Password Reset Requirements. When they type in a character in the password field I want the page to verify that what they typed in made one of the requirements valid. Basically once they hit the requisite length of the password I want it to move from a red X to a green check. Right now I have these validations as states and in the render function I check if this state is true or false and update it accordingly.
What I mean is that I cannot (or, should not) update the state in either componentWillUpdate or componentDidUpdate, right? So is the idea that I do my validations in the componentDidUpdate and manipulate the DOM in that way? I had this all working before with me changing the state in componentWillUpdate, but I'm trying to get away from terrible React practices.
urahonky on
0
Options
jaziekBad at everythingAnd mad about it.Registered Userregular
I had no idea this limit was even a thing, and it only became apparent once I tried testing my service against an endpoint with a built in delay of 30 seconds for each request.
Okay React question... Hate to call you out on this one @Nogs but I hope you can help. It's very simple:
I'm writing a page that displays Password Reset Requirements. When they type in a character in the password field I want the page to verify that what they typed in made one of the requirements valid. Basically once they hit the requisite length of the password I want it to move from a red X to a green check. Right now I have these validations as states and in the render function I check if this state is true or false and update it accordingly.
What I mean is that I cannot (or, should not) update the state in either componentWillUpdate or componentDidUpdate, right? So is the idea that I do my validations in the componentDidUpdate and manipulate the DOM in that way? I had this all working before with me changing the state in componentWillUpdate, but I'm trying to get away from terrible React practices.
Okay so, before getting into all that craziness I'm going to suggest you take a step back and maybe try implementing this guy:
My gut instinct is you actually just put an onChange method on the input and check length/state there. Also, be aware that React does some stuff automatically with form inputs. (read: https://facebook.github.io/react/docs/forms.html ).
But without knowing fully how things are set up, and also the fact that as far as I know you aren't using a data handler like Backbone or some kind of Flux implementation, I'm skeptical of giving you too much state changing advice without seeing the whole ecosystem.
So, for right now I suggest just quick pulling in that repo and giving that a shot, looks like it's got most of the stuff you'll need - then it'll just be styling.
If it doesn't suit your needs, let me know and we can go back and forth in PMs.
Yeah, dealing with forms is something that isn't trivial in React since it eschews two-way binding. You're on your own, but not really. Lots of implementations and packages you can utilize, but that means it depends on which you're using to know the best approach.
If you're not using one, maybe you should consider one? For example, we're using formsy-react, and it gives us easy tools for defining inline validation like this.
+2
Options
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
also if that repo doesnt work for your use case, or if it has defects, you could probably still learn a bit from looking at its src/index.js file.
We define all the validation (built-in and custom ones) in the props of our fields (themselves components) and hook into one canSubmit state, it handles showing of validation messages and enabling of the submit button reactively.
+1
Options
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
edited August 2015
well
ideally you dont do the getDOMNode() or ref stuff unless you absolutely need too. most of the time proper state flow heirachy will do that stuff for you. ( https://facebook.github.io/react/docs/more-about-refs.html last bullet at bottom of page )
ideally you would find a way to pass state to the button via a shared anscetor that holds that state and that takes care of it. Or you use a flux/backbone implementation to handle your app state and have component get state that way.
but youre on a deadline and it works, thats what matters. id suggest looking at the formsy-react stuff going forward, and highly suggest getting backbone or some flux implementation in your app sooner rather than later.
If I can't use state and I can't use refs I'm very, very unclear on what I need to do for validations. I see that Formsy has you pass in properties to those components but that means I need to have separate components for things like Inputs that can accept the validations, right? That means I have to write something similar to Input to do validations. I guess my problem is that this PasswordReset page is literally a self-contained component that uses the Bootstrap components to display stuff... I have to write sub-components that use these (something like <HonkyInput>) that take in these props and those props get validated against whatever I want. How would I get these values from a separate component, though? Like if I had:
How would I know if HonkyInput was valid to change the image? Would I attach a function in PasswordReset to HonkyInput that would change the state in PasswordReset?
I just wrote a new registration back-end to replace the stubbed one out. The whole thing from express post handling through validation through to saving the database and returning a jwt.
What's that? It had no syntax errors and worked completely the first time?
God I hate that. :rotate:
(Looks okay on the database and authentication followup calls...)
+1
Options
admanbunionize your workplaceSeattle, WARegistered Userregular
I've still yet to figure out just exactly what the point of each of these JS frameworks is supposed to fulfill.
You've got handlebars, react, express, node.
When should I use which? What are some examples!
I see a lot of hello world with a print or something, but real world practical examples are kind of missing.
Handlebars is a templating language that lets you generate HTML more easily. React is an end-to-end framework for making web apps. Express is a framework that sits on top of Node and lets you make webservers more easily. Node is a low-level way to run javascript natively and do network-y things.
Of those, React is the only "framework" in the way it's most commonly used; the other big-name frameworks right now are Angular and Ember. There's things like backbone which is much smaller and just gives you a way to get events/data moving around, without any rendering.
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
Angular and Ember a full "MVC"-ish frameworks. You can theoretically have an end-to-end solution with just Angular or Ember or Meteor. They handle data, routing, views, etc. and are generally pretty opinionated.
React JUST handles view, which is why you have things like Flux to handle data, and react-router to handle routing. You can technically use React inside of Angular, Ember or Meteor.
Posts
Don't do this to me man
I just came into web dev to escape these monstrosities and ohgodno the flashbacks
they're happening again
bloodlust... rising....
... where... where did this dagger come from?
what's.. going... on...? why so much... red paint in the room....
Oh whoops... just trying my new paintbrush and you must've grabbed my knife.
Thanks ES6, you're the best.
hell es6 makes JS feel like almost a completely different language. especially if you use babel to implement some of the proposed es7 ideas.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
Where we're going, we don't need roads.
i don't think i like decorators.
it feels way too much like 'magic' to me. its really hard to understand wtf is going on at a glance.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
I like that using classes has forced us to drop mixins though, which are even more magic.
It is really hard to grok I find at first yeah, but that's more in the "write them properly" sense. Using them is straight-forward, and my other dev is thankful that I sorted it out and am converting mixins to them for her instead of leaving it to her.
Also, I submitted an issue for Webstorm which will make me happy because it's the only thing that isn't fitting our code style now. :rotate:
mixins cause way too many problems the larger you go.
all about them higher order components now.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
I think the only difference is that for the more verbose and explicit code of a HOC, you can see clearly the wrapping of components. It's not so obvious with a decorator, but the resulting object is identical.
But smack in the middle and I can barely get a call back, let alone an in-person.
And it looks like it's recruiters or nothing - I haven't had a single company even acknowledge that I've sent them a resume. Dammit, save your company tens of thousands of dollars and freaking call me you lazy HR drones!
Any recommendations on recruiters? Mine is getting me a phone call per week, but really seems to want me to be a Sr. dev, so I'm always underqualified.
I talk to the guys wanting Sr. devs, but so far I either lack team experience (I was a solo dev for 3.5 of 4 years) or I don't know one of their tools (usually because I went knockout over Angular).
Decorators are awesome* as long as you are the one writing them. When you stumble upon a decorator that uses reflection** and does things to that innocent other class that make parent classes blush and you weren't the person that wrote it, you just want to stab people.
* No, not really.
** I have written those ;o(
Should be fun! (I hope)
Unfortunately I will only get 1 day with it since I will be off joining the 30-years-of-debt homeowners club Friday (wooohooooooo!)
I'm writing a page that displays Password Reset Requirements. When they type in a character in the password field I want the page to verify that what they typed in made one of the requirements valid. Basically once they hit the requisite length of the password I want it to move from a red X to a green check. Right now I have these validations as states and in the render function I check if this state is true or false and update it accordingly.
What I mean is that I cannot (or, should not) update the state in either componentWillUpdate or componentDidUpdate, right? So is the idea that I do my validations in the componentDidUpdate and manipulate the DOM in that way? I had this all working before with me changing the state in componentWillUpdate, but I'm trying to get away from terrible React practices.
http://blogs.msdn.com/b/darrenj/archive/2005/03/07/386655.aspx
I had no idea this limit was even a thing, and it only became apparent once I tried testing my service against an endpoint with a built in delay of 30 seconds for each request.
Okay so, before getting into all that craziness I'm going to suggest you take a step back and maybe try implementing this guy:
https://seethroughtrees.github.io/react-ux-password-field/
My gut instinct is you actually just put an onChange method on the input and check length/state there. Also, be aware that React does some stuff automatically with form inputs. (read: https://facebook.github.io/react/docs/forms.html ).
But without knowing fully how things are set up, and also the fact that as far as I know you aren't using a data handler like Backbone or some kind of Flux implementation, I'm skeptical of giving you too much state changing advice without seeing the whole ecosystem.
So, for right now I suggest just quick pulling in that repo and giving that a shot, looks like it's got most of the stuff you'll need - then it'll just be styling.
If it doesn't suit your needs, let me know and we can go back and forth in PMs.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
If you're not using one, maybe you should consider one? For example, we're using formsy-react, and it gives us easy tools for defining inline validation like this.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
one thing thats so great about react is, everytime you make something, it is automatically reusable.
that fosters a huge open source community. which means that a lot the problems you run into, someone has probably already attempted to solve.
now react is still new enough that these solutions arent always perfect. but they really help with quick bootstraping.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
I'm using React-Bootstrap, by the way, so that's what the Panel, Grid, Inputs, etc are.
render:
All of my onChanges look like:
componentDidUpdate:
validate:
Am I on the right track? This works exactly as I want it to (updates the images immediately, disables the button if it's invalid, etc).
We define all the validation (built-in and custom ones) in the props of our fields (themselves components) and hook into one canSubmit state, it handles showing of validation messages and enabling of the submit button reactively.
ideally you dont do the getDOMNode() or ref stuff unless you absolutely need too. most of the time proper state flow heirachy will do that stuff for you. ( https://facebook.github.io/react/docs/more-about-refs.html last bullet at bottom of page )
ideally you would find a way to pass state to the button via a shared anscetor that holds that state and that takes care of it. Or you use a flux/backbone implementation to handle your app state and have component get state that way.
but youre on a deadline and it works, thats what matters. id suggest looking at the formsy-react stuff going forward, and highly suggest getting backbone or some flux implementation in your app sooner rather than later.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
just kidding, but I couldn't resist
PasswordReset.render:
How would I know if HonkyInput was valid to change the image? Would I attach a function in PasswordReset to HonkyInput that would change the state in PasswordReset?
You've got handlebars, react, express, node.
When should I use which? What are some examples!
I see a lot of hello world with a print or something, but real world practical examples are kind of missing.
What's that? It had no syntax errors and worked completely the first time?
God I hate that. :rotate:
(Looks okay on the database and authentication followup calls...)
Anxiety implies a fear of the unknown. It's not unknown if I know I broke something.
Handlebars is a templating language that lets you generate HTML more easily. React is an end-to-end framework for making web apps. Express is a framework that sits on top of Node and lets you make webservers more easily. Node is a low-level way to run javascript natively and do network-y things.
Of those, React is the only "framework" in the way it's most commonly used; the other big-name frameworks right now are Angular and Ember. There's things like backbone which is much smaller and just gives you a way to get events/data moving around, without any rendering.
See http://stackoverflow.com/questions/5284340/what-is-node-js-connect-express-and-middleware for more about node/express; see many religious war pages for more about react/angular/ember.
React JUST handles view, which is why you have things like Flux to handle data, and react-router to handle routing. You can technically use React inside of Angular, Ember or Meteor.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!