Also, to help with testing I'm pushing Docker containers for witness and cli in an automated fashion.  I will post instructions on how to join using docker later tonight.

https://bitsharestalk.org/index.php/topic,17935.0.html

Looks like it's been moved to here:

https://github.com/cryptonomex/graphene/wiki/Howto-become-an-active-witness-in-BitShares-2.0

I started off by making this docker build box: https://hub.docker.com/r/sile16/graphene-build/

After that I thought, it can't be too hard to automate the build process so when a new commit hits github I'll run the build capture the output and print to html.  Took about 10 times longer than it probably should but here it is:

https://www.everydaycrypto.com/?page_id=107

Every 5 minutes my server checks for a new commit, will download build and update the webpage with the results.  It also builds docker images once a day for the witness node and cli, but those aren't quite ready for use as I still need to tweak the docker configs to allow the correct ports through etc.  But theoretically i'll be able to deploy witness nodes from the auto generated docker images:

https://hub.docker.com/r/sile16/graphene-cli/
and
https://hub.docker.com/r/sile16/graphene-witness/

Once we actually have a taged release on github for graphene those tags should propagate into the docker image as tags.   I'd like to do this for the testnet / devshares as well but not sure what github repo will be used for that whether bitshares/devshares will be used or cryptonomex/devshares   ... 

I'm new to all this docker stuff so if you have a good idea how to make it better let me know.

Oh,, and all the code i'm using the automate the build process is at: https://github.com/sile16/bts2

I'm sure someone is going to tell me you can do this with jenkins in like 2 lines of code or something.....  hahaha

I've tried several times and from different computer and different networks... Thought GitHub might be rate limiting me or something but that didn't seem to work either. 

On today's dev hangout Dan made the comparison between graphene and ethereum.  Ethereum is an interpreted language and anyone can submit and start running code.  Whereas, graphene is a pre-compiled chain with many smartcontracts as modules and adding features really isn't "that" much harder than in ethereum and anyone can submit a pull request to get their feature into the codebase.  The additional challenge is getting into the code base and then deployed out into the network, which is similar to getting approval in the Apple app store with the end result of a highly optimized compiled version of a specific smart contract.  I really like this comparison and it makes it easier for people to conceptualize the different approaches. 

I think it would be awesome to embrace this, one key challenge is when choosing a platform to develop to it's not just the code.  If we are really saying and encouraging people to contribute additional smart contracts to graphene, the whole toolchain and process needs to be documented and made as simple as possible:

1.  Document graphene internal api's , data flows, objects, etc.
2.  Make getting a development environment up and running very easy with step by step instructions. like what files are necessary, make files, etc.
3.  Provide examples of several simple smart contracts.
4.  Provide a policy to which pull requests are evaluated.  Need to have public guidelines that need to be met to be considered for acceptance.  Just like apple store policy, (but maybe try and be even more transparent.)

Until this is available I don't think it's really a legitimate comparison.

I'm curious if we could provide these two things:
1.  Allow a specific smart contract to pay 10% of fees to the creator of said smart contract.
  - This would incentivize a lot of developers to submit smart contracts and compete for inclusion into the blockchain.
2.  From a security point of view could these smart contracts be sandboxed in such a way so that a secuirty issue in a specific smartcontract doesn't put the whole chain at risk? 

If these two possible and we had all the documentation, toolchains, and processes in place it would be a very powerful story to attract new developers.

Update: 8/2/2015
I added a script for easier use, moved the build files outside the container, and made the container smaller.
The original example will still work but a new easier method is now available:

docker run -v <local host path for build>:/build sile16/graphene-build [optional tag or commit sha]

Example:
[Install docker on ubuntu, sudo apt-get install docker]
sudo docker run -v /home/sile:/build sile16/graphene-build
this builds the latest master into -> /home/sile/graphene

now... I think i'm close to where I can automate the creation of runtime docker containers with just binaries...  to be continued..

=========  Original Post  ===========================
I was wanting to learn docker so I thought I'd make a build box for graphene:

Docker Image on Docker Hub:
sile16/graphene-build

The image gets everything installed right before you download graphene and compile.

Now if you want to compile graphene you can use the following docker file:

Dockerfile:
FROM sile16/graphene-build:pre

# Install Graphene
RUN cd && git clone https://github.com/cryptonomex/graphene.git
WORKDIR /root/graphene
RUN git submodule update --init --recursive
RUN cmake -DBOOST_ROOT="/usr/local/" -DCMAKE_BUILD_TYPE=Debug -DENABLE_COVERAGE_TESTING=true -DBUILD_TESTS=true .
RUN make -j4

Actually do the build
#docker build -t build01 .
Start a shell inside the docker container to run tests / use graphene , etc
#docker run -it build01 /bin/bash


Here is the docker file i used to create sile16/graphene-build

My Dockerfile:
FROM ubuntu:14.04

# Prep Server
RUN apt-get update

# Install Prerequisite Packages
RUN apt-get -y install git libreadline-dev uuid-dev g++ libdb++-dev libdb-dev zip
RUN apt-get -y install libssl-dev openssl build-essential python-dev autotools-dev libicu-dev
RUN apt-get -y install libbz2-dev automake doxygen cmake ncurses-dev libtool nodejs nodejs-legacy npm mc
RUN apt-get -y install autoconf wget
RUN apt-get -y autoremove

# Install Boost 1.57
WORKDIR /tmp
RUN wget -c 'http://sourceforge.net/projects/boost/files/boost/1.57.0/boost_1_57_0.tar.bz2/download'
RUN tar -xf download
WORKDIR /tmp/boost_1_57_0
RUN ./bootstrap.sh --prefix=/usr/local/
RUN ./b2 install

#Cleanup Boost Install
WORKDIR /root/
RUN rm -rf /tmp/boost_1_57_0
RUN rm -f /tmp/download

if there are ways to make this better please let me know.  I'm definitely not an expert in this stuff just dabbling.

Later if you update the registration. To a higher pay rate does that invalidate all the votes?

So, you are saying that in an upcoming hard fork this will change to 200% ?   Was there a discussion around this somewhere I missed?