HN user
http://jupo.org
Cool!
I built CurioDB a while back with the same idea, but using Akka as the underlying framework. Persistent Redis with distributed transactions, embedded Lua and a websocket front-end:
You're not wrong, Walter.
CurioDB too: http://curiodb.jupo.org
If each key/value in the DB is treated as distributed (as per the actor model), a lot of the limitations Redis faces in a distributed environment are solved. I wrote a lot more about it here: http://blog.jupo.org/2015/07/08/curiodb-a-distributed-persis...
I really love the idea of explaining the actor model as tons of tiny little servers compared to a single monolithic server. I tried to make the same comparison recently when I talked about adding distributed transactions to CurioDB (Redis clone built with Scala/Akka): http://blog.jupo.org/2016/01/28/distributed-transactions-in-...
Great project. I recently used LuaJ to embed Lua scripting inside CurioDB: https://github.com/stephenmcd/curiodb - it's a distributed Redis clone built with Scala/Akka. In terms of matching features with Redis, LuaJ was a life-saver.
Yep, one actor per KV means some kind of distributed coordination would be needed - that doesn't exist yet.
That'd be good!
Hey Jon, long time no see. :-)
Yes I imagine the thinking there is similar in your project, eg: Redis/CurioDB :: Node/SocketCluster (https://github.com/SocketCluster/socketcluster).
Glad you like it!
Hardware requirements would depend on your usage of course, it's like asking about the length of a piece of string. :-)
Honestly though, the code probably needs a lot more eyeballs on it before it's production ready, which is why I posted it here.
Funny is a +1 on Slashdot, while on HN it'd be a -1.
The rotated A in the Aerospike logo reminds me of a system that's fallen over, and now you can't unsee it:
You can easily render a tree many levels deep in O(n) time using a single DB query as an adjacency list with a lookup dictionary:
http://blog.jupo.org/2010/01/26/linear-traversal-of-adjacenc...
No need for mptt either.
Perhaps it was more a case of accuracy for what we were looking at at the time then :-)
It's something we run out of band on a subset of our data, so it's never been performance critical.
Great article.
I went through a similar process about a year ago for https://kouio.com (RSS reader). In its case I needed to coalesce closely matching RSS feeds purely for storage and performance. After trialling edit distance and various simhash implementations in Python, we ended up needing to look no further than the standard library's difflib.SequenceMatcher - I wish I documented my findings at the time, but I recall it was the best in terms of speed and accuracy.
Also you might not want to rely on str.isalnum for stripping punctuation. I made the same mistake here: https://twitter.com/stephen_mcd/status/506344236531212288
https://twitter.com/stephen_mcd - hit me up, lots of open source
I use the web version of kouio on android every day, it's tailored directly to mobile devices:
https://kouio.com/blog/kouio-your-mobile-rss-reader
You can also push articles out to a whole ton of services at once, including Evernote:
https://kouio.com/blog/sharing-is-caring
As for HN and Reddit, RSS is perfect for these - HN has its own RSS feed dedicated to front-page items:
https://news.ycombinator.com/rss
It gets even better with Reddit, each individual subreddit has its own RSS feed, eg:
http://www.reddit.com/r/systems/.rss
With kouio I group together all the interesting subreddit feeds under a folder called Reddit - then I can view them individually or all together at once.
Yeah I only found those recently and it kinda blew my mind - great way to keep an eye on the kinds of blockers people have with a particular technology.
Well that list above are all things I kinda class as "personal notifications", so I put all those into a folder - in kouio you can view a single folder at a time, or expand it and see the unread counts against each feed (pretty sure Google's worked that way too).
Then everything else goes into various folders, with a couple top-level main feeds that I don't put into a folder at all, here's a screenshot:
Very well put!
My RSS reader (http://kouio.com after Google's shut down) has always been my complete command centre:
- Google Alerts
- LinkedIn updates
- Every issue/comment/star on my Github projects
- The exact ages of my children every day (via http://howoldismykid.com)
- New questions per tag on stack overflow.
- New messages for individual Google Groups.
and so much more.
I was just lost when Google Reader shut down thinking I'd lose all that, RSS really is the universal API of web data.
Check out https://kouio.com if you're looking for something visually clean and simple.
- Make a list of successful companies using lang X. Bonus if competitors. They're a success because of lang X.
- Will using lang X over Y reduce total lines of code? That's less work, less time, less money.
- Are # jobs for lang X rising? Show some pretty graphs. We can't fall behind the market.
All of this is bullshit to an engineer, but precisely how you need to sell it.
Mezzanine takes that exact approach where pages are of specific types, and has consistently rejected calls to add arbitrary block features (although you can do that with add-ons).
Surprised you haven't looked at it - it's the most downloaded of all the Django CMSes.
collision / dangrossman - sorry I had my facts wrong there.
I don't understand how this is the case when younger competitors like Braintree and Pin are able to offer it.
A slap in the face to Australian users who've been waiting patiently for half a year to use USD and still can't.
Thanks - we originally looked at them but they didn't have recurring payment support at the time.
Since then they "acquired" an entirely separate recurring payments company (I don't recall the name), and it was all just a bit too much of an integration mess at the time, when compared to Stripe who also announced their beta then.
Email sent.
All depends on the country your bank account is in.
As an Australian company selling to the US, we've kinda been left in the lurch with their AU beta.
When it was launched we were told they were working on being able to accept/convert USD into AU accounts, so at the time we (incredibly naively) started building our subscription code around their API, assuming it'd be ready by the time we were.
Almost 6 months later and all we can get out of them is "we don't have an eta but we're working on it", and we've been sitting here the whole time losing money hoping that it's just around the corner, when really we should have just thrown out the work we'd done and gone with a provider that can already handle it.
Have a look at kouio, the app itself uses the public rest API, so it's been available since day one: