Putting AI in a box at MachineBox

Bandwidth for Changelog is provided by Fastly. Learn more@fastly.com we move fast and fix things here at Changelog because of Rollbar. Check them out@rollbar.com and we're hosted on Linode servers. Head to linode.com changelog this episode of Practical AI is brought to you by Hired. One thing people hate doing is searching for a new job. It's so painful to search through open positions on every job board under the sun. The process to find a new job is such a mess. If only there was an eas. Well, I'm here to tell you there is. Our friends at Hired have made it so the companies send you offers with salary, benefits and even equity up front. All you have to do is answer a few questions to showcase who you are and what type of job you're looking for. They work with more than 6,000 companies, from startups to large publicly traded companies in 14 major tech hubs in North America and Europe. You get to see all of your interview requests. You can accept, reject or make changes to their offer even before you talk with anyone. And it's totally free. This isn't going to cost you anything. It's not like you have to go there and spend money. Get this opportunity. And if you get a job through hire, they're even going to give you a bonus. Normally it's 300, but because you're a listener of practically I, it's $600 instead. Even if you're not looking for a job, you can refer a friend and hair will send you a check for $1,337 when they accept the job. As you can see, hire makes it too easy. Get started at hire.com PracticalAI.

Foreign.

Welcome to Practical AI, a weekly podcast about making artificial intelligence practical, productive and accessible to everyone. This is where conversations around AI, machine learning and data science happen. Join the community and slack with us around various topics of the show@changelog.com community. Follow us on Twitter. We're @practical aifm. And now onto the show.

Welcome to Matt and David from Machine Box. It's great to have you here on Practical AI. I know that Chris and I when we started thinking about guests for Practical AI and I was thinking about our our slogan or our mantra at Practical AI, which is making artificial intelligence practical, productive and accessible to everyone. I know the first people that came to my mind when were Matt and David from Machinebox. So welcome guys.

Thank you very much. It's great to be here.

Yeah. Thank you.

Yeah. Let's start out Maybe with just a kind of brief personal intro from both of you guys. So David, why don't you start by giving us a little personal intro?

Yeah, I'm David Hernandez. So my background is in computer science and engineering. So I was studying back more than 10 years ago in the uni. Machine learning and artificial intelligence mostly. I never use it till recently, the last three years that the machine learning was booming and I started to get through, implement, refresh my knowledge and started to implement things and probably that's how we started Machine Box in some way. Professionally I've been developing since I finished my degree almost. Also 10 years doing distributed systems website. My highlights probably I work at the BBC at 2012 for the, for the Olympics. So we were delivering the real time system to all the stats and all the video player data for the Olympics basically was real nice project.

So.

Yeah, that's it.

Sounds great. And Matt, why don't you give us a little bit of an idea of where you're coming from?

Yeah, sure. So, hi, my name's Matt Reyer. I've been doing computer science all my career in various forms. I spend a lot of time in the GO community at the moment. I kind of fell in love with GO as a language before it was released as version one. There was a little experimental tag in Google App Engine and I wanted to build something on App Engine and anything that's got a little experimental tag is going to grab my attention, it always has. So I jumped into the language kind of quite early and I've just been kind of using GO since then, really wherever I can. And turns out you can use it everywhere. I speak at conferences about GO mainly, and also I have a book, Go Programming Blueprints, which is nice because you build real projects in that book. So it's not a book where you learn the language or you just learn theory. You actually build real things. So it's very practical and very pragmatic and that's why I quite like the way you guys are approaching this podcast because, you know, complicated things can be extremely powerful, but they're very difficult for people to kind of marshal and get, you know, get into a shape that they can put into production. And that's really our philosophy at Machinebox, is to give people a head start on that and get them into production much quicker.

Hey Matt, while we're at it, what's the name of your book before we go on?

Oh, it's called. Thank you. It's called Go Programming Blueprints. Colon, second edition.

Okay, thank you very much.

Yeah, you don't have to say it in that accent, but it helps.

It sounds much better.

I think it does help.

So how did you guys originally meet and how did you start thinking about forming a company together that's focusing on AI?

Well, that's interesting story. So back few years ago I was one of the organizers of Golang uk, the first one. Now Gopher Coin UK or just go for Coin, I don't know.

