Philisophical/Best Practices question for you guys:
Should a front end engineer assume they are always going to get the proper data returned, and build their functions accordingly, to maximize performance, or should the front end engineer assume that the data will always be bad/wrong/missing and build everything so it fails gracefully, even at a small but noticeable performance hit?
Philisophical/Best Practices question for you guys:
Should a front end engineer assume they are always going to get the proper data returned, and build their functions accordingly, to maximize performance, or should the front end engineer assume that the data will always be bad/wrong/missing and build everything so it fails gracefully, even at a small but noticeable performance hit?
Not the user, data from the back end system/server ajax requests. Sorry if I worded that poorly.
Philisophical/Best Practices question for you guys:
Should a front end engineer assume they are always going to get the proper data returned, and build their functions accordingly, to maximize performance, or should the front end engineer assume that the data will always be bad/wrong/missing and build everything so it fails gracefully, even at a small but noticeable performance hit?
Unless you have ironclad validation or practices in your shop, the 2nd. You never know what's coming down the pipe, and penetration testing will tear apart anything that passes on nasty statements as valid if you don't limit them out.
My old job used to do K-Cups. Except the garbage was getting more and more, boxes magically starting disappearing (people taking them home) and ultimately, it's just not very good coffee.
They brought in a new supplier, centralized a bunch of the machines that went from bean to coffee in front of you. As well as mocha/vanilla/hot chocolate in the same machine. Across 4 or 5 sites, getting rid of 50-75 machines and putting in 25-30 new ones, they were going to save almost $500,000 / year. FOR COFFEE. It was a huge win. Garbage went down, people liked the newer coffee better.
We have K-Cups and automatic grind/brew single cup machines. I expect that on a per cup basis the K-Cup costs more, even when factoring in the cost of the automatic machine.
Philisophical/Best Practices question for you guys:
Should a front end engineer assume they are always going to get the proper data returned, and build their functions accordingly, to maximize performance, or should the front end engineer assume that the data will always be bad/wrong/missing and build everything so it fails gracefully, even at a small but noticeable performance hit?
Not the user, data from the back end system/server ajax requests. Sorry if I worded that poorly.
The rule of thumb, as far as I'm aware is:
Sanitize input from every entrance to your package as soon as it comes in. If data is coming into your package from outside it, sanitize it. If data is traveling within your package, you can assume its correctness because any bad data will not get through the gates.
That being said, there are some input types which don't reasonably ever need to be sanitized. (If your package processes the input with its own internal logic, it's probably okay. If your package accepts arbitrary input and tries to parse it, it's probably not.)
Well then I weep for this student and his classmates. We got into it yesterday, because he was explicitly referencing data from our ajax requests to the server, and not checking if it existed or not. So I was all "Hey you need to run some ternary checks as you stick this into the page to make sure it doesn't break if a value isn't there". Apparently one of his comp sci teachers insists that if they know the data is coming from within their package, then you trust it, which is just all kinds of "WTF" from me. Man, I fucking wrote the back end code and I sure as fuck don't trust myself to give me what I expect every time. Let alone any server or database hiccups that might happen. Assuming all of the data is going to be there every time just screams ignorance to me.
admanbunionize your workplaceSeattle, WARegistered Userregular
edited January 2015
If the data is coming from the same package, then I don't see why you would ever sanitize it on the front-end. Sending out non-null/non-breaking data should be your back-end's responsibility.
If the data is coming from some service that's not part of the same project then yeah, check the hell out of it.
If you write a service that sends out inconsistent data with the logic that you'll double-check it on the front-end, please go fuck yourself.
I'm not talking about sanitizing it. I'm talking about just basic checks to see if it exists. A bit of an overview:
It's an evaluation program. People fill out evaluations, submit them, then other's go and complete them. Sometimes people don't fill out all the fields because they aren't all required. Some of the evaluations are super old from before I took over the project, and they weren't requiring all the fields we currently are, so the data is incomplete, or 0's got put in instead of null values. So for every value I have to check to make sure that value existed before I blindly print it out to the page. Now I would assume you would want to do that ANYWAY because the resource cost for doing that sort of short ternary IE - ( this.data ? "None" : this.data) is super low, and it prevents display errors.
Does that make a bit more sense and less "OH GOD WHAT THE FUCK ARE YOU DOING?"
That's more that he's assuming structure of data that is incorrect for certain well-formed (at the time) data, that he will receive as valid input, and needs to address properly yes.
0
Options
admanbunionize your workplaceSeattle, WARegistered Userregular
edited January 2015
Sure, but I'd still rather fix that on the back-end and then be guaranteed to return valid data to the front-end. If you have no access to the back-end then yes, you definitely fix it on the front-end. However, even then I would want your front-end to have separation between service calls and UI controls, and data validation/sanitization should be done at the service call level.
It still makes sense, as you have to deal with junky legacy data and the potential for future junky input ("Oh, that wasn't required, oh well it should have been so we're including it"), so you're saving yourself many future headaches with that. I could think you could just do a coalesce or something though if you encounter a null.
+1
Options
admanbunionize your workplaceSeattle, WARegistered Userregular
Insisting on validating everything in your view templates is more likely to cause errors then figuring out a single point through which the data can pass through and validating it there.
So I've been playing around with node.js the past few days.
This is definitely a solution to some problems I've been having.
Right now instead of loading SNOMed codes on each client, I'm going to load it up into an array on the server, and deliver it to the client when they go visit:
LINQ is civilization. I wish PHP had something like that native. There's a crude PHP object library that kinda sorta does some of the simple stuff LINQ can do, but I'm not sure if it's been updated in the last few years.
Maybe I just need to set a goal for myself of some kind. Something like: "Any time I am tempted to iterate over a collection, use LINQ to do it instead of foreach"
Maybe I just need to set a goal for myself of some kind. Something like: "Any time I am tempted to iterate over a collection, use LINQ to do it instead of foreach"
Anytime you iterator or translate a collection, LINQ is the answer.
Even turning 5 lines of a for loop into 1 line is the best thing ever.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
One of my big projects which launches in a couple of weeks got an article done about it on techrunch today including links to one of my related currently in production projects. Awesome and scary.
I will seriously fucking cut the next person who uses git revert on any project I work on. It keeps getting used to fix some fuckup on master, then a feature branch afterwards gets created, then merged to staging, and staging gets all totally fucked up. It also almost always reverts something the reverter didn't intend and isn't caught until something fucks up on production.
I absolutely need to learn Linq. When I deliver the initial working version of the project I'm working on to the customer, updating it to use Linq will be one of the first things I do for the betterified version.
Speaking of, quick WPF question.
I'm still trying to wrap my head around data binding in WPF. I can do easily enough in simple cases, but what if say I have a user control, mostly consisting of a bunch of labels. Most of the labels are bound to different properties of a model I've got set as the DataContext. However I want one of the labels to display whatever the value of a particular dependency property of the control itself is set to.
Basically, the control looks something like this
So labels 2-3 are bound to properties of the model in the DataContext. What should {Some kind of binding} be in order for the first label to say "Buzz"?
Well that was informative. I'm taking the advice of someone in I should learn the basics know, and get better as time goes on. I still don't like the whole gotcha way of giving tests, but I'm better at understanding what the teacher is asking, and that helps.
Yeah I think they'll leave the Keurig but stop providing K-Cups. But yeah apparently people were stealing the K-Cups and it is at the point where they're just going to switch to regular coffee makers to prevent it.
Heh, I missed this. Had the same issue at my last job with people stealing k-cups. The morning radio show I listen to on the way in to work mentioned it a couple of years back as well. Their keurig machines had little monitors which counted how many cups were dispensed and the distributor guy said he was having to bring in 3 or 4 times as many k-cups as the machines had actually used. The cost was something crazy like $40k/yr worth of k-cups being stolen.
Drip coffee is the way to go if they'll pay for good coffee. We go through a few pounds of locally roasted beans every week or two at our office with a drip machine and then a little water heater pot to use with our pour over deals and aeropress.
I absolutely need to learn Linq. When I deliver the initial working version of the project I'm working on to the customer, updating it to use Linq will be one of the first things I do for the betterified version.
Speaking of, quick WPF question.
I'm still trying to wrap my head around data binding in WPF. I can do easily enough in simple cases, but what if say I have a user control, mostly consisting of a bunch of labels. Most of the labels are bound to different properties of a model I've got set as the DataContext. However I want one of the labels to display whatever the value of a particular dependency property of the control itself is set to.
Basically, the control looks something like this
So labels 2-3 are bound to properties of the model in the DataContext. What should {Some kind of binding} be in order for the first label to say "Buzz"?
Not sure if it's necessarily the best way to accomplish, but it's certainly a way, and fairly easy, but I ended up just setting the data context of the control to be the one thing, and the DataContext of the particular label to be the control itself. And from there the binding proceeded as normal.
So I'm going to start learning programming on the side because I think it will help me overall with my new job. The OP mentions python for scripting. Should I start looking into that and maybe one of the C languages (or Java)?
I'm a bit confused by the love for LINQ(caveat: never used it). That looks like composed reducers and frankly, I'm not a big fan of using libraries with specific syntax when simple composition would be enough. Maybe people used to it can find some happiness in having it available on another plaftorm if it's already in their toolbox, but otherwise, certainly not something I see value in picking up in javascript context.
I'm a bit confused by the love for LINQ(caveat: never used it). That looks like composed reducers and frankly, I'm not a big fan of using libraries with specific syntax when simple composition would be enough. Maybe people used to it can find some happiness in having it available on another plaftorm if it's already in their toolbox, but otherwise, certainly not something I see value in picking up in javascript context.
Think of it using relational terms in programmer.
Find this where this and that, give me them.
Instead of the normal logic:
Initiate a loop.
Loop through to a conditional, increment by a constant.
Match values to determine likeness.
Store for return.
Continue loop.
Am I finished?
Give values.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Your post makes me believe that I was a bit wrong and LINQ is actually probably a good idea for an abstraction and has a place in a lot of projects. Probably not for the reasons you pointed out;oP
What bowen said. Pretty much every programmer has written a SQL statement and understands what that looks like. It just applies that relational SQL terminology to collections. It cuts down a lot of the busywork in writing loops and iterators.
Posts
Should a front end engineer assume they are always going to get the proper data returned, and build their functions accordingly, to maximize performance, or should the front end engineer assume that the data will always be bad/wrong/missing and build everything so it fails gracefully, even at a small but noticeable performance hit?
Assume the user is a monkey smashing the keyboard.
Not the user, data from the back end system/server ajax requests. Sorry if I worded that poorly.
They literally are.
Unless you have ironclad validation or practices in your shop, the 2nd. You never know what's coming down the pipe, and penetration testing will tear apart anything that passes on nasty statements as valid if you don't limit them out.
Re: Coffee.
My old job used to do K-Cups. Except the garbage was getting more and more, boxes magically starting disappearing (people taking them home) and ultimately, it's just not very good coffee.
They brought in a new supplier, centralized a bunch of the machines that went from bean to coffee in front of you. As well as mocha/vanilla/hot chocolate in the same machine. Across 4 or 5 sites, getting rid of 50-75 machines and putting in 25-30 new ones, they were going to save almost $500,000 / year. FOR COFFEE. It was a huge win. Garbage went down, people liked the newer coffee better.
Coffee situation downtown is hilarious. :rotate:
Hope it turns out to be a false positive and we can get on with things soon.
The rule of thumb, as far as I'm aware is:
Sanitize input from every entrance to your package as soon as it comes in. If data is coming into your package from outside it, sanitize it. If data is traveling within your package, you can assume its correctness because any bad data will not get through the gates.
That being said, there are some input types which don't reasonably ever need to be sanitized. (If your package processes the input with its own internal logic, it's probably okay. If your package accepts arbitrary input and tries to parse it, it's probably not.)
Someone can tell me if I'm wrong.
If the data is coming from some service that's not part of the same project then yeah, check the hell out of it.
If you write a service that sends out inconsistent data with the logic that you'll double-check it on the front-end, please go fuck yourself.
It's an evaluation program. People fill out evaluations, submit them, then other's go and complete them. Sometimes people don't fill out all the fields because they aren't all required. Some of the evaluations are super old from before I took over the project, and they weren't requiring all the fields we currently are, so the data is incomplete, or 0's got put in instead of null values. So for every value I have to check to make sure that value existed before I blindly print it out to the page. Now I would assume you would want to do that ANYWAY because the resource cost for doing that sort of short ternary IE - ( this.data ? "None" : this.data) is super low, and it prevents display errors.
Does that make a bit more sense and less "OH GOD WHAT THE FUCK ARE YOU DOING?"
They're both under the same umbrella of "oh god why is that cat pissing blood?" sort of issue.
This is definitely a solution to some problems I've been having.
Right now instead of loading SNOMed codes on each client, I'm going to load it up into an array on the server, and deliver it to the client when they go visit:
http://ehrserver/sno/(searchterm)
so:
http://ehrserver/sno/hyper
Gives you every snomed that contains "hyper" in it's text.
http://ehrserver/snoid/53741008
Gives you the snomed that matches that.
Seems to be working better on the smaller scale so far.
How did I ever do anything before LINQ?
LINQ is civilization. I wish PHP had something like that native. There's a crude PHP object library that kinda sorta does some of the simple stuff LINQ can do, but I'm not sure if it's been updated in the last few years.
That's what I'm using.
It makes JavaScript bearable!
Maybe I just need to set a goal for myself of some kind. Something like: "Any time I am tempted to iterate over a collection, use LINQ to do it instead of foreach"
web.route('/sno/:qry') .get(function (req, res){ var query = req.params.qry.toLowerCase(); var results = Enumerable.from(snoList) .where(function (x) { return x.text.toLowerCase().indexOf(query) != -1 }) .orderBy(function(x) { return x.text }) .toArray(); console.log(results); res.send(results); })That's my code right now. So nice.
Anytime you iterator or translate a collection, LINQ is the answer.
Even turning 5 lines of a for loop into 1 line is the best thing ever.
Speaking of, quick WPF question.
I'm still trying to wrap my head around data binding in WPF. I can do easily enough in simple cases, but what if say I have a user control, mostly consisting of a bunch of labels. Most of the labels are bound to different properties of a model I've got set as the DataContext. However I want one of the labels to display whatever the value of a particular dependency property of the control itself is set to.
Basically, the control looks something like this
<StackPanel Orientation="Horizontal" > <Label Content="{Some kind of binding}"/> <Label Content="{Binding Thing1}" /> <Label Content="{Binding Poopy}" /> <Label Content="{Binding Butt}" /> </StackPanel>And the XAML for the thing it's getting used in looks like So labels 2-3 are bound to properties of the model in the DataContext. What should {Some kind of binding} be in order for the first label to say "Buzz"?Well that was informative. I'm taking the advice of someone in I should learn the basics know, and get better as time goes on. I still don't like the whole gotcha way of giving tests, but I'm better at understanding what the teacher is asking, and that helps.
Heh, I missed this. Had the same issue at my last job with people stealing k-cups. The morning radio show I listen to on the way in to work mentioned it a couple of years back as well. Their keurig machines had little monitors which counted how many cups were dispensed and the distributor guy said he was having to bring in 3 or 4 times as many k-cups as the machines had actually used. The cost was something crazy like $40k/yr worth of k-cups being stolen.
Drip coffee is the way to go if they'll pay for good coffee. We go through a few pounds of locally roasted beans every week or two at our office with a drip machine and then a little water heater pot to use with our pour over deals and aeropress.
Not sure if it's necessarily the best way to accomplish, but it's certainly a way, and fairly easy, but I ended up just setting the data context of the control to be the one thing, and the DataContext of the particular label to be the control itself. And from there the binding proceeded as normal.
Think of it using relational terms in programmer.
Find this where this and that, give me them.
Instead of the normal logic:
Initiate a loop.
Loop through to a conditional, increment by a constant.
Match values to determine likeness.
Store for return.
Continue loop.
Am I finished?
Give values.