I love channel9.
If you've never heard of it, you should definitely check it out. It’s a site filled with interviews, keynote speeches and demos in video format. It’s one of my favorite learning resources.
I was browsing channel 9 the other day, and came across this keynote. In it, Scott Hanselman talks about social networking, something that I’ve never been really crazy about. Despite my aversion to the topic, the title interested me, so I watched the hour long video clip (and the 25 or 30 minute follow up).
Scott argues that every developer should have a blog and use twitter, I’ll leave the details to the video, but the gist of it is that you should think of it as creating your own personal brand.
I liked the idea of a personal brand so much that I extended the concept to that of a virtual business for my online “persona”, to steal a term from Alan Cooper. By thinking of my online self as a business, I can filter what I am willing to blog about by whether or not it’s good for the business. I know, it’s a bit silly, but it makes me more comfortable with the idea.
Once I changed the way I was thinking about it, I had a philosophical moment where I realized that, not only can I apply this to blogging and my career, but the concept could be applied to virtually all aspects of life. It reminded me of a podcast I listened to a while back about relationships.
I think it could be interesting, as well as, motivating to come up with a mission statement and a set of business rules. At the end of the day though, I think it will make me a better developer and that is what really matters.
Sunday, November 27, 2011
Wednesday, November 16, 2011
Book Review: CLR via C#, Third Edition
This book was 29 chapters of awesome, and if I had to pick a favorite book this would be it.
Jeffrey Richter starts off by explaining how the CLR’s execution model works and how to package and deploy applications. The book covers how to use and design Types, how the garbage collector manages resources as well as threading.
The author does a really great job of explaining everything, and is careful to point out what his personal preferences are and why. The material in this book lays a solid foundation for development using the CLR, C# and the .NET framework.
This book is going to be a great reference.
Jeffrey Richter starts off by explaining how the CLR’s execution model works and how to package and deploy applications. The book covers how to use and design Types, how the garbage collector manages resources as well as threading.
The author does a really great job of explaining everything, and is careful to point out what his personal preferences are and why. The material in this book lays a solid foundation for development using the CLR, C# and the .NET framework.
This book is going to be a great reference.
Tuesday, November 15, 2011
Book Review: Clean Code
When I read the first few chapters of this book, I wrote about my initial reaction. Now that I’ve completed the book, this is a follow up.
This book is basically split in to two things: organizing your code so that it’s easy to read and following “good” OO practices. A great deal of the information presented in Clean Code is Robert C. Martin's personal preference, he’s very upfront about that, and what he has to say throughout the book makes a lot of sense.
The first part of the book makes it seem like writing clean code is relatively simple:
Organizing your code as the author suggests, will make it very easy to read.
The trickier part has to do with the OO principles that are covered.
Knowing when you've violated SRP, OCP or if your methods have multiple levels of abstraction can be more difficult.
Fortunately, there are some nice examples in the book that the author walks you through. This is something that is clearly going to take practice and discipline to master.
All of the examples are in Java. I use C# at work, so I converted the examples to C# and refactored them alongside him. I found this to be very helpful.
In addition to covering the importance of unit testing and the role it plays in keeping your code clean, the author has listed all of the advice at the end of the book. This makes for a handy reference to ensure that you are writing clean code and is listed under the heading “Code Smells”. The list includes advice from the author as well as Martin Fowler.
I enjoyed the book and look forward to mastering the techniques that were covered.
* Update *
I found a video clip of Robert Martin where he presents a lot of the points in this book.
It's a little under an hour long and despite the fact that he rambles a little bit for the first 8 or 10 minutes, it's worth watching.
This book is basically split in to two things: organizing your code so that it’s easy to read and following “good” OO practices. A great deal of the information presented in Clean Code is Robert C. Martin's personal preference, he’s very upfront about that, and what he has to say throughout the book makes a lot of sense.
The first part of the book makes it seem like writing clean code is relatively simple:
- Use unambiguous names for variables and methods.
- Comments should say things that the code can't say for itself.
- Keep methods small.
- Write unit tests.
Organizing your code as the author suggests, will make it very easy to read.
The trickier part has to do with the OO principles that are covered.
Knowing when you've violated SRP, OCP or if your methods have multiple levels of abstraction can be more difficult.
Fortunately, there are some nice examples in the book that the author walks you through. This is something that is clearly going to take practice and discipline to master.
All of the examples are in Java. I use C# at work, so I converted the examples to C# and refactored them alongside him. I found this to be very helpful.
In addition to covering the importance of unit testing and the role it plays in keeping your code clean, the author has listed all of the advice at the end of the book. This makes for a handy reference to ensure that you are writing clean code and is listed under the heading “Code Smells”. The list includes advice from the author as well as Martin Fowler.
I enjoyed the book and look forward to mastering the techniques that were covered.
* Update *
I found a video clip of Robert Martin where he presents a lot of the points in this book.
It's a little under an hour long and despite the fact that he rambles a little bit for the first 8 or 10 minutes, it's worth watching.
Tuesday, November 8, 2011
Does function size matter?
I just finished the 3rd chapter of Clean Code by Robert C. Martin and I feel like my brain has exploded.
I couldn't resist writing a post about what I've read so far, to see what others thought about it. Even though I'm only at the very beginning of this book, I can tell I'm going to like it.
The author believes functions should:
This ends up resulting in a LOT of functions. The author argues that if you do this, your code becomes very easy to understand and reads from top to bottom, like a story.
I've never given much thought to the size of my functions before, but 2 or 3 lines seems exceedingly small. I tend to write functions that are 6 - 10 lines.
I've never given ANY thought to the levels of abstraction in my code, in fact, I didn't even know what that was before I read about it. In case anybody else has never heard of this term, the idea behind it is that everything in the function should be at the same level of granularity. Here is a nice definition from Wikipedia and a post on stackoverflow with a good example.
The author argues that it can be confusing if you don't follow this principle because you aren't able to tell whether an expression is an important concept or a detail. Mixing the two in a function is just as bad as falling to be weary of the broken window theory.
If having code that is easy to read and maintain isn't compelling enough for you, and you are programming against the .Net framework, you might be interested to know that Jeffrey Richter, in CLR via C#, points out that code converted to IL is evaluated on a method by method basis. This means that a method isn't evaluated until it is actually needed - this makes your code run faster. Additionally the CLR optimizes the code by "enregistering " variables in the method, but only if it is small enough. Unfortunately Jeffrey doesn't specify what a "small" method actually is.
I couldn't resist writing a post about what I've read so far, to see what others thought about it. Even though I'm only at the very beginning of this book, I can tell I'm going to like it.
- The first chapter talks about what makes code "clean" (according to the author and a number of developers that are considered industry leaders).
- The second chapter talks about meaningful names, what makes them important, along with some examples. Interesting, but nothing super exciting.
- The third chapter is all about functions. This is where I had a mini freak out in my head.
The author believes functions should:
- use descriptive names
- be small - about 2 or 3 lines each
- do one thing and do it well
- only have 1 or 2 arguments passed to them, preferably none
- have one level of abstraction
This ends up resulting in a LOT of functions. The author argues that if you do this, your code becomes very easy to understand and reads from top to bottom, like a story.
I've never given much thought to the size of my functions before, but 2 or 3 lines seems exceedingly small. I tend to write functions that are 6 - 10 lines.
I've never given ANY thought to the levels of abstraction in my code, in fact, I didn't even know what that was before I read about it. In case anybody else has never heard of this term, the idea behind it is that everything in the function should be at the same level of granularity. Here is a nice definition from Wikipedia and a post on stackoverflow with a good example.
The author argues that it can be confusing if you don't follow this principle because you aren't able to tell whether an expression is an important concept or a detail. Mixing the two in a function is just as bad as falling to be weary of the broken window theory.
If having code that is easy to read and maintain isn't compelling enough for you, and you are programming against the .Net framework, you might be interested to know that Jeffrey Richter, in CLR via C#, points out that code converted to IL is evaluated on a method by method basis. This means that a method isn't evaluated until it is actually needed - this makes your code run faster. Additionally the CLR optimizes the code by "enregistering " variables in the method, but only if it is small enough. Unfortunately Jeffrey doesn't specify what a "small" method actually is.
Monday, November 7, 2011
Book Review: Pragmatic Unit Testing
I didn't even know what unit testing was before I picked up this book.
At not much more than 150 pages, this book is small. It's part of a series called "The Pragmatic Starter Kit". That series is part of a larger series of books that started coming out after "The Pragmatic Programmer" was published.
I LOVE what unit testing promises. To be able to incrementally build code that is known to work AND be instantly alerted when you break it is very, very cool.
The book goes over the NUnit framework, walks you through the initial setup, and shows some unit tests in an example project.
After reading this book, I have no idea how to write a useful unit test.
My guess is that it must take a lot of experience to do it well and might even be a bit of an artform.
The book talks about testing principles, fence post errors, mock objects and edge case scenarios. Things like: testing for null or handing a pre-sorted algorithm to a sort algorithm.
None of that really helps me.
Because of this book, I understand why it's a good idea to write unit tests and what the common reasons are that developers give for not writing them.
Even though I scratch my head a lot when I try to write a unit test, I've started using them. I open the book up, look through the examples, and skim the chapters looking for an appropriate example. Most of the time I feel like I'm missing something.
I'm wondering if I need to read a different book, one that has more concrete examples or find an open source project that uses unit tests.
At not much more than 150 pages, this book is small. It's part of a series called "The Pragmatic Starter Kit". That series is part of a larger series of books that started coming out after "The Pragmatic Programmer" was published.
I LOVE what unit testing promises. To be able to incrementally build code that is known to work AND be instantly alerted when you break it is very, very cool.
The book goes over the NUnit framework, walks you through the initial setup, and shows some unit tests in an example project.
After reading this book, I have no idea how to write a useful unit test.
My guess is that it must take a lot of experience to do it well and might even be a bit of an artform.
The book talks about testing principles, fence post errors, mock objects and edge case scenarios. Things like: testing for null or handing a pre-sorted algorithm to a sort algorithm.
None of that really helps me.
Because of this book, I understand why it's a good idea to write unit tests and what the common reasons are that developers give for not writing them.
Even though I scratch my head a lot when I try to write a unit test, I've started using them. I open the book up, look through the examples, and skim the chapters looking for an appropriate example. Most of the time I feel like I'm missing something.
I'm wondering if I need to read a different book, one that has more concrete examples or find an open source project that uses unit tests.
Saturday, November 5, 2011
Book Review: C# 2010 for Programmers, 4th edition
This book isn't for everybody. I found it to be perfect.
My first programming course in college was taught with the "C: How to Program" book by Paul and Harvey Deitel. I think that made this book feel very familiar to me. The difference between the "How to Program" and "For Progammers" series, is that the former includes practice exercises, the latter does not.
I really enjoy the Deitel books, and don't mean to make this sound like a negative review; however, I think the title of this book is a little misleading. The book's title should have been something more like: Intro to .Net development using C#.
In my opinion if you are an experienced developer that needs to pick up C# and .Net, you will probably be disappointed with this book. I think you can probably get what you need from google and some trial and error. On the other hand, if like me, you are a newbie and haven't done much programming and haven't had a chance to become familiar with OOP, XML, UML, etc, then I highly recommend this book. Reading this book will introduce you to the basics I just mentioned as well as C# 4 and .Net, Silverlight, WPF, XAML WCF, Windows Forms, Visual Studio and SQL server express.
The book is well written and offers the classic Deitel "tips" (common programming errors, software engineering tips, etc), that said, it feels like an introductory programming book that you can save a few bucks on because it doesn't have the exercises that you would find in a classroom textbook.
My first programming course in college was taught with the "C: How to Program" book by Paul and Harvey Deitel. I think that made this book feel very familiar to me. The difference between the "How to Program" and "For Progammers" series, is that the former includes practice exercises, the latter does not.
I really enjoy the Deitel books, and don't mean to make this sound like a negative review; however, I think the title of this book is a little misleading. The book's title should have been something more like: Intro to .Net development using C#.
In my opinion if you are an experienced developer that needs to pick up C# and .Net, you will probably be disappointed with this book. I think you can probably get what you need from google and some trial and error. On the other hand, if like me, you are a newbie and haven't done much programming and haven't had a chance to become familiar with OOP, XML, UML, etc, then I highly recommend this book. Reading this book will introduce you to the basics I just mentioned as well as C# 4 and .Net, Silverlight, WPF, XAML WCF, Windows Forms, Visual Studio and SQL server express.
The book is well written and offers the classic Deitel "tips" (common programming errors, software engineering tips, etc), that said, it feels like an introductory programming book that you can save a few bucks on because it doesn't have the exercises that you would find in a classroom textbook.
Thursday, November 3, 2011
Book Review: The Pragmatic Programmer
When I first started reading this book, it seemed to me to be a lot of stuff that I would consider common sense. As I progressed through the book, I noticed that it felt more and more like I was getting really good advice from an experienced developer.
I'm glad I read The Pragmatic Programmer early in my career. The authors talk about things that I think you can spend a lot of your time, if not your entire career, perfecting; things like the DRY principle, being careful not to program by coincidence, and the value of being able to make good estimates.
They also mention some really interesting things to ensure your code stays tidy and flexible, like moving the things that can change out of your code and in to configuration files, programming to an interface, and being aware of the broken window principle.
Overall I enjoyed the book, but I wish it had been more detailed. All of these principles are really great, but it would be nice to have somebody that's been there and done that to actually show you the ropes. The authors acknowledge this shortcoming in the resources section at the end of the book and provide a nice list of books, blogs, magazines and web references to look in to for further reading.
I'm glad I read The Pragmatic Programmer early in my career. The authors talk about things that I think you can spend a lot of your time, if not your entire career, perfecting; things like the DRY principle, being careful not to program by coincidence, and the value of being able to make good estimates.
They also mention some really interesting things to ensure your code stays tidy and flexible, like moving the things that can change out of your code and in to configuration files, programming to an interface, and being aware of the broken window principle.
Overall I enjoyed the book, but I wish it had been more detailed. All of these principles are really great, but it would be nice to have somebody that's been there and done that to actually show you the ropes. The authors acknowledge this shortcoming in the resources section at the end of the book and provide a nice list of books, blogs, magazines and web references to look in to for further reading.
Book Reviews
I've been reading.
On average, I read one book related to software development per month.
I've been doing this since I started developer work in March.
I'm going to review what I've read and express my personal opinion.
I'm a newbie so this will naturally be reflected in my review.
My hope is that this will generate discussion and suggestions for further reading and exploration.
At first, most of what I was reading was directly related to projects that I was working on. As I started to get a handle on the basics at work, I compiled a list and started working through it.
I developed the list based off advice from a couple friends, Marshall being one of them, as well as recommended titles I found while searching stackoverflow.
See what I'm currently reading.
To date I've read:
- C# 2010 for Programmers
- Professional Silverlight 4
- CLR via C# (Dev-Pro) (text only) 3rd (Third) edition by J.Richter
- Programming Entity Framework 2nd edition
- Refactoring to Patterns
- Agile Software Development, Principles, Patterns, and Practices
- Pragmatic Unit Testing in C# with NUnit, 2nd Edition
- The Pragmatic Programmer
- C# in Depth, Second Edition
- Clean Code
- Code Complete
Books remaining in my library that I haven't read:
- Inside the Microsoft Build Engine
- The Inmates Are Running the Asylum
- Effective C#
- More Effective C#
- Head First Object-Oriented Analysis and Design
Books I'm planning on adding to my library:
- Patterns of Enterprise Application Architecture
- Real World Functional Programming: With Examples in F# and C#
Books I'm considering adding to my library:
- UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)
- Programming WCF Services: Mastering WCF and the Azure AppFabric Service Bus
- WPF 4 Unleashed
- Silverlight 4 Unleashed
- Universal Principles of Design, Revised and Updated: 125 Ways to Enhance Usability, Influence Perception, Increase Appeal, Make Better Design Decisions, and Teach through Design
- Coder to Developer: Tools and Strategies for Delivering Your Software
- Software Craftsmanship: The New Imperative
Subscribe to:
Posts (Atom)