Podcasts about pragmatic bookshelf

Ever wondered why a seasoned software engineer would transition into becoming an author? Meet our guest for today, Andrew Atkinson, a software veteran who is about to launch his book focusing on database operations for Rails developers. Andrew's rich 15-year career as a software engineer has culminated in this exciting new venture, as he peels back the layers of database operations, specifically in the Ruby on Rails landscape. In our lively discussion, we delve into the heart of relational databases - comparing the merits of Postgres and MongoDB, and when to use one over the other. Andrew demystifies the assumption that one necessarily needs multiple databases, discussing how Postgres could be potentially used as a catch-all solution. Not stopping there, we journey through the thorny terrain of data synchronization challenges across multiple databases and the treasures of transactional consistency. Finally, we discuss the importance of performance optimization in Rails applications and the role of database internals. Andrew dispenses nuggets of wisdom on how to optimize Rails performance and database queries. We also talk about the benefits of strict loading in active record - a key player in avoiding the notorious n plus one query problem. Wrapping up our discussion, Andrew guides us to the Pragmatic Bookshelf where his upcoming book awaits all keen Rails developers. So, lean in and listen, as we uncover layers of database operations that could dramatically level-up your projects.Honeybadger Honeybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Sean Moriarity, creator of the Axon deep learning framework, co-creator of the Nx library, and author of Machine Learning in Elixir and Genetic Algorithms in Elixir, published by the Pragmatic Bookshelf, speaks with SE Radio host Gavin Henry about what deep learning (neural networks) means today. Using a practical example with deep learning for fraud detection, they explore what Axon is and why it was created. Moriarity describes why the Beam is ideal for machine learning, and why he dislikes the term “neural network.” They discuss the need for deep learning, its history, how it offers a good fit for many of today's complex problems, where it shines and when not to use it. Moriarity goes into depth on a range of topics, including how to get datasets in shape, supervised and unsupervised learning, feed-forward neural networks, Nx.serving, decision trees, gradient descent, linear regression, logistic regression, support vector machines, and random forests. The episode considers what a model looks like, what training is, labeling, classification, regression tasks, hardware resources needed, EXGBoost, Jax, PyIgnite, and Explorer. Finally, they look at what's involved in the ongoing lifecycle or operational side of Axon once a workflow is put into production, so you can safely back it all up and feed in new data. Brought to you by IEEE Computer Society and IEEE Software magazine. This episode sponsored by Miro.

