DAN_SHAPPIR: Hello everybody and welcome to another episode of JavaScript Jabber. Today I'm flying solo being the only panelist and interviewer and we're interviewing a very interesting person. That's Ashley Davis. Welcome to the show, Ashley. 

ASHLEY_DAVIS: Oh, thanks Dan. It's a, it's really exciting to be here. First time on a podcast. So feeling slightly nervous, but keen to get into it.

DAN_SHAPPIR: Well, I can appreciate. I think I told you this time is my first time interviewing on my own, so we can both be nervous together. And Ashley, I believe that you're coming to us from Brisbane, Australia? 

ASHLEY_DAVIS: Yep, that's right. What we call the Sunshine State in Australia. 

DAN_SHAPPIR: It's right on the East Coast, correct? More or less in the middle. 

ASHLEY_DAVIS: Yeah, a little bit above the middle on the East Coast. 

DAN_SHAPPIR: I think I told you before we started that I was thinking, hey, that's probably pretty close to Sydney, Australia, but it turns out that it's actually Australia distances close is a relative term. I think it's what like a 10 hour drive something like that? 

ASHLEY_DAVIS: Something like that. It's like nowhere in Australia is close to anywhere else basically, except if you're in the southeastern corner, you're about five or six hours drive from anywhere there, down there. But if you're anywhere else in Australia, in Brisbane, in Adelaide, Darwin or Perth, you've got basically a half a continent or a continent to cover to get anywhere. 

DAN_SHAPPIR: That's kind of like the inverse of the situation of where I am. I'm located in Israel and here everything is packed up or close together. So yeah, the drive from Tel Aviv to Jerusalem for example, it's just one hour and those are the two major cities in Israel. 

ASHLEY_DAVIS: I did live in the UK for about eight years so I know what it's like to kind of have big cities within a train ride so it's a very different environment to live in. 

DAN_SHAPPIR: Yeah I'm sure. By the way, how is the COVID situation over there? 

ASHLEY_DAVIS: It's good in Queensland. In Brisbane we've got very few cases. We've had our borders locked down for quite a while, quite a few months, so we've had very limited travel between states and incoming from other countries. So it's been kept under control pretty well. We've had a bit of a hot spot down south in Victoria, where they've had an extended lockdown for many months to try and get this under control. But I think we're very lucky in Australia, given that we've got hard borders around the country in terms of, you know, we're surrounded by an ocean and that we've got quite a small population compared to many other countries, we've managed to keep it under control a lot better than a lot of other places. So my heart goes out to everyone, everyone who's suffering. It's a really difficult situation to be in. 

DAN_SHAPPIR: Yeah, for sure. Good to hear that things are not so bad and even are improving over where you are. And by the way, I think you're also heading into springtime, correct, in terms of the seasons? 

ASHLEY_DAVIS: Yeah, we don't really have that distinct seasons in Australia. I mean, especially up the north end of Australia. So it's just in winter it's a little bit cool and in summer it's very hot. But the days are heating up now, but it'll be at its hottest here over Christmas and going to January. 

DAN_SHAPPIR: That's probably also better in terms of COVID, you know, less flus and stuff like that. 

ASHLEY_DAVIS: And the, I think you call it the La Nina effect is back again after a few years. And that brings with it a lot of wet weather, a lot of storms. And we've really just experienced it the last couple of weeks. We've had about three big storms, lots of hail, lots of lightning, not in my area but in a lot of areas around here, there's been damage to houses and cars. 

DAN_SHAPPIR: Oh my, I think I actually saw a picture of like hail balls that were fist size or something like that. 

ASHLEY_DAVIS: Yeah right. 

DAN_SHAPPIR: Wow. 

ASHLEY_DAVIS: Yeah that was just just on the south side of Brisbane in the last couple of days I think.

DAN_SHAPPIR: Oh, that's scary. Well, anyway, enough about the weather. Let's talk about technology and programming and stuff. JavaScript Java after all. 

 

When I went freelance, I was still only a few years into my development career. My first contract was paid 60 bucks an hour. Due to feedback from my friends, I raised it to 120 bucks an hour on the next contract. And due to the podcast I was involved in and the screencasts I had made in the past, I started getting calls from people I'd never even heard of who wanted me to do development work for them because I had done that kind of work or talked about or demonstrated that kind of work in the videos and podcasts that I was making. Within a year, I was able to more than double my freelancing rates and I had more work than I could handle. If you're thinking about freelancing or have a profitable but not busy or fulfilling freelance practice, let me show you how to do it in my DevHeroes Accelerator. DevHeroes aren't just people who devs admire, they're also people who deliver for clients trust them. Let me help you double your income and fill your slowdowns. You can learn more at devheroesaccelerator.com. 

 

DAN_SHAPPIR: So we were kind of talking about this before and you said that you've had an interesting journey into tech and into JavaScript. Can you tell us about it? 

ASHLEY_DAVIS: Yeah, I've got a long history. It's been over 20 years. So my first professional programming job was in 1997. And I had a few years before that of study and being a hobbyist coder sort of got me warmed up for it. Um, most of that time has been nowhere near web development or JavaScript. That's, that's a fairly recent thing. I sort of probably about 10 years ago, I really started the process of sidestepping into, into working with JavaScript from what I was doing. And only in the last two years have I really been able to kind of cut loose every other language I was sort of framework I was working with and really go full on JavaScript and more so TypeScript now, but believe it or not, I started my career. I more or less started my career working in game development. So I had 10 years working in game development before I had a bit of a stint in the financial industry. And then I came back to game development contracting for about a year. At that point, I went into serious games. So this is about getting up to about 10 years ago now when I came back from overseas to Australia and I started working at a company doing simulations, training products, virtual reality. So I'd sort of gone from C++ and a little bit of C-Sharp and a little bit of Python to at this point, mostly working in C-Sharp using the Unity game engine. But this is where I kind of started to step in, sidestep I would say, into web development. I was leading a team at this company and the whole team was C-Sharp programmers working with Unity, you know, we're 3D graphics guys. So it was a pretty different situation for me to kind of move into, but we had a need. And, you know, the need was to build UI for the company that was web-based. So that involved getting into JavaScript. And for some reason, JavaScript just really worked for me. I think programming languages can be very personal. And I think to really take something on board and go deep with it, you need to develop like, or pick a language basically that speaks to you on a personal level. And I don't know why, that was JavaScript after so long, you know, working with a bunch of other languages. 

DAN_SHAPPIR: I think that, you know, listening to what you're talking about, I'm kind of, you know, amusing for me because I see a lot of parallels between your career and my own. 

ASHLEY_DAVIS: Oh yeah? 

DAN_SHAPPIR: Yeah, like you, I'm an old timer. I'm an even older timer than you are. Yeah, my first job professional gig I think was around 94. I had some jobs before that, but they were more occasional, there was also my military service in Israel. But I also, like you, I actually started in game development, so my first professional job was also in game development. But it was long ago, it was before Unity. And by the way, when you're talking about Unity, Unity 3D engine that's like a world rendering engine that's used in a lot of games and game related applications just to, you know, in case some of our listeners may not be familiar with it. And like you, I started with C++ and C and languages like that and only found my way into JavaScript a bit later, though again earlier than you did. But I totally what you're saying about the particular programming language clicking with you really resonates with me. I think that as developers, the tools, we are fortunate to have a wide variety of tools that we can choose from and career paths that we can go down. 

ASHLEY_DAVIS: I think the tools and the ecosystem has been really important because, I mean, it was really stagnant in the games industry. I started working with Unity in about 2012. Before that, any game job I worked for, any job in the games industry, we'd basically build our own game engine. Until I started working with Unity, I hadn't really gotten hands-on with a game engine that someone else had built. But as I moved into JavaScript, I just found that there was this huge community. I mean, the games industry has been sort of very insular, like they don't share a lot of like open source work, at least, you know, in my experience, that's what I thought. But when I got into the JavaScript community, there's all these open source projects everywhere, the whole community is contributing to it. And it was just amazing how much, you know, it's a little bit overwhelming, I guess, when you first start learning JavaScript, just the sheer amount of, you know, tools and frameworks and APIs and all this stuff that you've got to, you think you've got to get your head around, you don't really. I mean, that's my advice to new devs is you don't really. There's a lot of stuff that you just don't need to know. But I love that. I love having that choice, trying a few different frameworks, picking one that appeals to you personally. That's just one of the things that really got me into JavaScript. 

DAN_SHAPPIR: Again, I totally agree. I think that one of the things that has really driven the success of the web and development around that platform has been the fact that the web was essentially an open source platform from the get-go and by design. When you know you can minify and bundle and package and agglify your JavaScript and even the HTML and CSS. But at the end of the day, you're delivering source code down to the endpoint devices. The browser downloads at the end of the day, it's HTML, CSS, and JavaScript. And even when it's minified, it's still, you know, readable if you really put your mind to it and a lot of people just you know take that into Just assume that a lot if you'll talk to a lot of the older timers in the web community they'll tell you that they learn most of the stuff that they originally knew just by doing a view source and and looking at the raw HTML and CSS and JavaScript and even though I think that's less the case today certainly if you're building a large web application using react or angular or whatever, it's, it's a lot more difficult to just browse the source code. But I think that the open source mentality is kind of permeated the, this, uh, particular segment of the software industry and exists here to this day. And that's one of the reasons I think that we're seeing so many open-source projects being used in so much sharing of code, which like you, I find to be very exciting and a very positive thing. So you said that the JavaScript kind of clicked for you when you got into it. Can you elaborate why you think that is? 

ASHLEY_DAVIS: Yeah, well, we were using it firstly because the Unity game didn't have a good way to make UIs, but there was this product. I can't remember the name off the top of my head, but it allowed you to integrate a web UI into Unity to be rendered on top of it. So we were like, you know, great, you can do pretty much anything with HTML and CSS. We can make this look amazing. We had an artist on board who had learned a bit of CSS and HTML at his college or university. And he really got stuck into it and started making some beautiful UIs. So we really went full on for this approach for a couple of years there at least before Unity came up with a better way of, you know, making UIs in C-sharp. But I think, you know, by the end of that process, you know, myself at least, you know, like I was pretty hooked on JavaScript. Cause at that stage we'd started using it for our backend, but no JS. We started running servers on Azure to support customers of the company. We were making proper web pages that were like telemetry dashboards to show, you know, information and analytics about what was happening in some of our simulations and our, our, our training courses that we had running. And then even to the point where like, I was using Ionic to build some really, really quite simple mobile applications that were kind of like, you know, tests or quizzes or, or surveys that people would do after doing their training. And of course, it wasn't just me doing this. I had a team around me at the time as well. And also I was, I was very motivated. And this is the whole kind of power I get into the data wrangling with JavaScript. I was looking to trade the stock market. And up until that point, I'd been using Python and pandas to do some data analysis, Jupyter Notebook, of course. But because I'd been getting into JavaScript and my ambition was to basically, to build a trading bot and to host it in the cloud somewhere and just have it be automatic and do its thing. And I wanted to do that with Node.js. Like I've tried a few different ways of making servers, a few different languages for making servers in the past. And Node.js is what, like I said, what clicked for me. Um, so I went on this long, quite a long road then of actually learning how to do stuff with data and building my own tool set as well to work with data in JavaScript. Now, working with data had been something that I had done, like going back to the beginning of my career. Of course, when you're working on a game, as you would know, it's very data-driven. A game is just probably a very small amount of code compared to the amount of data you've got, like 3D assets, you've got your textures, you've got your level data, you've got data for all the entities, you've got data about what the player's doing, what they've done. It's just, so working with data and doing things like working on performance of the game, looking for memory lags, that all involved collecting and analyzing data. So, for me, I didn't really feel like I needed Python to do that, which is the go-to language normally for working with data. But I'd always done this in C++, C sharp. Eventually, I started doing it in Python, whatever I had to hand. But once I got hooked by JavaScript, I really wanted to work with data in JavaScript. And once I figured out how to do that. That's when I had this kind of burning desire to kind of tell the world, or tell all the JavaScript programmers at least, how you can do this. You don't necessarily need Python. There's so much you can do already in JavaScript. 

DAN_SHAPPIR: So I gather you that, like you said, you got so excited about it and you discovered that it worked so well for you, and then you ultimately wrote a book about it, I think. 

ASHLEY_DAVIS: Yeah, that's right. 

DAN_SHAPPIR: The title of the book is Data Wrangler with with JavaScript. We'll post a link to it. It's published by Manning. Well then, what can you say about data wrangling with JavaScript? 

