I will branch away from my previous post for a quick issue I ran into. I was working with the simpleframework xml packages on a new project. During the deserializing of a response message in xml I ran across an issue which the exception was unclear about. The exception was
Caused by: org.simpleframework.xml.core.Element Exception: Unable to determine type for @org.simpleframework.xml.ElementList
At first glance the error looked like it was due to either a missing element in the xml or the compile of my classes was incorrect. It was actually neither. The error was due to my definition class for the parent element contained a duplicate definition of a child element which didn't belong.
Example of xml
<messageNode>
<element1>
<element2/>
<element1/>
<element3/>
<messageNode/>
code snipit
public abstract class MessageNode
@Element(name="element1", required=false,data=false )
private Element1 element1;
@Element(name="element3", required=false,data=false )
private Element3 element3;
public abstract class Element1
@Element(name="element2", required=false,data=false )
private Element2 element2;
@Element(name="element3", required=false,data=false )
private Element3 element3;
As you can see the definition of element3 is included in both class definitions. The simple framework xml creates a map of the nodes. when an element is included this way it creates an issue with the values stored in the map. My suggestion when you receive this error is to do a file search for the string of the element name. Double check the definition of the expected element is in the appropriate place.
Friday, May 14, 2010
Friday, April 16, 2010
I have let this blog sit for too long. I am going to attempt to write about the frustrations of development and ways they can be resolved. My first series will be about methodology. A word more foul than workflow. Both words used by those who think all problems can be solved by the wave of a WYSIWIG wand.
Methodologies can make or break a project, a team and companies. I view them, as many do, as effective ways to kill a project. The issue is most development methodologies require heavy paperwork. Often times resulting in long expensive meetings to produce documentation which ends up being more expensive than most realize. Nothing kills a project quicker than paying for large groups of people reading to each other. Money and precious time quickly become an issue if you design an enterprise service before you implement it.
Developing applications can be unpredictable. The issue is, some stakeholders want to think it is. The only way I have ever know a development effort to be successful is to keep it small to start, and grow it over time. Success on a project should never be measured by how many buffalo it can kill by a due date, rather by its small incremental accomplishments. The best analogy I can think of is, you can dream about what is at the other end but unless you start walking there it will always be a dream. Sometimes convincing all members of the team of this is more fight than it is worth.
start with test cases.
Everyone on the team needs to understand the true importance of this one simple item. JUnit or another testing tools can quickly prove their time and worth. It is an easy and effective way to create applications which manage themselves. This doesn't mean they don't need attention. More like having a good pet which has self control. Testing should be used not just to show the code works. It should show how it breaks also. A good test case should show people how to use the code you wrote. Think of it as teaching someone what it is the code does, ensuring they know when they misuse it.
Establishing a sync, test and if its green, release process.
This sounds simple however, for people are unaccustomed to using a Complete JUnit testing environment this can become an issue, fast. This process is comparable to a math equation. You have to be diligent to follow the process or you get the problem wrong. The order of operation is just as important as the execution of each step. Just because you only made a small change to the code you are working on, does not mean you didn't cause issues on a larger scale.
Each person is responsible for taking turns syncing, running and fixing all test which are broke, releasing code which is completely clean and tested. When everyone does their part by following good testing practices, taking solid steps forward quickly reveals a solid product.
Monitoring the project code base can not be trusted to JUnit alone. Two of them I have found to be very useful are Emma and SoapUI. Emma is wonderful for keeping a close eye on the code base. If you use an IDE like Eclipse, you can use both of these tools as plugins.
Running JUnit tests as code coverage gives very accurate percentage reports showing which classes need more testing. However, to my knowledge, it doesn't catch positive and negative situations for testing coverage. The feature of highlighting untested lines of code makes it quick to view areas of concern.
SoapUI has a nice feature of creating xml files containing testing information. I have become accustom to creating a SoapUI project in the Java view. From here you can sync it with a repository for sharing with others. The application I am currently working on uses SOAP messages as an interface. With SoapUI I can create tests containing test data which can be reused. Both tools are defiantly worth looking into.
Everyone on the team needs to pick a technology
This is not done to pigeon hole anyone but to bring the team up to speed on it quickly. This is a time to learn and offer the ability to create a passion for the technology. Once an individual of the team is ready they should then educate the team with what they found, how it works and give a plus minus analysis to the group. Above all everyone needs to have an open mind to learn everything they don't know and teach everything they know.
I will continue this soon.
Methodologies can make or break a project, a team and companies. I view them, as many do, as effective ways to kill a project. The issue is most development methodologies require heavy paperwork. Often times resulting in long expensive meetings to produce documentation which ends up being more expensive than most realize. Nothing kills a project quicker than paying for large groups of people reading to each other. Money and precious time quickly become an issue if you design an enterprise service before you implement it.
Developing applications can be unpredictable. The issue is, some stakeholders want to think it is. The only way I have ever know a development effort to be successful is to keep it small to start, and grow it over time. Success on a project should never be measured by how many buffalo it can kill by a due date, rather by its small incremental accomplishments. The best analogy I can think of is, you can dream about what is at the other end but unless you start walking there it will always be a dream. Sometimes convincing all members of the team of this is more fight than it is worth.
start with test cases.
Everyone on the team needs to understand the true importance of this one simple item. JUnit or another testing tools can quickly prove their time and worth. It is an easy and effective way to create applications which manage themselves. This doesn't mean they don't need attention. More like having a good pet which has self control. Testing should be used not just to show the code works. It should show how it breaks also. A good test case should show people how to use the code you wrote. Think of it as teaching someone what it is the code does, ensuring they know when they misuse it.
Establishing a sync, test and if its green, release process.
This sounds simple however, for people are unaccustomed to using a Complete JUnit testing environment this can become an issue, fast. This process is comparable to a math equation. You have to be diligent to follow the process or you get the problem wrong. The order of operation is just as important as the execution of each step. Just because you only made a small change to the code you are working on, does not mean you didn't cause issues on a larger scale.
Each person is responsible for taking turns syncing, running and fixing all test which are broke, releasing code which is completely clean and tested. When everyone does their part by following good testing practices, taking solid steps forward quickly reveals a solid product.
Monitoring the project code base can not be trusted to JUnit alone. Two of them I have found to be very useful are Emma and SoapUI. Emma is wonderful for keeping a close eye on the code base. If you use an IDE like Eclipse, you can use both of these tools as plugins.
Running JUnit tests as code coverage gives very accurate percentage reports showing which classes need more testing. However, to my knowledge, it doesn't catch positive and negative situations for testing coverage. The feature of highlighting untested lines of code makes it quick to view areas of concern.
SoapUI has a nice feature of creating xml files containing testing information. I have become accustom to creating a SoapUI project in the Java view. From here you can sync it with a repository for sharing with others. The application I am currently working on uses SOAP messages as an interface. With SoapUI I can create tests containing test data which can be reused. Both tools are defiantly worth looking into.
Everyone on the team needs to pick a technology
This is not done to pigeon hole anyone but to bring the team up to speed on it quickly. This is a time to learn and offer the ability to create a passion for the technology. Once an individual of the team is ready they should then educate the team with what they found, how it works and give a plus minus analysis to the group. Above all everyone needs to have an open mind to learn everything they don't know and teach everything they know.
I will continue this soon.
Friday, July 25, 2008
Unca Don Foundation
On Friday June 26th, one of the greatest men I have ever known passed away, Don Newman. He was survived by his wife Brenda and 15 year old son Spencer. I don't know what to say, scream, shout and cry. So I am creating a scholarship fund in his name. The scholarship fund will assist students interested in bettering the world in the study of marine biology and oceanography. It will be available for students of the Las Vegas high school he taught at and to attend University of Southern California.
My Plan
The site uncadon.org will be the home base for my operations. There will be a page for donations, one for a mailing list plus information on the status of the scholarship fund. Because it takes money to make money I will be taking non-tax deductible donations until I receive enough to launch the scholarship fund. The money will be used for lawyers and accountant fees and any other money donated will be used as basis in the scholarship fund. I am expecting the model of the scholarship fund to support itself by opening a bank account and using the interest generated by the principal to fund the scholarship.
Thank You
What ever you can do to help will be appreciated. You will be able to contact me through the website or by the address and phone number below. I assure you I will maintain and use donations with care and honor. This is something I feel strongly about because I want it to be a reflection of the love he gave me. I was lucky to know him. Most people never know someone as kind, gentle, funny and smart as him. I am blessed to have had so many great times with him. He was special to me and everyone around him. He was my hero, my uncle Don.
Brent Adkisson
Subscribe to:
Posts (Atom)
