I listed my project[1] there, but for some reason it's detected as having 0 issues.
Additionally my project is listed under JavaScript repos, while in reality it's both JavaScript and Ruby project, it just happens to have slightly more JS than Ruby code.
Now that would take the gray comments a step further by making them completely invisible :)
I can't really see the benefit of hunting the comments from your code with cursor. It definitely would make it even more unlikely that comments aren't updated when code is changed.
Neat, but it's still a very linear narrative, with the addition of having to type in commands to be able to read the next section.
Would have been much better if the review was exposed as an API which you could explore freely. And maybe some embedded silly programming challenges to be able to more effectively read the review. e.g. the example paragraph API could have just .nextChar() and .hasMoreChars() methods, so one would have to write a loop to comfortably read the example.
Opportunities are endless, though the book itself looks interesting.
I'm a bit disappointed, that the author didn't built a turing-complete interpreter. Frankly I've seen several of such articles which tell you how to build this kind of deterministic evaluator, but they all seem to stop before loops and branching.
And then there are articles about building compilers which do support loops etc, but the trick is that these constructs are implemented by some other already existing machine.
So I feel like there's some gap in my education. Pointers, anybody?
So what's the big difference of doing it on server side v/s client side? You can get it wrong on both sides.
Especially what's wrong with a templating system? A templating system on server side can help avoid casual escaping bugs by doing automatic escaping of everything by default. Exactly the same thing can be done on client side.
OK, I think I found the quote that is troubling you:
> It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers.
So basically we are talking about the case where users machine has been compromised? In such a case I don't really see how you can be sure of anything - that user is screwed.
At the same time the article suggests multiple ways of encoding the data on client side... I'm a bit puzzled.
Maybe what they really meant was that you shouldn't hope at server side that the client side correctly performed the encoding, like hoping the client will escape you database query arguments... but that's just basic everyday knowledge.
I've been switching between 2 and 4 spaces through my whole programming career. Even now I'm switching daily between different languages and projects with different amount of indentation. And I for one have noticed no correlation between bugs and amount of indentation. But I might be wrong - I have done no actual measurements.
What I can say though, is that there is a correlation between a lousily indented code and bugs. Consistency is the key in indentation. Reading non-consistently indented code, that's what drives you insane... but two instead of four spaces... hardly.
What struck me most was having multiple-choice answers on a math test... WTF?
You shouldn't be able to just guess the answers one-out-of-four. When I was in school (not in US) there never was such a thing. You simply solve the problem and write an answer, which usually is a simple number.
It's not really automatic interpolation. You have to very explicitly place the variable name inside ${var}. I'm puzzled in how you would think this will happen accidentally, or more accidentally than writing "+var+".
I've used Ruby quite a while and never experienced any problems with the very same construct in there.
I would argue the contrary, that the very reason why HTML took off so fast was that any fool was able to craft a site, and it would work even if it had a few bugs in it. Failure tolerance is a great feature. Especially if you consider it in the context of document authoring - for which HTML was originally designed for - it's better to read a document that has one unclosed <b> tag in it, than to be completely unable to read it because there's a syntax error in markup.
You seem to suggest that money is a better motivator than reputation. Money is a motivator, but it's often the wrong kind of motivator. Money can bring in people who do it just for the money. Especially as the money that any site can pay for it's experts is usually much-much less than the expert earns in its daily job.
I applaud that you have created a site that tries to compensate the effort to its contributors... I just hope that you have managed to tailor the site to avoid the problems that money can bring.
Care to explain how Linus got it wrong? I've never used Monotone, but searching the web I could't find a single thing in which Monotone was better than Git (although I did find information of the opposite kind).
3. For a limited time? 20 years is pretty much forever in the software industry. So sure you might start to look at alternative ways, but it can be quite hard when the obvious solution is patented. But often the patent attempts to cover the most general idea possible, so your entirely different implementation of the idea might still be infringing the patent.
But the main problem with software patents in particular is that you can never be sure if you're infringing something. You can only hope that you don't.
Do you know anybody who acquires new knowledge by reading patents?
1. Because of the legalese language in which patents are written it's pretty damn hard to even understand what is patented.
2. Even if you understand what the patent is about, it's probably of little help in implementing the thing by yourself, as the patent just describes the general idea.
3. If you indeed understand the idea, you might then come up with an improvement, but there's no benefit for you in publishing it, as the underlying idea is patented, the only one to gain from it is the patent holder.
4. You are encouraged by the system to not read patents, because if you happen to infringe one, your knowledge of the existence of patent can be used against you.
Well... you can do all these things when there's no DRM at all. It's like counting up all the things you can do in a new modern prison, but it's still a prison.
IMHO Github code search totally sucks. It's better than nothing, but it feels like the bare minimum - just a normal fulltext index applied to source code.
- It's not case-sensitive, which sucks for searching code.
- It's unable to search for any punctuation characters (searching for "foo()" is the same as searching for "foo"), which totally sucks for searching source code.
- The search finds lots and lots of duplicates. Even multiple matches in one file are listed as completely separate results.
- You can limit the search to one of the languages in dropdown menu, but if your language of choice doesn't happen to be in there, you're out of luck. For example you can't limit your search only to C header files.
Simply by adding package:github.com to Google Code Search search box one can apply a better tool for code in github, but unfortunately the good times seem to be over soon.
I listed my project[1] there, but for some reason it's detected as having 0 issues.
Additionally my project is listed under JavaScript repos, while in reality it's both JavaScript and Ruby project, it just happens to have slightly more JS than Ruby code.
[1]: http://www.codetriage.com/senchalabs/jsduck