ASHLEY_DAVIS: The book is a comprehensive guide on all different aspects of working with data. How do you work with large data sets? How do you work with databases from JavaScript? There's a couple of chapters on visualization, including a simple one using C3, a more advanced one using D3, working with live data pipelines in JavaScript, doing server-side visualization for rendering charts in the server, rendering reports in the server, that kind of thing. This is all stuff that just came from my experience, literally, of the work I was doing all throughout my career, really that I then had to figure out how to do in JavaScript. Working with large, huge data files. There's a chapter on data analysis and statistics, exploratory coding to explore your data and figure out what you've got. Working with unusual data formats. There's a fair bit in this book. I think I added, as I was writing the book, I came up with an extra two chapters. And there was more, I had like ideas for about four more chapters, but I kind of had to stop somewhere. In a way Manning changed the course of my career because as I was leaving my last full-time job in 2017, and I'd been talking to Manning, I'd been doing some technical reviews for Manning and that's how I kind of met them. And I had two pitches I was going to give them. One was how to build complex applications and serious games in Unity. And the other one was data wrangling with JavaScript. And I gave them a pitch for both books and they accepted data wrangling with JavaScript. So that really kind of set my course for the next couple of years, writing that book and continuing to learn as well, continuing to learn about JavaScript. At that point, I'd never worked in JavaScript full-time. It was something I did, as well as coding C-sharp and Unity in that job. But at that point there, I was transitioning basically to a whole new world. So at that point there that was my last full-time job. From 2017 onwards, I've basically been an entrepreneur and author and I still do contracting to keep the cash flow and doing a fair bit of open-source coding as well along the way. 

DAN_SHAPPIR: Good for you. So before we dive into the whole topic of data processing and data management and data storage. I actually do want to ask you another question about your journey into JavaScript. You came into JavaScript as you told us as an already experienced developer with experience in several other programming languages. But my own experience is that despite some, let's call it syntactical similarities, the often different and sometimes surprisingly different from a lot of these other programming languages. Like it's very tempting to assume that JavaScript is like Java where, you know, they have a similarity in the name. But ultimately they're very, very different and they should be used in different ways. 

ASHLEY_DAVIS: I did not really understand the features of JavaScript for quite some time, I would say. I kind of knew them. Like because I had worked with Lua, have you heard of Lua? 

DAN_SHAPPIR: Yes, I did. 

ASHLEY_DAVIS: I had worked with Lua and that's in a lot of ways, that's very similar to JavaScript.

DAN_SHAPPIR: It also has a knowledgeable avlua. Can't say that I've ever actually made any significant use of it. Certainly not any time recently. Does it also have this sort of a dynamic object structure like JavaScript? 

ASHLEY_DAVIS: Yeah, so, yeah, dynamic objects. I'm just trying to think from memory. It's got first-class functions, very similar to JavaScript. It's got closures, even though I think back when I was programming Lua, I didn't know what closures were. I've only really sort of understood closures since I started working with JavaScript, but Lua definitely has those as well. I think it's got prototype inheritance or like some equivalent of that. I know there's no such thing as classes in Lua. So you basically, you build your classes out of prototype objects, similar to what you do in JavaScript. So I don't know if there's, you know, the guys that originally made Lua, whether they had some experience of JavaScript or there was some crossover. Of course, Lua is an incredibly successful language in the games industry, probably not so much now that Unity is as big as it is, but before Unity, Lua was like a big language to use for scripting gameplay logic in games and scripting user interface logic, that kind of thing. And it's you can actually read the code for Lua. It's got a really compact, elegant C language code base. If you're interested in kind of understanding how a language like that works, it's a really good place to start looking. 

DAN_SHAPPIR: Cool. And you mentioned that you discovered closures when you started working with JavaScript. Just last week. 

ASHLEY_DAVIS: I would say I fully understood what closures were and were able to put a name to them when I was working in JavaScript. But even though Lua had that concept and I kind of recognized that concept in Lua, at the time I didn't really go deep enough on Lua to fully appreciate what that was. And also, with JavaScript, there's a million of my blogs telling you what closures are. And with Lua, you don't get that. Lua's community was not that big. So you don't get those kind of educational resources alongside Lua.

DAN_SHAPPIR: By the way, just to say that that closures are one of my favorite programming language features. Any language that doesn't have closures these days feels kind of stunted to me. 

ASHLEY_DAVIS: I feel the same way. I don't know how I could I mean, C Sharp was my previous favorite language before JavaScript. And JavaScript probably won't be my favorite language forever. But I mean, I can't imagine going back to a language that doesn't support closures. The other part of JavaScript that it's really hard for other people to get, and I didn't so much have a problem with it, is the asynchronous side of things, which you don't really get in other languages except they've bolted this thing onto C sharp, so it's asynchronous now. I think they might have done the same for Python. I have no idea what C++ is that. Asynchronous programming as I had to do like a sort of a special coverage of that in my first book data wrangling with JavaScript after my publisher convinced me that it was a hard topic now I don't want to demean anyone. I you know, I I do think that Coding development and some of these sort of concepts are genuinely difficult to learn I've had a bunch of junior developers and interns work for me, you know, I've seen the trouble the thing about thing about coding for me is that, I mean, I don't, I don't tend to remember how hard it was to learn things. And I think it's just because I get really, really engrossed in it. Like I just, you know, I can, I can, I can be learning and I can, I can lose all track of time. And, you know, something, sometimes some things in my career probably have taken years to make sense. You know, years on the job before it actually becomes clear, you know, all the way through what, what, what a, what a feature or a, you know, certain part of the language means. But I don't even notice. It's just like when you get totally engrossed in something, you just don't notice that it's difficult to learn. 

DAN_SHAPPIR: Oh, I totally agree. I'm actually having an interesting, let's say, it's interesting times for me about this because my eldest son is actually just starting a CS degree and he wasn't really into computers and software before he started. He came into it kind of late. You know, software was my thing in the house and he had his things and now he's decided he is actually interested in software and in programming. So a lot of the concepts that I take for granted are totally new for him and it's really interesting to see how challenging it can be to adapt to the relevant thought processes you know, things that are trivial and obvious for me are not so for him. He was very much into math and physics, which you would think it does help, but it's still a very different thought process. So I totally agree with what you're saying. And even like you said yourself, even when transitioning between different programming languages and development environments. The concepts change. I think I told this story before in this part, in some episode of this podcast about a seasoned C++ developer who was also transitioning into JavaScript and web development. And he came up to me and said that he was trying to download some resource from the web, effectively making an Ajax call. And he was asking me how to block execution until that Ajax call completes. And yeah, because that's what you do in languages like C++ or maybe Java. You, you block that thread and you have additional threads to process other events that occur. And with JavaScript, you only have mostly that one thread and you handle this by coding or by processing things asynchronously. So it was definitely a mental challenge for this developer to transition from blocking multi-threaded environment over to an asynchronous primarily single-threaded environment, which is JavaScript. 

ASHLEY_DAVIS: I love the single-threaded nature of JavaScript. I do not miss threads at all. I've spent some of the horror years of my career trying to debug issues in threads in C++ code that can take weeks or months to really kind of nail the cause of what other thread is corrupting your memory. Like it's not obvious. It takes a lot of work really to kind of get through some of those issues with threads. And so I'm really happy that for one, that JavaScript is single-threaded. It's never held me back. I mean, I've built this complicated application, DataForge notebook that has multiple processes, including like hidden electron windows for doing background processing. It's a bit of rigmarole to get that setup, but you know, you don't have this worry about multi-threaded corruption ever. And what was the other thing? Yeah, so I built my own, I do algorithmic trading on the Australian stock market, and I built my own trading algorithmic trading system. It runs on my desktop PC that has 16 cores and it's an OJS program. Basically, when it starts up, it forks itself into as many processes as I want to run simultaneously. And so I can get a lot of data processing throughput in that system because of that. And I never have to worry about these multi-threaded issues that have been the pain of my life really before moving to JavaScript.

DAN_SHAPPIR: Just a question, is it kind of scary to implement your own algorithmic trading application? I mean, if you have a bug, you can lose a lot of money very quickly. No? 

ASHLEY_DAVIS: Yeah, there are checks and balances in place. So I mean, my main system, I don't have an API from the broker that I can use anyway. So for a while I was using doing like screen scraping and browser automation to get my trades in. But that that hit some problems that meant I couldn't do that anymore. So now what I do is I run my code on the weekend and it gives me a list of trades to place during the week. And so I can get into the market first thing morning, place those trades manually. And I used to use conditional orders to get in, which meant I could place trades on the weekend, but again, various problems with those, you know, through experience means I don't want to use them anymore. So I place my trades manually provided everything is looking okay on the Monday morning. And then I use automatic stop losses and profit targets to get out of the market. So it's, it's as hands off as it can be, but there's no, I mean, the problem with trading is you get, you get emotional about it and you, and you, you can be irrational about it. So I wanted to eliminate, completely eliminate that and work off a strategy that had been back tested and, you know, analytically shown that, you know, that there was a mathematical edge that, you know, if you just run it long enough, it's a, it's gonna, you know, it's going to give you slow, steady profits. This has been a bad year with COVID in the stock market, so don't ask me about this year. But besides that, over the last few years, it's gone really well. 

DAN_SHAPPIR: Well, you still have a shirt on your back, so I guess it's still OK. 

ASHLEY_DAVIS: Funnily enough, the shirt that I'm wearing on my back at the moment was sent to me by Manning. They sent me four shirts at the beginning of the year, so that's kept me going all year. 

DAN_SHAPPIR: Well, you know, they say I remember seeing this comic strip on that said where this guy is talking to a programmer and says that, I see by your shirt that you just came back from a conference. And he says, yes. This was a strip from before COVID. So he goes, I don't think you actually buy shirts, do you? You just go to conferences. And he says, well, I try to time my conferences so that I don't even have to do the washing. 

ASHLEY_DAVIS: Well, you can't do that this year, can you? 

DAN_SHAPPIR: Yeah, no, not this year. This year, it'd be fun. 

ASHLEY_DAVIS: I'll tell you what. I really miss the meetup community in Brisbane. I mean, we do some online meetups still, but it's just not the same. 

DAN_SHAPPIR: Oh, I definitely agree. I participated in something like two or three online conferences this year. I actually spoke at them, but it's definitely not the same. My favorite thing about conferences is the face-to-face, is the meeting up in the hallways and meeting new people and discussing stuff, and that's just not there with online Chrome. Well, you know, they tried, but it's not the same. And so I definitely agree with you. It's it's one of the things that I miss the most that and just traveling around, which I also enjoy. I sometimes think that Google Maps is trolling me whenever they send me that monthly update of this is where you were. And it's just this red dot on my house. And yeah. So anyway, you mentioned this application, this data processing application that you've written called DataForge. Can you elaborate on that? 

ASHLEY_DAVIS: Well, there's two things really, and they're kind of related, but also kind of not related. So I'll give you a link at the end, but the DataForge actually is my open-source library for doing, yeah, that's it, that's the one. That's for doing data wrangling in JavaScript. So it's kind of, from my early days, this is version two now, so it's a few years old, but the version one of this came from my real entry early days into JavaScript. So there's some things in there that aren't quite like they should be really following JavaScript conventions. But this was inspired by pandas, like my experience using pandas in Python and wanting to do those kinds of things in JavaScript, like working really fluidly with time series data and being able to do operations on it and stitching together different data sets and stuff like that. And it's also inspired by LinQ or language integrated query that was popular in the C-sharp world that I used to love when I was working with C sharp. And so I wanted to build something that was a bit like that in JavaScript. I'm still, I'm still very happy with it. There's a couple of things that like a couple of C sharp isms in there that I would probably change to be JavaScript isms now if I, if I didn't want to break things and then what the natural thing that came after that was that I, you know, I really, I really love the concept of Jupiter notebook, but I really wanted that for JavaScript and I did try their, their JavaScript add-on, I remember what it was called. But that was really painful to set up and it just didn't work very well. It didn't, it didn't fit very nicely. And it didn't have the same feel of, of working with, with Python in Jupyter notebook. And I had this dream for years to, to basically remake Jupyter notebook for JavaScript. And over the years I've done a couple of, a couple of prototypes. And then, and then I figured out how to use Electron and I did my last prototype that I did, it must be about two and a half years ago. Now that actually turned into the proper version of data forge notebook. And I use that also at the same time to further my business skills. So I went about it as if it was going to be my business, you know, rather than an open source project. And I got, I got, I spread the word and I've got people to sign up for the early version of it and stuff like that. So I knew that people were interested in it before I started putting major amounts of effort into it,

DAN_SHAPPIR:  but so, so I can interrupt you for a second, just to clarify. So DataForge notebook is it what exactly? Is it a library? Is it an application? How do you actually use it? What is it exactly? 

ASHLEY_DAVIS: So if anyone who's listening wants to have a look, they can go to dataforgednotebook.com and they can see a video there that shows an overview. But if you know what Jupyter Notebook is, it's basically Jupyter Notebook for JavaScript and TypeScript. So it's a live coding environment. You type a bit of code, you can get a visualization. You type a bit more code, you get another live visualization. So it's a very visual way of coding and prototyping and doing data analysis. So originally it was intended to be used with DataForge and that's why it was called DataForge Notebook. But pretty early on I realized that, you know, it was gonna be a separate useful thing, you know, just for any JavaScript coder. And so I basically, I changed it so that DataForge Notebook wasn't like embedded in it. And DataForge Notebook, it's like you're coding Node.js. So it's got an embedded portable Node.js under the hood that evaluates your code. And it's just got a lot of convenient stuff there, like, you know, you install it and it's ready to go. And then you, if you type, if you type in your NPM imports and automatically installs them for you, so you can just start using them. And it's just a very, very convenient way to try out ideas in JavaScript, you know, start off a new project, prototype code, or if you're having problems in an existing JavaScript application, you can easily transport or transplant some of the code over to data forage to debug it and visualize it and see what's going wrong there.

 

Have you ever wondered if you could be offering a faster, less buggy experience for your customers? I mean, let's face it, the only way you're gonna know that is by actually running it on production. So go figure it out, right? You run it on production, but you need something plugged in so that you can find out where those issues are, where it's slowing down, where it's having bugs. You just, you need something like that there. And Raygun is awesome at this. They just added the performance monitoring, which is really slick. And it works like a breeze. I just, I love it. I love it. It's like, it's like you get the ray gun and you zap the bugs. It's anyway, definitely go check it out. It's going to save you a ton of time, a ton of money, a ton of sanity. I mean, let's face it, grephing through logs is no fun and having people not able to tell you that it's too slow because they got sidetracked into Twitter is also not fun. So go check out ray gun. They are definitely going to help you out. There are thousands of customer centric, customer focused software companies who use RayGun every day to deliver great experiences for their customers. And if you go to RayGun and use our link, you can get a 14 day free trial. So you can go check that out at javascriptjabber.com slash raygun. 

 

DAN_SHAPPIR: So if I understand correctly what you're explaining, it's sort of like an enhanced node JS type environment where I actually type commands at the prompt, but in addition to the built-in node commands, I also have operations to draw graphs and process various file formats and stuff like that, and additional libraries that are already preloaded, as it were. 

ASHLEY_DAVIS: It's just like you're editing a code file, a JavaScript code file that's designed to run under Node.js, but yeah, you can get these live visualizations for time series data, geographic data it supports maps. It can render HTML, it can just render basic text data, it can render JSON data, it can visualize JavaScript objects. It's got a bunch of visualizations built in. They're kind of hard coded into it. One thing I really want to do for version two is to really kind of refactor that so that the visualization system is plugin based so that you could potentially put any charting library in there, any graphing library or anything like maybe having kind of user submitted components, plugins that can be installed into it. And all the code that you write even the visualizations, which can be just compiled out, all the code that you write in DataForge Notebook can just be exported to run under Node.js. So one thing I didn't like about Jupyter Notebook, and that turns out to be a huge problem in the industry for anyone working with Jupyter Notebook, is that once you put code in a notebook, it's very hard to get that code to work outside of the notebook. And I've heard all sorts of tales about how, companies and people productionize their Jupyter Notebooks, to get these notebooks running in production. And my aim for DataForge Notebook was for you to be able to prototype visual, visually prototype code. You know, for me, that's data analysis and transformations and visualizations, but then be able to export that to runnable, a runnable Node.js project so that your, your code kind of isn't trapped in that notebook format. It was always, it was always going to be a stepping stone for me. Like, and that's why I couldn't, I couldn't go on using Jupyter Notebook because you can't say you can't prototype a stock trading strategy in Jupyter Notebook. Well, you can, I mean, you can do that part of it, but then what do you do with it? Like you can't export your code and have it run in a microservice or something like that. It's very difficult to do that with Jupyter notebook. And I really didn't want the notebook to be the, the end of the picture. Cause I'm like, I'm a working developer, like a working production developer. I don't, you know, I don't spend all my time in these notebooks at the end of the day, I need to get the code out and I need to get it into production. So that, that was one of the big motivations for me. DataForge notebook being, you know, something that I always wanted to kind of use myself. And so it's, for me, it's a big, big passion project, but I'm also selling it and I'm giving away, I'm giving away a free version of it now as well. So it's up there for everyone to try. 

DAN_SHAPPIR: I'm personally not familiar with Jupiter notebook, but I am, or I was at least familiar with the MATLAB environment, if you've heard about it or ever tried it. And it sounds kind of similar to that and type of a CLI type environment where you were able to, it had its own programming language, by the way, the Mac lab programming language. But again, you had the ability to read various file formats. You had a lot of built-in data processing functions and graphing functions. And it does seem to me that the big differentiator in the DataForge notebook that you created is indeed this ability to export the JavaScript code that you create in a way that indeed can run anywhere because again, with MATLAB, which again is the example that I'm familiar with, but based on your description also with Jupyter Notebook, you're kind of locked into that development environment. If you want to give your code just for somebody else to run, or if you yourself want to run it on the cloud, it becomes really challenging because essentially you would have to bundle and somehow provide that entire development environment. And it's not really intended to be automated in that way. So, and JavaScript definitely has this big advantage that it can literally run anywhere. So as long as you're- 

ASHLEY_DAVIS:Yeah, I mean, that really goes to the core of why I love JavaScript as well, is that you can use it anywhere. It's not trapped anywhere. It broke out of the front end. When was Node came out about 10 years ago or something, JavaScript broke away from the front end 10 years ago and it hasn't stopped. Like it's-It's everywhere now and you can do everything with it. And that's why I love it. And that's why I needed to be able to kind of do these things with it. The traditionally you would go to Python to do. That's why I just had to be able to do this in JavaScript. I just, I just had to help the community, you know, open it up for that kind of thing. And when I first started on this mission to be able to work with data in JavaScript, there wasn't much around like in terms of tools or software, but it has really opened up. Like, like people are starting to take it seriously in JavaScript. And we're a huge community. And if we want to, if we want to make JavaScript overtake Python for data analysis, like we can literally do that just because there's so many of us that can potentially work on this sort of stuff. You know, it's really up to the community where it goes. 

DAN_SHAPPIR: It's mostly about implementing existing algorithms and stuff like that, correct? And adding support for additional data structures and data formats. 

