Chris Beams: Yeah, so I’ll talk about “centralized” exchanges in just a second, like you talk about, but just to get first to principles - you’re asking “Why did we create it the way that we did?” and it’s because it’s really modeled after Bitcoin itself. We wanted to build the exchange that the Bitcoin network needed in our minds. What does that mean?

Well, Bitcoin itself is this remarkably censorship-resistant network; it’s really designed as such. It’s global, it’s at this point by all accounts unstoppable, right? It’s definitely powered through different governments and different agencies, considering ways to take it down or attack it, and so on. We’ll probably see lots and lots more of that over the years to come, but for essentially zero downtime on the networks, and January 2009 the Bitcoin blockchain has just been running along more or less smoothly, right?

[08:08] We thought that that’s exactly the kind of exchange that we wanted to build - something that’s just as permissionless, privacy-respecting, and indeed censorship-resistant as Bitcoin itself. What we’ve seen emerge since Bitcoin essentially first got a price, around 2010 – the network was running for many months before anybody ever actually exchanged Bitcoin for value, and pretty much the moment that began, the first exchanges started popping up, and if people know anything about this space, they probably know at least the headlines that they read in 2013 about the Mt. Gox exchange, which was responsible for something on the order of 700 million dollars worth of Bitcoin being stolen. Of course, the reason that that was possible, for Bitcoin to be stolen, is because when you’re dealing with a centralized exchange - meaning, by the way, a website, right? Fundamentally a web app, where three parties are involved - the person who wants to sell, the person who wants to buy, and the exchange itself. When things are designed that way, the exchange has to have custodial control over the user’s Bitcoin for at least some period of time. And typically, just for reasons of convenience, people would keep their Bitcoin on the exchange for much longer than just the moment that was necessary to match a trade and then cash out.

When Mt. Gox was hacked back then in 2013, something like the tune of 700 million dollars worth of Bitcoin were under the control of Mt. Gox, and that fundamentally means the private keys that were capable of spending that Bitcoin were in the control of Mt. Gox.

That’s basically a great, big honey pot. It’s like, there’s 700 million reasons that an exchange like Mt. Gox would get hacked, and it’s utterly predictable that the beatings will continue if this sort of architecture doesn’t change. And of course, that’s exactly what happened. Over the years, there’s been an almost predictable pace of exchanged getting hacked, and various amounts getting stolen and so on. It’s just the nature of the beast. When there’s enough value in a given system or location that can be hacked, it probably will be hacked. So that’s always been our motivation - that’s the security side of Bisq, it’s the security of users’ funds; we wanna make sure that people can actually fulfill the promise of Bitcoin, which is… You know, people sometimes say “Be your own bank”, that you can actually keep custodial control of your own private keys, your own Bitcoin, and you can have as much security as you can manage.

Assuming you have well put-together operational security practices, you’re using things like hardware wallets, or air gapped computers, or whatever it is that you deem appropriate to secure however many Bitcoin it is that you have, you have that full control, you have that full capability. The Bisq application never maintains control, it never has the opportunity to steal your funds, because it never holds your funds; it’s just between you and your counterparty, essentially.

Jerod Santo: Very cool. Well, I think it’s a very apt comparison then. Let me give you a little bit of the lay of the land from Adam and my perspective, as well as our listeners, what I would expect in terms of developer knowledge, what we’ve covered on the show, and then we’ll have you walk through – because one of the reasons why we have you on is to a) understand what Truffle offers, but also using Truffle as a lens, learning what all it takes to build these decentralized applications and what all the moving parts are, because as we’ve said, it’s all kind of new and different, and that means it’s also kind of intimidating and maybe difficult to approach.

[16:25] So we’ve covered Ethereum conceptually… Way back in the day we’ve had Gavin Wood on the show; we had shows about blockchains, and Hyperledger, Bitcoin, distributed exchanges… We had shows about the concepts around blockchains, cryptocurrencies, what have you - Ethereum specifically, we’ve covered smart contracts both generically and a little bit specifically with regard to Gitcoin, which was our most recent show. And with Gitcoin, we talked a little bit about how that application specifically works with regards to MetaMask, and Web3, and those kinds of things.

That being said, from a developer’s perspective, building an Ethereum-based application all the way through, even after myself having all these conversations, is still kind of a black box… So why don’t you give us the high level of all the parts that are involved, and then we’ll kind of dive into the specific regions?

