Yarnage

I'm pretty sure I've worked at this company. Haha

How can anyone take this article seriously when the author calls Scala a real language? Haha

This guy really has an axe to grind...he's also an idiot.

I like it!

The page is working.

I love Opera; it's incredibly fast (until the past few years Opera was king of the JavaScript speed) and very standards compliant. I hope this doesn't become a trend.

Dumb

This has annoyed me as a user. I use SkyDrive to back-up all of our images but I CANNOT do this while on my iPhone otherwise it thinks every image is the wrong date.

However, when I connect my iPhone to my Windows box and I manually navigate the photos the image taken date is still accurate. So I grab those instead.

It's a huge pain in the ass.

I love it. The author says Samsung copied Apple, someone pointed out that the software isn't Samsung's so, to try and save face, the author says but they bundled it.

lol

It was an RMA, not an extended warranty repair. But I agree with you anyway.

It's probably just a coincidence. Most electronics have a manufacturing failure rate so these things can happen.

Yeah I was surprised by those changes as well when I had to return something. The CSR I spoke to apologized then sent me a prepaid label and charged me no restocking fee.

So great customer service but the charges almost seem arbitrary when the CSR can just apologize and wipe them out...

I just threw up.

This seems like an issue only power users will have for the most part. Firefox even has an option to disable this for power users.

However, with that being said, I'm not a big fan. I think agumonkey's throttled loading is a nice idea though.

Everytime I've ever worked with Bluetooth as a user or a developer, it has always takes a little bit to pair before any data transfer can go. NFC can start data transfer immediately.

Am I missing something from Bluetooth 4.0 that can allow a transfer to start-up instantly? I feel like Bluetooth would be a really slow and hacky solution for payment not to mention it'll be open to attacks from anything with a Bluetooth device.

The same can be said for CoffeeScript (which I despise).

>>>Don’t get me wrong, Objective-C is better than C or C++, but I don’t think that’s saying a whole lot.

Objective-C better than C++? Wow, has this person ever used Objective-C and C++?

>What's vague about the question?

You asked nothing relevant to the conversation. Instead you asked about me ever working in a production environment and nothing more.

That questions accomplishes nothing but being insulting. I hate to sound crass but you're acting like an ass.

If you wish to bring something topical and relevant to the conversation then by all means do so but insulting someone gets nothing accomplished other than trolling...in which case you already won. Congrats.

>The point being that the things you sum up sound very much like textbook-knowledge and theory

No, they don't. Everything I stated is from real-world experience. I cannot fathom what kind of environment you work in where service to service communication includes comments going over the wire. But, as you can see above in my other responses, I've already covered all of these aspects. Nothing theoretical.

>You can claim all the experience you want, but your statements belie the truth. JSON is in no way limited to raw data interchange,

I never stated such a thing but that is what it's designed for and the primary use-case for JSON. I would imagine most other cases are edge-cases.

>and the files puppet manages cannot be put off to one side in some magical place where root cannot access them.

No one said to push them off to the "side" or into some "magical place". It's really simple: puppet has permissions to the files, your users do not.

A system administrator worth his salt isn't going to be messing with configuration files any which way and if said administrator has ROOT access then they should already know that's the level where puppet works and they could screw something up.

So I'm not really sure what your point was...

I made no assumptions and there is no need to be rude with your incredibly vague question. There are obviously better ways of asking and I'm sure you knew that (otherwise you would have asked a specific question).

>It appears that he is referring to JSON within the limited context of web APIs.

I was referring to JSON as an interchange format, which is what it is.

Arguably Amazon should have chosen something different for templates but I think that's an issue beyond simple comments and outside the scope of the argument. Regardless, it's hard to image anyone thinking it's a good idea to send comments over the wire especially if the end point is some sort of service.

>I'm forced to wonder from your comments throughout this thread whether you have much real-world development experience, versus having just ingested a bunch of theoretical information on best practices. The things you're dismissing out of hand happen all the time, and while sometimes they're useless, more often they're all the documentation you'll get, and you'll feel exceedingly lucky to get even them.

This is highly arrogant comment. There was no need to be rude. I've been developing and working with actual data for over a decade now. Yes, in the real world sometimes comments are transmitted over the line but I'm sure you can agree that isn't a good idea. Yes, many times you don't get good documentation but you make it sound like that's acceptable and anyone who thinks otherwise doesn't have real-world experience.

In all honestly I would expect comments generated from some odd software packages but it's been an incredibly long time since I've seen data transmissions that contain comments. In environments dealing with petabytes of data you can't afford to send comments with every single file.

As for Puppet, I think you misunderstand my point. Yes, it is a root-level tool. That doesn't mean any user should have the same permissions as Puppet. Why wouldn't you simply place configuration files people shouldn't modify in places where they don't have permission but Puppet does? Honestly, I thought that was standard practice.

That is something that MUST exist in documentation. If you're putting it within the configuration file itself it can go stale or simply deleted one day and you would have no idea what occurred after the fact without looking at a revision history.

I'm a bit puzzled by documentation seems like a bad word around here; it has its place and I'm not suggesting writing up a huge document. It takes only a couple of minutes to drop some text in Word / Google Docs / Wiki / your flavor and put it someplace accessible for your entire team.

>I'm much more apt to screw up the config if I have to look that up every time. That aside, it's really helpful to communicate to other people on the team that "this value is 768 MB because that's roughly 1/2 the total memory on this machine."

JSON comments would be a short-cut, sure, but that information should be within reach and should NOT only exist within the JSON anyway. So the helpfulness seems really limiting here.

>Re: transmitting annotated data. All I can say is not every application of JSON is for APIs for mobile devices. When I have a connected gigabit network and gzip data, I may not be that concerned about an extra 50 bytes of annotated data. But, again, that even presupposes that its only application is for computer-to-computer communication. The value in comments are human-to-human.

You're right in that the value for comments are human to human; I just cannot picture a scenario where you're actually transmitting data over the wire and including comments. I am not limiting this to mobile device; any service end point should ignore any comments and they will never be seen anyway.

As I mentioned before, if you're ingesting files in a very ad-hoc manner then of course comments could be useful but that's not a typical use-case of JSON. JSON is typically used as an interchange format for end point to end point communication and comments in ANY type of file in that scenario are useless.

>It's fairly common to annotate that data. While every entry in my postgresql.conf file is documented someplace, it'd be an absolute nightmare if defaults couldn't be commented inline or if I couldn't relay why a value is set to a particular value by adding a comment.

What happens when you accidentally delete a value you didn't mean to? You would refer to documentation. Honestly all configuration files _should_ be well documented, including postgres so I don't see the issue here. Why would you want to include every single possible option, probably commented out, when you could simply grab the ones you need from the documentation? I would prefer having a lean configuration file that shows exactly what I'm using rather than 400 commented options; that's a MESS to maintain.

>Even still, it can be handy to exchange annotated data over the wire.

I cannot disagree more. It is not useful AT ALL to exchange annotated data. Unless you're using an ad-hoc system (which obviously wouldn't scale), you're going to be handling this through APIs and services that already know and understand the JSON file format. So the only purpose of comments at this stage in the game is using up extra bandwidth.

>How does that follow? Usually "data", 5.23423, needs commenting more than most. What the hell is that? Why 5 decimal places?

You would already know the answer before seeing the JSON file so I'm not sure why you care.

For instance, you're not going to be receiving JSON data over email and then putting it into a system manually. Instead, you'll have APIs that handle the JSON formats for you and simply ingest the data.

If you're processing a large volume of data using JSON as the interchange format, why on Earth would you want it to include comments? No service on Earth does this that has any volume of users.

>Also comments in config files are for many things; when file was created, change history, by whom, who to contact with problems, warnings not to edit as it's managed via chef/puppet.

This is not the job of a comment. These go stale and all are available via whatever version control mechanism. However, keep in mind you're talking a very specific edge case in a development environment. Typically these don't matter, at all. If you need comments within the dev system for whatever reason, you can just strip them out. Puppet would obviously have appropriate permissions so no one can simply modify them anyway without knowing they're messing with puppet.

Shipping items, however, should simply have documentation regarding what configurations you product does or does not support.

>> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability.

>I do not read something on the lines of "you can also use a comment as a property". I wonder how you read that in the first sentence?

lol, please re-read my comment. I said the first COMMENT, not sentence, had the same suggestion.

:)

Article? It's only 5 short sentences and the idea to add it as a property is the first comment on the post.

This makes sense to me. JSON is designed to simply hold data so there shouldn't need to be any comments.

If it's related to configuration then there should be documentation regarding what is and isn't supported. If it's simply data you're sending across the wire then there should be documentation somewhere; you wouldn't want to waste bandwidth transmitting comments.

Error:

Problem at line 1 character 25: Expected exactly one space between 'function' and '('.

var crockford = function(){ while(1); }

Problem at line 1 character 27: Expected exactly one space between ')' and '{'.

var crockford = function(){ while(1); }

Problem at line 1 character 27: Missing space between ')' and '{'.

var crockford = function(){ while(1); }

Problem at line 1 character 29: Missing 'use strict' statement.

var crockford = function(){ while(1); }

Problem at line 1 character 34: Expected exactly one space between 'while' and '('.

var crockford = function(){ while(1); }

Problem at line 1 character 35: Unexpected '1'.

var crockford = function(){ while(1); }

Problem at line 1 character 37: Expected exactly one space between ')' and ';'.

var crockford = function(){ while(1); }

Problem at line 1 character 37: Missing space between ')' and ';'.

var crockford = function(){ while(1); }

Problem at line 1 character 37: Expected '{' and instead saw ';'.

var crockford = function(){ while(1); }

Problem at line 1 character 37: Unexpected ';'.

var crockford = function(){ while(1); }

Problem at line 1 character 39: Cannot convert 'array[0]' to object