You don't have to worry about memory management, pointers and the like, and can just focus on the algorithms.
All that stuff it super important to also know, but probably easier to learn about them separately.
184 karma · joined July 14, 2009
You don't have to worry about memory management, pointers and the like, and can just focus on the algorithms.
All that stuff it super important to also know, but probably easier to learn about them separately.
I don't see a problem with using a regex to validate email, unless you get false negatives. Rejecting anything that could be a valid e-mail address is bad and will cause frustration for someone at some point.
I don't think allowing validly formed e-mail addresses that don't have corresponding accounts (or even domains - consider a web app working in offline mode) is a bad thing, especially when taken with point 1, as surely the point of client side validation is a heads up to the user that the data is wrong, rather than actual validation?
Her situation is that she visits family in Canada once a year. They won't make a note of her being out of the country if she calls them beforehand. The fraud people then call her if she needs to use her card at unsociable (for Canada) hours and never leave answerphone messages. When they do get her, they require her to answer security questions without identifying themselves first. If she calls them, the person she speaks to has no way of knowning if anyone has been trying to call her for any reason.
They are, in my opinion, the "Worlds worst Bank"
You get called by a computer that asks you to identify yourself by picking a piece of personal information from a list. It might ask for the month and date of your birth, for example, and give you 5 options.
Because there are 365 possible month + date combinations, and yours appears in the list, you know they already have this information so you're safe to confirm it, and they also get to confirm that you are (likely) who they're intending to talk to.
I foresee the next version being considered harmful.
That is, if my understanding is correct, they're taking user posted data and trivially turning it into a command to update data.
This doesn't sound like a problem with Rails, in the same way that if I turn data I receive from the user straight into an SQL statement, the fact that people can abuse it isn't a problem with SQL.
Umm... a 0.5em width m?
...oh, wait.
12:53:03.051 I [ap:1387] Connecting to AP B2.spotify.com:4070
12:53:03.054 I [ap:937] Connected to AP: 78.31.8.17:4070
12:53:03.073 E [ap:3280] Connection error: 404
12:53:03.576 I [ap:1387] Connecting to AP B1.spotify.com:80
12:53:03.609 I [ap:937] Connected to AP: 78.31.8.15:80
12:53:03.629 E [ap:3280] Connection error: 404
12:53:03.810 I [ap:1387] Connecting to AP B3.spotify.com:443
12:53:03.840 I [ap:937] Connected to AP: 78.31.12.9:443
12:53:03.913 E [ap:3280] Connection error: 406
12:54:25.855 I [offline_authorizer.cpp:156] Unable to login offline: no such userYou ask how we'd tackle the problem, but I don't know how anyone can answer that without knowing what the problem actually is.
This might have been communicated, or evident, outside of this memo, but it sounds like he's trying to fix a problem that doesn't necessarily exist, based on questionable metrics.