Raza Habib: Yeah, so I think that because it’s so subjective for a lot of the applications that people are building, whether it be email generation, question answering, a language learning app - there isn’t a “correct answer.” And so people want to measure how things are actually performing with their end users. And so Humanloop makes it very easy to capture different sources of end user feedback. And that might be explicit feedback, things like thumbs up/thumbs down votes that you see in ChatGPT, but it can also be more implicit signals. So how did the user behave after they were shown some generated content? Did they progress to the next stage of the application? Did they send the generated email? Did they edit the text? And all of that feedback data becomes useful, both for debugging, and also for fine-tuning the model later on. So that evaluation data becomes this rich resource that allows you to continuously improve your application over time.

Yonatan Geifman: So first of all, there’s kind of a jungle of edge hardware types. There are a lot of types of hardware that you can use at the edge, and it really depends on the application. It could be a mobile phone, that if you deploy a mobile app with deep learning in it, you will found out that your users are spread across something like ten or more types of hardware, from iOS with [unintelligible 00:10:20.22] and Samsung devices with the Qualcomm Snapdragon, and hardware types like that. So first of all, you need to understand what hardware your users or you are going to deploy on. That’s the first task.

Then you need to understand what is the software stack that is best to use for that type of hardware. If we’re talking about Apple devices and iOS, we have the Core ML, but most of the other types of hardware will probably be better running with TF Lite, or those frameworks that are optimized for edge inference.

And above all that you need to understand what is the limitations of the hardware that you’re going to use. For example, memory constraints, memory bottleneck of loading the weights, loading the data, and stuff like this… And the performance - what are you going to get if you will run, for example, an object detection model on a Jetson, how many frames per second are you going to get? How many video streams can you put on that Jetson? And this is kind of something that if you will get to the accuracy, you’ll finish building a model and only then you will measure it on the device that you are looking to deploy on; you’ll get back to square one, to redesign the model in order to get the SLA, the latency that you’re looking for at the edge… And those are things that you need to have a holistic approach and to see how you solve all of them together. It’s kind of a multi-constrain optimization where the accuracy, the latency and the model size are things that you need to consider together when building an edge AI application.

Samantha Coyle: So to add on to that, it’s kind of down too to if the team has expertise. And so if you think about really niche areas, maybe like CV at the edge… Not everyone’s gonna have the machine learning knowledge, plus the app development knowledge, plus - the list goes on. I mean, there is overlap between these different fields, but that’s another consideration when it comes down to that.

Daniel Whitenack: Adrien, you mentioned - getting more into Streamlit itself - that Streamlit is an app framework for machine learning and data science teams. I was wondering if you can unpack that a bit for people that maybe are not familiar with front-end engineering and creating apps. When we’re talking about an app framework here, for example, are we talking about just something that’s going to be like a UI that’s running in your browser? Is this having anything to do with mobile? What is the app that we’re talking about, and what does it mean that it’s an app framework? I think you’ve mentioned some things about components, and stuff like that.

Latifa Mrisho: So it’s quite interesting actually, because the experts – we did a study with about ten experts, so groups of ten, and the experts, even though they’re experts, their ability to identify the different diseases also varies, and many varies on how exposed they are to the symptoms, to the variety, and how long they’ve been working in the area. And then when you go to extension officers, the agricultural extension officers are more or less the same - if they had been exposed to these diseases, then they are more inclined to know and understand them. But those agricultural extension officers who have not been exposed to the diseases, they actually are sort of clueless.

[32:21] More or less, it’s the same for the farmers. So having a tool that it can educate and aid the extension worker to be able to do his job and help the farmers is going to help a lot more than just helping them to identify the diseases. It’s also teaching them and giving them more expertise while they are learning and using the app.

Jessica Lord: Yeah, I have a workshopper – it started as a Node School workshopper that ran in the terminal, but then I switch it to an Electron app because it’s for learning Git and GitHub, which I wanted to make more visual to explain to people… Remote versus local, and things like that. So it’s an Electron app right now, but the same robot intervenes as it was doing before. Basically, it does everything, really… It wears many robot hats.

When you’re doing Git-it, you get to the point where you add a collaborator to your project, because I felt like it was important to teach people GitHub and working with other people to actually try and simulate a little bit working with other people on GitHub… So when you add the robot - his name is RepoRobot - to your project as a collaborator, it then has access and it writes to your repos. Then you have to learn how to pull in changes, and during the rest of the course of doing Git-it, RepoRobot is verifying challenges, it’s checking the people have a GitHub account and have done this or that… It’s like using the GitHub API a lot to verify that the person has done what they were supposed to do in that challenge.

