HTML5 for .Net Developers Preview

I am new to the book preview scene, but, I was excited for my first preview. I finished working my way through HTML5 for .Net Developers (http://www.manning.com/jackson/) preview for Manning Books. This book was written by Jim Jackson II and Ian Gilman and is a very good source for .Net developers like me who do not have a lot of experience with developing for the web. I was very impressed with how in depth the book was, especially with all of the roadblocks that HTML5 currently has with web browser support. 

Pro Tip: Use multiple browsers to work your way through the code (I know, obvious to web developers). There are good resources on the web that tell you which browsers support what, but, I learned early on that I should test the code against more than just IE. 

HTML5 for .Net Developers starts off with a little history and then gets right in to it. There are times when you have to hold your concentration as the book can be a little dry at times, but, when you start to deep dive into the different aspects of HTML5 and how it can be used with the different standards for elements and how it uses Javascript and CSS 3, the book moves faster. You can then tell the authors excitement for the topic and they let it show. 

One aspect of the book I really appreciated were the samples. Each sample is annotated to help you understand by explaining the samples. I found this really useful when trying to follow along. In reading this book, you will be shown many of the differences between HTML4 and HTML5, complete with code snippets, diagrams, and illustrations. 

Most of what I got out of the book was the basics of HTML5 and how it easily incorporates JavaScript APIs and CSS3 as that was what I was most interested in. There are many more topics I did not cover in my preview, such as jQuery, WCF, MVC 3 that are covered in this book. I will be proud to have this book in my stack of resources. 

My Experience with TDD

TDD. Test Driven Development. Extreme Programming Practice. I wish I had more experience in it. TDD was introduced to me at my previous position. At first, I was extremely skeptical. I rejected the notion of TDD. Then, a year or so later, I got interested in it. I started using it at home in my personal C# projects using NUnit. I noticed a benefit right off the bat. All the functionality I required; all the functionality that was cool and new; just worked. This made the User Interface easier to develop.

There are huge benefits in TDD. The first that comes to mind is… well, it’s a test. If you can write a test before writing the supporting code, then you shouldn’t many bugs. Of course, you can’t write a test for every scenario, many User Interface bugs can’t be or are very difficult to write a test for.. This leads to another benefit. Because you are writing the test first, you can get 95% or more code coverage because you should have a test for everything. This also eliminates most of the scope creep we generally have problems with, because, the tests should go against user stories or gathered requirements.

Test Driven Development is a practice of writing the unit test before having the code to support that test. I was explaining this to my mom a couple of weeks ago and she had a hard time grasping the concept. She’s not a developer. She has a certain set of rules she follows. She is fairly rigid in those rules. One of them, just so happens to be, is that you can’t test something doesn’t exist yet. I run into this a lot with other developers as well. We are “programmed” to believe in a process. That process does not change. That process is what gets us through.

It’s time for us to rearrange our processes. I’m starting to believe in this process of TDD.

Another benefit of TDD is that it sort of forces you to think in terms of reuse-ability. Why should I create new methods for my tests, when a similar method already exists. I could refactor that method and retrofit it with the other method call. Do you know how I found the other test accessor to that method? I made the change to the current method and ran my tests. It told me exactly where to make the change because that test failed. I noticed that when I was thinking in terms of reuse-ability, I also started to employ Dependency Injection. TDD was making me a better programmer.

That all sounds good and all, but, there are aguments against TDD. One of these arguments is that it does take a little more time to use this practice. But, I want to offer a rebuttal. This extra time writing the test and then writing the supporting code actually saves you time in the long run. You are making sure that certain functionality both exists and functions as expected. Besides, you are writing unit tests for your code, right? Right? So, why not write them first? I have found that there is diminished support time due to writing the tests first. These tests should pass before it leaves production, so, unless there are unaccounted issues with the data (and there shouldn’t be, because it should be something you are testing for) the application should work correctly out of the box.

These have been my thoughts and experiences regarding TDD. I have become a true believer in the practice and would like to pass on the knowledge and practice. Right now, this is really the only place I can do so; so, there you go.

PIE

Pie is good. Pie comes in many flavors. Pie makes me feel better. Unfortunately I’m not going to talk about the pie we eat. I’m going to talk about the three pillars to object oriented programming, Polymorphism, Inheritance, Encapsulation.

POLYMORPHISM

Every time I hear this word, I think of the Matrix, probably because Morpheus sounds like Morph… Anyway, there is also a little more to it than that. You see, Morpheus can take on more than one form. He can be in the real world, but, he can be in the Matrix at the same time. He also has different abilities in both “realities.” This does kind of relate to Polymorphism. Polymorphism is the ability to take on multiple forms and perform different functions based on the current form. I’m not talking about the Wonder Twins either, so, there will be no talk of taking the “Form of a …” Being able to mold into what is needed for a particular function can be useful. This is most easily done by using interfaces. You can cast the class as what you need it to be based on the interface and know there will be functionality attached to that class that you can use.

INHERITANCE

Inheritance is taking on the functionality of other classes or interfaces. By doing this, you are combining your classes abilities to perform multiple functions. The most used example of this is the relationship between a vehicle and a car. A vehicle has it’s own traits and it’s own things it can do. A vehicle can have a color, can have windows, can have a glove box. A vehicle can also go, stop, turn… A car can have the same traits. A car can also go, stop and turn. But, the car is more specific. This car may also have cup holders and this car may also have a stick shift. This car may also be able to open the door, or, close the trunk. The car extends the functionality of the vehicle by inheriting those traits and functions and adding it’s own.

ENCAPSULATION

Ah, information hiding! This is most commonly used with properties that you don’t want to expose. You would use a private variable for the encapsulated class and then use public methods to “get/set” that variable. The other easy example is to have that classes public methods call protected methods. By using encapsulation, you are not letting the consumer of this class use it in an inappropriate way. This keeps the business logic sound and doesn’t allow confusion from the consumer.

Not quite cherry or apple flavored, but I hope I gave a short, useful introduction to PIE and piqued interest in how these three pillars can be used.

Smart Models vs. Dumb Models

This is something I’ve been wrestling with for a while and I am starting to take a preference. I know there is gray area between these two extremes, but I will admit, I am making a push to one side.

I am referring to a dumb model as a data structure. It is just a bland model that is set up as a class. It has properties, but that is as far as it goes. It knows nothing of the project/solution outside of itself. A smart model would be the polar opposite. It also sets up your data as a structure, but also includes events, methods and access to the data access layer.

In my at home projects, I have come to prefer the smart models. It has lead to cleaner code in the GUI as well as the data access layer. When the models are set up, the data access layer and the GUI also tend to have minimal code. This has also made it easier to set up reusable project dlls.

An unexpected result of using smart models is the non existence of a controller layer (in the common sense of the term) in my projects, simply because it’s not needed. I guess that takes the MVC (Model View Controller) pattern down to a MV (Model View) pattern.

What say you?

Can You Decouple too Much?

I’ve been working on a project at home and came up with a question for which I flip back and forth. Can you write an application that is too separated, too decoupled?

I am writing an application where I always use the data access layer for my data methods, a business layer for other common methods, and the models where mere object definitions.

What if I want to call a method on the model object? I am using some other layer, but what I want to call is specific to that object and is not going to be used on any other object. What do you do in that case?

If you decouple, then you use the business layer or the data access layer. If you don’t decouple, then you might call the data access layer or the business layer to perform this method from the model.

Does it comes down to how and where the objects are going to be used? What else do you take into account? If you set up a method call in an model object, do you make it static?

To take it to another level, what if you want to set up events on the model? Do you try to add the events to the other layers if you are decoupling?

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!