ASHLEY_DAVIS: Well, there's two things that Python has got going for it. And one is it's community of data scientists. That's great. But who do they turn to when they want to visualize the data? You know, they, they, they either have to get it into the JavaScript themselves, or they have to come to the web developers. So, you know, we're at the end of their pipeline, no matter whether they like that or not. But the other thing that Python's got going for it is it's got these, these old, quite, quite clunky APIs like, like pandas that I don't think they're a good experience for a developer to use, but they do everything that you need to do. Everyone knows how to use them. And they're all backed by native code. So that makes them pretty fast. There's no reason we couldn't do all that in JavaScript. Of course, we can make native code plugins to Node.js. We could do that easily if we wanted to, if we had the will, if we had the need. So there's no reason why we can't do all of that in JavaScript. It's just that Python has got this ecosystem and this legacy and this history that's sort of pushing it forward. And it's especially for me, it's especially prevalent in the machine learning world. So I've been dabbling in machine learning for a few years now. And mostly I have to go to Python to do that still. I am reading this awesome book from Manning that's called Deep Learning with JavaScript. So I do hope to move some of my pipeline and it's all about training models. So you can, you can use TensorFlow now in JavaScript. You can, you can get TensorFlow running in Node.js. You know, we use that at my startup sortle. That's not a big deal. It's the training of the models and all the stuff that goes around that, that still seems where Python is the dominant king. And some of the stuff that I'm reading in this book, Deep Learning with JavaScript is, is really changing my mind on that. And, uh, and I'm trying, it's hard to get time, but I'm trying to work through that book and move some of my pipeline over to JavaScript. 

DAN_SHAPPIR: It might be interesting for you, but Charlie Gerard, I don't know if you've, you've heard about her. She actually lived in Australia for a while. I think, uh, she just released a book about using TensorFlow JS. So that might be interesting for you. 

ASHLEY_DAVIS: Yeah, definitely. 

DAN_SHAPPIR: But going back to what you were talking about, so you're saying that some of the challenges is that because particularly the data scientists are mostly working in Python, there's a lot of existing know-how and libraries and code examples within the Python community around machine learning and around data processing in general that don't yet exist for JavaScript, but there's no reason that they could not exist for JavaScript. It's just a matter of time and effort, I guess, correct? 

ASHLEY_DAVIS: Yeah, and it's whether the community wants to go in that direction. I mean, because there's no reason we have to. I mean, you know, Python as a language doesn't really agree with me. You know, I'll use it when I have to, but it's a perfectly usable, workable language, you know, and it's in a good position. So I don't think it's a case that we necessarily have to kind of try and rival them or try and try and better the Python community. It's not, it's not about that. It's really about like, you know, if you don't have to have someone tell you that you need to go to Python to do that stuff. Like that's just what I'm saying is that if you're already working in JavaScript, you can do a lot of that already in JavaScript. You don't have to leave it. And the situation is already improving and people like myself, and there's a lot of other people out there who are working on these problems, making it easier for the community basically to, to be able to do data science data in JavaScript and hopefully the situation is improving with machine learning in JavaScript as well. 

DAN_SHAPPIR: You're actually not the first person who I've talked with about this topic in the context of JavaScript, so it definitely seems like it's moving forward and I do think that, for example, the advantage of being able to do machine learning from within the browser, either using something like TensorFlow.js or even I think you know, browsers will be are and will be gaining more machine learning capabilities so that you can actually run some of this stuff client side. I think this is really interesting and this is definitely where JavaScript has an advantage over most any other programming language, just its integration with the browser. So I think this is going to be really, really interesting. You also mentioned that you're really getting into TypeScript now. So it's interesting that after you fell in love with with JavaScript, you're now feeling an inclination to move, well, I won't say move away from JavaScript to TypeScript because the end of the day, TypeScript is a superset of JavaScript, but you are sort of transitioning your development environment. Can you tell us about that? 

ASHLEY_DAVIS: Yeah, I think most of my development is in TypeScript now. I've probably still got a handful of really old microservices that I'm looking after that are in JavaScript. I've got one old web page that's just in JavaScript. But most of my code from the last two years has been moved to TypeScript already. I'm really happy with TypeScript. When I first started with JavaScript, I really fell in love with kind of like the dynamic nature of it, the freedom of just writing code and not having to compile it. And I'd come from this background where you have to compile your code and it's all statically type checked. And I was a big fan of that. Back then I was a big fan of that as well. But with JavaScript, after I kind ofAfter I kind of got it with JavaScript, I was like, Oh, I feel like I'm free. You know, like I love this. Isn't it? It's just great. And then of course, you know, you work in JavaScript for a couple of years. And for me, it was only part-time that I was working with JavaScript, but you work with it and you realize that there's a lot of problems with that. You know, it's kind of hard to refactor without breaking it. You're you're mistyping field names and not discovering it until runtime and stuff like that. And then you, then you start to think, yeah, I need, I need to get a bit of static typing back and TypeScript was great for me because I'd had this background in C Sharp, which is, you know, it feels very much of a kin to TypeScript. 

DAN_SHAPPIR: So they're both, they both were created by the same person. 

ASHLEY_DAVIS: Yeah, that's right. 

DAN_SHAPPIR: And just, and just Hillsburg, I think his name is pronounced. 

ASHLEY_DAVIS: Yeah. And so at Microsoft C Sharp was, was my favorite language before JavaScript. So, you know, TypeScript naturally sort of has taken that, that, that place. But the thing I love about it as well, that they've, they've built TypeScript so well, like that you can basically just disable whatever and whenever you want. So you've got the freedom of JavaScript where you want it. And then you've got the type safety of TypeScript and the semantic checking on top of that whenever you need it, whenever you feel like you need that extra helping hand in your coding to keep, you know, to keep it safe and error free. The other thing I really loved about JavaScript, of course, after years of working with C++ and C sharp, where you had to jump through a lot of hoops to get data serialized and you had to write up classes and you had to do all these annotations on all your you know, fields and stuff to kind of load them from your data. With JavaScript, it was just kind of automatic. Like, you kind of, the function to parse JSON is just built into the library, into the language basically. And what is JSON, but just basically a cut down version of JavaScript data. So like that's one of the reasons why I kind of took to working with data in JavaScript actually, I think is because of that, just that, that seamlessness of getting data in and out of the language just was just incredible. And I had this, by this time, I had this deep hatred for XML as well. So I really took to JSON. 