Then at the end of it all you make a pull request and RepoRobot is merging all the pull requests. So it’s going through and it’s like sort of reviewing the pull request, because after a certain amount of time, errors became common - or mistakes people were making became common. So the top three or four most common mistakes RepoRobot’s also looking out for, and will leave a comment on your pull request, telling you that “This thing was wrong. Here’s what you can do to fix it.” Then, if your pull request is great, it merges the pull request and then it rebuilds this page that has a list of everybody’s names on it that have done it, which is like 13,000+ now… Which is awesome, but also – I’m using free services as much as I can on this, and right now I have this problem where GitHub notifies you via email if you’ve been added to a project, and then you have to accept that invitation. So I’m using this third-party email service, but I’m using their free tier and right now too many people are doing Git-it, and I’m blowing through the email tier… So I have to fix this.

Chris Benson: So I want to actually pull you back for just a moment as we’re kind of learning this… If you’re an app developer and you’re interested in creating a stateful service, and you’ve started kind of going down the path about like, well, there’s kind of the old school way of going and doing a SQL query, and all that, and now we’re using LLM models and adding our data to it… I know that we’ve kind of gone beyond that just a little bit, but if you can back up and talk a little bit about what are you getting? …if you’re the app developer and you’re listening to this and you’re trying to understand, “Why would I go down that path? I sense that there’s value there”, but we haven’t talked about it. Versus a robust set of SQL queries on your own data. Why would you bring in that large language model in the beginning? What is it bringing to bear that’s worth all of that effort? Could you talk a little bit about that baseline value-add to it?

José Valim: Well, we’ve done episodes together, but you said “Oh, we are small, and we just want to have those things running”, and that’s one of the things that I think can be interesting about machine learning in Elixir… Because I thought it would come up at some point; people probably listening are like “Why machine learning in Elixir?” And I think it’s because the Erlang Virtual Machine that Elixir runs on, you can kind of – you know, if you have to do a lot of IO work, it’s going to do that well. If you have to do a lot of concurrency work, it can use all the CPUs at the same time; it allows you to say, “Hey, I want to run a machine learning model.” You can actually just run that machine learning model as part of your app. You don’t need to “Hey, I have this machine learning model. Now I have to pay Amazon to run it for me, or I have to figure out like this whole other service that I have to version it separately.” If you want - you don’t have to, but if you want, you can just run it with your servers. It’s going to depend a lot on what is the use case, the application… But at the same time - because again, Erlang is distributed, you can say “Hey, I started running with my web servers, but now the load is increasing, and I want some machines with GPU.” You just connect them with the distributed Erlang. So if you’re running on Fly, that happens by default. And now you will say “Hey, I just want these machine learning tasks to happen on those machines with GPU”, and you don’t change anything in the code. You just say which part is running the machine learning model.

So I think that’s one of the exciting things. And when you say “Oh, we are small”, I think it’s one of the appeals of just allowing people to play with those ideas, and embed within their apps. And then when trouble comes, if it comes, then you can figure out what is the next step, and you don’t have to worry about all those things up front.

Will McGugan: Okay, so the version that’s in master has been in there for quite a while, and I started building the CSS technology, but I had to leave the version master for people to use. I didn’t want to break it, and people have been using it. There is a lot of applications out there. We created a gallery, which you can find on Textualize.io. And there’s lots of apps already, and they’re using a much earlier version of Textual. What have we got? We’ve got things for managing Apache Kafka, we’ve got a to-do app, a static website generator, we’ve got machine learning monitor… Yeah, there’s quite a lot of applications out there, and they’re growing already… But we hope that once the CSS stuff is in there, that that will really explode.

Annie Sexton: Yeah. But I won’t go down that rabbit hole, talking about that client. But what I was actually doing was working on a note-taking app called Typist. And it was just the note-taking app that I always wanted. Both of the applications that I had attempted to turn into profitable businesses were just things that I wanted and didn’t exist yet. The first one that I built was a translation app for building vocabulary. I originally built it for learning Japanese, because that’s what I was doing at the time… And then, once again, got burned out on that, because I had let it become my whole identity. Any kind of spare time that I had, I was like “Time to work on that side hustle”, and that became very toxic.