Gopher Con uk.

Gopher Coin uk. So Matt was one of the speakers. So I met actually Matt in that conference. He was in, in another company before and I was looking kind of for a job. I was contractor at the time. So I joined the same company that Matt was and we met there. Basically we worked there for a few years.

Yeah.

David has a really kind of unique ability to think very clearly about big problems that are otherwise very complicated. And that's, that's a key skill for any team to have. If you can bring somebody in that can look at these kind of big broad problems like massive kind of scale, planet scale sort of problems like you said, like David mentioned earlier, he was part of the team that delivered the software that ran the Olympics and you can't, there's no dry runs of that. You can't say to everyone, guys, can we just like a week before, can we just have another Olympics just so we can test out all the, all the software? They'd probably say no. So having somebody like that on a team is invaluable. And it was very natural when it came to looking at machine learning and David's expertise in it. It was kind of his eureka moment where he said, you know, we could actually kind of containerize this and deliver it in a way that makes it very trivial for everybody to use machine learning capabilities rather than having to learn TensorFlow and work in these kind of abstract mathematical models. We could tell some stories differently. We could give people an API that just makes it very clear and sort of changes the way you think about the problem a little bit. It focuses really on the problem that you're trying to solve rather than technical sort of low level machine learning components that you might use to solve it.

Yeah, that's great. And again, I think I've been a Machine Box user for quite a while. I think very soon after you guys launched I was super excited about it just because of the practicality of the project. So in terms of what Machine Box is actually, as a developer, if I was wanting to use Machine Box to do something, what might that something be and what would be the interface to doing that.

Yeah, sure. So Machine Box is basically, we deliver machine learning models in Docker containers. So what you basically need is Docker install in your computer that is available in any major platform. Windows, Mac and Linux. You just Docker pull one of our images, you have a nice API in our images. So you only need to know about HTTP APIs to get started and do, for example, face recognition. That is one of our most famous boxes. So you can add face recognition to your stack in just minutes. So that's basic tools, Docker a little nodeless to do HTTP APIs as a programmer that probably every programmer should learn that the skill nowadays. And that's basically it. You don't need any other knowledge.

So just to clarify, I mean, really, like if I was a data scientist or a developer or whatever, I am, you know, there's a lot of APIs out there, both, you know, from the cloud platforms, like with, you know, machine learning, but also other things like if I want to send an email or something, programmatically, there's, there's like a REST API for, for that which uses HTTP and, and, and JSON. And so you're saying kind of one of your goals is to really make the interface to doing something complicated, maybe like facial recognition or something. As easy as it is to send an email via one of those APIs. Is that kind of a good.

Yeah, that's exactly right. Yeah. So essentially the machine learning that's going on inside the boxes is very complicated. And sometimes we mix different kinds of technologies in different ways. And if we tried to explain how to do that, it would be very complex and I think the deployment would be difficult and even just managing the dependencies would be a bit of a nightmare. So we take on all that pain and provide APIs that tell different stories. So, for example, you mentioned facial recognition. Facebox is a Docker container. You download it, you run it, you then have HTTP access. And the operations you can do are things like, here's an image, tell me all the faces in that image and give me the coordinates of the faces. Not only that, if you recognize these people who the face belongs to, tell me who that person is as well. Then there's another API call to teach. And we support one shot teaching, which is also pretty rare still. It just means that with one image, Daniel, I could take an image of your face and teach facebox with one example image. And then if we took a big photograph at a conference and you were in it, facebox would be able to find you and identify you, you know, so you get that facial recognition capability and it's only a couple of API endpoints you have to learn. It's basically teach this face and here's an image. Who do you, who do you see in there? And then, yeah, it's all JSON because we wanted to just feel really familiar and just fit into what people already had. And HTTP and JSON APIs still dominate. They're the simplest to use, you can use them, they're nice because you can just use them in the browser. And when you run one of our boxes, we actually host inside the box a little private website which you access through localhost8080. And that website contains all the API documentation, but also lets you interact with the box without even writing code. Because it's very important on our mission to make first of all communicate what's possible in a very simple way and then make that easy to play with and get to use so that people can see the power of it. And then once they've sold on that, then it's just a question of making the integration easy and operations. And so we're really focusing on that whole flow end to end. In particular, we care about people without any kind of machine learning experience being able to use these powerful technologies.

