The hilarity of players randomly changing their names for no reason never gets old. Enter the Centerfielder Formerly Known as B. J. Upton. You are now legally required to call him Melvin Upton, Jr. I don’t know how this will help the vortex of suck that is his bat, but I have a suspicion.
You’re welcome, Kevin.
SQL injection vulnerabilities were up in 2014. Sounds like a bunch of product managers need to buy copies of Tribal SQL and read the SQL injection chapter. Seriously, SQL injection should have died a decade ago and my presentation on the topic should simply have historical value.
On the Anthem breach, Chris Bell is fed up as well. Check out the comments there for additional insight. There’s no word yet on the exact nature of the breach, but given the frequency with which data gets out into the wild, someone else will get popped next week.
My first Play By Play was a doozy. In this one, Rob Conery and Scott Hanselman move the This Developer’s Life podcast site to Azure. I was particularly interested in this because I had just started using Azure myself, so I wanted to see what they did.
Although the nature of this move was different than mine, I still picked up an excellent tip. For Paskala, I had http://www.paskala.com set up as a CNAME to redirect to my website. I wanted to do the same with paskala.com but my web host (Webfaction, an excellent host I highly recommend) does not allow the same domain to have a CNAME as well as the ability to handle e-mail.
My hacky solution was to have Webfaction host a tiny site that does a 302 redirect to http://www.paskala.com. Hanselman’s solution, however, is the correct one: create an A record pointing to the relevant Azure IP address. That way, Webfaction handles e-mails to paskala.com but HTTP(S) requests to paskala.com go to Azure and all is well.
This is the big thing I learned from that hour-long talk, and that simple point was absolutely worth the talk for me. I would also recommend this session to show what a top-notch presentation looks like; the two speakers bounce off of each other really well, but the graphics are incredible and it feels like a film.
I just finished up Max Kanat-Alexander’s Code Simplicity: The Fundamentals of Software. I’m having a difficult time reviewing this book for a couple of reasons. I liked the concept, the contextual stories (particularly with respect to Bugzilla), and some of the ideas. Something that struck me as very interesting is the idea that development effort really boils down to the sum of all future effort over the sum of all future maintenance expenditure, and that these future measures generally overwhelm present value and cost. This was contrary to my prior belief, but after thinking about it some, I can see the argument. I don’t think it’s quite as clear-cut as Kanat-Alexander makes it out to be, but there is definitely value.
The focus of the book is on simplifying design, and much of the book is an argument for why one should simplify design. This really feels like it should be the first section of a larger book on design. I recommend reading the book, but it really isn’t that much longer than, say, a series of blog posts. This, combined with Kanat-Alexander’s very informal and friendly writing style, made the book almost saccharine in nature: it’s very sweet but not as filling as you’d want.
It’s official, the MLB committee about game pacing has spoken. All of the changes seem very reasonable and relatively easy to enforce. Anything that makes baseball more enjoyable is good for me.
My second Pluralsight course was Deborah Kurata’s Practical LINQ. I’ve been familiar with LINQ since its introduction in .NET 3.5, but like I mentioned before, I wasn’t as comfortable with it as I could have been because a lot of the Intellisense looks scary. Admittedly, that’s a pretty silly reason for not learning more about a technology, but I never had somebody explain it to me in a way that really clicks. Between Skeet/Conery and Kurata, I’m now a lot more comfortable with LINQ.
One of the big things I liked about Practical LINQ is that I was able to see and re-create all of the code on my own. I now have the full Pluralsight subscription which includes file downloads, but at the time, I was working off of a trial subscription. But even if I had access to the files, I find it a lot better to type out the code myself—it helps me think about what I’m typing and reflect upon what the writer intends—and I appreciate that Kurata’s examples are that way.
My single criticism of this course is that Kurata talks too slowly. If I had paid attention to the speed knob, I definitely would have turned it up to 1.5x.
I just finished up Mark Seemann’s opus, Dependency Injection in .NET. This book took a lot longer than I expected and I pretty much skipped his Part IV on various dependency injection frameworks (because I’m using Ninject, which he did not cover). This is a hefty tome at nearly 600 pages and Seemann goes into great detail on the topic of dependency injection.
My experience with dependency injection coming into the book was nil—in part because I’ve lived on the T-SQL side of the world for the past several years and probably haven’t written a non-trivial application in an object-oriented language this decade—and so I greatly appreciated the first part of the book. When Seemann described the wrong way of n-tier development, I immediately recognized it as the way I wrote code, and I kind of cringed. Seemann’s n-tier example included a data access layer, a business layer, and an application layer, and the wrong way had the app & business layers linked to the database layer, and the app layer linked to the business layer. This level of tight coupling has plenty of problems that I have experienced, but I simply didn’t know how to get around issue.
This is where parts 2 & 3 of the book come in. Throughout these parts, Seemann walks through “poor man’s DI,” manually writing code to perform dependency injection. He discusses what a composition root is, where to put the composition root (e.g., the Global.asax for ASP.NET MVC, or the Main method for a console application), how to build injectable objects, and he even spends some effort on refactoring older code to support dependency injection.
I can recommend this book, but at least for me, I needed supplementary resources to understand the topic better. It probably works great as a detailed manual for somebody familiar with the topic, but if you aren’t, be sure to check out videos on the topic and don’t be afraid to jump around a bit to understand where he’s going.