Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

Gildiss: Aug 24, 2010; Grimey Drawer

Honest Thief posted:

I need to improve my test methodologies, I know how to use test frameworks, like Karma for instance, but plainly I don't know how to even start unless someone forces me to just squirt out some tests to fill out their progress reports. I'm not the biggest fan of TDD due to mostly the community at times coming of as ideological and dogmatic, but I guess I can improve without having to buy into the whole thing.

Maybe put in coverage requirements?

# ? Mar 29, 2017 11:57

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 23:12

Honest Thief: Jan 11, 2009

Gildiss posted:

Maybe put in coverage requirements?

I got none, this is more in cases when, like it has happened before, a project manager requests for test coverage and just leaves it at that.

# ? Mar 29, 2017 12:03

Gildiss: Aug 24, 2010; Grimey Drawer

Honest Thief posted:

I got none, this is more in cases when, like it has happened before, a project manager requests for test coverage and just leaves it at that.

So put in a build requirement that test coverage on all services must be above x or the build fails.

# ? Mar 29, 2017 12:07

Honest Thief: Jan 11, 2009

It's more about writing meaningful tests, something beyond render function and expect(component).toExist(). Most of the time I just feel lost when trying to come up with tests.

# ? Mar 29, 2017 12:19

Gildiss: Aug 24, 2010; Grimey Drawer

Honest Thief posted:

It's more about writing meaningful tests, something beyond render function and expect(component).toExist(). Most of the time I just feel lost when trying to come up with tests.

Oh, well yeah.
:same:

# ? Mar 29, 2017 12:21

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Honest Thief posted:

It's more about writing meaningful tests, something beyond render function and expect(component).toExist(). Most of the time I just feel lost when trying to come up with tests.

I try to think about question "What happens if I send the dumbest input I can into this thing?" So write a bunch of method calls with "stupid" inputs in them. Like if I'm doing a function to format currency, write out some function calls like:

JavaScript code:

formatCurrency('a');
formatCurrency(undefined);
formatCurrency(true);

Then toss in some calls with valid inputs, then wrap those up in test cases. While I'm doing that, other cases pop to mind like:

JavaScript code:

formatCurrency('45000');  // hmm, should I try parseInt/Float on my inputs? Barf on non-number types??
formatCurrency('$32,000.34'); // what do I do here? Nothing? Parse it anyway?? Barf?
formatCurrency(26.005) // how do we handle rounding?
formatCurrency(26.00000000324) // it could happen thanks to js math!

Next thing you know, you have a decent set of tests.

That said, I tend to *not* test components, as I try to keep them so simple they don't benefit much. The code that drives the inputs to those components is the stuff I care about.

While I also try not to drink the dogma part of TDD, I find that for me, when I don't write tests first, I don't write tests.

# ? Mar 29, 2017 14:40

HaB: Jan 5, 2001; What are the odds?

Lumpy posted:

I try to think about question "What happens if I send the dumbest input I can into this thing?" So write a bunch of method calls with "stupid" inputs in them. Like if I'm doing a function to format currency, write out some function calls like:
JavaScript code:
formatCurrency('a');
formatCurrency(undefined);
formatCurrency(true);
Then toss in some calls with valid inputs, then wrap those up in test cases. While I'm doing that, other cases pop to mind like:
JavaScript code:
formatCurrency('45000');  // hmm, should I try parseInt/Float on my inputs? Barf on non-number types??
formatCurrency('$32,000.34'); // what do I do here? Nothing? Parse it anyway?? Barf?
formatCurrency(26.005) // how do we handle rounding?
formatCurrency(26.00000000324) // it could happen thanks to js math!
Next thing you know, you have a decent set of tests.

That said, I tend to *not* test components, as I try to keep them so simple they don't benefit much. The code that drives the inputs to those components is the stuff I care about.

While I also try not to drink the dogma part of TDD, I find that for me, when I don't write tests first, I don't write tests.

This is basically my methodology as well. "what could some dipshit user send to this thing that might break it?"

Dogma in anything is so weird to me.

It seems especially weird in code. Do whatever makes your workflow as agreeable as possible among your team and what makes it so everyone can get work done.

# ? Mar 29, 2017 15:24

Honest Thief: Jan 11, 2009