David was the chief software architect and director of engineering at Stitch Fix. He's also the author of a number of books including Sustainable Web Development with Ruby on Rails and most recently Ruby on Rails Background Jobs with Sidekiq. He talks about how he made decisions while working with a medium sized team (~200 developers) at Stitch Fix. The audio quality for the first 19 minutes is not great but the correct microphones turn on right after that. Recorded at RubyConf 2023 in San Diego. A few topics covered: Ruby's origins at Stitch Fix Thoughts on Go Choosing technology and cloud services Moving off heroku Building a platform team Where Ruby and Rails fit in today The role of books and how different people learn Large Language Model's effects on technical content Related Links David's Blog Mastodon Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today. I want to share another conversation from RubyConf San Diego. This time it's with David Copeland. He was a chief software architect and director of engineering at stitch fix. And at the start of the conversation, you're going to hear about why he decided to write the book, sustainable web development with Ruby on rails. Unfortunately, you're also going to notice the sound quality isn't too good. We had some technical difficulties. But once you hit the 20 minute mark of the recording, the mics are going to kick in. It's going to sound way better. So I hope you stick with it. Enjoy. Ruby at Stitch Fix [00:00:35] David: Stitch Fix was a Rails shop. I had done a lot of Rails and learned a lot of things that worked and didn't work, at least in that situation. And so I started writing them down and I was like, I should probably make this more than just a document that I keep, you know, privately on my computer. Uh, so that's, you know, kind of, kind of where the genesis of that came from and just tried to, write everything down that I thought what worked, what didn't work. Uh, if you're in a situation like me. Working on a product, with a medium sized, uh, team, then I think the lessons in there will be useful, at least some of them. Um, and I've been trying to keep it up over, over the years. I think the first version came out a couple years ago, so I've been trying to make sure it's always up to date with the latest stuff and, and Rails and based on my experience and all that. [00:01:20] Jeremy: So it's interesting that you mention, medium sized team because, during the, the keynote, just a few moments ago, Matz the creator of Ruby was talking about how like, Oh, Rails is really suitable for this, this one person team, right? Small, small team. And, uh, he was like, you're not Google. So like, don't worry about, right. Can you scale to that level? Yeah. Um, and, and I wonder like when you talk about medium size or medium scale, like what are, what are we talking? [00:01:49] David: I think probably under 200 developers, I would say. because when I left Stitch Fix, it was closing in on that number of developers. And so it becomes, you know, hard to... You can kind of know who everybody is, or at least the names sound familiar of everybody. But beyond that, it's just, it's just really hard. But a lot of it was like, I don't have experience at like a thousand developer company. I have no idea what that's like, but I definitely know that Rails can work for like... 200 ish people how you can make it work basically. yeah. [00:02:21] Jeremy: The decision to use Rails, I'm assuming that was made before you joined? [00:02:26] David: Yeah, the, um, the CTO of Stitch Fix, he had come in to clean up a mess made by contractors, as often happens. They had used Django, which is like the Python version of Rails. And he, the CTO, he was more familiar with Rails. So the first two developers he hired, also familiar with Rails. There wasn't a lot to maintain with the Django app, so they were like, let's just start fresh, fresh with Rails. yeah, but it's funny because a lot of the code in that Rails app was, like, transliterated from Python. So you could, it would, it looked like the strangest Ruby code in the world because it was basically, there was no test. So they were like, let's just write the Ruby version of this Python just so we know it works. but obviously that didn't, didn't last forever, so. [00:03:07] Jeremy: So, so what's an example of a, of a tell? Where you're looking at the code and you're like, oh, this is clearly, it came from Python. [00:03:15] David: You'd see like, very, very explicit, right? Like Python, there's a lot of like single line things. very like, this sounds like a dig, but it's very simple looking code. Like, like I don't know Python, but I was able to change this Django app. And I had to, I could look at it and you can figure out immediately how it works. Cause there's. Not much to it. There's nothing fancy. So, like, this, this Ruby code, there was nothing fancy. You'd be like, well, maybe they should have memoized that, or maybe they should have taken that into another class, or you could have done this with a hash or something like that. So there was, like, none of that. It was just, like, really basic, plain code like you would see in any beginning programming language kind of thing. Which is at least nice. You can understand it. but you probably wouldn't have written it that way at first in Ruby. Thoughts on Go [00:04:05] Jeremy: Yeah, that's, that's interesting because, uh, people sometimes talk about the Go programming language and how it looks, I don't know if simple is the right word, but it's something where you look at the code and even if you don't necessarily understand Go, it's relatively straightforward. Yeah. I wonder what your thoughts are on that being a strength versus that being, like, [00:04:25] David: Yeah, so at Stitch Fix at one point we had a pro, we were moving off of Heroku and we were going to, basically build a deployment platform using ECS on AWS. And so the deployment platform was a Rails app and we built a command line tool using Ruby. And it was fine, but it was a very complicated command line tool and it was very slow. And so one of the developers was like, I'm going to rewrite it in Go. I was like, ugh, you know, because I just was not a big fan. So he rewrote it in Go. It was a bazillion times faster. And then I was like, okay, I'm going to add, I'll add a feature to it. It was extremely easy. Like, it's just like what you said. I looked at it, like, I don't know anything about Go. I know what is happening here. I can copy and paste this and change things and make it work for what I want to do. And it did work. And it was, it was pretty easy. so there's that, I mean, aesthetically it's pretty ugly and it's, I, I. I can't really defend that as a real reason to not use it, but it is kind of gross. I did do Go, I did a small project in Go after Stitch Fix, and there's this vibe in Go about like, don't create abstractions. I don't know where I got that from, but every Go I look at, I'm like we should make an abstraction for this, but it's just not the vibe. They just don't like doing that. They like it all written out. And I see the value because you can look at the code and know what it does and you don't have to chase abstractions anywhere. But. I felt like I was copying and pasting a lot of, a lot of things. Um, so I don't know. I mean, the, the team at Stitch Fix that did this like command line app in go, they're the platform team. And so their job isn't to write like web apps all day, every day. There's kind of in and out of all kinds of things. They have to try to figure out something that they don't understand quickly to debug a problem. And so I can see the value of something like go if that's your job, right? You want to go in and see what the issue is. Figure it out and be done and you're not going to necessarily develop deep expertise and whatever that thing is that you're kind of jumping into. Day to day though, I don't know. I think it would make me kind of sad. (laughs) [00:06:18] Jeremy: So, so when you say it would make you kind of sad, I mean, what, what about it? Is it, I mean, you mentioned that there's a lot of copy and pasting, so maybe there's code duplication, but are there specific things where you're like, oh, I just don't? [00:06:31] David: Yeah, so I had done a lot of Java in my past life and it felt very much like that. Where like, like the Go library for making an HTTP call for like, I want to call some web service. It's got every feature you could ever want. Everything is tweakable. You can really, you can see why it's designed that way. To dial in some performance issue or solve some really esoteric thing. It's there. But the problem is if you just want to get an JSON, it's just like huge production. And I felt like that's all I really want to do and it's just not making it very easy. And it just felt very, very cumbersome. I think that having to declare types also is a little bit of a weird mindset because, I mean, I like to make types in Ruby, I like to make classes, but I also like to just use hashes and stuff to figure it out. And then maybe I'll make a class if I figure it out, but Go, you can't. You have to have a class, you have to have a type, you have to think all that ahead of time, and it just, I'm not used to working that way, so it felt, I mean, I guess I could get used to it, but I just didn't warm up to that sort of style of working, so it just felt like I was just kind of fighting with the vibe of the language, kind of. Yeah, [00:07:40] Jeremy: so it's more of the vibe or the feel where you're writing it and you're like this seems a little too... Explicit. I feel like I have to be too verbose. It just doesn't feel natural for me to write this. [00:07:53] David: Right, it's not optimized for what in my mind is the obvious case. And maybe that's not the obvious case for the people that write Go programs. But for me, like, I just want to like get this endpoint and get the JSON back as a map. Not any easier than any other case, right? Whereas like in Ruby, right? And you can, I think if you include net HTTP, you can just type get. And it will just return whatever that is. Like, that's amazing. It's optimized for what I think is a very common use case. So it makes me feel really productive. It makes me feel pretty good. And if that doesn't work out long term, I can always use something more complicated. But I'm not required to dig into the NetHttp library just to do what in my mind is something very simple. [00:08:37] Jeremy: Yeah, I think that's something I've noticed myself in working with Ruby. I mean, you have the standard library that's very... Comprehensive and the API surface is such that, like you said there, when you're trying to do common tasks, a lot of times they have a call you make and it kind of does the thing you expected or hoped for. [00:08:56] David: Yeah, yeah. It's kind of, I mean, it's that whole optimized for programmer happiness thing. Like it does. That is the vibe of Ruby and it seems like that is still the way things are. And, you know, I, I suppose if I had a different mindset, I mean, because I work with developers who did not like using Ruby or Rails. They loved using Go or Java. And I, I guess there's probably some psychological analysis we could do about their background and history and mindset that makes that make sense. But, to me, I don't know. It's, it's nice when it's pleasant. And Ruby seems pleasant. (laughs) Choosing Technology [00:09:27] Jeremy: as a... Software Architect, or as a CTO, when, when you're choosing technology, what are some of the things you look at in terms of, you know? [00:09:38] David: Yeah, I mean, I think, like, it's a weird criteria, but I think what is something that the team is capable of executing with? Because, like, most, right, most programming languages all kind of do the same thing. Like, you can kind of get most stuff done in most common popular programming languages. So, it's probably not... It's not true that if you pick the wrong language, you can't build the app. Like, that's probably not really the case. At least for like a web app or something. so it's more like, what is the team that's here to do it? What are they comfortable and capable of doing? I worked on a project with... It was a mix of like junior engineers who knew JavaScript, and then some senior engineers from Google. And for whatever reason someone had chosen a Rails app and none of them were comfortable or really yet competent with doing Ruby on Rails and they just all hated it and like it didn't work very well. Um, and so even though, yes, Rails is a good choice for doing stuff for that team at that moment. Not a good choice. Right. So I think you have to go in and like, what, what are we going to be able to execute on so that when the business wants us to do something, we just do it. And we don't complain and we don't say, Oh, well we can't because this technology that we chose, blah, blah, blah. Like you don't ever want to say that if possible. So I think that's. That's kind of the, the top thing. I think second would be how widely supported is it? Like you don't want to be the cutting edge user that's finding all the bugs in something really. Like you want to use something that's stable. Postgres, MySQL, like those work, those are fine. The bugs have been sorted out for most common use cases. Some super fancy edge database, I don't know if I'd want to be doing, doing that you know? Choosing cloud services [00:11:15] Jeremy: How do you feel about the cloud specific services and databases? Like are you comfortable saying like, oh, I'm going to use... Google Cloud, BigQuery. Yeah. [00:11:27] David: That sort of thing. I think it would kind of fall under the same criteria that I was just, just saying like, so with AWS it's interesting 'cause when we moved from Heroku to AWS by EC2 RDS, their database thing, uh, S3, those have been around for years, probably those are gonna work, but they always introduce new things. Like we, we use RabbitMQ and AWS came out with. Some, I forget what it was, it was a queuing service similar to Rabbit. We were like, Oh, maybe we should switch to that. But it was clear that they weren't really ready to support it. So. Yeah, so we didn't, we didn't switch to that. So I, you gotta try to read the tea leaves of the provider to see are they committed to, to supporting this thing or is this there to get some enterprise client to move into the cloud. And then the idea is to move off of that transitional thing into what they do support. And it's hard to get a clear answer from them too. So it takes a little bit of research to figure out, Are they going to support this or not? Because that's what you don't want. To move everything into some very proprietary cloud system and have them sunset it and say, Oh yeah, now you've got to switch again. Uh, that kind of sucks. So, it's a little trickier. [00:12:41] Jeremy: And what kind of questions or research do you do? Is it purely a function of this thing has existed for X number of years so I feel okay? [00:12:52] David: I mean, it's kind of similar to looking at like some gem you're going to add to your project, right? So you'll, you'll look at how often does it change? Is it being updated? Uh, what is the documentation? Does it look like someone really cared about the documentation? Does the documentation look updated? Are there issues with it that are being addressed or, or not? Um, so those are good signals. I think, talking to other practitioners too can be good. Like if you've got someone who's experienced. You can say, hey, do you know anybody back channeling through, like, everybody knows somebody that works at AWS, you can probably try to get something there. at Stitch Fix, we had an enterprise support contract, and so your account manager will sometimes give you good information if you ask. Again, it's a, they're not going to come out and say, don't use this product that we have, but they might communicate that in a subtle way. So you have to triangulate from all these sources to try to. to try to figure out what, what you want to do. [00:13:50] Jeremy: Yeah, it kind of makes me wish that there was a, a site like, maybe not quite like, can I use, right? Can I use, you can see like, oh, can I use this in my browser? Is there, uh, like an AWS or a Google Cloud? Can I trust this? Can I trust this? Yeah. Is this, is this solid or not? [00:14:04] David: Right, totally. It's like, there's that, that site where you, it has all the Apple products and it says whether or not you should buy it because one may or may not be coming out or they may be getting rid of it. Like, yeah, that would... For cloud services, that would be, that would be nice. [00:14:16] Jeremy: Yeah, yeah. That's like the Mac Buyer's Guide. And then we, we need the, uh, the technology. Yeah. Maybe not buyers. Cloud Provider Buyer's Guide, yeah. I guess we are buyers. [00:14:25] David: Yeah, yeah, totally, totally. [00:14:27] Jeremy: it's interesting that you, you mentioned how you want to see that, okay, this thing is mature. I think it's going to stick around because, I, interviewed, someone who worked on, I believe it was the CloudWatch team. Okay. Daniel Vassalo, yeah. so he left AWS, uh, after I think about 10 years, and then he wrote a book called, uh, The Good Parts of AWS. Oh! And, if you read his book, most of the services he says to use are the ones that are, like, old. Yeah. He's, he's basically saying, like, S3, you know you're good. Yeah. Right? but then all these, if you look at the AWS webpage, they have who knows, I don't know how many hundreds of services. Yeah. He's, he's kind of like I worked there and I would not use, you know, all these new services. 'cause I myself, I don't trust [00:15:14] David: it yet. Right. And so, and they're working there? Yeah, they're working there. Yeah. No. One of the VPs at Stitch Fix had worked on Google Cloud and so when we were doing this transition from Heroku, he was like, we are not using Google Cloud. I was like, really? He's like AWS is far ahead of the game. Do not use Google Cloud. I was like, all right, I don't need any more info. You work there. You said don't. I'm gonna believe you. So [00:15:36] Jeremy: what, what was his did he have like a core point? [00:15:39] David: Um, so he never really had anything bad to say about Google per se. Like I think he enjoyed his time there and I think he thought highly of who he worked with and what he worked on and that sort of thing. But his, where he was coming from was like AWS was so far ahead. of Google on anything that we would use, he was like, there's, there's really no advantage to, to doing it. AWS is a known quantity, right? it's probably still the case. It's like, you know, you've heard the nobody ever got fired for using IBM or using Microsoft or whatever the thing is. Like, I think that's, that was kind of the vibe. And he was like, moving all of our infrastructure right before we're going to go public. This is a serious business. We should just use something that we know will work. And he was like, I know this will work. I'm not confident about. Google, uh, for our use case. So we shouldn't, we shouldn't risk it. So I was like, okay, I trust you because I didn't know anything about any of that stuff at the time. I knew Heroku and that was it. So, yeah. [00:16:34] Jeremy: I don't know if it's good or bad, but like you said, AWS seems to be the default choice. Yeah. And I mean, there's people who use Azure. I assume it's mostly primarily Microsoft. Yeah. And then there's Google Cloud. It's not really clear why you would pick it, unless there was a specific service or something that only they had. [00:16:55] David: Yeah, yeah. Or you're invested in Google, you know, you want to keep everything there. I mean, I don't know. I haven't really been at that level to make that kind of decision, and I would probably choose AWS for the reasons discussed, but, yeah. Moving off Heroku [00:17:10] Jeremy: And then, so at Stitch Fix, you said you moved off of Heroku [00:17:16] David: yeah. Yeah, so we were heavy into Heroku. I think that we were told that at one point we had the biggest Heroku Postgres database on their platform. Not a good place to be, right? You never want to be the biggest customer person, usually. but the problem we were facing was essentially we were going to go public. And to do that, you're under all the scrutiny. about many things, including the IT systems and the security around there. So, like, by default, a Postgres, a Heroku Postgres database is, like, on the internet. It's only secured by the password. all their services are on the internet. So, not, not ideal. they were developing their private cloud service at that time. And so that would have given us, in theory, on paper, it would have solved all of our problems. And we liked Heroku and we liked the developer experience. It was great. but... Heroku private spaces, it was still early. There's a lot of limitations that when they explained why those limitations, they were reasonable. And if we had. started from scratch on Heroku Private Spaces. It probably would have worked great, but we hadn't. So we just couldn't make it work. So we were like, okay, we're going to have to move to AWS so that everything can be basically off the internet. Like our public website needs to be on the internet and that's kind of it. So we need to, so that's basically was the, was the impetus for that. but it's too bad because I love Heroku. It was great. I mean, they were, they were a great partner. They were great. I think if Stitch Fix had started life a year later, Private Spaces. Now it's, it's, it's way different than it was then. Cause it's been, it's a mature product now, so we could have easily done that, but you know, the timing didn't work out, unfortunately. [00:18:50] Jeremy: And that was a compliance thing to, [00:18:53] David: Yeah. And compliance is weird cause they don't tell you what to do, but they give you some parameters that you need to meet. And so one of them is like how you control access. So, so going public, the compliance is around the financial data and. Ensuring that the financial data is accurate. So a lot of the systems at Stichfix were storing the financial data. We, you know, the warehouse management system was custom made. Uh, all the credit card processing was all done, like it was all in some databases that we had running in Heroku. And so those needed to be subject to stricter security than we could achieve with just a single password that we just had to remember to rotate when someone like left the team. So that was, you know, the kind of, the kind of impetus for, for all of that. [00:19:35] Jeremy: when you were using Heroku, Salesforce would have already owned it then. Did you, did you get any sense that you weren't really sure about the future of the platform while you're on it or, [00:19:45] David: At that time, no, it seemed like they were still innovating. So like, Heroku has a Redis product now. They didn't at the time we wish that they did. They told us they're working on it, but it wasn't ready. We didn't like using the third parties. Kafka was not a thing. We very much were interested in that. We would have totally used it if it was there. So they were still. Like doing bigger innovations then, then it seems like they are now. I don't know. It's weird. Like they're still there. They still make money, I assume for Salesforce. So it doesn't feel like they're going away, but they're not innovating at the pace that they were kind of back in the day. [00:20:20] Jeremy: it used to feel like when somebody's asking, I want to host a Rails app. Then you would say like, well, use Heroku because it's basically the easiest to get started. It's a known quantity and it's, it's expensive, but, it seemed for, for most people, it was worth it. and then now if I talk to people, it's like. Not what people suggest anymore. [00:20:40] David: Yeah, because there's, there's actual competitors. It's crazy to me that there was no competitors for years, and now there's like, Render and Fly. io seem to be the two popular alternatives. Um, I doubt they're any cheaper, honestly, but... You get a sense, right, that they're still innovating, still building those platforms, and they can build with, you know, all of the knowledge of what has come before them, and do things differently that might, that might help. So, I still use Heroku for personal things just because I know it, and I, you know, sometimes you don't feel like learning a new thing when you just want to get something done, but, yeah, I, I don't know if we were starting again, I don't know, maybe I'd look into those things. They, they seem like they're getting pretty mature and. Heroku's resting on its laurels, still. [00:21:26] Jeremy: I guess I never quite the mindset, right? Where you You have a platform that's doing really well and people really like it and you acquire it and then it just It seems like you would want to keep it rolling, right? (laughs) [00:21:38] David: Yeah, it's, it is wild, I mean, I guess... Why did you, what was Salesforce thinking they were going to get? Uh, who knows maybe the person at Salesforce that really wanted to purchase it isn't there. And so no one at Salesforce cares about it. I mean, there's all these weird company politics that like, who knows what's going on and you could speculate. all day. What's interesting is like, there's definitely some people in the Ruby community who work there and still are working there. And that's like a little bit of a canary for me. I'm like, all right, well, if that person's still working there, that person seems like they're on the level and, and, and, and seems pretty good. They're still working there. It, it's gotta be still a cool place to be or still doing something, something good. But, yeah, I don't know. I would, I would love to know what was going on in all the Salesforce meetings about acquiring that, how to manage it. What are their plans for it? I would love to know that stuff. [00:22:29] Jeremy: maybe you had some experience with this at Stitch Fix But I've heard with Heroku some of their support staff at least in the past they would, to some extent, actually help you troubleshoot, like, what's going on with your app. Like, if your app is, like, using a whole bunch of memory, and you're out of memory, um, they would actually kind of look into that, for you, which is interesting, because it's like, that's almost like a services thing than it is just a platform. [00:22:50] David: Yeah. I mean, they, their support, you would get, you would get escalated to like an engineer sometimes, like who worked on that stuff and they would help figure out what the problem was. Like you got the sense that everybody there really wanted the platform to be good and that they were all sort of motivated to make sure that everybody. You know, did well and used the platform. And they also were good at, like a thing that trips everybody up about Heroku is that your app restarts every day. And if you don't know anything about anything, you might think that is stupid. Why, why would I want that? That's annoying. And I definitely went through that and I complained to them a lot. And I'm like, if you only could not restart. And they very patiently and politely explained to me why that it needed to do that, they weren't going to remove that, and how to think about my app given that reality, right? Which is great because like, what company does that, right? From the engineers that are working on it, like No, nobody does that. So, yeah, no, I haven't escalated anything to support at Heroku in quite some time, so I don't know if it's still like that. I hope it is, but I'm not really, not really sure. Building a platform team [00:23:55] Jeremy: Yeah, that, uh, that reminds me a little bit of, I think it's Rackspace? There's, there's, like, another hosting provider that was pretty popular before, and they... Used to be famous for that type of support, where like your, your app's having issues and somebody's actually, uh, SSHing into your box and trying to figure out like, okay, what's going on? which if, if that's happening, then I, I can totally see where the, the price is justified. But if the support is kind of like dropping off to where it's just, they don't do that kind of thing, then yeah, I can see why it's not so much of a, yeah, [00:24:27] David: We used to think of Heroku as like they were the platform team before we had our own platform team and they, they acted like it, which was great. [00:24:35] Jeremy: Yeah, I don't have, um, experience with, render, but I, I, I did, talk to someone from there, and it does seem like they're, they're trying to fill that role, um, so, yeah, hopefully, they and, and other companies, I guess like Vercel and things like that, um, they're, they're all trying to fill that space, [00:24:55] David: Yeah, cause, cause building our own internal platform, I mean it was the right thing to do, but it's, it's a, you can't just, you have to have a team on it, it's complicated, getting all the stuff in AWS to work the way you want it to work, to have it be kind of like Heroku, like it's not trivial. if I'm a one person company, I don't want to be messing around with that particularly. I want to just have it, you know, push it up and have it go and I'm willing to pay for that. So it seems logical that there would be competitors in that space. I'm glad there are. Hopefully that'll light a fire under, under everybody. [00:25:26] Jeremy: so in your case, it sounds like you moved to having your own platform team and stuff like that, uh, partly because of the compliance thing where you're like, we need our, we need to be isolated from the internet. We're going to go to AWS. If you didn't have that requirement, do you still think like that would have been the time to, to have your own platform team and manage that all yourself? [00:25:46] David: I don't know. We, we were thinking an issue that we were running into when we got bigger, um, was that, I mean, Heroku, it, It's obviously not as flexible as AWS, but it is still very flexible. And so we had a lot of internal documentation about this is how you use Heroku to do X, Y, and Z. This is how you set up a Stitch Fix app for Heroku. Like there was just the way that we wanted it to be used to sort of. Just make it all manageable. And so we were considering having a team spun up to sort of add some tooling around that to sort of make that a little bit easier for everybody. So I think there may have been something around there. I don't know if it would have been called a platform team. Maybe we call, we thought about calling it like developer happiness or because you got developer experience or something. We, we probably would have had something there, but. I do wonder how easy it would have been to fund that team with developers if we hadn't had these sort of business constraints around there. yeah, um, I don't know. You get to a certain size, you need some kind of manageability and consistency no matter what you're using underneath. So you've got to have, somebody has to own it to make sure that it's, that it's happening. [00:26:50] Jeremy: So even at your, your architect level, you still think it would have been a challenge to, to. Come to the executive team and go like, I need funding to build this team. [00:27:00] David: You know, certainly it's a challenge because everybody, you know, right? Nobody wants to put developers in anything, right? There are, there are a commodity and I mean, that is kind of the job of like, you know, the staff engineer or the architect at a company is you don't have, you don't have the power to put anybody on anything you, you have the power to Schedule a meeting with a VP or the CTO and they will listen to you. And that's basically, you've got to use that power to convince them of what you want done. And they're all reasonable people, but they're balancing 20 other priorities. So it would, I would have had to, it would have been a harder case to make that, Hey, I want to take three engineers. And have them write tooling to make Heroku easier to use. What? Heroku is not easy to use. Why aren't, you know, so you really, I would, it would be a little bit more of a stretch to walk them through it. I think a case could be made, but, definitely would take some more, more convincing than, than what was needed in our case. [00:27:53] Jeremy: Yeah. And I guess if you're able to contrast that with, you were saying, Oh, I need three people to help me make Heroku easier. Your actual platform team on AWS, I imagine was much larger, right? [00:28:03] David: Initially it was, there was, it was three people did the initial move over. And so by the time we went public, we'd been on this new system for, I don't know, six to nine months. I can't remember exactly. And so at that time the platform team was four or five people, and I, I mean, so percentage wise, right, the engineering team was maybe almost 200, 150, 200. So percentage wise, maybe a little small, I don't know. but it kind of gets back to the power of like the rails and the one person framework. Like everything we did was very much the same And so the Rails app that managed the deployment was very simple. The, the command line app, even the Go one with all of its verbosity was very, very simple. so it was pretty easy for that small team to manage. but, Yeah, so it was sort of like for redundancy, we probably needed more than three or four people because you know, somebody goes out sick or takes a vacation. That's a significant part of the team. But in terms of like just managing the complexity and building it and maintaining it, like it worked pretty well with, you know, four or five people. Where Rails fits in vs other technology [00:29:09] Jeremy: So during the Keynote today, they were talking about how companies like GitHub and Shopify and so on, they're, they're using Rails and they're, they're successful and they're fairly large. but I think the thing that was sort of unsaid was the fact that. These companies, while they use Rails, they use a lot of other, technology as well. And, and, and kind of increasing amounts as well. So, I wonder from your perspective, either from your experience at StitchFix or maybe going forward, what is the role that, that Ruby and Rails plays? Like, where does it make sense for that to be used versus like, Okay, we need to go and build something in Java or, you know, or Go, that sort of thing? [00:29:51] David: right. I mean, I think for like your standard database backed web app, it's obviously great. especially if your sort of mindset bought into server side rendering, it's going to be great at that. so like internal tools, like the customer service dashboard or... You know, something for like somebody who works at a company to use. Like, it's really great because you can go super fast. You're not going to be under a lot of performance constraints. So you kind of don't even have to think about it. Don't even have to solve it. You can, but you don't have to, where it wouldn't work, I guess, you know, if you have really strict performance. Requirements, you know, like a, a Go version of some API server is going to use like percentages of what, of what Rails would use. If that's meaningful, if what you're spending on memory or compute is, is meaningful, then, then yeah. That, that becomes worthy of consideration. I guess if you're, you know, if you're making a mobile app, you probably need to make a mobile app and use those platforms. I mean, I guess you can wrap a Rails app sort of, but you're still making, you still need to make a mobile app, that does something. yeah. And then, you know, interestingly, the data science part of Stitch Fix was not part of the engineering team. They were kind of a separate org. I think Ruby and Rails was probably the only thing they didn't use over there. Like all the ML stuff, everything is either Java or Scala or Python. They use all that stuff. And so, yeah, if you want to do AI and ML with Ruby, you, it's, it's hard cause there's just not a lot there. You really probably should use Python. It'll make your life easier. so yeah, those would be some of the considerations, I guess. [00:31:31] Jeremy: Yeah, so I guess in the case of, ML, Python, certainly, just because of the, the ecosystem, for maybe making a command line application, maybe Go, um, Go or Rust, perhaps, [00:31:44] David: Right. Cause you just get a single binary. Like the problem, I mean, I wrote this book on Ruby command line apps and the biggest problem is like, how do I get the Ruby VM to be anywhere so that it can then run my like awesome scripts? Like that's kind of a huge pain. (laughs) So [00:31:59] Jeremy: and then you said, like, if it's Very performance sensitive, which I am kind of curious in, in your experience with the companies you've worked at, when you're taking on a project like that, do you know up front where you're like, Oh, the CPU and memory usage is going to be a problem, or is it's like you build it and you're like, Oh, this isn't working. So now I know. [00:32:18] David: yeah, I mean, I, I don't have a ton of great experience there at Stitch Fix. The biggest expense the company had was the inventory. So like the, the cost of AWS was just de minimis compared to all that. So nobody ever came and said, Hey, you've got to like really save costs on, on that stuff. Cause it just didn't really matter. at the, the mental health startup I was at, it was too early. But again, the labor costs were just far, far exceeded the amount of money I was spending on, on, um, you know, compute and infrastructure and stuff like that. So, Not knowing anything, I would probably just sort of wait and see if it's a problem. But I suppose you always take into account, like, what am I actually building? And like, what does this business have to scale to, to make it worthwhile? And therefore you can kind of do a little bit of planning ahead there. But, I dunno, I think it would kind of have to depend. [00:33:07] Jeremy: There's a sort of, I guess you could call it a meme, where people say like, Oh, it's, it's not, it's not Rails that's slow, it's the, the database that's slow. And, uh, I wonder, is that, is that accurate in your experience, or, [00:33:20] David: I mean, most of the stuff that we had that was slow was the database, because like, it's really easy to write a crappy query in Rails if you're not, if you're not careful, and then it's really easy to design a database that doesn't have any indexes if you're not careful. Like, you, you kind of need to know that, But of course, those are easy to fix too, because you just add the index, especially if it's before the database gets too big where we're adding indexes is problematic. But, I think those are just easy performance mistakes to make. Uh, especially with Rails because you're not, I mean, a lot of the Rails developers at Citrix did not know SQL at all. I mean, they had to learn it eventually, but they didn't know it at all. So they're not even knowing that what they're writing could possibly be problematic. It's just, you're writing it the Rails way and it just kind of works. And at a small scale, it does. And it doesn't matter until, until one day it does. [00:34:06] Jeremy: And then in, in the context of, let's say, using ActiveRecord and instantiating the objects, or, uh, the time it takes to render templates, that kinds of things, to, at least in your experience, that wasn't such of an issue. [00:34:20] David: No, and it was always, I mean, whenever we looked at why something was slow, it was always the database and like, you know, you're iterating over some active records and then, and then, you know, you're going into there and you're just following this object graph. I've got a lot of the, a lot of the software at Stitch Fix was like internal stuff and it was visualizing complicated data out of the database. And so if you didn't think about it, you would just start dereferencing and following those relationships and you have this just massive view and like the HTML is fine. It's just that to render this div, you're. Digging into some active record super deep. and so, you know, that was usually the, the, the problems that we would see and they're usually easy enough to fix by making an index or. Sometimes you do some caching or something like that. and that solved most of the, most of the issues [00:35:09] Jeremy: The different ways people learn [00:35:09] Jeremy: so you're also the author of the book, Sustainable Web Development with Ruby on Rails. And when you talk to people about like how they learn things, a lot of them are going on YouTube, they're going on, uh, you know, looking for blogs and things like that. And so as an author, what do you think the role is of, of books now? Yeah, [00:35:29] David: I have thought about this a lot, because I, when I first got started, I'm pretty old, so books were all you had, really. Um, so they seem very normal and natural to me, but... does someone want to sit down and read a 400 page technical book? I don't know. so Dave Thomas who runs Pragmatic Bookshelf, he was on a podcast and was asked the same question and basically his answer, which is my answer, is like a long form book is where you can really lay out your thinking, really clarify what you mean, really take the time to develop sometimes nuanced, examples or nuanced takes on something that are Pretty hard to do in a short form video or in a blog post. Because the expectation is, you know, someone sends you an hour long YouTube video, you're probably not going to watch that. Two minute YouTube video is sure, but you can't, you can't get into so much, kind of nuanced detail. And so I thought that was, was right. And that was kind of my motivation for writing. I've got some thoughts. They're too detailed. It's, it's too much set up for a blog post. There's too much of a nuanced element to like, really get across. So I need to like, write more. And that means that someone's going to have to read more to kind of get to it. But hopefully it'll be, it'll be valuable. one of the sessions that we're doing later today is Ruby content creators, where it's going to be me and Noel Rappin and Dave Thomas representing the old school dudes that write books and probably a bunch of other people that do, you know, podcasts videos. It'd be interesting to see, I really want to know how do people learn stuff? Because if no one reads books to learn things, then there's not a lot of point in doing it. But if there is value, then, you know. It should be good and should be accessible to people. So, that's why I do it. But I definitely recognize maybe I'm too old and, uh, I'm not hip with the kids or, or whatever, whatever the case is. I don't know. [00:37:20] Jeremy: it's tricky because, I think it depends on where you are in the process of learning that thing. Because, let's say, you know a fair amount about the technology already. And you look at a book, in a lot of cases it's, it's sort of like taking you from nothing to something. And so you're like, well, maybe half of this isn't relevant to me, but then if I don't read it, then I'm probably missing a lot still. And so you're in this weird in be in between zone. Another thing is that a lot of times when people are trying to learn something, they have a specific problem. And, um, I guess with, with books, it's, you kind of don't know for sure if the thing you're looking for is going to be in the book. [00:38:13] David: I mean, so my, so my book, I would not say as a beginner, it's not a book to learn how to do Rails. It's like you already kind of know Rails and you want to like learn some comprehensive practices. That's what my book is for. And so sometimes people will ask me, I don't know Rails, should I get your book? And I'm like, no, you should not. but then you have the opposite thing where like the agile web development with Rails is like the beginner version. And some people are like, Oh, it's being updated for Rails 7. Should I get it? I'm like, probably not because How to go from zero to rails hasn't changed a lot in years. There's not that much that's going to be new. but, how do you know that, right? Hopefully the Table of Contents tells you. I mean, the first book I wrote with Pragmatic, they basically were like, The Table of Contents is the only thing the reader, potential reader is going to have to have any idea what's in the book. So, You need to write the table of contents with that in mind, which may not be how you'd write the subsections of a book, but since you know that it's going to serve these dual purposes of organizing the book, but also being promotional material that people can read, you've got to keep that in mind, because otherwise, how does anybody, like you said, how does anybody know what's, what's going to be in there? And they're not cheap, I mean, these books are 50 bucks sometimes, and That's a lot of money for people in the U. S. People outside the U. S. That's a ton of money. So you want to make sure that they know what they're getting and don't feel ripped off. [00:39:33] Jeremy: Yeah, I think the other challenge is, at least what I've heard, is that... When people see a video course, for whatever reason, they, they set, like, a higher value to it. They go, like, oh, this video course is, 200 dollars and it's, like, seems like a lot of money, but for some people it's, like, okay, I can do that. But then if you say, like, oh, this, this book I've been researching for five years, uh, I want to sell it for a hundred bucks, people are going to be, like no. No way., [00:40:00] David: Yeah. Right. A hundred bucks for a book. There's no way. That's a, that's a lot. Yeah. I mean, producing video, I've thought about doing video content, but it seems so labor intensive. Um, and it's kind of like, It's sort of like a performance. Like I was mentioning before we started that I used to play in bands and like, there's a lot to go into making an even mediocre performance. And so I feel like, you know, video content is the same way. So I get that it like, it does cost more to produce, but, are you getting more information out of it? I, that, I don't know, like maybe not, but who knows? I mean, people learn things in different ways. So, [00:40:35] Jeremy: It's just like this perception thing, I think. And, uh, I'm not sure why that is. Um, [00:40:40] David: Yeah, maybe it's newer, right? Maybe books feel older so they're easier to make and video seems newer. I mean, I don't know. I would love to talk to engineers who are like... young out of college, a few years into their career to see what their perception of this stuff is. Cause I mean, there was no, I mean, like I said, I read books cause that's all there was. There was no, no videos. You, you go to a conference and you read a book and that was, that was all you had. so I get it. It seems a whole video. It's fancier. It's newer. yeah, I don't know. I would love to hear a wide variety of takes on it to see what's actually the, the future, you know? [00:41:15] Jeremy: sure, yeah. I mean, I think it probably can't just be one or the other, right? Like, I think there are... Benefits of each way. Like, if you have the book, you can read it at your own pace without having to, like, scroll through the video, and you can easily copy and paste the, the code segments, [00:41:35] David: Search it. Go back and forth. [00:41:36] Jeremy: yeah, search it. So, I think there's a place for it, but yeah, I think it would be very interesting, like you said, to, to see, like, how are people learning, [00:41:45] David: Right. Right. Yeah. Well, it's the same with blogs and podcasts. Like I, a lot of podcasters I think used to be bloggers and they realized that like they can get out what they need by doing a podcast. And it's way easier because it's more conversational. You don't have to do a bunch of research. You don't have to do a bunch of editing. As long as you're semi coherent, you can just have a conversation with somebody and sort of get at some sort of thing that you want to talk about or have an opinion about. And. So you, you, you see a lot more podcasts and a lot less blogs out there because of that. So it's, that's kind of like the creators I think are kind of driving that a little bit. yeah. So I don't know. [00:42:22] Jeremy: Yeah, I mean, I can, I can say for myself, the thing about podcasts is that it's something that I can listen to while I'm doing something else. And so you sort of passively can hopefully pick something up out of that conversation, but... Like, I think it's maybe not so good at the details, right? Like, if you're talking code, you can talk about it over voice, but can you really visualize it? Yeah, yeah, yeah. I think if you sit down and you try to implement something somebody talked about, you're gonna be like, I don't know what's happening. [00:42:51] David: Yeah. [00:42:52] Jeremy: So, uh, so, so I think there's like these, these different roles I think almost for so like maybe you know the podcast is for you to Maybe get some ideas or get some familiarity with a thing and then when you're ready to go deeper You can go look at a blog post or read a book I think video kind of straddles those two where sometimes video is good if you want to just see, the general concept of a thing, and have somebody explain it to you, maybe do some visuals. that's really good. but then it can also be kind of detailed, where, especially like the people who stream their process, right, you can see them, Oh, let's, let's build this thing together. You can ask me questions, you can see how I think. I think that can be really powerful. at the same time, like you said, it can be hard to say, like, you know, I look at some of the streams and it's like, oh, this is a three hour stream and like, well, I mean, I'm interested. I'm interested, but yeah, it's hard enough for me to sit through a, uh, a three hour movie, [00:43:52] David: Well, then that, and that gets into like, I mean, we're, you know, we're at a conference and they, they're doing something a little, like, there are conference talks at this conference, but there's also like. sort of less defined activities that aren't a conference talk. And I think that could be a reaction to some of this too. It's like I could watch a conference talk on, on video. How different is that going to be than being there in person? maybe it's not that different. Maybe, maybe I don't need to like travel across the country to go. Do something that I could see on video. So there's gotta be something here that, that, that meets that need that I can't meet any other way. So it's all these different, like, I would like to think that's how it is, right? All this media all is a part to play and it's all going to kind of continue and thrive and it's not going to be like, Oh, remember books? Like maybe, but hopefully not. Hopefully it's like, like what you're saying. Like it's all kind of serving different purposes that all kind of work together. Yeah. [00:44:43] Jeremy: I hope that's the case, because, um, I don't want to have to scroll through too many videos. [00:44:48] David: Yeah. The video's not for me. Large Language Models [00:44:50] Jeremy: I, I like, I actually do find it helpful, like, like I said, for the high level thing, or just to see someone's thought process, but it's like, if you want to know a thing, and you have a short amount of time, maybe not the best, um, of course, now you have all the large language model stuff where you like, you feed the video in like, Hey, tell, tell, tell me, uh, what this video is about and give me the code snippets and all that stuff. I don't know how well it works, but it seems [00:45:14] David: It's gotta get better. Cause you go to a support site and they're like, here's how to fix your problem, and it's a video. And I'm like, can you just tell me? But I'd never thought about asking the AI to just look at the video and tell me. So yeah, it's not bad. [00:45:25] Jeremy: I think, that's probably where we're going. So it's, uh, it's a little weird to think about, but, [00:45:29] David: yeah, yeah. I was just updating, uh, you know, like I said, I try to keep the book updated when new versions of Rails come out, so I'm getting ready to update it for Rails 7. 1 and in Amazon's, Kindle Direct Publishing as their sort of backend for where you, you know, publish like a Kindle book and stuff, and so they added a new question, was AI used in the production of this thing or not? And if you answer yes, they want you to say how much, And I don't know what they're gonna do with that exactly, but I thought it was pretty interesting, cause I would be very disappointed to pay 50 for a book that the AI wrote, right? So it's good that they're asking that? Yeah. [00:46:02] Jeremy: I think the problem Amazon is facing is where people wholesale have the AI write the book, and the person either doesn't review it at all, or maybe looks at a little, a little bit. And, I mean, the, the large language model stuff is very impressive, but If you have it generate a technical book for you, it's not going to be good. [00:46:22] David: yeah. And I guess, cause cause like Amazon, I mean, think about like Amazon scale, like they're not looking at the book at all. Like I, I can go click a button and have my book available and no person's going to look at it. they might scan it or something maybe with looking for bad words. I don't know, but there's no curation process there. So I could, yeah. I could see where they could have that, that kind of problem. And like you as the, as the buyer, you don't necessarily, if you want to book on something really esoteric, there are a lot of topics I wish there was a book on that there isn't. And as someone generally want to put it on Amazon, I could see a lot of people buying it, not realizing what they're getting and feeling ripped off when it was not good. [00:47:00] Jeremy: Yeah, I mean, I, I don't know, if it's an issue with the, the technical stuff. It probably is. But I, I know they've definitely had problems where, fiction, they have people just generating hundreds, thousands of books, submitting them all, just flooding it. [00:47:13] David: Seeing what happens. [00:47:14] Jeremy: And, um, I think that's probably... That's probably the main reason why they ask you, cause they want you to say like, uh, yeah, you said it wasn't. And so now we can remove your book. [00:47:24] David: right. Right. Yeah. Yeah. [00:47:26] Jeremy: I mean, it's, it's not quite the same, but it's similar to, I don't know what Stack Overflow's policy is now, but, when the large language model stuff started getting big, they had a lot of people answering the questions that were just. Pasting the question into the model [00:47:41] David: Which because they got it from [00:47:42] Jeremy: and then [00:47:43] David: The Got model got it from Stack Overflow. [00:47:45] Jeremy: and then pasting the answer into Stack Overflow and the person is not checking it. Right. So it's like, could be right, could not be right. Um, cause, cause to me, it's like, if, if you generate it, if you generate the answer and the answer is right, and you checked it, I'm okay with that. [00:48:00] David: Yeah. Yeah. [00:48:01] Jeremy: but if you're just like, I, I need some karma, so I'm gonna, I'm gonna answer these questions with, with this bot, I mean, then maybe [00:48:08] David: I could have done that. You're not adding anything. Yeah, yeah. [00:48:11] Jeremy: it's gonna be a weird, weird world, I think. [00:48:12] David: Yeah, no kidding. No kidding. [00:48:15] Jeremy: that's a, a good place to end it on, but is there anything else you want to mention, [00:48:19] David: No, I think we covered it all just yeah, you could find me online. I'm Davetron5000 on Ruby. social Mastodon, I occasionally post on Twitter, but not that much anymore. So Mastodon's a place to go. [00:48:31] Jeremy: David, thank you so much [00:48:32] David: All right. Well, thanks for having me.

This time we talk with Scott Wlaschin, author of a book and a workshop titled Functional Programming Made Functional.Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home. Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss the origins of Scott's book, why DDD and Functional Programming work well together, what type of exercises we'll be doing in the workshop, how opening a blog can be a great asset, Scott's first approach to DDD and much more.Who: Scott Wlaschin is a developer, architect, and author. He is the author of the popular F# website fsharpforfunandprofit.com, and the book Domain Modeling Made Functional, published by Pragmatic Bookshelf.Workshop link: https://bit.ly/Scott_Wlaschin_DDD_FSharp_Podcast#DomainDrivenDesign #FunctionalProgramming #FSharp #DomainModeling #Software #SoftwareDevelopment #ProgrammingLanguages #DDDesign #EventStorming

This time we talk with Scott Wlaschin, author of a book and a workshop titled Functional Programming Made Functional.Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home. Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss the origins of Scott's book, why DDD and Functional Programming work well together, what type of exercises we'll be doing in the workshop, how opening a blog can be a great asset, Scott's first approach to DDD and much more.Who: Scott Wlaschin is a developer, architect, and author. He is the author of the popular F# website fsharpforfunandprofit.com, and the book Domain Modeling Made Functional, published by Pragmatic Bookshelf.Workshop link: https://bit.ly/Scott_Wlaschin_DDD_FSharp_Podcast#DomainDrivenDesign #FunctionalProgramming #FSharp #DomainModeling #Software #SoftwareDevelopment #ProgrammingLanguages #DDDesign #EventStorming

“Treating everyone as remote is to keep everyone in mind as having the same level, same equality, the same access to information in communication exchanges between people." James Stanier is the author of “Effective Remote Work” and Director of Engineering at Shopify. In this episode, James shared insights from his latest book and began by sharing why remote work is here to stay and the basic setup for remote work. He then talked about the importance of managing our time and energy and establishing team norms for successful remote work. James then explained about the concept of treating everyone as remote, which led to the discussion about producing more artifacts and balancing between synchronous and asynchronous working style. We also extended the discussion on how one can become a more effective manager in the remote setup, including how to manage up and allocating time for team bonding and fun activities. Towards the end, James shared how we can self-assess our remote working practices by using the 12 questions in his book, and how remote is the path to equality and can become a great leveler for everyone. Listen out for: Writing “Effective Remote Work” - [00:06:53] Remote is Here to Stay - [00:08:36] Basic Remote Setup - [00:11:45] Managing Yourself - [00:14:38] Effects of Being Unobserved - [00:17:19] Treat Everyone as Remote - [00:19:59] Producing More Artifacts - [00:22:13] Types of Artifacts - [00:25:18] Sync vs Async - [00:30:01] Effective Remote Manager - [00:36:55] Managing Up - [00:39:43] Allocating Fun Time - [00:42:27] Remote Work Self-Assessment - [00:44:44] Remote: The Great Leveler - [00:47:36] 3 Tech Lead Wisdom - [00:53:29] _____ James Stanier's Bio James Stanier is Director of Engineering at Shopify, a fully remote technology company. His latest book, Effective Remote Work, is being published by The Pragmatic Bookshelf in April 2022. His previous book, Become an Effective Software Engineering Manager, was published in 2020. Follow James: Website – https://theengineeringmanager.com Twitter – @jstanier LinkedIn – https://www.linkedin.com/in/jstanier/ Our Sponsor Today's episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals. Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/83.

“It is good to improve your processes to make them faster and more efficient. But sometimes what's even more important is doing the right thing in the first place." Scott Wlaschin is the author of “Domain Modeling Made Functional” and the popular F# site fsharpforfunandprofit.com. In this episode, Scott began by sharing his view of the need for developers today to become more polyglot developers and learn multiple programming languages. Scott then shared about functional programming (FP) fundamentals and how FP differs with object-oriented programming, as well as cases when one is better suited than the other. Scott then explained how we can use FP when implementing Domain-Driven Design (DDD), including how to model some of the DDD tactical designs and transaction boundary. He also shared why F# is his favorite and go-to programming language. Towards the end, Scott touched on important advice about effectiveness vs efficiency, and what leaders need to be aware of regarding doing the right thing. Listen out for: Career Journey - [00:06:16] Polyglot Developer - [00:11:01] Functional Programming - [00:14:59] Case for OOP - [00:19:56] DDD and FP - [00:21:02] Modeling Tactical Design in FP - [00:24:10] Modeling Transaction - [00:28:49] F# - [00:32:22] Effective Instead of Efficient - [00:34:43] Advice on Valuing Effectiveness - [00:38:31] 3 Tech Lead Wisdom - [00:40:30] _____ Scott Wlaschin's Bio Scott Wlaschin is a developer, architect and author. He is the writer behind the popular F# site fsharpforfunandprofit.com, and the book ‘Domain Modeling Made Functional' published by Pragmatic Bookshelf. Known for his non-academic approach to functional programming, Scott is a popular speaker and has given talks at NDC, F# Exchange, DDD Europe, and other conferences around the world. Follow Scott: Twitter – @ScottWlaschin LinkedIn – https://www.linkedin.com/in/scottwlaschin F# for Fun and Profit – https://fsharpforfunandprofit.com/ Our Sponsor Today's episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals. Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/79.

All of us have become more reliant on technology and software to solve problems and improve our lives.  However, many of us understand less and less about the programming that goes into these solutions.  Further, we forget or ignore the human element of this problem solving.   In this episode, I speak with ANDY HUNT who has devoted his life to these issues. Andy Hunt is a programmer turned consultant, author and publisher. He's authored a dozen books including the best-selling “THE PRAGMATIC PROGRAMMER,” was one of the 17 authors of the AGILE MANIFESTO and founders of the Agile Alliance, and co-founded the PRAGMATIC BOOKSHELF, publishing award-winning and critically acclaimed books for software developers. He's currently writing science fiction (see conglommora.com) and experimenting with The GROWS Method®. We talk about his early days of programming and the power of community and process in the world of software design as we go into his experience with broader consulting at the enterprise level. Further on, Andy dives into what he considers to be important in the future of programming and advice for young programmers. Finally, as a consummate Renaissance Man, Andy discusses how his hobbies in writing science fiction, music production and woodworking excite his brain and inform his problem solving ability. Andy started in the do-it-yourself days of CP/M and the S100 bus, of Heathkits and Radio Electronics. Andy wrote his first real program, a combination text editor and database manager, for an Ohio Scientific Challenger 4P. It was a great era for tinkering. Andy started hacking in 6502 assembler, modifying operating systems, and wrote his first commercial program (a Manufacturing Resources Planning system) in 1981. He taught himself Unix and C, and began to design and architect larger, more connected systems. Working at large companies, Andy kept an ear on Usenet, and started his early email habit via a direct bang-path to ihnp4. Next he settled into electronic pre-press and computer graphics, and worked on that wondrous eye-candy that was Silicon Graphics machines. By now a firm command of several flavors of Unix, from BSD to System V, led Andy to try consulting in the early 1990's. His knack for stirring things up really began to come in handy, and it soon became obvious that many of his clients each suffered similar problems—problems that Andy had already seen and fixed before. Andy joined up with Dave Thomas and they wrote the seminal software development book, The Pragmatic Programmer, followed a year later by the original Programming Ruby: The Pragmatic Programmer's Guide, which introduced the Western world to this new language from Japan. Together they founded The Pragmatic Programmers and are well known as founders of the agile movement and authors of the Agile Manifesto, as well as proponents of Ruby and more flexible programming paradigms. They founded the Pragmatic Bookshelf publishing business in 2003, helping keep developers at the top of their game. Andy is a founder of the Pragmatic Programmers, founder of the Agile Alliance and one of the 17 authors of the Agile Manifesto, and author of a dozen or so books on programming, agile methods and learning, as well as science fiction and adventure. He is an active musician and woodworker, and continues looking for new areas where he can stir things up. Comments from Andy on his early career- -Where did your initial interest in programming develop? (The Do-It-Yourself days) -What were the types of problems that attracted your attention? -What languages did you gravitate toward?  Working for larger, more complex situations -What were the big lessons you pick up in those work environments? -Programming considered by laymen as a solitary pursuit- was there an adjustment in delegating work or collobroating?  When does management of strategy get in the way of execution?

Andy Hunt is a writer of books on software development, co-author of "The Pragmatic Programmer," one of the 17 original authors of the Agile Manifesto, and a founder of "The Pragmatic Bookshelf" publishing agency. The video is here: https://youtu.be/zebqDkVfY-g

Watch the live stream: Watch on YouTube About the show Sponsored by us: Check out the courses over at Talk Python And Brian's book too! Special guest: Laís Carvalho Michael #1: Django 4.0 released Django is picking up speed: 4.0 Dec 2021 (+1) 3.0 Dec 2020 (+3) 2.0 Dec 2017 (+7) 1.0.1 May 2010 Feature highlights: The new RedisCache backend provides built-in support for caching with Redis. To ease customization of Forms, Formsets, and ErrorList they are now rendered using the template engine. The Python standard library's zoneinfo is now the default timezone implementation in Django. scrypt password hasher: The new scrypt password hasher is more secure and recommended over PBKDF2. However, it's not the default as it requires OpenSSL 1.1+ and more memory. Django 3.2 has reached the end of mainstream support. The final minor bug fix release, 3.2.10, was issued today. Django 3.2 is an LTS release and will receive security and data loss fixes until April 2024. Some backwards incompatible changes you'll want to be aware of when upgrading from Django 3.2 or earlier. They've begun the deprecation process for some features. Django 4.0 supports Python 3.8, 3.9, and 3.10. Brian #2: python-minifier Suggested by Lance Reinsmith My first thought was “we don't need a minifier for Python” The docs give one reason: “AWS Cloudformation templates may have AWS lambda function source code embedded in them, but only if the function is less than 4KiB. I wrote this package so I could write python normally and still embed the module in a template.” Lance has another reason: “I needed it because the RAM on Adafruit boards using the common M0 chip is around 192KB to 256KB total--not all of which is available to your program. To get around this, you can either 1) compile your code to an .mpy file or 2) minify it. The second worked for me and allowed me to alter it without constantly re-compiling.” Fair enough, what does it do? All of these features are options you can turn off, and are documented well: Combine Import statements Remove Pass statements Remove literal statements (docstrings) Remove Annotations Hoist Literals Rename Locals, with preserved Locals list Rename Globals, with preserved Globals list Convert Positional-Only Arguments to Normal Arguments Also looks like it replaces spaces with tabs Begrudgingly, that makes sense in this context. You can try it at python-minifier.com Laís #3: It's time to stop using Python 3.6 Python 3.6 is reaching the end of it's life in 1 week and 1 day (Dec 23rd), i.e. no more releases after it. You should care because the Python dev team will no longer release security updates for 3.6 ⚠️ if you use Linux, you have a bit more time BUT security updates will be released and bug fixes will not. also, Python 3rd party libraries and frameworks will drop support for 3.6 soon enough. See the log4j issue and Java. Brian might like this one: Grype - a vulnerability scanner for container images and filesystems Michael #4: How to Visualize the Formula 1 Championship in Python Race Highlights | 2021 Abu Dhabi Grand Prix Formula 1: Drive to Survive (Season 3) | Official Trailer Wanting to get into Formula 1 data analysis, the Ergast API is a very good starting point. This tutorial will show you how to use data from the Ergast API to visualize the changes in the 2021 championship standings over the rounds. Introduces fastf1: Wrapper library for F1 data and telemetry API with additional data processing capabilities. Brian #5: nbdime: Jupyter Notebook Diff and Merge tools Suggestion from Henrik Finsberg “you recently covered ‘jut' for viewing Jupyter notebooks from the terminal. Check out ‘mbdime'.” (that was episode 258) So I did. And it looks cool. nbdime provides tools for diffing and merging of Jupyter Notebooks. nbdiff compare notebooks in a terminal-friendly way nbmerge three-way merge of notebooks with automatic conflict resolution nbdiff-web shows you a rich rendered diff of notebooks nbmerge-web gives you a web-based three-way merge tool for notebooks nbshow present a single notebook in a terminal-friendly way Laís #6: Using AI to analyse and recommend software stacks for Python apps thanks Fridolin! Project Thoth: an open source cloud-based Python dependency resolver ML (reinforcement learning) that solves dependency issues taking into consideration runtime envs, hardware and other inputs. Using Markov's decision process. “a smarter pip” that instead of using backtracking, precomputes the dependency information and stores it in a database that can be queried for future resolutions. Using pre-specified criteria by the developer. In summary: Thot's resolver uses automated bots that guarantee dependencies are locked down to specific versions, making builds and deployments reproducible; the aggregated knowledge (reinforcement learning from installed logs) helps the bots to lock the dependencies to the best libraries, instead of the latest. They are in beta phase but welcoming feedback and suggestions from the community. Extras Brian: Pragmatic Bookshelf 12 days of Christmas Today, pytest book is part of the deal, nice timing, right? Michael: My talk at FlaskCon is out Firefox releases RLBox We're all getting identity theft monitoring for 1 year for free :-/ Laís: Python Ireland's speaker's coaching session is on Jan 22nd Learning git the visual way - cool for beginners, thorough explanations Good read for Java devs who want to start with Python (by Real Python) Joke: Janga Python (hellish) virtual envs

This episode serves as a round-up of some of the special mini-features we have recorded throughout Season 6, where we'll hear from Tyler Clemens, Elom Amouzou, Elise Navarro, and Jeremy Neal about their work and experiences with Elixir. Our first segment is with Tyler, who is a software developer at Jackpocket, where he explains what he is currently busy with and how the company is offering access to the lottery in more safe and convenient ways. We then move on to Elom, who talks about transitioning from a life in public education, and what prompted him to learn functional programming. Elise, who works at Zingeroo, takes us through her relatively new career, why she is so excited about Elixir, and the interesting work that is being done at her company to educate the public about the stock market. Lastly, Jeremy talks to us about the socially conscious agenda at Clover Food Lab, his personal interests in cooking and baking, and how he came to work with Elixir. All of our guests share helpful resources for learning, and reflections on their time working within Elixir - make sure to join us to catch all this good stuff! Key Points From This Episode: Tyler's path into software engineering and the first language he learned. What Jackpocket offers its customers and how Elixir is used within the company. Tyler's thoughts on the perks and challenges associated with engineering with Elixir. The most helpful resources that Tyler uses when in need: Elixir Slack, books, and Elixir School! Onboarding and training in Elixir and the biggest challenges presented in this area. Tyler's passion for photography and imagining an alternative career path in this direction. Elom's first programming language and the subsequent transition into Elixir. How Elom moved into working in programming from his roots in education. Elom's perspective on the positives associated with adopting Elixir early on. Resource recommendations from Elom for early-stage developers. Considering the pros and cons of the small intimate Elixir community and its future. Elom's ideal alternative career path and favorite book! Elise's beginnings in programming and her move from a career in digital media. Comparing Elixir with other languages; Elise weighs in with her experiences. What Zingeroo does and how they use Elixir to make the stock market more accessible through the app. The benefits of using Elixir for a real-time app like Zingeroo. The resources that have been most valuable to Elise since joining the community. Elise's alternative career path, and her passion for teaching Pilates. Jeremy's educational and professional path into software engineering and working with Elixir. How Jeremy has been using LiveView in his work to get a functional UI up and running. What Clover Food Lab does and how Elixir is used at the company and online store. Jeremy's thoughts on a different career and why he would love to be a baker! Links Mentioned in Today's Episode: SmartLogic — https://smartlogic.io/ Tyler Clemens — https://www.linkedin.com/in/tylerclemens Jackpocket — https://jackpocket.com/ Elixir in Action — https://www.goodreads.com/book/show/38732242-elixir-in-action Elixir School — https://elixirschool.com/ Turing School — https://turing.edu/ Pragmatic Bookshelf — https://pragprog.com/ Code Flow Thinking Elixir — https://thinkingelixir.com/available-courses/code-flow/ Frantz Fanon — https://www.britannica.com/biography/Frantz-Fanon Peau Noire, Masques Blancs — https://www.amazon.com/Peau-Noire-Masques-Blancs-French/dp/2020006014 Elise Navarro — https://www.linkedin.com/in/elise-navarro Zingeroo — https://zingeroo.com/ Jeremy Neal — https://www.linkedin.com/in/jeremy-neal-59ba8b82 Clover Food Lab — https://www.cloverfoodlab.com/ Special Guests: Elise Navarro, Jeremy Neal, and Tyler Clemens.

While we can think of many reasons why we love Elixir, the community could always benefit from a more lively conversation around testing. It was with this in mind that Jeffrey Matthias and Andrea Leopardi decided to write Testing Elixir, and today they join us on the show to share some of the insights to be found in their new book. Our guests start by sketching out the main reasons why they decided to write a book of this nature before speaking to the process of writing it collaboratively from their respective homes in Italy and the US. Andrea and Jeffrey speak about the challenges of finding a middle ground between their unique styles to come up with a unified testing method. The conversation then takes a deep dive into the weeds of testing in Elixir and we hear our guests' perspectives on the most appropriate situations to use async true, Mox, Ecto Sandbox, and other techniques. We wrap up our interview with a question about what Andrea and Jeffrey would most like people to take away from their book where they express the hope that it can act as a springboard for further conversation about best practices for testing in Elixir and more. As always, we close the show off with our mini-interview, this time talking to Tracey Onim from Podii. Key Points From This Episode: Why Jeffrey and Andrea wrote their book and how they pitched it to the publisher. How the feedback Andrea and Jeffrey got while writing the book shaped its content. What writing the book was like considering its authors live in different countries. How our guests came up with a unified testing method when each had their own style. Stories about testing mistakes and the funny situations they led to. Discussing the HBO integration test email and how it was responded to and dealt with. The issue of developers not using async true enough and how to get better at it. When to use async true, Ecto Sandbox, and Mox. Why our guests use Mox, when the best times to use it are, and how it shapes your thinking. Exploring the relationship between test driven development and using the program. What can go wrong if you rely purely on tests to test out your code. The main takeaways our guests hope can be found in their book. Final plugs from Jeffrey and Andrea and where to find them online. A quick interview where we learn more about Tracey Onim from Podii. Links Mentioned in Today's Episode: SmartLogic — https://smartlogic.io/ Jeffrey Matthias on Twitter — https://twitter.com/idlehands Andrea Leopardi — https://andrealeopardi.com/ Andrea Leopardi on Twitter — https://twitter.com/whatyouhide Andrea Leopardi on GitHub — https://github.com/whatyouhide/corsica Testing Elixir — http://testingelixir.com/ Testing Elixir — https://pragprog.com/titles/lmelixir/testing-elixir/ Testing Elixir — https://www.target.com/p/testing-elixir-by-andrea-leopardi-jeffrey-matthias-paperback/-/A-83072057#lnk=sametab Testing Elixir on Twitter — https://twitter.com/testingelixir Publish with The Pragmatic Bookshelf — https://pragprog.com/become-an-author/ Ecto.Adapters.SQL.Sandbox — https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html Mox — https://hexdocs.pm/mox/Mox.html Command Line Options — https://hexdocs.pm/mix/1.12/Mix.Tasks.Test.html#module-command-line-options Mocks and Explicit Contracts — http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-contracts/ bypass — https://github.com/PSPDFKit-labs/bypass Test-Driven Development with Phoenix — https://www.tddphoenix.com/ Tracey Onim — https://www.linkedin.com/in/tracey-onim-420b3316a?originalSubdomain=ke Podii — https://www.apollo.io/companies/Podii/5c1df0e8f651257261ddc16a?chart=count Special Guests: Andrea Leopardi and Jeffrey Matthias.

Tim has a chat with Karl Stolley about his journey to becoming a Pragmatic author. * Recorded 19-May-2021 On the latest episode of the Pragmatic Hero's Journey podcast, Tim chats with Karl Stolley, associate professor of information technology and management at Illinois Institute of Technology in Chicago. --- Karl Stolley has been teaching, researching, and writing about web development up and down the stack since graduate school. He frequently speaks at national and international academic conferences, and he's a presenter and active participant in many professional developer groups and meetups in the Chicago area.   With the contract signed and the project officially launched, Karl is working on his debut book with the Pragmatic Bookshelf, tentatively titled WebRTC: Build Real-Time Web Applications in the Browser. Beyond the professional advancement and other things this book means to Karl, writing and publishing with Pragmatic is a straight-up bucket-list item for him.   On this episode, Karl talks about his journey to becoming a pragmatic author and why selecting the right title for your book can make all the difference. Listen to the rest of Karl's story on this episode of the Pragmatic Hero's Journey podcast. You can stream the episode here: https://pragprog.libsyn.com/ or subscribe to the RSS feed using the following link: https://pragprog.libsyn.com/rss.

Tammy and Tim have a chat with Brian Hogan, author of Build Websites with Hugo, about his journey to becoming a Pragmatic author. * Recorded 10-March-2021 Show Links Brian Hogan on Twitter Build Websites with Hugo Small, Sharp Software Tools Tim and Tammy are back with another episode of the Pragmatic Hero's Journey podcast. This month, our hosts chat with Brian Hogan, author of Build Websites with Hugo. --- Brian Hogan is a software developer, teacher, author, editor, and musician. Since 1995, Brian's been building websites and web applications using a variety of tools and technology. But Brian's journey didn't stop with web development. He's been working as a freelance developer for small businesses and has helped countless developers through lectures, mentoring, and of course, books---including Small, Sharp Software Tools, Exercises for Programmers, tmux 2: Productive Mouse-Free Development, and several others for The Pragmatic Bookshelf. On this episode, Brian talks about his journey to becoming a pragmatic author and what he's learned along the way. He also spills the beans on what makes for a great bio and how to showcase who you are and what you do. Listen to the rest of Brian's story on this episode of the Pragmatic Hero's Journey podcast. You can stream the episode here: https://pragprog.libsyn.com/ or subscribe to the RSS feed using the following link: https://pragprog.libsyn.com/rss.

For this week's episode, we talk to Bruce Tate, member of the Elixir community since the language turned 1.0. As one of the main people behind Elixir's publishing scene, Bruce was the editor of the ElixirSource line of books for the Pragmatic Bookshelf through most of its history. He is a coauthor for Programming Phoenix, Designing Elixir Systems with OTP, and Adopting Elixir, and the chief author and content developer for Groxio, LLC. The episode starts as Bruce tells his story spanning the early days of Java, Ruby, and eventually Elixir. Along the way, he talks about writing books, and how Seven Languages in Seven Weeks led to an introduction to Joe Armstrong, and marked the beginning of his great love for programming languages. Along the way, Bruce and Lars discuss the PETAL stack, and his experiences teaching Groxio liveview classes. Bruce and Sophie also discuss writing at the Pragmatic Bookshelf together, and teaching together using the CRC pattern. https://changelog.com/posts/petal-the-end-to-end-web-stack https://pragprog.com/titles/liveview/programming-phoenix-liveview/ We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @StevenNunez @akoutmos @knewter @lawik @RedRapids @smdebenedetto Sponsored by @GroxioLearning

Tammy and Tim have a chat with Chris Pine, author of Learn to Program, about his journey to becoming a Pragmatic author. * Recorded 10-February-2021 Show Links Chris Pine on Twitter Learn to Program Sourcegraph Alan Watts, Out of Your Mind (Part 1) Alan Watts, Out of Your Mind (Part 2) Programming Ruby (2nd edition) Tim and Tammy are back with Episode #2 of the Pragmatic Hero's Journey podcast. This month, our hosts chat with Chris Pine, author of Learn to Program. From tiny houses to huge programming concepts and everything in-between, this episode has it all. --- Chris Pine started his Hero's Journey in 2002 when he thought about using Ruby to teach people how to program. There wasn't much Ruby documentation for beginners at the time, so he decided to stop thinking about teaching and start writing a tutorial aimed at beginners. But the task of writing a great tutorial for non-programmers was a bit more challenging than Chris first anticipated. But, he kept at it---adding more and more polish with each revision. Because Chris made it so easy for people to contact him, he was able to rework the tutorial based on reader feedback. Just as Chris was ready to wrap up the tutorial writing, he was contacted by a handful of publishers, including the Pragmatic Bookshelf---he's been with us ever since and is now working on the 3rd edition of Learn to Program, which is currently in beta. Listen to the rest of Chris's story on this episode of the Pragmatic Hero's Journey podcast. You can stream the episode here: https://pragprog.libsyn.com/ or subscribe to the RSS feed using the following link: https://pragprog.libsyn.com/rss.