Same thing happened when I was working on Typist, which I built and I actually used every single day. It’s basically Apple Notes with a Markdown WYSIWYG. Really easy, clean to use. It wasn’t perfect. I had a couple of – I had a few dozen users, but it was definitely buggy enough that it wasn’t ready yet. And I really loved it, and I really saw a future for it… But I just happened to burn out. I’ve actually recently picked it back up again, but I’ve set some ground rules for myself, which is if “I’m going to re approach this, I’d like to redo it in –” First of all, I’m rebuilding it because I’m a software engineer and that’s what we do… And ironically - or maybe not ironically at all - I’m rewriting it in the most common… “Oh, I want to rewrite this in Rust.” I feel like it’s almost become a meme now, of people who learn about Rust and are just like “Oh, I’m gonna rewrite everything in Rust.” And I say this – I’ve barely learned Rust. The only reason I’m considering this is because of - I think it’s called Tauri. It’s like an Electron alternative. Rust is very intimidating to me, but I’d like to learn it because one of the big complaints about Typist was that it’s massive, because it’s an Electron app. And I had many people who were like “Please, not again. I already have too many things that are Electron on my computer”, so I was like “Alright, okay, let’s try it.”

Jared Henderson: Yeah, so it has a web app, you’re right. That’s kind of the parent or the person who’s functioning as the parent in the relationship. They use a web app, so they can kind of administer and review stuff, and unlock things for their kids no matter where they are, as long as they have a web browser. I am actually running Swift on the server too, which is not a terribly common thing to do, but yeah, the whole Mac app is written in Swift, partially because I was learning and kind of getting into it and kind of enjoying Swift. I thought “Maybe I could –” Swift on the server was kind of a thing, and sort of a new area, at that time at least. It’s a little more mature now, but I kind of jumped in in fairly early days, where there weren’t a ton of libraries, and it’s not like everything was already solved for Swift on the server… Which a little bit appeals to me, because I’m a little bit of a guy who likes to roll my own things sometimes… But yeah, the API is written in Swift, and that allows me to actually share some code, which is nice. That was one of the – some of the core types that are shared kind of between the API and the macOS app, they’re literally the same Swift code, and they’re just an SPM module, and both the server app and the macOS app can import that and share that stuff. And then, of course, the web app‘s built in TypeScript. But I do some interesting stuff – interesting to me at least, about like typesafe [unintelligible 01:03:02.07] a little bit like GraphQL. I do some kind of my own deal, where I kind of take some of the types that live in the Swift world and kind of generate TypeScript types for them. I know you’re not a big TypeScript guy, Jerod…

Nick Nisi: So in 2011 I was working on an app – my first big challenge with Dojo was converting a 1.4 app to a 1.7 app, which meant completely changing over to AMD and learning that. I did that for a while at this startup; the CTO at that startup, John Christopher, he really was a big fan of Dojo, and dGrid was this other project that’s kind of a grid implementation that’s used in the Dojo ecosystem, and that was a really powerful tool for us in the app that we were building at the time.

Then it was from that dGrid project that I actually became familiar with SitePen and started looking to them as my next adventure in my career. I’ve been there pretty much ever since, so for about five years now, contributing to Dojo 1 and Dojo 2, and teaching workshops, and things like that. So I’ve been really happy to be a part of this community, and I think that there’s a lot fo really cool ideas that have been improved upon from Dojo 1.

One thing in particular is the Dijit system, with its declarative syntax for creating widgets that you can use, and having a whole lifecycle around that. That seems like it’s an earlier implementation of what Dylan was saying, like web components, or maybe even like React components. I think that it could maybe be seen as like a building block to get to where we are today, which is really cool.

Suz Hinton: It’s really hard to think of it. I actually have two examples… So I’ll cover React at first. The thing that annoys me about React is that when you have a loop and you’re iterating and you’re spitting out things based on an array or a map, and you’re returning components, you have to give it a key attribute, right? And it barks at you if you don’t do that. That is not something that should ever have to be necessary, in my opinion, in an API. You should not have to actually give a numeric key in order for React to be able to do its thing properly.

It has no bearing on your app at all; you’ll probably never ever use it… So warning you that you didn’t do it and forcing you to when you’re not even gonna use it in the first place - I think that’s implementation leakage.

Sarah Moeller: I’m excited about what I do, and I’m excited about the linguistics, but I also get excited on things that aren’t directly connected to what I do, but are hopefully consequences or by-products. I get excited seeing humanities and linguistic students who now have programming skills, which puts them in a much better position in the job market. I know what a difference it made for me and my prospects.

