Infragistics ASP.NET controls

The mono project. The state of .NET on non Microsoft platforms.

Ubuntu too I've recently decided that I wanted to install linux on an older PC in my home.  Many moons ago, before most linux distributions could auto detect and configure your hardware, I had cut my teeth on Debian.  I've had a soft spot ever since for the aptitude package manager.  Naturally I wanted to use a distro that was based on Debian so I went with Ubuntu.  The Ubuntu CD that I have is dated (version 8.04) so I did some research and decided to upgrade to version 10.04.  I fired up a terminal and executed 'sudo do-release-upgrade -d' to apply an upgrade to my system. Watching LED dry The upgrade was a pretty long process, and I found myself watching the terminal window as all of the packages were added, upgraded, and removed.  As I watched, I noticed that quite to my surprise, there were many packages that relied on mono assemblies.  As a .NET consultant, of course this had sparked my curiosity.  I've followed the mono project, from a distance, for a while now but I knew that there was a following, however, I had no idea that mono had made it's way into the heart of the packages that make up an Ubuntu installation.   The current state of things I've decided to take a 1,000 feet view of the current state of the mono project.  As stated by the official website; The easiest way to describe what Mono currently supports is:Everything in .NET 4.0 except WPF, EntityFramework and WF, limited WCF.   That's quite a lot of functionality!  I had no idea that there had been so much work done on the project.  I can write a .NET 4.0 application, an ASP.NET MVC 2 web application and host it on a linux based Apache server.  Well at least that's what the website has told me. Perhaps I'll try to accomplish just that and write about how smooth the whole process actually is. Here are some links for those who are interested. The official mono homepage http://www.mono-project.com/Main_Page The mono project compatability http://www.mono-project.com/Compatibility The mono migration analyzer MoMA http://www.mono-project.com/MoMA Design apps for your iPhone or iPad using monoTouch http://xamarin.com/monotouch Design apps for your android device using mono for android http://xamarin.com/monoforandroid I hope you found something of interest.  Until next time.. ~/Buddy James   kick it on DotNetKicks.com  


.NET Enumerated Types Explained

  My codeproject article on .NET enumerated types. http://www.codeproject.com/Articles/91195/NET-Enumerated-Types-Explained Introduction The purpose of this article is to provide an introduction to .NET enumerated types. Background Code readability is a big factor when considering the quality of source code. The easier code is to understand, the easier it is to maintain. Have you ever found yourself using numbers to represent a range of variable values? For example:  Collapse | Copy Code Dim CalculationOperation As Integer = 0 CalculationOperation = _ GetOperation () Select Case CalculationOperation Case 1 ’ Addition _PerformAddition() Case 2 ‘ Subtraction _PerformSubtraction() Case 3 ‘ Multiplication _PerformMultiplication() End Select This requires you as well as any other developers that might touch your code to remember all of the possible numeric values that represents colors. This can be a maintenance nightmare! To solve this problem, VB.NET has enumerated types. Reasons to Use Enumerated Types Readability From Wikipedia: "In computer programming, an enumerated type (also called enumeration or enum) is a data type consisting of a set of named values called elements, members or enumerators of the type. The enumerator names are usually identifiers that behave as constants in the language." Enumerated types allow you to give an English description to a range of integer values. Perhaps an example will explain this.  Collapse | Copy Code Public Type CalculatorOperations Addition = 1 Subtraction = 2 Multiplication = 3 End Type Dim Operation As CalculatorOperations Operation = _ GetOperation () Select Case Operation Case CalculatorOperations.Addition _PerformAddition() Case CalculatorOperations.Subtraction _PerformSubtraction() Case CalculatorOperations.Multiplication _PerformMultiplication() End Select     This routine is easier to read. When coding a routine, be sure to consider numeric literals that represent a value other than the number itself as a possible reason to create an enumerated type. Enums as Routine Parameters Enumerated types are great as routine parameters. Consider the following example. Bad Example  Collapse | Copy Code Dim ApplicationState as Integer = 5 ‘lets say five stands for Fatal Crash! Sub _SetApplicationState(ByVal State As Integer) Good Example  Collapse | Copy Code Dim ApplicationState As AppState = AppState.FatalCrash Sub _SetApplicationState(ByVal State As AppState) If you are using Visual Studio, then you no doubt have noticed the benefit of using enumerated types as function parameters. While you are writing the code to call the routine, intellisense will show you all available members of the enumerated type. Compiler Type Checking Using enumerated types also provides type checking by the compiler. Consider the following block of code:  Collapse | Copy Code ‘Valid color values are 0 – 9 Dim CurrentColor As Integer CurrentColor = 12 ‘invalid color This is impossible with enumerated types. Enumerated types can make powerful return values. Consider the following code:  Collapse | Copy Code Dim LoginResult As Boolean = false LoginResult = _AttemptLogin() If LoginResult = True Then _Authenticateuser() End If If LoginResult = False Then _InitiateLogin() End If As you can see, true and false allow for two conditions:  Collapse | Copy Code Dim LoginResult As AuthResult LoginResult = _AttemptLogin() If LoginResult = AuthResult.Authenticated Then _Authenticateuser() End If If LoginResult = AuthResult.Failed Then _InitiateLogin() End If If LoginResult = AuthResult.Suspended Then _AlertSuspended() End If If LoginResult = AuthResult.AuthenticatedChangePassword Then _InitiatePasswordChange() _AuthenticateUser() End If Do you see the possibilities? Define the First and Last Entry as Loop Limits You may find yourself in a situation where you need to iterate through each member of your enumerated type. One suggested practice is to reserve the first and last element as loop limits.  Collapse | Copy Code Public Type RGBValue RGB_FirstValue = 0 RGB_Red = 0 RGB_Green = 1 RGB_Blue = 2 RGB_LastValue = 2 End Type Dim RGBVal As RGBValue For RGBVal = RGBValue.RGB_FirstValue To RGBValue.RGB_LastValue ‘process here Next Here is an example of iterating through an enum. 'Imagine if you had an enum for EmployeeTypes and you 'wanted to iterate over 'each employee type and perform an 'action. 'For instance Public Type EmployeeType  Cashier = 0  Supervisor = 1  Manager = 2  Executive = 3 End Type Dim employeeType As EmployeeType For employeeType = EmployeeType.Cashier To EmployeeType.Executive  CalculateRaise(employeeType) Next Conclusion Well, I hope I’ve illustrated some of the benefits of using enumerated types. All of your feedback is welcome.   kick it on DotNetKicks.com  


