 My name is Yuri Matias. I'm the lead developer of the Embark framework. I quoted other tools as well, such as AtterSIM, which later got turned out into what you now know as TestRPC. 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 sent our contracts out for their final security audits. So those, thanks. And so those come back with green light, and then we'll launch. So that's what I've spent literally all my time on. Hi, my name's Andy Millennius. I'm a developer with DAP hub. 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 Ethereum API. And we have a standard library, a provable 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 Wayfund for a while, which some of you may know. But I kind of stopped doing that because crowdsales are just exhausting. I can't take it. So and doing ETHJS and a few dev tools and floating around for quite some time. So that's me. Hey, everyone. I'm Connors Benson. I'm the author of a library called Web3J, which is the Java and Android library for integrating with Ethereum. It provides full JSON-RPC implementation, but then also smart contract wrappers so you can work with smart contracts directly from native Java code and supports offline transaction signing or the filters and everything else. I'm also the founder of a company called BLK.io, which is building out tooling on top of Ethereum and Quorum, focused really on making it a lot simpler for companies and people who want to work with blockchain technology, but are less technical to kind of make sense of what's happening. Right now, really, you kind of need to be a developer who understands EVM bytecode in order to make sense of what's happening. And we're trying to address that. Hello. Yeah. So I am Ian Levro. I am working on Remix, developer of Remix. So Remix is a web ID, web-based ID, where you can write smart contracts and run smart contract as well. So these tools is mainly focused on debugging features. So you can run and debug transactions and also code analysis. So yeah, we have started this tool like one year and half ago. And we are in a state where it is used by many people, but we still have a lot to do. And we hope that in maybe one year or less than one year, we can have something that is really usable. It is now, but we still have so much to do. Thanks. Hi, I am Piper Merriam. I am the lead Python, the Python team lead for the Ethereum Foundation. And I am building out the Python tooling ecosystem for Ethereum developers. Sort of a three-pronged thing with Web 3PY, which is a counterpart to Web 3JS, 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 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 guys tell us 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, 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 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 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 days of confusion and questioning my own personal identity and why I was doing this. Yeah, and essentially, so the dev tools I created with ETH.js was just, I got pretty frustrated with Web3 and just wanted to do my own thing that worked for me, which is good and a bad thing. And then with things like ETH.deploy, I just wanted my contracts to deploy. 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 when I was initially starting way back, it was like Remix was like a C++ client and there was nothing and Web3 kind of worked and the Node kind of worked, but things didn't really work either. And so it was just like any sort of comfort you got from building the dev tools. I think that's just like a sanity check almost. So yeah. For me, it was kind of a bit of a disconnect in that there was all this noise in the media about blockchain, blockchain, blockchain and big enterprises using it. I'd spend 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 all these enterprises want to work with this technology. So then in the Ethereum ecosystem at that point, all you had was EthereumJ, which was a client, but you didn't actually have the tooling for integrating seamlessly with the JVM and the goal there was just to address that gap. Yeah. So for this tool Remix, I would say that we have started a long time ago to work on it and before the name was Mix. And the reason why we did that is that from the beginning, beginning, we will need to be able to debug 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, the first circumstance where we started to build Remix, to debug transactions. And to continue the theme, solving problems that I had during development, the populace 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 Ethereum ecosystem, it was ripped out of populace 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 a common thread here. We were living off the land back then. So a lot of tools that we develop are in different platforms, so they don't overlap. But in some ecosystems, especially the JavaScript one, there's a lot of competing tools. So how important is that diversity? Are we better off all focusing in one tool for each ecosystem and make it the best we can? Or is it better to develop several competing tools and try 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 in the JavaScript ecosystem, for instance. So for instance, our tools work really well from the command line and from Bash and that's kind of how they're developed with this 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, but the way that we approach it could be completely different. Can I continue? Sorry. Yeah, I'm very 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 audition of libraries and have good experience developer that can review libraries. And it's not really 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 to, yeah. I was just gonna add to that as well. I think that there's certain things though that can certainly help in this regard and that's for library developers, making sure that their code's modular, pushing like individual artifacts out there. And there's been a lot of movement in this space, but it's encouraging that reuse because there's that classic problem where people see a library and it doesn't quite do what they wanna do. So then maybe they'll go and ride 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 solve the problems that they have, but then they can build on top of that rather than the emergence of too many competing versions of things, doing similar things. I can kind of mirror that in a certain sense that there's a number of different abstractions that need to exist in every language ecosystem. We need tools for ABI and coding 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 gonna 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 have a better version of that and that's a good thing. Yeah, like 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 gonna approach handling data and then how you're gonna approach constructing a library. And I think the message about quality over quantity is definitely right. Like we shouldn't have a bazillion querying layers or something in JavaScript. Like you don't need that, like we just don't need that. But I think building them in isolated, small pieces is always, at 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 wanna break it down to its smallest pieces. But also like then I'll do all this JavaScript stuff and it's fantastic. And then I'll look at like the latest PyTheorium and then I'm just like, ah, shit. Like, you know, it's way nicer. Just cause it's just like, you know, there's no depth to the code. Like it's literally two or three lines deep and like it's just fucking tests. And I'm like, oh, shit, you know. So it's just across languages. I think you wanna also look at what's available everywhere because there's fantastic tooling coming up from different languages at different times. And like screw just JavaScript. Like JavaScript's great and it's accessible. But like, you know, 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 say JavaScript is great, but yeah, I mean, I think for, you know, libraries in different languages, I think it's completely fine and 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's subtly different than an existing library and there's some new niche that it's filling, then 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 offer general purpose libraries is that we're not just writing a library because there's a quote from Joel Spolski. He said that code is easier to write than to read. And I think that that's true. And I think 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 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 don't have the time to implement yet the solutions? I'll start. So 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 and another ERC for specifying some higher level stuff and just, well, like I said, tooling support. And it's not trivial. There's a lot of work to be done. I'm forecasting it's going to 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 those tools, the support shows up and we get network effect across different language boundaries and things start moving faster. Can I continue? Oh, yeah, yeah. Yes, so I think you're already right. And for remix, the same thing we need and we plan and we have thought about integrating and implementing the package manager. And it's like, there's a lot of stuff to do, a lot of work to fix as well. And then, yeah, it's very hard to be fixed in a point and to implement these things. But I hope we'll do that. I was thinking that, yeah, there is something in remix that is quite important and we need to overcome that. This is a web app and inside this web app there are different modules and they are kind of independent, but they are still packaged in the same big modules. And we want and we need to split up everything so maybe some modules can be used inside other tools or inside other web app or I don't know what. And this is something that's a nice example for the question that we need to do, we have to do, we will do, but we always say, okay, we need to do that, but that's in two months or three months because we don't have time or so on. So, yeah, this is, yeah, this example. So, yeah, I think the package management stuff for Ethereum, 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 comment 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 is 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 or whatever. But if you make that mistake in contracts it's like shipping hardware 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 to 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 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 MPM ecosystem and why that was so successful. But then again with the MPM ecosystem, like, how many crappy packages are shipped every day. So 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 that we've just got to have because it's just not being fucking used. It's like a disaster. Yeah, I mean, we're not using a package manager at the moment, but after this conference, after hearing Piper's talk on it, I definitely would like to start using Populus. I mean, it sounds great to me. I think that, I completely agree with the sentiment that a package manager is badly needed. Certainly beats copy-pasting code like you said. We've been getting by with Git sub-modules as a short-term solution. It's actually pretty useful. But of course, Nick is right. Package manager is 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. At DappUp, we're pretty confident, pretty comfortable with the command-line 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 Dapps. 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 DappUp and for MakerDAO, 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 to... 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, I just realized 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 Auger is actually going to scale. This is a... it's nothing too novel in our case. It's just a 0x slash Ether delta style system where you've got basically someone who maintains an off-chain order book and people can make and cancel orders with them, and then the order 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. 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 components are there. All of the pieces are there. They just have to be put together. I just want to say too that instead of making some random token-oriented app that go and raise $5 million or something, and that's where you're putting your development time because raising money is fun nowadays, and easy, if you can actually contribute to Dapp Hub or to EATJS or even to Web3 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 ridiculous, and you're going to raise all that money and it's probably going to be bullshit and it's not going to work. Instead, fucking spend your time doing something better. But also, there's some great Bounty systems coming up. They're trying to build great experiences to do Bounties, and I think try to engage with those, get coins, one of them, Bounties Network is another, and I know there's a few others, ETHLANCE and everything, like engage those tools and use those. Try to get yourself out there and actually submitting great PRs to things because we really need the help because we're all fucking inundated with crazy random shit at a consistent basis. 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 token launches are sort of like a tax on developers who are bad at realizing that they're probably going to be in the 99% who fail, whereas the people on this stage have a loosely 100% chance of being useful. So if you want to be useful, consider working on tooling. We're also in a very... Protect your long-term Ether investment by working on tooling. We're in a very unique position in that regard at the moment because as developers, you always want to be out there doing new things. You don't want to be taking something that's already there and just working with the status quo and there is just so much stuff that needs to be built to help grow this ecosystem and get more people involved because the better the tooling gets, the better it comes to everyone else. So it's a great time for developers to get into the space. 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. On the topic of open source, what are the main challenges you face as an open source contributor and maintainer and how do you try to deal with those challenges? For me, I think getting feedback from the users on the library and knowing what people are using it for, that's very, very hard. It's typically the main interactions you have with people when they've got problems or they're raising issues. And then the other piece is just finding people to contribute. So I think that one of the best things is when someone raises a pool request and they add in some new functionality that you didn't even think about, it's the coolest thing when someone just donates their time and does that. It's hard to build up momentum around the projects and have people consistently come back again and again and again. Just that and knowing what people are doing with the library, I think those are the two biggest challenges that I face anyway. Yeah, I would second that. 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 it truffle or whatever? And what kind of led to the lineage of your problems? All of that stuff needs to be fully exposed. Opening lots of issues is so good and PR is just the greatest feeling when someone random just shows up and helps improve your stuff. 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 helping us with pool requests, the users who answer questions in Gitter and respond to issues before I even get there are invaluable to me and help so much. But it's hard when you're working on a lot of stuff 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, we're not always great at the documentation piece and things like that and there's a lot of different aspects to maintaining these things. I would say that one of the challenges that I see is it's kind of what I said in my talk which is just that on the one hand when we release tools which are intended to be general purpose and naturally want to provide as good a support for them as you can but there's only 24 hours in the day and also we've got to get my DAP auger to release so there's some degree of tension between those two aims. For us, I think that something that's been very difficult in tooling specifically has been changing our minds. It's been very difficult 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 DAPL and it was something, it was a labor of love, I know Nick loved it for sure, he was our 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, 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 and it was the same thing with our smart contracts too. We've created smart contracts and we've refined them and really thought about them many, many times and changed them many times and all of this stuff becomes magnified when you add in new people into the equation. 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 starred 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 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 GovernX. I am really excited to get more people onboarded to the Python ecosystem because 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 want that ecosystem to grow. And package management. I want this next year to be the year that we get support for the spec across the board and support and wallets and support and explorers for verification and that we actually see that take off. I just want to second that the new PyTheorium is fucking rad. It's the shit. Also known as PyEVM? Yeah, it's very good. Definitely check it out. Great work. For me I think it's just seeing where Ethereum is going in terms of the progress that's being made around scaling it and with initiatives like Plasma and the second chain coming along that Vitalik 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 throughputs and handling greater volumes and so it's really exciting times for it. So for us, the next 12 months it will be testing and splitting down everything into several modules and really testing, testing, testing. I would like just to say that we are proud now of what Remix is. It's really nice. But one aspect that we need to improve is kind of the fact that you can use it in a 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 stuff it's a bit more difficult. So in the next year we will definitely 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 Ethereum would be as far ahead as it is today. There's like measurable progress being made. What? Yeah, yeah, yeah. And we're working on it. At Dapp Hub there's other people working on it in the space but I'll be very excited to see what happens in the next year on formal verification. All right, so we reached 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 come and talk to us. Thank you.