Hacker Newsnew | comments | show | ask | jobs | submit | tav's comments login

I'vs been obsessively checking too, but for React Relay :(

-----


It's the server-side GraphQL for me :(

-----


Someone wrote a GraphQL query parser. https://github.com/madjam002/graphqlite There aren't any GraphQL servers yet though. Pretty hard to write too in a generic useful-for-all manner.

-----


Want to use out Relay ahead of the official release? See React Transmit: https://github.com/RickWong/react-transmit

It's basically Relay but using Promises instead of GraphQL to write queries. Transmit is coincidentally also a very efficient way to create isomorphic apps that can render on the server.

-----


Does this mean that those who hacked Target could have just added the card details to their own Stripe account and waited for Stripe to update the data once the banks got around to replacing the customer cards?

At least with my banks, when they send me updated cards, only a handful of the digits actually change and most of those changes have tended to be in the last 4 digits — which Stripe lets you see, along with the updated expiry month/year.

At this point, it's just a matter of brute forcing the remaining permutations. Am I misunderstanding something or are there countermeasures to protect against such attacks?

-----


Seems like you could just have it not work until a card has been on system for certain amount of time. That way people couldn't just upload card they stole? Would also make easy to detect those who uploaded stolen cards

-----


Well the brute forcing of it would be mighty suspicious: the number on the back has a 1,000 or 10,000 combinations. So that will be noticed, even if you got the first 12 numbers right on the first try. Also, theoretically, of the remaining 12 numbers, 6 should change with each new card, which is another 1,000,000 possibilities (and bigger banks may change more numbers than that)!

-----


The number on the back is generated by an algorithm with secrets that are not very secret (though apparently "secret enough").

-----


Click refresh (ctrl/cmd+R in many browsers) and then press cancel in the dialog box that pops up asking if you want to leave the page.

-----


Whilst the concept of setImmediate is nice, the current implementation in IE isn't properly integrated with the rest of the event loop — resulting in broken behaviour when you use it in combination with setTimeout [1], DOM events, etc.

In contrast, using MutationObserver results in correct behaviour on all modern browsers and relatively minimal delays — between 0.002ms and 0.007ms according to an OS X only micro-benchmark I did last month [2].

And, yes, it would be great if we could call a builtin instead of hacking on top of MutationObserver, but it isn't that ugly:

  if MutationObserver
    $div = root.document.createElement 'div'
    observer = new MutationObserver tick
    observer.observe $div, attributes: true
    scheduleTick = ->
      $div.setAttribute 'class', 'tick'
      return
  else
    scheduleTick = ->
      setTimeout tick, 0
      return
In conclusion, I agree that a feature like setImmediate would be great. But given IE's broken implementation and a viable workaround in modern browsers, I see no need to rush it. I'd rather they focused on: new features like Object.observe; improving the performance of old features like Object.seal; and finalising some of the ES7 ideas like exposing the event loop!

[1] http://codeforhire.com/2013/09/21/setimmediate-and-messagech...

[2] https://gist.github.com/tav/9719011

-----


A bunch of ZeroDivisionErrors doesn't look so pretty :)

-----


For anyone who wants this for themselves, here's a Python script [0] that generates similar output [1]. It doesn't have the nice Google Cache feature from ajani's version, but it does produce static HTML which some may prefer.

[0] https://gist.github.com/tav/5545779

[1] http://tav.espians.com/temp/hacker-news-top-1000.html

-----


Could you share links to those projects that you are following and elaborate on the ideas that has you excited?

-----


You are right. But the problem that institutions face is that as the sums of money gets smaller, the relative cost of doing due diligence on the idea/team gets significantly larger.

-----


Thanks for putting the works into the public domain Mikael! You should link to the actual license though: http://creativecommons.org/publicdomain/zero/1.0/ Thank you again and good luck with the effort!

-----


For any AWS folk on here, it'd be great to know how this fits with the consistency guarantees. Can we do strongly consistent index queries?

Also, any chance we could have strongly consistent auto-expiring keys in DynamoDB? Would make DynamoDB a very useful tool for synchronisation/lease management and other funky uses.

I also sent Werner an email asking if it would be suitable to use DynamoDB as a block device — you could then build a filesystem on top and benefit from DynamoDB features like replication, consistency, etc. Unfortunately, I fear the email must have slipped through his no-doubt-busy-inbox. If any of DynamoDB developers could shed any light on its suitability as a block device, that would be awesome! Thanks.

-----


> I also sent Werner an email asking if it would be suitable to use DynamoDB as a block device — you could then build a filesystem on top and benefit from DynamoDB features like replication, consistency, etc.

This. 100 times. A filesystem was my first thought when DDB was announced last year. I can't imagine it would be harder to build than GridFS was. [1]

That said, I'm not talking about a FUSE-like filesystem. More like HDFS or GridFS -- a blobstore+ if you will.

[1] http://docs.mongodb.org/manual/core/gridfs/

-----


DynamoDB is optimized for storing relatively small records on redundant fast SSDs. You would blow through all your read and write units instantly using it as a BLOB store.

-----


Well, that depends on your BLOBs, how you use them and what it's worth to you, doesn't it?

-----


My name is Jon, and I’m a member of the DynamoDB team. To your specific question about consistency guarantees, local secondary indexes support both strong and eventual consistency. The indexes are updated automatically when the primary index is updated.

For more information, have a look at our FAQ guide and Developer Guides.

http://aws.amazon.com/dynamodb/faqs/

http://aws.amazon.com/documentation/dynamodb/

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: