Infragistics JQuery controls

Why Learn Assembly Language?

Here is my post from http://www.codeproject.com/Articles/89460/Why-Learn-Assembly-Language "Assembly language? Isn't that the hard to read instructions on how to assemble your brand new computer desk?"... No.. What is Assembly Language? x86 Assembly is a programming language for the x86 class of processors (specifically the 32bit x86 processors IA-32 - http://en.wikipedia.org/wiki/IA-32). The instruction set defined by the IA-32 architecture is targeted towards the family of microprocessors installed in the vast majority of personal computers on the planet. Assemblylanguage is machine specific and considered a "low level" language. This means that the code and syntax is much closer to the computer's processor, memory, and I/O system. A high level language is designed with keywords, libraries, and a syntax that introduces a high level of abstraction between the language and the hardware. Background I thought assembly was a dead language, why waste the time? Though it's true, you probably won't find yourself writing your next customer's app in assembly, there is still much to gain from learning assembly. Today, assembly language is used primarily for direct hardware manipulation, access to specialized processor instructions, or to address critical performance issues. Typical uses are device drivers, low-level embedded systems, and real-time systems (EDIT:Thanks Trollslayer). The fact of the matter is, the more complex high level languages become, and the more ADT (abstract data types) that are written, the more overhead is incurred to support these options. In the instances of .NET, perhaps bloated MSIL. Imagine if you knew MSIL. This is where assembly language shines. (EDIT)Assembly language is as close to the processor as you can get as a programmer so a well designed algorithm is blazing -- assembly is great for speed optimization. It's all about performance and efficiency. Assembly language gives you complete control over the system's resources. Much like an assembly line, you write code to push single values into registers, deal with memory addresses directly to retrieve values or pointers. To write in assembly is to understand exactly how the processor and memory work together to "make things happen". Be warned, assembly language is cryptic, and the applications source code size is much much larger than that of a high-level language. But make no mistake about it, if you are willing to put in the time and the effort to master assembly, you will get better, and you will become a stand out in the field. So why should you care?     Points of Interest Wirth's Law I remember dialling into a BBS on my 486 with my brand new 2400bps modem. Fast-forward 14 years and now we are only limited by our imagination. With all of these amazing technological breakthroughs, there is a glaring anomaly; a paradox. This is referred to as Wirth's law. Wirth's law states that software is getting slower more rapidly than hardware becomes faster. There's no one reason why this is the case, but I'd like to think that the further we as developers drift away from the lower level details of software development, we write less than stellar (inefficient code). Hold the phone! I'm not calling anyone stupid. It's just that these new languages and supercharged processors have abstracted us so far from the machine, that we no longer have to be concerned with things like garbage collection, variable initialization, memory address pointers, etc. All of these features and more are now standard in today's languages/runtimes/IDEs. The result is a new breed of developers that rely on superior hardware power for performance rather than striving to write concise, cohesive, efficient code. My Eyes are Open! I realize now that learning assembly language will teach me about the inner workings of the computer. I'll learnhow the CPU/CPU registers work with memory addresses to achieve the end result one instruction at a time. This doesn't mean that I'm going to begin coding everything in assembly, however, I will learn which data types to use and when. I'll learn how to write smaller, faster, more efficient routines. I will understand software development at a level that most of my peers don't. I'm even opening up to the possibility of looking into writing my own compiler. So if you are serious about getting a leg up on the competition in your field, I'd recommend trying to learnassembly language. Resources on Learning Assembly How To Use Debug - http://www.codeproject.com/KB/miscctrl/Debug.aspx Introduction to x86 Assembly Language http://www.c-jump.com/CIS77/ASM/Assembly/lecture.html 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