Short and sweet. Light on details but contained some pretty good tips. Worth the price of admission, you can read the entire book in one sitting, evenShort and sweet. Light on details but contained some pretty good tips. Worth the price of admission, you can read the entire book in one sitting, even right before an interview and you'll be able to easily put it into action....more
I kind of always had this hunch that Domain-Driven Design was something of a buzzword fad, that it likely described something I was already doing reguI kind of always had this hunch that Domain-Driven Design was something of a buzzword fad, that it likely described something I was already doing regularly and that the book and the approach likely just lent formality and terminology to common sense activities. After all, the biggest thing I see referenced seems to be this Ubiquitous Language stuff, which I think just means using the same nouns for stuff as the domain experts, which I try to do anyway so I'm sure I'm already doing everything in the book, right? Nope. I was flat wrong, which is why I consider this book a must-read for engineers who do a lot of greenfield work, domain modeling, and architecture.
Early on, the author provides a sort of toy example that will stay with us for the duration of the book, designing the domain for a Scrum management product. I've actually worked a job where I did this very thing, so this resonated fairly strongly. The book suggests that, if engineers are left to their own devices, they'll design around code generality to reduce duplication, so there might be like a ScrumElement that could be a Product or a BacklogItem, and there's like a generic ScrumElementContainer which could be either a Sprint or Release. I'm just reading this section like, yeah, that's exactly what I would do... in fact I did that. Is that bad? But the rest of the book explains exactly why that's bad, and exactly how to do it better. Chapter after chapter, the book showed me the ways in which my approach to domain modeling was disastrously bad and how much better it could be. It also explained how, with this alternative approach, my domain would lend itself more easily to modular system design along service-oriented boundaries.
In short, this book is excellent and completely changed how I think about and model domain objects at work. The book can sometimes be light on detail, I often found myself wanting more information, or stronger examples of exactly how something should work, but at the end of the day that's the purpose of this book - a short introduction that encourages the reader to dive in deeper with Domain Driven Design or Implementing Domain Driven Design. As such, I can't really complain about the general lightness of this book, as it's the primary reason it was such an easily digestible 197 pages.
Overall, this book is a must-read, I wish it existed years ago. I think back to all the times that a group of coworkers and I would gather in front of a whiteboard and model domain objects together without a single domain expert in the room. It makes me slap my head at how idiotic my approach has been for over a decade, the ways that I let database and technical concerns dictate the design of domain objects rather than the business's needs. I can never look at this regularly-performed process the same way, which is why it joins my list of Career-Changing Books....more
UPDATE: Given what has happened with Patton's wife since I wrote this review, it all seems a bit petty now. I'm only leaving it here because there areUPDATE: Given what has happened with Patton's wife since I wrote this review, it all seems a bit petty now. I'm only leaving it here because there are a few comments, and if I delete it they won't make sense. TL;DR of the review: I wound up reading this book for a weird reason, and it was alright.
Why did I read Patton Oswalt's "Silver Screen Fiend"? To answer that, I have to first tell a bit of a story.
A few years back I wrote a blog post introducing a new order for watching the Star Wars films. I named it "Machete Order" after my blog ("Absolutely No Machete Juggling", don't ask) and published it randomly without much of a thought. A year or so after publishing it, Wired.com linked to it in an article, and for the remainder of the year after that it sort of "went viral". I was interviewed on a local news station as well as NPR, the post was mentioned in various magazines, it got a shout-out in an episode of The Big Bang Theory and King of the Nerds, and was even mentioned on CNN. Clearly this was to be my fifteen minutes.
But by far, the absolute coolest mention of my dumb Star Wars post was on an episode of Late Night with Seth Meyers, in which Patton Oswalt mentioned the order as an "amazing" way of watching Star Wars. I went through the roof, I've listened to every single comedy album Oswalt has ever released, and seen every special he's ever taped. He has been one of my favorite comedians for years and the very notion that his eyeballs were looking at my dumb blog utterly floored me. To date, this is still the highlight of my fifteen minutes of fame, which have since subsided after the release of Episode VII.
Shortly after the Seth Meyers plug, I saw that Patton was touring and would actually be in Denver a few months later. I bought tickets simply because I'd never seen him live, and then I was struck by a silly idea. What if I messaged him on Facebook, told him I was the Machete Order guy, and asked if I could meet him when he comes to town? "No," I thought, "it's too presumptuous, it's awkward and weird. I'm just some guy on the internet, why the fuck would he want to meet me?"
But my own curiosity got the better of me and I convinced myself, hey, I'm nothing to sneeze at, after all HE'S the one who referenced ME. Hell, maybe he'd be a little excited to meet me like I would be to meet him. So I worked up the nerve to message him on Facebook and asked if he'd like to meet me after his Denver show. I assured him "I'm not some rabid, crazed fan - just a hello and a cell phone pic or something would be awesome." I told him I'd understand if he didn't feel comfortable with it, that I understood the internet is full of weirdos and I'm just a name on the internet to him. I thanked him for the shout-out on Seth Meyers either way, and pressed send.
To my immense surprise, Patton responded within minutes. "Sure! This should be no problem." Holy shit. I'm going to meet Patton Fucking Oswalt! He followed up with "You + 1 will be on the backstage visit list!" I was beside myself with excitement.
But then panic set in. What the hell would I say to him? I'm just some guy with a blog, what can he and I possibly talk about? Okay, one, Star Wars for sure. I didn't want to talk about Machete Order itself, that seemed to self-absorbed. But the date of his show was actually AFTER the release of Episode VII, so I figured I could ask him what he thought of the new movie, we could chat about that a bit. Two, cell phone picture. My wife can take it, and that'll take a little time too. Or wait, what if he wouldn't want that since I'm so much taller than him? Oh, I know, I could get him to sign something! Oh but shit, what would he sign? A comedy album? Who even owns physical CDs anymore, plus he's not a rock star so that's weird. "Wait," I thought, "I've got it! He just recently published a book called Silver Screen Fiend, I'll buy a copy and he can sign that!"
So I ordered a hardcover copy of the book. I honestly had no intention of reading it. I've read a few autobiographies by comedians and frankly haven't enjoyed them much, they're always too young to have enough life experiences to impart wisdom, and the funniest life experiences they've had are already part of their comedy routines, so the books always just seem like extremely long and watered-down sets. Patton's book in particular didn't interest me as it looked, from the cover and description, like it was mostly about movies he liked, and I hadn't seen a lot of the older films he seemed to discuss. But I figured, hell, I don't have to tell the dude I'm not gonna read his book, I really just want to meet him and it'd be nice if I had something he can sign. The book signature would just be a neat memento of what would definitely be the biggest celebrity encounter of my life.
The date of the show, the wife and I drove downtown and sat down in our seats - pretty far in the back, unfortunately. By this point, my wife was actually pregnant with our first baby, a girl. I knew Patton also had a young daughter from listening to his comedy, so I figured if I ran out of things to say my obviously-very-pregnant wife could be a topic to end any awkward silences. I was feeling pretty good, I just had to keep telling myself not to act like an insane gushing fanboy and treat the man like an ordinary person.
Patton came out on the stage in Denver's Paramount Theatre and bellowed "Hello Dallas!" Oof. Not a great start. The crowd was nearly silent, some people nervously laughing trying to figure out if he was messing with them. Patton then made some jokes about the local Dallas area, which were met with almost total silence from the audience. He seemed taken aback by the reaction, like he knew that normally name-dropping attractions gets the locals riled up. There was an awkward pause and I heard someone in the front row say something to him. Then Patton jumped, "oh fuck, am I in Denver?" - big laughs. Patton had a pretty good show that night, he rescued the set and won the audience over eventually, but I could tell the Dallas flub rattled him, he even made another crack about it and called himself an idiot later on. He talked about Star Wars Episode VII and shared his thoughts on the film as well. I tried hard to focus on the show and enjoy myself, but the thoughts of meeting him kept creeping in. When he made the Dallas flub, I wondered if it would put him in a bad mood after the show. When he mentioned Episode VIII, I realized it would no longer be a viable conversation starter.
When the show ended, I looked around and tried to figure out where to go or what to do. I'm not a famous person, I have no idea what the procedure is to go backstage because you're "on the list" - I've never been on a list before. The best I could tell was, up front near the stage were some curtains with guards standing in front of them. Me and my pregnant wife tried to make our way to the curtains, but struggled against the force of the crowd moving in the other direction to exit the theater. I could hear people muttering about me, snickering. One guy laughed when his girlfriend asked what I was doing, to which he responded "he thinks he's going to be able to go backstage." Yeah, I get it. I looked like some douchey nerd fan, holding my stupid Patton Oswalt book like an idiot. But little did that guy know, I'm on the list, motherfucker!
I finally pushed my way past everyone and got to the front. I walked up to the security guard and said "hey, I'm Rod Hilton, I should be on the list." He looked me up and down, then replied, "we weren't given a list." My face fell. I thought there might be some kind of mistake. "Can you just go ask--" I started, but he interrupted "nope, sorry, can't do that. You can feel free to call him yourself though" he said, smirking. Well, shit. I didn't have his number, we only talked on Facebook. I pulled out my phone and tried to show the guard my conversation with him, but when I held my phone out he pushed my arm back down and said "sorry, can't use that, he has to actually come out here and get you."
So I messaged Patton on Facebook. "Hey Patton I don't know if you're still here but they say they don't have a list..." I knew every minute that ticked by made it more likely Patton had already taken off for the evening. And now I was asking for so much more than being a name on a list, he'd actually have to walk all the way back out of the dressing room and come get me to let me come backstage, it seemed like a lot to ask. I quickly followed up with "I won't keep you or anything just wanted a quick signature" desperate to salvage the whole endeavor. And then I stood there, against the wall. All of the people I had to push past were still glancing back, seeing if Patton was going to show up to sign books or something. But they saw no Patton, just me and my wife, standing against the wall, waiting, having been completely rejected by a few large security guards. I felt my face flush with embarrassment as I tried to think of things I could say to the security guard to convince him to let me go back stage, but I realized everything I could think of saying only made me seem even more like a crazed fan, which to a security guard likely meant security risk.
Minutes went by, feeling like hours while I waited. I kept refreshing my Facebook messages over and over, hoping Patton would respond. After some time, the entire auditorium was empty aside from the guards, a few ushers picking up trash, my wife, and me. Eventually they told me they needed us to leave the room so they could close up, so we did. I stood in the lobby for a bit instead - there were a handful of other fans there, also holding books for him to sign. I guessed they were all fans who thought Patton might show up after to greet folks, but who didn't have the audacity to actually try and get backstage like I did. I stood there until the staff indicated that Patton had "probably already left" and other fans started filing out, their unsigned books in hand.
My wife and I walked back to the parking garage very quietly. She could tell I was upset, but she had no idea what to say. I kept flashing between feelings of intense disappointment and embarrassment. The faces of all the friends and family I told I was going to meet Patton Oswalt flashed in my mind as I imagined having to tell them all one by one I didn't actually get to meet him. I mentally rehearsed how to say it in a way that played it cool like it didn't bother me and was no big deal.
We drove home in near-silence as I thought about what happened. I found it odd that the security guard hadn't told me that my name wasn't on the list, but instead that there was no list at all. If Patton had simply forgotten to add me to the list, then him remembering would have meant that I was the *ONLY* person on the list. How awkward would that have been for him? No entourage of people drinking and mingling, just him, me, and my wife. No celebrity would put himself in that kind of situation. It doesn't seem possible that he could have intended for me to be the only person on this list. Hell, that's not even a list, you can't have a list with one item on it.
And then it dawned on me. The problem wasn't that my name wasn't on the list. The problem wasn't even that the guard hadn't been given a list. The problem was, there never was a list.
I finally realized what you probably realized twelve paragraphs ago, that "You + 1 will be on the backstage visit list!" was actually just a nice way of saying "no" without making a fan think you're a jerk. This way, Patton could say yes and keep a fan, and just rely on that fan to blame the security guards for being stupid. This way, there was no risk of a disgruntled ex-fan taking a screenshot of his Facebook conversation and posting about a famous person telling the fan to fuck himself. He gets to stay cool, but also doesn't have to meet some random guy on the internet. It was the equivalent of an attractive person giving an unattractive person a fake phone number in a bar. I realized, I was just some random noncelebrity bothering a famous person and being told he'd have his people call my people. I was the waiter who tries to give Steven Spielberg his screenplay, the limo driver who tries to hand Dr. Dre his demo tape. I was a sucker.
I walked through the door of my house at the end of a very disappointing evening and looked down at my hands. There it was. "Silver Screen Fiend". A hardcover copy of a book I never had any intention of reading - purchased only so I'd have something that one of my favorite comedians could sign - completely unsigned. A rectangular object whose purpose for existence now seemed to only be to serve as a reminder of a humiliating experience, a totem of my commoner status. And there it would sit, on my bookshelf, untouched by black sharpie, mocking me for entertaining the thought that my fifteen minutes of fame was the same as actual fame, just shorter.
So I read it.
I figured, if I at least read the book then it served some purpose other than mocking me. Its placement on my bookshelf would be germane to it being a book that I read like everything else on it, rather than a waste of money that I bought too long ago to return to Amazon. And hey, maybe it would completely suck and I could give it one star on goodreads.
But in fact, the truth is that it's pretty good. It's not a terribly funny book, but it's an honest one. And though it does START with a huge stress on Patton's goal of watching classic films, that's pretty much done by the end of the first chapter, with only occasional callbacks later on. The rest of the book mostly deals with his career, covering his early start as a stand-up comedian, talking about his first acting gig on Down Periscope, and his time as a staff writer on MADtv. These sections of the book were weirdly fascinating and extremely honest - I particularly enjoyed Patton's self-introspection as he recounted his first-ever speaking line on film and how he overanalyzed all the ways he might say it. It reminded me of my own thoughts working through what I'd say to him when I met him.
Given the personal experience I've recounted in this review, you can imagine how hollow Patton's words rang for me when he discussed meeting Jerry Lewis, or how nerve-wracking it was sharing a stage with his "idols" like David Cross, Dana Gould, and Laura Kightlinger. Imagining Patton as a giddy youngster meeting celebrities he admired was difficult while also imagining him as an A-lister callously dismissing a fan by telling him that his name would be on a nonexistent list.
Overall though, and particularly for anyone who wasn't personally cast aside by Patton Oswalt, Silver Screen fiend is actually (unfortunately) a really good book. Entertaining without being "jokey," and very honest. It's a great look "behind-the-scenes" at show business, and it offers a lot of insight into Patton as a person and what made him who he is today. If you're into Patton Oswalt's comedy, don't let the title or even the book's description turn you off the book, I think you'll enjoy it.
Patton eventually responded to me on Facebook, long after I'd already given up and gone home. He assured me "you were supposed to be on the list" doubling down on the fiction. He asked me what I wanted signed, and offered to mail it to me. I told him no thanks....more
This is just about the most you could expect from a book about Docker. It's far, far better than the documentation, it talks about best principles andThis is just about the most you could expect from a book about Docker. It's far, far better than the documentation, it talks about best principles and practices, and every single suggestion is accompanied by detailed commands to type to accomplish the tasks. The book has a great throughline of developing and improving a small application, which is used as a reference in every single chapter.
It covers almost everything you want to know about Docker including more operational stuff like monitoring, orchestration, and security. Pretty much no stone is left unturned, what you want to know about using Docker for real is covered eventually.
Occasionally I wished the book went into a bit more depth, or I felt like the author was sort of hand-wavey. There were a lot of times when he'd say something like "don't do this in production" without much explanation of what you WOULD want to do in production. Additionally, there were frequent mentions of how this or that aspect of Docker will be fixed or changed soon, leaving the reader to both wonder if Docker is truly ready for prime time, as well as if this was the proper time to publish a book on the subject with the technology so in-flux.
My biggest complaint is actually about Docker itself. By later chapters, Mouat would show incredibly complex and lengthy commands to type that left me wondering if it was even possible for documentation to be good enough to get a person to the point where they'd be able to type that command from scratch. What would you do if you wanted to do something slightly different than Mouat's example? It seemed almost impenetrable at times.
One thing I felt was lacking was an example of persistent data storage. The identidock example that runs through the entire book is all non-persistent, every single container could be restarted with complete loss of state and have no effect. The closest thing to a database used, redis, was used as a simple cache that could be emptied upon restart with no penalty. But many applications need real-live databases that need to persist across container restarts, and there's basically no coverage of how one would accomplish such a thing. From my own Googling it looks like the agreed-upon pattern is a data-only container volume linked to the system needing to store data, but it would have been nice if the example application could have incorporated such a fundamentally basic need.
Overall the book is fair and does a great job of helping the reader understand the pros and cons of containerized deployments, and it takes you through pretty much everything to know, at least in the world of Docker. In terms of how you might want to change your applications to make them more containerizable, it's largely left to the reader. Nonetheless, I can't imagine there even being a book on Docker that's more thorough and properly-paced than this one, it's basically a Missing Manual....more
I have consistently written a short little review of every book I've read for the last few years, and I'm not willing to let this one break my streak.I have consistently written a short little review of every book I've read for the last few years, and I'm not willing to let this one break my streak. The problem is, I usually read programming books, and I've read hundreds of them so I have a lot to compare to, and thus my reviews of programming books are pretty well informed.
However, this is my second "new dad" book and, I dunno, it's fine I guess? I just have little frame of reference here. I learned some stuff, it's good good advice, and it's easy to read. I basically have no idea what I'm doing as a first-time-father-to-be, so any advice is good. It's a low bar.
There's a lot of breadth here, it covers every trimester as well as the first few weeks with the new baby, which is good. A lot of these books only focus on the pregnancy itself which, yeah I like being helpful to my wife, but it's kind of her thing and I'm not super involved.
One thing I should point out is the tagline of the book "Dude, relax; you’re going to be fine." didn't ring true for me. In fact, I found that I had to stop reading this book immediately before bed, as it would give me anxiety that would cause me to wake up and be unable to sleep. The book didn't relax me at all, quite the opposite. I appreciate all the "heads up" type moments the book conveyed, but relaxation was a distant memory while reading.
Anyway, it's pretty good. Readable, kind of funny, short, useful. It's a new dad book. ...more
Full disclosure: I was a technical reviewer for this book
This is just a simple but rock-solid book on unit testing in Java 8. I wouldn't let the titleFull disclosure: I was a technical reviewer for this book
This is just a simple but rock-solid book on unit testing in Java 8. I wouldn't let the title fool you - it doesn't seem to be a big Java 8 book, in fact it doesn't really even seem to leverage the features Java 8 introduces very much. I think mostly it's a book about Unit Testing in Java, and Java 8 happened to have been released at the time, so it got thrown in the title. The code definitely IS Java 8 (not 7), but I wouldn't say that it's a book all about how Java 8 introduces new features, and here's how to unit test code that uses them, which is kind of what the title implied to me.
Mostly the book seems geared to people who are brand new to unit testing, maybe people who had never written a unit test before. The different mneumonic devices (CORRECT, FIRST, etc) underscore the targeting of newbies. However, it does NOT seem like it is a book for people new to Java itself, or even Java 8, since very little explanation is provided for any of the code aside from the unit tests themselves and why they are the way they are. If you're a big unit tester, you might find a lot of the book doesn't provide you with anything new, but honestly I actually recommend reading it anyway.
Part I is going to be familiar to anyone with background unit testing - it's just the basic mechanics of testing itself. Part II however might give even unit testing veterans some stuff to think about. It's basically all about how to write effective tests that really stress the system - and it introduces a number of mnemonics to that end. A little cheesy but I actually learned quite a bit here, and was surprised at how useful I found it, given how much experience I have writing tests.
When I first started reading Part III, all about the overall design of your code, my reaction was thinking, gosh, a lot of other books cover refactoring... it seems out of scope for a book on testing. I was very skeptical, and I didn't understand why it was included. But once I kept reading, I saw the point, and saw how using mock objects were going to allow us to refactor the book's primary example code into something more testable, and better-designed because of it (it even fixed an issue I had with the code when I first saw it, the side effects in the scoring method). By the end of the section, I was fully on board, and to be honest an entire chapter about refactoring tests was simply amazing (and easily my favorite chapter). To be frank, these later chapters are worth the price of admission alone for the book, I can't remember any other single book that covers refactoring to improve quality of tests themselves (especially in a step-by-step fashion). I can't even remember a book that covered testing multithreaded code, and for it to just be a chapter at the end of a book on testing in general was a real treat. This book covered absolutely everything, mock objects, refactoring, TDD, SOLID, and of course the basic principles of unit testing in general.
I was pretty impressed with how thorough and useful parts I and II were, but I was blown away by III and IV. Simply put, this is probably my favorite book on unit testing I've ever read. If you're new to unit testing and use Java (even if it's not Java 8), this book is a must-read. If you're a unit testing pro, there might not be that much for you here, but I still recommend giving it a read anyway and just skipping bits and pieces. Parts II and III in particular have a lot of valuable insight to share....more
There's not really a lot to say about this book - if you're interested in CoffeeScript, then it's great. It summarizes a lot of what CoffeeScript is aThere's not really a lot to say about this book - if you're interested in CoffeeScript, then it's great. It summarizes a lot of what CoffeeScript is about, the syntax, and is basically very good documentation on the language.
Full disclosure: I was a technical reviewer for this book....more
Full Disclosure: I was a technical reviewer for this book
Your Code as a Crime Scene has a lot of extremely interesting ideas, and for those alone it'sFull Disclosure: I was a technical reviewer for this book
Your Code as a Crime Scene has a lot of extremely interesting ideas, and for those alone it's worth reading. The essential idea is exactly what the title says - this seems weird or impossible at first but I assure you, the title is genuine. Effectively what this book is about is using forensic techniques to figure out which spots in a large code base are most in need of improvement/refactoring.
There are lots of different kinds of things to look for and visualize in your code to help figure out dangerous areas in it, and the book takes you through each one, how it works, and how to get at the data to find these areas. It's really, really interesting, in fact it's one of the most interesting books on software I've ever read. At a previous job, we did something similar to find good candidates for our weekly Refactotum meetings - it was a script that used Git and our ticketing system to find files that were frequently modified, very large, and the source of a disproportionate number of bugs - the function for a evaluating the sort order of the files was kind of complex and involved, and I was actually pretty proud of helping develop it because it was such a neat way of viewing a codebase. I had no idea that some day there'd be a book all about stuff like that, with even more techniques. Really cool.
My main complaint with the book is that the author frequently uses a tool he wrote, code maat, to perform the analyses. I'd have much preferred more stress on the actual methods - I often came away feeling like I'd be unable to employ these techniques without code maat because I didn't get enough detail on the thinking behind the tool. In fact, I think the book often comes off as a code maat tutorial that was renamed. The other thing that bothers me is that often the code base analyzed to illustrate one of the book's ideas is the code maat database itself. This just seemed so self-referential to me, weirdly meta or something. It made it hard for me to really understand things - the code itself was already one step removed from the ideas, and then the codebases being looked at wound up kind of having the same leap. It's hard to explain, but the book would be much better if it analyzed popular open source projects that people use every day, and personally I'd have preferred less involvement from code maat itself - maybe a little paragraph or section at the very end showing how code maat could be used to automate a lot of the more manual work that the previous pages employed.
Overall, I actually highly recommend checking this book out - especially if you work on a large codebase and are concerned about its quality. There are lots of cool ideas in the book to help you find the biggest "bang for your buck" areas to improve the codebase....more