This Wednesday, the Austin Agile user group is meeting during lunch at the Mongolian BBQ on N. Lamar. Check out the website for details: http://groups.yahoo.com/group/agileatx/
Monthly Archives: April 2005
Vote for Birds of a Feather sessions for Tech Ed. – level 000
If you haven’t already voted for BoF sessions, go there! http://www.msteched.com/cfp/bofvoting.aspx
I submitted the following:
Agile Methodologies With
.Net
I have to look hard to find fellow developers using Agile
methodologies with .Net projects in my area. Wouldn’t it be great to talk about
how others are using Agile? Also, the next version of MSF will have an Agile
track, and this would be an excellent forum for discussion.
Intended
Audience: Developer
Submitted By: Jeffrey Palermo, Dell, Inc.
methodologies with .Net projects in my area. Wouldn’t it be great to talk about
how others are using Agile? Also, the next version of MSF will have an Agile
track, and this would be an excellent forum for discussion.
Intended
Audience: Developer
Submitted By: Jeffrey Palermo, Dell, Inc.
Step by Step: Create java package and import to use with C# – level 300
Yesterday I explained
that I was able to import java .jar packages for use with .Net. Here’s the
steps.
First, here is my sample Java class. (Don’t put this in VS.Net, compile this
with the java compiler):
1 package
ClassLibraryInteropTest;
2
3 public class Calculator
4 {
5
public int
Add(int first, int second)
6 {
7 return
first + second;
8 }
9
10
public int
Subtract(int first, int second)
11 {
12 return
first – second;
13 }
14
15
public int
Multiply(int first, int second)
16 {
17 return
first * second;
18 }
19
20
public float
Divide(int first, int second)
21 {
22 return
first / second;
23 }
24 }
ClassLibraryInteropTest;
2
3 public class Calculator
4 {
5
public int
Add(int first, int second)
6 {
7 return
first + second;
8 }
9
10
public int
Subtract(int first, int second)
11 {
12 return
first – second;
13 }
14
15
public int
Multiply(int first, int second)
16 {
17 return
first * second;
18 }
19
20
public float
Divide(int first, int second)
21 {
22 return
first / second;
23 }
24 }
This is just a sample calculator that I will leverage at the end with my C#
code. I’ll need to compile this, so I’ll run:
javac Calculator.java
This will create a Calculator.class file. Next I’ll package that class into
a .jar file:
jar cvf Calculator.jar *.class
This will take all the class files in the directory and put them in
Calculator.jar. I only have one class, so I’m good to go. Now, I’ll run JBImp,
with is a .Net utility, to convert the .jar’s Java bytecode to MSIL:
jbimp /t:library Calculator.jar
And you’ll see the following output:
Microsoft (R) Java-language bytecode to MSIL
converter version 1.1.4322.0
for Microsoft (R) .NET Framework version
1.1.4322
Copyright (C) Microsoft Corp 2000-2002. All rights
reserved.
Created
ClassLibraryInteropTest.Calculator.dll
Now I have my .Net assembly named ClassLibraryInteropTest.Calculator.dll.
Note that the utility used the package name (defined internally) to prefix the
assembly name.
Next, create a .Net project to use as a test harness, and add a reference to
this newly created .dll file. Once you have referenced it, you’ll be able to
use the following C# code:
1 using
System;
2
3 namespace
JavaInterop
4 {
5 class
Tester
6 {
7 [STAThread]
8 static
void Main(string[] args)
9 {
10 ClassLibraryInteropTest.Calculator
myCalc = new
ClassLibraryInteropTest.Calculator();
11 Console.WriteLine(myCalc.Add(23,
7).ToString());
12
Console.ReadLine();
13 }
14 }
15 }
System;
2
3 namespace
JavaInterop
4 {
5 class
Tester
6 {
7 [STAThread]
8 static
void Main(string[] args)
9 {
10 ClassLibraryInteropTest.Calculator
myCalc = new
ClassLibraryInteropTest.Calculator();
11 Console.WriteLine(myCalc.Add(23,
7).ToString());
12
Console.ReadLine();
13 }
14 }
15 }
If you get an error running this code (cannot find assembly Calculator),
rename the assembly: ClassLibraryInteropTest.Calculator.dll to Calculator.dll.
You get full intellisense about all the methods of the Calculator class, and
essentially, you treat it exactly the same as .Net code because the JBImp
utility actually makes it a .Net assembly.
Import existing Java .jar files to .Net .dll files for use with any .Net project – level 400
If you have existing .jar files from a Java application, and you need to use
that existing business logic or rewrite it, wouldn’t it be nice if you could
just leverage the existing package?
You can with the JBImp utility.
I recently had to do this, and it was a breeze. I ran the utility on my .jar,
and out came a managed .dll that I subsequently referenced and used in my .Net
app.
According to the documentation,
the utility actually converts the Java IL to MSIL at the bytecode level. It
sure did make the reuse picture a lot prettier.
Coding IS design – level 200
I’ve had extensive conversations with people about the phases of
development. Some say the “construction” phase of a software product is
coding. I contend that construction is actually compiling and deploying and
that everything before that is design that gets more specific with code being
the language of specific component design, and the code spells out exacting
specifications so that the compiler can appropriately construct the software
product.
So many managers in the industry have tried to reduce coding to construction
where they seek programmers who will work for what seems like hourly wages to
just “construct” the product as set forth by the designer or architect. Maybe
sometime in the future, it may be like that, but it could only happen if the
software designers designed it completely. In other words, the architects would
need a language far more specific than UML to design every detail of the
software.
Up to this point, the only way to design the software down to the last detail
is through code. No design or modeling language currently can come close to
designing lower-level details. It requires code to accomplish this, and the
coders should be just as skilled as the designers or they will have a hard time
implementing the holes in the high-level design. Diagrams are great, but if the
coders are not highly skilled, the implementation of the code won’t fulfill the
spirit of the design and will soon become an unmaintainable mess if it even
works in the first version.
From personal observation, I don’t see this situation being rectified.
Business managers continually come up with root cause analysis as to why it went
wrong. They will never _discover_ that the problem is they refuse to pay what
it takes to get _good_ coders to make their software, so in the end, the company
will pay more every 5 years or so to completely replace the application that has
become unmaintainable. The managers responsible for this waste are shielded
from accountability, of course, because of frequent corporate reorganizations.
The first version of the software gets the job done, and the pretty UI shields
observers from the true state of the code beneath. The design diagrams look
good in a project managers portfolio even though the software doesn’t look
anything like them. By the time the software because unmanageable, and a
project takes off to replace the old application and “do it right this time”,
several managers have come and gone, and “no one is to blame”. The new manager
will make a Version 1 application in the same fashion, get promoted, and several
managers down the line will repeat the same series of events.
The above is my observations from talking with others at other companies. My
company does a better job at this (thank God), but I hear of so many other
companies where people forget the mistakes of the past and repeat them all over
again. We, as an industry, have a lot of maturing to do.
Patterns: Provider vs. Plugin vs. Strategy – level 300
Previously I
made an implementation and called it the Provider pattern. After some good
discussion, I must redefine what I implemented. I implemented something that
had major traits of Provider, Plugin, and Strategy. I implemented a Repository
class that used a configuration service to get the assembly and type of the
class to load. This class loads the appropriate type that implements my
interface. My implementation implements every element of Provider except that
instead of an abstract base class for contract, I use an interface. That breaks
the definition. Strategy is defined as using interfaces, but in my
implementation uses a configuration item to dynamically load the concrete
implementation via reflection, so I’ve added something not explicitly not
defined in the pattern.
I have a feeling that our vocabulary is getting a bit muddled because we now
have pattern names from different sources, and they overlap quite a bit. I
don’t feel that I can use a pattern name: I have to define it first so that
fellow developers know what I really mean.
Perhaps as our industry matures more, a common vocabulary will truly
emerge.
Get to Tech Ed early for a Pre-conference Pre-PARTY – level FUN
Tech
Ed starts on June 6th with the Pre-conference labs being on
June 5th. June 4th is the Saturday before _anything_ starts.
On Saturday, June 4th, I’ll be hosting a Pre-Pre-Conference PARTY!
Plan on getting to Orlando one day early (after all, it’s the weekend) to attend
the “Tech Ed Kick-Off Bash“! I’ll be releasing more details in the following
weeks and finalizing information in late May. Watch my blog for details. This
will be a lot of fun and will have something for everyone.
Time to select those sessions for Tech Ed. and vote on Birds of a Feather sessions – level 000
If you are registered for Tech Ed, you will receive in an email a link to
pick your sessions. Each is identified as a track. I ended up with a mix
between the following tracks: Developer, Architect, and Web. My selections did
include quite a bit of WinForms smart client, and I tended to shy away from the
topics I could learn by reading a few good articles.
Vote on Birds of a Feather sessions here.
The following session is a _must attend_.
Test-Driven Development is
Design!With the new testing tools available in Visual
Studio 2005, Microsoft is enabling an ever greater potential for the adoption of
Test-Driven Development. The upwelling of recent test tool adopters that comes
with Visual Studio 2005 has also created a great deal of ambiguity around
Test-Driven Development for Microsoft developers. Test-Driven Development is a
micro-iterative process whose primary aim is software design – specifically
loosely-coupled designs. As the saying goes, “Tests are just a side effect.”
This session is specifically geared to creating a clear understanding of
Test-Driven Development for Microsoft developers in the ramp up to Visual Studio
2005.
Intended Audience: Developer
Submitted By: Scott Bellware,
Bellware.NET
Provider pattern: Abstract class or Interface? – level 300
In Rob Howard’s article, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp02182004.asp,
he describes the “Provider” pattern as coined by Microsoft. I like the pattern,
and it seems similar to the Strategy pattern as put forth GoF.
I love the benefits: the ability to control what provider is used by a
configuration item. Microsoft seems to have coined the term “Provider”, so I
guess it’s their definition, but at the lowest level it is an abstract class
that defines the contract, or API. Then a configuration item controls which of
the abstract class’s implementation in invoked. For example, I could have a
class that needs data. I think we can all imagine different classes that allow
access to different data sources. All the different data sources would have a
class that inherited from the abstract provider class. My client class would
get the configuration item that contained the assembly and type of the provider
implementation and instantiate it through reflection. The reference would be of
the abstract base class, so no matter which provider is configured, The client
will instantiate the appropriate one at runtime and access it through the
methods defined in the abstract class.
Personally, I would choose an interface first. I know they are immutable,
but is that an issue? Using an abstract class eliminates the possibility of
having a base class for the provider elsewhere, so it seems to me that this is
an unnecessary constraint. If the contract of the base class needs to provider
base functionality, then an abstract class makes sense, but as long as it is
just an API contract, I would favor an interface.
I feel that the “Provider” pattern should specify the general concept and not
specify inheritance vs. interface. I would consider either to be the Provider
pattern depending on the application of the pattern.
Architecture prototype revised and tested – level 400
Here, I’m following up on my previous
post about making a prototype of the architecture diagram presented.
Please download my revised VS.Net solution
here.
I’ve decided not to repost much of the code because of the amount, but I made
some pretty significant changes. In line with Scott Bellware’s suggestions,
I’ve added more granularity to the View interface so that the view never
actually holds a reference to the business object. The control’s to display
information are exposed as properties (actually, the textbox.Text property is
exposed as a property of the interface), so the presenter can actually change UI
elements through the inderection these properties provide. I defined two events
on the interface as well to denote when the LookUp event first and Persist. My
Presenter doesn’t care about a button click, so when the View experiences a
button click that actually means “LookUp”, it fires the LookUp event, which the
Presenter is listening for.
I will include one bit of code, and that is the IView interface
implementation in my WinForms code-behind class:
72 private void button2_Click(object sender, System.EventArgs e) {
73 if(LookUp
!= null) LookUp(sender, e);
74 }
75
76 private void button1_Click(object sender, System.EventArgs e) {
77 if(Persist
!= null) Persist(sender, e);
78 }
79
80 // Below are
interface members
81 public event
System.EventHandler LookUp;
82
83 public event System.EventHandler Persist;
84
85 public
Presenter.ContactPresenter Presenter {
86 get {
return _presenter; }
87 set {
_presenter = value; }
88 }
89
90 public string ContactPhoneNumber {
91 get {
return txtPhoneNumber.Text; }
92 set {
txtPhoneNumber.Text = value; }
93 }
94
95 public string ContactName {
96 get {
return txtName.Text; }
97 set {
txtName.Text = value; }
98 }
99
100 public int ContactAge {
101 get {
return int.Parse(txtAge.Text); }
102 set {
txtAge.Text = value.ToString(); }
103 }
104
105 public string ContactUserName {
106 get {
return txtUserName.Text; }
107 set {
txtUserName.Text = value; }
108 }
109
110 public string UserNameToLookUp {
111 get {
return ddlUserName.SelectedItem.ToString();
}
112 }
113
114 private void Form1_Load(object sender, EventArgs e) {
115 if(_presenter == null) _presenter = new Presenter.ContactPresenter(this);
116 }
73 if(LookUp
!= null) LookUp(sender, e);
74 }
75
76 private void button1_Click(object sender, System.EventArgs e) {
77 if(Persist
!= null) Persist(sender, e);
78 }
79
80 // Below are
interface members
81 public event
System.EventHandler LookUp;
82
83 public event System.EventHandler Persist;
84
85 public
Presenter.ContactPresenter Presenter {
86 get {
return _presenter; }
87 set {
_presenter = value; }
88 }
89
90 public string ContactPhoneNumber {
91 get {
return txtPhoneNumber.Text; }
92 set {
txtPhoneNumber.Text = value; }
93 }
94
95 public string ContactName {
96 get {
return txtName.Text; }
97 set {
txtName.Text = value; }
98 }
99
100 public int ContactAge {
101 get {
return int.Parse(txtAge.Text); }
102 set {
txtAge.Text = value.ToString(); }
103 }
104
105 public string ContactUserName {
106 get {
return txtUserName.Text; }
107 set {
txtUserName.Text = value; }
108 }
109
110 public string UserNameToLookUp {
111 get {
return ddlUserName.SelectedItem.ToString();
}
112 }
113
114 private void Form1_Load(object sender, EventArgs e) {
115 if(_presenter == null) _presenter = new Presenter.ContactPresenter(this);
116 }
The above is a snippet from the form code. Notice how the interface
properties are mapped to the appropriate text box, and the button click handlers
just invoke the events defined by the interface. Now it would be very trivial
to snap a different UI on to the same Presenter.
I used NUnit to hook up unit tests to the entire thing to prove that this
layout was fully testable. Each component at every layer has been tested in
isolation. The interfaces make it easy to make stubs, but interfaces were
mainly used for loose-coupling. I’m tightly coupled where concrete classes are
referenced, but that’s fine. I think that loose-coupling should server a
purpose, so it may not be appropriate everywhere. For instance, my Presenter is
tightly coupled with the Repository object. I can still test my Presenter is
isolation because I have a property in my Presenter to hold a reference to the
Repository. In my test, I inherit from the Repository, override the members,
and set the Presenter’s property to my stub object. This isolates Presenter.
I was a bit surprised at how simple my tests ended up being because each
class served a specific purpose, so it was easy to test for that purpose. As
long as my Presenter could call the Repository, it was working. As long as the
Repository could get a Contact back from the ContactData object, it was
working. Only my unit test for MyContactData actually tested that the data was
correct because the object was being created at this point.
Another point of interest is the amount of private methods in my solution.
My two event handlers in the Presenter are private, and that is it. Everything
else is a publicly exposed piece of a concrete class that serves a distinct
purpose.
Download my code and give it a look. I’m open for criticism. Maybe with a
little collaboration, we can, as a community, make architecture recommendations
and provide a community-supported prototype of a single feature demonstrates the
use of good practices. The more feedback the better.