Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:Not surprising at all (Score 1) 64 64

In my perfectly unbiased opinion, the two sets of intelligent and obsessed with money are very separated. If I got to choose one trait on which to guess who will be a good programmer, it would be someone who is interested in the subject.

Intelligence isn't enough to be good, you need to be motivated and being good requires a lot of motivation. CS/Programming is very unhindered in its ability to evolve, allowing for quick changes in short time frames. Programming is one sector where maintaining status quo means you're worthless. The theory that people learn in CS is great, but many can't abstract that theory well enough to apply to new situations. Almost all new "inventions" are just rediscoveries of something already known back in 1970.

The biggest annoyance I see is too many look at issues as cookie-cutter. I've seen too many people who I consider very intelligent and have a wealth of knowledge, but see everything as a nail. They can't abstract out the minor differences and try to shoe-horn too many issues. Like a person trying to view a Tesseract as a 3D object, they over complicate issues because they over-simplify the solution. Just add an extra dimension and the problem is simple, but they instead treat each view of the Tesseract as a new problem.

Comment Re:...actually that's kinda cool. (Score 1) 85 85

All of my $130 gaming monitors that I've purchased in the past year are 1080p. $200 is my general max for most any single part of a computer, with a bit of give for important parts. eg Maybe $220 for a CPU or $250 for 512GB SSD instead of a $180 256GB

Comment Re:If something like this slips through testing (Score 1) 54 54

Until some knob-head inserts an empty string into the database and breaks code that assumes empty will never happen. If something should NEVER happen, then make sure it never happens. That's the whole point of constraints in databases, forcing the business logic to at least conform to basic data model rules.

Comment Re:Wait, what? (Score 1) 54 54

The fact that the front end logic implements the business logic that handles password reset is a bad practice. The front end should call an internal API that has a signature like this "bool TryPasswordReset(string username, string resetCode, out userObject user)". If unccessfuly user is null, but if the try is successful, then user is a valid user object that can be passed into the change password API that looks like this "bool TryChangePasswordWithReset(UserObject user, string newPassword, string resetCode)".

This API could be unit tested to hell and back to make sure the business logic works, and it keeps the front end dev from making stupid mistakes that affect security.

Shit like resetCode being null, empty, or whitespace will throw a lovely exception that the front end dev should have checked for. Not to mention that resetCode must be a valid value.

Comment Re:They tell you to ignore it too... (Score 2) 54 54

I had a similar thing a month ago. I got an email that stated I got a password reset request. Just to test things, I logged out of Steam and logged back in. It said someone else from another IP "logged in" to my account, that was after I entered my original password. That left me confused. How could someone log in if my password was the same. I saw a reset request, but I never got an email that my password got changed.

I decided to change my password, and just to test things out I issues a password reset instead of just changing my password the normal way. I got the email saying a password reset was requested, then I changed my password and I got another email saying my password was changed.

since nothing was amiss, I assume that someone did not log into my account but only issued a password reset. This scares me. To me this indicates that the web page thought the Chinese IP address actually logged in. If I was to write a program to notify a user that an unknown IP logged into their account, I would tie that in with the authentication logic that on a successful login, an email get sent. Does this mean the Steam code that handles password resets technically calls a code path that authenticates as that user? Shitty programming is all I can say.

Comment Re:If something like this slips through testing (Score 1) 54 54

I can't say one way or the other for whatever you bug was, I like to do validation as much as possible in my code until there is a valid performance issue. Several times in the past few years I've had outside developers start using my code only to have their front-ends blow up with some helpful error messages. They would complain that my backend code was causing their frontend code to fail, but I explained that they were making undefined calls and my backend code was just making sure calls were being used in a way consistent with the envisioned data model.

I've gained a reputation for thoroughly checking edge cases that I am now "that guy" people go to first. This can be annoying because 95% of the time it's an issue with the frontend, but the person who made the frontend doesn't do any useful logging and lets default exception handling drop a "object null" error or whatever. Even the frontend devs come to me asking why their program is breaking. JUST PASS SOME VALID PARAMETERS! They're too used to things silently failing, leaving stuff in invalid states, but only causing errors when they attempt to use the invalid state.

My goal is that when using my code, it either works beautifully or fails spectacularly with a clear reason why. The sooner code breaks, the better. None of this code seems to work but something is in an invalid state and someone forgot the check the state. No, it goes BOOM and is never in an invalid state. All states are accounted for and how you can use something in a certain state is enforced.

A simple example is authentication. I've seen people write auth APIs where the programmer is supposed to request the user object, if found, then attempt to validate it. I don't do that. I let you pass in the auth data, and I'll pass back an immutable user object if the validation was successful. With the other way, I've seen programmers who have forget to validate the user object. oops.

Another example is SQL sprocs. Many programmers like to use internal identifiers. Yay incrementing integers, no chance of accidentally flipping around some arguments and still getting a valid response because those identities exist in more than one table. /sarc Nope, UniqueIdentifiers. Virtually no chance of accidentally passing in a UUID to the wrong parameter and not getting an error. But UUIDs fragment the index more quickly... boo freaking hoo. I'll worry about it when it becomes a performance issue.

Comment Re:If something like this slips through testing (Score 4, Interesting) 54 54

Obviously they don't unit test their failure cases, only their success cases. I've programmed many security APIs for stuff around validation and authentication, and there are many many more failure cases, but you need to test them all. My general rule of thumb is to unit test all edge cases I can think of.

The only thing more important than something working how I want it is for it to fail how I want it.

Comment Re:Gigabit speeds, though? (Score 1) 116 116

It depends on who is running those 1Gb ports. If they're a company that does not stream bulk data, then their ports will probably never be at capacity anyway. Your customers will still get 1Gb/s speeds, but only for the fractions of a second it takes to transfer their small web pages.

The company I work for only has a 2Gb connection to the Internet and hundreds of thousands of live connections at peak usage, yet our peak bandwidth is around 1.2Gb/s. Of course those 100K+, if they all had 1Gb connections could flood our connection if the data being transfers was sustained, but sustained is not a normal usage for us. All of our bandwidth is micro-bursts.

Many people write memos to tell you they have nothing to say.

Working...