hello my name is Yuri Matias I'm the
lead developer of the embark framework I
caught her other tools as well such as
ether same which later got turned out
into what you no no no as a test RPC
this is the frame this is the frameworks
development frameworks panel and also
discuss tooling we're going to start by
asking the panelists to give a brief
introduction about themselves and also
to tell us what you have been up to this
past year Jack Peterson I'm the lead
developer at augur and spent the last
year literally the entire year
developing augur and I'm happy to say we
just we just sent our contracts out for
their final security audits so those
Thanks and so those come back with green
light then launch so that's what it's
meant literally always I want hi my name
is Andy millenias and weed developer
with bebo good to see you all
I'm a developer with DAPA so we are a
self-organizing network of developers
who focus on the root problems of DAPs
and we mostly make developer tools and
other forms of blockchain infrastructure
we have some command line tools that
make your life a lot easier when you're
working with the solidity compiler and
the etherium api and we have a standard
library approvable standard library of
smart contracts that has been written
with an eye towards formal verification
which we also have some specialists
working on in the background as you just
saw me but screw it
hi I'm Nick Dodson so I'm a senior dev
at consensus and I've been working on a
project for a while called boardroom
originally I was working on wave fund
for a while which some of you may know
but I kind of stopped doing that because
crowd sales are just exhausting I can't
take it so and doing hjs and a few dev
tools and floating around for quite some
time so it's me everyone I'm Conor
Svendsen I'm the author of a library
called web 3 J which is the Java and
Android library for integrating with
aetherium it provides full JSON RPC
implementation that then also smart
contract wrappers so you can work with
smart contracts directly from native
Java code and sports track offline
transactions signing all the filters and
everything else I'm also the founder of
a company called blk dot IO which is
building our tooling on top of aetherium
and core and focused really on making it
a lot simpler for
companies and people who want to work
with blockchain technology but a less
technical to kind of make sense of
what's happening because right now
really you kind of need to be a
developer who understands IBM byte code
in order to make sense of what's
happening and we're we're trying to
address that hello yeah so Ian Loveall
I'm working on a mix developer of he mix
so he mixed a mix is web ID web-based IG
where we can write math contract and run
smart contract as well
so this tools is mainly focused on
debugging features so you can run and
debug transactions and also called
analysis so yeah we have started this
tool like one even alphago and we are in
states where it is used by many people
but we still have a lot to do and we
hope we hope that's in maybe one year or
we can have some it is now but we still
have so much to do things
hi I am piper Miriam I am the lead
Python the Python team lead for the
etherium foundation and I am building
out the Python tooling ecosystem for
aetherium developers sort of a
three-pronged thing with lip 3py which
is a counterpart to web 3gs which you
guys heard about a few minutes ago
populous which is a development
framework for smart contract developers
and then related to those is the package
management and Ethier packaging up smart
contracts the tooling to support that
effort so development tools are often
created to address certain needs or to
overcome certain obstacles could you
tell guys tell is what's your origin
story of sorts why did you create your
tools what circumstances led to that ok
I guess I'll start
well I guess most of the tools that
we've created have the same origin story
which is just that when we got started
there really weren't any tools so by and
large we ended up rolling our own stuff
yeah that's pretty much the long and
short of it so I think jack is right
when it comes to the command-line tools
definitely but a point to add as
specifically as it relates to our smart
contracts library we wanted to make
something that was generic and something
that was repeatable and something that
would benefit the entire ecosystem and
something that's easy to share and when
we solved these problems we didn't want
to solve them in bespoke ways that would
never be useful again so a lot of what
we've been doing over the last two or
three years has been thinking about what
is thinking about striking a balance
between being sufficiently generic and
repeatable and useful but not spending
all your time on this and actually
moving forward with your application and
and not getting lost on imagining
far-flung visions of the future about
how these things will be used that was
great yeah anger and frustration and
sadness and like days of confusion and
like questioning my own personal
identity and why was doing this yeah and
and essentially so was the dev tools I
created with ejs was just I got pretty
frustrated with web 3 and just wanted to
do my own thing that worked for me which
is good and a bad thing and then with
things like eat deploy I just wanted my
contracts to deploy like I just wanted
to deploy them a specific way and do it
in a sequence and get the data at the
end of it
so yeah that's definitely my journey and
like when I was initially starting like
way back it was like remix was like a
C++ client and like there was nothing
and like web 3 kind of worked and the
node kind of work but like things didn't
really work either and like so it was
just like any sort of comfort you got
from building the dev tools I think
that's just like yeah it's like a sanity
check almost so yeah for me it was kind
of a bit of a disconnect and that's
there was all this noise in the media
about you know blockchain blockchain
blockchain and big enterprises using it
I'd spent the first part of my career
working in large enterprises building on
top of the JVM and really I saw a clear
gap there in terms of you know all these
enterprises want to work with this
technology but then in the etherium
ecosystem at that point all you had was
a theory MJ which was a client but you
didn't actually have the tooling for
integrating seamlessly with the JVM ins
you know the goal there was just to
address that gap yeah so for this to
remix I would say that we have started a
long time ago to work on it and before
the name was mixed and the reason why we
did that is that from the beginning
beginning we will need to be able to
develop transactions so the first use
case of mix and now remix which is the
latest version is just to debug stuff
and we will need this from the beginning
so it was kind of yeah intense where we
started to build remix to debug
transactions and continue the theme
solving problems that I had during
development the populous was the
original piece of code that I wrote and
if you look at almost every other
library that has shown up from me in the
etherium ecosystem it was ripped out of
populist and turned into something
generic but every single one of those
things was to solve a problem or to
fix something that I needed in the
developer workflow which is common
thread here we were living off the land
back then so a lot of tools that we
develop are in different platforms so
that they don't overlap but in some way
I consistent especially the JavaScript
one there's a lot of competing tools so
our important is that diversity are we
better off all focusing in in one tool
for each ecosystem and make it the best
we can or or is it better to to focus to
devote several competing tools and try
different different approaches I think
having a lot of different tools is
really valuable especially because we're
not all unified by a programming
language in the same way that you are
and like the JavaScript ecosystem for
instance so like for instance I our
tools work really well from the command
line and from bash and that's kind of
how they developed with this like UNIX
design philosophy but from the command
line and his tools are designed from
JavaScript right and so people who like
to use JavaScript can use his and people
who want to use the command line can use
ours and so there's like different ways
to approach the same blockchain we're
all coordinating around a blockchain
boot the way that we approach it could
be completely different can I continue
yeah I'm okay with you and if I want
just to add a small thing I think when
we think about libraries I think it's
very important to be able to have a good
edition of libraries and I've good
experienced developer that can review
libraries and he needed to have a lot of
libraries but it's really needed to have
good libraries so it's something that we
should improve I don't have so much
solution but yeah I think it's really
important I was just gonna answer that
as well I think that there's a certain
things though that can certainly help in
this regard and that's you know if the
library developers making sure that
their codes modular push
like individual artifacts out there and
you know there's been a lot of movement
in this space but it's encouraging that
that reuse because there's a classic
problem where people see a library and
it doesn't quite do what they want to do
so then maybe they'll go and write it
from the ground up because the library
that they've seen isn't modular enough
to pull parts out and so I think that
that part then as well the good
documentation at least it ensures that
you've got strong foundations there and
then people have a bit more flexibility
to kind of cherry-pick the pieces that
they need that do what they'd rather
solve the problems that they have but
then they can build on top of that
rather than you know the emergence of
too many you know competing versions of
things doing similar things I I can kind
of mirror that in a certain sense that
have that there's a number of different
abstractions that need to exist in every
language ecosystem we need tools for ABI
encoding and decoding and we need
abstractions for just doing the RPC
stuff and there's all of these different
things that sort of do need to be
mirrored and a number of these
architectures are kind of already
figured out things that work they're not
necessarily going to translate perfectly
to every language ecosystem but there's
been a lot of my tooling where the
JavaScript ecosystem did the heavy
lifting and we just sort of copied their
architecture and it has worked quite
well so I think it's good that we sort
of what we're seeing the same libraries
across different language boundaries but
I also think it's good for there to be
competition of a sense inside of those
language boundaries because well I don't
always get the abstraction right and
somebody else might come along and and
have a better version of that and that's
a good thing so yeah like I think I
think a lot of this stuff especially on
the higher layers are really
straightforward like there's not many
ways you can dance around a lot of these
concepts like they're pretty
straightforward it's just how you're
going to approach handling data and then
you're gonna approach you know
constructing your library and I think I
think the message about quality over
quantity is definitely right like we
shouldn't have like a bazillion crate
querying layers or something in
JavaScript like you don't need that like
we just don't need that but I think you
know building women in isolated small
pieces is always a least in my mind
that's been always key and kind of a
motivation for some of the stuff that I
did just to break it all down even if it
doesn't get used like I just want to
break it down to its smallest smallest
pieces but also like you know then I'll
do all this JavaScript stuff and it's
fantastic and then I'll look at like the
latest pi theorem and then I'm just like
like you know it's way nicer just
because it's just like you know there's
no there's no depth to the code like
it's literally two or three lines deep
and like it's just tests and I'm
like oh you know so it's just
across languages I think you want to
also look at what's available everywhere
because there's fantastic tooling coming
up from different languages at different
times and like screwed just JavaScript
like Java scripts great and it's
accessible but like you know a Python
offers a lot rust offers a lot Java if
you're into Java I can't stand Java but
you know some people love Java so yeah
I'm not sure I'd go so far as to say
javascript is great but yeah I mean I
think for you know libraries in
different languages I think it's
completely fine understandable to
replicate one library's functionality in
different language within the same
language I mean I think as long as if
you're creating a new library if there's
you know as long as it sits subtly
different than an existing library and
there's some new niche that it's filling
then I think it I think that can be
great you know I think it's good to have
some degree of competition among
libraries I think one thing that we have
to watch out for as you know people that
sometimes off the author general-purpose
libraries is that we're not just writing
a library because there's a quote from
Joel Spolsky he's
that code is easier to write than to
read and I think that that's true and I
think that that's that that underlies a
lot of decisions that you know
programmers will make regarding whether
or not they should roll their own stuff
and I think that that in isolation is
not necessarily a good reason so the
tools they this they address a lot of
problems that you have but surely
there's other problems that you want to
solve what I'm curious about is what
problems have you solved but you just
have no time to implement yet the
solutions I'll start so a number a
number of you may have seen the package
management talk from the first day if
not go take a look we have a fully baked
solution for package management that
looks a lot like an app store if you
look at it from the right angle and a
lot of it just comes down to more
tooling support for the spec another ERC
for specifying some higher level stuff
and and just well like I said tooling
support and and it's not trivial there's
a lot of work to be done I'm forecasting
it's gonna take us the next six months
to a year to really get to a point where
that stuff starts to be usable but there
is that force multiplier effect as as
those tools the support shows up and we
get Network effect across different
language boundaries and and things start
moving faster can I continue I think
you're already right and four he mixes
same thing we need any plan and we have
thought about integrating the package
manager and it's like it's a lot of
stuff to do right of
work to fix as well and then yeah it's
very hard to to be fixing a point and
who and to implement these things but I
already do that I was thinking that's
yeah there is something in remix that is
quite important and we need to overcome
that this is a web app and sign this web
app there are different modules and
there are kind of independent met but
they are still packaged in the same big
modules and we want and we need to speed
up everything so can maybe some modules
can be used inside other tools or inside
was a web app I don't know what you know
and this is something that's it's a nice
example of for the question that we need
to do we have to do we will do but we
always say ok we need to do that but
imagine to most of her multiples we
don't have time or so on so so yeah I
think the package management stuff for
aetherium like it's absolutely essential
it's so critical and it's so underused
and I think there's a few different
reasons why like even for one as I read
about it and look at it like it's still
not something I want to interact with
yet and that's almost my fault for not
making a comments about that because I
definitely will but the thing is is we
need to start using all that stuff if we
don't you're going to have so many
different issues where copying code just
causes a bazillion problems and package
management's really really critical but
I also find that even when using
solidity there's a lot of interesting
dangers coming from just hidden code
that's in an import so if you're
importing a bunch of solidity files and
you're smashing them together in a
contract like sure in JavaScript if you
make a mistake like maybe it could cost
you your company some time or some
processing whatever but if you make that
mistake in contracts
it's like shipping hard
that's failing or failed and so we know
how dangerous that is so there's a lot
of interesting dynamics because in some
senses I just want a copy solidity code
together so I can see the whole damn
thing but then at the same time I
absolutely want to use a package manager
and use imports because I don't want to
do that because accidents happen and
they certainly do so there's almost
primitive things of like visibility
across that system that need to be
worked on but also everyone needs to
chip in their opinions on why they're
not using the package managers right now
and what they hate about them and just
go nuts like just say everything you
absolutely hate about them and I think
as well we probably want to study if not
already because I don't know all the
research that's been done on that but
the NPM ecosystem and why that was so
successful but then again with the NPM
ecosystem like how many crappy packages
are shipped every day maybe we don't
want to copy that maybe we want to have
something a little sturdier so this is
definitely I think like a big deep
conversation than that like we've just
got to have because this is just not
being used it's like a disaster
yeah I mean we're not using a package
manager at the moment but you know after
this after this conference after you
know you know here in Piper's talk on it
I I definitely would like to start using
populist I mean it sounds great to me I
think that yeah I think I completely
agree with the sentiment that of package
managers badly needed certainly
certainly beats copying pasting code
like you said we've been getting by with
github modules as a short term solution
it's actually pretty useful but of
course Nick is right package managers
badly needed to the original question
which was about things that we have
solved in our heads but haven't had time
to develop a lot of it is in the realm
of smart contracts adapt up were pretty
we're pretty confident pretty
comfortable with the
and tools that we have and they're
already starting to generate interesting
command-line tools on top of them but
for the contracts what we really want to
make is just a whole bunch of free dabs
this is kind of what I was talking about
in my talk earlier but we just want to
make free versions of things and a lot
of it is around business infrastructure
so things like invoicing and payments
and payroll and running our own
organizational logic on the blockchain
both for adapt up and for maker dough
which is a project that we're very very
involved in and so these are things that
are fairly straightforward I would
consider them solved at least in my own
head and it's things that we just need
to like Yuri said find the time to
develop so a lot of what we want - a lot
of what I want to get done in the next
year is laying down the roads not
necessarily building towns but laying
down the roads for the logic of
organizations on the blockchain
yeah just realize I didn't actually
answer the question as far as things
that we figured out but haven't built
yet one big one for us is an off chain
trading system which i think is sort of
the first component of how how augur is
actually going to scale this is a-you
know it's nothing too novel in our case
it's just 0 X slash ether Delta style
system where you've got you know
basically someone who maintains an off
chain order book and people can make and
cancel orders with them and then the
older matching is done on chain so we
pretty much know how that's going to
work we just need to sit down and
implement it we I have had a solution
for at least being able to show stack
traces in your solidity code when
something goes wrong for a while but
there's pieces to be glued together and
work to be done so all of these things
are already the the components are there
all of the pieces are there they just
have to be put together I just want to
say to that
[Music]
instead of making some random
touken oriented app that like go and
raise five million dollars or something
and that's where you're putting your
development time because raising money
is like fun nowadays like easy if you
can actually contribute to adapt hub or
to ejs or even to web three or to these
other libraries and spend your time
doing that and building your reputation
up as a developer and actually
committing to the ecosystem that's worth
so much more especially for your
long-term reputation and everything just
tagging yourself to a token project and
raising some money is like ridiculous
and like you're gonna raise all that
money and it's probably gonna be
and it's not gonna work so just
instead you know spend your time
doing something better but also like
there's some great bounty systems coming
up they're trying to build great
experiences to do bounties and I think
you know try to engage with those get
coins one of them bounties networks is
another and I know there's a few others
eath lance and everything like engage
those tools and use those try to get
yourself out there and like actually
submitting great pr's to things because
like we really need to help because
we're all inundated with crazy
random at a consistent basis so one
way to think about this is so I've heard
the phrase the lottery is a tax on
people who are bad at math startups who
are doing toget launches are sort of
like attacks on developers who are bad
at realizing that they're probably going
to be in the 99 percent who fail whereas
the people on this stage have a loosely
hundred percent chance of being useful
so if you want to be useful consider
working on tooling and we're also I know
Barry
protect your long-term ether investment
by working on tooling we were in a very
unique position in that regard at the
moment cuz as developers you know you
always want to be out there doing new
things you don't want to be taking
something that's already there and just
they're working with the status quo and
there is just so much stuff that needs
to be built you know help grow this
ecosystem and get more people involved
because the bed of the tooling gets the
more appealing if it comes to everyone
else so it's it's a great time for
developers to get into the space and and
we are still at the ground floor you did
not miss the train
you did not miss the boat we are still
in the very early days of all this all
right so on the topic of open source
what are the main challenges you what
what are immense challenge challenges
you face as an open source contributor
and maintainer and how do you try to
deal with those with those challenges
stop so for me I think I think you know
getting feedback from the users on the
library and knowing what people are
using it for that's very very hard is
typically the main interactions you have
with people when they've got problems or
they're raising issues and then the add
the other piece is just finding people
to contribute so I think that's you know
one of the best things is when these you
know someone raises a pull request and
they add in some new functionality that
say you didn't even think about in a
slightest it's the coolest thing when
someone just donates their time and does
that but it's hard to you know build up
momentum around the projects and how
people consistently come back again and
again and again and and the just sudden
knowing what people are doing with the
library I think those are the two
biggest challenges that I face anyway
yeah I just I would second that like
knowing how you're using it and what
problems you're running into how did you
start your environment so what
environment did you start with was a
truffle whatever and what kind of led to
the lineage of your problems all of that
stuff needs needs to be fully exposed
opening lots of issues is so good and
you know PRS yeah it is just the
greatest feeling when someone random
just shows up and helps you know improve
your stuff and so yeah make lots of
fantastic high-quality PRS and like kill
it yeah I've had trouble with just
ongoing support and that's just a
problem with me spreading myself too
thin across too many tools and too many
libraries and same with the helping us
with pull requests the users who answer
questions and get er and respond to
issues before I even get there are
invaluable to me and and help so much
but it's hard when there's when you're
working on a lot of stuff and and
there's a lot of support to be given
it's not always our specialty we're not
always great with interacting with
people or not always great that the the
documentation piece and things like that
and and it's a there's a lot of
different aspects to maintaining these
things I would say that one of the
challenges that that I see is well it's
kind of what I said in my talk which is
just that you know on the one hand when
we release you know tools which are
intended to be general-purpose and
naturally we want to provide as good a
support for them as you can but there's
only 24 hours in the day and you know
also if we gotta get you know I have to
get my DAP augur to release so there's a
you know there's some degree of tension
between those two aims I think that
something that's been very difficult in
tooling specifically has been changing
our minds it's been very difficult to
change your to make a real change in
your product after it's out there and
after it's open-source and after it has
users so our first tool was called
dapple and it was something it was a
labor of love I know Nick loved it for
sure he was a biggest number-one fan
for a while and it was something that
was near and dear to our heart but for
various reasons we decided to kind of
pivot to just a different model you know
we wanted to write it in bash instead of
JavaScript and we wanted to take a
different approach to it simplify it but
that was difficult knowing that there
were people already out there using it
you know and there's and it was the same
thing with our smart contracts too we
we've created smart contracts and we've
refined them and really thought about
the many many times and changed them
many times and this all of this stuff
becomes magnified when you add in new
people into the equation you know
there's this whole it's difficult to
kill your darlings when you're alone
together in a room it's even more so
when you've got a bunch of people who
have started the repo and they're kind
of expecting they have expectations
about it so I think that making tough
choices about your tools but for the
right reasons has been something that
we've found very challenging so the
final question for the next 12 months
what are you most excited about
launching augur launching maker
launching boardroom now becoming govern
X I am really excited to get more people
on board it to the Python ecosystem
because we it has been a I don't know
what the word I'm looking for here is
but the Python ecosystem hasn't been
amazing up until now and it hasn't been
well supported and that is all changing
the tools that we're making we have a
team we have resources and that stuff is
going to be worked on supported and we
we want that ecosystem to grow and
package management
I want this next year to be the year
that we get support for the spec and
across the board and support and wallets
and support and explorers for
verification and that we actually see
that take off I just want a second that
the new pi-theorem
is rad it's the
also known as pi EVM yeah yeah it's it's
very good it's very good definitely
check it out
yeah great work for me I think is just
seeing where our theorems going in terms
of like that the progress that's being
made around scaling it and with
initiatives like Klaus Moran's and the
second chain coming along the metallic
was talking about on the first day of
the conference I think that's going to
present all sorts of new challenges for
the libraries in terms of through
persons and in greater volumes and so
that's really exciting time through so
forth next wave morph it would be like
testing and spitting down everything
into several modules and yeah rating
testing testing we like just to to say
that we are proud now of what remix is
it's real nice but one aspect that we
need to improve is kind of the fact that
you can use it in the browser it's very
nice but if you have to deal with local
files if you have to deal with
continuous integration and all those 12
it's a bit more difficult so in the next
year we will definitively improve that
stuff yeah and to give a more thorough
answer something that I'm really excited
to see in the next 12 months is around
formal verification one year ago I did
not think that formal verification on
aetherium would be as far ahead as it is
today there's like measurable progress
being made well yeah yeah and we're
working on it at a pub there's other
people working on in this space but
it'll be I'll be very excited to see
what happens in the next year on formal
verification alright so we reach the end
of the session if any of you want to
talk to us about contributing to the
tools or even creating your own tools
please don't hesitate to to come and
talk to us thank you
[Applause]
[Music]