Design and Document your Code using PDL (Programming Design Language)

Introduction Many of us underestimate the importance of proper code documentation through comments. Comments, when used correctly, can greatly increase the maintainability of your functions and routines, especially if there is any chance that another developer will ever need to look at your code. It's hard enough for you to remember what your intentions were for a routine you wrote 5 years ago. Imagine what it's like for someone that has no clue what you meant to do in the first place. Background While reading "Code Complete" (every developer, regardless of skill level, age, or programming language should own this book), I discovered a method used to comment your routines that provides so much more than just code comments. Using the Code This method is called PDL (Programming Design Language). The basic idea behind PDL is that you write all of the comments for your method before writing any code. Once the comments are finished, you then fill in the blanks with the implementation. Here is an example: Public Function CanUserBuyAlchohol(ByVal Age As Integer, ByVal HasLicense As Boolean) As Boolean      'If the user is of the legal drinking age          If Age > 21 Then          'If the user has a drivers license                  If HasLicense Then                  'Return success to the caller                          Return True                  'Otherwise the user does not have a drivers license                   Else                     'Return Failure to the caller                          Return False         End If       'Otherwise the user is too young          Else               'Return Failure to the caller                  Return False       End If  End Function     A few things to note here: All of the comments are formatted logically (indentation) When using this method, you write the comments first in a high level format (plain English) This allows you to design the routine at a high level of abstraction The requirements are in English so the routine is designed such that it can be ported to any language very easily All of the thinking work is done up front All that's left is to fill in the code under each comment The comments written in English explain exactly what you need, so implementation is a breeze Since comments are written first, you can be rest assured that all of your methods will be well documented If another developer is reading through your code, he can simply read your high level comments until he finds the code he needs. Points of Interest So as you can see, using PDL has several advantages: Assures code is always documented Allows for high level design of routine that does not rely on a specific programming language implementation (remember the comments are plain English) Once the comments are complete, coding is a snap because the logic has already been documented in plain English in the comments. I hope you find PDL as beneficial to learn as I have. Don't forget to buy Code Complete! Until next time.   kick it on DotNetKicks.com  


TDD using MSTest and Visual Studio 2010 Part one of two

