more transcript corrections.

Author: mikeckennedy

transcripts/098.txt

@@ -36,7 +36,7 @@
 
 00:05:30 Michael Kennedy: Oh yeah, absolutely. That's really, really great. Let's talk about this project that you've created, Django Channels, can you just kind of tell us, briefly, you know, what is Django Channels?
 
-00:05:41 Andrew Godwin: It's a very hard thing to describe but I'll have a go. So Django Channels is actually, it's kind of two things. Like it's important to, as we talk about it more in the podcast. So first of all, so the headline feature as you were is Django Channels is a way of having WebSockets supported in Django. And we can go in later on as to why that's difficult and hard but needless to say that until Channels existed, WebSockets was very hard to do in Django just due to some of the technical limitations therein. But the second part of Channels is sort of this underlying layer of like to solve the problem in WebSockets, there's a lot of interesting technical challenges that go with that. And so part of it is like well how do we solve the problem of writing semi-asynchronous code, not fully asynchronous code but semi-asynchronous code, with Django and having things like the Django RM and the middleware and stuff and things that people are familiar with still work. Like how do we keep that stuff familiar yet also have extra power in there? Like I said, it's almost this two-faced story of the underlying solution that powers everything and on top of it, the nice layer of and here's WebSocket supports to go on top of it.
+00:05:41 Andrew Godwin: It's a very hard thing to describe but I'll have a go. So Django Channels is actually, it's kind of two things. Like it's important to, as we talk about it more in the podcast. So first of all, so the headline feature as you were is Django Channels is a way of having WebSockets supported in Django. And we can go in later on as to why that's difficult and hard but needless to say that until Channels existed, WebSockets was very hard to do in Django just due to some of the technical limitations therein. But the second part of Channels is sort of this underlying layer of like to solve the problem in WebSockets, there's a lot of interesting technical challenges that go with that. And so part of it is like well how do we solve the problem of writing semi-asynchronous code, not fully asynchronous code but semi-asynchronous code, with Django and having things like the Django ORM and the middleware and stuff and things that people are familiar with still work. Like how do we keep that stuff familiar yet also have extra power in there? Like I said, it's almost this two-faced story of the underlying solution that powers everything and on top of it, the nice layer of and here's WebSocket supports to go on top of it.
 
 00:06:48 Michael Kennedy: Okay, and just making that really easy and giving people a great API for it, huh?
 

transcripts/125.txt

@@ -182,11 +182,11 @@
 
 00:24:30 Tom Christie: Yes. And also dealing with the if you've got some data that you want to present to the user, or rather if you've got some objects that you want to present to the user, what do you want the representation of those objects to look like? If we're dealing with relationships between the objects are you presenting those as the plain primary keys or should they be presented as hyperlinks? All of those sorts of that. Like do you want to return big nested sets of data where you've got all sorts of interlinks objects all being returned in bulk, or do you want flat set data structures? All of those sorts of things.
 
-00:25:12 Michael Kennedy: Okay cool, so if I'm working with Django RM or even SQLAlchemy or MongoDB, something like this, and I'm getting sort of ORM objects back does it handle like the serialization of those types of things?
+00:25:12 Michael Kennedy: Okay cool, so if I'm working with Django ORM or even SQLAlchemy or MongoDB, something like this, and I'm getting sort of ORM objects back does it handle like the serialization of those types of things?
 
-00:25:25 Tom Christie: So it works, being Django based, it works primarily with the Django RM. There's stuff that you could do to integrate it with other backends as well, but...
+00:25:25 Tom Christie: So it works, being Django based, it works primarily with the Django ORM. There's stuff that you could do to integrate it with other backends as well, but...
 
-00:25:38 Michael Kennedy: The question is like suppose I'm in my web app that I do a query and I get like a list of users back from Django RM, can I just return that list and have it magically JSONified, or XMLified, or whatever?
+00:25:38 Michael Kennedy: The question is like suppose I'm in my web app that I do a query and I get like a list of users back from Django ORM, can I just return that list and have it magically JSONified, or XMLified, or whatever?
 
 00:25:50 Tom Christie: Yes and no. So yes, you can, no, you probably don't want to.
 
@@ -252,7 +252,7 @@
 
 00:38:04 Michael Kennedy: Yeah. So, there's another thing that I came across that you just started working on as well that's very exciting. I don't know how it ties into the funding stuff, but I certainly think it's cool, is called API Star. Tell people what API Star is.
 
-00:38:20 Tom Christie: This is a new API framework that I started working on. REST framework is still my my main gig I guess, but there are a couple of different things that I think are important to explore at the moment, and API Star is my step towards doing some of that. It's an API framework that's not tied into Django or the Django RM and has a different approach to the fundamental interface that you use for building your code base. So, rather than having views, which are functions that take a request and return a response, instead you have views where you declare on the view function using type annotations, the sorts of data and the sorts of components that that function is going to take. And you also declare what type of data it's going to return, as well. And once you take that different approach there's a lot of interesting things that you can start to do on top of that. So to start with because you've got a plain data interface, rather than take a request and return a response, you can layer on different types of network interface or different ways of interacting with that function on top of it. So for example, as well as accepting HTTP requests, you could root a command line command into your view, or you can potentially look at being able to build views that accept either HTTP requests or web socket connections, and that provide a real time subscription endpoint. There are ways you can start to think about doing that, or even start to think about can we build views that we can share, that we can kind of share functionality being exposed to GraphQL endpoints and regular HTTP calls. Now, not all of those things are done, but I'm starting to think about how would we be able to do those. As well as having this different style of interface, something else it provides is a type system that corresponds to the same capabilities as JSON's schema. So, we have a type system that you can use to declare what your data structures look like both for the input and for the output for these functions. And once you've got that you've suddenly got something really powerful where you're able to for instance build API documentation based on those type annotations that is guaranteed to always be in sync with your code base. Not only can you build this API documentation, you can also build interactive API documentation because you've got enough information in those types that you can build HTML form controls with appropriate controls given the shape of the data input. You have this proxy all of a sudden that you have a really nice one to one mapping between your function declarations and an API schema language such as Swagger or RAML. So, you can have a really clear way of generating Swagger or RAML from your type declarations. If you wanted you could even go the other way and say, "Okay, I've got my Swagger blueprint. Build me this stubbed out set of functions that I'm going to want for my project." You've even got enough information that once you write out these declarations even before you implemented anything you could start running, or you will be able to start running, a mock API. So, you've got all the response types. You know what the inputs look like and whether they're valid or they're not valid. So, what you can do is have your team build up all the function declarations and present to your front end team a mock API that's already ready to start then build the front end again, while your back end team starts to fill in all the blanks of, "Oh, well we better actually implement the behavior here." So, there's all these...
+00:38:20 Tom Christie: This is a new API framework that I started working on. REST framework is still my my main gig I guess, but there are a couple of different things that I think are important to explore at the moment, and API Star is my step towards doing some of that. It's an API framework that's not tied into Django or the Django ORM and has a different approach to the fundamental interface that you use for building your code base. So, rather than having views, which are functions that take a request and return a response, instead you have views where you declare on the view function using type annotations, the sorts of data and the sorts of components that that function is going to take. And you also declare what type of data it's going to return, as well. And once you take that different approach there's a lot of interesting things that you can start to do on top of that. So to start with because you've got a plain data interface, rather than take a request and return a response, you can layer on different types of network interface or different ways of interacting with that function on top of it. So for example, as well as accepting HTTP requests, you could root a command line command into your view, or you can potentially look at being able to build views that accept either HTTP requests or web socket connections, and that provide a real time subscription endpoint. There are ways you can start to think about doing that, or even start to think about can we build views that we can share, that we can kind of share functionality being exposed to GraphQL endpoints and regular HTTP calls. Now, not all of those things are done, but I'm starting to think about how would we be able to do those. As well as having this different style of interface, something else it provides is a type system that corresponds to the same capabilities as JSON's schema. So, we have a type system that you can use to declare what your data structures look like both for the input and for the output for these functions. And once you've got that you've suddenly got something really powerful where you're able to for instance build API documentation based on those type annotations that is guaranteed to always be in sync with your code base. Not only can you build this API documentation, you can also build interactive API documentation because you've got enough information in those types that you can build HTML form controls with appropriate controls given the shape of the data input. You have this proxy all of a sudden that you have a really nice one to one mapping between your function declarations and an API schema language such as Swagger or RAML. So, you can have a really clear way of generating Swagger or RAML from your type declarations. If you wanted you could even go the other way and say, "Okay, I've got my Swagger blueprint. Build me this stubbed out set of functions that I'm going to want for my project." You've even got enough information that once you write out these declarations even before you implemented anything you could start running, or you will be able to start running, a mock API. So, you've got all the response types. You know what the inputs look like and whether they're valid or they're not valid. So, what you can do is have your team build up all the function declarations and present to your front end team a mock API that's already ready to start then build the front end again, while your back end team starts to fill in all the blanks of, "Oh, well we better actually implement the behavior here." So, there's all these...
 
 00:43:06 Michael Kennedy: That's really cool.
 

transcripts/277.txt

@@ -30,7 +30,7 @@
 
 00:12:45 then with the query, and for example, if you're filtering, you can use under double underscore to, for example, you have a field and then you can do underscore underscore contains, is that like a person? Like a like? percent? Like, exactly, exactly. Okay. Yeah, that's how quick the SQL language Yeah, yeah, yeah, just I like the syntax at this with double underscore. And you can even link to other models, if you go through underscore, underscore, and then the foreign key fields, and then underscore on this chord attributes. But of course, as we said before, we have to be careful with doing a lot of lot of queries there. But sometimes you just need to reach out to linked models, right? Yeah. Then if you want to do like more complex queries, you can use the uppercase Q, the Q objects, so you could do Q, if one field is this or Q, if another field is that. So that's a way to concatenate certain conditions, right? Because a lot of times you'll end up, you can use filter and put multiple parameters, but you're going to end up with an and which is exactly that's a good point. You don't Yes, yeah. don't always want to Yeah, like sometimes you do. But if you don't build, you're not gonna help you. That's a great addition. Because Exactly. If you do like filter, attribute equals comma, another attribute equals their end. And yeah, with you, you can do an or Yeah, if something else is convenient. Yeah. And then we have annotations. So the group by so for example, I have a tangled tip, we, we might be able to link to it. Maybe in the show notes how to get we got the most common user names on the platform, which happened to be David, Daniel and Michael.
 
-00:14:31 Another other programmers names like that. Yeah, I guess so. Interesting. I feel like we almost have to create some just have your little code, say, Oh, yeah. And like link to them. Right. We could do that. I can totally do that. Yeah. And also, this one, one. I really like that how the code is laid out over multiple lines, as I guess black would do it. And you're looking at the same code, right? It's pretty elegant, I think. Yeah, it's super elegant. Yeah, I really like it. And I feel like I write Django RM code all the time, even though I don't use Django nor do
+00:14:31 Another other programmers names like that. Yeah, I guess so. Interesting. I feel like we almost have to create some just have your little code, say, Oh, yeah. And like link to them. Right. We could do that. I can totally do that. Yeah. And also, this one, one. I really like that how the code is laid out over multiple lines, as I guess black would do it. And you're looking at the same code, right? It's pretty elegant, I think. Yeah, it's super elegant. Yeah, I really like it. And I feel like I write Django ORM code all the time, even though I don't use Django nor do
 
 00:15:00 Do I use a relational database? That's weird, right? And the reason is I use a Mongo engine, which is the ORM. ODM for MongoDB. But it's modeled on Django or M. So like, it's almost identical, you know, as much as it can be no crappy and non relational. So anyway, yeah, it's it's a really nice API. I do like, Oh, these are cool. Yeah. Well, we'll put the gist of how you got the most common usernames? Yeah. Out of first names out of your users. That's cool. And make it okay, I guess hand in glove with RMS od M's is the models that define them, right? Yeah. nice segue right
 

transcripts/426-pyscript-update.vtt

@@ -1953,7 +1953,7 @@ he has implemented the FFI, the foreign function interface between Python and th
 
 
 00:25:59.060 --> 00:26:05.380
-context. Okay, it's the same sort of API as you get in Pyedite. Okay, so it's familiar.
+context. Okay, it's the same sort of API as you get in Pyodide. Okay, so it's familiar.
 
 
 00:26:05.380 --> 00:26:10.740

