Hey Vilnius.  Try selecting "Show DevTools" from the View menu.  Do you see any errors in the Console?

I believe you can import your KeyID (formerly BitShares DNS) wallet directly into the BitShares client.

Some resources that may be helpful:

• https://bitsharestalk.org/index.php/topic,10390.msg136613.html#msg136613
• https://bitsharestalk.org/index.php?topic=11251.0
• https://bitsharestalk.org/index.php/topic,18019.0.html

Alternatively, you may need to run BitShares 0.9.3c to import your KeyID wallet, then export that, then finally import the 0.9.3 wallet into the BitShares 2 client.

The KeyID forum is located here:
https://bitsharestalk.org/index.php/board,50.0.html

Quote from: 70231f697a2b3c2b on July 22, 2016, 04:15:07 pm

If you want a really cool intro to Python and cryptography, work your way through https://inventwithpython.com/hacking/chapters/ .  It will help you get up to speed with Python, and you'll be learning by writing programs to implement and break cryptographic ciphers.

Once you're feeling confident, then move onto https://cryptopals.com/ .

You are awesome....

555 Well, I'll take a teeny bit of credit for posting the links, but I am really amazed at the knowledge (and generosity) demonstrated by the creators of those projects.

Incidentally, anyone who's interested in working through these exercises collaboratively, send me a PM.

I'm mostly following, I think. In step 6, how does it interpret that part? I'm thinking I only need lines 248, 251, and 257 in airsign _main_.py to do what I need to do if I instantiate my own rpc object.

Start with a simple example:

the_answer = 42

class Test1(object):
  def __getattr__(self, name):
    return the_answer

t1 = Test1()

t1.foo # 42
t1.bar # 42

t1.foo + t1.bar # 84

In the first example, wherever you see `t.something`, you can substitute `the_answer`, and that's more or less what Python does, too.

Now let's make it a little more interesting:

def get_the_answer():
  return 42

get_the_answer # <function get_the_answer at 0x10906ec80>
get_the_answer() # 42

Once you define a function, you can treat it just like any other variable.  `the_answer` is a reference to a variable containing the value `42`, and `get_the_answer` is a reference to a function that returns `42` when invoked.

class Test2(object):
  def __getattr__(self, name):
    return get_the_answer

t2 = Test2()

t2.foo # <function get_the_answer at 0x10906ec80>
t2.bar # <function get_the_answer at 0x10906ec80>

t2.foo() # 42

`Test2.__getattr__` returns a reference to the `get_the_answer` function, so wherever you see `t2.something`, you can substitute `get_the_answer`:

t2.foo => get_the_answer => <function get_the_answer at 0x10906ec80>
t2.foo() => get_the_answer() => 42

One more example to bring it closer to what you saw in airsign:

class Test3(object):
  def __getattr__(self, name):
    def create_request(*args):
      return {'params': [name, args], 'method': 'query'}
    return create_request

t3 = Test3()

t3.foo # <function create_request at 0x10906ec80>
t3.bar # <function create_request at 0x109088668>

t3.foo() # {'params': ['foo', ()], 'method': 'query'}
t3.bar(1, 2, 3) # {'params': ['bar, (1, 2, 3)], 'method': 'query'}

Unlike `Test2.__getattr__` where it returned a reference to the same function every time, `Test3.__getattr__` creates a function on the fly and returns that, but otherwise the idea is the same.

__getattr__ seems like a method for choosing from a variety of methods based on the input, does that seem accurate?

Not quite.  In this case, `GrapheneWebsocketRPC.__getattr__` literally creates a new function every time you call it, similar to `Test3.__getattr__`.  You can verify this by checking the object ID of the resulting function:

t2.foo # <... at 0x10906ec80>
t2.foo # <... at 0x10906ec80> (same)

t3.foo # <... at 0x10907ccf8>
t3.foo # <... at 0x109075758> (different)

(if you run the code on your system, the exact values will be slightly different, but the result will be the same; `t2.foo` always returns the same instance, but `t3.foo` always returns a different one)