So it sounds like Machinebox, you've taken the machine learning part and abstracted that and put it in a little black box for your end users. Who specifically are you targeting as your customer for this?

Well, we have already paying customers. And so I say already because although Daniel started playing with Machinebox way before we really launched anything. And one of the nice things about the fact, the way we approach our developer community is we give them the technology for free early and let them just play with it. And that process, what happens is first of all, any bugs are immediately found and squashed. Luckily, it doesn't happen very often. We do a lot of testing and test driven development and other techniques which help us when it comes to, to kind of code quality. But beyond that we get to validate the way we've told a story and also if the APIs really make sense for the particular way in which their system expects to use a technology like this. So we see customers, all kinds, we really only it's a developer tool, so this is for developers to integrate into their platform. So by and large all of our audience are developers, but the people that really kind of have so far found it to be useful are people who, they understand machine learning in broad terms, some of them, but they know that it's a lot of effort to go to, to build your own things yourself and then, you know, if you care about the data not leaving your own network, whether that's on Prem or your own cloud, because we're just docker containers, you can spin them up anywhere and scale them anywhere. It's, you know, you keep control of all that data. So it's people who, they understand, they have already a need, which is great. They've got a problem that they want to use machine learning to solve and then they use our APIs to solve that problem. So they're basically developers of all levels usually. I mean some, some of them are just JavaScript developers, some of them are Ruby. We do have a GO sd, so we have a lot of gophers, we have a lot of Go people that are using it. So it's really that, that's who we target, is basically anyone's a potential target. But specifically we've seen traction in developers who don't want to have to do all the heavy lifting of machine learning and just want to get something and get going.

My favorite users, it's kind of a personal opinion. It doesn't necessarily mean that is right. So my favorite users are DevOps people doing DevOps basically because they basically love it because they usually don't have time or willing to learn any kind of data science. They want to solve specific problems and they find matchingbox and our APIs really good and really productive for that. So we get lot of love from DevOps. The best comments that we hear is from people doing DevOps like, oh, I have this problem, I want to solve it quickly, I want to deploy it quickly and it's just the perfect tool for that kind of people. Yeah, pretty much.

Yeah. That's great. I know personally I can attest to just the quality of the models. I know I actually kind of got into a little bit of trouble at a, at a conference because I was showing Facebox and the kind of one shot updating of the, of the model and, and people didn't believe me that it actually worked. Worked that well. So yeah, so that made for.

Yeah, that's happened to us as well. I think in a demo we've had it where people just think we've spoofed it. Yeah, I know it's surprising because you know, we're told again and again for machine learning to be any good, you need massive amounts of training data. So that's why. And really the solution, I mean it's kind of a bit secret of what we do, but it's just a clever use of technology inside the box which allows us to provide that. But the thing is, we don't want people to have to worry about how it works. We just want them to know that it works and integrate it and get to MVP really quickly. That's really another one of our goals.

A few weeks ago I was in San Jose at Nvidia's annual GPU Technology conference. And through my employer I was in a small group meeting with the Nvidia CEO Jensen Huang. And he noted something that I see you guys kind of going toward and that we're really at a junction where software developers are becoming the targets of machine learning rather than just data scientists. And it will continue to be both. But he noted that that was a big strategic initiative on them, was to target the software development community, which is somewhat new to these technologies. And it seems you guys have really centered your strategy around that approach.

Yes, I mean, that's right. I mean really what happened, if I'm being completely honest, is we just built something that we needed to use. We wanted to use some of these technologies and it's hard and we had constraints and you know, some of them at scale, some of the prices of the machine learning APIs at scale, really it really becomes prohibitive. I mean it's just, it's still quite expensive and still it's quite valuable, I guess. So that's why. But we weren't really kind of too strategic about it in the beginning. We just thought let's build it how we think it should be built and how we would want to use it. And from there we've then started to see traction and some great feedback on our developer experience.