DAN_SHAPPIR: Yeah, I can appreciate that. It's interesting really. I mean, obviously the fact that JavaScript is so closely associated with the web and built-in browser support, native browser support has obviously been instrumental to the success of this language. But I think that the association with JSON, the fact that like you said, what was originally effectively JavaScript's own build, a cut-down or stripped down version of JavaScript own way to represent literal objects and arrays and whatnot has effectively become a data interchange format that's almost ubiquitous now. Well, you know, we now have what's it called. There are other formats as well now, but JSON is still prevalent. And I think that's, that's definitely been instrumental to the success of JavaScript. It's just so easy to, like you said, it's just so easy to work with it and it maps so well to the way that JavaScript internally represents data. 

ASHLEY_DAVIS: I feel like even though some things in JavaScript are hard to learn like closures and asynchronous programming, I think generally JavaScript probably, drops a lot of barriers. Like there's less, I feel like there's less barriers to entry, getting stuff in JavaScript than there can be in other languages. It's just for me, for me, JavaScript's like a really practical language. And since I've basically been doing the entrepreneur thing, you know, and building various MVPs and product prototypes, you know, JavaScript, because you can do JavaScript basically full stack front end, back end, mobile. Like I can cover everything. I can cover everything with JavaScript to a reasonable degree. And, uh, and it basically just takes me through everything. Another thing I love, I love about JavaScript, which I I probably tried to do in older, more static languages, but never really succeeded, is the ability to do live code reload. So I can't get over that. It feels like a superpower to me. You're basically either doing unit testing, test-driven development, you've got Jest on watch so that you can type code and have your tests automatically rerun. In fact, this is what I'm going to be live streaming. I'm live streaming on Twitch at the end of this week and I'm going to be showing how to do this with live reload, automated testing with Jest. But just also things like that. I use the web pack dev server a lot, running it in kind of the hot reload mode. So you can, you can fiddle with your, with your styling. You can play with HTML and JavaScript and you know, it just, it doesn't, it just, it's just there instantly. And, you know, I come from a background where, you know, in the old days, you know, we'd be working on the PlayStation 2 or the Nintendo Wii or something like that and you'd have to compile and it could take like, you know, 20 to 30 minutes on a big game. And then you'd have to like, you know, push it down to the device to run it and start it up. And like in hindsight, now that I'm working with JavaScript, you know, even just working on traditional native mobile apps now, it just seems so slow and awkward and clunky compared to, you know, what you get pretty much out of the box with, you know, web development and, you know, development under Node.js and testing with Jest and Mocha frameworks like that. 

DAN_SHAPPIR: I totally agree. We're starting to run towards the end of the show, but before we, before we move over to picks, I know that you have another book out, I think also on Manning about microservices. Can you tell us briefly about that? 

ASHLEY_DAVIS: Yeah. So, bootstrapping microservices with Docker, Terraform and Kubernetes. That's, that's my latest book. I'm literally going through the final revisions now, but it's been available for about a year on early access. But in the next couple of months, it should actually be printed, which is going to be magnificent feeling to hold my next book in my hand. But it's a practical and project based guide to building microservices. Now it's really focused on the high-level tools like Docker and how to get it running production on Kubernetes and how we use Terraform to implement infrastructure as code. But all the way through because Node.js is what I use in my production work. I use Node.js and JavaScript for example, microservices throughout the book. So it's got a JavaScript theme running all the way through it. Although I do try to explain to people that you're using Docker. So the tech stack to a large extent doesn't matter, but it's a very practical book. And I want to show you how to code these things and how to put them together. So it takes you all the way through from absolute basics to having a fairly non-trivial application running in production on the Kubernetes cluster. But it's just starting with absolute basics like, you know, how do you build one microservice? And then, you know, how do you, how do you publish that? How do you build that doc to a Docker image and publish that? And then how do you use Docker compose to simulate a multi-microservice application on your local development PC? And then, you know, how do you work with databases and microservices using RabbitMQ for messaging between microservices, and then using Terraform towards the end of the book, using Terraform to build your Kubernetes cluster using Terraform to deploy microservices and putting all this on automatic or having a continuous delivery pipeline in your hosted basically next to your code repository. So you're basically pushing code changes to get them into production. And then rounding out the book with some tips on how to take it further. And the whole idea here is that you've been working with microservices so that you've got pathways to future scalability. So there's tips there on how you can change the number of nodes in your Kubernetes cluster just through code, just through using Terraform and how you can change, how you can make replicas of your microservices within your cluster, you know, for fault tolerance and performance and things like that. But this is like the last year and a half of my life, basically writing this book. And it, you know, it builds on, it builds on my experience, you know, over the last 20 years, but specifically in the last three years, when I've been doing contracting around JavaScript microservices. I've built a few of my own products on JavaScript microservices. There was no practical book on how to build a microservices application. There's a bunch of books that, the way I kind of look at it, they're on microservices theory, which might be okay if you're an experienced developer wanting to kind of sidestep into microservices, which is basically where I was at three years ago. But the real practical book that was quite opinionated and was held your hand through the whole process didn't exist. So that's why I wrote this book, you know, I felt like there was like a niche to feel here where I could share my knowledge and share my recipe with the world. And it's very practical, very, very practical, straightforward guidance all the way through. 

DAN_SHAPPIR: That sounds really, really, really good. And I definitely agree that providing practical information about microservices, especially in this day and age, is very pertinent and very, very useful. So thank you for that. And with that, I will push us to picks. 

 

Hey folks, if you love this podcast and would like to support the show, or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production, and you can go sign up at devchat.tv slash premium.

 

DAN_SHAPPIR: Since it's only the two of us, I'll start and then I'll let you, hopefully you also have some picks to share with our listeners. So I actually have just one pick this time. I have not written a book yet. Maybe I will someday, but I have written a couple of blog posts. Again, not as often as I would like, but I just released the latest one yesterday. A day ahead of this recording it will be probably a month or two by the time this episode actually comes out. It's about JavaScript. It's actually me rethinking the use of the JavaScript pipeline operator. For those of you who are not familiar with it, the pipeline operator is a proposal. It's a stage two, I think, proposal, or maybe even just a stage one. I need to check again, but it's definitely not yet part of the standard. There are in fact two competing proposals about how to implement it, which is also holding it back. Despite this fact, I actually used pipeline operator in my in in past yeah it's stage one. I actually use the pipeline operator in two previous blog posts simply because it makes writing sequence of functions in a functional type programming style much cleaner and more readable and consequently I was developing showing how I'm developing a library for synchronous and asynchronous processing of data flowing through effectively a pipeline. And the pipeline operator was really, really useful in that context. But so I got a lot of positive feedback about those blog posts, but a lot of, well, not a lot, but some really negative feedback about the use of the pipeline operator. Some people just didn't like the syntax. It's definitely different. And in both the syntax and semantics are kind of different than what you're used to in JavaScript, so some people are really wary about adding something like that into the language. And then I got an interesting feedback from Kyle Simpson, Getify, a known friend of this podcast and JavaScript guru extraordinaire, who actually gave me a tip about how you might implement something like the pipeline operator without needing to actually extend the language. And I tried it out, played with it, extended it a bit and came out with this blog post. So now I've actually moved from wanting to have the pipeline operator in the language to a position where I think that it's actually not needed and that you don't actually need to add it into the language. And if you're interested in this entire evolution and thought process, well, then I'll be really happy if you read my blog post about it. And that- That's really- Yeah. I'd appreciate your feedback as well. Yeah, I'd like to have a look at that. Yeah, so obviously it will be linked in the show notes for this podcast. And that would be my pick for today. Do you have any picks for us? 

ASHLEY_DAVIS: Yeah, but just what you were just talking about, did you use like a Babel plugin to implement that? 

DAN_SHAPPIR: No, well, in the pipeline operator, yes, it required the Babel plugin because, as I said, it's not yet supported by any browser or other a JavaScript runtime environment. JavaScript runtimes environment, like let's say the DH that's used in Node and in Chrome or Chromium-based browsers, they do occasionally provide early access to stage four or even occasionally stage three features. These are essentially proposals that have not yet been released as part of the standard, but just you know they're on their way they're almost here you know stage four it means that you'll be part of the next release it's done but this is like I said is just stage one so it's which means that it's highly likely to change and if you actually made it part of something like V8 you would create a potentially really big problem because people would start using it and then you kind of be forcing the committee's hand, the PC39, you know, they won't be able to change it because it's already out in the field. So it's actually discouraged for browser makers are discouraged from implementing support for features that are stage one or even stage two. But they do create web plugins for it so that people can actually play with it and provide their feedback about it. And the committee actually looks at that feedback when they try to to choose what to add or not to add to the language. And the CodePen Babel plugin actually supported the pipeline operator. So when I, in the previous blog post, I was actually using that. Now in the latest one, where I show how you don't actually need it, I've just removed the need for the Babel plugin because it's just straight on JavaScript and there's no need to extend it in any way. 

ASHLEY_DAVIS: That's really cool. Yeah, it's just probably just two things I'd like to mention. One is that, just for myself really as a side project and because it's useful to me, I've been developing a can, a Trello style, can band board extension for visual studio code. But I'm also using this as an excuse to get into some live streaming. So I'll give you a link to my, my Twitch feed that you can put up in the show notes, but if people want to learn, you know, about TypeScript coding, actually see someone trying to do test driven development with TypeScript using Jest. And then ultimately building towards this this Kanban thing we can use basically to edit our Kanban boards within Visual Studio Code backed by Markdown files. So you have all your kind of to-do lists and stuff like that in text files, in Markdown files, but you can edit them using this nice UI. So I'm going through the process of building that and I've just started live streaming it and it's really fun. So I'll share that link with you in a minute. But I also just wanted to end up with just saying, you know, a few things sort of toward some advice to new developers or people who are aspiring to get into development. Go for it. Writing these books, you know, like has really allowed me to sort of get back into the position of how do I see this from a beginner perspective? And I want to write my books, minimal jargon and really, really orientated it to make it easy for people to break in really into areas that they might traditionally have been excluded from. So it really gave me a chance to kind of, you know, basically get back in the beginner shoes and kind of look at it from that perspective and coming into these books, you have minimal experience. And I just try to make it easy to read. But it's allowed me to see that perspective in a way that I hadn't been able to see, I guess, for a long time, which was an interesting learning experience for me. But my advice for new devs when I speak to new developers is basically the best skill that you can have to progress as a developer is persistence. Like, like if you can, if you can keep up a little bit of coding every day, like even if it's just five minutes, 10 minutes, 20 minutes, that's the starting point that that's building a habit of coding. And that's going to ensure that you retain the knowledge of the things that you're learning. So it's just practice, practice, practice, you know, build projects. It's all, it's all good to do tutorials, watch videos, read blog posts, all that kind of stuff. I, you know, I still especially love reading like full proper books when I'm trying to get into a new technology or a new language or something like that. But the real way to actually getting into it is to just code every day. And if you can throw yourself into it, and if you can be passionate and always be coding, just never giving up, that daily habit, that daily time adds up and you'll be an experienced developer in no time. So I just, yeah, just. 

DAN_SHAPPIR: I totally agree. Interestingly few episodes back, we had Danny Thompson on the show, who's a person who not only broke his own way into software development, but also helps a lot of other people make their way into this field. And in fact, one of his mantras or one of the basic rules that he tells everybody who's trying to enter software development is what he calls his ABC is always be coding. So I definitely agree with everything that you've said there. I think, I think, you know, you got to get your hands dirty. That's the only way that you can actually learn. 

ASHLEY_DAVIS: And I think if you, if you find yourself really inquisitive and just really into it and loving coding, like, like it just makes that, that time go really quickly. Like you just, it won't, it won't be boring. It won't be hard. You'll just be in the middle of it and it'll be, you know, you'll just be immersed in it, so you don't even notice if it's, if it's hard or not, that's the, that's, that's, I think that's how you know, if you're, if you're going to be really successful as a developer, if you, if you really love doing it, you're going to you're really going to get on well with it. But at the end of the day, it's just that persistence. Just keep trying, keep going and be nice to people, show respect. I think soft skills have been very underrated in our industry and are very important. Because at the end of the day, I think with hard work, anyone can acquire technical skills. It's just that matter of persistence. So if you can do that, if you're on the path to doing that, then start looking at your soft skills. How do you speak to people? How do you relate to people? Can you put yourself in their shoes? I think all that's really important as well. 

DAN_SHAPPIR: I totally agree. Before we finish, if people want to get in touch with you, what would be the best ways to go about it? 

ASHLEY_DAVIS: Oh, yeah, so the best way is probably Twitter. So AshleyDavis75. I'll give you a link for that as well that you can put up. And my live stream on Manning is AshleyDavis. 

DAN_SHAPPIR: Very, very nice. So it was great having you on the show. A lot of super interesting and useful information, I think. And with that, we conclude another episode of JavaScript Jabber. So goodbye everybody. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To deliver your content fast with Cashfly, visit C-A-C-H-E-F-L-Y dot com to learn more.