I get excited for people out there, hobbyists, community members, probably people at hackathons - I hope there’s more - who are building useful technology for minority communities, for them to use their language, to learn their language, or just things that are in their language, just to build that sense of identity and pride and value that they have, I believe, just because they are people God created. Yeah, seeing other people take some of what we’re doing or building off of it and building tools that– because what I’m doing is kind of theoretical and scientific. You have to make several jumps to be things that people who aren’t interested in this specific area think are cool, but language learning apps, or spell checkers and Microsoft word. Those sort of things are exciting to see people build.

And for the momentum - when I first started in this area, there wasn’t very much work being done on computational morphology. It was starting, because most of the work had been done in English, and again, Mandarin or European languages, which are not complex in morphology either; they’re fairly simple. So that’s grown a lot. And then I think specifically in this intersection of documenting and describing endangered languages with NLP is this realization that we have to do a human-in-the-loop. We can’t expect to just get more data. We also can’t expect to– there’s a lot of cool techniques about how to augment data, how to “hallucinate” data in interesting ways that does actually help the models, but they only go so far.

So this realization that we do have to build some way to bring the linguist, hopefully the native speakers back into the loop - that that’s the best way to go, and to bring it to a place where they are involved, and there are interfaces. So the flip side of that is it becomes accessible to them. Those tools, the NLP stuff just doesn’t remain in the computer science departments in the big companies, but it becomes something that’s accessible to speakers and workers in minority communities. That’s really exciting for me to see. That’s a trend. That’s kind of what I recognize, and a lot more people are realizing, kind of confirming what I thought, that this has to happen.

Georgi Gerganov: Yeah. So what made it attractive, I guess, as you said - okay, the simplicity I think definitely. It’s about ten thousand lines of code. It’s not that much. But overall, this neural network is at the core there. They’re actually pretty simple; it’s simple matrix operations, additions, multiplications and stuff like this… So it’s not that surprising.

Yeah, another thing that generated interest was the speed, and it’s a bit tricky topic… But yeah, so I was mostly focused on learning this on Apple… So I don’t use Python a lot, and pretty much I don’t use it at all, and I don’t really know the ecosystem very well… But what I figured is basically if you try to run the Python codebase on an M1, it’s not really utilizing yet the available resources of these powerful machines yet, because if I understand correctly, it’s kind of in the process of being implemented to be able to run these operations on the GPU, or the neural engine, or whatever. And again, maybe it’s a good point to clarify here - maybe there’s some incorrect stuff that I’ll say in general about Python, and transformers, and stuff like this, so don’t trust me on everything, because I’m just kind of new to this.

Okay, so you run it on an M1… The Python is not really fast, and it was surprising when I ran it with my port, it was quite efficient, because for the very big matrix multiplications which are like the heavy operations during the computation, I was in the encoder part of the transformer, and learning those operations with the Apple Accelerate framework… Which is like an interface that somehow gives you extra processing power compared to just running it on the CPU. So yeah, it was efficient running Whisper.cpp. I think people appreciated that.

[16:07] There was – I said it was a bit tricky, because there was this thing with the text decoding mode… So yeah, I’ll try not to get into super-much details, but there were basically two modes of decoding the text, like generating the transcription; they call it the greedy approach, and beam search. Beam search is much heavier to process in terms of computational power compared to the greedy approach. I just had the greedy approach implemented, and it was running by default, while on the Python repo it’s the beam search running by default… And I tried to clarify this in the instructions. I don’t think a lot of people really…

Abubakar Abid: Yeah, absolutely. So I’ve been doing machine learning for about a decade now. I did my Ph.D. at Stanford, and I worked a lot on building machine learning models for medical imaging and medical videos, that kind of thing. And during the course of my Ph.D, I would often work with collaborators who are not machine learning scientists, not machine learning engineers. They were doctors, clinicians, biologists, that kind of thing.

[04:05] And one of the things that we realized was - well, first of all, not everyone knows how to use machine learning models directly, not everyone can code, software engineering and all of that good stuff… And we wanted to make it easy for other people to try out the model so that they could get feedback. Because you know, sometimes you tell someone, “Hey, I trained a model for you. It’s 95% accurate”, they’re not going to believe you. They’re not going to take your word necessarily, so they want to try it out themselves and test it.

