One way of looking at it is that S4 is to map-reduce what Streambase or Coral8 are to SQL.
In the enterprise software world, this is what's called CEP - Complex Event Processing: http://en.wikipedia.org/wiki/Complex_event_processing
411 karma · joined March 28, 2008
In the enterprise software world, this is what's called CEP - Complex Event Processing: http://en.wikipedia.org/wiki/Complex_event_processing
Gotta feel for the JetBrains guys, I have a feeling that a good chunk of their users are on Macs and it's not clear that they'll have a way forward. It does look to me like Eclipse will be a viable option in future. Which, as an IntelliJ fan using a Mac, doesn't make me super happy.
That said, I think the original article was spot-on.
So it is tolerant of partition and it sacrifices availability in favour of consistency. So it is CP, not CA.
If a node you can contact is required to guarantee consistency, there will be some times that it will have to refuse your request because other nodes are not contactable.
The author's point was that in any distributed system there is a non-zero probability of a network failure. While both clients and server nodes can retry connections, there is a non-zero probability that the problem will persist longer than your "availability agreement" allows. In that case, you have a choice - return potentially inconstent data or refuse the request.
What you seem to be arguing is that the probabilities of failure - in particular of repeated failure - while non-zero, are effectively zero. The author would disagree (as they point out, the probabilities combine exponentially as the number of nodes increase.) I think he's right and that you are wrong.
"Consistent sometimes" is not the same thing as "Consistent" and "Available sometimes" is not the same thing as "Available" - and so "Consistent and Available sometimes" is not the same as "Consistent and Available".
I believe you might be guilty of confusing "Eventual Consistency" with "Consistency".
Funnily enough, no-one has found much use for "Eventual Availability" so far.
In the first instance they've picked 17 sites with the explicit purpose of avoiding the kind of conflict described in the article - so they tend to be in front of office buildings etc. The process of handing out licenses for these sites by lottery initially produced some odd results but this seems to be sorting itself out in the wash - and we're starting to see some success stories.
It'll be interesting to see how the scheme can be expanded while still avoiding conflict - I think we may have a case of Portland-envy and won't stop until we can say Vancouver's scene is as vibrant as Portland's.
The whole area of BIAs and how well they represent the interests of local businesses is somewhat interesting to me right now, as it appears that BIAs are a primary force in opposing any kind of change in the city especially those that affect parking and car usage. Like, for example, better bike lanes.
Is it just not exciting enough?
I think static methods are OK for the same reason that not every object needs to be an implementation of an abstract interface, but you should be aware of the possibilities you are eliminating when you make that choice.
At first the machine did not even have a cassette interface, so there was no way to save programs and you had to type them in every time. The machine came with some examples, like Conway's "Life". Given that the machine really only had about 256 bytes of usable program storage (half the 1k was used for video) this wasn't quite as bad as it sounds but still pretty tedious.
Actually when I first got a cassette interface I still had to type the cassette loader in by hand to boot :( Eventually I got the rom expansion that included the cassette loader and an assembler.
Obviously writing a program directly into memory in opcodes does involve some upfront thinking, but you'd be surprised how "REPL-like" the coding experience could be :)
Luckily the 6502's instruction set is pretty easy to memorize, used to know it back to front. Only 56 base instructions and once you understand the way the addressing modes affect the opcode for LDA it's easy to work it out for the others.
Glad I don't have to do that anymore, but it was a great grounding for all the high-level stuff that came later.
(*Well, unless you count my dad's 31-step programmable TI calculator.)
FWIW, the compile time is still pretty long even with one compile permutation - and even while developing there is sometimes a need do do this (for example, changes to serialized objects.)
You do have to be able to stand Java, of course. The upside of the use of Java is that when you're dealing with a large codebase the kind of tooling you get from Eclipse or IntelliJ is a big timesaver when refactoring. Things like CssResources and UiBinders are also very nice to work with, and do really help with keeping logic and presentation separate.
Some would claim that GWT is a bit of a crutch for enterprisey developers who "don't like working in the browser" but I'd say it's more for people who like working in the browser but don't much like Javascript. (FWIW I like Javascript, at least The Good Parts.) You do at the end of the day have to have a good understanding of how the browser works and what it is and is not good at to get the most out of it.
The biggest downsides for me are, in no particular order...
1) Very slow compiler when generating javascript. GWT compilation is the biggest chunk of our build time but not the majority of our code.
2) For a large application, load time in hosted mode is still pretty slow. Also hosted mode has some funky performance characteristics especially around serialization.
3) It kind of annoys me seeing lots of code working around a lack of reflection in GWT's version of Java, when the underlying Javascript runtime is completely dynamic and reflective.
I do have a lingering concern that GWT might be exposed to similar patent risks as Android, since it subsets Java and could not be considered a "compliant" java implementation. Not the same patents as in the Android case, obviously - since they were mostly VM related - but who knows what else Sun had in their cupboard.
I think Twitter's position - that you should not have done this - is completely reasonable.
It's like when someone spoofs your credit card - the bank blocks it, and sends you a new one. Inconvenient, yes - but better than the alternative.
ISTM in a desktop app context, the consumer key/secret combination effectively becomes a complicated equivalent to your browser's "User Agent" string and yes, only slightly more difficult to spoof.
So what Twitter is asking for is that in order to authenticate a user (with additional credentials) you give them a valid "user agent" that was assigned by Twitter. This at least allows them to understand, when they get traffic, who wrote the app that's sending it. It's obviously not perfect in a desktop case but then neither is user agent - but there is no perfect solution for the desktop case, and Twitter's choice allows them use a consistent mechanism for client and server apps.
(Edit: the OA responds below and says I'm wrong about this part. I'll take his word for it.) I suspect the OA's problem is more with being a) asked to do this nasty complicated Oauth thing and b) with the idea of Twitter wanting to know who he is - and he'd rather they just let him keep on persisting user's twitter creds himself. Conflating this consumer key with DRM is a bit of a giveaway.
(Updated: The important point here is that the author's app is open-source and he chose to distribute the keys with the source code, rather than require each person who builds it from source to get their own API keys. I think Twitter's position - that the author should not have done this - is completely reasonable.)
I thought there was fairly universal agreement that while javascript has many strengths, its syntax was not one of them.
She's the first recommended follow for everyone.
Surprised how many people have failed to work this out - the "recommendations" are the same for everyone. There are basically 12 artist profiles in the whole system.
While marshalling of model objects to JSON is obviously going to be easier to achieve if your model objects are Javascript objects, marshalling to JSON is trivially achieveable in almost all programming languages.
To suggest that developers should - to achieve this microscopic payoff - choose to build servers using a language with a crippled concurrency model (i.e none) is laughable.
It's a convenience, at least intuitively, but in practice one has to wonder what parts of your code run in both browser and server and do async I/O.
(Basically the app currently fails quietly if the SSL certificate doesn't validate, rather than prompting for action.)
Interesting app though - have been a heavy user of Selenium for testing but building the scripts has been time intensive and generally is done by the QA team rather than by devs. If the UI for building these tests gets better, then devs may end up building tests for themselves rather than expecting someone else to do it.
I generally approach these kinds of methods with some skepticism - it is a bit 7-habits-ish - but one thing I did like about this one was that you could look at it as "design patterns for productive meetings", in that you could ask yourself what the goal of the meeting was and work from there to identify the right way to structure it. However I definitely attended too many meetings where the goal ended up being following the 6TH plan to the death rather than reaching a real goal.
So I appear to be target market for this product...