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.
Monday, November 7, 2011
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
Tuesday, October 25, 2011
Are comments always necessary?
I was reminded of a conversation Marshall and I had about comments when I read this post by Jesse Liberty.
The post gives an example of the reason your comments should explain why you're doing something, rather than how you're doing it.
At the end, Jesse argues that if your reader knows the language, your comments will be reduntant if you use descritptive names for methods and variables.
Lately I've been thingking a lot about how much I should be commenting. And whether or not I'm just stating the obvious.
Take this method for example.
public string GetRunTimeForAllCars()
{
IEnumerable<Car> listOfCars = listOfVehicles.FindAll(c => c is Car).Cast<Car>();
double totalRunTime = listOfCars.Select(t => t.RunTime).Sum();
return totalRunTime.ToString("f2");
}
I experimented with a few ways or writing the method out before I decided on this one.
I think it's pretty clear and doesn't need any comments to tell you what's going on.
What do you guys think?
Are comments always neccessary?
If somebody doesn't know linq, can they still understand what that code is doing?
The post gives an example of the reason your comments should explain why you're doing something, rather than how you're doing it.
At the end, Jesse argues that if your reader knows the language, your comments will be reduntant if you use descritptive names for methods and variables.
Lately I've been thingking a lot about how much I should be commenting. And whether or not I'm just stating the obvious.
Take this method for example.
public string GetRunTimeForAllCars()
{
IEnumerable<Car> listOfCars = listOfVehicles.FindAll(c => c is Car).Cast<Car>();
double totalRunTime = listOfCars.Select(t => t.RunTime).Sum();
return totalRunTime.ToString("f2");
}
I experimented with a few ways or writing the method out before I decided on this one.
I think it's pretty clear and doesn't need any comments to tell you what's going on.
What do you guys think?
Are comments always neccessary?
If somebody doesn't know linq, can they still understand what that code is doing?
Monday, October 17, 2011
Being a better developer
Scott Hanselman lists some things to "sharpen the saw" on his website.
I listened to the podcast he links on his page, he mentions several things I found interesting.
Reading books is a great way to learn, but Scott warns about becoming "too academic". A great way to improve your own code is to read other's code. Of course, you want to make sure the code you're reading is "good code". One way to do this is to read code from successful open source projects.
Scott mentions several by name:
CastleProject, Microsoft's Patterns & Practices, SubText and he puts in a plug for dasBlog as well.
Other things he talks about doing are:
Talking with other developers about how they do things.
Teaching a class on a topic and joining a developer's users group.
I'm guilty of being too academic. I do a lot of reading, mostly books.
Since March I've read: Programming Entity Frameworks, Refactoring to Patterns, Pragmatic Testing in C# with nUnit, C# in depth, and I'm halfway through CLR via C#. These are on my list for the next 6 - 12 months: The Pragmatic Programmer, Clean Code and Code Complete 2, they've arrived at my house and I'm really excited to read them!
I also listen to podcasts, mostly Scott Hanselman's, and I read blogs from the same, as well as, Scott Guthrie, Jeffrey Palermo, Eric Lippert, Julie Lerman and John Papa.
I've watched quite a few videos on SilverlightTV and Channel9.
There are some really great videos on that site.
I really like watching the videos and downloading the code from the show, it's really great to be able to go through the code to see how they've done what they're talking about on the show.
That makes me think that checking out code from some of those open source projects is going to be really good for me.
Scott briefly mentions that learning a new language to get out of your comfort zone is a good idea.
I've heard this idea on other podcasts and read about it as well. The idea being that if you're a Windows guy working in .Net you should try running Linux and play around with Python, Perl, Ruby on Rails, etc. To that end, I set up my home computer to dual boot Windows and Ubuntu. I installed MonoDevelop and eventually plan on learning IronPython (since it works with .Net in Visual Studio) and F#. I'm also considering eventually taking a look at Ruby on Rails, Lisp and Smalltalk.
I'm going to start by downloading and reading code from one of those projects, it sounds like that's where it's at.
What do you guys think?
I listened to the podcast he links on his page, he mentions several things I found interesting.
Reading books is a great way to learn, but Scott warns about becoming "too academic". A great way to improve your own code is to read other's code. Of course, you want to make sure the code you're reading is "good code". One way to do this is to read code from successful open source projects.
Scott mentions several by name:
CastleProject, Microsoft's Patterns & Practices, SubText and he puts in a plug for dasBlog as well.
Other things he talks about doing are:
Talking with other developers about how they do things.
Teaching a class on a topic and joining a developer's users group.
I'm guilty of being too academic. I do a lot of reading, mostly books.
Since March I've read: Programming Entity Frameworks, Refactoring to Patterns, Pragmatic Testing in C# with nUnit, C# in depth, and I'm halfway through CLR via C#. These are on my list for the next 6 - 12 months: The Pragmatic Programmer, Clean Code and Code Complete 2, they've arrived at my house and I'm really excited to read them!
I also listen to podcasts, mostly Scott Hanselman's, and I read blogs from the same, as well as, Scott Guthrie, Jeffrey Palermo, Eric Lippert, Julie Lerman and John Papa.
I've watched quite a few videos on SilverlightTV and Channel9.
There are some really great videos on that site.
I really like watching the videos and downloading the code from the show, it's really great to be able to go through the code to see how they've done what they're talking about on the show.
That makes me think that checking out code from some of those open source projects is going to be really good for me.
Scott briefly mentions that learning a new language to get out of your comfort zone is a good idea.
I've heard this idea on other podcasts and read about it as well. The idea being that if you're a Windows guy working in .Net you should try running Linux and play around with Python, Perl, Ruby on Rails, etc. To that end, I set up my home computer to dual boot Windows and Ubuntu. I installed MonoDevelop and eventually plan on learning IronPython (since it works with .Net in Visual Studio) and F#. I'm also considering eventually taking a look at Ruby on Rails, Lisp and Smalltalk.
I'm going to start by downloading and reading code from one of those projects, it sounds like that's where it's at.
What do you guys think?
Saturday, October 15, 2011
Good Taste
In episode #222 "Art is Shipping", Scott Hanselman interviews Jin Yang, the lead designer for StackOverflow.
In this podcast Jin Yang mentions a couple things that I found really interesting:
The first was that a well designed site should evoke a feeling from it's users.
I had never considered this, but it makes a lot of sense. Imagine you have a site where you want your users to donate money for some worthy cause, you might design the site to evoke a feeling of compassion so that your visitors will be inclined to donate more.
The second was that good taste can be developed.
This got me to thinking "what is good taste?". According to Immanuel Kant, it comes down to a judgement based on a subjective feeling. Well, if that's the case, how do you get better at it?
Scott links a number of design blogs in the notes for the show, perhaps the anwer is to check out the blogs, see what others are doing, and take from that the things that appeal to you.
I've found that I'm a big fan of minimalist art, a style that Apple has been really good at.
What do you guys think? What is good taste and how do you recognize it?
In this podcast Jin Yang mentions a couple things that I found really interesting:
The first was that a well designed site should evoke a feeling from it's users.
I had never considered this, but it makes a lot of sense. Imagine you have a site where you want your users to donate money for some worthy cause, you might design the site to evoke a feeling of compassion so that your visitors will be inclined to donate more.
The second was that good taste can be developed.
This got me to thinking "what is good taste?". According to Immanuel Kant, it comes down to a judgement based on a subjective feeling. Well, if that's the case, how do you get better at it?
Scott links a number of design blogs in the notes for the show, perhaps the anwer is to check out the blogs, see what others are doing, and take from that the things that appeal to you.
I've found that I'm a big fan of minimalist art, a style that Apple has been really good at.
What do you guys think? What is good taste and how do you recognize it?
Subscribe to:
Posts (Atom)