And so we started off with a very simple library that was designed to make it easy to test computer vision models. That ultimately grew into Gradio, which is an open source Python library to build machine learning models very generally, to build GUIs for machine learning models very generally, to build demo web apps for machine learning models… And then I actually finished my Ph.D. at Stanford last year, and then soon after that actually, Gradio got acquired by Hugging Face. And so now we’re here at Hugging Face, which is a fantastic place to be, and really, we have this amazing mandate, which is “Hey, let’s make Gradio the default tool for machine learning practitioners to build demos”, to get their work out there, so that other people can access their work, so that machine learning researchers can make their work more reproducible, machine learning teams can easily collaborate and kind of see what machine learning models are actually doing. And we’re hoping to grow this a lot more in the next few years.

Jerod Santo: I mean, saying “Where did you learn it?” assumes a few things about me, like I’ve actually learned it… Which I haven’t. I’m still dorkin’ around… I’m trying to create shareable snippets of our shows, and stuff like that, and make them a little stickier than the ones that I can produce quickly in web apps… So I’m learning it as I go. But yeah, I’ve just turned to YouTube specifically, because it’s free and quick, and it’s goal-oriented. I can say “How do I do captions in After Effects?” and there’s a video on that. Probably not the best way to learn it, but that’s what I’ve been doing.

Adam Stacoviak: [19:57] Maybe it’s something that everyone can really identify with, is when you read your credit card statement, and you’re like “What the heck is that?” They’re using machine learning in their Apple Maps to reduce the obfuscation of their merchant names, which is like “Hey, this is literally the 7-Eleven on the corner” versus whatever it might be…

Sean Larkin: But dialing back… Man, get some popcorn or whatever you want; I’ll try and not make it a long story. Long story short, I’m a previous technical support rep who kind of went rogue, and got tired of not being able to fix people’s problems. The first place I worked at in the tech community was when I moved here to Nebraska - my wife’s from here - and I just wanted to get a job that was consistent. So I did tech support, and I did a really great job at it, but it was just so frustrating having to work around issues, getting the same calls every day… So I kind of took an interesting quality assurance in programming, and started from just doing like little Apple scripts, to learning Ruby…

[04:16] I worked hard enough at that company and kind of proved my worth, and they eventually hired me to work on Objective-C for their native application product that they sold. From there, I had the official title as a software engineer.

Nine days later I got fired on my birthday for sharing one line of source code. TL;DR version is some people were not very happy that I had been able to make it as a software engineer, people on the support side of the company. So I think they were just looking for a reason to get rid of me. But I tell people that because it’s like the best thing that’s ever happened to me. I was able to work at a small digital agency and got to kind of bust my chops with Ruby, Ruby on Rails and some other web technologies, and then I had the opportunity to work in Omaha for the first time at a retail company called Hayneedle, who got bought by WalMart now. I did a lot of almost fully exclusive JavaScript.

Then I worked shortly at another contracting job where I got introduced to Webpack, called Infogroup. I was kind of blown away at how incredible the dev experience was. Mind you, I didn’t have to set it up myself… I’ve heard the stories from people. But it was already set up and it was just an awesome development environment, and there was a React shop… It was kind of my first time experiencing a bunch of different technologies, but it was a great learning experience.

When I left there to take a job at Mutual of Omaha as a UX developer where I work currently – you know, being at an insurance company you get the opportunity to have a little bit more research and development time, because you have things like compliance, state compliance, copy and legal… So the dev flow or the dev cycle is a bit slower. My first few weeks working there I had the opportunity to research Webpack and Angular. I was able to get some sort of boilerplate setup, and we use still exclusively across our team.

From there… I didn’t even know you could submit talks to conferences… That was kind of a new thing to me. So I’d just submitted a talk to NG-Conf, and I was lucky enough to get accept. They said, “Alright, we would like you to actually do a workshop on how to use Webpack with Angular 2.” That was a whole immersive learning process for me as well, and ever since then I realized how important it was to kind of spread the word about Webpack. It was at that time that I found out after the workshop - which went really well… You know, a lot of people were like, “Who is Webpack? What is this?” The Angular community had no idea really, with the exception of a few people, so it made me kind of frustrated, because you see this tool which has so much potential, and nobody really knows about it in this community.

The first thing I did was try and really stress how to get funding for the team. I kind of put myself out there and jumped in the Gitter chat that was there (a web-based chat, kind of like Slack, but for GitHub repos) and at private I mentioned all of them and pulled them into a private channel and I was like, “Hey, I wanna get you guys paid. I really believe in your tool. How can I help?”

