|
tef posted:If you meet someone with a high stack overflow reputation, chances are they'd make a great copy editor. It is a game that rewards those who can cannibalise other peoples answers into a way that garners approval from the idiot who can't google. My experience is that Stack Overflow is awesome if you have a simple question. If you have a reasonably complex or obscure question, you're not going to get much help. I've asked 4 questions and only one has gotten a useful response that solved the issue. The others I figured out on my own. I still like answering questions, though.
|
# ? May 2, 2012 02:36 |
|
|
# ? Jun 10, 2024 11:38 |
|
I'd wager a quite significant chunk of the questions on SO are examples of the X-Y problem, but trying to ascertain this tends to lose you reputation. You earn more points for answering a stupid question, than you ever will for trying to work out the actual problem they're facing.
|
# ? May 2, 2012 02:49 |
|
Ithaqua posted:My experience is that Stack Overflow is awesome if you have a simple question. If you have a reasonably complex or obscure question, you're not going to get much help. I've asked 4 questions and only one has gotten a useful response that solved the issue. The others I figured out on my own.
|
# ? May 2, 2012 03:07 |
|
As a hobbyist who has maybe 5 years of hobbyist experience... I find answers on SO via Google all the time, but if I ask a question on there its not uncommon to not get a good answer. I think this is because all the easy to answer questions have already been asked.
|
# ? May 2, 2012 03:16 |
|
tef posted:Read the JSON rfc sometime, and see if you don't go wat. That does have the virtue of making escape sequences fixed width, so there's no possibility of ambiguity between the escape sequence and the following text.
|
# ? May 2, 2012 04:11 |
|
tef posted:I'd wager a quite significant chunk of the questions on SO are examples of the X-Y problem, but trying to ascertain this tends to lose you reputation. You earn more points for answering a stupid question, than you ever will for trying to work out the actual problem they're facing. Eric Lippert has answered a couple of my x-y questions by answering y, yelling at me for wanting to do it, then figuring out x and answering that That in of itself is pretty cool.
|
# ? May 2, 2012 04:16 |
|
I try to answer uncommon questions on SO, but then again I only have like 130 points/karma/epeen/whatever. I don't answer questions to get points and don't give a poo poo how many I have. Just help out your fellow devs and be satisfied in doing a good job.
|
# ? May 2, 2012 04:18 |
|
Fren posted:Douglas Crockford's shtick is really getting old.
|
# ? May 2, 2012 04:18 |
|
Suspicious Dish posted:Yep. Go look at his commit messages. They're all terrible. I shouldn't have to explain what commit messages are for to someone like Douglas Crockford: they're there to summarize a change, and more importantly, detail why it changed. Maybe instead of saying wrong things in the midst of character assassination you should stop and consider that you may be wrong. Here you are, saying things about the sanctity of commit messages that you have no particular reason to believe. Because guess what? It's not actually important to describe what a commit does. If you disagree, please name one person that was harmed by his commit messages. Here's why you are wrong. By making rules that commit messages must be long and detailed, you are causing people to make fewer commits! That's bad. Also, it takes time to do that, and if people want to look at the way the code works, they can look at the current version of the code. And if they want to know why it works that way, they can look at the comments in the current version of the code. The main useful purpose of commit messages is to provide a memorable title for a commit. That's 99% of the commit message value proposition: providing a title better than a SHA-1 hash. His commit messages work admirably for that goal. If you want to go back and look for what commits touched a certain type you don't do so by searching long and detailed commit messages. You use git blame. So what benefit does the long and detailed commit message have? Nothing! Nobody was hurt by his commit message. If you took out commit messages entirely, you'd retain 95% of the benefits of a version control system. If you limited commit messages to 140 characters, you'd retain 99.9% of the benefits of a version control system. Guess what: If your commit only changes comments, then your commit message should be "comments". Are you going to sit there and sperg about what comments you changed, and why? No, because that's a waste of time and completely retarded. code:
|
# ? May 2, 2012 04:23 |
|
If you don't give a poo poo about anyone else looking at your commits then yeah, commit messages are just irrelevant metadata. If the only people looking at your commits are developers, and they're only looking at them because something is broken then sure, git blame is the better solution than scrolling through commit messages looking for the relevant one. But poo poo, if someone tries to submit a pull request to anything I'm maintaining and their commit messages are garbage, I'm not going to look at their changes and try to imply the meaning of them. There's no reason not to use a commit message that in some way assists in knowing why the change was made.
|
# ? May 2, 2012 04:50 |
|
Those commit messages are all significantly worse than "comments" and are entirely worthless. They tell you absolutely nothing when looking at the commit log (and on projects with useful commit messages, I find looking at the log to be useful approximately all the loving time), and they tell you nothing when looking at the commit itself.
|
# ? May 2, 2012 05:07 |
|
Also if I saw a commit with the title "comments" my immediate assumption would be that it's a pile of unrelated functional changes along with a single comment since that's what people who can't handle spending a few seconds to write a short sentence per commit tend to do.
|
# ? May 2, 2012 05:13 |
|
pseudorandom name posted:That does have the virtue of making escape sequences fixed width, so there's no possibility of ambiguity between the escape sequence and the following text. Python's handling is much better. It has fixed-width for both BMP and astral, by using \u for BMP and \U for astral. \uFF5E -> always 6 characters \U0001D11E -> always 10 characters
|
# ? May 2, 2012 05:21 |
|
shrughes posted:Are you seriously defending lovely commit message practices, in the coding horrors thread of all places? ShadoX fucked around with this message at 05:30 on May 2, 2012 |
# ? May 2, 2012 05:21 |
|
Janin posted:Speaking as someone who's written three JSON parsers, no, the JSON encoding of astral characters has no virtue. It exists that way only to more closely resemble Javascript, which is not a goal any sane person should strive for.
|
# ? May 2, 2012 05:26 |
|
Plorkyeran posted:When the entire concept of your format is that it's a subset of Javascript, resembling Javascript is a pretty important goal.
|
# ? May 2, 2012 05:35 |
|
shrughes posted:Linus Torvalds thinks you're wrong. I know you don't care about Linus's opinions. I really couldn't care less myself. But his logic is sound: commit messages should contain the motivation behind the change. Maybe it's just a URL to a bug report. Maybe it contains a reference to the JS specification, and an essay or talk by Crockford showing why this JS feature is bad. Maybe it's a link to a graph showing a 20% speedup between this commit and the last. Maybe it's just the words "JSLint looks for ~~ and `~ in comments at the end of lines to allow certain kinds of behaviors. Two lines were incorrectly marked", because otherwise I can't even start to imagine what this was for. If I have a fork of JSLint that I'm shipping to my customers (which I can't really do because of the license, but whatever), should I cherry-pick this change? Janin posted:That's *not* the point of JSON, though. It may resemble JavaScript's object notation, but it isn't defined by the JavaScript spec. JSON is already incompatible with JavaScript in dozens of subtle ways, so there would have been no harm in adding a proper astral escape sequence. I only know of one subtle way that JSON isn't a valid subset, and that's the Unicode newline separator not being allowed in a string. It's more of an oversight than anything. Do you know of more? If you're talking about JS object notation not being exactly JSON, wrt. unquoted keys, of course. But there are rationales for every one of those. What you're suggesting would make JSON not a proper subset of JS. Janin posted:Especially if they could then go and add it to the JS standard. Crockford, if anything, is the guy who would be against adding anything to the JS standard.
|
# ? May 2, 2012 06:06 |
|
Suspicious Dish posted:Linus Torvalds thinks you're wrong. Linus may actually be hurt by lovely commit messages, considering what he does all day. Crockford's lovely commit messages don't hurt anybody.
|
# ? May 2, 2012 06:20 |
|
Janin posted:That's *not* the point of JSON, though. It may resemble JavaScript's object notation, but it isn't defined by the JavaScript spec. JSON is already incompatible with JavaScript in dozens of subtle ways, so there would have been no harm in adding a proper astral escape sequence. Especially if they could then go and add it to the JS standard. What are those incompatibilities, out of curiosity? And ES6 does have the proposed \u{xxxxxx} notation.
|
# ? May 2, 2012 06:27 |
|
shrughes posted:Linus may actually be hurt by lovely commit messages, considering what he does all day. Crockford's lovely commit messages don't hurt anybody.
|
# ? May 2, 2012 06:29 |
|
Thermopyle posted:As a hobbyist who has maybe 5 years of hobbyist experience... I find answers on SO via Google all the time, but if I ask a question on there its not uncommon to not get a good answer. I've never tried asking something on SO, but I suspect I'd have a similar experience. I've been thinking I need to start asking questions so I can answer them, just to get the solution/explanation out there. So many obscure things I've figured out, then soon after forgotten, lost to the world once again.
|
# ? May 2, 2012 06:51 |
|
Suspicious Dish posted:I only know of one subtle way that JSON isn't a valid subset, and that's the Unicode newline separator not being allowed in a string. It's more of an oversight than anything. Do you know of more? pseudorandom name posted:What are those incompatibilities, out of curiosity? The worst is encoding detection, though. JSON mandates that a document be encoded with UTF-{8,16,32} and specifies how to detect which encoding is used. JavaScript (as far as I know) does not specify this, and leaves it up to the browser to auto-detect based on the page's encoding (good luck including a UTF-8 script in an ISO8859-1 page!). pseudorandom name posted:And ES6 does have the proposed \u{xxxxxx} notation.
|
# ? May 2, 2012 06:59 |
|
This is presumably a legitimate optimization but it's still one hell of an if-statement:code:
|
# ? May 2, 2012 07:02 |
|
The big is using both .count and .length().
|
# ? May 2, 2012 07:04 |
|
Janin posted:To start, {} is a valid JSON document, but an invalid JavaScript expression. Janin posted:Numbers are different, in that [1e10000000000000] is perfectly fine JSON but cannot even be represented in JavaScript. Janin posted:Ditto [-0.0], which JavaScript treats as identical to [0.0]. code:
Janin posted:The worst is encoding detection, though. JSON mandates that a document be encoded with UTF-{8,16,32} and specifies how to detect which encoding is used. JavaScript (as far as I know) does not specify this, and leaves it up to the browser to auto-detect based on the page's encoding (good luck including a UTF-8 script in an ISO8859-1 page!). ECMA-262, Section 6 posted:ECMAScript source text is assumed to be a sequence of 16-bit code units for the purposes of this specification. Such a source text may include sequences of 16-bit code units that are not valid UTF-16 character encodings. If an actual source text is encoded in a form other than 16-bit code units it must be processed as if it was first convert to UTF-16.
|
# ? May 2, 2012 07:24 |
|
Janin posted:That's a silly notation; they'd be much better off adopting Python's. What, you mean \u verses \U? They can't, they've already defined them to be equivalent. Or do you want to break backward compatibility?
|
# ? May 2, 2012 08:42 |
|
Suspicious Dish posted:Many number formats can't be represented exactly in a machine native format, even ones like 0.1 and 0.2, yet we pretend that we can. [1e10000000000000] can still be parsed by JavaScript, even if it will resolve to Infinity. code:
pseudorandom name posted:What, you mean \u verses \U? They can't, they've already defined them to be equivalent. Or do you want to break backward compatibility?
|
# ? May 2, 2012 16:45 |
|
I don't know what JavaScript interpreter has that >>> prompt, but it is defective. JavaScript has positive and negative zeroes.
|
# ? May 2, 2012 17:51 |
|
pseudorandom name posted:I don't know what JavaScript interpreter has that >>> prompt, but it is defective. If the chrome dev tool console is a true javascript interpreter, [-0.0] is returning [0] for me.
|
# ? May 2, 2012 18:00 |
|
I get 0 out of every browser I punch it into
|
# ? May 2, 2012 18:00 |
|
The best way to distinguish negative zero from zero is to divide by it. Using the Chrome dev console:code:
|
# ? May 2, 2012 18:03 |
|
Yeah, it's purely a display issue, for some reason Chrome and Firebug both display -0 as 0.
|
# ? May 2, 2012 18:08 |
|
Janin posted:
It's a bit more complicated than that, actually. Mozilla has the incorrect behavior. There is a -0, it just isn't stringified as such: ECMA-262, Section 8.5 posted:Note that there is both a positive zero and a negative zero. For brevity, these values are also referred to for expository purposes by the symbols +0 and −0, respectively. (Note that these two different zero Number values are produced by the program expressions +0 (or simply 0) and -0.) ECMA-262, Section 9.8.1 posted:2. If m is +0 or −0, return the String "0". http://es5.github.com/#x8.5 http://es5.github.com/#x9.8.1
|
# ? May 2, 2012 18:11 |
|
Bhaal posted:In terms of data format I wouldn't say XML is necessarily a terrible way to go in this case, BUT: quote:A better solution, though involves a lot more dev time, is to make an editor for them. It's on the fly validation as you can have the editor demand input where input is required, generate required child nodes and so on, so your user doesn't get lost in the weeds on your data structures. Also they don't have to worry about syntax or any of that meta data and instead just fill in the pertinent stuff. You could do this in a native app or make a page that builds out form elements with js/jquery/etc, submits to your server, and you feed them back the resulting xml. Note: I don't know how much use those xml documents will see from your userbase, though, so putting in the time to make a tool like this may not be an efficient sub-project to work on if you don't anticipate a lot of user generated documents. If 1 in 10 of your dedicated userbase will ever seriously dabble in it, maybe it's best to provide clear documentation & examples and leave it at that.
|
# ? May 2, 2012 22:27 |
|
Contero posted:What do people think about Yaml? I haven't actually used it in a project yet, but it seemed nice enough. Belatedly, but I like it a lot. Used it as an editable file format for a few projects I did, to allow people to tweak and roll their own data. It's readable and comprehensible. Wish it had a wider mindshare.
|
# ? May 3, 2012 08:35 |
|
is there even a feasible way of looking at a file that big?
|
# ? May 3, 2012 16:17 |
|
Am I reading that right? Does that say 163 GB? There are some text editors that will handle large files, but I don't know any that run on Windows. The easiest way would be to write a small tool that split up the file into N-million-line chunks. The resulting chunks would still be large, but should be readable in standard mmap-based editors like Vim.
|
# ? May 3, 2012 16:32 |
Zorro KingOfEngland posted:
Should have set up some log rotation. Obviously, it can be analysed, as long as the software doing it is well-written, though I wouldn't want to do it over a network. If you only need to read entries from some particular date range, you could do a binary search in the file, assuming the entries are timestamped and timestamps are strictly increasing.
|
|
# ? May 3, 2012 16:34 |
|
Relatively minor but... We've partnered with a GPS vehicle tracking company, we poll them and get updates about where a client's assets are. Each update is timestamped DD/MM/YYYY. Recently, they decided to change that to MM/DD/YYYY without telling us. This results in strange numbers for the first half of a month, and broken updates after the 12th Not really 'horrifying', I'm just still amazed at the sheer lack of competence. (To be fair, I'll take part of the blame. I could have anticipated them screwing up and compared the current month to the month in the update, and if it was off, flipped day/month. Still...)
|
# ? May 3, 2012 16:43 |
|
|
# ? Jun 10, 2024 11:38 |
|
Zorro KingOfEngland posted:
Awk. Specifically mawk as gawk is sloooow.
|
# ? May 3, 2012 16:51 |