Note:  when you write your own classes, you don't have to use `__getattr__` this way.  It has many uses; generating a function on the fly is just one of them.

Thank you for your input. Say I wanted to extend that interest to something like... bts...

Should I just pick a language, pull up the source code for a version of graphene that can be released freely, and get to rewriting at my lack of skill level, just researching every single new thing as I go and pestering reddit relentlessly for advice? What sort of project do you suppose would be a good start?

Good questions.  Learning how to code by rewriting Graphene is akin to learning construction by recreating the Burj Khalifa.  It is possible, but the process will be extremely slow, difficult and fraught with peril (think more, "learning bad habits" and less, "plummeting 2.7km to your death").  No one will disparage your ambition, but there may be more effective ways for you to build your skill set.

Instead, think of the Burj Khalifa as the foundation that you will build upon (e.g., set yourself to the task of constructing a helipad at the top of the building).  The existing tower will provide structure that you can use to support your creation, and you can reference aspects of the building for inspiration and best-practices.

This may sound anti-climactic, but starting small grants you many benefits:

• You can complete the project more quickly.
• You can publish your code more frequently and get valuable feedback from other developers.
• Other developers will be more inclined to review your code if there's less code to review.
• A smaller project has fewer moving pieces, which frees up head-space for learning and retaining new concepts as you go.
• A smaller project is easier to refactor if you realize that you made a mistake in a critical piece of code.

And, you can always expand the scope of the project later, when you're ready to work on v2.0.

If you'd like a starter app that you can use as a PoC, try this:

• The application runs via command-line.
• When started, the application will prompt the user to enter a BitShares account name and press return.
• If the account name is blank, the application will exit.
• Else, output the corresponding BTS balance.
• When finished outputting the balance, the application will prompt the user to enter another BitShares account name.  Continue until the user enters an empty account name.

@xeroc has published a fantastic library on GitHub that you can use in a Python application to interact with the BitShares blockchain.  The code is incredibly well-documented, and it includes several examples that you can look at and run to see how it works.

This may seem like a trivial application, but keep in mind that your primary goal at this point is to learn, so you want to design the requirements of your first application around that goal.  Once you get the hang of it, new ideas will start to flow, and you will start building momentum to tackle larger and more complex projects.

If you have any questions, need help understanding how something works, run into a bug that you can't squash – even if you need assistance getting started – do not hesitate to post on BitSharesTalk/StackOverflow/Reddit/etc.

But it's pretty much just for clarity and preventing your code from turning into an enigmatic riddle, and poorly written but logical code that uses lots of them will still compile and run just fine at the same speeds, right (not that I am advocating their use)?

Correct.  The code will still work exactly the same either way (and depending on the language/compiler, the resulting bytecode/opcode may be the same in both cases as well).

Even if the code runs more slowly with constants, the performance hit will be so small as to be negligible*, and since a developer's time is generally more valuable than a computer's time^{[citation needed]}, it usually makes sense to optimize for maintainability over runtime performance.

* There are exceptions, but generally you won't know what they are until you profile your code.  See http://programmers.stackexchange.com/q/80084/ for a discussion about what constitutes "premature" optimization.

I looked for another comparison thread in that subreddit, and came across one for Nxt.  It's a bit of an apples-to-oranges, since this thread was created before Frontier was released, but there does appear to be a slightly more positive tone towards Nxt.

I also found a few threads that were basically also comparison threads, but they were worded to be Ethereum-centric, and they seemed to get a more positive response:

• https://www.reddit.com/r/ethereum/comments/2jwsfo/why_should_i_choose_ethereum_over_nxt_to_build_my/
• https://www.reddit.com/r/ethereum/comments/2dr64v/explanation_for_delegated_proof_of_stake/

It's a small sample size, granted, and I didn't check which posters were /r/ethereum regulars vs. guests from other communities.  But, the main takeaway that I got from these threads is, /r/ethereum (sensibly) wants to talk about how great Ethereum is, so a thread about Ethereum+BitShares will likely receive a better reception than a thread about Ethereum vs. BitShares.