The problem with RSS/Atom is not in the XML. It is in the HTML that is embedded within.
RSS was not designed for content to be embedded in it. It had a short-plain-text-only element. People started putting HTML in there. It broke XML structure. People started escaping that HTML. RSS 2.0 made that practice official.
The designers of Atom looked at RSS and saw that it was bad. They added an element for the content and specified that it can contain plain text, escaped HTML, or include XHTML as a sub-schema. The intent was, probably, that all good people will write valid HTML and serialize it as XHTML. It never took off. People are still writing invalid HTML and escape it in their feeds.
And that is the problem. People who are likely to write blogs are also likely to write invalid HTML. That is a basic fact and cannot be changed by choosing a different container.
Seriously, there is not much reason to want to store binary data in JSON. As a minimum, you want to tag that blob with a MIME type, so that other code will know what to do with it. And as soon as you do, you can represent that with a data: URI. Which gives you a choice of two serialization modes, quoted-printable and base64, both well specified and documented.
Do not touch the operational end of The Device. Do not look directly at the operational end of The Device. Do not submerge The Device in liquid, even partially. Most importantly, under no circumstances should you ^^/-#+$*./#^+\?
Imagine you’re writing a tutorial on, I don’t know, getting a list of repositories in a GitHub account and dumping their names and descriptions to the terminal. At the core, it is a single HTTP request: GET/users/:username/repos. You could probably trim the whole thing down to a shell one-liner.
But no, you want good practices. Let’s do it.
Our script will accept a user name and a configuration option for the API endpoint; that means some CLI argument parsing and --help handling. Check that the API root is a valid IRI. Validate and/or escape the user name for use in a URL. Handle DNS resolution errors. Handle TCP connection errors. Handle timeouts. Check if the HTTPS certificate presented by the alleged GitHub is well-formed, signed by a trusted CA, strong enough, valid for key exchange, valid at this point in time. Constant vigilance! Send the request. Check that the first line of the response is valid as an HTTP status line. Handle redirects. Not that there are any in the normal case, but you can never be sure! Be careful to not get stuck in infinite redirects. Check that the final status code is 200. Check that Content-Type is application/json (case-insensitively, after trimming any whitespace where allowed by HTTP spec and ignoring any unknown MIME type parameters). Parse the response, handle any UTF-8 decoding errors, handle any JSON parsing errors. Validate the parsed response against JSON Schema, handle any validation errors. Do not forget to sanitize the name and description against possibly malicious terminal control sequences before printing! Be sure to return a zero exit code in case of success and a non-zero in case of any error.
Tutorials do not write bad code. People write bad code.
A tutorial’s purpose is not to follow good practices in all aspects; such a tutorial would be unreadable. A good tutorial focuses on the one aspect being demonstrated, and, for the sake of exposition, intentionally neglects all other aspects, including, but not limited to, error handling, separation of responsibilities, access control, injection avoidance, naming, cache invalidation, etc.
The implicit assumption is always that you will apply good practices that you already know from elsewhere. You get that by (a) reading books (with wider scope than just a tutorial), (b) reading war stories in blogs (where neglecting a good practice led to a horrible vulnerability or a lengthy debugging session), and (c) participating in actual real-world projects collaborating with and learning from more experienced developers.
Please do not talk about "C/C++" as if it were a single language.
C is one thing. C++ is another thing altogether. In order to write good idiomatic C++, one has to unlearn many habits that are essential to a C programmer.
The problem with that graph is that its upper limits are completely unrealistic. 60ft viewing distance, that’s, like, viewing across a hall which is 6 standard dungeon cells wide! (And if you stand a 120in monitor on its corner, it will reach the ceiling.)
Find the point at 27in (this monitor being discussed), 2.5ft (normal viewing distance for a *computer monitor*). It’s close to the lower edge of the green 8K zone.
The problem is not limited to access points. Power strips, monitors, speakers, keyboards, mice — everything has a LED.
Some devices have options to turn off the LED when working, but insist on blinking said LED when in standby. Good luck turning your monitor to face the wall so that its blinking LED doesn’t disturb your sleep.
Start by agreeing on a common open federated protocol and common patent-unencumbered codecs for video and audio. Then and only then client and server software will follow.
This one is not a ridiculously high resolution monitor. At 3840×2160 39in, it’s just 113dpi, only a bit higher than my 2003 era 20in 1600×1200, or comparable with a 9in 1024×600 ASUS Eee.
For reference, Your 1280×800 at 20in gives just 75dpi. That’s quite low unless you’re a classic Mac user. (Macs traditionally assumed 72dpi; I don’t know how they work now. Windows, 96dpi in standard font size, 120 in Large Fonts mode. X11, whatever the monitor reports or the user specifies.)
A male-to-male cord seems to be a bad idea. Suppose you plug it into a wall socket before plugging into furniture; then you have an electrocuter device.
If you are going to need dedicated plugs/sockets for power source, you might as well switch gender on dedicated connectors.
Learn a language written in a non-Latin alphabet. Russian, Greek, Armenian. Get to know their historical character encodings — e.g. the Russian had cp866 in the DOS age, windows-1251 in pre-Unicode Windows age, and koi8-r for mail, because it had the desirable property of still being readable when a misconfigured mail server ate all your high bits. Converting between all these and UTF-8 is still a lot of fun.
Learn a right-to-left language. Hebrew, Arabic. Bonus points for Arabic because it is also a Complex script (has different letter forms depending on position in word). Understand the Unicode RTL algorithm.
Learn a Turkic language. They have the unique property that make Unicode upper/lowercase transformation language-dependent — namely, the small dotless i and the capital dotted I.
Learn a language written in a non-alphabetic script. Chinese, Japanese, to a lesser extent Korean. Experience the world of input methods and the pain of entering 4000 different characters with just 106 keys. See it cramped into an 8pt type.
Learn a language with many grammatical cases (as opposed to 1.5 cases in English). Latin, Russian, Japanese. Understand why one does not simply compose a UI message out of several separate localized strings.
Learn a language with a different set of plural forms. English has singular and plural. Russian has singular, dual and plural. Japanese has no plural at all, but they have counting suffixes — a strong typing system for numerals.
Learn a language that has concepts unheard of in English. Japanese has different words and patterns for talking to peers, to subordinates and to superiors, and they use all these three sublanguages on a daily basis.
Slashdot Mirror
The problem with RSS/Atom is not in the XML. It is in the HTML that is embedded within.
RSS was not designed for content to be embedded in it. It had a short-plain-text-only element. People started putting HTML in there. It broke XML structure. People started escaping that HTML. RSS 2.0 made that practice official.
The designers of Atom looked at RSS and saw that it was bad. They added an element for the content and specified that it can contain plain text, escaped HTML, or include XHTML as a sub-schema. The intent was, probably, that all good people will write valid HTML and serialize it as XHTML. It never took off. People are still writing invalid HTML and escape it in their feeds.
And that is the problem. People who are likely to write blogs are also likely to write invalid HTML. That is a basic fact and cannot be changed by choosing a different container.
> how do you store binary data?
You don’t.
Seriously, there is not much reason to want to store binary data in JSON. As a minimum, you want to tag that blob with a MIME type, so that other code will know what to do with it. And as soon as you do, you can represent that with a data: URI. Which gives you a choice of two serialization modes, quoted-printable and base64, both well specified and documented.
Do not touch the operational end of The Device. Do not look directly at the operational end of The Device. Do not submerge The Device in liquid, even partially. Most importantly, under no circumstances should you ^^/-#+$*./#^+\?
Imagine you’re writing a tutorial on, I don’t know, getting a list of repositories in a GitHub account and dumping their names and descriptions to the terminal. At the core, it is a single HTTP request: GET /users/:username/repos. You could probably trim the whole thing down to a shell one-liner.
But no, you want good practices. Let’s do it.
Our script will accept a user name and a configuration option for the API endpoint; that means some CLI argument parsing and --help handling. Check that the API root is a valid IRI. Validate and/or escape the user name for use in a URL. Handle DNS resolution errors. Handle TCP connection errors. Handle timeouts. Check if the HTTPS certificate presented by the alleged GitHub is well-formed, signed by a trusted CA, strong enough, valid for key exchange, valid at this point in time. Constant vigilance! Send the request. Check that the first line of the response is valid as an HTTP status line. Handle redirects. Not that there are any in the normal case, but you can never be sure! Be careful to not get stuck in infinite redirects. Check that the final status code is 200. Check that Content-Type is application/json (case-insensitively, after trimming any whitespace where allowed by HTTP spec and ignoring any unknown MIME type parameters). Parse the response, handle any UTF-8 decoding errors, handle any JSON parsing errors. Validate the parsed response against JSON Schema, handle any validation errors. Do not forget to sanitize the name and description against possibly malicious terminal control sequences before printing! Be sure to return a zero exit code in case of success and a non-zero in case of any error.
What was that tutorial about again?
Tutorials do not write bad code. People write bad code.
A tutorial’s purpose is not to follow good practices in all aspects; such a tutorial would be unreadable. A good tutorial focuses on the one aspect being demonstrated, and, for the sake of exposition, intentionally neglects all other aspects, including, but not limited to, error handling, separation of responsibilities, access control, injection avoidance, naming, cache invalidation, etc.
The implicit assumption is always that you will apply good practices that you already know from elsewhere. You get that by (a) reading books (with wider scope than just a tutorial), (b) reading war stories in blogs (where neglecting a good practice led to a horrible vulnerability or a lengthy debugging session), and (c) participating in actual real-world projects collaborating with and learning from more experienced developers.
Prolog does not “do”. It just “is”.
No they didn’t. We write in straigh C++, no “C/” about it.
This post is about getting started. A novice who thinks C and C++ are the same or similar may accidentally learn the wrong thing.
Please do not talk about "C/C++" as if it were a single language.
C is one thing. C++ is another thing altogether. In order to write good idiomatic C++, one has to unlearn many habits that are essential to a C programmer.
You would be right if it was a plan to protect the citizens’ privacy.
However the plan is to put Russia(n government) in a preferential position to violate said privacy.
> seriously, would you want your private information stored on a server in a foreign country?
YES PLEASE.
Seriously, would you, as a citizen of the Free Internet, rather have your private information stored on a server in Russia or in a foreign country?
Thought so.
If you don’t have a pointing device, the only thing you need about toolbars is a way to hide them, and that’s what the View menu is for.
They work in bash, but it’s a bit ignorant to call them “bash shortcuts”. Rather, they are Emacs shortcuts.
The problem with that graph is that its upper limits are completely unrealistic. 60ft viewing distance, that’s, like, viewing across a hall which is 6 standard dungeon cells wide! (And if you stand a 120in monitor on its corner, it will reach the ceiling.)
Find the point at 27in (this monitor being discussed), 2.5ft (normal viewing distance for a *computer monitor*). It’s close to the lower edge of the green 8K zone.
You’re saying that as if gaming and movies are the only uses for a computer monitor. Or for a computer, for that matter.
The problem is not limited to access points. Power strips, monitors, speakers, keyboards, mice — everything has a LED.
Some devices have options to turn off the LED when working, but insist on blinking said LED when in standby. Good luck turning your monitor to face the wall so that its blinking LED doesn’t disturb your sleep.
Start by agreeing on a common open federated protocol and common patent-unencumbered codecs for video and audio. Then and only then client and server software will follow.
Also, Slashdot, get real and learn not to lose Unicode.
-32 (resp. -27) degrees Centigrade.
...drop everything you’re doing RIGHT NOW and come here to Siberia. 32C today, 27 this weekend.
This one is not a ridiculously high resolution monitor. At 3840×2160 39in, it’s just 113dpi, only a bit higher than my 2003 era 20in 1600×1200, or comparable with a 9in 1024×600 ASUS Eee.
For reference, Your 1280×800 at 20in gives just 75dpi. That’s quite low unless you’re a classic Mac user. (Macs traditionally assumed 72dpi; I don’t know how they work now. Windows, 96dpi in standard font size, 120 in Large Fonts mode. X11, whatever the monitor reports or the user specifies.)
At that pixel count, I would want it in 15, maybe 20 inches, not 39.
http://abstrusegoose.com/531
A male-to-male cord seems to be a bad idea. Suppose you plug it into a wall socket before plugging into furniture; then you have an electrocuter device.
If you are going to need dedicated plugs/sockets for power source, you might as well switch gender on dedicated connectors.
Learn a language written in a non-Latin alphabet. Russian, Greek, Armenian. Get to know their historical character encodings — e.g. the Russian had cp866 in the DOS age, windows-1251 in pre-Unicode Windows age, and koi8-r for mail, because it had the desirable property of still being readable when a misconfigured mail server ate all your high bits. Converting between all these and UTF-8 is still a lot of fun.
Learn a right-to-left language. Hebrew, Arabic. Bonus points for Arabic because it is also a Complex script (has different letter forms depending on position in word). Understand the Unicode RTL algorithm.
Learn a Turkic language. They have the unique property that make Unicode upper/lowercase transformation language-dependent — namely, the small dotless i and the capital dotted I.
Learn a language written in a non-alphabetic script. Chinese, Japanese, to a lesser extent Korean. Experience the world of input methods and the pain of entering 4000 different characters with just 106 keys. See it cramped into an 8pt type.
Learn a language with many grammatical cases (as opposed to 1.5 cases in English). Latin, Russian, Japanese. Understand why one does not simply compose a UI message out of several separate localized strings.
Learn a language with a different set of plural forms. English has singular and plural. Russian has singular, dual and plural. Japanese has no plural at all, but they have counting suffixes — a strong typing system for numerals.
Learn a language that has concepts unheard of in English. Japanese has different words and patterns for talking to peers, to subordinates and to superiors, and they use all these three sublanguages on a daily basis.
If he asked for a trial and was given a fully functional version configured to act like a trial, there’s nothing wrong in reconfiguring it.
Ubuntu --> Kubuntu -(KDE4 happens)-> back to Ubuntu -(Unity and GNOME3 happen)-> Xubuntu.