Scott's Gu posted a chapter from the new MVC book on his blog, which I finished reading a few minutes ago. I was amazed by the backward progression of "modern" development tools and programming techniques. Scott Gu, Microsoft and the cheerleaders act as if this debacle known as Visual Studio was created outside the sweep of history, or that they cannot possibly glean wisdom from yesterday's technologies. Is Scott Gu and Microsoft really so bright, so brilliant, so ingenious, that they need not consult with the wisdom of prior development tools used in the 6.0 days? Yes, the old fashioned musty things - can be our salvation - if only Microsoft would install them and realize how productive these "legacy" technologies are in comparison to .NET. Instead of learning from experience thereby building on the "legacy" knowledge base in order to guide future development tools, Microsoft and Scott Gu in a clear lapse of thought insist on reinventing the wheel. Their exercise in stupidity comes at great cost to developer productivity.
If we could provide only Lotus 1-2-3, as the next revision to our complex business systems that our client possess - then merely instruct them how to manually enter data into cells and create formulas while cheerleading the control they have over their data and complex algorithms they "get" to happily create spinning the extra work as a benefit -while we know know full well in their ignorance we would receive payment along with praise in the process for introducing them to this "great new user definable flexible technology" would we? If we answer yes, then we can't necessarily blame Scott Gu, Soma and Microsoft for the current state of Visual Studio and .bloat as we became the ignorant end users.
Perhaps we should blame the people who offer praise for Microsoft, pathetically thanking them for providing "new" technology and development tools that mandates hand-coding a user interface - employing coding techniques predating FoxPro 2.0 - which on a productivity level equate closer to Mainframe COBOL. The cheerleaders as much as Soma, Scott Gu and Microsoft bear the responsibility for our current state of affairs. Have we grown so accustom to horrific software by Microsoft, that lack of Visual Designers, debuggers and nonsensical glue code we now find praise-worthy instead of appalling?
If we don't expend the energy and time to speak up, we can only blame ourselves, when Visual Studio 2012 forces us to use technologies that resemble assembler.
.Mark
Wednesday, March 11, 2009
Thursday, March 5, 2009
Source Code Doesn't Lie #4: UI Framework Layer
The source code challenge creating a UI framework layer
The Winner - Visual FoxPro
Score card through 4 coding challenges:
The Legacy Visual FoxPro 4
The Great Visual Studio 0
--------------------------------------------------------------------------------------
Let’s start with a brief overview of what N-TIER design entails.
An n-tier application is one where the application is split into logic sections. These sections are the user interface tier, the middle tier where the application business rule along with data access programming resides and the data tier (the database). While all the tiers may reside on one or two computers or servers this model allows the application to be “scaled” to improve performance. In other words the user interface may reside on the client’s workstation or in a browser, the middle tier could utilize its own application server and the data tier would have its own server.
There are numerous benefits to this programming model besides scalability, for example the same middle tier and database can be accessed by both a web based interface or a client application interface. This means all the middle tier code and the database is shared instead of writing the code twice. Moreover a framework can be implemented to further reduce programming by creating a baseline of generic programming (classes) which the application is based upon. By employing a framework in conjunction with N-TIER design patterns we are able to create an application that is scalable, easy to maintain and provides a consistent programming model for maintenance along with a consistent user interface.
The most common mistake a programmer (and Microsoft for that matter) makes when trying to implement this design pattern is to place code that really belongs in the middle tier in the user interface tier or to access the database directly from the user interface layer.
Now that we have a basic understanding of the N-TIER model let’s move to implementing the classes that would be required by the user interface layer for a Visual FoxPro application and a winform application. I must be in a good mood tonight as using Winforms will paint Visual Studio in the best light. Microsoft royally screwed this model up in WPF and a comparison with Visual FoxPro would not even be close in terms of code and ease of implementation. On a side note: Yes they failed with Webforms and MVC as well .
Are you ready to develop a framework UI layer at light speed with Visual Studio 2008 and .BLOAT?
The first step is subclass the native development controls into a UI framework class. To keep things simple we will subclass a form, label and textbox class. Let’s start with Visual FoxPro, this step requires zero coding we simply use the class browser. As you see in the screen shot we have a base UI framework layer that is ready to use in our application. This took less then a minute to build.
Now let’s perform the same task in Visual Studio. First off you can’t subclass UI controls in the class browser therefore we have to hand code each class. In order to save some code in Visual Studio - which I really freaking shouldn't - I will exclude the code necessary to workaround bugs that are related to setting default proprieties in the subclass that get jacked by the property sheet.
Now here is the Visual Studio Code that was NOT required in the legacy Visual FoxPro base framework layer.
//FOLKS: This is the Microsoft money section it forces your client to use the windows
//operating system. Steve and Bill count the dollar signs each time they see a
//USING system in your code.
using System;
using System.Text;
using System.Data;
using System.Drawing;
using System.Windows.Forms;
using System.ComponentModel;
using System.Collections.Generic;
namespace UILayer
{
//Since VS doesn't have a class browser that works
//or an ide with code windows we need regions to keep the code manageable
#region forms
//Why in the hell do I have to add an attribute to my class that
//tells the great Visual Studio what icon it needs to display in the toolbox for the class?
//
//The ide freaking knows it is inheriting from a textbox. It should display a default
//textbox icon then allow us to override it as needed.
//
//In VFP a property sheet could have been used and no coding would be necessary
[ToolboxBitmap(typeof(System.Windows.Forms.Form))]
public class SampleForm : Form
{
public SampleForm()
{
}
}
#endregion
//Blah, Blah Blah the same crap not exciting but it is code we should not have to write!
//All that should be required is us setting proprieties and the business logic.
// yes this is plumbing code!
#region textboxes
[ToolboxBitmap(typeof(System.Windows.Forms.TextBox))]
public class SampleTextBox : TextBox
{
public SampleTextBox()
{
}
}
#endregion
#region labels
[ToolboxBitmap(typeof(System.Windows.Forms.Label))]
public class SampleLabel : Label
{
public SampleLabel()
{
}
}
#endregion
}
It is obvious FoxPro requires less work as the more we keep adding to this model the worse things get for Visual Studio. Adding methods, proprieties and inheritance are all done in the class browser visually with the legacy FoxPro and using the Microsoft's Latest Technology Visual Studio 2008 with 70k class of bloat in .NET this it is all done in code.
If this nonsense was not bad enough; let's say for example you decide to use the wizards in Visual Studio instead of using subclasses, guess what happens? (Don't think this wizard code is not used in the field I see it all the time in applications). Anyway back to my point guess what occurs, I will tell you, a WTF MOMENT occurs - that is what. The visual studio wizards embeds data access code into the user interface layer, not only do we lose the value of inheritance and have duplicate code everywhere, the foundation of N-TIER design is broken by code generated by Microsoft!
Even the Visual Studio Cheerleaders will try to spin this extra work as a positive, below is an excerpt from code magazine…
“...Subclassing the base .NET Windows Forms controls is different from VFP because developers must write code to do so. You cannot subclass visually, but the process will provide good exposure to the language and the .NET Framework.”
What the hell are they talking about, they can't think we are that stupid - Let's read it again -
“...Subclassing the base .NET Windows Forms controls is different from VFP [hell yeah it is it is alot more freaking work in Visual Studio] because developers must write code to do so [which in any worthwhile tool we shouldn't have to]. You cannot subclass visually, [no shit thanks for pointing out the obvious, they should have mentioned due to the fact the visual studio class browser sucks] but the process will provide good exposure to the language and the .NET Framework.”
Yes I read it correctly, they wrote "this process will provide good exposure to the language and the .NET framework" - are they freaking joking me?!?!? Here is what I have to say to the code magazine Visual Studio cheerleaders “SCREW THAT”. This is a major bug in Visual Studio call it exactly what the F&$K it is!
I hate to do this I really do, but we have to dig deeper into this idea of "providing good exposure to the language and the .NET framework".
First off I need to ask this, how many freaking times during the application development process do we need to WASTE time getting "good exposure to the language and the .NET framework". WTF - With all the code we have to write in Visual Studio do they think we are going to forget? There is less typing involved in a Mavis Beacon teaches typing dvd. This is a perfect example of what I have been saying all along folks, cheerleaders will do or say anything to hide the truth of Visual Studio.
Secondarily please stop calling .NET a framework. .NET is NOT a framework. For the most part Microsoft took the Windows API layer and wrapped it in classes - that is all the majority of .NET is. Moreover a portion of .NET is based on outdated legacy technology that has been around since early version of windows, yes before Visual FoxPro. There are basic principles of framework design: I will pick 2 general ones everyone can understand, a framework should eliminate code redundancy and a framework should provide a consistent way of coding. How in the world do we have a consistency in .NET when there is class redundancy everywhere, for example we have 6 bad ways of accessing data alone, that is not eliminating redundancy that is BLOAT! If .NET fails the first two general tests required to be considered a framework then it is not a framework!
Getting back to their quote "good exposure to the language and the .NET framework", If we apply their logic for minute to a car, would anyone want to push a freaking car instead of drive one because the car maker failed to design the engine correctly? Your answer would be NO - but a cheerleader would say that is fine because it would provide good exposure to fresh air. Yes, this is as freaking unbelievable as it sounds, and that is the idea they are trying to sell us on.
The bottom line is Visual Studio is so bad and unproductive it can not be defended using rational arguments so cheerleaders invent crap like "exposure to the language". The pathetic part is, believe or not, these people (and I purposely left out their name) are good programmers, why they insult their intelligence time and time again for Microsoft and Visual Studio is mind boggling? Here is a thought, they want to help the Visual Studio community, then in their next issue of code magazine demand Microsoft give us tools so we can get our work done in the most productive way possible, freaking get some balls and point out the bugs. Look, if you don't have the balls to speak the truth for fear of biting the hand that feeds you, just direct your readers to my website and I'll do it.
I will break down what I think transpired, Microsoft was smart when they issued the end of life of Visual Basic and Visual FoxPro in this respect. Before Microsoft killed these solid products Microsoft grabbed the more respected cheerleaders in each community and promised them 75 virgins besides Vista Ultimate to spin Visual Studio. Microsoft was betting that the Visual Basic and FoxPro development community would blindly take the advise of community leaders and just follow along. (Well it wasn't the virgins, actually most got offered jobs in Redmond then disappeared into the woodworks-I should find Griver's letter to the VFP community on the end of life and analyze that to prove my point) . Then with the Visual Studio community, Microsoft didn't want non-microsoft employees leading the development community so they created the Microsoft Evangelist network, these are the A-team cheerleaders that spin visual studio. You know what, sadly for us, this plan worked perfectly. Developers are listening to the cheerleadering squads, which is exactly why we are stuck with this crappy bloated bullshit platform to write applications with. I have said it all along Microsoft may not release the best software (With Vista and Visual Studio I'm being nice) but they are smart when it comes to business.
Ok I will get off my soap box, well there you have it another code challenge and Visual Studio lost again to Visual FoxPro. It is time to move off the class browser, inheritance and User Interface Layer for the time being as the Visual Studio suck factor is obvious. In the next installment of source code doesn't lie I will put LINQ-TO-SQL up against VFP'S native data centric language. Perhaps we can develop at light speed when creating middle tier components that perform basic business processing.
By the way if you haven't checked out the Ms. Fox Pro (Ms. means female not Microsoft) video, do so, it is posted on my blog and also my facebook page.
Until next time, be productive Developing at Bloat Speed!
.Mark
The Winner - Visual FoxPro
Score card through 4 coding challenges:
The Legacy Visual FoxPro 4
The Great Visual Studio 0
--------------------------------------------------------------------------------------
Let’s start with a brief overview of what N-TIER design entails.
An n-tier application is one where the application is split into logic sections. These sections are the user interface tier, the middle tier where the application business rule along with data access programming resides and the data tier (the database). While all the tiers may reside on one or two computers or servers this model allows the application to be “scaled” to improve performance. In other words the user interface may reside on the client’s workstation or in a browser, the middle tier could utilize its own application server and the data tier would have its own server.
There are numerous benefits to this programming model besides scalability, for example the same middle tier and database can be accessed by both a web based interface or a client application interface. This means all the middle tier code and the database is shared instead of writing the code twice. Moreover a framework can be implemented to further reduce programming by creating a baseline of generic programming (classes) which the application is based upon. By employing a framework in conjunction with N-TIER design patterns we are able to create an application that is scalable, easy to maintain and provides a consistent programming model for maintenance along with a consistent user interface.
The most common mistake a programmer (and Microsoft for that matter) makes when trying to implement this design pattern is to place code that really belongs in the middle tier in the user interface tier or to access the database directly from the user interface layer.
Now that we have a basic understanding of the N-TIER model let’s move to implementing the classes that would be required by the user interface layer for a Visual FoxPro application and a winform application. I must be in a good mood tonight as using Winforms will paint Visual Studio in the best light. Microsoft royally screwed this model up in WPF and a comparison with Visual FoxPro would not even be close in terms of code and ease of implementation. On a side note: Yes they failed with Webforms and MVC as well .
Are you ready to develop a framework UI layer at light speed with Visual Studio 2008 and .BLOAT?
The first step is subclass the native development controls into a UI framework class. To keep things simple we will subclass a form, label and textbox class. Let’s start with Visual FoxPro, this step requires zero coding we simply use the class browser. As you see in the screen shot we have a base UI framework layer that is ready to use in our application. This took less then a minute to build.
Now let’s perform the same task in Visual Studio. First off you can’t subclass UI controls in the class browser therefore we have to hand code each class. In order to save some code in Visual Studio - which I really freaking shouldn't - I will exclude the code necessary to workaround bugs that are related to setting default proprieties in the subclass that get jacked by the property sheet.
Now here is the Visual Studio Code that was NOT required in the legacy Visual FoxPro base framework layer.
//FOLKS: This is the Microsoft money section it forces your client to use the windows
//operating system. Steve and Bill count the dollar signs each time they see a
//USING system in your code.
using System;
using System.Text;
using System.Data;
using System.Drawing;
using System.Windows.Forms;
using System.ComponentModel;
using System.Collections.Generic;
namespace UILayer
{
//Since VS doesn't have a class browser that works
//or an ide with code windows we need regions to keep the code manageable
#region forms
//Why in the hell do I have to add an attribute to my class that
//tells the great Visual Studio what icon it needs to display in the toolbox for the class?
//
//The ide freaking knows it is inheriting from a textbox. It should display a default
//textbox icon then allow us to override it as needed.
//
//In VFP a property sheet could have been used and no coding would be necessary
[ToolboxBitmap(typeof(System.Windows.Forms.Form))]
public class SampleForm : Form
{
public SampleForm()
{
}
}
#endregion
//Blah, Blah Blah the same crap not exciting but it is code we should not have to write!
//All that should be required is us setting proprieties and the business logic.
// yes this is plumbing code!
#region textboxes
[ToolboxBitmap(typeof(System.Windows.Forms.TextBox))]
public class SampleTextBox : TextBox
{
public SampleTextBox()
{
}
}
#endregion
#region labels
[ToolboxBitmap(typeof(System.Windows.Forms.Label))]
public class SampleLabel : Label
{
public SampleLabel()
{
}
}
#endregion
}
It is obvious FoxPro requires less work as the more we keep adding to this model the worse things get for Visual Studio. Adding methods, proprieties and inheritance are all done in the class browser visually with the legacy FoxPro and using the Microsoft's Latest Technology Visual Studio 2008 with 70k class of bloat in .NET this it is all done in code.
If this nonsense was not bad enough; let's say for example you decide to use the wizards in Visual Studio instead of using subclasses, guess what happens? (Don't think this wizard code is not used in the field I see it all the time in applications). Anyway back to my point guess what occurs, I will tell you, a WTF MOMENT occurs - that is what. The visual studio wizards embeds data access code into the user interface layer, not only do we lose the value of inheritance and have duplicate code everywhere, the foundation of N-TIER design is broken by code generated by Microsoft!
Even the Visual Studio Cheerleaders will try to spin this extra work as a positive, below is an excerpt from code magazine…
“...Subclassing the base .NET Windows Forms controls is different from VFP because developers must write code to do so. You cannot subclass visually, but the process will provide good exposure to the language and the .NET Framework.”
What the hell are they talking about, they can't think we are that stupid - Let's read it again -
“...Subclassing the base .NET Windows Forms controls is different from VFP [hell yeah it is it is alot more freaking work in Visual Studio] because developers must write code to do so [which in any worthwhile tool we shouldn't have to]. You cannot subclass visually, [no shit thanks for pointing out the obvious, they should have mentioned due to the fact the visual studio class browser sucks] but the process will provide good exposure to the language and the .NET Framework.”
Yes I read it correctly, they wrote "this process will provide good exposure to the language and the .NET framework" - are they freaking joking me?!?!? Here is what I have to say to the code magazine Visual Studio cheerleaders “SCREW THAT”. This is a major bug in Visual Studio call it exactly what the F&$K it is!
I hate to do this I really do, but we have to dig deeper into this idea of "providing good exposure to the language and the .NET framework".
First off I need to ask this, how many freaking times during the application development process do we need to WASTE time getting "good exposure to the language and the .NET framework". WTF - With all the code we have to write in Visual Studio do they think we are going to forget? There is less typing involved in a Mavis Beacon teaches typing dvd. This is a perfect example of what I have been saying all along folks, cheerleaders will do or say anything to hide the truth of Visual Studio.
Secondarily please stop calling .NET a framework. .NET is NOT a framework. For the most part Microsoft took the Windows API layer and wrapped it in classes - that is all the majority of .NET is. Moreover a portion of .NET is based on outdated legacy technology that has been around since early version of windows, yes before Visual FoxPro. There are basic principles of framework design: I will pick 2 general ones everyone can understand, a framework should eliminate code redundancy and a framework should provide a consistent way of coding. How in the world do we have a consistency in .NET when there is class redundancy everywhere, for example we have 6 bad ways of accessing data alone, that is not eliminating redundancy that is BLOAT! If .NET fails the first two general tests required to be considered a framework then it is not a framework!
Getting back to their quote "good exposure to the language and the .NET framework", If we apply their logic for minute to a car, would anyone want to push a freaking car instead of drive one because the car maker failed to design the engine correctly? Your answer would be NO - but a cheerleader would say that is fine because it would provide good exposure to fresh air. Yes, this is as freaking unbelievable as it sounds, and that is the idea they are trying to sell us on.
The bottom line is Visual Studio is so bad and unproductive it can not be defended using rational arguments so cheerleaders invent crap like "exposure to the language". The pathetic part is, believe or not, these people (and I purposely left out their name) are good programmers, why they insult their intelligence time and time again for Microsoft and Visual Studio is mind boggling? Here is a thought, they want to help the Visual Studio community, then in their next issue of code magazine demand Microsoft give us tools so we can get our work done in the most productive way possible, freaking get some balls and point out the bugs. Look, if you don't have the balls to speak the truth for fear of biting the hand that feeds you, just direct your readers to my website and I'll do it.
I will break down what I think transpired, Microsoft was smart when they issued the end of life of Visual Basic and Visual FoxPro in this respect. Before Microsoft killed these solid products Microsoft grabbed the more respected cheerleaders in each community and promised them 75 virgins besides Vista Ultimate to spin Visual Studio. Microsoft was betting that the Visual Basic and FoxPro development community would blindly take the advise of community leaders and just follow along. (Well it wasn't the virgins, actually most got offered jobs in Redmond then disappeared into the woodworks-I should find Griver's letter to the VFP community on the end of life and analyze that to prove my point) . Then with the Visual Studio community, Microsoft didn't want non-microsoft employees leading the development community so they created the Microsoft Evangelist network, these are the A-team cheerleaders that spin visual studio. You know what, sadly for us, this plan worked perfectly. Developers are listening to the cheerleadering squads, which is exactly why we are stuck with this crappy bloated bullshit platform to write applications with. I have said it all along Microsoft may not release the best software (With Vista and Visual Studio I'm being nice) but they are smart when it comes to business.
Ok I will get off my soap box, well there you have it another code challenge and Visual Studio lost again to Visual FoxPro. It is time to move off the class browser, inheritance and User Interface Layer for the time being as the Visual Studio suck factor is obvious. In the next installment of source code doesn't lie I will put LINQ-TO-SQL up against VFP'S native data centric language. Perhaps we can develop at light speed when creating middle tier components that perform basic business processing.
By the way if you haven't checked out the Ms. Fox Pro (Ms. means female not Microsoft) video, do so, it is posted on my blog and also my facebook page.
Until next time, be productive Developing at Bloat Speed!
.Mark
Sunday, March 1, 2009
Weekend Update: Dot Net Chick VS Ms. Fox Pro
I was thinking today, what if Apple bought FoxPro instead of Microsoft? Given there was a FoxPro for Mac version it might have been possible. I'm sure Apple would develop a "simple" way to port my code over to the iPhone without a complete rewrite. My application would also run in any OS instead of being "used as bait" to feed the Microsoft monopoly by locking my clients to Windows through .BLOAT, you know the OS api wrappers Microsoft and the cheerleaders spin as the .NET framework.
More importantly, if Apple would have bought FoxPro just think what great commericals Apple would have made to actually market FoxPro something Microsoft failed to do. Wouldn't it be cool if Apple would have followed a similar Mac vs PC format. Instead of the PC and Mac guy we had the DOT NET chick vs Ms. Fox Pro, like in the video below, I wonder which one you would perfer to take you where you want to go today?
Definately check it out!
Like everything there would be some downsides to Apple owning FoxPro, I would have to find some hobbies to occupy my free time. You know the time that I now waste writing tedious nonsensical Visual Studio "plumbing and glue code" that wasn't required in legacy technology, and working around bugs in LINQ for example when used in the middle tier
Unforunately, I snapped back to reality only to look down at the Visual Studio IDE and thought life can be a real bitch sometime!
In closing, later this week I will be releasing my next installment of Source Code Doesn't Lie: The User Interface Layer. You want to be sure to check it out!
Until then have fun and "Develop at Bloat Speed!"
.Mark
More importantly, if Apple would have bought FoxPro just think what great commericals Apple would have made to actually market FoxPro something Microsoft failed to do. Wouldn't it be cool if Apple would have followed a similar Mac vs PC format. Instead of the PC and Mac guy we had the DOT NET chick vs Ms. Fox Pro, like in the video below, I wonder which one you would perfer to take you where you want to go today?
Definately check it out!
Like everything there would be some downsides to Apple owning FoxPro, I would have to find some hobbies to occupy my free time. You know the time that I now waste writing tedious nonsensical Visual Studio "plumbing and glue code" that wasn't required in legacy technology, and working around bugs in LINQ for example when used in the middle tier
Unforunately, I snapped back to reality only to look down at the Visual Studio IDE and thought life can be a real bitch sometime!
In closing, later this week I will be releasing my next installment of Source Code Doesn't Lie: The User Interface Layer. You want to be sure to check it out!
Until then have fun and "Develop at Bloat Speed!"
.Mark
Subscribe to:
Posts (Atom)