No one cares about clever code. Instead, people want code that works. Code that they can read six months down the line. Today we speak with Johnny Winn, who avoids writing clever code by following a clear vision — “Make it work, then make it beautiful, then if you really, really have to, make it fast.” A Renaissance man, Johnny’s career ranged from cheffing to design before he settled into software engineering. Reflecting his many interests, we spend the first section of the podcast chatting about cooking. Johnny shares his kitchen secrets before seamlessly transitioning into the topic of coding. After touching on why clever code is bad code, we explore the trend of ‘componentizing,’ when your views are taken over by an endless array of components and folders. Like Johanna Larsson, a previous guest, Johnny makes a case for umbrella projects and explains why many of us have been using them incorrectly this whole time. An enemy of dogma, Johnny emphasizes that teams should use what works best for them, and not what conventional wisdom suggests. Following this, we dive into imposing patterns on our architecture bases, how design patterns serve as communication tools, and why tribal knowledge leads to communication issues. Johnny brings his experience to bear and shares how he structures projects while limiting component creation. Near the end of the episode, Johnny talks about how he learned the cardinal sins of coding before leaving us with his final hot take on living a balanced life. So, tune in for a dynamic conversation where Johnny is as likely to share his smoked pork recipe as he is to deliver key coding insights. Key Points From This Episode: Introducing Johnny Winn and why he’s been called a ‘Renaissance man.’ How to cook the perfect steak or burger — don’t share this with anyone. Hear about what Johnny would cook if he needed to impress you. A recipe for the perfect smoked pork shoulder brine. Food wars; we debate what the best meat and sandwiches are. The inter-industry virtue of keeping things simple and why clever code is bad code. Exploring the trend of ‘componentizing’ everything to extreme levels. The case for umbrella projects and why most people are doing it wrong. Ignoring conventional wisdom and favoring approaches that best work for a team. Winging it versus adding too many components and nested file structures. How design patterns function as a way to communicate. Why developing tribal knowledge can lead to communication issues. Johnny’s mission when coding; “Make it work, make it beautiful, make it fast.” The method that Johnny uses to structure a project. Johnny’s advice for avoiding the cardinal sins of coding; write bad code in your side projects. The importance of living a balanced life and spending time with loved ones. Links Mentioned in Today’s Episode: SmartLogic — https://smartlogic.io/ Johnny Winn on Twitter — https://twitter.com/johnny_rugger Johnny Winn on LinkedIn — https://www.linkedin.com/in/johnnywinn5/ Elixir Fountain — https://twitter.com/elixirfountain?lang=en Code Sync — https://www.codesync.global/ Code BEAM San Francisco — https://codesync.global/conferences/code-beam-sf/ Kerrygold — https://www.kerrygoldusa.com/ Kraft Macaroni & Cheese Deluxe — https://www.kraftmacandcheese.com/products/100166000004/deluxe Annie’s Mac and Cheese — https://www.annies.com/products/mac-and-cheese/ Velveeta — https://www.myfoodandfamily.com/brands/velveeta Shake Shack — https://www.shakeshack.com/ Dave Thomas — https://www.thoughtworks.com/profiles/dave-thomas Phoenix — https://www.phoenixframework.org/ Chris McCord — http://chrismccord.com/ Johanna Larsson — https://blog.jola.dev/ Johanna Larsson Episode — https://smartlogic.io/podcast/elixir-wizards/s4e11-larsson/ The Pragmatic Bookshelf — https://pragprog.com/ Ecto — https://hexdocs.pm/ecto/Ecto.html Pirates of the Caribbean: The Curse of the Black Pearl — https://www.imdb.com/title/tt0325980/ Joe Armstrong — https://joearms.github.io/#Index Johnny’s Smoked Pork Shoulder Brine Ingredients — Hot Water Coconut Sugar Kosher Salt Smoked Paprika Chili Powder Granulated Garlic Peppercorns Bay Leaves Cinnamon Special Guest: Johnny Winn.

Today’s guest is Amos King, Principal CEO at Binary Noggin, and host on the Elixir Outlaws and This Agile Life podcasts. This episode is centered around a casual conversation about everything from programming, the military, sarcasm, and puns to systems and application architecture, domain-driven design, and bitmasks. Amos shares with us how he got into programming, after wanting to be a doctor or an engineer first, and tells us how he met Famous Amos. We talk about spectrum analyzers, Elixir resources, and MUDs, as well as type-first design and Haskell. Amos gives us his takes on domain-driven design, API, booleans, and enums, and even roasts his co-host Chris Keithley a little. Don’t miss this episode for everything you’ve ever wanted to know about the legendary Amos King (and a whole lot more)! Key Points From This Episode: * Amos explains what Adkron means, which is his gaming and social media handle. * Where the name Elixir Outlaws for the podcast came from. * How Amos got into programming as a career, after wanting to be a surgeon and an engineer. * What Amos’s first opportunity as a programmer was, and how he met Wally Amos. * Amos explains what a spectrum analyzer is, based on his experience in the military. * Amos shares why Steve Bussey’s book, Real-Time Phoenix, is his favorite Elixir resource. * Eric and Amos talk about the MUD engine that they worked on together. * What systems and application architecture means to Amos and how it differs from design. * What type-first design (TFD) is and Amos’s opinion on it as a thought exercise. * Amos talks about Haskell programming and domain-driven design. * Relating domain-driven design to a car dealership to describe types and terminology. * Amos talks a bit about his company and what they do. * Justus, Eric, and Amos debate the term “architect” and what it actually means. * Amos shares his take on API architecture, booleans, enums, and bitmasks. * Amos gives his hot take on his co-host Chris Keithley. Links Mentioned in Today’s Episode: Amos King on Twitter — https://twitter.com/adkron Elixir Outlaws Podcast — https://elixiroutlaws.com/ Wally Amos — https://en.wikipedia.org/wiki/WallyAmos Windows 3.0 — https://en.wikipedia.org/wiki/Windows3.0 Real-Time Phoenix on Pragmatic Bookshelf — https://pragprog.com/book/sbsockets/real-time-phoenix Elixir School — https://elixirschool.com/en/ Elixir Inaction — https://twitter.com/gausby/status/986550202248187904 This Agile Life Podcast — https://www.thisagilelife.com/ Screen — https://screen.so/#/home Haskell Book — https://haskellbook.com/ Binary Noggin Website — https://binarynoggin.com/ Binary Noggin on Twitter — https://twitter.com/BinaryNoggin SmartLogic — https://smartlogic.io/ Justus Eapen on Twitter — https://twitter.com/justuseapen Eric Oestrich — https://oestrich.org/ Kalevala — https://github.com/oestrich/kalevala Eric Oestrich on Twitter — https://twitter.com/ericoestrich Eric Oestrich on GitHub — https://github.com/oestrich Special Guest: Amos King.

We talk with Steve Bussey about his book Real-Time Phoenix, his library ecto_tenancy_enforcer, and we delve into user auth. We cover how TDD works for us, approaches to partitioning user data, recent auth developments in the community and much more! Panelists Josh Adams Mark Ericksen Guest Steve Bussey   "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!   Links SalesLoft The Pragmatic Bookshelf GitHub sb8244/ecto_tenancy-enforcer citusdata Citus Community Pow Dashbit Keycloak devise Gibson Research Corporation Elixir Forum Picks Josh Adams: Bitwarden Baby Chickens. 'Nuff said Mark Ericksen: FREE Pattern Matching Course Seinfeld Steve Bussey: Zwift Follow on Twitter: @yoooodaaaa Follow on Twitter: Elixir Mix - @elixir_mix Mark Ericksen - @brainlid Sophie DeBenedetto - @sm_debenedetto Josh Adams - @knewter

We talk with Steve Bussey about his book Real-Time Phoenix, his library ecto_tenancy_enforcer, and we delve into user auth. We cover how TDD works for us, approaches to partitioning user data, recent auth developments in the community and much more! Panelists Josh Adams Mark Ericksen Guest Steve Bussey   "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!   Links SalesLoft The Pragmatic Bookshelf GitHub sb8244/ecto_tenancy-enforcer citusdata Citus Community Pow Dashbit Keycloak devise Gibson Research Corporation Elixir Forum Picks Josh Adams: Bitwarden Baby Chickens. 'Nuff said Mark Ericksen: FREE Pattern Matching Course Seinfeld Steve Bussey: Zwift Follow on Twitter: @yoooodaaaa Follow on Twitter: Elixir Mix - @elixir_mix Mark Ericksen - @brainlid Sophie DeBenedetto - @sm_debenedetto Josh Adams - @knewter

Real-time applications come with real challenges—persistent connections, multi-server deployment, and strict performance requirements are just a few. Our guest today is Steve Bussey, a software architect at SalesLoft and author of the new book, Real-Time Phoenix: Build Highly Scalable Systems with Channels. In this episode, Steve shares with us what he has written on real-time Elixir applications and how he has led development in the field. We discuss how Steve found Elixir, what system and application architecture means to him, and what he considers the differences between architecting and designing a system. Steve gives us his opinions on domain-driven design, umbrella apps, and Phoenix LiveView, and shares some of his personal processes when working on new real-time features, as well as what he believes are the toughest parts of developing and rolling out real-time applications. Finally, we talk about testing, security, and performance issues, and Steve sells us on his book. Tune in today! Key Points From This Episode: What Steve’s favorite pair of shoes is and how he got into sneakers. Where Steve is from and how long he has been doing programming. What system and application architecture means to Steve. The difference between architecting and designing a system. Steve’s opinions on domain-driven design. Eric’s opinion on umbrella apps and Steve’s response. Where Steve starts when he works on a new real-time feature. Steve’s personal and professional pre-code design processes. The toughest parts of developing and rolling out real-time applications. Testing real-time features and Steve’s thoughts on Phoenix LiveView. How Steve incorporates security into the architecture when designing applications. Multi-tenant applications and how Steve deals with performance issues. Deployment considerations when going into production with a real-time application. Steve sells us on his book and gives his final plugs and asks for the audience. Links Mentioned in Today’s Episode: Steve Bussey on Twitter – https://twitter.com/YOOOODAAAA Steven Bussey’s Website – https://stevenbussey.com/ Real-Time Phoenix on Pragmatic Bookshelf – https://pragprog.com/book/sbsockets/real-time-phoenix SmartLogic — https://smartlogic.io/ Justus Eapen on Twitter — https://twitter.com/justuseapen Eric Oestrich — https://oestrich.org/ Eric Oestrich on Twitter — https://twitter.com/ericoestrich Eric Oestrich on GitHub — https://github.com/oestrich Special Guest: Steve Bussey.

Ned and Meg discuss the concept of embedding failure, which we read about in one of our favorite books, Pragmatic Thinking and Learning by Andy Hunt (2008, The Pragmatic Bookshelf). In section 7.3, the author discusses approaches to failure. We talk about adding failure deliberately into our own work process/life process to ensure that we continue to learn and grow. Failure is great, come enjoy it with us!

Ryan Ripley (@ryanripley) joined the Aptera Live team to discuss the release of his new book: Fixing Your Scrum – Practical Solutions to Common Scrum Problems. In this episode you’ll discover: How to Ryan and Todd wrote Fixing Your ScrumThe power of a Sprint GoalTip and advice for avoiding the most common Scrum problems Links from the show: Get a free sample chapter from the book here – https://ryanripley.com/fixing-your-scrum/ Take a Scrum.org Class with PST Ryan Ripley – https://www.scrum.org/ryan-ripleyRead Ryan’s New Book – https://pragprog.com/book/rrscrum/fixing-your-scrum How to Support the Show: Thank you for your support. Here are some of the ways to contribute that were discussed during this episode: Share the show with friends, family, colleagues, and co-workers. Sharing helps get the word out about Agile for HumansRate us on iTunes and leave an honest reviewJoin the mailing list – Check out the form on the right side of the pageTake the survey – totally anonymous and helps us get a better idea of who is listening and what they are interested inLeadership Gift ProgramMake a donation via Patreon Buy Ryan’s New Book: Broken Scrum practices limit your organization’s ability to take full advantage of the agility Scrum should bring: The development team isn’t cross-functional or self-organizing, the product owner doesn’t get value for their investment, and stakeholders and customers are left wondering when something—anything—will get delivered. Learn how experienced Scrum masters balance the demands of these three levels of servant leadership, while removing organizational impediments and helping Scrum teams deliver real-world value. Discover how to visualize your work, resolve impediments, and empower your teams to self-organize and deliver using advanced coaching and facilitation techniques that honor and support the Scrum values and agile principles. Click here to purchase on The Pragmatic Bookshelf. Want to hear another podcast about the life of an agile coach? — Listen to my conversation with Zach Bonaker, Diane Zajac-Woodie, and Amitai Schlair on episode 39. We discuss growing an agile practice and how coaches help create the environments where agile ideas can flourish. The post AFH 111: Fixing Your Scrum on Aptera Live appeared first on Ryan Ripley.

Kim Brainard (@agilebrain1) joined Ryan Ripley (@ryanripley) to discuss her jouney to become a Certified Scrum Trainer (CST) with Scrum Alliance. Kim Brainard Leading an Agile Workshop In this episode you’ll discover: How to become a CST with Scrum AllianceWhat to expect when you decide to become a Scrum TrainerTip and advice for when the journey becomes difficult Links from the show: Certified Scrum Trainer – Scrum Alliance – https://www.scrumalliance.org/ Kim and Ryan’s Upcoming Facilitation Course: https://agilebraingroup.com/event/icagile-agile-team-facilitation/ Kim and Ryan’s Upcoming Coaching Course: https://agilebraingroup.com/event/advance-your-coaching/ Kim’s Website: https://agilebraingroup.com Take a Scrum.org Class with PST Ryan Ripley – https://www.scrum.org/ryan-ripleyRead Ryan’s New Book now in BETA – https://pragprog.com/book/rrscrum/fixing-your-scrum How to Support the Show: Thank you for your support. Here are some of the ways to contribute that were discussed during this episode: Share the show with friends, family, colleagues, and co-workers. Sharing helps get the word out about Agile for HumansRate us on iTunes and leave an honest reviewJoin the mailing list – Check out the form on the right side of the pageTake the survey – totally anonymous and helps us get a better idea of who is listening and what they are interested inLeadership Gift ProgramMake a donation via Patreon Buy Ryan’s New Book: Broken Scrum practices limit your organization’s ability to take full advantage of the agility Scrum should bring: The development team isn’t cross-functional or self-organizing, the product owner doesn’t get value for their investment, and stakeholders and customers are left wondering when something—anything—will get delivered. Learn how experienced Scrum masters balance the demands of these three levels of servant leadership, while removing organizational impediments and helping Scrum teams deliver real-world value. Discover how to visualize your work, resolve impediments, and empower your teams to self-organize and deliver using advanced coaching and facilitation techniques that honor and support the Scrum values and agile principles. Click here to purchase on The Pragmatic Bookshelf. Want to hear another podcast about the life of an agile coach? — Listen to my conversation with Zach Bonaker, Diane Zajac-Woodie, and Amitai Schlair on episode 39. We discuss growing an agile practice and how coaches help create the environments where agile ideas can flourish. The post AFH 110: How to Become a Certified Scrum Trainer (CST) with Kim Brainard appeared first on Ryan Ripley.

Join Tammy Coron and Tim Mitra on Episode 138, which was recorded on July 31, 2019. On this episode, they talk with Brian P. Hogan. Brian is a web developer, teacher, author, editor, and musician. He's developed web sites using HTML5, Elixir, JavaScript, and Ruby. He's also a coach and mentor, and author of several books, including his most recent, Small, Sharp Software Tools available at The Pragmatic Bookshelf. If you like listening to Roundabout: Creative Chaos, and you want to know how you can help support the show, please visit our website at RoundaboutFM.com for details.

Pragmatic Programmer at 20 with Dave Thomas and Andy Hunt Guests Dave Thomas (https://twitter.com/pragdave) and Andy Hunt (https://twitter.com/PragmaticAndy): Authors of The Pragmatic Programmer (https://pragprog.com/book/tpp20/the-pragmatic-programmer-20th-anniversary-edition) and publishers of The Pragmatic Bookshelf (https://pragprog.com/). Summary I’m very excited to have Dave Thomas and Andy Hunt on the show today. Dave and Andy are the authors of the Pragmatic Programmer, which has a 20th anniversary edition that is out now, and they are the publishers of the Pragmatic Bookshelf, where they have (full disclosure) published my books a time or two. We talk about what’s changed in the new version, what being a Pragmatic Programmer means, whether there’s still a role for tech books, and how to make automated testing pragmatic. Somehow I avoid telling the slightly embarrassing story about the bad impression I made the first time I met Dave. Enjoy. Notes 02:52 - Revisiting the Book 20 Years Later and What Has Changed/Hasn’t Changed 06:41 - What it Means to be a Pragmatic Programmer 08:39 - Software Development as a Team Sport 12:56 - Extreme Programming Explained and The Pragmatic Programmer; Similarities and Differences Extreme Programming Explained (https://amzn.to/31xukpR) Agile Manifesto (http://agilemanifesto.org) 22:09 - Finding The Pragmatic Programmer Voice/Tone 24:55 - Roles for Dead-Tree Technical Books 30:36 - How To Make Automatic Testing Pragmatic Special Guests: Andy Hunt and Dave Thomas.

stdout.fm 42번째 로그에서는 인사이트 출판사 송우일 님을 모시고 IT 출판사, 전자책, IT 도서 출간 등에 대해서 이야기를 나눴습니다. 참가자: @seapy, @raccoonyy, 송우일 개발자 팟캐스트 stdout.fm 테라폼 삽질 공유회 | Festa! 손에 잡히는 10분 정규 표현식 / IT 도서 출판사 도서출판 인사이트 – 프로그래밍, IT 관련 서적을 발간합니다. 알라딘: 손에 잡히는 10분 정규 표현식 알라딘: 손에 잡히는 정규표현식 알라딘: 함께 자라기 - 애자일로 가는 길 알라딘: 실리콘밸리의 팀장들 - 까칠한 인재마저 사로잡은 그들의 지독한 솔직함 The Pragmatic Bookshelf Programming Elixir 1.6 | The Pragmatic Bookshelf Programming Crystal | The Pragmatic Bookshelf 대안언어축제 - anpshare LangDev Packt | Programming Books, eBooks & Videos for Developers 알고리즘 알라딘: 알고리즘 문제 해결 전략 - 전2권 - 프로그래밍 대회에서 배우는 Baekjoon Online Judge 알라딘: 알고리즘 트레이닝 : 프로그래밍 대회 입문 가이드 알라딘: 코딩 인터뷰 완전 분석 - 187가지 프로그래밍 문제와 해법 프로그래밍 면접, 이렇게 준비한다 - YES24 전자책 O’Reilly Media - Technology and Business Training 도서출판 인사이트 전자책 인프런 - 배우고 나누고 성장하세요 | 온라인 강의 플랫폼 EPUB - Wikipedia stdout_23.log: 만우절, 일본의 새 연호, 북스캔 w/ ecleya | 개발자 팟캐스트 stdout.fm 최승준 - 이북 대여 서비스에 관한 상상… (친구 공개) Amazon.com: All-new Kindle Oasis - Now with adjustable warm light - 8 GB, Graphite (International Version): Gateway 비스킷 - 싸니까 믿으니까 인터파크도서 알라딘: 리버싱 핵심 원리 - 악성 코드 분석가의 리버싱 이야기 알라딘: 아마존, 세상의 모든 것을 팝니다 - 아마존과 제프 베조스의 모든 것 IT 서적 출판하기 주유의 IT 책 쓰기 불바다 강론 : 빠르게 포기하거나, 진짜로 저자가 되거나 by 최현우 - issuu WegraLee (Wegra Lee) (일본어) Ruby로 만드는 Ruby(전자책) (일본어) ASCII.jp：Ruby로 배우는 Ruby(잡지 연재) 중국 / 그 외 선전시 - 위키백과, 우리 모두의 백과사전 中 선전시내 모든 택시 연내 전기차로 바꾼다 | 한경닷컴 Tencent 腾讯 알라딘: 프로그래밍 그루비 알라딘: 프로그래밍 클로저 알라딘: 프로그램 디자인, 어떻게 할 것인가 Amazon.com: Mindstorms: Children, Computers, And Powerful Ideas 알라딘: 패턴 랭귀지 - 도시 건축 시공 알라딘: 똑바로 일하라 - 성과는 일벌레를 좋아하지 않는다 알라딘: 미래를 만든 Geeks 알라딘: 멀티미디어 - 바그너에서 가상현실까지

stdout.fm 40번째 로그에서는 Tech야,놀자 행사 준비, 기술 블로그 운영, 야놀자 등에 대해서 이야기를 나눴습니다. 게스트: @totuworld 참가자: @seapy, @nacyo_t, @raccoonyy stdout.fm are creating 클라우드, 소프트웨어 개발, 전자 제품에 대해 이야기하는 프로그래머들의 팟캐스트 | Patreon 카카오페이 QR결제 totu

Melissa Boggs (@HmngbirdAgility) joined Ryan Ripley (@ryanripley) to discuss her new role as co-CEO at Scrum Alliance, the power of cross-functional teams, and how to use HR practices in an agile world. Melissa Boggs – Chief Scrum Master at Scrum Alliance In this episode you’ll discover: What’s happening over at Scrum AllianceHow to make transformations to agile organizations more likely to succeedWhen agile values can help influence hiring decisions Links from the show: Scrum Alliance – https://www.scrumalliance.org/ Melissa Boggs – https://www.linkedin.com/in/melissa-boggs/Joy Inc. by Richard Sheridan – https://amzn.to/30AOcrQScrum Alliance Unscripted – https://www.scrumalliance.org/unscripted Take a Scrum.org Class with PST Ryan Ripley – https://www.scrum.org/ryan-ripleyRead Ryan’s New Book now in BETA – https://pragprog.com/book/rrscrum/fixing-your-scrum How to Support the Show: Thank you for your support. Here are some of the ways to contribute that were discussed during this episode: Share the show with friends, family, colleagues, and co-workers. Sharing helps get the word out about Agile for HumansRate us on iTunes and leave an honest reviewJoin the mailing list – Check out the form on the right side of the pageTake the survey – totally anonymous and helps us get a better idea of who is listening and what they are interested inLeadership Gift ProgramMake a donation via Patreon Buy Ryan’s New Book: Broken Scrum practices limit your organization’s ability to take full advantage of the agility Scrum should bring: The development team isn’t cross-functional or self-organizing, the product owner doesn’t get value for their investment, and stakeholders and customers are left wondering when something—anything—will get delivered. Learn how experienced Scrum masters balance the demands of these three levels of servant leadership, while removing organizational impediments and helping Scrum teams deliver real-world value. Discover how to visualize your work, resolve impediments, and empower your teams to self-organize and deliver using advanced coaching and facilitation techniques that honor and support the Scrum values and agile principles. Click here to purchase on The Pragmatic Bookshelf. Want to hear another podcast about the life of an agile coach? — Listen to my conversation with Zach Bonaker, Diane Zajac-Woodie, and Amitai Schlair on episode 39. We discuss growing an agile practice and how coaches help create the environments where agile ideas can flourish. The post AFH 109: Agile Organizations with Melissa Boggs appeared first on Ryan Ripley.

Join Tammy Coron and Tim Mitra on Episode 134, which was recorded on July 3, 2019. On this episode, they talk with Daniel Pritchett. Daniel is the human purveyor of chatbots and the author of Build Chatbot Interactions: Responsive, Intuitive Interfaces with Ruby published by the Pragmatic Bookshelf. If you like listening to Roundabout: Creative Chaos, and you want to know how you can help support the show, please visit RoundaboutFM.com for details. Your support helps us cover the costs of hosting, post-production, and other administrative fees.

Dave Thomas and Andy Hunt, best known as the authors of The Pragmatic Programmer and founders of The Pragmatic Bookshelf, joined the show today to talk about the 20th anniversary edition of The Pragmatic Programmer. This is a beloved book to software developers all over the world, so we wanted to catch up with Andy and Dave to talk about how this book came to be, some of the wisdom shared in its contents, as well as the impact it’s had on the world of software. Also, the beta book is now “fully content complete” and is going to production. If you decide to pick up the ebook, you’ll get a coupon for 50% off the hardcover when it comes out this fall.

Dave Thomas and Andy Hunt, best known as the authors of The Pragmatic Programmer and founders of The Pragmatic Bookshelf, joined the show today to talk about the 20th anniversary edition of The Pragmatic Programmer. This is a beloved book to software developers all over the world, so we wanted to catch up with Andy and Dave to talk about how this book came to be, some of the wisdom shared in its contents, as well as the impact it’s had on the world of software. Also, the beta book is now “fully content complete” and is going to production. If you decide to pick up the ebook, you’ll get a coupon for 50% off the hardcover when it comes out this fall.

We look at a recent SIM port hack where a crypto professional lost $100k worth of crypto from his Coinbase account. We discuss in detail how he was attacked and how you can safeguard your crypto assets better. We then do a recap of the one-day Elixir conference, Empex, where topics ranged from OTP to LiveView to functional programming more broadly. Topics: What a SIM port attack is How people can be careful Their experience at Empex Their thoughts on Elixir Links: The Most Expensive Lesson Of My Life: Details of SIM port hack - https://medium.com/coinmonks/the-most-expensive-lesson-of-my-life-details-of-sim-port-hack-35de11517124 Monero’s Fluffy Pony - https://twitter.com/fluffypony/status/1130555634330554368?s=21 EMPEX - https://empex.co/nyc.html Erlang Ecosystem Foundation - https://erlef.org/ SimpleBet - https://simplebet.io/ Frame.io - https://frame.io/ Manning - https://www.manning.com/ The Pragmatic Bookshelf - https://pragprog.com/ How to use Mint - https://scoutapm.com/blog/how-to-use-mint-an-awesome-http-library-for-elixir-part-01

Join Tammy Coron and Tim Mitra on Episode 128, which was recorded on April 11, 2019. On this episode, they talk with Roman Zabicki. Roman is the author of Practical Security, the first security book from The Pragmatic Bookshelf. He has a BA in computer science from the University of Chicago and has worked in software full-time since 1999. If you like listening to Roundabout: Creative Chaos, and you want to know how you can help support the show, please visit RoundaboutFM.com for details. Your support helps us cover the costs of hosting, post-production, and other administrative fees.

An airhacks.fm conversation with Simon Harrer (@simonharrer) about: Amstrad Laptop, first line of VB code was a commercial one, customers two desks away, Scheme is an excellent language to learn programming, Java is great - mainly because of the tool support, Eclipse was the first opensource IDE with decent refactoring support, Bamberg is the home of Schlenkerla, teaching is the best way to learn, therefore teaching is selfish, building portals for students with PHP and Joomla, building e-commerce shops for students with Ruby on Rails, 2006 everything had to be Rails, PhD about choreography and distributed transactions, too high expectations on workflow and rule engines, workflow engines are for developers and not for business people, central process view is still desirable, startups with Bosch, in Germany it is hard to find developers who are willing to join startups, Simon works for InnoQ and Stefan Tilkov, Computer Science University of Bamberg, the pragmatic book: Java by Comparison by The Pragmatic Bookshelf, in streams there are no exceptions, over-abstractions cause trouble, reviewing the code of thousands of students for six years, it is unusual for universities to promote pragmatic code, be strict about adding external libraries, clear separation between infrastructure and business logic helps with clean code, moving domain specific libraries into the infrastructure, human centered code, optimizing for machines, not for humans is problematic, writing bad code is often not intentional, "Abstract, If, Impl, Default, Bean Conventions - Just For Lazy Developers", don't write for reuse, reuse rarely happens, reuse as motivator for bad abstractions, do repeat yourself, than refactor, "How To Comment With JavaDoc", Book: Java by Comparison, Become a Java Craftsman in 70 Examples, Simon Harrer on twitter: (@simonharrer).

Andy Hunt and Dave Thomas wrote the seminal software development book, The Pragmatic Programmer. Together they founded The Pragmatic Programmers and are well known as founders of the agile movement and authors of the Agile Manifesto. They founded the Pragmatic Bookshelf publishing business in 2003. The Pragmatic Bookshelf published it's most important book, in my opinion, in 2017 with the first pytest book (https://pragprog.com/book/bopytest/python-testing-with-pytest) available from any publisher. Topics: * The Pragmatic Programmer (https://pragprog.com/book/tpp/the-pragmatic-programmer), the book * The Manifesto for Agile Software Development (https://agilemanifesto.org/) * Agile methodologies and lightweight methods * Some issues with "Agile" as it is now. * The GROWS Method (https://growsmethod.com/) * Pragmatic Bookshelf (https://pragprog.com/), the publishing company * How Pragmatic Bookshelf is different, and what it's like to be an author (http://write-for-us.pragprog.com/) with them. * Reading and writing sci-fi novels, including Conglommora (https://conglommora.com/), Andy's novels. * Playing music (https://andyhunt.bandcamp.com/). Special Guest: Andy Hunt.

GUEST BIO: Dave is a computer programmer and was an original signatory and author of The Manifesto For Agile Software Development.  He has also co-authored several books, including “The Pragmatic Programmer”, and was a co-founder of the Pragmatic Bookshelf. EPISODE DESCRIPTION: Dave Thomas is Phil’s guest on today’s show. He is a well-known programmer who works in numerous programming languages, in particular, Elixir, Ruby and agility. Dave is one of the original signatories and author of The Manifesto for Agile Software Development. Over the years, Dave has published several other books and is a trainer. Currently, he is also an Adjunct Professor at the Southern Methodist University. KEY TAKEAWAYS: (0.45) – So, Dave, can you expand on that brief introduction and tell us a little bit more about yourself? Dave says that fundamentally he is a programmer. For the past 45 years he has enjoyed coding and has done it practically every day. Most of the other things, he does really just to make a living. For example, he published more books when things crashed in the early 2000s. Even then, he spent time writing the various bits of infrastructure, he just could not stay away from the code. (3.08) – Are you still involved in the pragmatic? Dave says that about 18 months ago, with Andy’s agreement, he stepped back a bit on the day-to-day stuff. He had other things he wanted to investigate and basically did not have enough time to do so. Right now, he is almost like a Victorian gentleman scientist exploring things on his own. But, he has spent about a year shuttling from one thing to another. He is now focused again. (4.21) – Phil asks Dave to share a unique IT career tip. We work in the fastest changing industry that ever existed, so you need to keep up. You can’t know everything, but you can look at what is coming up and pick a few things that are likely to make it. Then spend a bit of time learning and researching those. (5.20) – A lot of people say my employer does not give me time to do that. Dave’s response is that is not your employer’s job. It is your career - you need to invest in yourself. If you do not, you and your skills will slowly become irrelevant as new technology replaces what you are good at. (6.11) – Dave is asked to share his worst career moment and what he learned from that experience. After 45 years, Dave has understandably had quite a few bad career moments. At least, things that felt bad at the time. But, usually he learned a lot from those situations. So, in the end, many of those experiences turned out to be positive ones. When you are working in such a malleable format it is very easy to mess things up. However, with a bit of discipline and patience, it is also very easy to fix the problem. (7.29) – Phil asks Dave what his best career moment was. Dave explained that, like most people, he has a need to create. So, when he finds his “software expressing me” he gets a lift. A great example of this is the Prestel videotext system, from the 1970s. Dave was involved in writing a front end so that people could find flight availability and book them via travel agents. One day, Dave was walking down a High Street, looked in a travel agents window and saw his software running. Seeing that brought home the fact that what he was doing really was making a difference. (9.53) – Dave explained that whenever he publishes a book, he also goes to a bookstore to see it on the shelf. Seeing a physical manifestation of your work helps you to fully appreciate what you have achieved and is very fulfilling. (11.11) – So, Dave what excites you about the future of the IT industry and careers in IT in particular? For Dave the fact that in IT you are shaping the world, literally. You cannot do much, these days, without IT. We can do great things with IT, which is exciting. In the very near future our coding will become part of the fabric of life. Now we code things that mainly happen via a screen or browser. In the future, our work will become an ambient background to people’s lives. That is a phenomenal responsibility, but incredibly empowering. (13.31) – What first attracted you to a career in IT? When Dave did his A-levels he took them a year earlier, so had no work to do at school. Fortunately, he was not allowed to simply leave. Instead, his school sent him across the road to take the first-ever A-level UK programming classes. They were using Basic, with a teletype paper tape punch, but Dave was captivated by the work. He had planned to study math, instead he studies software at university and begun his IT career. (15.31) – What is the best career advice you were given? Dave’s first job was working for a startup. They were asked to produce a coupon compiler, by a client. The director of that company had quite a bit of technical understanding, but there were some important gaps in his knowledge. So, at some point in the meeting Dave said – “No, you’re wrong. That’s not right” blah, blah. There was a deathly silence. At which point his boss stepped in and moved things along. Afterward the meeting he apologized. But, his boss said “No it’s OK, you did the right thing, just not in the right way.” That incident stayed with him. It made Dave realize that we should not be saying yes all the time. Instead, we have to find a way of saying no without putting people’s backs up. (16.43) – If you were to start your IT career again, right now, what would you do? Dave replied “It depends”, but he would probably not go to college or university. Instead, he would look for a company that ran a good apprenticeship scheme and join. He would then spend 5 to 10 years flitting across different areas. At that point, he would reflect on those years and work out the thing that he enjoyed the most and work in that field. Phil agreed that was a good approach. People tend to forget that taking a job is not a lifetime commitment. In the early days, it is probably only an 18-month commitment. Nobody expects any more from you, so it makes sense to take advantage of that fact and move around until you find something you love doing. (19.15) – Phil asks Dave what he is currently focusing on for his career. Dave says “changing the world”, kind of. Right now, he has two main aims. Firstly, he wants to encapsulate and share what he has learned. He is on the board of a company that teaches genuine software skills to 8 to 14-year-olds. These days, coding literacy is as important as any foreign language. The other objective is to simplify software development. Things do not have to be anywhere near as complicated as they are now. Dave believes we can make software development far easier and is working on doing exactly that. (21.25) – What is the number one non-technical skill that has helped you the most in your IT career? Dave says that enjoying learning has helped him tremendously. Being able to move across industries and learn your client’s jobs, how they work and what their problems are all helps you to build software that solves the real problem, rather than just meeting the spec. (22.46) – Phil asks Dave to share a final piece of career advice. Dave says that you need to “remember to make it fun.” You need to look forward to going to work, at least most of the time. If you feel that way you will do a good job. BEST MOMENTS: (3.06) DAVE – “You just can't keep me away from the code.” (3.39) DAVE – “I've been almost like a Victorian gentlemen scientist for the last two years, just exploring stuff on my own.” (5.38) DAVE – “The most important tip is to invest in yourself. To keep yourself current, spend some time and a little bit of money on a personal level, just to make sure that you're still relevant.” (7.24) DAVE – “I honestly think it's an important thing to learn that if you break it, you can fix it.” (9.54) PHIL – “I think seeing what you produce in action is self-fulfilling, in some ways.” (13.07) DAVE – “The most exciting thing to look forward to is a future where we can really genuinely make the world better.” CONTACT DAVE THOMAS: Twitter: https://twitter.com/pragdave @pragdave LinkedIn: https://www.linkedin.com/in/dave-thomas-53aa1057/ Website: https://pragprog.com/

In today’s episode, Phil chats with Andy Hunt. Andy is a programmer turned consultant, author and publisher. He’s authored a dozen books including the best-selling “The Pragmatic Programmer,” and was one of the 17 authors of the Agile Manifesto and founders of the Agile Alliance. He also co-founded the pragmatic bookshelf, publishing award-winning and critically acclaimed books for software developers. Andy shares his story about why he chose I.T as his career and reveals his best and worst experiences in the I.T world. Listen to his career tips and advice. There is a lot to learn from Andy that will help you to become the best that you can be. KEY TAKEAWAYS: [1:21] Phil asks Andy to expand upon the brief introduction provided. Andy shares the story of how he had a real interest in radio electronics at that time. He says that he was very interested in early computers with the S100 BUS and CPM. He recalls that he loved how programming lets you go in and create your own world which, for Andy, is still the most exciting aspect of it. Andy says that programming was easier and much more self-contained back then. The programming world is a very different place than it used to be. [2:41] Phil requests for Andy to share a unique career tip for the I.T Career Energizer audience, one that the audience should know but don’t. Andy excitedly answers that he’ll give two tips. He talks about his 2008 book “Pragmatic Thinking and Learning”, the thesis being that the two things you do more than anything else as a programmer are learning and communication. We communicate with the machine. We communicate with each other, and to end users to gather requirements, to learn requirements. Besides the tech stacks and the latest language of the day, you’re learning how the evolving system behave, you’re learning how your team behaves, and you’re learning how the end users work and what they expect, what the market demands. So, we’re all about learning in communication. Those are the important things. [3:42] Andy’s first tip is to never stop learning. When you come across something unfamiliar, a term you don’t know, a framework you’ve never heard of, a new language, look it up, Google’s right there. It’s on your phone. It’s right on your screen. Take the 5 seconds when something you’re unfamiliar with comes up and see what it is. Look into it. Look more into it if it’s something interesting or something that you might have to work with. So, always take that extra step and pursue the unfamiliar. That’s part one. [4:16] Andy says that this second tip makes the biggest difference for people who are successful. Always write down your ideas. Carry something with you always where you can jot down a quick note. It doesn’t have to be electronic. It might even be better if it’s not. Use an App on your phone, send yourself a voicemail. Andy says that he found out that most of the processes in the brain are asynchronous. You get interesting ideas or the seeds of great ideas randomly and usually when you’re not at a computer and not at work. So you need something with you to jot them down because you won’t remember it later. And then, when you have a chance later, when you’re at the computer, when you’re working, whatever, follow up on it. Make a note somewhere else more permanently. That’s really key to capturing the great ideas that you have but most people just loose. And Phil totally agrees with the idea. [6:54] Phil asks about Andy’s worst career moment and what he has learned from it. Andy recalls a story from early in his career when, between the time of being interviewed and starting the job, his interviewer had been fired and the position eliminated. Andy was therefore assigned to a different group. It was an awful place to work and within a year the company went out of business which made an impact on him. The myth of working for a big company and having stability is just a myth. You’re not stable with a big company. You’re not necessarily stable with a small startup either. So, in terms of career preparation, you really can’t count on the organization being there for you for any number of reasons. Later on, during Andy’s consultant career phase, one project that he rather enjoyed and he had a good time at. It was very clear from their practices and what they were doing on the project that they were going to fail. Andy made his report, talked to the boss and said, “Okay, here’s the problem. This is what you need to fix.” They said, “Thank you very much.” and didn’t change a thing. They lost $14 million. That was a lot of what inspired Andy to get on the early train of lightweight methods which was when the term ‘agile’ was coined. Andy then provides some insight into the Agile Manifesto. [12:34] Phil asks about Andy’s career greatest success. Andy recalls one of his projects which was highly successful. It was replace a debit card transaction system. In fact, that’s the project where Andy met his partner Dave Thomas. They wrote “The Pragmatic Programmer” together and founded the Pragmatic Bookshelf. He recalls that it was one of those insane projects where it was just the two of them. The key was that they had access to an on-site customer who knew the existing system inside and out. They got the project done and the system was subsequently the preferred solution when the company merged with other companies. Andy and Dave’s system did what it was supposed to do and did it better than the other companies solutions that cost a lot more money and had been written by large teams. [15:46] Phil asks Andy about the future of the industry and careers in IT. Andy says that he is amazed when he watches his nephews and nieces, toddler age, navigating an iPad and buying apps. The idea that being able to learn at an early age how computers work and how to create and adapt software yourself, that’s critical. Because if you don’t take that next step and learn how to manipulate this world, you’ll be powerless in the future. He adds that he thinks we’ve barely scratched the surface of technology. [18:42] Phil asks what first attracted Andy to a career in IT? Andy recalls when he was at a radio shack, it was in the 70’s, and there was a book about microcomputers. Andy thought that it was fascinating and as cool as any science fiction he had ever read. The author was convinced that this is going to happen in the future. It wet Andy’s appetite and he started from there. [18:54] Phil asks what the best advice Andy has ever received. Andy says don’t focus solely on the technology because the tech comes and goes. And the companies behind the tech come and go. Andy says that people are much harder to program and deal with than with computers, but this is the world we now live in. This is what you’ve got to learn to do. If you focus solely on the tech, you’re going to get steamrolled. [23:15] Phil then asks Andy what he would do if he had to begin his IT career again right now. Andy says that it would be AI, genetic algorithms, machine learning, that whole world. [24:59] Phil asks Andy what objectives he is currently focusing on and Andy says that it’s retirement and going out with a bang. He wants to come up with something interesting. [25:22] Phil then asks Andy what has been the number one non-technical skill that has helped him in his career so far. Andy thinks that all non-technical skills are critical. The sort of basics such as continuous learning and reading voraciously. Read everything you get your hands on. Write to remember. Take note and summarize. Write it in your own words. The act of writing stuff down like that really helps wire it in and to cement it in your memory. Do user group talks or write a blog if you don’t like talking in front of people. Talk to people at work, such as brown bag lunches. Be an advocate for the stuff that you’ve discovered, that you’re passionate about and that’s interesting. [26:37] Phil asks Andy for a parting piece of career advice. Andy thinks that the number one piece of advice is to realize that you’re never done and that you’ve never made it. If you’ve learned some great framework, some great language, don’t stop there. The technology, the methodology that you used in the last project that was so successful might not work at all in the next project. That could be a completely different context. You might need completely different tools. So, the number one thing is to be prepared for that and to be ready to learn something completely different all the time. BEST MOMENTS [18:00] Andy: “Turbo Pascal when it came out was brilliant. It was 79 bucks and it included an IDE and a multi-pass compiler, and it was like, “Oh my God that genius.” At the time that was a real breakthrough. These days you can get the hardware and any language you’ve ever heard of and just download it. So I think that’s pretty exciting and pretty remarkable and I think we’ve barely scratched the surface of where we can go with that.” “The stuff you learn in college you probably will not use much more than the first couple of years out in the world just because things change. So the tech comes and goes, and that’s fine. You need to know the basics. You need to understand how it all works at the lowest level.” “The hard part is that the tech keeps improving, but people are still people, and we are deeply flawed creatures. We are not like these brilliant computers that we work with. We have got major cognitive processing issues.” “You have to remember that whatever you think of the pace of change at the moment, this is the slowest that the pace of change will ever be because it is ever increasing. So as bad as it is now, this is slower. It’s going to be slightly faster tomorrow and slightly faster the day after that, on and on and on and on. So if you want to keep up, you have to keep going.” ABOUT THE HOST Phil Burgess, an I.T. consultant, mentor, and coach, is the creator and host of the I.T. Career Energizer Podcast. His podcast continues to inspire, assist and guide anybody wanting to start, develop and grow a career in I.T. by inviting successful I.T. professionals, consultants, and experts to share their advice, career tips and experiences. CONTACT THE HOST Website: itcareerenergizer.com LinkedIn: www.linkedin.com/in/philburgess     ABOUT THE GUEST Andy is a programmer turned consultant, author and publisher. He’s authored a dozen books including the best-selling The Pragmatic Programmer, was one of the 17 authors of the Agile Manifesto and founders of the Agile Alliance and co-founded the Pragmatic Bookshelf, publishing award-winning, critically-acclaimed books for software developers. CONTACT ANDY HUNT Andy’s Website – www.toolshed.com Twitter – https://twitter.com/PragmaticAndy @PragmaticAndy LinkedIn - https://www.linkedin.com/in/pragmaticandy/ The Pragmatic Programmer – www.pragprog.com Andy’s Latest Sci-fi book – www.conglommora.com Software Methodologies – www.growsmethod.com  

Panel: Charles Max Wood Guest: Andy Hunt This week on My Ruby Story, Charles talks to Andy Hunt. Andy has previously been on Ruby Rogues for Episode 277, and is known for his book The Pragmatic Programmer, his company The Pragmatic Bookshelf, and much more. He first got into programming because of his interest in electronic music and his first RadioShack project he created, which led him to finding a book on the future of integrated circuits. They talk about how he found Ruby, why he wrote Programming Ruby, what he is working on now, and more! In particular, we dive pretty deep on: Ruby Rogues Episode 277 His book The Pragmatic Programmer His company The Pragmatic Bookshelf How did you first get into programming? Interest in electronic music RadioShack project Book on the future of integrated circuits Fire in the Valley by Michael Swaine Exposure to the programming as it was being born How did you find Ruby? Time as a consultant Needed a flexible and fast language Couldn’t use C++ or Java Using Perl Amazed by the Unix shell Loved that he could write pages of code that would actually work Lacked documentation in the beginning Writing his Programming Ruby book Been messing around with Elixir recently Ruby is still his number one language And much, much more! Links: Ruby Rogues Episode 277 The Pragmatic Programmer The Pragmatic Bookshelf Fire in the Valley by Michael Swaine Ruby Perl Programming Ruby Elixir Andy’s GitHub @PragmaticAndy Andy’s Website @pragprog Sponsors: FreshBooks Picks: Charles Google Drive ScanSnap S1300i Andy PragProg.com

Panel: Charles Max Wood Guest: Andy Hunt This week on My Ruby Story, Charles talks to Andy Hunt. Andy has previously been on Ruby Rogues for Episode 277, and is known for his book The Pragmatic Programmer, his company The Pragmatic Bookshelf, and much more. He first got into programming because of his interest in electronic music and his first RadioShack project he created, which led him to finding a book on the future of integrated circuits. They talk about how he found Ruby, why he wrote Programming Ruby, what he is working on now, and more! In particular, we dive pretty deep on: Ruby Rogues Episode 277 His book The Pragmatic Programmer His company The Pragmatic Bookshelf How did you first get into programming? Interest in electronic music RadioShack project Book on the future of integrated circuits Fire in the Valley by Michael Swaine Exposure to the programming as it was being born How did you find Ruby? Time as a consultant Needed a flexible and fast language Couldn’t use C++ or Java Using Perl Amazed by the Unix shell Loved that he could write pages of code that would actually work Lacked documentation in the beginning Writing his Programming Ruby book Been messing around with Elixir recently Ruby is still his number one language And much, much more! Links: Ruby Rogues Episode 277 The Pragmatic Programmer The Pragmatic Bookshelf Fire in the Valley by Michael Swaine Ruby Perl Programming Ruby Elixir Andy’s GitHub @PragmaticAndy Andy’s Website @pragprog Sponsors: FreshBooks Picks: Charles Google Drive ScanSnap S1300i Andy PragProg.com

Panel: Charles Max Wood Guest: Andy Hunt This week on My Ruby Story, Charles talks to Andy Hunt. Andy has previously been on Ruby Rogues for Episode 277, and is known for his book The Pragmatic Programmer, his company The Pragmatic Bookshelf, and much more. He first got into programming because of his interest in electronic music and his first RadioShack project he created, which led him to finding a book on the future of integrated circuits. They talk about how he found Ruby, why he wrote Programming Ruby, what he is working on now, and more! In particular, we dive pretty deep on: Ruby Rogues Episode 277 His book The Pragmatic Programmer His company The Pragmatic Bookshelf How did you first get into programming? Interest in electronic music RadioShack project Book on the future of integrated circuits Fire in the Valley by Michael Swaine Exposure to the programming as it was being born How did you find Ruby? Time as a consultant Needed a flexible and fast language Couldn’t use C++ or Java Using Perl Amazed by the Unix shell Loved that he could write pages of code that would actually work Lacked documentation in the beginning Writing his Programming Ruby book Been messing around with Elixir recently Ruby is still his number one language And much, much more! Links: Ruby Rogues Episode 277 The Pragmatic Programmer The Pragmatic Bookshelf Fire in the Valley by Michael Swaine Ruby Perl Programming Ruby Elixir Andy’s GitHub @PragmaticAndy Andy’s Website @pragprog Sponsors: FreshBooks Picks: Charles Google Drive ScanSnap S1300i Andy PragProg.com

Join Tammy Coron and Tim Mitra on Episode 108, which was recorded on April 08, 2018. On this episode, they talk with Chris Adamson. Chris is a freelance iOS and Mac developer and the co-author of iPhone 10 SDK Development and Learning Core Audio. His most recent book, Xcode Treasures, is available at The Pragmatic Bookshelf website. If you like listening to Roundabout: Creative Chaos, and you want to know how you can help support the show, please visit our Patreon page at patreon.com/justwritecode.

MRS 014 Noel Rappin Today's episode is a My Ruby Story with Noel Rappin. Noel talked about his contributions to the Ruby community and how they explore new technologies like Elixir. Listen to learn more about Noel! [00:01:40] – Introduction to Noel Rappin Noel is in episodes 30, which was about Software Craftsmanship. He was also on episode 185, which was about Rails 4 Test Prescriptions. And then, the latest one was 281, which was about Take My Money. [00:02:45] – How did you get into programming? Noel is a stereotypical nerdy kid so he started programming when he was young. He had afterschool classes in Applesoft BASIC at a place near their house. He had TRS-80 and Texas Instruments, and a couple of other things. [00:03:35] – Computer Science degree Noel has a Computer Science degree and a Ph.D. from the College of Computing at Georgia Tech, which was in the intersection of user interface design and Ed tech. He was designing interfaces for teaching, specifically for teaching engineers and developers. [00:04:15] – How did you get into Ruby? Noel came out of grad school immediately and went to a small web development company. He started hearing about Rails in about 2005. Having been one of the people who have done a lot of the Java-Struts web development that Rails was created in opposition to, Noel searched it up pretty quickly. But he started using it in 2005 or 2006 for some internal tools for his team. He built a test tracker and other things that his team is using internally. He built a couple of web apps for them to collaborate because they were working with some developers in Poland. And as he got comfortable with it, he contracted to do a Ruby on Rails book and got a full-time professional Ruby job. [00:06:30] – What is it about Ruby that got you excited? Noel has always like scripting languages and dynamic languages. He did a lot of work on Python for a while. It was extraordinary how quickly you do things in Rails compared to Java tools, even compared to Django, which was more or less contemporaneous. Ruby emphasized testing and Rails was very similar to some of the tools that he was building in Python. [00:08:50] – Books and contributions to the Ruby community Noel had a book which was out of date, 30 to 40 seconds after it was published. It’s normal in this industry. Sometime after that, he started publishing Rails Test Prescriptions and submitted it to the Pragmatic Bookshelf, and they purchased it. They published Rails Test Prescription 6 years. After that, he did a series of self-published JavaScript books called Master Space and Time with JavaScript. They are also out of date but they’re free now. He also did a self-published book about projects called Trust-Driven Development that you can still get. He did a book about purchasing, handling money and web purchases, and mostly this API called Take My Money, which came out last summer. Noel is currently working on a Rails 5 Test Prescriptions, which will include all the new Rails 5.1. It will come out this fall. [00:10:35] – Table XI Noel works at Table XI, which is a web consulting firm in Chicago with about 35 people. They do Rails development, websites, mobile development and a lot of React Native development. They build websites for companies that are not web software companies but companies that need web pages like non-profit or start-ups. They like to focus on solid business problems in software, rather than technology problems in software. [00:11:15] – What are you working on these days? Noel has his own podcast called Tech Done Right. The latest episode was with Michael Feathers. There is also an episode with somebody who is in charge of the Medicare Program under President Obama, who was actually the person who was called in to fix healthcare.gov and had some interesting stories about what that was like from a software manager perspective. From the development side, Noel has been doing a lot of Rails development, some JavaScript development, building purchase-sides for nonprofit, and doing a lot of upgrade work recently. [00:12:40] – Rails upgrades story This upgrade was for a Rails 2 application that was still in active development. The Rails community, at one point, was so bad at managing upgrades. And now, it does seem like the community has gotten better at managing new tools without breaking old ones. The security needs have pushed people towards the best practices. [00:14:15] – Ruby and Elixir Like a lot of Ruby companies, they’ve been exploring what the next tools are. They ran an Elixir project. It’s originally an internal prototype, which is a great way to get new technologies into the company. They wound up building a small project that was largely API focused. That’s the kind of thing that Rails is not super great at. They’re exploring what to do with front-end because there’s a sharp understanding of what Ruby on Rails is good for and what might be the purview of other tools. Elixir does a couple of things that Ruby doesn’t do very well. A lot of people who start with Ruby can learn a lot from going off to a functional language like Elixir or something that has a pattern-matching type of language like Elixir. Picks Noel Rappin R programming Podcast: Tech Done Right Author: Martha Wells The Murderbot Diaries by Martha Well Atom Editor Audio Hijack Bear Twitter @noelrap noelrappin.com Charles Max Wood Mighty Mug Phrase Express

MRS 014 Noel Rappin Today's episode is a My Ruby Story with Noel Rappin. Noel talked about his contributions to the Ruby community and how they explore new technologies like Elixir. Listen to learn more about Noel! [00:01:40] – Introduction to Noel Rappin Noel is in episodes 30, which was about Software Craftsmanship. He was also on episode 185, which was about Rails 4 Test Prescriptions. And then, the latest one was 281, which was about Take My Money. [00:02:45] – How did you get into programming? Noel is a stereotypical nerdy kid so he started programming when he was young. He had afterschool classes in Applesoft BASIC at a place near their house. He had TRS-80 and Texas Instruments, and a couple of other things. [00:03:35] – Computer Science degree Noel has a Computer Science degree and a Ph.D. from the College of Computing at Georgia Tech, which was in the intersection of user interface design and Ed tech. He was designing interfaces for teaching, specifically for teaching engineers and developers. [00:04:15] – How did you get into Ruby? Noel came out of grad school immediately and went to a small web development company. He started hearing about Rails in about 2005. Having been one of the people who have done a lot of the Java-Struts web development that Rails was created in opposition to, Noel searched it up pretty quickly. But he started using it in 2005 or 2006 for some internal tools for his team. He built a test tracker and other things that his team is using internally. He built a couple of web apps for them to collaborate because they were working with some developers in Poland. And as he got comfortable with it, he contracted to do a Ruby on Rails book and got a full-time professional Ruby job. [00:06:30] – What is it about Ruby that got you excited? Noel has always like scripting languages and dynamic languages. He did a lot of work on Python for a while. It was extraordinary how quickly you do things in Rails compared to Java tools, even compared to Django, which was more or less contemporaneous. Ruby emphasized testing and Rails was very similar to some of the tools that he was building in Python. [00:08:50] – Books and contributions to the Ruby community Noel had a book which was out of date, 30 to 40 seconds after it was published. It’s normal in this industry. Sometime after that, he started publishing Rails Test Prescriptions and submitted it to the Pragmatic Bookshelf, and they purchased it. They published Rails Test Prescription 6 years. After that, he did a series of self-published JavaScript books called Master Space and Time with JavaScript. They are also out of date but they’re free now. He also did a self-published book about projects called Trust-Driven Development that you can still get. He did a book about purchasing, handling money and web purchases, and mostly this API called Take My Money, which came out last summer. Noel is currently working on a Rails 5 Test Prescriptions, which will include all the new Rails 5.1. It will come out this fall. [00:10:35] – Table XI Noel works at Table XI, which is a web consulting firm in Chicago with about 35 people. They do Rails development, websites, mobile development and a lot of React Native development. They build websites for companies that are not web software companies but companies that need web pages like non-profit or start-ups. They like to focus on solid business problems in software, rather than technology problems in software. [00:11:15] – What are you working on these days? Noel has his own podcast called Tech Done Right. The latest episode was with Michael Feathers. There is also an episode with somebody who is in charge of the Medicare Program under President Obama, who was actually the person who was called in to fix healthcare.gov and had some interesting stories about what that was like from a software manager perspective. From the development side, Noel has been doing a lot of Rails development, some JavaScript development, building purchase-sides for nonprofit, and doing a lot of upgrade work recently. [00:12:40] – Rails upgrades story This upgrade was for a Rails 2 application that was still in active development. The Rails community, at one point, was so bad at managing upgrades. And now, it does seem like the community has gotten better at managing new tools without breaking old ones. The security needs have pushed people towards the best practices. [00:14:15] – Ruby and Elixir Like a lot of Ruby companies, they’ve been exploring what the next tools are. They ran an Elixir project. It’s originally an internal prototype, which is a great way to get new technologies into the company. They wound up building a small project that was largely API focused. That’s the kind of thing that Rails is not super great at. They’re exploring what to do with front-end because there’s a sharp understanding of what Ruby on Rails is good for and what might be the purview of other tools. Elixir does a couple of things that Ruby doesn’t do very well. A lot of people who start with Ruby can learn a lot from going off to a functional language like Elixir or something that has a pattern-matching type of language like Elixir. Picks Noel Rappin R programming Podcast: Tech Done Right Author: Martha Wells The Murderbot Diaries by Martha Well Atom Editor Audio Hijack Bear Twitter @noelrap noelrappin.com Charles Max Wood Mighty Mug Phrase Express

MRS 014 Noel Rappin Today's episode is a My Ruby Story with Noel Rappin. Noel talked about his contributions to the Ruby community and how they explore new technologies like Elixir. Listen to learn more about Noel! [00:01:40] – Introduction to Noel Rappin Noel is in episodes 30, which was about Software Craftsmanship. He was also on episode 185, which was about Rails 4 Test Prescriptions. And then, the latest one was 281, which was about Take My Money. [00:02:45] – How did you get into programming? Noel is a stereotypical nerdy kid so he started programming when he was young. He had afterschool classes in Applesoft BASIC at a place near their house. He had TRS-80 and Texas Instruments, and a couple of other things. [00:03:35] – Computer Science degree Noel has a Computer Science degree and a Ph.D. from the College of Computing at Georgia Tech, which was in the intersection of user interface design and Ed tech. He was designing interfaces for teaching, specifically for teaching engineers and developers. [00:04:15] – How did you get into Ruby? Noel came out of grad school immediately and went to a small web development company. He started hearing about Rails in about 2005. Having been one of the people who have done a lot of the Java-Struts web development that Rails was created in opposition to, Noel searched it up pretty quickly. But he started using it in 2005 or 2006 for some internal tools for his team. He built a test tracker and other things that his team is using internally. He built a couple of web apps for them to collaborate because they were working with some developers in Poland. And as he got comfortable with it, he contracted to do a Ruby on Rails book and got a full-time professional Ruby job. [00:06:30] – What is it about Ruby that got you excited? Noel has always like scripting languages and dynamic languages. He did a lot of work on Python for a while. It was extraordinary how quickly you do things in Rails compared to Java tools, even compared to Django, which was more or less contemporaneous. Ruby emphasized testing and Rails was very similar to some of the tools that he was building in Python. [00:08:50] – Books and contributions to the Ruby community Noel had a book which was out of date, 30 to 40 seconds after it was published. It’s normal in this industry. Sometime after that, he started publishing Rails Test Prescriptions and submitted it to the Pragmatic Bookshelf, and they purchased it. They published Rails Test Prescription 6 years. After that, he did a series of self-published JavaScript books called Master Space and Time with JavaScript. They are also out of date but they’re free now. He also did a self-published book about projects called Trust-Driven Development that you can still get. He did a book about purchasing, handling money and web purchases, and mostly this API called Take My Money, which came out last summer. Noel is currently working on a Rails 5 Test Prescriptions, which will include all the new Rails 5.1. It will come out this fall. [00:10:35] – Table XI Noel works at Table XI, which is a web consulting firm in Chicago with about 35 people. They do Rails development, websites, mobile development and a lot of React Native development. They build websites for companies that are not web software companies but companies that need web pages like non-profit or start-ups. They like to focus on solid business problems in software, rather than technology problems in software. [00:11:15] – What are you working on these days? Noel has his own podcast called Tech Done Right. The latest episode was with Michael Feathers. There is also an episode with somebody who is in charge of the Medicare Program under President Obama, who was actually the person who was called in to fix healthcare.gov and had some interesting stories about what that was like from a software manager perspective. From the development side, Noel has been doing a lot of Rails development, some JavaScript development, building purchase-sides for nonprofit, and doing a lot of upgrade work recently. [00:12:40] – Rails upgrades story This upgrade was for a Rails 2 application that was still in active development. The Rails community, at one point, was so bad at managing upgrades. And now, it does seem like the community has gotten better at managing new tools without breaking old ones. The security needs have pushed people towards the best practices. [00:14:15] – Ruby and Elixir Like a lot of Ruby companies, they’ve been exploring what the next tools are. They ran an Elixir project. It’s originally an internal prototype, which is a great way to get new technologies into the company. They wound up building a small project that was largely API focused. That’s the kind of thing that Rails is not super great at. They’re exploring what to do with front-end because there’s a sharp understanding of what Ruby on Rails is good for and what might be the purview of other tools. Elixir does a couple of things that Ruby doesn’t do very well. A lot of people who start with Ruby can learn a lot from going off to a functional language like Elixir or something that has a pattern-matching type of language like Elixir. Picks Noel Rappin R programming Podcast: Tech Done Right Author: Martha Wells The Murderbot Diaries by Martha Well Atom Editor Audio Hijack Bear Twitter @noelrap noelrappin.com Charles Max Wood Mighty Mug Phrase Express

RR 317: Computer Science at University and the Future of Programming with Dave Thomas Charles Max Wood interviews Dave Thomas about the Computer Science course he's teaching at Southern Methodist University, Elixir, and the future of programming. Dave is the author and co-author of several well known programming books including Programming Ruby (also known as the PickAxe Book), Programming Elixir, and the Pragmatic Programmer. This episode starts out discussing Dave's course and Computer Science education, then veers into Elixir and the future of programming. Tune in to hear where Dave thinks the programming industry is heading next. [00:02:30] Dave's Computer Science Course at SMU  Dave's advanced computer science course covers topics like source control and testing. He's been wanting to get into formal Computer Science for a while, so when he pulled back on his work at the Pragmatic Bookshelf, he approached SMU about teaching a course. He selected Advanced Application Development since he could teach pretty much whatever he wanted. The class is made up of Seniors and Master's students whose coursework primarily focused on theory, but lacked in the basics of coding as it happens "in the wild." The plan was to go in and subvert them with Elixir.  All of the assignments are coding assignments and must be submitted with a pull request. Chuck recalls taking a class similar to the one that Dave describes.  [00:06:22] Computer Science's focus on theory People who go into academia generally get their degrees and don't spend any time in the non-academic world. So, they don't know what's important when it comes down to nuts and bolts programming. This serves the students that stay in academia, but fails to teach the skills needed by their students. They also focus on the mathematical aspects of Computer Science and fail to show students that if they get excited about software, it can be fun. [00:09:55] This is a job where we make a difference Sometimes we do great harm. and sometimes great good. [00:10:23] How do you communicate all of these aspects of coding to the students? You can't just tell them. Mostly, Dave just tries to be enthusiastic. The teaching as it's done now is like a eulogy given by someone who doesn't know the person. Instead, Dave shows his passion for coding, tells stories, and shows how fun it is to write code. Imagine walking down the street and seeing the code you wrote being used. Dave's code was used on the satellite sent to see Haley's Comet. [00:13:04] Software as a tool for change A painter's medium is paint. Sculptors' stone. People in software don't "write" per se, but they still express themselves. This is a medium for programmers to get their thoughts out and interact with other people all over the world. We do a really crappy job explaining this to students. Dave is involved in after-school programs for software development as well. The ones that succeed don't approach software head on. They do fun and fancy stuff with Raspberry Pi or put a webserver up and then point out the concepts used in the programming. This approach is the future of development training. [00:16:01] Do you feel like CS programs aren't preparing students well? or have the wrong focus? Students come out well versed in the theoretics of programming and can write programs. These are good things to know. The assumption is that they'll pick up the rest in their first couple of jobs. They're not preparing people to walk straight into a job, but prepares them to learn the rest on the job. A 4 year program should be done after 2 years working in the real world. Most of the things not taught don't make sense until the student has the problem that it solves. For example, source control. This would give them context for the things that are important and bring the knowledge back to the  [00:20:26] What is in the curriculum? In a few years, these students will probably be writing a functional language like Elixir. They start out writing a hangman game using Elixir. Then they add Phoenix. Then they add a webserver. The focus is around the fact that what you care about is state and transformations. Then someone will realize that you're really just implementing objects. Dave is trying to teach how to think in decoupled services. [00:22:28] The future is functional? Elixir is a practical functional language and solves some problems that programmers have been trying to solve for a long time. Clojure has a strange relationship with the JVM. Elixir is not as cleanly functional as other languages, but it's functional enough. At the same time, you can write kick-ass web services as well. You also get the power of the Erlang virtual machine. Looking at Moore's Law, why aren't our processors getting faster? Over the last 10 years, they're not that much faster and the next generations are slower. But they have more cores. If you double the clock speed, you 8x the power dissipation. So, there's a limit to how fast you can go before you melt the processor. So, you run more cores at a lower speed. This vastly increases your processing power and lower your consumption. If you're writing processes that run on a core from start to finish, then it only uses 1/16th of the processor's power (if it has 16 cores.) So, we need a programming paradigm that supports parallelism. Concurrent programming is hard.  Making data immutable makes it so you can eliminate common problems with threading and concurrency. Read-only (immutable) Object Oriented programming is effectively functional programming. We should see this change occur over the next 3-7 years.  [00:31:05] Most of the people at Ruby conferences are using Elixir When Dave goes to conferences about Ruby, he finds out that about 50% of speakers and many of the attendees are doing Elixir and/or experimenting heavily with it. Ruby and Rails changed the way we work, but in many ways the functional programming is changing things again. Scaling matters. We can't just throw hardware at it. You can drop your server bill by 10x or 100x. Elixir can get you there fast like Ruby, but it can also cut costs of running your server. [00:35:43] Is a computer science degree that way to get in? or should people get in through bootcamps or self learning? It depends on your learning style. You do not want to get into Computer Science because your parents wanted you to have a good job. The students that get into it because of family pressure don't love what they're doing and are kind of stuck. Programming is hard enough that if you don't enjoy it you won't excel. In any case, do what works for you. You don't need to do a 4 year course of study to be a successful programmer. Quite a few good programmers Dave knows never took a CS course. If you do a course, find out that if the teachers are doing or have done the kinds of things you want to do. The better IT shops also tend to recognize that it's the person, not what they know, that really matters. So go to them and ask to apprentice with their good programmers at a lower salary. Then if you're contributing, ask for a competitive salary. [00:41:03] What do we as programmers assume about CS degrees that we need to change? Don't let the HR department do the hiring. Making them happy is what gets you bogus job requirements. Instead, put together some requirements that hint that enthusiasm trumps everything else. Or, have criteria like "must be able to fog a mirror" and pick for enthusiasm. Or, go to local maker groups or users groups or community colleges where the kinds of people you want are, and talk to people. Then network into the people you want. Ignore the qualifications and pay attention to the qualities. One of the best people Dave hired was an alcoholic chemistry teacher, but he could get into a project. [00:45:00] You don't want a career. Spend the next 5-10 years job hopping. You want experience, not a career. You have no idea what you want to do right now, so try lots of things. Then if it's not working move on. Picks Charles: Ubuntu Bash on Windows VMWare Workstation: https://www.vmware.com/products/workstation.html Dave: Have something in your life that is relatively simple and relatively mechanical that you can fix if something goes wrong. (Dave tells us about his tractor.)

RR 317: Computer Science at University and the Future of Programming with Dave Thomas Charles Max Wood interviews Dave Thomas about the Computer Science course he's teaching at Southern Methodist University, Elixir, and the future of programming. Dave is the author and co-author of several well known programming books including Programming Ruby (also known as the PickAxe Book), Programming Elixir, and the Pragmatic Programmer. This episode starts out discussing Dave's course and Computer Science education, then veers into Elixir and the future of programming. Tune in to hear where Dave thinks the programming industry is heading next. [00:02:30] Dave's Computer Science Course at SMU  Dave's advanced computer science course covers topics like source control and testing. He's been wanting to get into formal Computer Science for a while, so when he pulled back on his work at the Pragmatic Bookshelf, he approached SMU about teaching a course. He selected Advanced Application Development since he could teach pretty much whatever he wanted. The class is made up of Seniors and Master's students whose coursework primarily focused on theory, but lacked in the basics of coding as it happens "in the wild." The plan was to go in and subvert them with Elixir.  All of the assignments are coding assignments and must be submitted with a pull request. Chuck recalls taking a class similar to the one that Dave describes.  [00:06:22] Computer Science's focus on theory People who go into academia generally get their degrees and don't spend any time in the non-academic world. So, they don't know what's important when it comes down to nuts and bolts programming. This serves the students that stay in academia, but fails to teach the skills needed by their students. They also focus on the mathematical aspects of Computer Science and fail to show students that if they get excited about software, it can be fun. [00:09:55] This is a job where we make a difference Sometimes we do great harm. and sometimes great good. [00:10:23] How do you communicate all of these aspects of coding to the students? You can't just tell them. Mostly, Dave just tries to be enthusiastic. The teaching as it's done now is like a eulogy given by someone who doesn't know the person. Instead, Dave shows his passion for coding, tells stories, and shows how fun it is to write code. Imagine walking down the street and seeing the code you wrote being used. Dave's code was used on the satellite sent to see Haley's Comet. [00:13:04] Software as a tool for change A painter's medium is paint. Sculptors' stone. People in software don't "write" per se, but they still express themselves. This is a medium for programmers to get their thoughts out and interact with other people all over the world. We do a really crappy job explaining this to students. Dave is involved in after-school programs for software development as well. The ones that succeed don't approach software head on. They do fun and fancy stuff with Raspberry Pi or put a webserver up and then point out the concepts used in the programming. This approach is the future of development training. [00:16:01] Do you feel like CS programs aren't preparing students well? or have the wrong focus? Students come out well versed in the theoretics of programming and can write programs. These are good things to know. The assumption is that they'll pick up the rest in their first couple of jobs. They're not preparing people to walk straight into a job, but prepares them to learn the rest on the job. A 4 year program should be done after 2 years working in the real world. Most of the things not taught don't make sense until the student has the problem that it solves. For example, source control. This would give them context for the things that are important and bring the knowledge back to the  [00:20:26] What is in the curriculum? In a few years, these students will probably be writing a functional language like Elixir. They start out writing a hangman game using Elixir. Then they add Phoenix. Then they add a webserver. The focus is around the fact that what you care about is state and transformations. Then someone will realize that you're really just implementing objects. Dave is trying to teach how to think in decoupled services. [00:22:28] The future is functional? Elixir is a practical functional language and solves some problems that programmers have been trying to solve for a long time. Clojure has a strange relationship with the JVM. Elixir is not as cleanly functional as other languages, but it's functional enough. At the same time, you can write kick-ass web services as well. You also get the power of the Erlang virtual machine. Looking at Moore's Law, why aren't our processors getting faster? Over the last 10 years, they're not that much faster and the next generations are slower. But they have more cores. If you double the clock speed, you 8x the power dissipation. So, there's a limit to how fast you can go before you melt the processor. So, you run more cores at a lower speed. This vastly increases your processing power and lower your consumption. If you're writing processes that run on a core from start to finish, then it only uses 1/16th of the processor's power (if it has 16 cores.) So, we need a programming paradigm that supports parallelism. Concurrent programming is hard.  Making data immutable makes it so you can eliminate common problems with threading and concurrency. Read-only (immutable) Object Oriented programming is effectively functional programming. We should see this change occur over the next 3-7 years.  [00:31:05] Most of the people at Ruby conferences are using Elixir When Dave goes to conferences about Ruby, he finds out that about 50% of speakers and many of the attendees are doing Elixir and/or experimenting heavily with it. Ruby and Rails changed the way we work, but in many ways the functional programming is changing things again. Scaling matters. We can't just throw hardware at it. You can drop your server bill by 10x or 100x. Elixir can get you there fast like Ruby, but it can also cut costs of running your server. [00:35:43] Is a computer science degree that way to get in? or should people get in through bootcamps or self learning? It depends on your learning style. You do not want to get into Computer Science because your parents wanted you to have a good job. The students that get into it because of family pressure don't love what they're doing and are kind of stuck. Programming is hard enough that if you don't enjoy it you won't excel. In any case, do what works for you. You don't need to do a 4 year course of study to be a successful programmer. Quite a few good programmers Dave knows never took a CS course. If you do a course, find out that if the teachers are doing or have done the kinds of things you want to do. The better IT shops also tend to recognize that it's the person, not what they know, that really matters. So go to them and ask to apprentice with their good programmers at a lower salary. Then if you're contributing, ask for a competitive salary. [00:41:03] What do we as programmers assume about CS degrees that we need to change? Don't let the HR department do the hiring. Making them happy is what gets you bogus job requirements. Instead, put together some requirements that hint that enthusiasm trumps everything else. Or, have criteria like "must be able to fog a mirror" and pick for enthusiasm. Or, go to local maker groups or users groups or community colleges where the kinds of people you want are, and talk to people. Then network into the people you want. Ignore the qualifications and pay attention to the qualities. One of the best people Dave hired was an alcoholic chemistry teacher, but he could get into a project. [00:45:00] You don't want a career. Spend the next 5-10 years job hopping. You want experience, not a career. You have no idea what you want to do right now, so try lots of things. Then if it's not working move on. Picks Charles: Ubuntu Bash on Windows VMWare Workstation: https://www.vmware.com/products/workstation.html Dave: Have something in your life that is relatively simple and relatively mechanical that you can fix if something goes wrong. (Dave tells us about his tractor.)

RR 317: Computer Science at University and the Future of Programming with Dave Thomas Charles Max Wood interviews Dave Thomas about the Computer Science course he's teaching at Southern Methodist University, Elixir, and the future of programming. Dave is the author and co-author of several well known programming books including Programming Ruby (also known as the PickAxe Book), Programming Elixir, and the Pragmatic Programmer. This episode starts out discussing Dave's course and Computer Science education, then veers into Elixir and the future of programming. Tune in to hear where Dave thinks the programming industry is heading next. [00:02:30] Dave's Computer Science Course at SMU  Dave's advanced computer science course covers topics like source control and testing. He's been wanting to get into formal Computer Science for a while, so when he pulled back on his work at the Pragmatic Bookshelf, he approached SMU about teaching a course. He selected Advanced Application Development since he could teach pretty much whatever he wanted. The class is made up of Seniors and Master's students whose coursework primarily focused on theory, but lacked in the basics of coding as it happens "in the wild." The plan was to go in and subvert them with Elixir.  All of the assignments are coding assignments and must be submitted with a pull request. Chuck recalls taking a class similar to the one that Dave describes.  [00:06:22] Computer Science's focus on theory People who go into academia generally get their degrees and don't spend any time in the non-academic world. So, they don't know what's important when it comes down to nuts and bolts programming. This serves the students that stay in academia, but fails to teach the skills needed by their students. They also focus on the mathematical aspects of Computer Science and fail to show students that if they get excited about software, it can be fun. [00:09:55] This is a job where we make a difference Sometimes we do great harm. and sometimes great good. [00:10:23] How do you communicate all of these aspects of coding to the students? You can't just tell them. Mostly, Dave just tries to be enthusiastic. The teaching as it's done now is like a eulogy given by someone who doesn't know the person. Instead, Dave shows his passion for coding, tells stories, and shows how fun it is to write code. Imagine walking down the street and seeing the code you wrote being used. Dave's code was used on the satellite sent to see Haley's Comet. [00:13:04] Software as a tool for change A painter's medium is paint. Sculptors' stone. People in software don't "write" per se, but they still express themselves. This is a medium for programmers to get their thoughts out and interact with other people all over the world. We do a really crappy job explaining this to students. Dave is involved in after-school programs for software development as well. The ones that succeed don't approach software head on. They do fun and fancy stuff with Raspberry Pi or put a webserver up and then point out the concepts used in the programming. This approach is the future of development training. [00:16:01] Do you feel like CS programs aren't preparing students well? or have the wrong focus? Students come out well versed in the theoretics of programming and can write programs. These are good things to know. The assumption is that they'll pick up the rest in their first couple of jobs. They're not preparing people to walk straight into a job, but prepares them to learn the rest on the job. A 4 year program should be done after 2 years working in the real world. Most of the things not taught don't make sense until the student has the problem that it solves. For example, source control. This would give them context for the things that are important and bring the knowledge back to the  [00:20:26] What is in the curriculum? In a few years, these students will probably be writing a functional language like Elixir. They start out writing a hangman game using Elixir. Then they add Phoenix. Then they add a webserver. The focus is around the fact that what you care about is state and transformations. Then someone will realize that you're really just implementing objects. Dave is trying to teach how to think in decoupled services. [00:22:28] The future is functional? Elixir is a practical functional language and solves some problems that programmers have been trying to solve for a long time. Clojure has a strange relationship with the JVM. Elixir is not as cleanly functional as other languages, but it's functional enough. At the same time, you can write kick-ass web services as well. You also get the power of the Erlang virtual machine. Looking at Moore's Law, why aren't our processors getting faster? Over the last 10 years, they're not that much faster and the next generations are slower. But they have more cores. If you double the clock speed, you 8x the power dissipation. So, there's a limit to how fast you can go before you melt the processor. So, you run more cores at a lower speed. This vastly increases your processing power and lower your consumption. If you're writing processes that run on a core from start to finish, then it only uses 1/16th of the processor's power (if it has 16 cores.) So, we need a programming paradigm that supports parallelism. Concurrent programming is hard.  Making data immutable makes it so you can eliminate common problems with threading and concurrency. Read-only (immutable) Object Oriented programming is effectively functional programming. We should see this change occur over the next 3-7 years.  [00:31:05] Most of the people at Ruby conferences are using Elixir When Dave goes to conferences about Ruby, he finds out that about 50% of speakers and many of the attendees are doing Elixir and/or experimenting heavily with it. Ruby and Rails changed the way we work, but in many ways the functional programming is changing things again. Scaling matters. We can't just throw hardware at it. You can drop your server bill by 10x or 100x. Elixir can get you there fast like Ruby, but it can also cut costs of running your server. [00:35:43] Is a computer science degree that way to get in? or should people get in through bootcamps or self learning? It depends on your learning style. You do not want to get into Computer Science because your parents wanted you to have a good job. The students that get into it because of family pressure don't love what they're doing and are kind of stuck. Programming is hard enough that if you don't enjoy it you won't excel. In any case, do what works for you. You don't need to do a 4 year course of study to be a successful programmer. Quite a few good programmers Dave knows never took a CS course. If you do a course, find out that if the teachers are doing or have done the kinds of things you want to do. The better IT shops also tend to recognize that it's the person, not what they know, that really matters. So go to them and ask to apprentice with their good programmers at a lower salary. Then if you're contributing, ask for a competitive salary. [00:41:03] What do we as programmers assume about CS degrees that we need to change? Don't let the HR department do the hiring. Making them happy is what gets you bogus job requirements. Instead, put together some requirements that hint that enthusiasm trumps everything else. Or, have criteria like "must be able to fog a mirror" and pick for enthusiasm. Or, go to local maker groups or users groups or community colleges where the kinds of people you want are, and talk to people. Then network into the people you want. Ignore the qualifications and pay attention to the qualities. One of the best people Dave hired was an alcoholic chemistry teacher, but he could get into a project. [00:45:00] You don't want a career. Spend the next 5-10 years job hopping. You want experience, not a career. You have no idea what you want to do right now, so try lots of things. Then if it's not working move on. Picks Charles: Ubuntu Bash on Windows VMWare Workstation: https://www.vmware.com/products/workstation.html Dave: Have something in your life that is relatively simple and relatively mechanical that you can fix if something goes wrong. (Dave tells us about his tractor.)

Hajime Morita さんをゲストに迎えて、達人プログラマーなどについて話しました。 Show Notes Rebuild: Supporter Naoya Ito: "業界の悪習: 新人に10冊も20冊も自分が読んだ本を薦める" 新装版 達人プログラマー 職人から名匠への道 | Amazon 新装版 達人プログラマー 職人から名匠への道 | オーム社 eBook Store The Pragmatic Bookshelf Convolutional neural network Rational Unified Process UML 統一モデリング言語 Plantuml レガシーコード改善ガイド Add Code from a Template | Android Studio Protocol Buffers Amazon Athena Sumo Logic Splunk jq Becky! Internet Mail Wanderlust リファクタリング　既存のコードを安全に改善する CODE COMPLETE 第2版 上 Error handling and Go Thinking in React - React Design Patterns Martin Fowler UNIXという考え方―その設計思想と哲学 Takuto Wada: "若者への課題図書としてまずは『達人プログラマー』と『UNIXという考え方』を挙げた" 新卒ソフトウェアエンジニアのための技術書100冊 - クックパッド開発者ブログ The Best Software Writing I: Selected and Introduced by Joel Spolsky steps to phantasien

00:42 - Introducing Jason Swett Angular on Rails Use the code “rubyrogues” to get $10 off your purchase Twitter Email: jason@angularonrails.com 2:20 - Angular or Rails? 4:40 - Real-time data modeling 9:00 - Angular CLI 11:15 - Structuring Angular and Rails apps 16:50 - Should beginners learn Angular or Rails first? 19:50 - Building apps and tying Angular and Rails together Tour of Heroes Tutorial Jason’s blog post 25:00 - Angular on Rails feedback 28:00 - What’s the hardest part of integrating Angular and Rails? 31:00 - Why invest in Angular when it evolves so fast? 33:35 - Why did Jason write his book? Angular for Rails Developers Pragmatic Bookshelf 37:50 - How to get the most out of the book 42:40 - Panelist Jerome Hardaway Previous Ruby Rogues Episode Vets Who Code DreamForce Picks: Tour of Heroes Tutorial (Jerome) General Assembly (Jerome) DreamForce (Jerome) Adventures in Angular Podcast (Charles and Jason) Angular Remote Conf videos (Charles) NgBook (Jason) How to Win Friends and Influence People by Dale Carnegie (Jason) The 7 Habits of Highly Successful People by Stephen Covey (Jason)

00:42 - Introducing Jason Swett Angular on Rails Use the code “rubyrogues” to get $10 off your purchase Twitter Email: jason@angularonrails.com 2:20 - Angular or Rails? 4:40 - Real-time data modeling 9:00 - Angular CLI 11:15 - Structuring Angular and Rails apps 16:50 - Should beginners learn Angular or Rails first? 19:50 - Building apps and tying Angular and Rails together Tour of Heroes Tutorial Jason’s blog post 25:00 - Angular on Rails feedback 28:00 - What’s the hardest part of integrating Angular and Rails? 31:00 - Why invest in Angular when it evolves so fast? 33:35 - Why did Jason write his book? Angular for Rails Developers Pragmatic Bookshelf 37:50 - How to get the most out of the book 42:40 - Panelist Jerome Hardaway Previous Ruby Rogues Episode Vets Who Code DreamForce Picks: Tour of Heroes Tutorial (Jerome) General Assembly (Jerome) DreamForce (Jerome) Adventures in Angular Podcast (Charles and Jason) Angular Remote Conf videos (Charles) NgBook (Jason) How to Win Friends and Influence People by Dale Carnegie (Jason) The 7 Habits of Highly Successful People by Stephen Covey (Jason)

00:42 - Introducing Jason Swett Angular on Rails Use the code “rubyrogues” to get $10 off your purchase Twitter Email: jason@angularonrails.com 2:20 - Angular or Rails? 4:40 - Real-time data modeling 9:00 - Angular CLI 11:15 - Structuring Angular and Rails apps 16:50 - Should beginners learn Angular or Rails first? 19:50 - Building apps and tying Angular and Rails together Tour of Heroes Tutorial Jason’s blog post 25:00 - Angular on Rails feedback 28:00 - What’s the hardest part of integrating Angular and Rails? 31:00 - Why invest in Angular when it evolves so fast? 33:35 - Why did Jason write his book? Angular for Rails Developers Pragmatic Bookshelf 37:50 - How to get the most out of the book 42:40 - Panelist Jerome Hardaway Previous Ruby Rogues Episode Vets Who Code DreamForce Picks: Tour of Heroes Tutorial (Jerome) General Assembly (Jerome) DreamForce (Jerome) Adventures in Angular Podcast (Charles and Jason) Angular Remote Conf videos (Charles) NgBook (Jason) How to Win Friends and Influence People by Dale Carnegie (Jason) The 7 Habits of Highly Successful People by Stephen Covey (Jason)

00:30 Introducing Andy Hunt Website Twitter The Pragmatic Bookshelf GROWS Method 5:25 - GROWS Method Dreyfus Model of Skill Acquisition 13:20 - How GROWS solves Agile’s shortcomings 19:50 - GROWS for executives 22:50 - Marketing Ruby Faker Gems Fakercompany.bs 25:30 - GROWS and laying framework for change 29:00 - How empirical is GROWS? 33:35 - How expectations from the Agile Manifesto have changed 36:10 - Prescribing practices that work 40:00 - Getting feedback Burnup and Burndown charts 42:40 - Human limitations 46:00 - Meaning behind GROWS name 50:05 - Knowing when to scale up 53:00 - Agile Fluency Agile Fluency Model by Diana Larson and James Shore 57:30 - The future of GROWS   Picks: Going camping in your front yard (Jessica) California Academy of Sciences in San Francisco (Sam) Exploratorium in San Francisco (Sam) Shoe Dog by Phil Knight (Saron) Espresso Pillows (Saron) “It’s Darkest Before Dawn” DjangoCon 2016 talk by Timothy Allen (Saron) Ruby Book Club Podcast (Saron) Investing in yourself (Andy)

00:30 Introducing Andy Hunt Website Twitter The Pragmatic Bookshelf GROWS Method 5:25 - GROWS Method Dreyfus Model of Skill Acquisition 13:20 - How GROWS solves Agile’s shortcomings 19:50 - GROWS for executives 22:50 - Marketing Ruby Faker Gems Fakercompany.bs 25:30 - GROWS and laying framework for change 29:00 - How empirical is GROWS? 33:35 - How expectations from the Agile Manifesto have changed 36:10 - Prescribing practices that work 40:00 - Getting feedback Burnup and Burndown charts 42:40 - Human limitations 46:00 - Meaning behind GROWS name 50:05 - Knowing when to scale up 53:00 - Agile Fluency Agile Fluency Model by Diana Larson and James Shore 57:30 - The future of GROWS   Picks: Going camping in your front yard (Jessica) California Academy of Sciences in San Francisco (Sam) Exploratorium in San Francisco (Sam) Shoe Dog by Phil Knight (Saron) Espresso Pillows (Saron) “It’s Darkest Before Dawn” DjangoCon 2016 talk by Timothy Allen (Saron) Ruby Book Club Podcast (Saron) Investing in yourself (Andy)

00:30 Introducing Andy Hunt Website Twitter The Pragmatic Bookshelf GROWS Method 5:25 - GROWS Method Dreyfus Model of Skill Acquisition 13:20 - How GROWS solves Agile’s shortcomings 19:50 - GROWS for executives 22:50 - Marketing Ruby Faker Gems Fakercompany.bs 25:30 - GROWS and laying framework for change 29:00 - How empirical is GROWS? 33:35 - How expectations from the Agile Manifesto have changed 36:10 - Prescribing practices that work 40:00 - Getting feedback Burnup and Burndown charts 42:40 - Human limitations 46:00 - Meaning behind GROWS name 50:05 - Knowing when to scale up 53:00 - Agile Fluency Agile Fluency Model by Diana Larson and James Shore 57:30 - The future of GROWS   Picks: Going camping in your front yard (Jessica) California Academy of Sciences in San Francisco (Sam) Exploratorium in San Francisco (Sam) Shoe Dog by Phil Knight (Saron) Espresso Pillows (Saron) “It’s Darkest Before Dawn” DjangoCon 2016 talk by Timothy Allen (Saron) Ruby Book Club Podcast (Saron) Investing in yourself (Andy)

This week, Terry Ryan and Brent Shaffer join Francesc and guest host Chris Broadfoot to talk all about PHP on Google Cloud Platform About Terry Terry Ryan is a Developer Advocate for the Google Cloud Platform team. He has 15 years of experience working with the web - both front end and back. He is passionate about web standards and wants to bring web developers to the Google Cloud Platform. Before Google, he worked for Adobe and the Wharton School of Business. He also wrote Driving Technical Change for Pragmatic Bookshelf, a book that arms technology professionals with the tools to convince reluctant co-workers to adopt new tools and technology. About Brent Brent Shaffer is a Developer Programs Engineer at Google who is involved primarily in the Open Source world of PHP and Ruby. His most notable Open Source contribution is the OAuth2 server for PHP, and his favorite OpenSource project is the Symfony framework. Outside of work, he loves mountaineering and playing folk music in a band. Cool thing of the week Preemptible VMs now up to 33% cheaper blog Interview PHP on Google Cloud Platform docs PHP App Engine Getting Started docs Run PHP on Compute Engine docs Create a Guestbook with Redis and PHP on Container Engine docs Quick Start WordPress for Google App Engine github How to Run Symfony Hello World on App Engine docs github Docker images for running PHP applications on the App Engine Flexible Runtime github Cloud Launcher LAMP Stack launcher Question of the week How do I load balance WebSocket connection with a Google Cloud Load Balancer? Setting Up HTTP(S) Load Balancing docs Setting Up Network Load Balancing docs Setting Up SSL proxy for Google Cloud Load Balancing docs When should I use HTTPS load balancing instead of SSL proxy load balancing? faq

Andy Hunt (@PragmaticAndy), Jared Richardson (@JaredRichardson), and Don Gray (@DonaldEGray) joined me (@RyanRipley) to discuss the Grows Method for agile adoption. [featured-image single_newwindow=”false”]Andy Hunt Presenting at The Path to Agility Conference 2013 – Copyright COHAA[/featured-image] Andy is one of the 17 authors of the Agile Manifesto. He is the author of 9 books including: The Pragmatic Programmer: From Journeyman to Master (with Dave Thomas), Pragmatic Thinking and Learning: Refactor Your Wetware, and Practices of an Agile Developer: Working in the Real World (with Venkat Subramaniam). Andy publishes books with Dave Thomas at the Pragmatic Bookshelf. He blogs at toolshed.com. Jared is an agile coach, blogger, and speaker. He is the founder of Agile Artisians and the author of Ship It! – A Practical Guide to Successful Software Projects (with William A. Gwaltney). Don works with executives and managers to build coherent organizational structures, processes, policies, and goals that allows teams to flourish. He co-teaches one of the top coaching workshops offered globally – Coaching Beyond the Team – with Esther Derby. Don brings both wisdom and humor to his coaching practice. In this episode you'll discover: What is the Grows Method for Agile Adoption How to gradually grow agile in an organization What is essential to be agile How to get alignment between executives and agile teams The point is to ship software. Let’s focus on that, perhaps!?!Tweet This Links from the show: The Grows Method Coaching Beyond the Team – The next session is in Costa Mesa, California. Use discount code “AgileForHumans” to get the friends and family discount. Pragmatic Bookshelf – Use the discount code “AgileForHumans” for 35% off of your next purchase The Business of Agile: Better, Faster, Cheaper – Come see me (Ryan Ripley) present at Agile2016 [callout]The Pragmatic Programmer cuts through the increasing specialization and technicalities of modern software development to examine the core process–taking a requirement and producing working, maintainable code that delights its users. It covers topics ranging from personal responsibility and career development to architectural techniques for keeping your code flexible and easy to adapt and reuse. The Pragmatic Programmer illustrates the best practices and major pitfalls of many different aspects of software development. Click here to purchase on Amazon.[/callout] [reminder]What is your go to method to help people adopt agile? Does the Grows Method fill a gap that you’ve seen in your practice? Let’s discuss![/reminder] Want to hear another podcast about craftsmanship? — Listen to my conversation with Ron Quartel about FAST Agile and bringing craftsmanship back to software development on episode 10. We discuss scrum, extreme programming (XP), and the concept of craftsmanship applied to agile software development. One tiny favor.  — Please take 30 seconds now and leave a review on iTunes. This helps others learn about the show and grows our audience. It will help the show tremendously, including my ability to bring on more great guests for all of us to learn from. Thanks! This podcast is brought to you by Audible. I have used Audible for years, and I love audio books. I have three to recommend: Turn the Ship Around: A True Story of Turning Followers in to Leaders by L. David Marquet Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland The Lean Startup by Eric Ries All you need to do to get your free 30-day Audible trial is go to Audibletrial.com/agile. Choose one of the above books, or choose between more than 180,000 audio programs. It's that easy. Go to Audibletrial.com/agile and get started today. Enjoy! The post AFH 042: The Grows Method for Adopting Agile Software Develpoment [PODCAST] appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

Dave Thomas has done a lot for the programming community. He coined the phrase “DRY” (Don’t Repeat Yourself). He popularized the idea of code katas. He was one of the signers of the Manifesto for Agile Software Development, and he's the founder of the Pragmatic Bookshelf publishing company. But despite all that, he refers to himself as simply a programmer. In this episode, he shares his own coding journey, gives advice to new developers on how to navigate the mountain of information available, and how he ended up becoming a publisher. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Lone Star Ruby Elixir Tacit knowledge Design patterns C2.com Airbrake Avdi Grimm CodeNewbie Austin Elm Functional programming Statically Typed vs. Dynamically Typed Languages Codeland Conf Codeland 2019

02:37 - Dave Thomas Introduction Twitter Blog The Pragmatic Bookshelf 04:17 - How Dave Got Started in Programming 06:34 - Tools and Constraints “An Enthusiast’s Problem”? Is the focus on tools a form of cargo culting? Leadism Over Chosen Technologies and Its’ Effect on Innovation Switching Tools and Making Excuses 19:29 - Limerence Love and Limerence: The Experience of Being in Love by Dorothy Tennov Irrational Interest and Defensiveness 28:54 - Ruby = Happiness: Does it Hurt? 31:00 - Tools and Falling in Love with Tools Fear of Falling Behind; Fear of Irrelevancy Different Tools for Different Contexts 35:08 - When Do You Learn? When Do You Train? (Not Falling Behind) 38:01 - Choosing Similar Tools and Technologies vs Choosing Different Tools and Technologies Gulp => Grunt => Browserify Example Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt 43:36 - Relationships and Identities 46:08 - Looking Forward vs Looking Back (Knowing Your History) Resources, Curriculum: Structure and Interpretation of Computer Programs - 2nd Edition (MIT Electrical Engineering and Computer Science) by Harold Abelson (SICP) Smalltalk Best Practice Patterns by Kent Beck Types and Programming Languages by Benjamin C. Pierce    The Art of Computer Programming by Donald Knuth (Series) Communicating Sequential Processes (CSP) Brainstorming Example 01:01:48 - Is the rampant use of social media hindering the learning of big ideas? Self-Curation = Key 01:08:15 - How You Learn a Language / Decide You Like a Language Sudoku Solver Markdown Parser Picks Slack (Dave) Why Does E=mc2? (And Why Should We Care?) by Brian Cox and Jeff Forshaw (Dave) Philly Emerging Tech Conference  (Dave)  

02:37 - Dave Thomas Introduction Twitter Blog The Pragmatic Bookshelf 04:17 - How Dave Got Started in Programming 06:34 - Tools and Constraints “An Enthusiast’s Problem”? Is the focus on tools a form of cargo culting? Leadism Over Chosen Technologies and Its’ Effect on Innovation Switching Tools and Making Excuses 19:29 - Limerence Love and Limerence: The Experience of Being in Love by Dorothy Tennov Irrational Interest and Defensiveness 28:54 - Ruby = Happiness: Does it Hurt? 31:00 - Tools and Falling in Love with Tools Fear of Falling Behind; Fear of Irrelevancy Different Tools for Different Contexts 35:08 - When Do You Learn? When Do You Train? (Not Falling Behind) 38:01 - Choosing Similar Tools and Technologies vs Choosing Different Tools and Technologies Gulp => Grunt => Browserify Example Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt 43:36 - Relationships and Identities 46:08 - Looking Forward vs Looking Back (Knowing Your History) Resources, Curriculum: Structure and Interpretation of Computer Programs - 2nd Edition (MIT Electrical Engineering and Computer Science) by Harold Abelson (SICP) Smalltalk Best Practice Patterns by Kent Beck Types and Programming Languages by Benjamin C. Pierce    The Art of Computer Programming by Donald Knuth (Series) Communicating Sequential Processes (CSP) Brainstorming Example 01:01:48 - Is the rampant use of social media hindering the learning of big ideas? Self-Curation = Key 01:08:15 - How You Learn a Language / Decide You Like a Language Sudoku Solver Markdown Parser Picks Slack (Dave) Why Does E=mc2? (And Why Should We Care?) by Brian Cox and Jeff Forshaw (Dave) Philly Emerging Tech Conference  (Dave)  

02:37 - Dave Thomas Introduction Twitter Blog The Pragmatic Bookshelf 04:17 - How Dave Got Started in Programming 06:34 - Tools and Constraints “An Enthusiast’s Problem”? Is the focus on tools a form of cargo culting? Leadism Over Chosen Technologies and Its’ Effect on Innovation Switching Tools and Making Excuses 19:29 - Limerence Love and Limerence: The Experience of Being in Love by Dorothy Tennov Irrational Interest and Defensiveness 28:54 - Ruby = Happiness: Does it Hurt? 31:00 - Tools and Falling in Love with Tools Fear of Falling Behind; Fear of Irrelevancy Different Tools for Different Contexts 35:08 - When Do You Learn? When Do You Train? (Not Falling Behind) 38:01 - Choosing Similar Tools and Technologies vs Choosing Different Tools and Technologies Gulp => Grunt => Browserify Example Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt 43:36 - Relationships and Identities 46:08 - Looking Forward vs Looking Back (Knowing Your History) Resources, Curriculum: Structure and Interpretation of Computer Programs - 2nd Edition (MIT Electrical Engineering and Computer Science) by Harold Abelson (SICP) Smalltalk Best Practice Patterns by Kent Beck Types and Programming Languages by Benjamin C. Pierce    The Art of Computer Programming by Donald Knuth (Series) Communicating Sequential Processes (CSP) Brainstorming Example 01:01:48 - Is the rampant use of social media hindering the learning of big ideas? Self-Curation = Key 01:08:15 - How You Learn a Language / Decide You Like a Language Sudoku Solver Markdown Parser Picks Slack (Dave) Why Does E=mc2? (And Why Should We Care?) by Brian Cox and Jeff Forshaw (Dave) Philly Emerging Tech Conference  (Dave)  

Hello and welcome to episode 29 of Floppy Days.  My name is Randy Kindig and I’m the host of this podcast.  This is a special interview-only episode of Floppy Days.  I’m very excited to have with me today the authors of the various editions of the computer history book entitled “Fire in the Valley”; that being Paul Freiberger and Michael Swaine.  I think a majority of the listeners will be familiar with the book.  I have mentioned it several times before on this podcast and have used it as a reference for the vintage computers I’ve covered.  Many listeners will also be familiar with the movie “The Pirates of Silicon Valley” starring Anthony Michael Hall as a young Bill Gates and Noah Wyle as a young Steve Jobs which was made based on the book.  I was amazed when I recently contacted the authors about coming onto Floppy Days and both of them immediately responded that they would be happy to.  Pay special attention to our conversation at the end of the interview, which may hint at something special to come on Floppy Days.  Before we begin, I do want to warn you that the Skype quality for this interview was not the best at times.  Nevertheless, I think you will enjoy it!!   Links:   “Fire in the Valley” 2nd Edition at Amazon - http://www.amazon.com/dp/0071358927/?tag=flodaypod-20 “Fire in the Valley” 3rd Edition at Amazon - http://www.amazon.com/dp/1937785769/?tag=flodaypod-20   “Fire in the Valley: The Birth and Death of the Personal Computer, Third Edition” by Michael Swaine and Paul Freiberger at the Pragmatic Bookshelf  - https://pragprog.com/book/fsfire/fire-in-the-valley   “The Pirates of Silicon Valley” at IMDB - http://www.imdb.com/title/tt0168122/?ref_=nm_flmg_act_38 “The Pirates of Silicon Valley” at Amazon - http://www.amazon.com/dp/B0009NSCS0/?tag=flodaypod-20 Paul Freiberger’s Site - “Fire in the Valley: the Making of the Personal Computer” - http://www.paulfreiberger.com/book/fire-valley-making-personal-computer/ Swaine’s World - Michael Swaine’s Blog on Writing and Technology - http://www.swaine.com/wordpress/category/about/ Facebook page - https://www.facebook.com/FireInTheValley Paul Freiberger Contact Information: paul.freiberger@gmail.com   Michael Swaine Contact Information: Blog: www.swaine.com Email: mike@swaine.com Twitter: @pragpub or @mswaine

舘野祐一さんをゲストに迎えて、WEB+DB Press, Podcast, 電子書籍などについて話しました。 (2014年9月 WEB+DB Press 対談後に収録) Show Notes Amazon.co.jp: WEB+DB PRESS Vol.83 ★ WEB+DB PRESS Vol.83 Documentation - The Go Programming Language The Swift Programming Language: About the Language Reference Introducing Swift - and the Sunset of Our Culture? - YAPC::Asia Tokyo 2014 gihyo.jp The Pragmatic Bookshelf 達人出版会 markdown2inao GitHubで雑誌・書籍を作る

In this episode of Build Phase, Mark and Gordon talk about testing, frameworks and public vs private interface. The Pragmatic Bookshelf Kiwi Specta Expecta OCMock KIF Frank Bwoken xctool Page Objects Follow @thoughtbot, @21x9, and @gfontenot on twitter.

Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013! Panel Brian Hogan (twitter github blog) AJ O’Neal (twitter github blog) Joe Eames (twitter github blog) Merrick Christensen (twitter github) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:55 - Brian Hogan Introduction HTML5 and CSS3: Develop with Tomorrow's Standards Today by Brian Hogan tmux: Productive Mouse-Free Development by Brian Hogan Web Development Recipes by Brian P. Hogan, Chris Warren, Mike Weber, Chris Johnson, Aaron Godin Development Editor with Pragmatic Bookshelf Professor at Chippewa Valley Technical College 01:48 - What Accessibility Means 02:56 - Making Websites Accessible YSlow People vs Users 06:06 - “The Right Things” VersaBraille Responsive Web Design 09:00 - Tools & Techniques Fahrner Image Replacement (FIR) Web Fonts ⌘+ 14:56 - Manipulating the DOM ARIA - HTML5 Ember.js 16:54 - Screen Resolution 19:24 - Typeahead 20:58 - Testing Jaws VoiceOver 23:11 - Resources WebAIM Web Content Accessibility Guidelines (WCAG) Section 508 25:00 - Dealing with different kinds of impairments Transcripts Text Color 28:08 - Ease of Accessibility & Empathy 31:41 - Interactive Pages 35:26 - Making things accessible vs not making things accessible Making experiences better for everyone, period 42:09 - Resources Cont’d Web Content Accessibility Guidelines (WCAG) Pro HTML5 Accessibility by Joe O Conner Design Accessible Web Sites: 36 Keys to Creating Content for All Audiences and Platforms by Jeremy Sydik 42:46 - Understanding Others’ Difficulties Picks Leviathan: Warships (Joe) Star Command (Joe) That Conference (Joe) Lowes (AJ) Friends (AJ) Ticket to Ride (Chuck) 4 Pics 1 Word (Chuck) Continuum (Chuck) AngularJS (Brian) Presentation Manager from Woojijuice (Brian) Next Week JavaScript Jabber: jQuery Mobile with Todd Parker Transcript MERRICK:  Fine, don’t come to my talk. CHUCK:  I won’t. I won’t even come to the conference. [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCK:  Hey everybody, and welcome to Episode 58 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal. AJ:  Coming at you semi-live from ORM. CHUCK:  Joe Eames. JOE:  Hey everybody. CHUCK:  Merrick Christensen. MERRICK:  What’s up? CHUCK:  I’m Charles Max Wood from Devchat.tv. And this week, we have a special guest. And that is Brian Hogan. BRIAN:  Hello. CHUCK:  Since you haven’t been on the show before, do you want to introduce your self really quickly? BRIAN:  Sure, my name is Brian Hogan and I’m a web developer and I like to spend a lot of time hacking on code in Ruby and JavaScript. I also am an author. I’m a development editor with The Pragmatic Bookshelf. And I have a fabulous new gig where I get to teach brand new programmers how to get started programming now. So, that’s what I’m doing myself. CHUCK:  So where’s that at? AJ:  Cool. BRIAN:  That’s at a little technical college in Eau Claire, Wisconsin called Chippewa Valley Technical College. CHUCK:  Oh, cool. Yeah, speaking of your reviewing books for The Pragmatic Bookshelf, Ruby Rogues, we actually interviewed Bruce Williams and John Athayde about The Rails View this morning. They mentioned you, and I was like “Oh, we’re talking to him in a couple of hours.” BRIAN:  Oh, those are some great guys and that’s a great book. CHUCK:  Yup. So, the reason we brought you on the show is because, at least in my case, I know absolutely nothing about building accessible websites.

Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013! Panel Brian Hogan (twitter github blog) AJ O’Neal (twitter github blog) Joe Eames (twitter github blog) Merrick Christensen (twitter github) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:55 - Brian Hogan Introduction HTML5 and CSS3: Develop with Tomorrow's Standards Today by Brian Hogan tmux: Productive Mouse-Free Development by Brian Hogan Web Development Recipes by Brian P. Hogan, Chris Warren, Mike Weber, Chris Johnson, Aaron Godin Development Editor with Pragmatic Bookshelf Professor at Chippewa Valley Technical College 01:48 - What Accessibility Means 02:56 - Making Websites Accessible YSlow People vs Users 06:06 - “The Right Things” VersaBraille Responsive Web Design 09:00 - Tools & Techniques Fahrner Image Replacement (FIR) Web Fonts ⌘+ 14:56 - Manipulating the DOM ARIA - HTML5 Ember.js 16:54 - Screen Resolution 19:24 - Typeahead 20:58 - Testing Jaws VoiceOver 23:11 - Resources WebAIM Web Content Accessibility Guidelines (WCAG) Section 508 25:00 - Dealing with different kinds of impairments Transcripts Text Color 28:08 - Ease of Accessibility & Empathy 31:41 - Interactive Pages 35:26 - Making things accessible vs not making things accessible Making experiences better for everyone, period 42:09 - Resources Cont’d Web Content Accessibility Guidelines (WCAG) Pro HTML5 Accessibility by Joe O Conner Design Accessible Web Sites: 36 Keys to Creating Content for All Audiences and Platforms by Jeremy Sydik 42:46 - Understanding Others’ Difficulties Picks Leviathan: Warships (Joe) Star Command (Joe) That Conference (Joe) Lowes (AJ) Friends (AJ) Ticket to Ride (Chuck) 4 Pics 1 Word (Chuck) Continuum (Chuck) AngularJS (Brian) Presentation Manager from Woojijuice (Brian) Next Week JavaScript Jabber: jQuery Mobile with Todd Parker Transcript MERRICK:  Fine, don’t come to my talk. CHUCK:  I won’t. I won’t even come to the conference. [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCK:  Hey everybody, and welcome to Episode 58 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal. AJ:  Coming at you semi-live from ORM. CHUCK:  Joe Eames. JOE:  Hey everybody. CHUCK:  Merrick Christensen. MERRICK:  What’s up? CHUCK:  I’m Charles Max Wood from Devchat.tv. And this week, we have a special guest. And that is Brian Hogan. BRIAN:  Hello. CHUCK:  Since you haven’t been on the show before, do you want to introduce your self really quickly? BRIAN:  Sure, my name is Brian Hogan and I’m a web developer and I like to spend a lot of time hacking on code in Ruby and JavaScript. I also am an author. I’m a development editor with The Pragmatic Bookshelf. And I have a fabulous new gig where I get to teach brand new programmers how to get started programming now. So, that’s what I’m doing myself. CHUCK:  So where’s that at? AJ:  Cool. BRIAN:  That’s at a little technical college in Eau Claire, Wisconsin called Chippewa Valley Technical College. CHUCK:  Oh, cool. Yeah, speaking of your reviewing books for The Pragmatic Bookshelf, Ruby Rogues, we actually interviewed Bruce Williams and John Athayde about The Rails View this morning. They mentioned you, and I was like “Oh, we’re talking to him in a couple of hours.” BRIAN:  Oh, those are some great guys and that’s a great book. CHUCK:  Yup. So, the reason we brought you on the show is because, at least in my case, I know absolutely nothing about building accessible websites.

Use this link and code JAVAJAB to get 20% off your registration for FluentConf 2013! Panel Brian Hogan (twitter github blog) AJ O’Neal (twitter github blog) Joe Eames (twitter github blog) Merrick Christensen (twitter github) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:55 - Brian Hogan Introduction HTML5 and CSS3: Develop with Tomorrow's Standards Today by Brian Hogan tmux: Productive Mouse-Free Development by Brian Hogan Web Development Recipes by Brian P. Hogan, Chris Warren, Mike Weber, Chris Johnson, Aaron Godin Development Editor with Pragmatic Bookshelf Professor at Chippewa Valley Technical College 01:48 - What Accessibility Means 02:56 - Making Websites Accessible YSlow People vs Users 06:06 - “The Right Things” VersaBraille Responsive Web Design 09:00 - Tools & Techniques Fahrner Image Replacement (FIR) Web Fonts ⌘+ 14:56 - Manipulating the DOM ARIA - HTML5 Ember.js 16:54 - Screen Resolution 19:24 - Typeahead 20:58 - Testing Jaws VoiceOver 23:11 - Resources WebAIM Web Content Accessibility Guidelines (WCAG) Section 508 25:00 - Dealing with different kinds of impairments Transcripts Text Color 28:08 - Ease of Accessibility & Empathy 31:41 - Interactive Pages 35:26 - Making things accessible vs not making things accessible Making experiences better for everyone, period 42:09 - Resources Cont’d Web Content Accessibility Guidelines (WCAG) Pro HTML5 Accessibility by Joe O Conner Design Accessible Web Sites: 36 Keys to Creating Content for All Audiences and Platforms by Jeremy Sydik 42:46 - Understanding Others’ Difficulties Picks Leviathan: Warships (Joe) Star Command (Joe) That Conference (Joe) Lowes (AJ) Friends (AJ) Ticket to Ride (Chuck) 4 Pics 1 Word (Chuck) Continuum (Chuck) AngularJS (Brian) Presentation Manager from Woojijuice (Brian) Next Week JavaScript Jabber: jQuery Mobile with Todd Parker Transcript MERRICK:  Fine, don’t come to my talk. CHUCK:  I won’t. I won’t even come to the conference. [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] CHUCK:  Hey everybody, and welcome to Episode 58 of the JavaScript Jabber Show. This week on our panel, we have AJ O’Neal. AJ:  Coming at you semi-live from ORM. CHUCK:  Joe Eames. JOE:  Hey everybody. CHUCK:  Merrick Christensen. MERRICK:  What’s up? CHUCK:  I’m Charles Max Wood from Devchat.tv. And this week, we have a special guest. And that is Brian Hogan. BRIAN:  Hello. CHUCK:  Since you haven’t been on the show before, do you want to introduce your self really quickly? BRIAN:  Sure, my name is Brian Hogan and I’m a web developer and I like to spend a lot of time hacking on code in Ruby and JavaScript. I also am an author. I’m a development editor with The Pragmatic Bookshelf. And I have a fabulous new gig where I get to teach brand new programmers how to get started programming now. So, that’s what I’m doing myself. CHUCK:  So where’s that at? AJ:  Cool. BRIAN:  That’s at a little technical college in Eau Claire, Wisconsin called Chippewa Valley Technical College. CHUCK:  Oh, cool. Yeah, speaking of your reviewing books for The Pragmatic Bookshelf, Ruby Rogues, we actually interviewed Bruce Williams and John Athayde about The Rails View this morning. They mentioned you, and I was like “Oh, we’re talking to him in a couple of hours.” BRIAN:  Oh, those are some great guys and that’s a great book. CHUCK:  Yup. So, the reason we brought you on the show is because, at least in my case, I know absolutely nothing about building accessible websites.

伊藤直也さんをゲストに迎えて、Kindle出版、GitHub、Google Reader などについて話しました。 Show Notes 入門Chef Solo - Infrastructure as Code Kindle 向けにChef本を出版しました Blog Hacks O'Reilly Rough Cuts Pragmatic Bookshelf Plack Handbook 紹介 - Plack Handbook 404 Blog Not Found Gumroad Markdown Calibre KindleGen Markdown to Inao Github Flavored Markdown パブー Pro paberish ソーシャルコーディング革命後の開発委託の世界 Linux Conference 2000 Fall Google Readerが終わっても、RSSは終わらない Why is Google Killing Google Reader? Google Reader API Unofficial document pubsubhubbub Transitioning from Google Reader to Feedly Superfeedr Baby steps toward replacing Google Reader

In Folge 65 reden Dirk, Axel und Venty übers Fachliteratur schreiben. Vorallem gehen wir auch auf die Rolle des Lektorats und der Verlage ein. Trackliste Buzzer – Compofiller Funk DAC – Black Sun Rises Nächste Sendung am Samstag, 2. März 2013, 19:00 Uhr Küchenstudio :: Axel und Dirk in der Küche samt dem neuen Equipment Lulu :: Self Publishing mit Lulu No Starch Press :: No Starch Press Medialinx AG :: Vormals bekannt als Linux New Media Autorenvertrag :: PDF des Autorenvertrags von Linux-User Autorenhinweis :: Autorenhinweis von Linux-User als Musterartikel Pragmatic Bookshelf :: How to write for us von Pragmatic Bookshelf Der Weg zum Buch :: Open Source Press' Weg zum Buch Kontaktformular :: Open Source Press Kontaktformular für Autoren Buchpreise :: Dirks Blogeintrag zum Thema Buchpreise Linux-Server :: Linux-Server - Das Administrationshandbuch unter Anderem von Dirk geschrieben Swiss Perl Workshop 2013 :: Swiss Perl Workshop 2013 CoSin :: Das CoSin-OK ist noch auf Raumsuche! DeimHart :: DeimHart Podcast von Dirk Deimeke und Roman Hanhart File Download (76:28 min / 132 MB)

In Folge 65 reden Dirk, Axel und Venty übers Fachliteratur schreiben. Vorallem gehen wir auch auf die Rolle des Lektorats und der Verlage ein. Trackliste Buzzer – Compofiller Funk DAC – Black Sun Rises Nächste Sendung am Samstag, 2. März 2013, 19:00 Uhr Küchenstudio :: Axel und Dirk in der Küche samt dem neuen Equipment Lulu :: Self Publishing mit Lulu No Starch Press :: No Starch Press Medialinx AG :: Vormals bekannt als Linux New Media Autorenvertrag :: PDF des Autorenvertrags von Linux-User Autorenhinweis :: Autorenhinweis von Linux-User als Musterartikel Pragmatic Bookshelf :: How to write for us von Pragmatic Bookshelf Der Weg zum Buch :: Open Source Press' Weg zum Buch Kontaktformular :: Open Source Press Kontaktformular für Autoren Buchpreise :: Dirks Blogeintrag zum Thema Buchpreise Linux-Server :: Linux-Server - Das Administrationshandbuch unter Anderem von Dirk geschrieben Swiss Perl Workshop 2013 :: Swiss Perl Workshop 2013 CoSin :: Das CoSin-OK ist noch auf Raumsuche! DeimHart :: DeimHart Podcast von Dirk Deimeke und Roman Hanhart File Download (76:28 min / 132 MB)

In this musing Clark and Mark chat with Pragmatic Bookshelf author Brian Hogan. We explore some of the different aspects of HTML5 and what it offers.

I spoke with Dave Thomas at the RailsEdge in Reston Virginia.  We talk about his new book Agile Web Development With Rails and the Erlang book that is in the pipeline for the Pragmatic Bookshelf. The most striking feature of this podcast is the range of topics that we discuss.  The second half of the discussion explores music, photography, monoculture and education.  I was tired when I recorded this and you can hear it.  Fortunately Dave was engaging enough to make this a decent podcast.Enjoy-bob payne