[08:00] We talked for about three weeks off and on, and I found out that Kent C. Dodds was doing a podcast - JS Air - with that core team on it, and I was like “Oh my gosh! I need to meet them!” I think I talked to Jeff Whelpley and I said, “Hey, can you get me on this panel? I just wanna be there as like a panelist and just talk, or sit behind the scenes.” I don’t know if it was because Kent wanted to save face or something, but the week before it was announced, he goes “Introducing the Webpack core team”, and I’m there, right next to those three, and I’m like “Oh my gosh…!”

The day of the podcast/live stream they asked me “Do you want to be on the core team?” and I said “I would love to.”

William Falcon: That’s a good question. Generally, I like to think about what we’re trying to do like that leap between Windows machines to Mac machines, where things just work. Like, what is that Apple experience for machine learning. And to answer your question, it’s very easy. It’s not as easy as I want it to be today, but it will be. Basically, there are a few ways. We have three tiers of usage on Grid. We have the community tier, which is free. Literally, you’re just paying the AWS compute. There’s nothing in there; we’re just orchestrating stuff for you. But it doesn’t really work for teams and big companies, because there’s a lot of stuff that needs to happen. Then we have the teams and enterprise tier, so that you do those kind of things.

On the community tier, you literally have to do nothing. You just copy-paste the link to a GitHub file, you paste it into the UI or use the CLI, and you select how many GPUs you want, and you press enter, and you’re done. It’s that easy. Dependencies are automatically pulled for you, they’re inference from the code that you have, your requirements, all that stuff. So we try to do as much as possible.

Yes, there will be times when that fails, and we will work with you to figure out what happened, and make sure that we get it done… But you know, dependency management is a big deal for everyone, and it’s a really hard problem to solve, so it’s gonna take us a while to fully solve that problem. But if you are at a company or a big lab, usually – we call that community tier. That’s gonna work great for side projects, and public data, and stuff like that; Kaggle, prototyping things… Sure, if your data is not secret, then it’s fine. It’s great for academics as well.

But if you have corporate data, then you’re gonna be in the teams and enterprise tier. There, what you end up doing is we basically link up your cloud accounts. So you just set it up through Grid, you’re passing credentials through there, and then those keys let us control resources on your behalf only as much as you allow us to, to make sure that we orchestrate everything on your cloud. So it’s kind of this hybrid on-prem vs. not on-prem. We also offer on-prem if people want it.

[42:47] So once you do that, you basically put in your cloud credentials in there, then you’re good to go. When you run stuff on Grid, instead of running on the Grid Cloud, which is a community cloud, you just select your cloud, whatever you named it, and then you just run on it. That means you can link up as many of these as you want as well.

Alexis Richardson: GitOps is – we called it “operations by pull request.” It’s fundamentally about automation. Git and ops. Git is, as you know, an open source shared control system for documents and code, which has many implementations including GitHub, GitLab, BitBucket, and others… And actually, you don’t even need to use Git for GitOps, but it’s probably the best implementation of the concept.

And around Git we have developer workflows. And the developers who are doing these workflows used to just write code and push it, and then they would have other tools that did infrastructure automation. With GitOps we see a much tighter coupling between that and a new class of automation tools for operations. So in GitOps, operations is as automated as you like, and is triggered by changes in what’s in Git, which we call “the source of truth.”

The people who love GitOps love it because they can ask questions like “Is my infrastructure/my cluster in a correct state? If I destroy my infrastructure or delete it, can I start it again in the right state, and can I upgrade just by making config changes?” If you can’t do those things, you will end up in a manual, semi-automated mess, and that’s why so many people today have got stuck with one or two or three snowflake Kubernetes clusters, which end up getting frozen… And then when the team that built them move on, they don’t know how to adapt them to new circumstances.

Commercially, we are engaged with customers who are building application platforms using this. Yesterday on the stage with Fidelity we showed how GitOps was an enabler for – currently it’s on Amazon, but it’s designed inherently to be MultiCloud. A new class of application platform for categories like machine learning, big data, mobile apps etc. So it’s a very, very powerful technique for building application platforms using our products, and also many open source tools.

Alex Moore: Yeah, so I think we have to rewind back to that Steve Jobs speech in 2007, where they announced “We’ve got a great new way to do –” You can watch the whole speech online, but he said “There’s a great way to build web apps, because we have the whole Safari engine inside the iPhone. And there’s no SDK required.” Basically, for anyone who’d ever built mobile applications prior to that day, they were really difficult. They were kind of Java applets, and it was really complex to get a working mobile app onto a phone. And we just thought it was a great direction; we’d already had a lot of experience building web technology, and we started investing in learning how to port our apps or create side apps for mobile.

Then about a year later they announced native apps, the App Store and native apps. And at the time, both of us thought “Yeah, that’s good.” Especially back in 2008 web apps couldn’t do everything, and so having another ecosystem that could fill those gaps just seemed reasonable. But then gradually what happened was there were all these features that would come out for native apps… And we kind of expected that there’d be a lag that we were getting for the web. You know, six months down the track, or a year down the track… And the one I remember the most was notifications. It came out for the iOS apps I think in 2009, by memory. And I was thinking “Oh, maybe next year we’ll get notifications for web apps.” But in 2010 it didn’t happen, in 2011 it didn’t happen…

[00:10:06.02] And at this point, there was – originally, obviously it was only Safari. And when the App Store came out, Apple created a raw – it was 2.5.6, all browsers must use the WebKit and JavaScript framework… Which is kind of not quite true. What they actually mean is “We’re gonna ship a web view”, which is kind of like a full-screen operating system component outside of the browser Chrome, where anything within that is exclusively controlled by Apple. So you know, you can do a menu, and you can do the tabs system, but whatever is actually in the web page itself was completely controlled by Apple. And browser vendors not only couldn’t bring their own browser engines, they couldn’t even make modifications to WebKit.

Now, at the time, back in 2011-2012, Safari was still a very competitive browser compared to what the other browsers were offering, especially considering that the Google Chrome team were also still on WebKit as well, so all their contributions were also going into WebKit and getting to developers that way.

Amal Hussein: Yeah. I have to echo – a couple shout-outs to some web APIs that I think have helped smooth the link communication in mobile apps… The Web Share API - I don’t know if y’all are familiar or remember it. It’s not that old. Essentially, it’s a way for you to share information, with anything, from your phone. So you can actually implement it, which is really nice. It works beautifully on Android and iOS. But I think for me the walled gardens, like the areas where you’re interacting with the web through a device that’s perhaps owned by a proprietary company, and the company has interests in you using their app store… I feel like the web has had a really tough battle, both with devices getting smaller and faster, and better to use, and the long arc of the web - how long it takes for things to get updated etc. Not all websites really caught up with it, so you don’t have this graceful, beautiful, out-of-the-box experience.

So there’s just so many uphill battles that I’ve seen for the web. We’re still very much in the thick of it, specifically also for new internet users, like folks coming online for the first time. There’s millions of people in Brazil and in India coming online for the first time every year, and they’re kind of learning about the internet through apps. And when I say apps, I mean native apps that come pre-installed on their low-end devices. And I can say the same thing about my younger siblings, that are much younger than me.

[12:17] So the web has a lot of catch-up to do, I would say, in certain areas… But obviously, if you take the accessibility of the web and you kind of supercharge it with the powers of native apps, that’s what you’re supposed to get with progressive web apps, and potentially projects like FUGU from Chrome.

Stu Keroff: And we’ve actually tried approaching a few different things in that time. The first and most immediate thing is that we want every kid in the club to at least once experience installing the operating system itself. When people go to the store and they buy a computer, a lot of them simply just take it as is; it’s the default choice - whatever it came with, that’s what it has; why would it have anything else? And we tried to take the mystery away from that. We hand them a flash drive and say, “No, this computer doesn’t have any of that. It’s been wiped completely clean. YOU are going to put it there.”

Every kid in the club, at a minimum, does that. But from there, then we have them learning how to install the apps and configure the apps that we want the computers to have; depending on where they’re going, there will be different packages of apps. We teach them a few different ways to make sure the apps get onto the computer. It’s like, “Well, you can use the app store for your distro - that’s one way, and it’s easy. You can use [unintelligible 00:27:40.14] for things that aren’t in the software store, but you still want the computer to have. And you can use the terminal window. You’re going to experience all three.”

[27:51] They can see what the differences are and how each one is going to apply in different circumstances. Depending on the hardware available, sometimes kids are also doing things like installing hard drives or RAM, depending on what the machine needs. Again, we don’t always have time to do these things just for kicks; generally, if we’re working on a computer is because we have a plan for it. But we’ve had kids also installing video cards in the past… So a few different odds and ends like that. Then there’s also just troubleshooting and testing things to make sure everything actually works.