Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Null

popey.com

Post reply on HN
Print view View original

181–190 of 196 posts

Re: Null

#181

Post by chenglou »

munificent wrote: post #162

> I went through a phase a while back of holding down keys to see what they did. Back when I was a gamedev at EA, one of the things QA would do is button-mash test the games. Just smash as many buttons as they could at the same time at all sorts of random points in the game. This was a constant source of bugs. It was surprisingly easy to get the game into a state where it was totally hung because of this. One of the…

No good generalized solution for this it seems. The best you can do is to specialize per situation and leverage all the assumptions you can while being cautious not to leverage the assumptions you can’t.

This problem contains lots of incidental complexity and it doesn’t help that folks do the opposite of the above and add a ton of accidental complexity on top. For example, for a situation with a crossfade or morphing set of 2 buttons you should:

- leverage the assumption that there are only 2, and static, buttons. - not assume that there are only 1 button present at any time.

Some end up inclined to create some “reusable” abstraction on top and end up doing the opposite: - generalize to handling n dynamic buttons. Without realizing that some important properties of that specific situation would have been lost. - (usually due to the lack of experience/focus/interest on the problem) oversimplify and assume there’s only 1 button present at any time.

Re: Null

#182

Post by marcosdumay »

staticassertion wrote: post #144
marcosdumay wrote: post #119

Earlier quoted context omitted.

You can do some actually useful stuff with a real type system, instead of replicating Perl's stupidity. For example, you can convert the input into a safe representation, suitable for the exact place you'll be using the string, instead of "validating" it.

This is what I was referring to at the end of my post: > Few work directly on strings. But they do it naturally, without enforcement - so like, a function might take a 'str', but the 'str' passed in was parsed into a wrapping structure already. ie: Most programs in typed languages already do what you're saying - they parse the data directly into a structure, and therefor they validate some aspects of it naturally, so…

Hum... Your sibling has a nice explanation of what I was trying to say.

You don't sanitize user input when parsing, you do it on usage. "Robert'; drop table users--" is a perfectly fine name and you shouldn't mangle it on you data fields.

Re: Null

#183

Post by snoshy »

diamondo25 wrote: post #166
munificent wrote: post #162

> I went through a phase a while back of holding down keys to see what they did. Back when I was a gamedev at EA, one of the things QA would do is button-mash test the games. Just smash as many buttons as they could at the same time at all sorts of random points in the game. This was a constant source of bugs. It was surprisingly easy to get the game into a state where it was totally hung because of this. One of the…

If it was up to me, there were no transitions. I am happy I can disable them on Android... Everything that does or manipulates animation is terrible. Scroll hijackers, image carousels, icon transitions, they are all wasting cpu cycles to please UX/designers!

I'm glad there's at least one other person vocal about doing this. I use a several-year-old Android phone, and when anyone new sees me use it, the first thing they ask is what phone it is and if I just bought it.

Those animations were for a time and place where phone processors were genuinely slow. That time and place is nearly a decade ago, and most of the world is stuck with lower productivity due to this vestigial cruft.

Think of all of those teens that can type a billion letters a minute without batting an eye, and yet have to unwittingly endure all of these silly transitions...

But of course, it breaks a whole bunch of poorly tested apps, even mainstream ones like Uber and Lyft.

Re: Null

#184

Post by pitay »

david422 wrote: post #142
msh wrote: post #28

Earlier quoted context omitted.

Why do you require software to be more resilient than other things? If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?

I think the answer is - because the software can. And most of the time, the software can be more resilient with a trivial amount resource usage. If there was a physical device that could filter gas and non-gas liquids that could be installed in a car we would expect car manufacturers to do that. I have seen software that puts the onus on users to use it correctly "Hey user, don't enter more than 5 items in this list"…

If there was a physical device that could filter gas and non-gas liquids that could be installed in a car we would expect car manufacturers to do that.

There is one thing they could do to stop people putting the wrong liquid in their car. That is to key the nozzle to only fit cars which support their fuel, so petrol pumps nozzles only correctly fit petrol cars, diesel pumps only fit diesel cars.

Completely agree with you on you main point, software should be made correct and resilient (more than other things) because it can be made so.

Re: Null

#185

Post by staticassertion »

marcosdumay wrote: post #182
staticassertion wrote: post #144

Earlier quoted context omitted.

This is what I was referring to at the end of my post: > Few work directly on strings. But they do it naturally, without enforcement - so like, a function might take a 'str', but the 'str' passed in was parsed into a wrapping structure already. ie: Most programs in typed languages already do what you're saying - they parse the data directly into a structure, and therefor they validate some aspects of it naturally, so…

Hum... Your sibling has a nice explanation of what I was trying to say. You don't sanitize user input when parsing, you do it on usage. "Robert'; drop table users--" is a perfectly fine name and you shouldn't mangle it on you data fields.

We're saying the same thing.

Re: Null

#186

Post by mleonhard »

sethammons wrote: post #116

Reminds me of a QA buddy. One day at the crosswalk, he decided to, I believe, hold the button. For the whole wait. He apparently broke the entire intersection’s lights and a repair crew came out. He was unable to reproduce it after.

Maybe it was working as intended? If a crosswalk button becomes stuck, it's reasonable to switch the intersection to "safety mode" so people can still cross the street.

Re: Null

#187

Post by thih9 »

rkangel wrote: post #143
thih9 wrote: post #139

Earlier quoted context omitted.

> Good testers just think differently than software engineers. I'm sure in some cases it's useful to detect all possible crashes, e.g. to make an app as secure as possible. In other cases I'd watch out for diminishing returns; perhaps instead of "think differently than software engineers" it would be enough to "think in the similar way as product users".

There's a consideration about number of users. If 100k users are using your product a lot, in a similar way to the 'million monkeys' thing they're accidentally going to find bugs. Software engineers tend to use products in a consistent way (based on how they know it's meant to be used) whereas good testers explore the space of possible inputs in a much more 'creative' way.

> good testers explore the space of possible inputs in a much more 'creative' way.

My point is that the extent of testing should depend on the actual product; eliminating all bugs is not the primary goal of every team.

Some companies might decide on other goals and prioritize e.g.: just paying users (giving them better support to resolve issues), or acquiring new users, or something else.

Re: Null

#188

Post by CRConrad »

mcosta wrote: post #114
iforgotpassword wrote: post #34

Earlier quoted context omitted.

Holding down the button for your hazard lights should not break your car. Holding down a key should not crash an app.

Holding down a pedal probably is going to crash your car.

I think I can sit in my car with a foot on the brake pedal all day long and it won't break the car.

Your proposed problem will probably only affect bad spellers, who have a break pedal.

Re: Null

#189

Post by CRConrad »

FalconSensei wrote: post #174
enobrev wrote: post #123

Earlier quoted context omitted.

With physical things, if I do something stupid, I blame myself. With software, if it allows me to do something stupid, I blame the software. Unfortunately, the same mindset carries for clients, employers, and other various people using software who will report said stupidity to me, my client, or my employer.

Like, putting water on the gas tank is obviously wrong, as it's called a gas tank, and gas cars don't tend to run on water. Clicking a button that was enabled for me and does many things in the background is not so obvious. Also, cars have been accessible to everyone way longer that PCs and smartphones. Most people alive today (in developed countries/areas) saw their dads driving when they were kids. A person in thei…

I think not even most people in their fifties did. Forties, maybe.

Re: Null

#190

Post by fallingfrog »

I laughed out loud when he said he held down the print screen key until it started repeating. That’s exactly the kind of thing a user would do but a developer would never think of!
Post reply on HN