jimfuller

I welcome this call to action and continue to believe that the open source approach provides the foundation for transparency ... though the red herring in this debate is the concept/notion of privacy.

The reasons why such systems are built and supported is that they check a lot of boxes for purely commercial reasons ... the scenarios that no one is talking about is the one where senators dip into the classified stream giving serious competitive advantage to actors in the free market.

Earlier efforts, such as ECHELON were just state sanctioned industrial espionage and what is going on now is just an extension of the same.

I am all for defending/upgrading the concepts of privacy and basic human rights, but as with many things ... the pragmatic solution is to make it very easy to 'follow the money' ...

thx, I think I understand what you are saying,

my (perhaps snarky) comment was more to do with 'why be so careful' with the potential data failure (that circus handily addresses) when data is being placed in a 'leaky bucket' (redis) in the first place.

just noticing the comment 'When a server is being stopped, we need to make sure we don’t lose any incoming data.'... the potential for data lose is already present with the use of redis server ?

I guess I am missing something.

agree with your sentiments,

I believe the issue that many people have with XML goes a bit deeper ... using XML means you are creating a bit of distance between yourself and the host programming language. XML stands alone, apart, that distance comes with costs in terms of ease of use (which could have been addressed by proper tooling), as well as many benefits.

HTML may not be pleasant to write documents with and I would say exactly the same thing of json ... show me the equiv of a Word document in json and I would argue that only a madman would like to directly edit that.

Really, James Clark said it right, 'json for data, xml for documents'.

Today's 'ease of use' of manipulating a native data structure of the 'language du jour' will eventually be viewed a bit more negatively in the years, decades to come. But really this is a storm in a tea cup ... XML has embraced json and has lots of support for generating it so I am fine. For others, they will eventually find the boundaries of json and start redeveloping the same concepts.

However, all the above being said/done I do think json is the right 'over the wire' format for data today; I just think we should embrace heterogeneity instead of 'knee jerk' cargo cult advice of 'don't use XML'; that's the equivalent of throwing tools out of one's toolshed and that's just plain stupid.

of course 'dont use xml'; unless your data mainly looks like documents, needs to handle mixed content, need to represent richer types and/or if you already have a robust, full featured, stable XML toolchain.

ya, my eyes gloss over when I read 'rediscoveries' like this ...

I think the finer point is more about workflow then programming.

That is state based workflow is fundamentally harder for developers to grok, also maintaining state is a kind of fallacy when scaling out and/or up.

Flow based workflows, while probably can't cover easily the breadth of exotic corner cases that FSM can achieve, are much easier to understand and state is byproduct of the system, not to mention that a full record of mutation occurs with a copy of data at every step (similar to MVCC - Multi-value-consistency-control)

This is similar to how http://www.w3.org/TR/xproc/ XProc works, which has a serious implementation in http://xmlcalabash.com/ and slowly gaining adoption in XML circles.

Its nice to see yet another XML technology, which of course is based on older established concepts in computing, being emulated/replicated in the JS universe ... shame about the visual programming antipattern/lunacy.

yes, a bit of a cheap shot that ... and the guy works at a company that makes MarkLogic server which spits out XML ... but it also spits out JSON (all at very large scale I may add) so choose your poison.

Until someone replies with the same experimental rigor to refute the findingsthen I think the observations this paper makes stands ... thats how peer reviewed journals work.

The paper is not saying 'XML is better' or even 'XML is faster' ... its just addressing the perception that XML is slow in certain scenarios which has become a default myth.

JSON has been accepted as a datatype in the Markup conferences of the world its great for data transfer, XML is a compromise on many different levels but tends to be good for mixed content and documents. I think we've all moved on.

the existence of a language should not be a threat, its ok for you to move on from Perl.

as one who is owned by a dog ... I will categorize this post under the 'bleeding obvious' epiphany ... cue 3 mths from now a new startup whose main product is 'puppies for productivity'.

really folks, I mean this in the best possible way ... get a life (and a dog).

I agree with you its ridiculous, but this was used by many 'back then' as evidence ;)

interesting commit, though its got a long way to go to match up to something like PostgreSQL (or at the other end of the scale, MarkLogic, for extremely mature structure/unstructured + text search).

from an impl pov I suspect the stemmer is the (logical) next step (of many) on this long road of implementing full text search features.

Agree with your sentiments, I won't be so nice though ... this article is stunning in its naivety and ignorance.

Perhaps the author realizes that for every successful startup there are thousands of failures; young people are being convinced (usually by clever older people with money) to use up that most precious commodity e.g. time.