Visual Studio 2010 and unit testing Unit testing has become a necessity in the world of software development.  Incorporating unit testing early and often into your build process can detect new bugs introduced into source code by recent changes from you or other developers.  This in turn will produce lower maintenance costs associated with your projects.   This article will explain MSTest, the integrated testing suite introduced in Visual Studio 2010.  I'll cover the core attributes that you use to mark the test methods in your test classes.  These attributes provide solutions to accomplish common testing tasks such as test setup and break down routines.   I'll also explain Test Driven Development or TDD which is a design methodology that when used properly can add great benefit to your software projects. Just to be clear, I will start by discussing what a unit test is and what it's not. A Unit Test IS An automated unit of code that will invoke methods and change property values on your classes under test then evaluate the state of your objects to see if your code performs as you expect. A unit of code that should be small in size. A unit of code that should be easy to write and maintain. A unit of code that should execute quickly. A unit of code that who's tests are handled by an automated testing framework. In this instance we are using MSTest inside of Visual Studio 2010 as our unit testing framework although there are other alternatives which I will list at the end of this article. A Unit Test IS NOT A test of the entire system by a QA technician. Found inside of your production source project. A piece of code that is dependent upon objects in which you have no control.  Some examples include; A Database system. A file system. A network resource. A third party library in which you don't own the source code. Test Driven Development Test driven development is a design methodology in which you write unit tests before implementing the code that is being tested.  I know, this seems strange, however, when implemented properly, TDD can greatly benefit the design of your code. How does it work? In this multipart series I will explain TDD and related concepts and then follow up with an example project that you can download. Chances are, you source code is probably contained in one or more class libraries (.DLL projects).  These libraries represent components which are made up of classes that define the data and logic of your application.   The idea behind TDD is to write tests that invoke the methods and properties that make up the interface or contract of your class.  The contract is made up of the public members of your classes. You are only testing how the objects are intended to be used by the outside world.  In this way, you are free to think about the design of your classes from a higher level of abstraction because you aren't concerned about the inner workings of your methods.  This concept of information hiding is known as encapsulation.  Once you've written a failing test, it's time to develop the code that implements the methods and properties tested so that you can successfully build the tests. The end goal is to have unit tests that pass.     Red, Green, Refactor! So you have a test project and a class library in a solution and they both build.  The test project should contain a reference to the class library that contains the code under test.  The test class should contain a method to test some functionality of your class.  The test method should be marked with the attribute [TestMethod] MSDN Documentation on [TestMethod] attribute .  At this point, we are aiming for a test that fails when you try to run it.  When your test fails, you will receive a red error indicator from the MSTest Visual Studio integration window.  This is the "Red" in Red, Green, Refactor.  Your next step is to implement the class' methods and properties until you can run the unit test and it passes.  This is the "Green" state.  The last step in the process is to refactor your newly written class.  The definition of refactoring from wikipedia is as follows.   Code refactoring is a "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior",[1] undertaken in order to improve some of the nonfunctional attributes of the software. Typically, this is done by applying a series of "refactorings", each of which is a (usually) tiny change in a computer program's source code that does not modify its functional requirements. Advantages include improved codereadability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility. An important thing to remember when refactoring code is that you don't change the way that the world interacts with your objects, or their interfaces.  Refactoring should be applied in small incremental changes to optimize the existing code found in your methods and helper routines.  With each iteration, be sure to run your unit tests to make sure you have not broken the functionality of your new class.   Some examples of refactorings are as follows;  Try to remove over complicated blocks of code like unnecessary nested if blocks.  Try to rename variables to better suite their values.  A key benefit to refactoring is your code should be easier to read. Once you've finished refactoring, simply start the process over.  Pick some functionality, write a test that fails, get the test to pass, then refactor the newly written code. Here are some TDD related links. MSDN Guidelines for Test-Driven Development http://msdn.microsoft.com/en-us/library/aa730844(v=vs.80).aspx TDD with Visual Studio 2010 http://channel9.msdn.com/Blogs/VisualStudio/Test-Driven-Development-with-Visual-Studio-2010 I hope I have provided you with a place to start with TDD and MSTest.  In part two of this article I plan to implement a full fledged example in c#.  Stay tuned.   kick it on DotNetKicks.com  


About the author

My name is Buddy James.  I'm a Microsoft Certified Solutions Developer from the Nashville, TN area.  I'm a Software Engineer, an author, a blogger (http://www.refactorthis.net), a mentor, a thought leader, a technologist, a data scientist, and a husband.  I enjoy working with design patterns, data mining, c#, WPF, Silverlight, WinRT, XAML, ASP.NET, python, CouchDB, RavenDB, Hadoop, Android(MonoDroid), iOS (MonoTouch), and Machine Learning. I love technology and I love to develop software, collect data, analyze the data, and learn from the data.  When I'm not coding,  I'm determined to make a difference in the world by using data and machine learning techniques. (follow me at @budbjames).  

Related links

Month List