In celebration of "Day Against DRM", Steven Levy has let it be known that O'Reilly will let you have the ebook edition of Hackers 25th Anniversay edition for 50% off.
Yeah, I don't like DRM but that's not what caught my attention. I was stunned that I didn't know there was a 25th anniversary edition of Levy's Hackers. I guess all my getting into guns thing these past few years have caused me to miss a couple of things. DRM... phooey. I just ordered the physical book.
Friday, May 4, 2012
Thursday, May 3, 2012
Oracle Database Vulnerabilities
7 Ways Oracle Puts Database Customers At Risk
Just one more reason we are making the move away from Oracle.
Just one more reason we are making the move away from Oracle.
Friday, April 6, 2012
Thursday, March 22, 2012
Tuesday, March 13, 2012
The Wisdom of Ruby
A co-worker pointed this out to me over at the Nokogiri page:
XML is like violence - if it doesn’t solve your problems, you are not using enough of it.Pretty much.
Monday, March 12, 2012
Sunday, March 11, 2012
Saturday, March 10, 2012
Monday, March 5, 2012
Ignore the Glaring Security Gap in Rails
Because, you know... that's what the Rails team does.
Looks like Rails has some pretty crappy defaults as far as security is concerned, and when this young programmer tried to point it out to them they told him it wasn't their problem.
So he defaced, ever so slightly, Github to prove the point. And now his account has been deleted.
Could he have been more patient with getting his point across? Possibly. Could the community have handled this better? Absolutely!
Here's the implication: if the Github team didn't think of locking down their webapp, its fairly likely that most of Rails-using-land hasn't done so either. Do you have a Rails app? If so, go check it.
Looks like Rails has some pretty crappy defaults as far as security is concerned, and when this young programmer tried to point it out to them they told him it wasn't their problem.
So he defaced, ever so slightly, Github to prove the point. And now his account has been deleted.
Could he have been more patient with getting his point across? Possibly. Could the community have handled this better? Absolutely!
Here's the implication: if the Github team didn't think of locking down their webapp, its fairly likely that most of Rails-using-land hasn't done so either. Do you have a Rails app? If so, go check it.
Trollop
If you've done some Ruby CLI development, you've likely tried to use OptionParser which is built in to Ruby. While it is full featured and very clever, I've found that in some cases it is just overkill.
If you want a simpler system, you might want to try Trollop. It's a nice, slimmed down alternative to OptionParser.
If you want a simpler system, you might want to try Trollop. It's a nice, slimmed down alternative to OptionParser.
Wednesday, February 15, 2012
Saturday, January 28, 2012
Thursday, January 26, 2012
Bad Citrix, Bad
I don't know what the major malfunction is at Citrix, but they have a 64-bit Linux download of their Citrix receiver that is a 32-bit executable. It is bad enough that the client uses Motif.
Anyway, if you run into this problem a fix can be found here.
Anyway, if you run into this problem a fix can be found here.
Sunday, January 22, 2012
IPv6 Adoption
Google has a graphic of IPv6 adoption by country. The United States, at 0.37% adoption is beat out by France (4%), Japan (1.51%) and Slovenia(?) (1.08%). It is interesting to note that we skunk Europe (other than France) and Canada. And by skunk I mean a faint peepee smell, because 0.37% is not really that impressive.
The Most Secret History of the Web
I've not seen a recalling of how the Web got started like this...
He credits the Web for the March 2011 Arab Spring. Perhaps he should have waited a couple of months, because things haven't exactly turned out great in the Arab world. And the Web (and personal communication in general) were active in Iran the year before but that led to a lot of blood shed. There is a missing ingredient with revolution that a lot of liberals don't wish to acknowledge: an armed populace. Bang, bang beats clicky, clicky.
There is one even the Web is widely credited with enabling, the 2011 London Riots.
He credits the Web for the March 2011 Arab Spring. Perhaps he should have waited a couple of months, because things haven't exactly turned out great in the Arab world. And the Web (and personal communication in general) were active in Iran the year before but that led to a lot of blood shed. There is a missing ingredient with revolution that a lot of liberals don't wish to acknowledge: an armed populace. Bang, bang beats clicky, clicky.
There is one even the Web is widely credited with enabling, the 2011 London Riots.
Thursday, January 19, 2012
Friday, December 30, 2011
Some Animals Just Won't Go Extinct
I posted back in August my thoughts on XML vs JSON, and since then I have to admit to warming up to JSON a lot more. The reason is simple, and by that I mean JSON is simple -- and it's not just JSON itself but the JSON ecosystem, which is also simple. As with anything good, people can't leave well enough alone and so we now have standardization efforts of JSON namespaces, schema, patterns, etc...
So when I saw that there was a binary encoding for JSON, BSON, I didn't know whether to laugh or cry. What is it about computer science that the same thing has to be reinvented five times? We must have a lot of idle hands, which I find odd considering programmers are still commanding good salaries in these hard economic times.
So for the love of all that is good, I ask that everyone stop it. JSON doesn't need anything it doesn't already have. There is no need for JSON namespaces or schemas or binary encodings. If you need those things, use XML or ASN.1 or something else that has already been tarted up.
So when I saw that there was a binary encoding for JSON, BSON, I didn't know whether to laugh or cry. What is it about computer science that the same thing has to be reinvented five times? We must have a lot of idle hands, which I find odd considering programmers are still commanding good salaries in these hard economic times.
So for the love of all that is good, I ask that everyone stop it. JSON doesn't need anything it doesn't already have. There is no need for JSON namespaces or schemas or binary encodings. If you need those things, use XML or ASN.1 or something else that has already been tarted up.
Wednesday, December 28, 2011
Software Development Developments of 2011
Interesting read for software developers:
Monday, December 26, 2011
The Year In Up and Coming Programming Languages
Rob Diana has an article about going over his predicted aspirations for 9 programming languages for 2011, and what happened to them. Some people put a lot of effort into the "next new" programming language. Keep in mind, such a thing was highly popular in the 1970's too. Though the history of modern computer science isn't long enough, perhaps this exploring-new-avenues thing is a cyclical trend.
Monday, August 8, 2011
Angle Bracket Backlash In Protocol Development: XML vs JSON
At IETF 81, I found myself in more than one discussion about XML vs JSON all of which had the tone "XML sucks, we are all moving to JSON". Having been in one or two angle bracket fiascos in my life, I understand the sentiment. But I just can't square the points being made.
First, there was a repeated talking point that JSON usage is for Python and Ruby on the server side, the unsaid implication being that XML can't be done in those languages. This is false; Python has, and has had for sometime, XML APIs. The same is true of Ruby, which does not have a built-in JSON parser unless one is considering JSON as a proper subset of YAML (more on this in a bit).
Beyond that, any talk of scrapping XML for JSON meanders to two other topics: a JSON schema language and namespaces. Officially, JSON has neither.
Schema languages are important for writing protocol specifications as they greatly help reduce ambiguity in prose. It is why the IETF has its own form of BNF. In some XML-based provisioning protocols, such as EPP, validation against a schema is a useful guard to prevent bad data being committed to a database. JSON does have a schema effort: http://jason-schema.org. However, the draft seems to have expired indicating that the effort is stumbling (let's hope I'm wrong and work continues).
Namespaces are important to stop protocol element collisions from separate specifications and are frequently used as a protocol extension mechanism. There are many proposals for JSON namespaces, the first I encountered being the Badgerfish convention. It works and provides all the functionality you get with XML namespaces, but I think it is fairly obvious that the results are just as bad, if not worse, than what you get in XML.
There are other proposals, such as using domain names (and there is an even simpler version of that, but I can't find the link). This proposal, and ones like it, boil down to always using the same globally unique prefix (more on why the dotted notation is not good in a bit). Anybody who has done their fair share of C coding would be familiar with the concept, which is why C++ has namespaces, Java has packages, Ruby has modules, etc... in theory it sounds good, in practice not so much.
The Rise of JSON
Truth be told, JSON's popularity comes from the fact that Javascript in the web browser easily handles JSON. If Java applets had ever caught on, perhaps we'd be talking about Java Serialization instead of JSON and RMI instead of Ajax (incidentally, Java Serialization has ready answers to the schema and namespace quandaries). This leads to some insight from Tim Bray:
If a Ruby developer were to do what comes natural to Ruby developers and serialize an object hierarchy with the built-in YAML engine, the result would not be digestible by a Javascript engine. The results would be specific to the Ruby object hierarchy and class structure, and the resultant syntax is probably not JSON compliant (all JSON syntax maybe YAML compliant, but the opposite is not true).
The results would be a little better with the Ruby program ingesting JSON, but it wouldn't be the "Ruby way", meaning user defined objects instead of an array or hash. However, such is possible with XML with a little code, as demonstrated here... which brings up the point as to why the dotted name syntax has problems: those dots disallow usage as an object variable (the same is true for XML elements with dashes, or minus signs, in them).
The Fall of JSON
In Googling around for JSON information, I noticed that a lot of the XML vs JSON discussions and JSON schema/namespace proposals are years old, thus giving me the impression that the movement forward on JSON has slowed considerably. This may not be true, but that's the impression I got. If so, let me offer this hypothesis.
JSON gained rapid popularity because of the heightened and new use of AJAX-like widgets on web sites, the client side being written in JavaScript. These things were hot stuff... three years ago. But nowadays mobile programming is all the rage, which means Objective-C for iOS and Java for Android and the natural nature of JSON evaporates on the client-side.
Conclusion
I hope this post doesn't make it sound like I'm an XML apologist. There are certainly a slew of issues with XML and a large number of misuses of it (SOAP, WS-Everything). Something new and better would be good, but the that new and better needs to have more clearly defined benefits than the merely subjective "Its just simpler."
Some Good Reads on This Topic
First, there was a repeated talking point that JSON usage is for Python and Ruby on the server side, the unsaid implication being that XML can't be done in those languages. This is false; Python has, and has had for sometime, XML APIs. The same is true of Ruby, which does not have a built-in JSON parser unless one is considering JSON as a proper subset of YAML (more on this in a bit).
Beyond that, any talk of scrapping XML for JSON meanders to two other topics: a JSON schema language and namespaces. Officially, JSON has neither.
Schema languages are important for writing protocol specifications as they greatly help reduce ambiguity in prose. It is why the IETF has its own form of BNF. In some XML-based provisioning protocols, such as EPP, validation against a schema is a useful guard to prevent bad data being committed to a database. JSON does have a schema effort: http://jason-schema.org. However, the draft seems to have expired indicating that the effort is stumbling (let's hope I'm wrong and work continues).
Namespaces are important to stop protocol element collisions from separate specifications and are frequently used as a protocol extension mechanism. There are many proposals for JSON namespaces, the first I encountered being the Badgerfish convention. It works and provides all the functionality you get with XML namespaces, but I think it is fairly obvious that the results are just as bad, if not worse, than what you get in XML.
There are other proposals, such as using domain names (and there is an even simpler version of that, but I can't find the link). This proposal, and ones like it, boil down to always using the same globally unique prefix (more on why the dotted notation is not good in a bit). Anybody who has done their fair share of C coding would be familiar with the concept, which is why C++ has namespaces, Java has packages, Ruby has modules, etc... in theory it sounds good, in practice not so much.
The Rise of JSON
Truth be told, JSON's popularity comes from the fact that Javascript in the web browser easily handles JSON. If Java applets had ever caught on, perhaps we'd be talking about Java Serialization instead of JSON and RMI instead of Ajax (incidentally, Java Serialization has ready answers to the schema and namespace quandaries). This leads to some insight from Tim Bray:
Seems easy to me; if you want to serialize a data structure that’s not too text-heavy and all you want is for the receiver to get the same data structure with minimal effort, and you trust the other end to get the i18n right, JSON is hunky-dory.I should point out that the "minimal effort" is when the language in use is Javascript. To better understand this, let us talk about that Ruby+JSON nexus mentioned above.
If a Ruby developer were to do what comes natural to Ruby developers and serialize an object hierarchy with the built-in YAML engine, the result would not be digestible by a Javascript engine. The results would be specific to the Ruby object hierarchy and class structure, and the resultant syntax is probably not JSON compliant (all JSON syntax maybe YAML compliant, but the opposite is not true).
The results would be a little better with the Ruby program ingesting JSON, but it wouldn't be the "Ruby way", meaning user defined objects instead of an array or hash. However, such is possible with XML with a little code, as demonstrated here... which brings up the point as to why the dotted name syntax has problems: those dots disallow usage as an object variable (the same is true for XML elements with dashes, or minus signs, in them).
The Fall of JSON
In Googling around for JSON information, I noticed that a lot of the XML vs JSON discussions and JSON schema/namespace proposals are years old, thus giving me the impression that the movement forward on JSON has slowed considerably. This may not be true, but that's the impression I got. If so, let me offer this hypothesis.
JSON gained rapid popularity because of the heightened and new use of AJAX-like widgets on web sites, the client side being written in JavaScript. These things were hot stuff... three years ago. But nowadays mobile programming is all the rage, which means Objective-C for iOS and Java for Android and the natural nature of JSON evaporates on the client-side.
Conclusion
I hope this post doesn't make it sound like I'm an XML apologist. There are certainly a slew of issues with XML and a large number of misuses of it (SOAP, WS-Everything). Something new and better would be good, but the that new and better needs to have more clearly defined benefits than the merely subjective "Its just simpler."
Some Good Reads on This Topic
- The Limitations of JSON
- JSON and XML - Tim Bray
- On Namespaces in JSON - Michael Hanson
- XML and JSON - James Clark
- Money Quotes: "You can't partition the world of information neatly into documents and data."
- JSON Namespacing - Kris Zyp
Subscribe to:
Posts (Atom)