After spending two hours trying to solve a weird import dependency, I simply erased the node_modules folder and re-installed.. it's working now. gently caress me

Lumpy posted:

I try to think about question "What happens if I send the dumbest input I can into this thing?" So write a bunch of method calls with "stupid" inputs in them. Like if I'm doing a function to format currency, write out some function calls like:
JavaScript code:
formatCurrency('a');
formatCurrency(undefined);
formatCurrency(true);
Then toss in some calls with valid inputs, then wrap those up in test cases. While I'm doing that, other cases pop to mind like:
JavaScript code:
formatCurrency('45000');  // hmm, should I try parseInt/Float on my inputs? Barf on non-number types??
formatCurrency('$32,000.34'); // what do I do here? Nothing? Parse it anyway?? Barf?
formatCurrency(26.005) // how do we handle rounding?
formatCurrency(26.00000000324) // it could happen thanks to js math!
Next thing you know, you have a decent set of tests.

That said, I tend to *not* test components, as I try to keep them so simple they don't benefit much. The code that drives the inputs to those components is the stuff I care about.

While I also try not to drink the dogma part of TDD, I find that for me, when I don't write tests first, I don't write tests.

This seems a good guideline overall, thanks.

# ? Mar 29, 2017 15:37

geeves: Sep 16, 2004

Honest Thief posted:

I need to improve my test methodologies, I know how to use test frameworks, like Karma for instance, but plainly I don't know how to even start unless someone forces me to just squirt out some tests to fill out their progress reports. I'm not the biggest fan of TDD due to mostly the community at times coming of as ideological and dogmatic, but I guess I can improve without having to buy into the whole thing.

I'm not a fan of TDD, either.

A lot of the JS bugs that I come across have to do with JS' flexibility when assigning type. I have a Java background so this irks me to no end. When watching the Redux tutorials, I liked the deepFreeze way of approaching tests to make sure things are immutable. Having tests that check for things like this can save a lot of debugging headache later down the line. The biggest problem in my company is that a large number of methods, classes, etc. are all procedural and long as hell. It's sadly very common to have a 700 line method that's dealing with mutable objects and tons of nested if / else statements.

# ? Mar 29, 2017 15:58

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

geeves posted:

I'm not a fan of TDD, either.

A lot of the JS bugs that I come across have to do with JS' flexibility when assigning type. I have a Java background so this irks me to no end. When watching the Redux tutorials, I liked the deepFreeze way of approaching tests to make sure things are immutable. Having tests that check for things like this can save a lot of debugging headache later down the line. The biggest problem in my company is that a large number of methods, classes, etc. are all procedural and long as hell. It's sadly very common to have a 700 line method that's dealing with mutable objects and tons of nested if / else statements.

I've been messing around with Elm the past weeks, and while I'm still getting used to the language / FRP style, the type system and warnings are so, so, so wonderful.

# ? Mar 29, 2017 16:06

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

Honest Thief posted:

After spending two hours trying to solve a weird import dependency, I simply erased the node_modules folder and re-installed.. it's working now. gently caress me

I think that's pretty much the js version of "did you turn it off and back on"

# ? Mar 29, 2017 16:18

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Honest Thief posted:

After spending two hours trying to solve a weird import dependency, I simply erased the node_modules folder and re-installed.. it's working now. gently caress me

That's basically the first thing I do if Node is being weird.

# ? Mar 29, 2017 17:20

Flat Daddy: Dec 3, 2014; by Nyc_Tattoo

if you're not on windows, yarn is really nice. it locks down versions and makes your builds deterministic. so I haven't need to nuke my node_modules at all yet, unless I accidentally forget and use npm again. the performance is amazing on Mac and linux but horribly slow on windows

# ? Mar 29, 2017 18:31

Flat Daddy: Dec 3, 2014; by Nyc_Tattoo

Lumpy posted:

I've been messing around with Elm the past weeks, and while I'm still getting used to the language / FRP style, the type system and warnings are so, so, so wonderful.

you can get kind of close to elm (and be Real Job work-friendly) with typescript + redux + tslint rules that prefer immutability. we have a decent sized codebase with this stack and it's ridiculously easy to dive into parts of the codebase I haven't touched or looked at, and immediately be able to understand and work on them. only downside is there's a bunch of boilerplate but it's starting to become second nature when creating a component to create the stub redux component, saga, reducer, initialState, wire them up, and then grow it from there.

# ? Mar 29, 2017 18:35

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Using yarn instead of npm has eliminated that for me.

edit: Oops, left tab open too long.

# ? Mar 29, 2017 18:47

smackfu: Jun 7, 2004

Karma handles coverage? That is neat.

# ? Mar 30, 2017 00:18

Odette: Mar 19, 2011

Honest Thief posted:

After spending two hours trying to solve a weird import dependency, I simply erased the node_modules folder and re-installed.. it's working now. gently caress me

This happens way too often for me to laugh at. Pisses me off when behaviour becomes funky and I have to resort to that "fix".

# ? Mar 30, 2017 00:44

luchadornado: Oct 7, 2004; A boombox is not a toy!

Honest Thief posted:

I need to improve my test methodologies, I know how to use test frameworks, like Karma for instance, but plainly I don't know how to even start unless someone forces me to just squirt out some tests to fill out their progress reports. I'm not the biggest fan of TDD due to mostly the community at times coming of as ideological and dogmatic, but I guess I can improve without having to buy into the whole thing.

http://artofunittesting.com/

Great book even if you're not a C# developer. I still personally can't do TDD since I like to get something working first, but after that point I'll usually write tests hand in hand with the feature. I'll do TDD if fixing a bug. Good unit tests > no unit tests > bad unit tests. Having to learn new code or refactor old code with awesome unit tests in place almost makes you break down and cry with happiness.

# ? Mar 30, 2017 02:25

Gildiss: Aug 24, 2010; Grimey Drawer

Helicity posted:

http://artofunittesting.com/

Great book even if you're not a C# developer. I still personally can't do TDD since I like to get something working first, but after that point I'll usually write tests hand in hand with the feature. I'll do TDD if fixing a bug. Good unit tests > no unit tests > bad unit tests. Having to learn new code or refactor old code with awesome unit tests in place almost makes you break down and cry with happiness.

A good book.

Can also find videos of him giving talks about the book which are nice summaries of the main points.

# ? Mar 30, 2017 02:53

Honest Thief: Jan 11, 2009

Now it's a weirder "weird behaviour" I cloned the same repository twice, and replicated the changed in one branch into the other, and ran the same build command and on one it fails before the babelfy and the other branch doesnt, on the same exact entry point file. I probably installed an untracked dependency or smth.

# ? Mar 30, 2017 10:28

Kekekela: Oct 28, 2004

We started using Jest and Travis on my current project this week. Loving it so far.

The Github integration with Travis is dead simple, and Jest is giving me some warm and fuzzies that I'm not used to on the front end.

# ? Mar 30, 2017 23:45

smackfu: Jun 7, 2004

So what are people doing about Angular 1 apps?

* Migrate to Angular 2+ which is not trivial and hope that catches on.
* Migrate to React which seems even more of a rewrite.
* Put our head in the sand and keep using Angular 1 until something breaks

I don't really like any of the options.

# ? Mar 31, 2017 20:39

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

smackfu posted:

So what are people doing about Angular 1 apps?

* Migrate to Angular 2+ which is not trivial and hope that catches on.
* Migrate to React which seems even more of a rewrite.
* Put our head in the sand and keep using Angular 1 until something breaks

I don't really like any of the options.

AngularJS isn't going anywhere, the devs have committed to maintaining it until the "majority" of people have moved onto Angular:

quote:

Angular 1.X will not end life until the majority of traffic has moved to 2.0.

https://www.youtube.com/watch?v=QHulaj5ZxbI

And even then once AngularJS EOL's your sites won't mysteriously stop working, unless you're linking to a CDN or something that coincidentally pulls downloads that same day.

# ? Mar 31, 2017 21:03

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

smackfu posted:

So what are people doing about Angular 1 apps?

* Migrate to Angular 2+ which is not trivial and hope that catches on.
* Migrate to React which seems even more of a rewrite.
* Put our head in the sand and keep using Angular 1 until something breaks

I don't really like any of the options.

I'm probably going to do the Migrate to Angular 2+ part. We are already most of the way there, as we use TypeScript and closely follow the 1.5 Component model. Also looking at Aurelia, but will address that when time comes to upgrade. Not exactly in a big rush, as AngularJS 1.5 + TypeScript removes most of the warts Angular 2 wanted to fix, just without the performance improvements, and that isn't an issue yet.

