Skip to content
This repository was archived by the owner on Jun 22, 2021. It is now read-only.

WIP: Rewriting the get started flow #136

Closed
wants to merge 17 commits into from

Conversation

Mr0grog
Copy link
Contributor

@Mr0grog Mr0grog commented Jun 1, 2016

For merging into the general nav restructure or for merging afterwards. This is a work-in-progress branch for writing a new 3 part getting started guide.

This starts with an initial draft of the second step (we've already got the first draft of the first step in learn/get-started/readme.md).

Layout and widget-y stuff will live in https://github.com/stellar/developers. In particular, I need to write up a nice way to present footnotes and the multi-language markup for examples.

Example code is included here in three languages—bash, JavaScript, and Java. I could definitely use feedback on whether the examples show the simplest way to go about doing what they do. The markup looks like:

```md
<example name="Example Name">
```language-name-1
// example code
```

```language-name-2
// example code
```

etc.
</example>
```

```java
// create a completely new and unique pair of keys see more:
// https://stellar.github.io/java-stellar-sdk/org/stellar/sdk/KeyPair.html
import org.stellar.sdk.*;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor but I'd change to: import org.stellar.sdk.KeyPair;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, I’d originally done that, then switched to this so I didn’t have to write imports in all the subsequent examples :P Will change.

@Mr0grog Mr0grog force-pushed the get-started-rewrite branch from 67321b9 to 19d5500 Compare June 2, 2016 18:32
@bartekn
Copy link
Contributor

bartekn commented Jun 3, 2016

Added Go examples.

@Mr0grog
Copy link
Contributor Author

Mr0grog commented Jun 3, 2016

@bartekn Awesome 👍

@@ -66,7 +66,7 @@ func main() {
</example>

[TODO: should this only show if viewing the SDK examples?]
You might notice that, in the SDK, you ask for the *account ID* instead of the public key. That’s because an account’s ID *is* its public key.
You might notice that, in the SDK, you are asked for the *account ID* instead of the public key. That’s because an account’s ID *is* its public key.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, I think this definitely should have been “ask” instead of “are asked”—at least, I was trying to refer to the fact that you call pair.accountId() or pair.getAccountId() rather than what one might expect from a key pair, e.g. pair.publicKey().

Would if be clearer if it was:

You might notice that, in the SDK, you call pair.accountId() instead of something like pair.publicKey(). That’s because an account’s ID is its public key.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, yeah that works also

@Mr0grog
Copy link
Contributor Author

Mr0grog commented Jun 22, 2016

Draft of Sending and Receiving Money, the final step of Get Started. (It only has JS examples for now, so if anybody wants to add Java/Go before I have time to get to it, go for it.)

Mr0grog added 3 commits June 24, 2016 15:47
Footnotes should be `[^number]`, not `[number]`.
Our Markdown parser has a bug and needs a blank line between the `<example>` element and the fenced code block.
Links to in-site .html files should be to .md files.
The first thing you’ll need to do anything on Stellar is an account. Accounts hold all your money inside Stellar and allow you to send and receive payments—in fact, pretty much everything in Stellar is in some way tied to an account.

Every Stellar account has a pair of public and private keys. Stellar uses public key cryptography to ensure that every transaction is secure. The private key is a secret piece of information that proves you own the account. You should never share your private key with anyone. It’s kind of like the combination to a lock—anyone who knows the combination can open the lock. In the same way, anyone who knows your account’s secret key can control your account. The public key is how other people identify your account and verify that you authorized a transaction.
[TODO: decide on whether we're using public/private or public/secret for keypairs. This doc currently uses both private and secret.]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The correct terminology used by Stellar everrywhere is:

Public Key and Secret Key.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So… this came about because the JS and Java SDKs both don't really expose private keys, only secret seeds:
https://stellar.github.io/js-stellar-sdk/Keypair.html
https://stellar.github.io/java-stellar-sdk/

Some docs talk exclusively about secret seeds (e.g. https://www.stellar.org/developers/learn/get-started/get-started.html) and some talk about both without really clarifying the difference (e.g. https://www.stellar.org/developers/learn/integration-guides/building-blocks/account-management.html). The quick start widget calls the secret seed a private key, which might set someone up for confusion later.

I don't think I've seen a doc that uses "secret key," but maybe I missed it?

Anyway, I think it's important that the secret seed is a different thing from the private key—this actually caused me some personal confusion for a couple days and several wrong steps when trying to use the API and write the original docs. I'm not sure we can just say "secret key" without talking about "secret seed," since seed is the terminology used in most of the SDK APIs.

It might be that I just need to stop and explain both here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because seed is a deprecated term and we haven't taken the time to fix those.

We aspire to use "public key" and "secret key" (we had a big conversation about this a while back).

In practice though, we haven't updated a lot of our code and some stuff even refers to "address".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to move forward with the right terms than try to accommodate for the old terms that we are trying to abandon.

@Mr0grog
Copy link
Contributor Author

Mr0grog commented Jun 28, 2016

Made some changes in e5a5038 and 4a2ccdf around the descriptions of account IDs, keys, seeds. @irisli @jedmccaleb @jessica-collier how do these read to you, both general clarity and technical accuracy?

@Mr0grog
Copy link
Contributor Author

Mr0grog commented Jun 28, 2016

@irisli @jedmccaleb I think I am also going to drop the Bash examples from the “create an account” doc, since I don’t feel like they add a whole lot and will be inconsistent with “sending and receiving money,” which will never have Bash examples because it would be stupidly complicated. Does that seem alright?

@irisli
Copy link
Contributor

irisli commented Jun 29, 2016

@Mr0grog Sounds fine to remove bash examples. We don't have any cli tools to build transactions (without invoking one of the js/ruby/go libraries)

@irisli
Copy link
Contributor

irisli commented Jun 29, 2016

Using #140 instead so that we merge into master

@irisli irisli closed this Jun 29, 2016
@irisli irisli deleted the get-started-rewrite branch June 29, 2016 23:36
@irisli irisli restored the get-started-rewrite branch June 29, 2016 23:36
@irisli irisli deleted the get-started-rewrite branch July 5, 2016 18:05
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants