sidi

There are two parts:

1. Source API endpoint - Heartbeat fetches the data using the authentication supported by the source API (basic auth, security token in headers, URL query strings for example).

2. Heartbeat transformed endpoint - This is accessible over an HTTPS endpoint and is secured with a basic auth username:password key. As long as you use it within a secure environment (server code, or an internal network), there should be no problems. If you use it within a web app that's distributed to other users, they can see the key. However, this key is read-only and we will allow generating a new key from within the dashboard shortly.

We would like to enable a lower polling interval, but wanted to see the general response before doing that.

In fact, we would like to enable:

1. A lambda function support to transform APIs (diffing to only append new data, adding meta data, removing unnecessary fields) before they get streamed.

2. Polling frequencies of up to 1s.

3. Custom domains for the resulting streaming endpoints.

this is a great resource, wonder how the underlying docs.json is being created. would like to see it being extended to explain the query dsl.

fyi, the table doesn't render in Safari browser.

Much of this article focuses on the applicability of H-1B visa for startup founders. As some comments in this thread share their anecdotal experiences with it, H-1B is very limited in scope.

1.) H-1B relies on a lottery system: with a 0.3 to 0.5 chance depending on some factors,

2.) and you need an independent board of directors,

3.) and you can't be a majority stakeholder.

Not to mention once you get one, if your startup goes to ground, you have a month to find another job or risk being deported. Most startup founders in early life can't afford this.

What US needs is a robust startup visa: Startup founders that have x revenue or investment $$ can come in and work, not H-1B or other diversity visa hacks. It's not so hard, Canada has a pretty decent startup visa program.

The project has no activity in the last 6 months. I would like to see an open-source graph database that's being actively developed and maintained.

The power of positive thinking has to be one of the most undervalued capital. I would really like to see if there are any counter examples to this thinking that have worked for others.

Jekyll is a general purpose site generator, docbase is specific for generating documentation sites. It can show github contributors on a page, allow collaborative editing, create an offline search index, support docs versioning and so on.

Creating beautiful documentation is hard, and there are tons of things we don't do yet.

It supports basic CRUD already (adding new data, updating existing data, deleting one or multiple records).

exporting data makes sense, happy to look into it - filing an issue https://github.com/appbaseio/dejaVu/issues/1.

exporting is tricky when the data is large. ES restricts a query result to return 1000 results, there's a scroll API that can be used for doing this - but it can no longer be a serverless app at that point.

We have this feature in the version of dejavu used in appbase.io.

We originally built dejavu as a data viewer for Elasticsearch to scratch our own itch at appbase.io. It all started when we shifted our APIs to use Elasticsearch transparently and needed a way to display the DB data to users. We tried elasticsearch-head and a couple of other similar tools but found them to be lacking in Ux and stodgy. Others (like Kibana) were more geared towards visualization / charting than viewing raw data and even then, were hard to use outside the Elasticsearch ecosystem.

With dejavu, our goal has been to build an open-source data viewer with a modern UI and make it more widely available. You can get it from the chrome webstore, use it from a github hosted page or install it as a plugin with Elasticsearch.

(I am cross-posting this from Product Hunt as it got featured there, here's a link for those interested in following the discussion there - https://www.producthunt.com/tech/dejavu)

We do this at https://appbase.io, but with ElasticSearch. (disclaimer: I am the co-founder)

Reminds of Atwood's law: http://blog.codinghorror.com/the-principle-of-least-power/

Punch cards, followers, stars on the repositories of the user, important contributions - all are available at a bird's eye view. You are missing the point if you just check whether the person HAS a github profile.

Any attempt to use revenues as justification of the valuation is missing the point, also comments regarding git hosting being a commodity misses it.

The valuation imho is a bet that GitHub will be ingrained in developer's workflow and continue to occupy developer mindshare for at least the next decade. Some reasons have already been mentioned in the comments here: * Revenues - It's already the dominant player in git hosting and has better enterprise plans, * Mindshare - GitHub is not just git hosting, it's wikis, issues, gh-pages, atom, and more to come. Each of them are good products in their own right and also create a lot of value by being under the same roof. * Platform - Github is no longer a product, it's an emerging platform. There are plugins / extensions that augment the power of GitHub; zenhub.io (as someone mentioned here) - a case in point.

And one point that every comment here has missed is Github's value as a latent hiring marketplace. Unlike LinkedIn / Resumes / Referrals, a github profile is a much better signal for an employer. Punchcards, followers, projects built and contributed to build a very comprehensive visual of a developer, his coding style, tools used. As Github gets more popular, more employers will find value in this providing a reinforcing loop getting more developers to be creating profiles and maintaining them.

From an employer's perspective, github profile has been one of the highest signal in our hiring decisions. Anecdotally, I have yet to see a gamed profile.

This builds a very tight feedback loop, and ends up with more developers using github. And I don't see anything disrupting this loop for the time being.

One correction - Technical co-founder, consumer product: -31% (over non-technical founders)

We have had a very similar experience, and I was a paying customer the first day they launched. However, over the month of migrating documentation - we discovered a couple of areas really lacking:

1. Having to use JS too often and they only offered it in their higher plans,

2. surprisingly poor md support. I don't usually write markdown in visual blocks.

In the end, we built an aggregation of open-source tools to create something similar to the effect of readme - https://github.com/appbaseio/docbase. It uses github for markdown editing and versioning, flatdoc for rendering docs, and creates a beautiful single page routing for the doc. http://docs.appbase.io is using it.

Really interesting backstory, and congrats to @Greg and team for joining YC. Curious to know more how this worked out, since readme was gaining dev adoption pretty rapidly when they launched last fall.

Wow, didn't know TitanDB was abandoned. Last I read, datastax was working on a commercial offering of TitanDB.

There are some real use-cases when you stop confining yourself to a single tenant architecture. Apart from that, think of any categorization that's dynamic - timeline based data, versioning of data, etc.

There are a ridiculous number of new things - including the entire design itself that I believe it deserves more than a Foo 1.3.1 update. Appreciate your comment.

There are some similarities. The big differences: Appbase is a graph API (similar to Neo4j), all your data is indexed and searchable instantly.

Link to blog post: http://news.appbase.io/posts/233094-jam-with-friends

If you notice, it's available to try out today (and hence the new post :-) ).

About the name, we don't see that being a problem -- hopefully, not now at least. We see it as an easter egg in good humour.

My bad, added the link - http://hooli.io.

Strange coincidence, I don't play planetside.

The name is partly inspired from the show, and with the domain lying around, thought it made for a good easter egg. There are some others on the site if you look carefully ;).

OP here:

There are a gazillion collaboration tools out there. Why build a new one?

I use Trello/Hipchat/Github-issues in my workflow on a daily basis. I have tried a lot more tools. Most of the tools try to do many things and are not friendly on mobile devices. Hooli takes the simplicity of a tweet message to make actionable discussions that can be tracked in one live document. We have been using it extensively for taking meeting notes, managing our scrums.

Sneakpeak link - http://hooli.io/#/app/

Imo, latency difference shouldn't be huge between a tree/graph data topology. Graph traversals for our read requests takes less than 10ms.

Firebase is great for building real-time apps, and it uses a tree topology to model data. Fundamentally, we are using a graph topology to model data which has some interesting upsides, for instance, data denormalization is not needed.