3 ms·

Show HN: Dweet.io – Twitter for machines, now with alerts

47 points by gdilla 12y ago

Bug_Labs 12y ago
Thank you for the follow up post! Here is a direct link: http://beta.dweet.io http://beta.dweet.io
- MrSaints 12y ago
  I've been using Dweet for some time on a lot of different fun and hacky projects, I just wanted to say good job!
  - Bug_Labs 12y ago
    Thank you for the support!
michaelmior 12y ago
The link should probably be directly to the post http://buglabs.tumblr.com/post/94633748906/dweet-tm-now-with-real-time-alerts-and-notifications http://buglabs.tumblr.com/post/94633748906/dweet-tm-now-with...
- gdilla 12y ago
  argh, sorry about that. can't edit it :(
  - michaelmior 12y ago
    No worries. Just dropped that in there in case dang sees this thread. Or at least it's here if someone finds this in the future.
    - dang 12y ago
      Thanks! We changed it.
jschulenklopper 12y ago
Nice! At first, it looked a lot like https://data.sparkfun.com/ https://data.sparkfun.com/ which hosts a similar service. (Sparkfun made all the code available with an OSS license at https://github.com/sparkfun/phant. https://github.com/sparkfun/phant.) But it seems that Dweet.io adds subscriptions and alerts to the mix - actively pushing data out to subscribers or when certain conditions are met. That's a nice addition.
azdle 12y ago
Full Disclosure: I work for a competitor of theirs as an embedded engineer. Question for any bug labs people. How are you guys running the alert code? I assume it's something long the lines of a node sandbox that just runs the bit of JS, I've only looked into that stuff breifly. I was also looking at using really light weight interpreter called Duktape for a personal project. It has got a really similar C interface to Lua, but that ended up being way too much work and I abandoned it. I also recently found an erlang js interpreter that looked really interesting too, can't remember what it was called but it was from one of the erlang nosql databases, they used it for doing map reduce. Also, why did you guys decide to go with chunking for the push over something like long polling or websockets? I assume the websockets was because of device code complexity, but longpolling seems more standard/less of a hack to me. I always love seeing how others implement these kinds of things.
- jheising 12y ago
  Hey azdle, thanks for the question and being honest. Do you mind me asking who you work for? Just curious more than anything. To answer your questions about the alert code, yes it runs in a sandbox, but we also parse it and take it through a pretty lengthy pre-check process to weed out any code that might cause performance bottlenecks or general security problems. As for websockets, we actually do support them (well, technically socket.io) but just don't make it very clear in the documentation. If you take a look at our open-source javascript client (https://github.com/buglabs/dweetio-client/blob/master/dweet.io.js#L367 https://github.com/buglabs/dweetio-client/blob/master/dweet....) you can see that we're actually using it there. Hope that helps.
  - azdle 12y ago
    Sure, I work for Exosite[1]. I'm mostly curious about this because we're working on getting something similar into our API right now (the subscribe part, scripting has been there for awhile now) and I've been thinking a lot about this stuff recently, I've probably been pushing the most out of anyone here. Did you guys have a reason for going for chunked over long polling though? [1]http://exosite.com http://exosite.com

47 points by gdilla 12y ago

Bug_Labs 12y ago

Thank you for the follow up post! Here is a direct link: http://beta.dweet.io http://beta.dweet.io

MrSaints 12y ago
I've been using Dweet for some time on a lot of different fun and hacky projects, I just wanted to say good job!
- Bug_Labs 12y ago
  Thank you for the support!

michaelmior 12y ago

The link should probably be directly to the post http://buglabs.tumblr.com/post/94633748906/dweet-tm-now-with-real-time-alerts-and-notifications http://buglabs.tumblr.com/post/94633748906/dweet-tm-now-with...

gdilla 12y ago
argh, sorry about that. can't edit it :(
- michaelmior 12y ago
  No worries. Just dropped that in there in case dang sees this thread. Or at least it's here if someone finds this in the future.
  - dang 12y ago
    Thanks! We changed it.

jschulenklopper 12y ago

Nice! At first, it looked a lot like https://data.sparkfun.com/ https://data.sparkfun.com/ which hosts a similar service. (Sparkfun made all the code available with an OSS license at https://github.com/sparkfun/phant. https://github.com/sparkfun/phant.) But it seems that Dweet.io adds subscriptions and alerts to the mix - actively pushing data out to subscribers or when certain conditions are met. That's a nice addition.

azdle 12y ago

Full Disclosure: I work for a competitor of theirs as an embedded engineer. Question for any bug labs people. How are you guys running the alert code? I assume it's something long the lines of a node sandbox that just runs the bit of JS, I've only looked into that stuff breifly. I was also looking at using really light weight interpreter called Duktape for a personal project. It has got a really similar C interface to Lua, but that ended up being way too much work and I abandoned it. I also recently found an erlang js interpreter that looked really interesting too, can't remember what it was called but it was from one of the erlang nosql databases, they used it for doing map reduce. Also, why did you guys decide to go with chunking for the push over something like long polling or websockets? I assume the websockets was because of device code complexity, but longpolling seems more standard/less of a hack to me. I always love seeing how others implement these kinds of things.

jheising 12y ago
Hey azdle, thanks for the question and being honest. Do you mind me asking who you work for? Just curious more than anything. To answer your questions about the alert code, yes it runs in a sandbox, but we also parse it and take it through a pretty lengthy pre-check process to weed out any code that might cause performance bottlenecks or general security problems. As for websockets, we actually do support them (well, technically socket.io) but just don't make it very clear in the documentation. If you take a look at our open-source javascript client (https://github.com/buglabs/dweetio-client/blob/master/dweet.io.js#L367 https://github.com/buglabs/dweetio-client/blob/master/dweet....) you can see that we're actually using it there. Hope that helps.
- azdle 12y ago
  Sure, I work for Exosite[1]. I'm mostly curious about this because we're working on getting something similar into our API right now (the subscribe part, scripting has been there for awhile now) and I've been thinking a lot about this stuff recently, I've probably been pushing the most out of anyone here. Did you guys have a reason for going for chunked over long polling though? [1]http://exosite.com http://exosite.com