Yeah, definitely. And I kind of want to follow up a little bit on that idea that we mentioned around the conference talks is you use this machine box to do something and it's doing something complicated under the hood and it giving you great, you know, great results. But to some degree, you know, even though you might know generally what's happening in, in the box, it still is a black box. And there's kind of a lot of back and forth in industry right now, at least in the circles that I kind of frequent around, you know, is treating machine learning and AI models as kind of a black box, a good thing or a bad thing and you know, AI, you know, like I can, I can download pre trained models and that sort of thing that I don't really. Right from the TensorFlow repo and other things and often really they're you know, I don't get the kind of results that are, that are, you know, either published results or the kind of quality that's promised from these pre trained models. Now the models that you're putting out are definitely, I get really good quality but I still don't really know all of what's going on on the inside. So in this case like we're treating machine learning and AI models kind of like a black box. Why do you think at least in certain cases treating models like this like a black box can be a really good thing or maybe what are some downsides or cases in which maybe you wouldn't want to treat them like that?

Yeah, sure. So yeah, all the machine box models are kind of a black box. So in that case we don't have any explainability for any the models. But also most of the models are based in neural networks. So nobody has that answer yet in the research. There are some BIM research about it but nobody knows what is happening inside.

So you just mean in terms of the complexity of the models.

Yeah, but also for use cases. So I mean for example if you gonna deny or accept a credit or an insurance, it's quite important to understand what a model is predicting saying oh if my income is less than this quantity, the model is going to say oh you're not going to get the insurance or you're not going to get the credit. But for example facial recognition, you care less about why the model is predicting that this is matching a face rather than not matching this other identity. So you are more worried about the value that you can extract for that matching rather than the value that you can get explaining why the model is doing. So. It's quite a balance and it really depends the use cases mostly our use cases doesn't really matter the explainability in most of the boxes we have for example classification box that allows you to build any kind of classifier given text or images or it may matter most for that kind of model. But in general sense we more focus on getting value for the models rather to explain what the model do.

Yeah, that's, that's a great point. And I mean to, to your guys point I think you know, if, if you're not able to put your model into production and get any value out of it via a useful interface then you know, really what we're talking about is just you know, AI research that isn't really applicable in a, in a business setting. So you have to be able to get things into production. I think that's, that's where this sort of black box treatment in my opinion is a really good thing in terms of providing a unified interface for developers and DevOps people and infrastructure people to interact with a model.

Yeah. But anyway, it should be. I believe that the research is going to come through someday. We can explain how a neural network do the reasoning and wipe a prediction is that prediction. So we probably try to keep up with the research and if that comes through, it's a possibility to add it to the boxes.

Yeah, but those kinds of. Those sorts of things and a lot of the arguments against black boxing are for. It's really, I think people who are deep in machine learning, they know about it, they want to. They want to invest time and resources into kind of building expertise and things like that. Lots of people aren't in a position where they can do that. So we give them a capability. It's a solution. They are models inside. Sometimes there are multiple ones inside each box, but there's also other things going on in there. So really is a solution that. You know, the only reason really that Machinebox isn't just completely an open source project is that it's just so complicated that it wouldn't be. I don't think, you know, it's not like it's just kind of a trivial little, little package that would be sensible to open source and everyone can get use out of. To use to be able to contribute to the Machinebox code base I think would be more difficult. Difficult than other projects. And so that's one of the reservations I have against open sourcing is that. But yeah, so it's really an audience question. I think if people care deeply and know a lot about machine learning, then maybe they're going to want to pick up TensorFlow and tackle it themselves. If you're an app developer and you want to quickly, you know, make your. Make your software smarter, slotting Machine Box in is just the quickest way to do that.

Yeah. And I think it's not inconsistent with other trends we're seeing like TensorFlow estimators and that sort of thing. Right. Which is intending to kind of give these modules to people that will let them practically integrate things.

Yeah, exactly. Yeah. It's kind of overlapping. They are catching up with Machine Box.

And that was a great transition. When you were talking about the tooling and under the hood, I assume you're talking about TensorFlow there. What other tooling are you using? Where are you using Go if any. Love to know how you guys are putting the pieces together.

Yeah. So the basic Stack is in Go, so we basically probably more than 80% of the code is go, because more than 80% of the go is just APIs, network calls and these kind of things. And the machine learning models, the training is done in Python and our favorite frameworks are Keras and TensorFlow. That's mostly what we use for deep learning. We use other ones, like more traditional machine learning things like Ballpump. Bobbit is a really old C library that I quite like, but basically that's it. This is not so much machine learning code. We serve all the models in GO and train all the models in Python and even scripts.

