andrewmccall

Do you embed the schema with every Kafka message? Otherwise you need to use some out of band method to distribute schema updates with avro

EU data protection regulations are in force. There will no doubt be some scrutiny as to what data safe harbour companies have transfered outside the EU and what steps were taken to protect it.

Far from giving up the EU is engaged in strengthening the directives far beyond what's required now: http://en.wikipedia.org/wiki/General_Data_Protection_Regulat...

Don't worry, they will.

I had the same question and it leads me to believe the companies saying they had no idea. Someone at Google/MS/Facebook would almost surely notice those extra servers over there, all that extra network traffic going somewhere, or those cables that seem to go into a locked closet.

I think it's far more likely this is built off the back of the data they're already known to be sucking down via major exchanges.

A national security letter for the TLS certs and you can take what you want, when you want off straight from the stream of packets.

This isn't true. Many people bike on footpaths and surfaces that are completely unsuitable for motorised vehicles. Almost anywhere you can walk you could ride a bike and cross the terrain faster.

If walking turns into scrambling or climbing the bike becomes a bit of a hinderance, but they're not that heavy and the benefits across most terrain outweigh the inconvenience. In fact on a bike you could probably avoid it altogether, not losing a great deal of time just going around.

You're not likely to still be travelling long distances long enough after whatever event that the roads and paths are in such a state of disrepair. You'd be talking years for that to happen and you probably would have had to sort out some sort of place to live and grow food long before you had to worry about it.

I'm not saying the tesla couldn't be better or that they couldn't learn something from Sony. But part of the author's complain was that he had one reading in the evening and when the temperature dropped overnight his reading the next morning was drastically lower.

Also a while a digital camera does get to spend some time outdoors it spends most of it's life in fairly people comfortable environment.

I thought that, then I installed nexus and let it proxy the remote repositories and really haven't looked back. Takes some time to setup (few hours). But makes life so much easier that it's well worth the effort, especially that with Java you WILL have a dependency on a 3rd party jar from Oracle that for whatever reason won't ever show up in maven central or want to include some other 3rd party repository.

I think it's the sheer size of the surge in demand that's unique. It's 1.5-1.75 million kettles going on at almost exactly the same time.

With 25 million homes in the UK that's 6% of them suddenly wanting another 1000w of electricity.

The same thing that happens now. Malicious user can recover/reset their password.

I'd assume that if you used the email to login and since the article talks about also using cookies with expiry dates in the future the codes in emails would be single use.

A lot of the time it's because the implementations haven't even been agreed between the different browsers.

I can't remember any specific examples off the top of my head but I do remember that some of the -webkit and -moz prefixes were ever so slightly different.

I think once it made it into the draft most browsers start supporting it using the standard css without any prefix.

For raw storage Hadoop beats an RDBMS, sure I'll buy that argument. It's not the same thing though and it doesn't do the same job.

Hadoop excels at data processing, trawling vast quantities of unstructured or semi structured data and extracting information from it. It's a poor platform for random access to specific elements of that data though.

RDBMS are great in exactly the places Hadoop isn't, getting access to random elements of data in a structured manner. Executing structured queries on that data. Things you know you'll do a lot of and can optimise.

There are column and table data stores built on top of Hadoop, and it can be argued that they could be used as an alternative to an RDBMS but they aren't drop in replacements and for the most part they're not meant to do the same job.

The most interesting uses of Hadoop aren't going to come from replacing existing RDBMS infrastructure with a Hadoop cluster. They're going to come from pushing data into a Hadoop cluster to process it. Collecting data that would otherwise be impossible to collect because it's either unstructured or there is simply too much to put in a RDBMS at a cost effective scale.

Hadoop and the NoSQL movement is exciting when you start to think about processing that data and pulling what's useful back out into your existing infrastructure.

Are they allowed to do this as a public company? Would their growth be attractive enough for someone to take them up on the offer?

This is likely the reason, and probably not just as a cheap work around, in most day to day situations it's probably the desired effect since both sticks are independent and don't move in reaction to the other.

GPS can only tell you how fast you're moving over the ground. It can't tell you how fast you're moving through an airmass that might be moving with or against you, this is far more important to keeping a plane in the air than how fast you're moving between point a and point b.

Except the client id has to be generated so that you know which client was authorised with it - in the case of something like Facebook or twitter, so you can revoke their access.

That means you have to agree on a way of exchanging that client ID.

Which at it's simplest is what OAuth 2 does with bearer tokens. If you have no use for the other parts of the spec then just ignore them, it's all optional and you only need to implement it if you need it.

The problem with OAuth1 was that the complicated crypto dancing around was exactly that, complicated. Making sure you're using HTTPS is hardly a big ask for developers on either the client or the server and frankly is probably a much better idea given most of these services are more likely than not sending some form of private data.

OAuth2 isn't just about bearer tokens and while the OAuth2 spec doesn't mandate using TLS the bearer token sub-spec does.

The reason is OAuth1 is painful, the double encoded and signature requirements are strict and so easy to get wrong that everyone has jumped on OAuth2. Unfortunately they've all jumped on different versions of the spec which keeps changing , because it's still a draft.

That's the big win I think this architecture has, it's already an API and already ready to create platform specific implementations.

It also makes a developer program something that's quick and easy to support, again the API is ready and waiting.

I think they're only really harder to develop in so much as it's more like developing two applications. One backend that throws out JSON/XML or whatever and a frontend in HTML/Javascript.

I actually find that bit easier, because I can separate out the the parts and worry about things a piece at a time. The other benefit of this is if you chose to develop for iOS, Android or any other platforms you already have an API. Equally if you wanted a developer program, again it's already there.

The complexity comes when you make the decision as to whether or not to support clients that can't or won't execute Javascript, if you want to make it work for them too you're stuck with more work and things do get more difficult.

As far as testing goes, there are plenty of mature javascript unit testing frameworks and if your inclined to unit test your javascript already this doesn't add a great deal of overhead. Your really just testing something in JS you would have otherwise done and tested server-side.

Look at the label on the fridge in the video. "Shit Burger"

I don't think they'd have the power to drag the users to a new service without them wanting to join - but they could highlight a new one quite prominently within TweetDeck.

A new service that has 20-30 percent of tweets from the start and many power users is off to a pretty good start as a twitter competitor.

In a way, for those reasons, it's a shame twitter have gobbled it up - but obvious why they'd want it.

I think not having to drive is a pretty good reason to use this. I'd love to be able to join a convoy and use my laptop, read a book or just nap.

On a 200 mile journey if you're doing the 60 trucks do instead of the 70 cars do you'd be 30 minutes faster at 70.

I wouldn't want to have to rendezvous at a time and place. That would kill this idea.

You'd also have to take into account people with small kids. I wouldn't use this if I had to stay in the convoy for the whole trip. I like to stop fairly frequently, otherwise the kids get bored, restless and upset.

I think it's likely only to work if you get on the motorway catch up to a convoy and then join it - Which I think is the way this works.

The OAuth 2 spec addresses some of these points by providing the user-agent flow.

The only place where it falls down some is when it comes to actually creating users. It's fine with one of the other flows because you can authenticate as an application with client credentials.

I made similar comments in previous posts about the TCK and why it's actually much worse than it seems.

The end result is that the only open source Java will be the 'Open' JDK - anything else gets any traction and it's open to being shut down without notice.

This is why we all need to get behind the ASF and support Harmony.

What separates this from continuous integration. As I understand it the article proposes testing the same build over and over again, well the same commit rebuilt and retested over and over again. Where do you benefit from this?

I could see a situation where tests running against a live system would be worthwhile, this is what I though when I saw the title.

Java for most startups won't be Java EE. My best experience with Java recently has been with Jetty as an application server. It's fast and it's lightweight.

I usually run Jetty behind nginx and don't generally need to configure Jetty to do anything.

The whole Tomcat and connectors for apache configuration from a few years ago is well and truly behind me.