There's no reason to think AngularJS will ever stop working, unless JavaScript stops working.

# ? Mar 31, 2017 21:10

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

IAmKale posted:

And even then once AngularJS EOL's your sites won't mysteriously stop working,

The issue with sticking with outdated libraries isn't that they will stop working. It's that it makes your site less secure.

# ? Mar 31, 2017 21:20

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Thermopyle posted:

The issue with sticking with outdated libraries isn't that they will stop working. It's that it makes your site less secure.

That's not exactly true... some DO stop working, like Silverlight.

# ? Mar 31, 2017 21:38

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Skandranon posted:

That's not exactly true... some DO stop working, like Silverlight.

Ok, the main issue with javascript libraries!

# ? Mar 31, 2017 22:15

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Thermopyle posted:

The issue with sticking with outdated libraries isn't that they will stop working. It's that it makes your site less secure.

Yes, you're exactly right, and to that end I advocate for the "Migrate to Angular 2+" option. The point I was more going for, though, is that there's not some kind of timer buried in the angular.min.js file that'll go, "oh hey, today's August 29th, 2019, time to break completely!" so there's no immediate need to start porting.

That said, now's as good a time as any to begin planning to port because before you know it it WILL be August 29th, 2019 and your AngularJS app will get hacked to poo poo because you didn't bother upgrading to Angular 14.

# ? Mar 31, 2017 23:23

Rubellavator: Aug 16, 2007

Do you still call it migration when it practically means a rewrite of your entire client?

# ? Apr 1, 2017 00:29

geeves: Sep 16, 2004

Our issue with AngularJS was that the front end devs that initially implemented it wrapped our entire Struts application in it and basically made Controllers from every struts action through Site Mesh. They effectively locked us in to angular indefinitely :barf:

2 or 3 months into the implementation I got curious as to what was taking so long. I thought that new features, etc. would be with AngularJS and we would port things as major changes came up with components. I peeked at their branch and to my horror saw what they had been doing.

For every page, app.com/writePost.action there needs to be a corresponding controller named writePost, even if it's all JSP, the controller just has to exist because they did this in the main decorator:

<body ng-controller="<%=actionName%>">.

Either the controller was an empty function or it initialized a handful of services in the most non-maintainable way imaginable.