An analogy I see is in the stock market; where hiring young (malleable) young guns to work 24/7 ... most of these people don't get wealthy, most of them burn out or used as responsibility fodder. Most of them don't enjoy their youth and end up regretting it.

as for the age bias in the article ..., lets hope a few decades from now that his article will be preserved for pleasurable reading later on in life as much wincing will ensue.

I love how some technologies cause some folks to get hostile ... HTML and XML are very close cousins in the same markup family.

On the basis of correct usage (e.g. not insane application of XML to corner cases) I don't fully understand the logic of people who profess love for HTML and hatred of XML, they are in the same family. The only difference is that HTML (now)is a controlled vocabulary, eventually folks will want to add markup of their own design w/o committee discussing the merits.

Perhaps next decade ;)

hehe, I like the denotation LEMs ...

the lack of being able to extend or define my own tags and attributes feels like a reduction in freedom to me ... but I guess it depends on your perspective. If you feel comfortable with browser companies and a small handful of ppl defining a rigid vocabulary for the world to use, that is your option; me ... I don't feel comfortable with that situation.

XML schemas are hard ... the xml suite of technologies certainly did not get it right the first time around, but slowly those 'hard' technoloiges get eaiser to use (either because of tooling or in XML Schema case we now have v1.1 with things like assertions that make validation a lot more useful and easier). In the meantime, I am certain that we will see every XML technology eventually will get regenerated and replicated within the JSON stack of tech.

Lastly, I agree that having a sanctioned vocabulary called HTML5 is a 'good thing' ... however saying that the world only needs one markup format is plainly incorrect, its akin to saying we only need a single spoken language; sure a lingua franca would make life (and processes) a magnitude simpler but hoping for this situation to actually occur is a real 'pipe' dream.

IMO, if a 'fallacies of data' type edict was to be handed down, then 'planning for homogeneity (lingu franca)' would be in the top 7.

'XML became terrible for all jobs' ... you do realize that there are literally hundreds of billions of xml encoded documents out there, happily doing what they are supposed to do ... not trolling; but lets put some of the comments in context for what they are.

XML in its original role of extensible markup is thriving and completely successful ... as I previously mentioned, I am glad we are not slinging around angle brackets and happily use JSON instead.

I agree that XML was hijacked during its hype cycle to do a lot of jobs it should have never been intended to do ... AJAX (see the X) was a side effect of this, and we moved on to AJAJ ... evolution sometimes needs different routes to get out of local maxima.

Note also that there is a very long tail of XML vocabularies that you will never use or hear about that get extended and reflect their authors intents, w/o nary an agreement required between you (or I) to get real work done.

HTML5 though is where I have the problem (in terms of XML Failure)... baked in controlled vocabularies ... hmmm, what happens when your tag (or attribute) du jour doesn't pass muster with the WHATWG ?

I console myself by saying that both XML and HTML5 are part of the same markup family, just a short term family dispute for the time being; never bet against markup (or data for that matter) as they tend to stick around a lot longer then the programming languages that generated them.

I could just as similarly ask why the author even mentions XML ?

XML, being in the markup family tree, has a lot more history then simple json encoding ... measuring its usefulness on a corner case has always been well ... boring. I am glad people are using JSON to sling simple data across the web versus markup.

Come back to me when you are using json to encode an entire document ... you might look at XML a bit differently.

tl;dr use the right tool for the right job.

nice introduction article (on mostly how to setup nginx); the title should reflect this instead of focusing on 'safe and secure' ... if one was to store something valuable (lets say cc info) you would want to go far beyond what this article covers. #justsayin

MarkLogic is looking for consultants and engineers

http://www.marklogic.com/company/career-opportunities/

knowing bigdata tech (hadoop) a big plus

I especially like the performance and real time query demonstration!

its easy to look at code out of context ... was the coder under duress, was he being asked to do a million things at the same time. Was he being paid enough to care ... i'm not making apologies, I think one of the worst things that can happen to a coder is you lower your own personal quality bar; but its easy to do if in the wrong set of context. I always recommend quitting before getting to that point.

Addressing some of the other comments; Perl and the Perl community itself is so far removed from macho ... its still one of the kindest, most intelligent and beneficial public communities online .... if someone feels emasculated by just reading someone's code; don't mistake that for the original coder's intent was to emasculate.

Perl is the programming language that I would want with me if the world was coming to an end (asteroids of course) and somehow I could help save it with getting the damn lasers to work to blow up the asteroids ... if it takes a 150 char regex then so be it.

I certainly would attend this ... Europe based best for me ... preferably Prague (which is a surprisingly good place for a conference).