transcripts/451-djangonauts.vtt

@@ -1663,7 +1663,7 @@ that would be really a bonus is just the edge it gives you in working in web dev
 and Python as a job opportunity going forward, right? If you say, yes, I know how to do a
 
 00:50:05.340 --> 00:50:10.300
-database query with the Django RM, please hire me. That's one thing. It's another to
+database query with the Django ORM, please hire me. That's one thing. It's another to
 
 00:50:10.300 --> 00:50:15.500
 say, I added that feature that you're excited about. Can we talk about my position? Right?

transcripts/464-kolo-app-for-django-and-observing-pythons.vtt

@@ -1228,7 +1228,7 @@ This will be a play.colo.app.
 So with this, yeah, this is super fun because this is fully Python just running in the
 
 00:18:45.020 --> 00:18:47.460
-browser using Pyedite and like WebAssembly.
+browser using Pyodide and like WebAssembly.
 
 00:18:47.460 --> 00:18:48.540
 Nice. OK.
@@ -1279,7 +1279,7 @@ That's awesome. So this is super cool.
 It's just just all from scratch.
 
 00:19:28.660 --> 00:19:30.860
-It's besides Pyedite here.
+It's besides Pyodide here.
 
 00:19:30.860 --> 00:19:34.700
 Not like VS Code in the browser or anything like that.
@@ -1288,7 +1288,7 @@ Not like VS Code in the browser or anything like that.
 I think it's using Monaco in this case or CodeMirror.
 
 00:19:37.500 --> 00:19:41.620
-But otherwise, this is all is this Pyedite and a little bit of React to like pull kind
+But otherwise, this is all is this Pyodide and a little bit of React to like pull kind
 
 00:19:41.620 --> 00:19:43.980
 of the data together. But yeah, we're really.
@@ -1837,7 +1837,7 @@ One of the things that makes me want to write fewer unit tests or not write a un
 in a certain case is I can test given using mocking, given my let's say SQLAlchemy or
 
 00:29:10.820 --> 00:29:15.580
-Beanie or whatever Django RM model theoretically matches the database.
+Beanie or whatever Django ORM model theoretically matches the database.
 
 00:29:15.580 --> 00:29:19.060
 I can do some stuff, set some values and check that that's all good.

youtube_transcripts/335-gene-editing.vtt

@@ -4669,7 +4669,7 @@ So we had time for just a little bit more digging into it.
 
 
 00:59:22.100 --> 00:59:25.380
-So you talked about the Django RM, Django REST framework,
+So you talked about the Django ORM, Django REST framework,
 
 
 00:59:25.380 --> 00:59:27.140

youtube_transcripts/379-17-django-libs.vtt

@@ -3425,7 +3425,7 @@ say, image upload, for example.
 
 
 00:36:42.680 --> 00:36:45.620
-- You obviously need this for the Django RM field
+- You obviously need this for the Django ORM field
 
 
 00:36:45.620 --> 00:36:48.500

youtube_transcripts/426-pyscript-update.vtt

@@ -4493,7 +4493,7 @@ And we can have multiple interpreters.
 
 
 01:00:50.000 --> 01:00:53.680
-Maybe one is Pyedite, another is Python, another is Lua.
+Maybe one is Pyodide, another is Python, another is Lua.
 
 
 01:00:53.680 --> 01:00:58.080

youtube_transcripts/451-djangonauts.vtt

@@ -3202,7 +3202,7 @@ as a job opportunity going forward.
 If you say, yes, I know how to do a database query
 
 00:53:41.420 --> 00:53:43.700
-with the Django RM, please hire me.
+with the Django ORM, please hire me.
 
 00:53:43.700 --> 00:53:45.140
 That's one thing.

youtube_transcripts/464-kolo-app-for-django-and-observing-pythons.vtt

@@ -1345,7 +1345,7 @@ So with this, yeah, this is super fun
 because this is fully Python just running in the browser
 
 00:18:39.060 --> 00:18:41.060
-using Pyedite and like web assembly.
+using Pyodide and like web assembly.
 
 00:18:41.060 --> 00:18:42.460
 - Oh, nice, okay.