Software Sessions
Jeremy Jung
Subscribe
Practical conversations about software development.
Available episodes
Newest first
Oldest first
Nov 10, 2021
Taking Notes on Serverless
Swizec is the author of the Serverless Handbook and a software engineer at Tia.
Swizec
* Swizec's personal site
* Serverless Handbook
AWS
* Lambda
* API Gateway
* Operating Lambda (The cold start problem)
* Provisioned Concurrency
* DynamoDB
* Relational Database Service
* Aurora
* Simple Queue Service
* CloudFormation
* CloudWatch
Other serverless function hosting providers
* Gatsby Cloud Functions
* Vercel Serverless Functions
* Netlify Functions
* Cloud Functions for Firebase
Related topics
* Serverless Framework
* Jamstack
* Lighthouse
* What is a Static Site Generator?
* What is a CDN?
* Keeping Server-Side Rendering Cool With React Hydration
* TypeScript
Transcript
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: Today, I'm talking to Swiz Teller. He's a senior software engineer at Tia. The author of the serverless handbook and he's also got a bunch of other courses and I don't know is it thousands of blog posts now you have a lot of them.
[00:00:13] Swizec: It is actually thousands of, uh, it's like 1500. So I don't know if that's exactly thousands, but it's over a thousand.
I'm cheating a little bit. Cause I started in high school back when blogs were still considered social media and then I just kind of kept going on the same domain.
Do you have some kind of process where you're, you're always thinking of what to write next? Or are you writing things down while you're working at your job? Things like that. I'm just curious how you come up with that.
[00:00:41] Swizec: So I'm one of those people who likes to use writing as a way to process things and to learn. So one of the best ways I found to learn something new is to kind of learn it and then figure out how to explain it to other people and through explaining it, you really, you really spot, oh shit. I don't actually understand that part at all, because if I understood it, I would be able to explain it.
And it's also really good as a reference for later. So some, one of my favorite things to do is to spot a problem at work and be like, oh, Hey, this is similar to that side project. I did once for a weekend experiment I did, and I wrote about it so we can kind of crib off of my method and now use it. So we don't have to figure things out from scratch.
And part of it is like you said, that just always thinking about what I can write next. I like to keep a schedule. So I keep myself to posting two articles per week. It used to be every day, but I got too busy for that. when you have that schedule and, you know, okay on Tuesday morning, I'm going to sit down and I have an hour or two hours to write, whatever is on top of mind, you kind of start spotting more and more of these opportunities where it's like a coworker asked me something and I explained it in a slack thread and it, we had an hour. Maybe not an hour, but half an hour of back and forth. And you actually just wrote like three or 400 words to explain something. If you take those 400 words and just polish them up a little bit, or rephrase them a different way so that they're easier to understand for somebody who is not your coworker, Hey, that's a blog post and you can post it on your blog and it might help others.
[00:02:29] Jeremy: It sounds like taking the conversations most people have in their day to day. And writing that down in a more formal way.
[00:02:37] Swizec: Yeah. not even maybe in a more formal way, but more, more about in a way that a broader audience can appreciate. if it's, I'm super gnarly, detailed, deep in our infrastructure in our stack, I would have to explain so much of the stuff around it for anyone to even understand that it's useless, but you often get these nuggets where, oh, this is actually a really good insight that I can share with others and then others can learn from it. I can learn from it.
[00:03:09] Jeremy: What's the most accessible way or the way that I can share this information with the most people who don't have all this context that I have from working in this place.
[00:03:21] Swizec: Exactly. And then the power move, if you're a bit of an asshole is to, instead of answering your coworkers question is to think about the answer, write a blog post and then share the link with them.
I think that's pushing it a little bit.
[00:03:38] Jeremy: Yeah, It's like you're being helpful, but it also feels a little bit passive aggressive.
[00:03:44] Swizec: Exactly. Although that's a really good way to write documentation. One thing I've noticed at work is if people keep asking me the same questions, I try to stop writing my replies in slack and instead put it on confluence or whatever internal wiki that we have, and then share that link. and that has always been super appreciated by everyone.
[00:04:09] Jeremy: I think it's easy to, have that reply in slack and, and solve that problem right then. But when you're creating these Wiki pages or these documents, how're people generally finding these. Cause I know you can go through all this trouble to make this document. And then people just don't know to look or where to go.
[00:04:30] Swizec: Yeah. Discoverability is a really big problem, especially what happens with a lot of internal documentation is that it's kind of this wasteland of good ideas that doesn't get updated and nobody maintains. So people stop even looking at it. And then if you've stopped looking at it before, stop updating it, people stop contributing and it kind of just falls apart.
And the other problem that often happens is that you start writing this documentation in a vacuum. So there's no audience for it, so it's not help. So it's not helpful. That's why I like the slack first approach where you first answered the question is. And now, you know exactly what you're answering and exactly who the audiences.
And then you can even just copy paste from slack, put it in a conf in JIRA board or wherever you put these things. spice it up a little, maybe effect some punctuation. And then next time when somebody asks you the same question, you can be like, oh, Hey, I remember where that is. Go find the link and share it with them and kind of also trains people to start looking at the wiki.
I don't know, maybe it's just the way my brain works, but I'm really bad at remembering information, but I'm really good at remembering how to find it. Like my brain works like a huge reference network and it's very easy for me to remember, oh, I wrote that down and it's over there even if I don't remember the answer, I almost always remember where I wrote it down if I wrote it down, whereas in slack it just kind of gets lost.
[00:06:07] Jeremy: Do you also take more informal notes? Like, do you have notes locally? You look through or something? That's not a straight up Wiki.
[00:06:15] Swizec: I'm actually really bad at that. I, one of the things I do is that when I'm coding, I write down. so I have almost like an engineering log book where everything, I, almost everything I think about, uh, problems I'm working on. I'm always writing them down on by hand, on a piece of paper. And then I never look at those notes again.
And it's almost like it helps me think it helps me organize my thoughts.
And I find that I'm really bad at actually referencing my notes and reading them later because, and this again is probably a quirk of my brain, but I've always been like this. Once I write it down, I rarely have to look at it again.
But if I don't write it down, I immediately forget what it is.
What I do really like doing is writing down SOPs. So if I notice that I keep doing something repeatedly, I write a, uh, standard operating procedure. For my personal life and for work as well, I have a huge, oh, it's not that huge, but I have a repository of standard procedures where, okay, I need to do X.
So you pull up the right recipe and you just follow the recipe. And if you spot a bug in the recipe, you fix the recipe. And then…
playlist_add
Oct 27, 2021
Robotic Process Automation with Alexander Pugh
Alexander Pugh is a software engineer at Albertsons. He has worked in Robotic Process Automation and the cognitive services industry for over five years.
This episode originally aired on Software Engineering Radio.
Related Links
* Alexander Pugh's personal site
Enterprise RPA Solutions
* Automation Anywhere
* UiPath
* blueprism
Enterprise "Low Code/No Code" API Solutions
* appian
* mulesoft
* Power Automate
RPA and the OS
* Office primary interop assemblies
* Office Add-ins documentation
* Task Scheduler for developers
* The Component Object Model
* The Document Object Model
Transcript
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: Today, I'm talking to Alexander Pugh. He's a solutions architect with over five years of experience working on robotic process automation and cognitive services.
Today, we're going to focus on robotic process automation.
Alexander welcome to software engineering radio.
[00:00:17] Alex: Thank you, Jeremy. It's really good to be here.
[00:00:18] Jeremy: So what does robotic process automation actually mean?
[00:00:23] Alex: Right. It's a, it's a very broad nebulous term. when we talk about robotic process automation, as a concept, we're talking about automating things that humans do in the way that they do them. So that's the robotic, an automation that is, um, done in the way a human does a thing.
Um, and then process is that thing, um, that we're automating. And then automation is just saying, we're turning this into an automation where we're orchestrating this and automating this. and the best way to think about that in any other way is to think of a factory or a car assembly line. So initially when we went in and we, automated a car or factory, automation line, what they did is essentially they replicated the process as a human did it. So one day you had a human that would pick up a door and then put it on the car and bolt it on with their arms. And so the initial automations that we had on those factory lines were a robot arm that would pick up that door from the same place and put it on the car and bolt it on there.
Um, so the same can be said for robotic process automation. We're essentially looking at these, processes that humans do, and we're replicating them, with an automation that does it in the same way. Um, and where we're doing that is the operating system. So robotic process automation is essentially going in and automating the operating system to perform tasks the same way a human would do them in an operating system.
So that's, that's RPA in a nutshell,
Jeremy: So when you say you're replicating something that a human would do, does it mean it has to go through some kind of GUI or some kind of user interface?
[00:02:23] Alex: That's exactly right, actually. when we're talking about RPA and we look at a process that we want to automate with RPA, we say, okay. let's watch the human do it. Let's record that. Let's document the human process. And then let's use the RPA tool to replicate that exactly in that way.
So go double click on Chrome, launch that click in the URL line and send key in www.cnn.com or what have you, or servicenow hit enter, wait for it to load and then click, you know, where you want to, you know, fill out your ticket for service. Now send key in. So that's exactly how an RPA solution at the most basic can be achieved.
Now and any software engineer knows if you sit there and look over someone's shoulder and watch them use an operating system. Uh, you'll say, well, there's a lot of ways we can do this more efficiently without going over here, clicking that, you know, we can, use a lot of services that the operating system provides in a programmatic way to achieve the same ends and RPA solutions can also do that.
The real key is making sure that it is still achieving something that the human does and that if the RPA solution goes away, a human can still achieve it. So if you're, trying to replace or replicate a process with RPA, you don't want to change that process so much so that a human can no longer achieve it as well.
that's something where if you get a very technical, and very fluent software engineer, they lose sight of that because they say, oh, you know what? There's no reason why we need to go open a browser and go to you know, the service now portal and type this in when I can just directly send information to their backend.
which a human could not replicate. Right? So that's kind of where the line gets fuzzy. How efficiently can we make this RPA solution?
[00:04:32] Jeremy: I, I think a question that a lot of people are probably having is a lot of applications have APIs now. but what you're saying is that for it to, to be, I suppose, true RPA, it needs to be something that a user can do on their own and not something that the user can do by opening up dev tools or making a post to an end point.
[00:04:57] Alex: Yeah. And so this, this is probably really important right now to talk about why RPA, right? Why would you do this when you could put on a server, a a really good, API ingestion point or trigger or a web hook that can do this stuff. So why would we, why would we ever pursue our RPA?
There there's a lot of good reasons for it. RPA is very, very enticing to the business. RPA solutions and tools are marketed as a low code, no code solution for the business to utilize, to solve their processes that may not be solved by an enterprise solution and the in-between processes in a way.
You have, uh, a big enterprise, finance solution that everyone uses for the finance needs of your business, but there are some things that it doesn't provide for that you have a person that's doing a lot of, and the business says, Okay. well, this thing, this human is doing this is really beneath their capability. We need to get a software solution for it, but our enterprise solution just can't account for it. So let's get a RPA capability in here. We can build it ourselves, and then there we go. So there, there are many reasons to do that. financial, IT might not have, um, the capability or the funding to actually build and solve the solution. Or it it's at a scale that is too small to open up, uh, an IT project to solve for. Um, so, you know, a team of five is just doing this and they're doing it for, you know, 20 hours a week, which is uh large, but in a big enterprise, that's not really. Maybe um, worth building an enterprise solution for it. or, and this is a big one. There are regulatory constraints and security constraints around being able to access this or communicate some data or information in a way that is non-human or programmatic. So that's really where, um, RPA is correctly and best applied and you'll see it most often.
So what we're talking about there is in finance, in healthcare or in big companies where they're dealing with a lot of user data or customer data in a way. So when we talk about finance and healthcare, there are a lot of regulatory constraints and security reasons why you would not enable a programmatic solution to operate on your systems.
You know, it's just too hard. We we're not going to expose our databases or our data to any other thing. It would, it would take a huge enterprise project to build out that capability, secure that capability and ensure it's going correctly. We just don't have the money the time or the strength honestly, to afford for it.
So they say, well, we already have. a user pattern. We already allow users to, to talk to this information and communicate this information. Let's get an RPA tool, which for all intents and purposes will be acting as a user. And then it can just automate that process without us exposing to queries or any other thing, an enterprise solution or programmatic, um, solution.
So that's really why RPA, where and why you, you would apply it is there's, there's just no capability at enterprise for one reason or another to solve for it.
[00:08:47] Jere…
playlist_add
Sep 16, 2021
Deployment from Scratch with Josef Strzibny
Josef Strzibny is the author of Deployment from Scratch and a current Fedora contributor. He previously worked on the Developer Experience team at Red Hat.
This episode originally aired on Software Engineering Radio.
Links:
* Deployment from Scratch
* @strzibnyj
* systemd
* Introduction to Control Groups
* SELinux
* Fedora
* Rocky Linux
* Puma
* AppSignal
* Datadog
* Rollbar
* Skylight
* Bootstrapping a multiplayer server with Elixir at X-Plane
* StackExchange Performance
* Chruby
* Password Safe
* Vault
* Rails Custom Credentials
Transcript:
You can help edit this transcript on GitHub.
[00:00:00] Jeremy: Today, I'm talking to Josef Strzibny.
He's the author of the book deployment from scratch. A fedora contributor. And he previously worked on the developer experience team at red hat.
Josef welcome to software engineering radio.
[00:00:13] Josef: Uh, thanks for having me. I'm really happy to be here.
There are a lot of commercial services for hosting applications these days. One that's been around for quite a while is Heroku, but there's also services like render and Netlify. why should a developer learn how to deploy from scratch and why would a developer choose to self host an application
[00:00:37] Josef: I think that as a web engineers and backend engineers, we should know a little bit more how we run our own applications, that we write. but there is also a business case, right?
For a lot of people, this could be, uh, saving money on hosting, especially with managed databases that can go, high in price very quickly. and for people like me, that apart from daily job have also some side project, some little project they want to, start and maybe turn into a successful startup, you know but it's at the beginning, so they don't want to spend too much money on it, you know?
And, I can deploy and, serve my little projects from $5 virtual private servers in the cloud. So I think that's another reason to look into it. And business wise, if you are, let's say a bigger team and you have the money, of course you can afford all these services. But then what happened to me when I was leading a startup, we were at somewhere (?) and people are coming and asking us, we need to self host their application.
We don't trust the cloud. And then if you want to prepare this environment for them to host your application, then you also need to know how to do it. Right? I understand completely get the point of not knowing it because already backend development can be huge.
You know, you can learn so many different databases, languages, whatever, and learning also operations and servers. It can be overwhelming. I want to say you don't have to do it all at once. Just, you know, learn a little bit, uh, and you can improve as you go. Uh, you will not learn everything in a day.
[00:02:28] Jeremy: So it sounds like the very first reason might be to just have a better understanding of, of how your applications are, are running. Because even if you are using a service, ultimately that is going to be running on a bare machine somewhere or run on a virtual machine somewhere. So it could be helpful maybe for just troubleshooting or a better understanding how your application works.
And then there's what you were talking about with some companies want to self-host and, just the cost aspect.
[00:03:03] Josef: Yeah. for me, really, the primary reason would be to understand it because, you know, when I was starting programming, oh, well, first of there was PHP and I, I used some shared hosting thing, just some SFTP. Right. And they would host it for me. It was fine. Then I switched to Ruby on Rails and at the time, uh, people were struggling with deploying it and I was asking myself, so, okay, so you ran rails s like for a server, right. It starts in development, but can you just do that on the server for, for your production? You know, can you just rails server and is that it, or is there more to it? Or when people were talking about, uh, Linux hardening, I was like, okay, but you know, your Linx distribution have some good defaults, right.
[00:03:52] Jeremy: So why do you need some further hardening? What does it mean? What to change. So for me, I really wanted to know, uh, the reason I wrote this book is that I wanted to like double down on my understanding that I got it right. Yeah, I can definitely relate in the sense that I've also used Ruby and Ruby on rails as well. And there's this, this huge gap between just learning how to run it in a development environment on your computer versus deploying it onto a server and it's pretty overwhelming. So I think it's, it's really great that, that you're putting together a book that, that really goes into a lot of these things that I think that usually aren't talked about when people are just talking about learning a language.
[00:04:39] Josef: you can imagine that a lot of components you can have into this applications, right? You have one database, maybe you have more databases. Maybe you have a redis key-value store. Uh, then you might have load balancers and all that jazz. And I just want to say that there's one thing I also say in the book, like try to keep it simple. If you can just deploy one server, if you don't need to fulfill some SLE (SLA) uh, uptime, just do the simplest thing first, because you will really understand it. And when there was an error you will know how to fix it because when you make things complex for you, then it will be kind of lost, very quickly. So I try to really make things as simple as possible to stay on top of them.
[00:05:25] Jeremy: I think one of the first decisions you have to make, when you're going to self host an application is you have to decide which distribution you're going to use. And there's things like red hat and Ubuntu, and Debian and all these different distributions. And I'm wondering for somebody who just wants to deploy their application, whether that's rails, Django, or anything else, what are the key differences between them and, and how should they choose a distribution?
[00:05:55] Josef: if you already know one particular distribution, there's no need to constantly be on the hunt for a more shiny thing, you know, uh, it's more important that you know it well and, uh, you are not lost. Uh, that said there are differences, you know, and there could be a long list from goals and philosophy to who makes it whether community or company, if it's showing distribution or not, lack of support, especially for security updates, uh, the kind of init systems, uh, that is used, the kind of c library that is used packaging format, package manager, and for what I think most people will care about number of packages and the quality or version, right?
Because essentially the distribution is distribution of software. So you care about the software. If you are putting your own stuff, on top of it. you maybe don't care. You just care about it being a Linux distribution and that's it. That's fine. But if you are using more things from the distribution, you might star, start caring a little bit more.
You know, other thing is maybe a support for some mandatory access control or in the, you know, world of Docker, maybe the most minimal image you can get established because you will be building a lot of, a lot of times the, the Docker image from the Docker file. And I would say that two main family of systems that people probably know, uh, ones based on Fedora and those based on Debian, right from Fedora, you have, uh, Red Hat Enterprise Linux, CentOS, uh, Rocky Linux.
And on the Debian side you have Ubuntu which is maybe the most popular cloud distribution right now. And, uh, of course as a Fedora packager I'm kind of, uh, in the fedora world. Right. But if I can, if I can mention two things that I think makes sense or like our advantage to fedora based systems. And I would say one is modular packages because it's traditional systems for a lon…
playlist_add
May 29, 2021
Quality Assurance Testing
Michael Ashburne and Maxwell Huffman are QA Managers at Aspiritech.
This episode originally aired on Software Engineering Radio.
Related Links:
* Aspiritech
* Section 508 Test for Accessibility
* ANDI Accessibility Testing Tool
* Windows Hardware Compatibility Program
* Audio over Bluetooth
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] Today I'm joined by Maxwell, Huffman and Michael Ashburn. They're both QA managers at Aspiritech. I'm going to start with defining quality assurance. Could one of you start by explaining what it is?
Maxwell: [00:00:15] So when I first joined Aspiritech, I was kind of curious about that as well. One of the main things that we do at Aspiritech besides quality assurance is we also, give meaningful employment to individuals on the autism spectrum. I myself am on the autism spectrum and that's what, initially attracted me to the company.
quality assurance in a nutshell is making sure that, products and software is not defective. That it functions the way it was intended to function.
Jeremy: [00:00:47] how would somebody know when they've, when they've met that goal?
Michael: [00:00:50] It all depends on the client's objectives. I guess. quality assurance testing is always about trying to mitigate risk. There's only so much testing that is realistic to do, you know, you could test forever and never release your product and that's not good for business. It's really about, you know, balancing, like how likely is it that the customer is going to encounter defect X, how much time and energy would be required to, to fix it?
Overall company reputation, impact, there's all sorts of different metrics. Uh, and every, every customer is unique really they, they get to set the pace,
Maxwell: [00:01:30] does the product work well? is the user experience frustrating or not? that's always a bar that I look for. One of the main things that we review in the different defects that we find is customer impact.
and how much of this is going to frustrate the customers. And when we're going through that analysis, is this cost effective or not. The client they'll determine it's worth, the cost of the, uh, quality assurance and of the fix of the software to make sure that that customer experience is smooth.
Jeremy: [00:02:03] When you talk to, to software developers, now, a lot of them are familiar with things like they need to test their code right. They have things like unit tests and integration tests that they're running regularly. where does quality assurance fit in with that? Like, is that considered a part of quality assurance is quality assurance something different?
Michael: [00:02:24] we try to partner with our clients, because the goal is the same, right. It's to release a quality product that's as free of defects, as, you know, as possible.
We have multiple clients that will let us know these are clients typically that we've worked with for a long time that have sort of established a rhythm. they'll let us know when they've got a new product in the pipeline and as soon as they have available, Uh, software requirements, documentations specs, user guides, that kind of thing.
They'll provide that to us, to be able to then plan. Okay. You know, what are these new features? Uh, what defects have been repaired since the last build or, you know, it all depends on what the actual product is. And we start preparing tests even before there may be, uh, A version of the software to test, you know, now that's more of a, what they call a waterfall approach where it's kind of a back and forth where, you know, the client preps the software, we test the software.
If there's something amiss, the client makes changes. Then they give us a new build. but we just as well, we work in, uh, iterative design or agile is a popular term, of course, where. We have embedded testers, that are, you know, on a daily basis, interacting with, uh, client developers to address, you know, to, to verify certain parts of the code as it's being developed.
Because of course the problem with waterfall is you find a defect and it, it could be deep in the code or some sort of linchpin aspect of the code. And then there's a lot of work to be done. To try to fix that sort of thing. Whereas, you know, embedded testers can identify a defect or, or even just like a friction point as early as possible.
And so then they don't have to, you know, tear it all down and start over and it's just, Oh, fix that, you know, while they're working on that part, basically.
Jeremy: [00:04:18] so I think there's two things you touched on there. One is. the ability to bring in QA early into the process. And if I understand correctly, what you were sort of describing is. even if you don't have a complete product yet, if you just have an idea of what you want to build, You were saying you start to generate test cases and it almost feels like you would be a part of generating the requirements generating. Like, what are the things that you need to build into your software before uh, the team that's building it necessarily knows themselves did that I sort of get that.
Maxwell: [00:04:55] I've been in projects that we've worked with the product from cradle to grave. a lot of them haven't gotten all the way to a grave yet, but, um, some of them, the amount of support that they're offering. It's reached that milestone in its life cycle, where they're no longer going to, um, address the defects in the same way.
They want to know that they're there. They want to know what exists. But then now there are new products that are being created, right? So we are, um, engaged in embedded testing, which is, which is testing, certain facets of the code actively, and making sure that it's, doing what it needs to do.
And we can make that quick patch on that code and put it out to market. And we're also doing that at earlier stages with, in, in earlier development where before it's an even, fully formed design concepts, we're offering suggestions, and recommending that, you know, this doesn't follow with the design strategy and the concept design.
so that part of embedded testing or unit testing, can be involved at earlier stages as well. For sure.
Michael: [00:06:08] Of course, those, you have to be very, careful you know, we wouldn't necessarily make blanket recommendations to a new client, a lot of the clients that we have, we have been with us for several years. And so. You know, you develop a rhythm, common vocabulary, you know, you know, which generally speaking, which, goals weigh more than other goals and things like that from, from client to client or even coder to coder.
it's only once we've really developed that. shared language that, you know, we would say by the way, you know, such and such as missing from blankety blank, say great example with a bunch of non words in it, but I think you get the picture.
Jeremy: [00:06:48] when you're first starting to work on a project, you don't know a whole lot about it, right? you're trying to, to understand how this product is supposed to work and, what does that process look like? Like what should a company be providing to you? What are the sorts of meetings or conversations you're having that, that sort of thing.
Michael: [00:07:08] we'll have an initial meeting with a handful of people from both sides and just sort of talk about both what we can bring to the project and what their objectives are. and, and, you know, the, the thing that they want us to test, if you will. And, if we reach an agreement that we want to move forward, then the next step would be like a product demo, basically, we would come together and we would start to fold in, you know, leads and some other analysts, you know, people that were, might be a good match for the project say, and we always ask, our clients.
And they're usually pretty accommodating. if we can record the meeting, you know, now everyone's meeting on Google meet and vir…
playlist_add
Mar 23, 2021
Scott Hanselman on What's .NET?
Scott is the Community Program Manager for the .NET team at Microsoft and the host of the Hanselminutes podcast.
This episode originally aired on Software Engineering Radio.
Personal Links and Projects:
* @shanselman
* Hanselminutes
* Blog
* YouTube Channel
Related Links:
* .NET (How to get started)
* What is .NET?
* Common Language Runtime (CLR) Overview
* NuGet (package manager)
* Techempower Benchmarks (ASP.NET core)
* Mono runtime (Cleanroom .NET implementation)
* Unity (Write games using C#)
* Xamarin (.NET Mobile apps)
* .NET nanoFramework (embedded devices / microcontrollers)
* .NET foundation
* .NET interactive
* Blazor (Client web apps with .NET)
* Single file deployment and executable
* All About Span: Exploring a New .NET Mainstay
* Virtual Desktop is what VR needs
* SE Radio 394 Chris McCord on Phoenix LiveView
Transcript:
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] Today I'm talking to Scott Hanselman. He's a partner program manager at Microsoft, the host of over 750 episodes of the Hanselminutes podcast. And he's got a YouTube channel. He's got a lot of interesting videos. one of the series I really enjoy is one called computer stuff they didn't teach you. You're all over the place. Scott, welcome to software engineering Radio.
Scott: [00:00:22] Thank you for having me. Yeah. I was an adjunct professor for a while and I realized that in all of my career choices and all of my volunteerism and outreach, it's just me trying to get back to teaching. So I just started a TikTok. So I'm like the old man on TikTok now. But it's turned out to be really great.
And I've got to engage with a bunch of people that I would never have found on any other social platform. So whether you find me on my podcast, my blog, which is almost 20 years old now, my YouTube or my TikTok or my Twitter, it's pretty much the same person. I'm a professional enthusiast, but that's all done in the spare time because my primary job is to own community for visual studio.
Jeremy: [00:01:02] That experience of being a teacher in so many ways is one of the big reasons why I wanted to have you on today, because I think in the videos and things you put out, you do a really good job of explaining concepts and just making them approachable. So I thought today we could talk a little bit about .NET and what that ecosystem is because I think there's a lot of people who they know .NET is a thing, they know it exists, but they don't really know what that means. So, maybe you could start with defining what is .NET?
Scott: [00:01:37] Sure, so Microsoft is historically not awesome at naming stuff. And, I joke about the idea that 20 years ago, Microsoft took over a top level domain, right? Thereby destroying my entire .org plan to take over the world. When they made the name .NET they were coming out of COM and C and C++ involved component object models.
And they had made a new runtime while Java was doing its thing in a new language and a new family of languages. And then they gave it a blanket name. So while, Java was one language on one runtime, which allowed us to get very clear and fairly understandable acronyms like JRE, Java, runtime, environment, and JDK... Microsoft came out of the gate with here's .NET and C# and VB and you know, COBOL.NET and this and that. And this is a multilanguage runtime. In fact, they called it a CLR, a common language runtime. So rather than saying here's C#, it's a thing. They said here's .NET. And it can run any one of N number of languages now.
The reality is that if you look over time, Java ended up being kind of a more generic runtime and people run all kinds of languages on the Java runtime. .NET now has C#, which I think is arguably first among equals as its language. Although we also have VB and F# as well as a number of niche languages, but the .NET larger envelope name as a marketing thing remains confusing. If they had just simply said, Hey, there's a thing called C# it probably would have cleared things up. So, yeah. Sorry. That was a bit of a long answer and it didn't actually get to the real answer.
Jeremy: [00:03:24] So, I mean, you had mentioned how there was this runtime that C# runs on top of. Is that the same as the JVM? Like the Java virtual machine?
Scott: [00:03:36] Right. So as with any VM, whether it be V8 or the JVM, when you could take C# and you compile it, you compile it to an intermediate language. We call it IL. Java folks would call it a byte code and it's basically a process or non-specific assembler. For lack of another word. If you looked at the code, you would see things like, you know, load, you know, load four byte string into, you know, pseudo register type of stuff.
And, um, you would not be able to identify that this came from C#. It would just look like this kind of middle place between apples and apple juice. It's kind of apple sauce. It's pre chewed, but not all the way. And then what's interesting about C# is that when you compile it into a DLL, a dynamic link library or Linux which is like a shared object where you compile it into an executable.
The executable contains that IL, but the executable doesn't know the processor it's going to run on. That's super interesting, because that means then I could go over to an ARM processor or an Intel x86 or an x64 or whatever, an iPhone theoretically. And then there's that last moment. And then that jitter that just-in-time compiler goes and takes it the last mile, that local runtime, in this case, the CLR, the common language runtime takes that IL.
Chews it finally up into apple juice. And then does the processor specific optimizations that it needs to do. And this is an oversimplification because the, the pipeline is quite long and pretty exquisite. In fact, for example, if you're on varying levels of processor on varying versions of x64, or on an AMD versus on a, uh, an Intel machine.
There's all kinds of optimizations you can do as well as switches that we can do as developers and config files to give hints about a particular machine. Is this a server machine? Is this a client machine? Does it, is it memory constrained? Uh, does it have 64 processors? Can we prep this stuff both with a naive JIT a naive just-in-time compilation, or then over time, learn, literally learning over the runtime cycle of the process and go, you know, I bet we could optimize this better then swap out in while it's running a new implementation so we can actually do a multi-layered JIT. So here's the, I want to start my application fast and run this for loop.
You know, this for loop's been running for a couple of thousand milliseconds and it's kind of not awesome. I bet you, we can do better then we do a second pass. Swap out the function table, drop a new one in, and now we're going even faster. So our jitter, particularly a 64 bit jitter is really quite extraordinary in that respect.
Jeremy: [00:06:29] That's pretty interesting because I think a question that a lot of people might have is what's, what's the reason for having this intermediary language and not compiling straight to machine code. And what it sounds like, what you're saying is that, it can actually at runtime figure out like how can I run things more efficiently based on what's being executed in the program.
Scott: [00:06:50] Right. So when you are running a strongly typed language that has the benefits and the speed of drawing type language. and you also choose to compile it to a processor specific representation. We, we usually as developers and deployers think about things in terms of architectures like this is for an arm processor, but is this a raspberry PI, is it an Android device you really want to get down to the stepping individual versions of like an Intel?
For example, I'm talking to you right now on an Intel. But it's a desktop class processor. That was the first one released many, many years ago. It doesn't have the same instruct…
playlist_add
Feb 25, 2021
Distributed Systems and Careers with Shubheksha Jalan
Shubheksha is a Software Engineer at Apple. She previously worked at Monzo and Microsoft.
Personal Links and Projects:
* @scribblingon
* Lessons learnt in year three as a software engineer
* Personal Site
* Systems Recipes
* Computers Illustrated
Other interviews about getting into open source:
* Code Newbie
* Software Engineering Daily
Related Links:
* Monzo Service Graph
* Go context
* An Illustrated Proof of the CAP theorem
* Apache Cassandra
* Distributed System Building Block: Flake Ids
* Protocol Buffers
* Go rpc
* Consul
* Envoy
* What is a Runbook?
* Error Budgets Explained
* Kubernetes
* Go by Example: Errors
Music by Crystal Cola.
Jeremy: This is Jeremy Jung and you're listening to software sessions. Today, I'm talking to Shubheksha Jalan about working with distributed systems, the go programming language and some of the lessons she's learned being a software engineer for the last three years. Previously, she worked as a backend engineer at Monzo Bank. And before that she was a software engineer at Microsoft.
Shubheksha, thank you so much for joining me today.
Shubheksha: Thank you so much for having me.
Jeremy: You picked up a lot of experience with distributed systems at Monzo bank. Could you start with explaining what a distributed system is?
Shubheksha: Yeah. So the main premise and the main difference, between like, a distributed and a non distributed system, is that a distributed system has more than one node. And when I say a node, I mean just computers, machines, servers. So it's basically a network of interconnected nodes that is being asked to behave as a singular entity and present itself as, as something that's not really disjoint.
And that's kind of where the trouble starts. something that you hear a lot of people who work with distributed systems say is that just don't do it unless you really really need to because like things spiral out of control very, very quickly. Because like, when you have a single machine, you don't have to think about like communication over the network.
You don't have to think about like distributing storage. You don't have to think about so many other things, whereas with like, when you have multiple machines, you have to think about coordination. You have to think about communication and like at what levels and like what sort of reliability you need and all of that.
So on and so forth. So it just gets super tricky.
Jeremy: Yeah. And when we talk about distributed systems, you mentioned about how it's having multiple nodes. And I think a more traditional type of application is where you would expect to have a load balancer and some web servers behind the load balancer and having those talk to a database and those that involves multiple nodes or multiple systems. But, I guess in that case, would you consider that to be a distributed system or not really?
Shubheksha: I think, yeah, like if something is going over the network and like, you have to sort of make those trade offs, I think I would still call it a distributed system. And like right now, like it's not just the big companies that are building and deploying distributed systems. It's pretty much everyone, like even small startups, especially like, because the cloud has become so dominant now, like the cloud is essentially a giant distributed system that we sort of take parts off and deploy our stuff, which is isolated from all of the other stuff that's also deployed on it. But like from the perspective of a cloud provider, it is a big big distributed system. And like, even when you, as a customer are using a cloud provider, you are, your code is deployed. You don't even know where, and it's still to you like if you spin up like multiple EC2 instances, for example, that is a distributed system.
Jeremy: It's almost not so much that the different nodes are doing different things I guess it's just the fact that you have to deal with the network at all. And that's where all of these additional troubles or, or challenges come in.
Shubheksha: Yeah, I think, yeah, that's probably a more accurate way to put it. Like, I can't really think of a system that you can like reasonably fit on a single machine right now. especially with the way, like we provision things, in the cloud. So yeah, by that definition, pretty much everything that we are building is a distributed system at some level.
Jeremy: Mmm you were saying earlier about how don't build one if you don't need to. But now it almost sounds like everything is one, right?
Shubheksha: Yeah. To some level. Yeah. Everything is one. Yeah.
Jeremy: When people first start getting started with having a system that involves the network, what are some common mistakes you see people make?
Shubheksha: Like a lot of people misunderstand the CAP theorem. The CAP theorem, is basically one of the most popular theorems in distributed systems literature and it states that like CAP stands for consistency, availability and network partitions.
And there's a lot of debate around like what those terms actually mean. So I don't want to go into that right now because that'll probably take up the rest of our time. CAP theorem states that you can only have two out of those three things at a given point of time.
And a lot of people sort of take that to heart and take it way too literally whereas there's a great blog post about this, which we should definitely link in the show notes, but which argues that like network partitions are not really optional. There's no way you can have a network that's a hundred percent reliable, like that's not humanly possible.
And there's also like some confusion around like what the terms, availability and consistency mean, And that's also like a huge source of debate and confusion in the community. And like a lot of people when they, when they sort of start working. They don't really understand what that means in what context, because those terms are very, very overloaded in tech in general.
And like one thing means like five different things depending on the context. So yeah, it can be really hard to get started.
Jeremy: Mm, and since it's a little difficult to pin down, what CAP means, I guess, for somebody who's, who's starting out. what would you suggest they they focus on to make sure that when they build something, that it works, I guess is one way to put it.
Shubheksha: I think that's, that's a very hard question to answer in like a generalized manner. It, it depends on your requirements and like, what is your end goal? What sort of like availability and reliability characteristics that you're looking for, from the system, for example, if it's a, if it's a system that's like sorting some critical data in that case, like consistency would be more valuable compared to variability, like it's a trade off.
Like everything else. So it really depends on the use case and yeah, like what you hope to achieve with the system.
Jeremy: Do you have a example from your experience where you, you chose those trade offs and could kind of walk us through that process?
Shubheksha: Uh, no, I don't think most people would have to deal with this day to day. And if you do, it's probably not a very good sign.
Like at Monzo, we had like a pretty unified platform. We did not have to like, think about this, at like, that level and go into it like super deep.
Jeremy: If I understand correctly there are engineers who build infrastructure or build tooling so that the software engineers or the backend software engineers don't have to worry about is this going to be eventually consistent or is this being partitioned instead you have some kind of API that's layered on top of that. Is that correct?
Shubheksha: Yeah. So you don't have to worry about like partitioning or anything like that. Like that's just taken care of. you just write a database schema, you deploy it and like data gets populated. You're not super worried about how that's done.
Jere…
playlist_add
Dec 17, 2020
React Authentication with Ryan Chenkie
Ryan is the author of Advanced React Security Patterns and Securing Angular Applications. He picked up his authentication expertise working at Auth0. Currently, he's a GraphQL developer advocate at Prisma.
Related Links:
* @ryanchenkie
* React Security
* Stop using JWTs for Sessions
* What are cookies and sessions?
* Learn how HTTP Cookies work
* JSON Web Token Introduction
* Refresh Tokens: When to Use Them and How They Interact with JWTs
* Critical Vulnerabilities in JSON Web Token Libraries
* RS256 vs HS256: What's the difference?
Music by Crystal Cola.
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] Today, I'm talking to Ryan Chenkie. He used to work for Auth0 and he has a new course out called advanced react security patterns.
I think authentication is something that often doesn't get included in tutorials, or if it's in there, there's a disclaimer that says, this isn't how you do it in production. So I thought it would be good to have Ryan on and maybe walk us through what are the different options for authentication and, how do we do it right?
Thanks for joining me today, Ryan.
Ryan: [00:00:30] Yeah, glad to be here. Thanks for inviting me.
Jeremy: [00:00:33] When I first started doing development, my experience was with server rendered applications. like building an app with rails or something like that.
Ryan: [00:00:42] Yep.
Jeremy: [00:00:42] And the type of authentication I was familiar with there was based on tokens and cookies and sessions. And I wonder if for people who aren't familiar, if you could just walk us through at sort of a basic level, how that approach works.
Ryan: [00:01:01] Sure. Yeah. so for those who have used the internet for, for a long time, the web, I should say for a long time, And who might be familiar with like the typical round trip application, which, which many of these still exist. A round trip application is one where every move you make through the application or the website is a trip to the server that's responsible for rendering the HTML for a page for you to see and on the server things are done. Data is looked up and HTML is constructed which is then sent back to the clients to display on the page.
That approach is in contrast to what we see quite often these days, which is like the single page application experience, where if we're writing a react or an angular or Vue application it's not always the case that we're doing full single page, but in a lot of cases, we're doing full single page applications where all of the JavaScript and HTML and CSS needed for the thing gets downloaded initially, or maybe in chunks as movements are made.
But let's say initially is downloaded and then interacting with data from the server is happening via XHR requests that that go to the server and you get some data back. So it's different than the typical round trip approach, In the roundtrip approach. And what's historically done, what is still very common to do and it's still a very legit way to do auth is you'll have your user login. So username and password go into the box. They hit submit. And if everything checks out, you'll have a cookie be sent back to the browser, which lines up via some kind of ID with a session that gets created on the server.
And a session is an in memory kind of piece of data. It could be in memory on the server. It can be, in some kind of like store, like a Redis store, for example, some kind of key value store, could be any of those things. And the session just points to a user record, or it holds some user data or something.
And it's purpose is that when subsequent requests go to the server, maybe for new data or for a new page or whatever, that cookie that was sent back when the user initially logged in is automatically going to go to the server. That's just by virtue of how browsers work cookies go to the place from which they came automatically.
That is how the browser behaves. The cookie will end up at the server. It will try to line itself up with a session that exists on the server. And if that is there then the user can be considered authenticated and they can get to the page they're looking for or get the data, the data that they're looking for.
That's the typical setup and it's still very common to do. It's a very valid approach. Even with single page applications. That's still a super valid approach and some people recommend that that's what you do, but there are other approaches too these days.
There are other ways to accomplish this kind of authentication thing that we need to do, which I suspect maybe you want to get into next, but you tell me if we want to, if we want to go there.
Jeremy: [00:04:03] You've mentioned how a lot of sites still use this cookie approach, this session approach, and yet I've noticed when you try to look up tutorials for working on react applications or for SPAs and things like that. I've actually found it uncommon, at least, it seems like usually people are talking about JSON web tokens that are not the cookie and session approach.
I wonder, if you had some thoughts on, on why that was.
Ryan: [00:04:37] Yeah, it's an interesting question. And I've thought a lot about this. I think what it comes down to is that especially for front end developers who might not be super interested in the backends, or maybe they're not concerned with it. Maybe they're not working on it, but they need to get some interaction with a backend going.
It's a little bit of a showstopper, perhaps, maybe not a showstopper. It's a hindrance. There are road blocks put in place if you start to introduce the concept of cookies and sessions because it then necessitates that they delve a little bit deep into the server. I think for front end developers who want to make UIs and want to make things look nice on the clients but they need some kind of way to do authentication.
If you go with the JSON web token path, it can be a lot easier to get done what you need to get done. If you use JSON web tokens maybe you're using some third party API or something. And they've got a way for you to get a token, to get access to the resources there.
It becomes really simple for you to retrieve that token based on some kind of authentication flow, and then send it back to that API on requests that you make from your application and all that's really needed there is for you to modify the way that requests go out. Maybe you're using fetch or axios or whatever you just need to modify those requests such that you've got a specific header going out in those requests. So it's not that bad of a time, but if you're dealing with cookies and sessions, then you've got to get into session management on the server. You've got to really get into the server concepts in some way if you're doing cookies and sessions.
I think it's just more attractive to use something like JSON web tokens, even though when I think when you get into, like, if you look at companies that have apps in production and, and like, especially like with organizations that have lots of applications, maybe internally, for example. And they're probably doing single sign-on. Maybe they've got tons of React applications, but if they're doing single sign-on, especially there's going to be some kind of cookie and session story going on there. So yeah, I think all that to say ease of use is probably a good reason why in tutorials, you don't see cookies and sessions, all that often.
Jeremy: [00:06:51] It's interesting that you bring up ease of use because, when you look at tutorials, a lot of times, it just makes this assumption that you're going to get this JSON web token. You're going to send it to the API to be authenticated. But there's a lot of other pieces missing.
I feel like to to make an actual application that's secure and going through your course for example, there's the concept of things like, the fact that with a JWT, a JSON web token, you can't, invalidate a token…
playlist_add
Dec 2, 2020
iOS Development with Timirah James
Timirah is an iOS developer, developer advocate, founder of the TechniGal LA meetup group, and instructor for O'Reilly and Coursera.
Related Links
* @timirahj
* Swift Optionals
* Stanford CS193p - Developing Apps for iOS
* Hacking with Swift
* Ray Wenderlich
* Swift
* Objective C
* Xcode
* Flutter
* Dart
Music by Crystal Cola.
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:03] Today I'm talking to Tamirah James. She's been an iOS developer for... how many years has it been?
Timirah: [00:00:09] Oh my goodness. Since I first started iOS, I want to say ooh (whispering) oh my gosh seven years.
Jeremy: [00:00:15] Seven years. Where did that time go?
Timirah: [00:00:17] My goodness. Oh yeah. Seven years. Wow.
Jeremy: [00:00:21] I think a lot of people listening have written software before, but maybe not for iOS. So I'm interested to hear what your experience is and how you think people should get into it.
Timirah: [00:00:31] Absolutely. So, yeah, and excuse me, we, we talked about my, before, before we, cut the podcast on, we were talking about how I have this 8:00 AM rasp in my voice (laughs) so you'll have to excuse the rasp. But, yeah, I, like we said, you know, seven years with iOS development. The great thing, and the crazy thing about, you know, my journey in iOS is I really went in with purpose and, intention, right. I went into mobile development knowing, that it was going to be something that was valuable not only into my career, but valuable to, society as a whole right. Valuable to the industry as a whole. So it, it goes all the way back to like, when I first started coding and I was like, I want to say I was 17 years old. and I started to get into web development and, I got bamboozled into getting into a, like a high school, like internship thing, to learn web design. and I loved it and that was my first introduction to coding. And I was like, Oh my goodness.
Like, this is amazing, like web development, web design. And then once I started to think about college and the route that I wanted to go, I was like, okay. Hm. There's so many other avenues. And so many other doors in this industry, like. You know what? I know that I want to pursue computer science but what, what is going to be my path?
So I started thinking about my career pathway immediately. I'm like, okay, going to college then what? And at that time, I think like we were just making the transition from like flip phones. And like the cameras and the, Oh my gosh. If you had the video phone, you call them the video phones, video phones.
And then the transition into like, Oh, now we're at, iPod touches. Now we're at iPhones now or at we're like, okay. Oh, wow. This is like the birth of the smartphone, the birth of the iPhone, and really seeing the transition. The phone being something that's way beyond just a communication device right now it's media, now it's entertainment, now it's education, it's finance, it's, all of these things. I always say like, you can leave your laptop at home, but if you leave your phone, You're like, Oh my gosh like, how am I going to function throughout the day? If I can build something for that, I can make a huge, huge impact so I really went into it with all, like, it was very much, something that I went with all intentions, all intentional purposes.
So I said, you know, after college I'm going to go right into mobile development. I really think that I will make the biggest impact there and build things that will stick with people and people will spend time with, and people enjoy, and will live with users. I fell in love with the idea of the evolution of the phone and mobile development.
So went to college, ended up dropping out in that first year, computer science, for a lot of reasons, one of them being that the university I went to wasn't a, tech school, so to speak, computer science was not one of their pillars. You know, one of their like, Oh, this is something that we're focusing and we have resources and we have a gateways for mentorship and internships.
Like they were just like, Hey, we got computer science is here, you know? and yeah, so I went and I took that opportunity. And it just, wasn't what I thought it would be. I didn't have any support coming in, you know, just learning, computer science and, you know, there were so many different aspects to it.
It was culture, there were, cultural aspects. There was just the support in terms of what was being taught. and I just felt like the more I was in it, the more behind I felt, I felt like it was being pushed out. and yeah, so I left school and I was like, okay, where do I, where do I kind of go from here?
And again, I knew that I still wanted to do mobile development. So I continued that journey, online there were, there were, maybe some coding, boot camps, that were really underground and just getting started or getting their feet wet and trying to figure that out but none that were really visible like that and really like, Oh, this is an option. So didn't have any like bootcamp or coding school, situation.
But I had so many resources online. I can remember my primary source of education at that time, along with like, everything like Ray Wenderlich, and, tree house, coursera, which is crazy cause I'm teaching courses for Coursera now. And, in addition to that, my primary source was Stanford's iOS development course, which they were offering all the lectures for free.
And I was upset cause I was like, wait a minute, the school I was going to. It was like this private university, you know, and here I could have a Stanford education, you know, in which I kind of ended up with it, so, okay. I have a Stanford education in iOS development (laughs) . so yeah, I kind of continued on from there and really went cold turkey.
I know that like, it's hard for a lot of people to adapt to like being self-taught in really the meaning of being self-taught right, where I don't really have a physical community or any source of like mentorship around me saying, Hey, you should learn this. Or you should learn that.
I didn't even know where to look for that kind of guidance. I didn't really have, a boot camp that was promising me a roadmap, a career ladder. what the important tech stacks for mobile development were. all that groundwork. Like I really did it myself and, I had the support of my mom.
I didn't work another job. Like I was living with my mom. and she's always been single parent so one paycheck. And, It was really, maybe less than a year before I, started into my professional, career and got my first role landed my first role as an iOS engineer.
So, anything you want to learn, you want to make sure that you do the work right? Outside of, even if you're at a coding bootcamp, you have to want to learn it for yourself. and then you have to look at the benefits, what, what are the benefits of learning?
Something like this. iOS development. Okay. You know, that it has a very strong Apple developer community around it, and then Apple, the entity itself, Apple, really prides itself on making sure that they give an abundance of resources to developers, you know, via, you know, th the WWDC, you know, which is their yearly conference that they do.
And they make sure that they are. flooding developers with new things and, new information and, you know, hands-on training, in the best ways that they can. So there is a lot of resources out there. and just in terms of iOS development itself, the benefit of iOS. again, it, iOS can be very niche and that's something that probably turns people away.
They're like, Why iOS development, you know, Android you have a plethora of different devices. you have, I guess, more scalability in terms of who's able to access, your applications, right? You think about people in other countries like the iOS device is probably the number one device in the United States.
But outside of here, like, you know, I've been to…
playlist_add
Nov 18, 2020
Object Relational Mappers with Julie Lerman
Related Links:
* @julielerman
* The Data Farm (Julie's blog)
* Entity Framework
* Dapper
* Automapper
* Pluralsight Courses
This episode was originally posted on Software Engineering Radio.
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] Today I'm talking to Julie Lerman. She's a frequent conference speaker, an independent consultant and a Pluralsight course author. Today we're going to talk about her experience working on ORMs and Entity Framework.
Julie, welcome to software engineering radio.
Julie: [00:00:16] Hey, Jeremy. Thanks so much for having me.
Jeremy: [00:00:18] For those who aren't familiar with ORMs what are they and why do we need them?
Julie: [00:00:23] The first thing is the definition so ORM stands for object relational mapper. It's a software idea and implementation in many aspects for taking the concepts that we describe as classes and transforming them into the structure of a relational database. So you can get the data in and out easily.
So the ORM takes care of that mapping and the transformation. So you don't have to worry about writing SQL. You don't have to worry about getting structured results from a database that are in rows and columns and then transforming them back into object instances. So the ORMs do that for you.
Jeremy: [00:01:15] Some of the most popular languages used are object oriented. Why do we continue to store our data in a relational database when it's so different from our application code?
Julie: [00:01:26] There's certainly a lot of reasons for relational databases compared to document databases, object databases. Relational databases for their structure and normalization and tuning, and it's different kinds of storage needs I think than when you're storing documents. Sometimes I think more about getting the data back out. Finding data.
It's one thing to be able to store it in a way that makes sense. But then when you need to pull data together and create relationships that aren't naturally in those documents unless you have prepared and designed something like a document database for every possible scenario.
There's also the whole concept of event sourcing where if you're just storing the events then you can actually re-persist that data in different structures so that it's easier for the various ways you might access it. Also, relational databases have been around for a long time and it's interesting that even with the popularity and extreme power of these other kinds of nonrelational databases, the NoSQL databases, relational databases are still, I can't say the source off the top of my head but I've used them in conference slides. They update their data monthly, but I can see these graphs where it shows that it was still about 70% of systems out there are using relational databases and in a lot of cases, so much legacy data, too, right. That's all going to be in relational databases.
Jeremy: [00:03:18] Relational databases, they give us the ability to request just the data we need that matches a certain condition or we can combine different parts of our data and get just a specific thing that we need.
If we were dealing with a bunch of arrays of objects or documents it might be harder to query for a specific thing does that sort of match...?
Julie: [00:03:45] Yeah, especially that unplanned data access and. Another interesting thing. And it's one of those things that I think you have to like, stop and think about it, to realize the truth in it, which is that most systems, most of the work you're doing the database is reading the database much more than creating and storing data.
That's the bigger problem. Getting the data back out and having the flexibility to do weird things whereas something like a document database depending on how you split it up and keys and everything, it's just more designed. A relational database is a little easier to get at that weird stuff.
Jeremy: [00:04:37] You mentioned ad hoc queries. So with a relational database you can store all your information and then you can decide later what queries or information you want to get out, whereas you had hinted at with a document database you have to think upfront about what queries you want to make. Could you elaborate a little bit on that?
Julie: [00:05:02] I don't want to be generalizing too much, because there's all kinds of other factors that might come in especially when talking about huge amounts of data for like machine learning and things like that. There's pros and cons to both of them.
And like I mentioned with event sourcing ways to have your cake and eat it too. When I look for example at documentation for Azure CosmosDB, that's the document database that I have the most familiarity with. One of the most important documents is that upfront design and that design bleeds into how you're modeling your data in your application so that you can store it fluidly into the document database. So it's really, really important. Now I don't want to conflate this with the beauty of a system like document database, how that aligns so much more nicely for persistence.
And most of your getting data in and getting data out when we're talking about domain driven design. Where you don't want to worry about your persistence, just focus on the domain and then we can figure out how to get the data in and out right? We've got patterns for that.
But it is interesting if something like a document database more naturally aligns with your objects right? So that flows nicely in. However, it's still really important to be considerate of how you're breaking up that data in the way you store it. What your graphs are going to be. Maybe it's easy to get it in this way. But then what about when you're getting it out? What about different perspectives that you have? I want to be really careful about, comparing and contrasting the document DB versus relational DB. I want to stop at some level of that because there's always going to be debate and argument about that.
However one of the nice things about an ORM is it does take away some of that pain. That we normally would have when we're writing applications and writing that data access layer where we have to say, okay, I want this. Now I have to figure out the SQL statement, or call a stored procedure, or however I'm going to do it.
Whether I'm getting data in or getting data out and then I have to transform my objects into the SQL right? Or I get data back. And then I have to read through that data and instantiate objects and stuff, all the values into those objects. That's the stuff that the ORM can...
Repetitive. Like Bull (bleep). Right. Writing all that stuff. So that's what the ORMs do. I think the next big question that comes up then is yeah, but my SQL is always going to be better than some generic thing that an ORM is going to build for me. Right? The general advice for that is for many cases what the ORM doesthe performance will be just perfectly fine. And then there's going to be the cases where the performance isn't good. So then you can use your own stored procedures, use your views.
But a lot of the ORMs, certainly the one I focus on, which is Microsoft's Entity Framework, has the ability to also interact with stored procedures and views and do mappings to views and things like that. So people don't realize that, right. But maybe 80% of the SQL that entity framework is going to write whether it's for queries or for pushing data into the database. Maybe 80% of that is perfectly fine. And then 20% of that, do performance testing, go yeah. I can do better. I can do better and fix those up.
Jeremy: [00:09:27] I want to step back a little and walk through some of the features of ORMs that you had mentioned. Uh, one of them was not necessarily having to write SQL so you have some alternative query language that the ORM is providing. So what are some of the benefits of, that?
Like why would somebody not just jump straight to SQL…
playlist_add
Nov 3, 2020
Fixing a Broken Development Process
John Doran is the CTO of Phorest, an application for managing salons and spas.
We discuss:
- Transitioning a desktop application to a SaaS
- Struggling with outages and performance problems
- Moving away from relying on a single person for deployment
- Building a continuous integration pipeline
- Health monitoring for services
- The benefits of docker
- Using AWS managed services like Aurora and ECS
This episode originally aired on Software Engineering Radio.
Transcript
Jeremy: [00:00:00] Today I have John Doran with me. John is the director of engineering at Phorest, a Dublin based SAAS company, that processes appointments for the hair and beauty industry. He previously worked as a technical lead at Travelport digital, where he supported major airlines and hotel chains with their mobile platforms.
I'll be speaking with John about the early days of their business, the challenges they faced while scaling and how they were able to reshape their processes and team to overcome these challenges. John, welcome to software engineering radio.
John: [00:00:29] Hey Jeremy, thanks so much for having me.
Jeremy: [00:00:31] The first thing I'd like to discuss is the early days of forest to just give the listeners a little bit of background. What type of product is Phorest?
John: [00:00:40] Sure. So forest is essentially, um, It's a salon software focused in the hair and beauty industry. And it didn't actually start off as that back in 2003, it was actually a messaging service actually built by a few students and Trinity college. One of which was his name was Ronan.
Percevel. Ronan is actually our current CEO. So that in 2003, that messaging service was supporting, um, nightclubs, dentists, various small businesses around Dublin, and the guys were finding it really hard to get some traction in, in those phase different industries. So Ronan actually went and worked as a, as a hair receptionist in a salon.
And what he learned from that was that through using messaging on the platform that they were able to actually increase revenue for salons and actually get more money in the tills, which was hugely powerful thing. So from there, they were able to refocus on the, on that particular industry, they built supplementary features and a product around that messaging service.
So in 2004, it became a kind of a fully fledged appointment book. And from there then they, they integrated that appointment book with the messaging service. So by 2006, then I guess you could classify phorest as a full salon software. So it had things like stock take, financial reporting, and staff rostering. That's fully based salon software system was pretty popular in Ireland and actually by between 2006 and 2008, they became the number one in the industry in Ireland. So what that meant was, you know, the majority of salons in Ireland were running on, on the phorest platform and that was actually an on-premise system. So all the data would have been stored locally in the hair salon.
And there was no backend,
Jeremy: [00:02:30] just so I understand correctly. So you say it was running on premise. It was an appointment system. So is this where somebody would come into the salon and make an appointment and they would enter it into a local computer and it would be just stored there?
John: [00:02:46] Exactly. So, so what Ronan figured out throughout his time, working in the salon that by actually sending customers text messages, to remind them about their appointments really helped cut down the no-show rates, meaning that customers did turn up for their appointments when they were due and meaning that the staff members didn't have to sit around, waiting for customers to walk in.
So as Phorest I guess, as a company developed. We, we moved into building extra features around that core system, which is an appointment book, which manages the day-to-day, uh, rows of a hairstylist. So we built, uh, email and marketing retention tools around that. Okay. I guess a really important point about Phorest's history is when the recession hit in 2008 in Ireland, we, uh, moved into the UK.
So as we were kind of the number one provider in Ireland, we felt that, uh, when the recession hit that we needed to move into the UK, but being on premise meant there was a lot of friction actually installing the system into the salons. So in 2011, they actually took a small seed round to build out, I guess, the cloud backend.
Well, once the kind of cloud backend was built, it took about a year to get it off the ground and released. Um, and as the company kind of gained traction in the UK, they, they migrated all of their premise customers onto the cloud solution.
Jeremy: [00:04:07] I guess you would say that when it was on premise, a lot of the engineering effort or the support effort was probably in keeping the software, working for your customers and just addressing technical issues or questions and things like that. And that was probably taking a lot of your time. Is that correct?
John: [00:04:25] Precisely the, the team was quite small. So we had five engineers who were essentially building it at the cloud backend. And one engineer who was maintaining that Delphi on premise application.
So what was happening was our CEO Ronan was actually the product owner at that time. And the guys were making pretty drastic and kind of quickfire decisions in terms of features being added to the product based on, you know, getting a certain customer in that really needed to pay the bills. And some of those decisions, uh, I guess, made the product a bit more complex, uh, as a group, but it certainly was, it was a big improvement from the on-premise solution.
Jeremy: [00:05:03] Hmm. So the on-premise solution you said was written in Delphi, is that correct?
John: [00:05:08] Yeah,
Jeremy: [00:05:09] when it was first started, was it just a single developer?
John: [00:05:13] Exactly. Yeah. So it was, it was literally, uh, put together by some, some outsourcers and a single developer managing it. There was no, there was no real in-house developers.
It was, you know, a little bit of turnover there. But when that small seed round came in with the guys put that together, the foundations of the cloud-based backend, which was a, a Java kind of classic, uh, n-tiered application with web socket to update the appointment screen. If anything changed on the backend.
And, um, you, you would kind of consider it a majestic monolith as such
Jeremy: [00:05:44] When you started the cloud solution. Were you maintaining both systems simultaneously?
John: [00:05:49] Yeah, so, um, for a full year, that goes where we're building out that backend. And at the same time, there was a one guy who was, who was literally maintaining, fixing bugs on that, that Delphi application.
And just to kind of give you an example. Um, one of the guys who was actually working on support, he actually went and taught himself SQL and he used to, to tunnel into the salons at nighttime to fix any database issues. And, um,
Jeremy: [00:06:17] Oh, wow.
John: [00:06:17] Yeah. So it was, it was, you know, hardcore stuff. Um, another big thing about not being a cloud-based and, and one of the big reasons we needed to become cloud based was we, you know, as, as people move online and, you know, it's, it's quite common to book, you know, your cinema or some something else online, but, um, Ronan could see that trend coming for online bookings, uh, and we needed to be cloud-based to build, to build out that online booking system.
And just to kind of give you an idea of the scale, like last year, we, we would have processed about over 2 billion euros worth of transactions to the system. So it's really, it's really growing. And, um, you know, it's huge, huge scale at the moment by that, I guess looking, looking back at the past, the guys would have built a great robust system getting us to that 10,000 salon mark, particularly in the UK, but that would have been the poin…
playlist_add
Oct 7, 2020
Building Maps using Leaflet
We cover:
* Choosing Leaflet vs other mapping libraries
* Sources for mapping layers
* Using GeoJSON to store data
* Raster vs vector data
* Working with live positions such as car data
* Picking a database with geospatial queries
* Using frontend frameworks with Leaflet
* Leaflet plugins
* Desktop vs Mobile
* His work on the Leaflet-Geoman plugin
Related Links
* Leaflet
* Leaflet-Geoman
* GeoJSON
* Geoman
* Mapbox
This episode was originally on Software Engineering Radio.
Transcript
You can help edit this transcript on GitHub.
Jeremy: Today, I'm speaking with Sumit Kumar. Sumit is the head of engineering at Share Now, which is previously car2go. He's also the creator of an open source plugin called leaflet-geoman, which provides drawing tools for the leaflet mapping library.
I'll be speaking with Sumit about his experience working with leaflet and how developers can build mapping applications with it. Sumit, welcome to software engineering radio.…
playlist_add
Sep 22, 2020
WebAssembly on the Server with Krustlet
Taylor Thomas is an Engineer at Azure, the core maintainer of the Kubernetes Package Manager Helm, and a member of the Krustlet team.
Timestamps
* [00:55] - Kubernetes
* [07:37] - WebAssembly
* [12:06] - WebAssembly Runtimes and WASI Specification
* [15:42] - WebAssembly vs Containers vs Native Binaries
* [25:11] - Krustlet and the case for writing it in Rust
* [30:52] - Missing APIs in WASI
* [33:38] - Wascc vs Wasmtime runtimes
* [38:15] - Rust ecosystem for Kubernetes and WebAssembly
* [40:23] - Comparing other languages to Rust
* [45:09] - Rust learning curve, experiences as a beginner
* [53:16] - Next steps for Krustlet and WebAssembly
Related Links
* @_oftaylor
* Krustlet
* Kubernetes
* Open Container Initiative
* WebAssembly
* WASI
* Wasmtime
* waSCC
* WebAssembly meets Kubernetes with Krustlet
* Introducing Krustlet, the WebAssembly Kubelet
* Kubernetes: A Rusty Friendship
* The Safety Boat: Kubernetes and Rust
* A Heaping Hel…
playlist_add
Sep 9, 2020
Building the Lucky Web Framework in Crystal with Paul Smith
Paul Smith is a Software Engineer at GitHub and the creator of the Lucky web framework. He previously worked at heroku and thoughtbot and has experience building applications using Rails and Phoenix. He's also the creator of the Bamboo e-mail package and the co-creator of the ExMachina test data package for Elixir.
We discuss:
* The tradeoffs of object oriented and functional programming
* How a lack of compile time guarantees slow down ruby and elixir development
* Creating conversational error messages
* Ways fast languages can change how you write applications
* Writing templates with Crystal instead of HTML
* Choosing what to include in a web framework
* The Crystal community and ecosystem
Related Links:
* @paulcsmith
* The Crystal programming language
* The Lucky web framework
* HTML2Lucky
* AlpineJS
This episode originally aired on Software Engineering Radio.
Transcript:
You can help edit this transcript on GitHub.
Jeremy: Today I'm talking with Pa…
playlist_add
Aug 26, 2020
Life after JPEG with Henri Helvetica
Henri is a frequent conference speaker and organizer of the Toronto Web Performance and JAMStack meetups.
We discuss:
* Managing images with features like lazy loading and the picture tag
* Handling varying network conditions on mobile
* Making designers a part of the performance conversation
* The WebP image format that could replace JPEG and PNG
* Ways the GIF can be an MP4 in disguise
* How lighthouse has given websites a visible target for performance
* What we can learn from "lite" news sites
Conference Talks
* A Decade of Disciplined Delivery
* Shape Of The Web
* Moving Pictures: A Snapshot At the Future of Web Media
Related Links
* @HenriHelvetica
* Cloudinary
* Picture tag
* Network Information API
* WebP
* Responsive images done right: a guide to picture and srcset
* Use srcset to automatically choose the right image
* Mozilla: Improving JPEG Image Encoding (Mozilla explains why they want to stick with JPEG in 2014)
* The Great JPEG…
playlist_add
Aug 12, 2020
The battle for your privacy on the web with Pete Snyder
Pete is the senior security researcher at Brave Software and the co-chair of the W3C Privacy Interest Group.
We discuss:
* The differences between academic research and product development
* How websites track us with cookies, fingerprinting, and other techniques
* The surprising amount of data your browser gives up without a permission prompt
* What features should go in the browser vs being native only
* The confusion behind what incognito or private modes do
* The role of EasyList and the underappreciated people behind it
* Building tools like PageGraph to identify and rewrite tracking code
* Replacing resources at page load to preserve privacy without breaking websites
* Developing web standards at the W3C while preserving privacy
* Brave's plan to fund websites with ads instead of paywalls while preserving user privacy
* Getting involved in privacy and web standards
Related Links
* @pes10k
* Personal Site
* Privacy Interest Group (PING)
* W3C Priv…
playlist_add
Jul 29, 2020
Functional Programming in Enterprise Applications with Vladimir Khorikov
Vlad is a Pluralsight course creator and the author of Unit Testing: Principles, Practices, and Patterns.
We discuss:
* Immutability
* Error handling
* Avoiding null
* Preventing invalid state
* Updating existing applications
This episode originally aired on Software Engineering Radio.
Related Links
* @vkhorikov
* Enterprise Craftsmanship
* Is Entity the same as Value Object?
* Combining ASP.NET Core validation attributes with Value Objects
* Error handling: Exception or Result?
* Applying Functional Principles in C#
* F# for Fun and Profit
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:05] Hey, this is Jeremy Jung for Software Engineering Radio. Today. I'm talking with Vladimir Khorikov. Vladimir is the author of the book Unit Testing: Principles, Practices and Patterns he's a Microsoft MVP, and he's the author of many Pluralsight courses including Applying Functional Principles in C#, and today we're going to be talking about fu…
playlist_add
Jul 15, 2020
Open Source Onboarding with Brian Douglas
Brian is a Senior Developer Advocate at GitHub and was previously a Developer Advocate at Netlify.
We discuss:
* Unintentional gatekeeping
* Formal onboarding for your projects
* The value of discord communities for newcomers
* Streaming issue triage and programming on twitch
* How Open Sauced helps developers get involved with open source
Related Links
* @bdougieYO
* Open Sauced
* ExpressJS Triager Guide
* GraphiQL
* Babel's contributing guide (Gives suggestions on familiarizing yourself with codebase)
* Webpack's funding page
* SE Unlocked episode with Dan Abramov
* Explore GitHub
* Changelog Nightly
* Code Triage
* Figma
* Discord
Twitch Streams
* bdougieYO
* jlengstorf
* Noopkat
Music by Crystal Cola: 12:30 AM / Orion
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] This is Jeremy Jung and today I'm talking to Brian Douglas, he's a senior developer advocate at GitHub, the host of JAMstack radio and the creator of open…
playlist_add
Jul 1, 2020
Senior engineers and baby managers with Lauren Tan
Lauren is a Software Engineer on the React Organization's Web Core team at Facebook and was previously an Engineering Manager at Netflix.
We discuss:
* Being empowered to say "no" as a senior engineer
* Straddling the line between engineer and manager
* The programmer's midlife crisis
* Resisting the urge to use clever abstractions
If you enjoyed this discussion with Lauren, be sure to check out her episode on the Changelog.
Music by Crystal Cola: 12:30 AM / Orion
Related Links
* @sugarpirate_
* Personal Site
* The Engineer / Manager Pendulum
* Should I Become a Tech Lead?
* Does it Spark Joy?
* Changelog Episode - Engineer to Manager and Back Again
* Dan Abramov's Redux twitter post
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:00] Hey, this is Jeremy. Usually when software developers are talking career progression, it moves in the direction from being a software engineer to becoming an engineering manager. And today I'm talking…
playlist_add
Jun 17, 2020
Learning in Public with Swyx
Swyx is a senior developer advocate at AWS, an instructor at Egghead, and the author of The Coding Career Playbook.
We discuss:
* Getting help without having a big following
* Remixing and summarizing what others create
* Creating Friendcatchers
* Betting on technologies
* His new book "The Coding Career Playbook"
Music by Crystal Cola: 12:30 AM / Orion
Related Links
* @swyx
* Personal Site
* The Coding Career Playbook
* 1% rule
* Lindy Effect
* Learn in Public
* The Ultimate Hack for Learning in Public
* The Day I Became a Software Engineer
* Developer's Guide to Tech Strategy
* Every Public Engineering Career Ladder
* Friendcatchers
* React Typescript Cheatsheet
* Steve Yegge's Google Platforms Rant
* DynamoDB Book
* Egghead
* Frontend Masters
* How I Write Backends
Transcript
You can help edit this transcript on GitHub.
Jeremy: I did a computer science bachelor's.
Swyx: [00:00:45] Nice.
Jeremy: [00:00:46] It's interesting seeing…
playlist_add
Jun 3, 2020
Writing for Software Developers with Philip Kiely
Philip Kiely is the author of Writing for Software Developers and has written for companies like Smashing Magazine, CSS-Tricks, and Twilio.
We discuss:
* Doing research beyond the first page of search results
* Writing e-mails people will read
* The "get it done" and "learning" modes of readers
* Making articles easily skimmable
* Long form articles vs Stack Overflow
* Promoting and launching a book
* Borrowing the reputation of others
Related Links:
* Writing for Software Developers
* Personal Site
* @philip_kiely
* Stripe documentation example (Complete code sample with switchable frontends, backends, and walkthrough as you scroll)
* Go by Example (Straightforward samples readers can copy/paste)
* Tailwind UI (Sustains Tailwind CSS open source project by providing prebuilt components)
Music by Crystal Cola: 12:30 AM / Orion
Transcript
You can help edit this transcript on GitHub.
Jeremy: [00:00:35] This episode, I'm talking to Phillip Kiely. He's…
playlist_add
May 19, 2020
Localizing and Porting Japanese Games with Sara Leen
Sara Leen is a localization programmer for XSEED Games on titles like Ys, Trails in the Sky, and Corpse Party. She got her start reverse engineering and fan translating games.
We discuss:
* What makes games different
* How games store and encode text
* Rewriting Corpse Party (and not being able to run it for a year!)
* Porting and modernizing games
* Reverse engineering raw assembly
This episode originally aired on Software Engineering Radio.
Related Links:
* @SaraJLeen
* Personal Site
* Corpse Party PC Programming Blog
* Trails in the Sky Second Chapter Localization Blog 5
* Mojibake (Garbled text when text is decoded using the wrong encoding)
* Shift JIS (Japanese character encoding used in older games)
* Hot Soup Processor (Obscure programming language used for Corpse Party)
* XSEED Games
Music by Crystal Cola: 12:30 AM / VHS Skyline
Transcript
You can help edit the transcript on GitHub.
Jeremy: Hey, this is Jeremy Jung. This episode, I'm talki…
playlist_add
May 7, 2020
Creating Tuple using WebRTC with Spencer Dixon
Spencer Dixon is the CTO and cofounder of Tuple, a pair programming application for remote developers.
We discuss:
* How WebRTC works
* Capturing audio and video
* Choosing a video codec
* NAT traversal
* Choosing a native application over Electron
* Diving into C++ and MacOS development
* Getting expert help
This episode was originally on Software Engineering Radio.
Related Links:
* @spencercdixon
* Tuple
* WebRTC
* Introduction to WebRTC Protocols
* WebRTC Mozilla Docs
* WebRTC Hacks
* Discuss WebRTC Google Group
* WebRTC by Dr Alex
* Cosmo Software
* High Performance Browser Networking
playlist_add
Apr 23, 2020
Building Indie Hackers with Courtland Allen
Courtland Allen is the founder of Indie Hackers, a community for people who want to start bootstrapped and profitable businesses. It was acquired by Stripe in 2017.
We discuss:
* Why a SPA was the wrong choice
* Caching strategies
* Using firebase and algolia
* Fighting spam
* Why he hasn't hired another engineer
* Focusing on the right problems
* Being a part of Stripe
Related Links:
* Indie Hackers
* @csallen
* Stripe
* How to Build a Life You Love by Quitting Everything Else with Lynne Tye of Key Values (One of Courtland's favorite podcast episodes)
* Ember (SPA framework)
* Ember fastboot (Server Side Rendering)
* Firebase (Authentication provider and NoSQL database)
* Algolia (Provides search for posts)
* Render (Web Host)
* Dribbble (Site to find design inspiration)
* Egghead (Developer video courses, got started selling zip files of videos to mailing lists)
* Balsamiq (Wireframing tool, added inspirational quotes to their loadin…
playlist_add
Apr 8, 2020
League of Legends Gameplay Engineering with Iris Zhang
Iris Zhang is a gameplay engineer at Riot Games on the League of Legends Champions Engineering team. She previously worked on backend services at Microsoft.
We discuss:
* Working at Microsoft and Riot Games
* Finding a role and team that fits you
* Backend services vs gameplay engineering
* Building features, testing, and debugging gameplay
* Using internal tools to create game logic
Related Links:
* Personal Site
* @riotnyanbun
* Clean Code (Book used by Microsoft team)
* Spring Framework (Java web framework used by League of Legends)
* Chef (Deployment tool used at Riot)
* Hazelcast (Cache that Riot Games switched to)
* What it's like to work on League of Legends
* Sylas (Champion that can steal ultimates)
* Clash (Public facing mode worked on by backend team)
Music by Crystal Cola: 12:30 AM / Orion
playlist_add
Mar 25, 2020
Async Programming and TCP Sockets in C# with Stephen Cleary
Stephen Cleary is the author of the Concurrency in C# Cookbook and a Microsoft MVP. He has also written many blog posts on asynchronous programming.
We discuss:
* Why he calls manual thread creation legacy code
* Using Async/Await and the Task Parallel Library instead of Threads
* APIs to avoid when writing concurrent applications
* Why you shouldn't write TCP Sockets
* Continuously reading from a socket to detect errors
* Building state machines to manage socket connections
Related Links:
* @aSteveCleary
* Getting Started with Async/Await
* TCP/IP Sockets
* There is no Thread
* Concurrency in C# Cookbook
Music by Crystal Cola:
* Intro: 12:30 AM
* Outro: Orion
playlist_add
Mar 11, 2020
How I write backends with Federico Pereiro
Federico has been writing backends for web applications since 2012 and is the co-founder and chef of alto;code. He wrote a post on GitHub named "How I write backends" that summarizes his process.
We discuss:
* His current stack
* Redis as a primary data store
* Reducing the number of layers in your software
* How duplicating input validation makes code harder to understand
* Integration tests over unit tests
* Minimizing dependencies
* Why you should never normalize alerts
Federico Pereiro
* Personal Site
* How I write backends
* Our company
* ac;pic, our pictures application
* ac;tools, our backend services
Related Links
Fred Brooks & The Mythical Man Month (conceptual integrity)
Steve Yegge - Code's worst enemy
Steve Yegge - Platforms rant (no backdoors, all services talking through the wire as if they were external actors)
Book of Hook - Suffer no jankiness
Taiichi Ohno & the Toyota Production System
Auto-activation in software
playlist_add
Feb 26, 2020
From agency to startup with Noah Labhart
Noah is the CTO and cofounder of Veryable, an on-demand marketplace for manufacturing, logistics, and warehousing labor.
He's also the host of the Code Story podcast where tech leaders reflect on the path they took to create their products.
We talk about:
* Leaving the corporate world
* How poor estimation and scoping nearly sunk his agency
* Why bad software is worse than no software
* Hiring for an agency vs a startup
* Validating ideas and finding your first customers
Noah Labhart
* Personal Site
* LinkedIn
Other Links
* Code Story (Noah's podcast)
* Veryable (Current startup)
* Touchtap (Mobile app agency being wound down)
* Alcon (Previous employer)
* Dev Mountain Bootcamp (Bootcamp that Noah hired from)
Music by Crystal Cola
playlist_add
Feb 12, 2020
The good parts of AWS with Daniel Vassallo
Daniel is the co-author of the book "The Good Parts of AWS" and previously worked at AWS on the CloudWatch team. He left last year after over 8 years at Amazon to work on his own projects.
He's currently working on an end-to-end encrypted user database SaaS called Userbase. Daniel is also openly sharing his experiences building an audience, writing a book, and building Userbase on twitter.
We talk about:
* Why AWS has so many services
* His default AWS stack and how he chose it (Dynamo, SQS, S3 and EC2)
* Why he uses EC2 over ECS or EBS
* Why services like RDS and ElastiCache aren't in his book
* The difference between SQS and Kinesis
* Why AWS will probably never build a Heroku-like service
* The future of AWS
Daniel Vassallo
* Personal Site
* @dvassallo
Other Links
* The Good Parts of AWS
* Userbase
* Only Intrinsic Motivation Lasts
playlist_add
Jan 29, 2020
A decade long retrospective with Ben Orenstein
Ben is the CEO of Tuple, a pair programming application for remote developers.
He currently co-hosts The Art of Product with Derrick Reimer.
We talk about:
* His first crazy programming job
* Why you should speak at conferences
* The trade-offs of remote work
* Why great coworkers should be the #1 priority for new developers
* How these are "the good old days" of Tuple
* Ben's favorite smash bros character
* ...and much more!
Ben Orenstein
* Personal Site
* @r00k
Podcasts
* The Art of Product
* Giant Robots (Ben hosted this podcast until episode 240)
Other Links
* Tuple (Remote pair programming application)
* Refactoring Rails (Ben's video course)
* How to talk to developers (Fantastic talk for anyone giving presentations)
* Upcase (Rails, vim, and tmux video tutorials)
playlist_add
Jan 15, 2020
Bringing GeoCities Back with Kyle Drake
Kyle is the creator of Neocities a free web hosting site that encourages people to build creative personal websites in the spirit of GeoCities. He's currently working on restorativland where people interested in the history of the web can discover websites originally hosted at places like GeoCities and Myspace Music.
Kyle Drake
* Personal Site
* @kyledrake
Projects
* Neocities
* restorativland
Other Links
* Yahoo! Geocities - Wikipedia
* What is BGP?
* What is Anycast?
* Vultr (Neocities hosting provider)
Timestamps
* [00:00:50] What GeoCities was
* [00:06:45] Why the old web failed
* [00:15:06] Reasons to create Neocities
* [00:21:04] Fighting phishing, spam, and DMCA takedowns
* [00:27:17] Purchasing an IPv4 address block and building an Anycast CDN
* [00:43:28] Why create your own CDN? (Takedown requests come directly to you, reduced chances of hosting provider shutting you down)
* [00:51:09] The costs of running a CDN ($130 a month)
* [01:07…
playlist_add
Jan 1, 2020
Rebuilding Fathom Analytics on Serverless Infrastructure with Jack Ellis
Jack Ellis
* Personal Site
* @JackEllis
Fathom Analytics
* Fathom Analytics (SAAS version, Affiliate link with $10 discount)
* Fathom Lite (Open-source, original Golang version)
* We rebuilt Fathom Analytics from the ground up and moved to Laravel Vapor
* How we built a GDPR compliant website analytics platform without using cookies
Laravel
* Laravel (PHP web framework)
* Laravel Vapor (Serverless provisioning and deployment tool)
Hosting Providers
* Digital Ocean (Host for Open-source version)
* Heroku (Host for 1st rewrite)
* AWS (Host for 2nd rewrite)
AWS Services Used
* ElastiCache (Redis)
* Elastic Load Balancing (Handles web requests and triggers Lambda functions)
* Relational Database Service (MySQL)
* Simple Queue Service (Message Queue)
* Lambda (Run functions without managing a server)
Other Links
* Things you should never do (Post Jack mentions on never rewriting software)
Timestamps
* [00:00:58] What's Fathom Ana…
playlist_add
Dec 19, 2019
Creating Static Sites in Rust with Vincent Prouillet
Vincent is the creator of Zola (Formerly Gutenburg), a Static Site Generator built with Rust and Tera, a Jinja2-like template engine.
If you create a site with Zola, Vincent would appreciate you adding your site to the EXAMPLES file in the repository.
You can also take a look at the source for this website which is currently built with Zola.
Vincent Prouillet
* Personal Site
* @20100Prouillet
Zola
* Zola Website
* Zola Forum
Tools/Crates used by Zola
* pulldown-cmark (Markdown)
* syntec (Syntax highlighting using Sublime Text definitions)
* rayon (Parallel computation)
* heaptrack (Memory Profiler)
Static Site Hosts
* Github Pages
* Netlify
Crates for Web Applications
* jsonwebtoken
* Bcrypt
* Validator
Compiled Template Engines
* askama
* maud
* horrowshow
Runtime Template Engines
* Tera (Jinja2-like HTML template engine)
* ramhorns
* rust-mustache
Static Site Generators
* Hugo
* Jekyll
* Pelican
Other li…
playlist_add
Dec 6, 2019
Load Balancing and HAProxy with Daniel Corbett
Daniel is the Director of Product at HAProxy Technologies.
This episode originally aired on Software Engineering Radio.
Theme music is 12:30 AM by Crystal Cola.
Links
* HAProxy Community Edition
* HAProxy Technologies Blog
* @danielcorbett_
* Keepalived
* Linux Virtual Server
* Nginx
* Envoy
Timestamps and Transcript are coming soon.
playlist_add
Nov 20, 2019
Choosing the Right Job with Cassidy Williams
Cassidy is a developer and instructor at React Training and the Director of Outreach at cKeys, a Seattle based organization that promotes learning electronics through mechanical keyboards. She previously worked at Amazon, CodePen, L4 Digital, Clarifai, and Venmo. However, she's probably best known for promoting diversity in tech, creating cool mechanical keyboards, and making memes.
Cassidy
Personal Website
@cassidoo
Current Work
React Training
cKeys
Keyboards
Follow your dreams (literally): How I designed and launched the Official Scrabble Keyboard
Astrolokeys (Collaboration with Amy Wibowo)
Notes App
Bear
Resources for new conference speakers
@CallbackWomen
You've got this!
Theme music is 12:30 AM by Crystal Cola.
Timestamps
* [00:36] Organizing and completing side projects
* [05:08] Choosing and quitting jobs
* [09:03] Joining React Training
* [12:31] Why Amazon was a poor fit and figuring out what's important
* [17:46] Leaving a company with a smooth transition…
playlist_add
Nov 6, 2019
Building Scalable Systems Safely in Ruby with Samuel Williams
Samuel is a member of the Ruby core team. He's working on making it safer and easier to write scalable applications in Ruby.
Conference Talks:
Fibers are the Right Solution
The Journey to One Million
Posts:
Asynchronous Ruby
Fibers Are the Right Solution
Early Hints and HTTP/2 Push with Falcon
2019 Ruby Association Grant
Source with comments on why the Global VM Lock exists
Ruby gems:
Async
Falcon
Contact:
@ioquatix
Samuel's website
Timestamps:
* 0:51 - What's concurrency? What's parallelism?
* 5:49 - Piping commands between Unix processes provides easy parallelism
* 6:58 - Some types of applications abstract out threads/processes,
* 9:27 - Many Ruby gems have thread safety issues
* 10:44 - The CRuby Global VM Lock hides thread safety issues
* 11:24 - The problems with threads and shared mutable state
* 13:58 - Examples of mutexes causing problems in Ruby gems.
* 19:09 - What a deadlock is and how it causes problems
* 19:51 - Running separate processes to get pa…
playlist_add
Oct 24, 2019
How the Ruby Runtime Works with Aaron Patterson
Aaron is on both the ruby and rails core teams. He's best known for making puns, teaching others, and his contributions to the internals of ruby. Lately he's been focusing on a compacting garbage collector for ruby.
This episode originally aired on Software Engineering Radio.
Timestamps:
* 00:40 - What Aaron likes about Ruby
* 04:43 - Interpreted vs Compiled
* 07:00 - Why the ruby interpreter is written in C
* 11:00 - Other good languages to write virtual machines?
* 15:20 - Moving from an Interpreter (MRI) to Virtual Machine (YARV)
* 18:50 - Why there's no manual compilation step in Ruby
* 23:28 - Why compile to bytecode instead of directly to machine code?
* 26:34 - Stack based vs Register based VM
* 28:00 - Differences between Core and Standard Library
* 29:46 - Do you program more in ruby or C as a member of the ruby/rails core teams?
* 30:30 - The Global Interpreter Lock (GIL / GVL)
* 37:40 - Concurrency options in Ruby
* 45:55 - Just in Time Compilati…
playlist_add
Oct 10, 2019
Pod Hunt and Side Projects with Mubashar Iqbal
Mubs is an amazingly prolific creator. He's built 85 side projects which are all listed on his website and was Product Hunt's Maker of the Year in 2016. His output is inspiring and he offers great advice on how to approach building side projects of your own.
Mubashar Iqbal
* Personal Site
* @mubashariqbal
* Projects
Projects
* Pod Hunt
* Hacker News Day
* Will Robots Take My Job?
Pod Hunt Stack
* Laravel
* Laravel Forge
* Tailwind CSS
* VueJS
* MySQL
Timestamps
* 01:14 - What's Pod Hunt?
* 03:42 - How are people using Pod Hunt?
* 08:42 - Why Pod Hunt isn't a native app yet
* 11:25 - How long to build the prototype?
* 15:50 - Pod Hunt's Stack
* 16:55 - Why Pod Hunt isn't a Single Page Application
* 22:18 - No CDN yet
* 23:24 - MySQL as the datastore
* 24:24 - Laravel Forge for hosting
* 28:13 - What's Hacker News Day?
* 34:06 - Choose a side project that solves your own problem
* 40:43 - The difference between projects for fun vs mon…
playlist_add
Sep 27, 2019
How to Teach Programming with Felienne
Felienne is an associate professor at Leiden University who brings a unique perspective on programming education backed by scientific research. She also runs the Programming Education Research Lab (PERL) in order to study the best ways to teach programming.
Keynote at Strange Loop
* How to Teach Programming (and other things?)
Related Research Papers
* How is Programming Taught at Code Clubs
* The Effect of Reading Code Aloud on Comprehension: An Empirical Study with School Students
* Code Phonology
* Why Minimal Guidance During Instruction Does Not Work
* Cognitive Architecture and Instructional Design: 20 Years Later
* Papers by Brianna Morrison
Felienne
* Blog
* Twitter
* Publications
* Software Engineering Radio Podcast
Bonus
* St. Louis City Museum
Timestamps
* 00:56 - Spreadsheets as programming
* 04:57 - When do you build software vs use what's already there?
* 10:14 - Direct instruction vs independent learning
* 20:28 - How should you s…
playlist_add
Sep 16, 2019
How HTTP Works with Julia Evans
Julia Evans is best known for her zines and blog posts that break down technical topics in a friendly way. She has written educational material on everything from Linux system calls to working with managers.
She joins us to talk about what she learned while writing her latest zine: HTTP: Learn your browser's language.
Timestamps:
* 0:50 - Why write a zine about HTTP?
* 1:21 - What's a header that could break your site?
* 2:50 - What does HTTP look like?
* 5:58 - What headers are most important?
* 8:39 - Response Codes
* 12:26 - Authentication
* 14:57 - Cookies
* 18:37 - Using browser development tools
* 19:46 - Caching and CDNs
* 25:46 - Referrer Header and Hotlinking images
* 27:34 - Resuming file downloads
* 30:00 - URLs
* 32:11 - Why webpages show different languages
* 34:34 - Same Origin Policy / CORS
* 43:42 - Compression / GZIP
* 45:58 - Intermediate Programming Education
* 49:35 - Picking topics for blogs and zines
* 57:10 - Picking an audi…
playlist_add
Sep 13, 2019
Rust in Production with Armin Ronacher
Topics:
* Deciding when to use Rust
* Concurrency in Rust
* When to create a separate service
* Introducing Rust at Sentry
* Challenges of writing Python modules in Rust
* Creating Symbolicator, a Rust web service that processes debug files
* Using Actix to create Symbolicator
* Why Rust doesn't need a Django or Rails equivalent
* Concerns about the stability of the Rust ecosystem and the lack of shared solutions
* What's missing in the Rust ecosystem
* Why developers need better debugging tools
If you're interested in helping Armin build an open source debugging community, reach out to him via e-mail or twitter.
This episode is part of the Rustacean Station feed. Check it out if you're interested in Rust podcasts.
Links:
* Armin's Twitter
* Armin's Blog
* Sentry
* Actix
* Rocket
* Building Sentry: Symbolicator
* Symbolicator
* Semaphore
* Milksnake
* Wasmer
* Existential Types
* Tokio Tower
* RFC to add Backtraces to standard error…
playlist_add