All of this was implemented without my knowledge or involvement (I wasn't involved as I had to work from home for about 6-7 months to recover from an accident and I was implementing our REST app which I could do pretty independently).

Anyway, my email to the entire dev team was short and to the point: "What the gently caress is this poo poo?" in bold 100pt letters with a link to the Stash branch with the one file change that was made that doomed our system.

We all have a good sense of humor so the email was taken in stride and when I returned to the office a couple months later, my email was printed out as a poster and taped to the wall behind my desk.

We can get around this by adding another decorator page without it, so that definitely helps.

This whole clusterfuck echoed all the way up to the C-levels and needing some more transparency as well as not to put devs in a vacuum for 5-6 months finally got us out of Waterfall into Agile.

# ? Apr 1, 2017 00:46

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Rubellavator posted:

Do you still call it migration when it practically means a rewrite of your entire client?

It really depends how your AngularJS apps are written. A lot of the components/services in mine could actually be used in Angular 2 verbatim, with only a few line changes to register them in Angular 2. So in this case, I am expecting what could be called a migration.

If you have an AngularJS 1.1 app with $scope, $watch, and $rootScope all over the place, yeah, you're basically doing a re-write, because your app is trash.

# ? Apr 1, 2017 05:42

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Why are you talking about Angular 2? It's 4 now.

Also I think it's great that Angular, written by Google, has terrible SEO.

# ? Apr 1, 2017 14:40

Vesi: Jan 12, 2005; pikachu looking at?

The Merkinman posted:

Why are you talking about Angular 2? It's 4 now.

Also I think it's great that Angular, written by Google, has terrible SEO.

Yes retro-namechanging angular to angularjs and angular 2 to angular makes them both impossible to search for, it's probably the stupidest naming decision in IT history.

# ? Apr 1, 2017 14:46

smackfu: Jun 7, 2004

"You said Angular 2 was a big upgrade and now they are already up to 4? Maybe we should step back and investigate other technologies that are not moving so fast."

# ? Apr 1, 2017 16:01

luchadornado: Oct 7, 2004; A boombox is not a toy!

The community, and maybe just Igor/Brad, are insistent that it's AngularJS (v1) and Angular (v2+).

The skipping of 3 actually makes sense in that they embraced semver, and most of their core libs were v2, but at least one was v3. v4 gets them all in parity again.

The very fact that we're discussing any of this means that they did a lovely job naming and versioning it. Hail ~~Satan~~React.

# ? Apr 1, 2017 16:19

Rubellavator: Aug 16, 2007

smackfu posted:

"You said Angular 2 was a big upgrade and now they are already up to 4? Maybe we should step back and investigate other technologies that are not moving so fast."

We just convinced the higher-ups to let us switch from using JSF to Angular 1.X/REST for new development and I can only imagine their response to being told that we now need to move to Angular 4 and possibly rewrite the handful of clients we've already written.

# ? Apr 1, 2017 19:47

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Rubellavator posted:

We just convinced the higher-ups to let us switch from using JSF to Angular 1.X/REST for new development and I can only imagine their response to being told that we now need to move to Angular 4 and possibly rewrite the handful of clients we've already written.

You can probably make a decent case to start using TypeScript with your existing Angular 1 app, which will get you a step closer. You can then try to follow the Angular 1.5 component model more strictly, and you can get very close to what Angular 2/4 is. The nice thing about both of these steps is they can both be gradual, and should provide you with immediate benefits. Don't even phrase it as a rewrite, just propose using a new technology (TypeScript), and following some better guidelines for Angular development (components).

I'd start a prototype and then say to boss/team lead/rest of team "Hey, check out this cool thing I've been working on at home, I think this could improve our current apps, make them easier to maintain and develop, etc."

Skandranon fucked around with this message at 19:53 on Apr 1, 2017

# ? Apr 1, 2017 19:51

Summit: Mar 6, 2004; David wanted you to have this.

Nobody should really be saying "Angular 4" much like nobody says "React 15" (current version, since they also do semver). I'll admit Angular team has handled this situation very poorly but the piling on about version numbers is pretty silly.

# ? Apr 1, 2017 20:03

Professor of Cats: Mar 22, 2009

Angular 1 is fine, vetted and still getting updates. While less secure may be an issue in the future due to some unforeseen massive exploit(angular wouldn't be the only thing in trouble), if any good dev has any sense, monkey patching for security updates will never be a problem.

I feel like a few of us keep having to reiterate this every couple of pages. Angular 1 isn't utilizing some soon to be outdated browser tech and if anything is in a good spot for a while. If new major security things come out that is necessary to adopt....Just adopt it...if the devs or tons of other contributors haven't done so already.

In other words, it is all gravy baby, relax.

E. Missed a word

Also:

Skandranon posted:

It really depends how your AngularJS apps are written. A lot of the components/services in mine could actually be used in Angular 2 verbatim, with only a few line changes to register them in Angular 2. So in this case, I am expecting what could be called a migration.

If you have an AngularJS 1.1 app with $scope, $watch, and $rootScope all over the place, yeah, you're basically doing a re-write, because your app is trash.

Professor of Cats fucked around with this message at 21:26 on Apr 1, 2017

# ? Apr 1, 2017 21:21

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 23:12

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Professor of Cats posted:

Angular 1 is fine, vetted and still getting updates. While less secure may be an issue in the future due to some unforeseen massive exploit(angular wouldn't be the only thing in trouble), if any good dev has any sense, monkey patching for security updates will never be a problem.

I feel like a few of us keep having to reiterate this every couple of pages. Angular 1 isn't utilizing some soon to be outdated browser tech and if anything is in a good spot for a while. If new major security things come out that is necessary to adopt....Just adopt it...if the devs or tons of other contributors haven't done so already.

In other words, it is all gravy baby, relax.

E. Missed a word

Also:

Like...I pretty much agree with this, but also feel like it's a pretty rose-colored world you live in where you can expect companies to go back and update sites for security issues. On the one hand, there's not much you can do about it, but on the other hand I question whether starting something with Angular 1 now is the best idea when it comes to maintaining security for as long as possible.

# ? Apr 1, 2017 22:17

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »