Addition of readme + Blog fixes #4
Conversation
|
|
||
| $ jekyll build | ||
|
|
||
| One built, all of the static content will be placed in the folder `_site` inside |
There was a problem hiding this comment.
I believe it's "content" now, not "_site".
There was a problem hiding this comment.
@takidau My dumb - I missed that change from Max. Fixed in README which is now part of the PR.
Fix for output path in readme
| The Apache Beam website uses `svnpubsub`. The `_site` folder contains the | ||
| website's content. When the content in `_site` is committed to the svn | ||
| repository, the Apache Beam website will automatically be updated. | ||
| One built, all of the static content will be placed in the folder `content` inside |
Typo fix.
|
+1 |
|
Just rebuilt static content; turns out jekyll serve will only do it for you sometimes. |
| @@ -93,784 +93,13 @@ <h3 id="a-classpost-link-hrefbeamcapability20160317capability-matrixhtmlclarifyi | |||
|
|
|||
| <p>With initial code drops complete (<a href="https://github.com/apache/incubator-beam/pull/1">Dataflow SDK and Runner</a>, <a href="https://github.com/apache/incubator-beam/pull/12">Flink Runner</a>, <a href="https://github.com/apache/incubator-beam/pull/42">Spark Runner</a>) and expressed interest in runner implementations for <a href="https://issues.apache.org/jira/browse/BEAM-9">Storm</a>, <a href="https://issues.apache.org/jira/browse/BEAM-19">Hadoop</a>, and <a href="https://issues.apache.org/jira/browse/BEAM-79">Gearpump</a> (amongst others), we wanted to start addressing a big question in the Apache Beam (incubating) community: what capabilities will each runner be able to support?</p> | |||
|
|
|||
| <p>While we’d love to have a world where all runners support the full suite of semantics included in the Beam Model (formerly referred to as the <a href="https://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf">Dataflow Model</a>), practically speaking, there will always be certain features that some runners can’t provide. For example, a Hadoop-based runner would be inherently batch-based and may be unable to (easily) implement support for unbounded collections. However, that doesn’t prevent it from being extremely useful for a large set of uses. In other cases, the implementations provided by one runner may have slightly different semantics that those provided by another (e.g. even though the current suite of runners all support exactly-once delivery guarantees, an <a href="https://samza.apache.org/">Apache Samza</a> runner, which would be a welcome addition, would currently only support at-least-once).</p> | |||
There was a problem hiding this comment.
I'm probably missing something obvious, but not sure why this section is going away. Is this duplicated elsewhere?
There was a problem hiding this comment.
GitHub lies! ;)
The new blog page uses a "summary" section for posts (delimited by a "" tag) to keep the blog index from becoming huge. To make things easy, new new static page also includes "Read more" buttons after the summary so people can click on them and enjoy the full post goodness.
This is a balance between having a super long blog page and weird pagination, which doesn't work with Jekyll + Markdown, sadly.
|
Nice text! I love that the instructions will be prominently displayed, and that people won't need to lookup documents elsewhere, etc. Generally, I'd prefer separate PRs for unrelated things; leave as is for now. |
s/dealing with//g
|
@davorbonaci I agree about seperate PRs. Sorry - this one ended up being a minor Blog fix which snowballed a little into a readme and also trying to figure out how the new publish scheme works (so I can also document it.) :) |
Fix to "Generating the static website" section.
Change to "About this site"
Fix for "About this site"
This PR has three changes:
<!--more-->tag to create summary for new blog postI tried pagination for the blog; does not work well (so buttons were used instead to keep the blog page from growing huge over time.)