And just out of curiosity and maybe for the audience, why go for 80% of the stack? What is it about go? Because so many people in the AI space are doing Python, they're doing C, they're doing. You don't hear GO as often. So I'd love to know why that. For your selection.

Yeah. So GO has a deliberately limited language feature set. I once was speaking to a group and I said, you can't do that many things with Go. And it got a laugh because I realized how it sounds. But what I meant was the actual language itself doesn't have that many features, which forces the code to therefore be simpler. You know, in some of the more modern languages with oo, you have big type inheritance, you've got all these language features that allow you to build really quite complicated, very clever and complicated things. The GO philosophy is around simplicity, which mirrors exactly what we're doing at Machinebox. So it fits brilliantly. Essentially all of our code is GO code all kind of looks the same, so it's all familiar and you get such kind of benefits at development time, but actually more as you maintain the project. So that's why GO wins, I think, from our point of view. Plus we're fanboys of go. There's no denying that. We met at a GO conference pretty much.

But also some people are really surprised when they ask and they may heard about matching box in a blog post or, or at a conference, they contact us and say, oh yeah, I like your product. Just out of curiosity, how many people are you? Well, it's just Matame development, we have some business side with Aaron, but it's just pretty much three people company right now. And the people get quite surprised like, oh, you did so much, you have so many boxes, so many products in like two people developing and one business development.

Yeah. And the answer isn't that we're awesome, although David is. The answer is that we are Very selective about what we do. So we deliberately don't do as much as you could do. There's loads of possible things we could push into facebox, for example, and some of them tell you where the eyebrows are. I haven't yet seen a good use case for why you need to know in an image where, where the eyebrows are, but maybe there is one. But until that, you know, until then we're not going to, we're not going to invest all that time and effort and also, you know, add that kind of complexity to the API. So yeah, it's because we pick, we're very selective about what we do. We pick the things that we think are just the gold from all this potential kind of complexity and we just sort of focus around telling that story and solving that problem. So that's how we're able to do so much. It seems, I think Go.

It's the perfect tool for our philosophy. It fits really well into that mantra, into that mindset. So it's the perfect tool for us.

I think both of you guys are awesome. Just to set the record straight.

Thank you. I was fishing for that. That's why I said it. Yeah, I'm glad you picked up on it.

I figured you were. And not only that, but you've given me my next blog post idea which is around eyebrow. Eyebrow based analysis.

Very important stuff.

Yeah.

You can, you can detect sarcasm with it. That's the only use, I think. Yeah.

With you. Or maybe anger Matt, with you.

If you had that sarcasm detector, wouldn't it be pegged most of the time?

Yeah, it would. You can basically just return true.

Okay.

Yeah, that will be 99.9 accuracy.

There was one time where I said something serious and wasn't being sarcastic, but I forget what it was now.

So you've talked a lot about kind of your technology stack, why you've chosen Go. One thing I'm curious about, I mean, so I think everybody should use Machine Box in one way or another, but there's a lot of people out there, maybe that are working on data science teams or data engineering teams or whatever it is, and are maybe using TensorFlow to develop and train models that are getting deployed internally into their own sorts of services and products. I'm curious, kind of because you consistently produce such high value models that are integrated into your products. Do you have any advice around kind of that progression from training your model to kind of getting it deployed. Deployed within some type of service? Whether that be kind of. You mentioned testing. Testing might look differently for machine learning models. Or AI models than in other cases. But do you have any kind of advice and insights around that process from training your model to actually integrating it into a service? Whether that's integrating Machine Box into your service or maybe that's integrating your own model into your own internal service?

Yeah, so I don't really know. So most of the problems are just technology that usually technology, you just get it solved one way or another. So there are a lot of tools coming up these days that solve that problem well, including Machine Box. But also in TensorFlow, the deployment is getting better. So. But I think most important is people. So how this machine learning thing is transforming the way that people c software, especially talking with customers. Now we have. Well, you know, in machine learning we have a lot of false positive, false negatives. Once you have something in production, they come up with with questions. Sometimes the most, the. The question that most of the customers are. So we have this problem. Well, that's not actually a problem, it's just a false positive. And there are ways to deal with false positives and false negatives and changing the mindset to accept that a thing is not a bug is a false positive. In a machine learning model, it changed the way that you interact with people. It's like, oh, you're not gonna have a machine learning that is 100% accurate. So you have to deal with these situations. And that situation is just the ways that we are mostly struggling or just trying to get the right conversations with people. And I think that is going to come up in any software development in the next couple of years.

Yeah, our job, one of our big challenges is communicating what's actually going on. Like, you know, we thought we're just going to deliver face recognition APIs. That's it. Or image recognition, image class or personalization APIs. And we found that quite quickly. We did actually have to get into the conversation a bit more about, look, this, we don't expect this to get everything right 100% of the time. We expect it to do a much better job automatically than you're doing. Hopefully you can get it to the point where the exceptions that you have to deal with, if there are any in the workflow get smaller and smaller. But yeah, that's definitely been something we've had to focus on, is communicating that this is a kind of unlike other software where you do something and you get a result you don't like, that's a bug. And we've had some bugs opened where it says, I put this image in and it didn't find the face, you know, and of course the image, the face is like turned to the side or it's got a weird shadow on it or just something is weird about it. And then we kind of get into that conversation. It's. Well, it isn't really a bug. I mean, you know, it's kind of part of the expected workflow. The question is how do we then tackle that going forward? From a data scientist's point of view, someone did actually ask if they could put their models into our boxes because they knew the, the building the models bit. They were good at that, but they had no idea about getting things into production and running them at scale. One of the things, one of the very early kind of rules that we gave ourselves and this comes, this is kind of common sense now I think a little bit, but comes from David's experience building at massive scale for the Olympics in particular was that we, you know, we, we had to be able to horizontally scale the boxes just by adding more of them, you know, because scale is, you know, it's fine if you get this awesome technology and it works nice and slow on one machine, but to really get the value from it, in most cases you want to run this thing at scale so that it can really, you know, get through work that it needs to get through. And so we did, we spent a lot of time also, which you don't really see apart from the fact that it just works, but we spent a lot of time in making sure that this, these boxes could horizontally scale in a kind of kubernetes environment where it would just elastic up and down as you needed. And of course you have to think about what's the state inside the box, how does that work? And various other sort of, you know, will, will just load balancing across the boxes be enough in a, you know, to, to, to get what you want or is there more that we need to do and where does that happen and all those kinds of things. So yeah, it's been a great, it's been a great sort of experience building it and it's even, it's more fun when people start integrating it and paying for it. That's, that's when you really feel like you've created something valuable.

Yeah, that's, that's great. And I can definitely resonate with, with some of the things you said around kind of exceptions in models and that sort of thing. I think people too often, in my personal opinion, you know, think about an end to end machine learning or AI model that does everything all the time correctly and I think that's, you know, to some degree the wrong thought in a lot of cases because, you know, when machine learning models fail, it's the same, you know, we, we have an opportunity to refactor them, right, which is, is in the end a good thing, right? So just to kind of, you know, getting, getting close to the end here, I was wondering, you know, again, what, what you guys are doing is kind of setting some, some standards as far as interacting with machine learning models. And so I'd love to get more advice from you guys in terms of the skills that data engineers or just kind of developers who don't really consider themselves data scientists or AI researchers, what sort of skills would you kind of recommend them looking into or what kind of skills do they need to begin to start integrating machine learning into their applications?

I think that, I don't think you need that many. Depends how deep you want to go into it. The trajectory that I would recommend to somebody who didn't have any kind of idea about it would be to start by consuming APIs. And, and because if, if those, if, if that's good enough, if that works for your case, then you don't have to do anything more. And that's what we found so far. A lot of our customers have said, you know, we're just gonna, we're just gonna kind of try this because then we can build MVP quickly and then later we might change it and then that later never happens because the, you know, the boxes are doing just such a good job that they don't need to then change it. So definitely like any kind of API skill around consuming APIs, you know, most people already have those already. And then I think beyond that, it's really just a question of I think understanding a little bit more about just the kind of high level concepts I would say would be useful. Like, you know, with classification box, with classification box you can create your own classifier. With training, a training set. Now with classification box you do need a good amount of examples for each class. So you know, if you, when some people start using it, they have just a couple of images, a couple of examples, and you can't really get a model that's useful from, from that. So learning things like the sort of softer skills around machine learning, I guess, which is, you know, the kinds of data, the kinds of problems that machine learning is good at. First of all, then what kind of training data are you going to have? Because machine learning is only as bad as its training data. So I think those sorts of things would be Useful for everyone to have. And then if you're getting into more machine learning, technical stuff, then I don't know.

Yeah, so in my opinion, you should focus in one type of problem. So the machine learning is quite broad. So if you want to get started, there are many different subfields. So probably just focus in a problem that you have or you want to solve, like, I don't know, sentiment analysis or classifying text or something more or less straightforward or in machine learning, work more or less easy and learning by doing it instead of focusing in maths or things like that, you can get easily loose in that sense. So try to learn it by doing. Solve a problem that you have and see how it goes. Once you have that working, you have that boost of energy, just, oh, I have something that is more or less working. Maybe it's not the state of the art, it's not very accurate, but it's better than random. So the machine is actually learning. And that is a good feeling. I'm probably just. That is good to get started and get more curiosity and learn more things.

That sounds great. So let me ask one last question for you. As we wind up. So many of the listeners that we have are trying to figure out how to get into machine learning themselves. And they might be software developers, they might be business people who are intrigued by what's possible here. And so as two entrepreneurs who have gone down this road and you have created a business based on making AI technologies available and recognizing there's so many people that may want to either supplement their own business that they have or create a new business, what advice do you have for other entrepreneurs that might be interested in taking the same adventure that you guys are now a couple of years down? What would you say to them?

Yeah, I would always say solve a specific problem, make sure you're solving a real problem. This goes for any kind of software, actually. But it's too especially machine learning because it's all cool and sexy and hard. Like machine learning is hard. So anyone that, like David said, if you make some ground, you really get really kind of big rewards for doing that. Like just emotional rewards you get. So, yeah, it's kind of difficult to make sure that you're building something that has some true value, you know, because if you're just building cool tech, then there's no guarantee that's ever going to be anything. And often, often you can build, you end up building something that technically is brilliant but actually doesn't quite fit the problem. And then you have to basically move or change what you're doing so that it does solve a real problem. And that can be quite a painful transition, usually involves adding loads of complexity because it didn't quite. You weren't really thinking about those things from the beginning. So of course you want to be able to evolve and learn and move, you know, a project along. But I would say start with a real problem that you understand. And the problem shouldn't be anything to do with machine learning, but machine learning might be part of the solution.

Great. Yeah, that's, that's wonderful advice. And we'll include links, of course, to Machinebox and other things that we've talked about. You know, TensorFlow and Keras and Docker and Kubernetes. If you're not familiar with those technologies. We'll include some good links to getting started with those and learning more. And just want to thank David and Matt one more time for joining us. It's been great to have you here and really excited about what's going on with Machinebox.

Thank you very much. Yeah, and good luck with the podcast. I think it's awesome. I can't wait for future episodes. I'm sorry to everyone who had to listen to our voices for this episode, but future ones I'm sure will be even more interesting.

Yeah. Thank you very much.

Hey, thank you.

Thank you. Appreciate it very much.

All right, thank you for tuning into this episode of Practically I. If you enjoyed this show, do us a favor. Go on itunes, give us a rating. Go in your podcast app and favorite it. If you are on Twitter or social network, share a link the with all with a friend, whatever you gotta do. Share the show with a friend if you enjoyed it. And bandwidth for changelog is provided by Fastly. Learn more@fastly.com and we catch our errors before our users do here at Changelog because of rollbar. Check them out@robot.com changelog and we're hosted on Linode Cloud Servers. Head to lino.com changelog check them out. Support this show this episode is hosted by Daniel White Knack and Chris Benson. Editing is done by Tim Smith. The music is by Breakmaster Cylinder. And you can find more shows just like this@changelog.com when you go there, pop in your email address. Get our weekly email keeping you up to date with the news and podcasts for developers in your inbox every single week. Thanks for tuning in. We'll see you next week.