Archives
-
New Article: Agile: Story Completion Problems
I've posted a new article on some issues we had with story completion and steps we took to resolve them.
-
Agile: Story Completion Problems
On a recent project we ran into an interesting problem – or rather we ran into it at the end of every iteration and especially the end of each release. The essence of the problem was the stories were “done” but the customer had not signed off on them. In non-agile shops the mantra “QA has it” is heard for the same symptom, in fact our morning stand-ups were starting to have the same flavor. For this project there are 2-3 developers for each tester and our current immature state of acceptance test automation means a full regression of our primary product takes about 1 week including automated, manual and some ad hoc testing.
-
Going the Extra Mile – Why Bother?
Having recently been involved with a team that was being exhorted to “step up” and “go the extra mile” I noticed a range of responses from “lets go” to “why bother” to “I don’t think so”. After thinking about the response I identified several personal factors:
-
Why We Love Lazy Programmers
At one time our build and deploy process was full of manual steps and could take 1-2 days to put a build into the QA and Dev environments. Using tools like nAnt we improved the build and deploy time to 1-2 hours with most of the automation on the build side. Later one developer got tired of manually deploying and created some deploy scripts. Now deployment to any of the 5 environments (development, testing, staging, demo, production) is a single command line taking 1-10 minutes depending on whether a full build is required or not.
-
Ward Takes On Microsoft
From Wards page on c2.com:
-
Agile Q&A: Missing Features/Requirements
Given the 3 part agile team of customer, QA, and development, what should we do when a feature the customer wanted is not implemented, or is incorrectly implemented at the end of the iteration?
-
Pixel Perfect Web Design
It can't be done.
-
Why Is So Much Code So Bad?
I've been in the position to read a lot of code written by many different developers. And most of it is terrible.
-
What Makes A "Good" Company Different From Any Other?
I haven't had that many jobs in my life, but as a contractor for 13 years I've been in numerous companies and talked to lots of people about how much they liked their jobs. Believe it or not, the biggest reason I've found for job dissatisfaction is management.
-
Versioning And XP
This came across the AgileDotNet mailing list awhile back and indicates one of the misconceptions about XP that I run across regularly.
-
Public Variables In VB.NET Modules
Interesting bit of detective work the other day I thought I'd share with everyone. A friend of a friend was having trouble with an ASP 2.0 project that was ported to ASP.NET. Turns out that on some web servers the different clients were getting their data overwritten by others. A little splunking uncovered that the application was maintaining state using a public variable declared in a VB module. I could guess what was happening, but wanted to know the details so I created a tiny test app that looked like this:
-
Presenting at XP Users Group in Portland, OR
I will be presenting "Writing Testable Code: Where XP meets QA"
-
Context Sensitive Config Files
M. Keith Warren was asking for an enhancement to the web.config to look like:
-
Is FIT Testing Useful?
A question came up yesterday as I was explaining the virtues of FIT to the development team (see my previous entry).
-
Playing with FIT
Spend a few odd hours over the last week integrating the ability to run FIT tests into our wiki. Generally everthing worked well except I was having trouble figuring how to bring the wiki pages that described the tests together with the code that actually got tested with the framework that brings them together.
-
Do You Model?
An interesting discussion with a co-worker today related to the release of Together.NET. We were discussing why we weren't really interested and realized that neither of us thought about code in UML. Rather we thought about code as components with services. Personally I used to think about code in UML, but about 3 years ago I just kind of stopped.
-
Technical Debt
Martin Fowler wrote a post about technical debt that struck a nerve we me and others.
-
Vault NAnt Tasks
Brian Schkerke, Ryan Duffield, Robert Hurlbut and I put together a project to add Vault support to NAnt at http://vaulttasks.sscli.net/. Eric Sink was kind enough to provide a Vault server,
but it dosen't allow public access. All the necessary commands necessary for integrating Vault into Draco are provided. Thanks to several of my developers for working on these tasks. -
XP/Agile Universe 2003: Day 3, part 2
XP/Agile Universe 2003 was held Aug. 10-13 in New Orleans, LA (NOLA). See my previous posts regarding day 1, day 2 and day 3.
-
Version Control: Decision Revoked
In contrast to my earlier post, it turns out that we will not be using Vault. For some reason that even SourceGear cannot explain (we are customer #2) we had tremendous difficulty migrating our repository. So for the time being we've decided to clean up our VSS repository and live with it until it causes pain again. I still think Vault is a great product and SourceGear tried valiantly to assist, but to no avail. I expect we will re-assess when 2.0 is released.
-
XP/Agile Universe 2003: Day 3, part 1
XP/Agile Universe 2003 was held Aug. 10-13 in New Orleans, LA (NOLA). See my previous posts regarding day 1 and day 2.
-
XP/Agile Universe 2003: Day 2
XP/Agile Universe 2003 was held Aug. 10-13 in New Orleans, LA (NOLA). See my previous post regarding day 1.
-
XP/Agile Universe 2003: Day 1
XP/Agile Universe 2003 was held Aug. 10-13 in New Orleans, LA (NOLA) and was a great experience.
-
RE: Roadmap for SourceSafe and Beyond
Korby Parnell recently bloged about the VSS Roadmap. He notes that the big (HUGE) feature increase will revolve around Unicode support, web services, and better IDE integration for Whidbey (i.e. 2004 if no delays).
-
Version Control: Decision
Regarding my previous post on version control, I thought I give a little update on what we finally decided to do.
-
Agile Process: Iteration Planning Tweak
On Ward's suggestion we made a change to our iteration planning around the velocity & task sign-up process.
-
XP/Agile Universe
Looks like I'll be attending XP/Agile Universe in New Orleans Aug. 10-13. Any other bloggers going to be there?
-
Agile QA: Iterations & Release Testing
In discussions with Ward and others in our QA group I'm starting to see another possible arrangement for an agile QA team.
-
Ward in the house
We have the great pleasure of having Ward Cunningham on-site this week to help us fine tune our implementation of XP/agile process.
-
Agile QA: Customer Advocate
One of the roles we have defined in our agile process is the "Customer Advocate". This is a distinct role from Customer or Customer Proxy in that the advocate is looking after the customer's needs from a quality perspective. The need for an advocate is seen in many agile implementations. The usual symptoms are a customer that needs to do their "real" job or where the customer needs assistance writing appropiate stories and acceptance tests. The advocate him/herself may or may not have any specific domain knowledge.
-
What are you currently reading?
ScottW asked What are you reading? For all the reasons he mentioned I think it a good idea.
-
Agile QA: 1 Team or 2?
We've been having an interesting discussion internally about whether our development and QA groups should be part of the same agile team or seperate with a half iteration offset. So far we've developed a list of pros and cons to help us decide where to go.
-
Is Software Really Different than other Industries?
Much has been made about the failure rate of software projects with the failure rate being around 66%. Failure being defined as over budget, delivered late or both. No mention is made of how many of those projects suffered from severe scope creep and feature bloat. Neither is whether or not the sucessful projects delivered the correct software nor how complicated the "sucessful" projects were. Further it has been claimed that if it were any other industry the failure rate wouldn't be tolerated.
-
Why is Software Hard?
I read an article recently that in part was asking the question, "why is software so hard?" They were using the statistics that 1/3 - 2/3 of all projects are late, over budget or canceled. Whether this is really any different in other industries is another article.
-
Session Variables are Globals Too
Since I'm on this rant about global variables I'd just like to point out that sessions are globals too - use them sparingly if at all. It is amazing the quality of product you can force yourself to create if you eliminate globals from your toolbelt.
-
Patterns for Replacing Global Variables - Reduce Scope of Global
The closest I can come to this one is Reduce Scope of Variable.
-
Patterns for Replacing Global Variables - Replace Global(s) with Singleton
-
Global Variables Considered Harmful
Prof. William Wulf and Mary Shaw wrote a paper of this title in 1973, although I couldn't find the original paper online I did find some references.
-
Version Control
I had such good responce to my original post on version control software I thought I'd risk posing the question to a wider audience again.
-
Project Organization
In reflecting on my previous post regarding shared libraries in VSS vs CVS I realized that the end of the post got to the real meat of the matter. Turns out we are using a feature of VSS to help us organize our shared libraries, however, shared libraries really have very little to do with version control (except for released versions of course).
-
Weblogs as Community
I know this has been talked about before, but this is the first time I have really experienced it. In my post on Moving to VSS I posed a question and got several answers in both comment and email form. When I posed the question I didn't really expect to much response, and I greatly appreciate those that did.
-
Spatial Thinker
Fun alternative quiz to see your "thinker" type. Seems pretty accurate considering the length of the quiz.
-
Issues Moving to CVS from VSS
We are considering moving from VSS to CVS but have run into some feature differences (i.e. sharing) that we currently rely on to distribute shared libraries to all dependant projects.
-
Looking into SOA
A while back I found the Enterprise Integration Patterns website and was please to see that someone out there has been putting some serious thought into this (and writing about it). Our intergration style is somewhere between Shared Database and Remote Procedure Invocation. I had come up with my own architecture that had some significant gaps which are being nicely filled in by Gregor and co.
-
The Prodigal Programmer
I've finally crawled out from under my pile of work. Many interesting things happening here.
-
NiftyPortal.com
NiftyPortal is a web based aggregator with a really nice look.
-
Debugging Windows Services
As seen on Peter Provost's Geek Noise
-
XPath & Namespaces
I'm sure many out there know this or figured it out eons ago, but it was new to me and took awhile to figure out.
-
Writing Testable Code - Story: Retrieve RSS Feeds
See http://dotnetweblogs.com/Wallen/posts/4065.aspx for backgound info.
-
Writing Testable Code - Introduction
I've had a keen interest in the way testable code is different than non-testable code. To help me explore the differences more fully I plan to write a series of posts that chronicle my experiences, insights and failures.
-
Root Canal
Lucky me had a root canal today. My dentist told me I had the longest roots he had ever seen, whoopee! What that means in practical terms is that the tools they use for cleaning out the canal wan't quite long enough and that I'll have to rely on antibiotics to make sure I don't have any problems.
-
Windows Update, Good vs. Evil
Scott H. pointed out that they typically disable Windows Update on their production servers. Makes perfect sense to me. On the other hand, I want Windows Update to pull updates for EVERYTHING on my dev box. I don't want to look for Office patches, SQL patches, MapPoint patches, etc., etc. I want a Just Patch Everything button.
-
Writing nAnt Tasks
I finally broke down and started writing my own set of nAnt Tasks to control version (revision) numbering and updating the AssemblyInfo.cs files so our deployed assemblies will finally have the real version number embedded in them. I expect there is documentation somewhere on the best way to do this, but I went with the "if all else fails read the documentation" approach.
-
BuildIt
BuildIt is a new build tool from MS (via Sapient Corp.)
-
Terrorism Humor
ATTENTION
-
Hmm
How evil are you? -
Fred Rogers 1928-2003
-
Cool VS.NET Feature
-
How to be a Programmer
Mike Gunderloy turned me on to this paper by Robert L. Read.
-
Ingo's Distributed .NET Newsletter
From Ingo - his free "Distributed .NET Newsletter". After reading his book and his weblog for a while I appreciate his straightforward approach. Sign up, I did.
-
I am
-
Pair Programming
Today was a great day! After spending most of yesterday and this morning chasing down a deployment bug that turned out to be a mis-registered COM object (worked in DEV, but not in QA) I spent the rest of the day pair programming with a new employee. We decided as part of his orientation that we should develop an extension to the ConfigurationSettings.AppSettings to be aware of the environment the code was running in. This has been a desired feature for some time now as we spent too much time twidling config files after deployment. After consulting with a couple of other developers on the design we plowed ahead, test-first.
-
Shuttle
Like many I am saddened by the loss of the crew of Columbia. It is one of those defining tragedies in the collective memory. I still remember the exact place I heard about President Reagan being shot, the Challenger explosion, 9/11 and now the Columbia.
-
More nAnt
I was playing with nAnt today to try and auto-generation version/build numbers so I wouldn't have to keep track of them. Luckily (via Google) I came across John Lam's nifty version task. Just an aside for those wanting to use John's task or write your own - the naming convention for task assemblies is "*Tasks.dll", note the plural. If you don't name your task correctly (and place it in the bin folder) nAnt won't recognize it.
-
A New News Aggregator
NewsGator is a great tool for keeping up with all the interesting blogs out there. It is a News Aggregator that integrates into MS Outlook which is my primary communications tool. I was using Aggie - a nice tool in itself, but it didn't fit into my day as seamlessly as NewsGator. Many thanks to Greg Reinacker for creating this great tool.
-
Better Builds
Did a complete deployment in 40 minutes today. World record!
-
Learning nAnt
I've volunteered to be the build master/coordinator the last 2 iterations of our web product. As we've gotten more sophisticated we've pushed some of the functionality off to Windows Services based applications. This has the net affect of quadrupling the deployment headache we've been fighting for the last few months.
To address this headache with a little automation aspirin I turned to nAnt based on tones of positive feedback from others who use it and the little I used Ant in the past. My first order of frustration is the documentation is nearly useless from a beginners perspective. It assumes you know everything and just need to look up the attribute for this or that. Once I figured out what was happening from the source code (the blessings of open source) things began to fall into place fairly quickly. -
Abandoning the blow by blow
I've decided to abandon the day by day account (obviously) since the teams are in a nice flow now. Instead as interesting things or events happen I'll write about them.
-
Iteration #2 - Day #3 Tuesday 1/7/2003
The continious integration issue raised its head again in the form of deployment issues. Simply put our current process stinks, it takes over an hour to create the build and 3-4 hours to deploy to Dev and QA and that is a simple website + database deployment, it doesn't include any other services. The first order of business was to automate the website build process and dedicate a build machine and build master. After fiddling with nAnt for awhile I discovered the devenv.exe command lets you build a solution without haveing to redefine it in nAnt, a big bonus. I then created an installation (deployment?) project for dev and QA. I only created the QA install project to support our current shared Dev/QA web server, that will be changing soon so that Dev and QA have completely seperate environments. The end result is we can build a Dev installer for the website in about 5 minutes now. The tasks remaining are automatically getting the latest source from VSS and labeling the source. I'd like to automate the VS IDE since it has its own ideas about which files belong to a project and how that is integrated into VSS. Eventually I'd love to have automated version control, builds, unit tests, functional tests (FIT) and deployment. We'll see.
-
Iteration #2 - Day #2 Friday 1/3/2003
I had a very interesting conversation with our customer and the QA team today. Most of it centered around communications between the customer, developers and QA. The issue that started the whole conversation was that the customer and a developer discussed a story and agreed to build it a certian way. At the completion of the iteration one of the features was not implemented the way the customer remembers specifying it. However, since there are no formal requirements documents he dosen't have anything to point at to say you missed this. To further complicate matters the omission wasn't noticed until the next iteration had started causing the customer to wonder if he could insist that the omission be corrected even though it wasn't oficially part of the current iteration.
-
Iteration #1 - Day #1 Thursday 1/2/2003
We slipped into our second iteration with ease today. The processes are starting to feel normal for the team and we are getting the daily heartbeat. Soon we should get into the iteration heartbeat as well. We spent some serious time getting our DBA up to speed today (vacations and other tasks have kept him out of the loop until now, something that we should have addressed sooner but didn't). We also have a good discussion on how we are going to incrementally add unit tests to our existing code base, add the necessary helper function to test code that currently requires lots of database setup because of the existing architecture (to be changed as we touch that code some day).
-
Agile Databases
Martin Fowler and Pramod Sadalage have written an article about Evolutionary Database Design. This is a good starting point for all of us trying to do agile processes with database heavy projects. I'm looking forward to seeing the patterns they come up with.
-
Iteration #2 - Day #-1 Tuesday 12/31/2002
Today we had a major deployment issue. It took 2 of us all day to find a strange set of "bugs" that were a result of not getting a couple of stored procedures into our dev and QA builds. Afterwards we all sat down to see how we could avoid this kind of thing in the future, especially for production releases. Here is what we came up with:
-
Iteration #2 - Day #-2 Monday 12/30/2002
Another interesting fact came out of our discussion with our customer. He was feeling nervous about progress since our integration was late and couldn't determine the true state or quality of the project. We determined that our binary approach to story completion didn't reflect what people needed to know. So we changed our approach to list the number of test cases that passed and failed as a stacked graph with time as the X axis. This should give the stakeholders a better feel for how complete the iteration is.
-
Programming Fun
I was talking to one of our developers last week and he made a comment that didn't strike me until yesterday. He said he was actually having fun again! This made me realize that by placing responsibility for tasks in the correct hands, everyone can better enjoy their jobs. I recall other projects where the development team was given high level guidelines and left to it. Everything was fine until we got done with the "fun" stuff and were trying to make decisions about features etc, where we didn't have the slightest clue. The developers were working on whatever they wanted, and not much was getting accomplished.
-
Iteration #1 – Day #10 Friday 12/20/2002
Today was the last official day of the iteration. We didn't get everything signed off by our customer representative (QA), but we did complete all the technical tasks generated from the story. Additionally we got a few bonus features as people noticed that an hour or two would pull things together. I'm not sure this is the best thing to do since it wasn't on our official list, but as most of the developers know what features are desired and it wasn't blatant gold plating we can let it slide. Our director and PM decided to slide the end of the iteration to 12/31/2002 to line up with another related project and because of the difficulty of having a 2 week iteration over the Christmas holidays.
-
Iteration #1 – Day #9 Thursday 12/19/2002
Today was a regular working day. We came, we coded, we went home. We did make a couple of design decisions and the design of a couple of components is changing as we better understand what we are building. I keep waiting for someone to complain about constantly changing interfaces, but people are just stubbing out the return results for know. I should check in to see what the tests look like. Mock objects are something we have on tap for a training brownbag and seems like a technique that could be useful.
-
Iteration #1 – Day #8 Wednesday 12/18/2002
Yesterday our customer was (rightly) getting nervous about not having seen a build yet, so the team committed to producing a build today and followed through with flying colors. I'm still getting some questions along the lines of "why build when we know all the functionality isn't there yet". If we can get the build process somewhat more automated I think these questions will go away. Our customer really likes being able to see incomplete functionality so he can make changes before we've committed a lot of time. QA also likes being able to see the product earlier in the cycle so they know their tests are accurate and complete as well as giving earlier feedback. All in all just the way agile should be working, we just need to straighten out some kinks.
-
Iteration #1 – Day #7 Tuesday 12/17/2002
Brief status: bullpen space is ready, desktops are installed, servers built. Hooray! A couple of us actually worked in the "pod" as it is called, but no pairing yet. At this point it looks like this is not going to happen this iteration.
-
Iteration #1 – Day #6 Monday 12/16/2002
Brief status: bullpen space is ready, the desktops almost installed, servers on-site, but not built. Looks like will be good to go tomorrow afternoon.
-
Iteration #1 – Day #5 Friday 12/13/2002
Brief status: bullpen space is ready, but desktops not installed - still shooting for EOD Monday.
-
Self configuration of objects
Mark Strawmyer has a nice article on using .NET attributes to assist the self configuration of objects. Interesting approach, and one I'm sure I can apply in many areas as I think more about how to leverage attributes. In my current thinking (revolving around writing testable code) I'm having difficulties with the whole area of configuration. We are trying to write code that can have automated unit and acceptance tests (customer tests) and since the dev, qa, integration and production environments all have different configuration settings one can't just grab everything out of VSS and run the test (the goal) since the tests will break without the correct configuration files.
-
Iteration #1 – Day #4 Thursday 12/12/2002
Brief status: no bullpen yet, hardware arrived - everything should be ready EOD Monday. Today I spent time resolving the need to share information without resorting to MS Word files in VSS (which never works since there are too many layers to go through to get the information).
-
Joel on Software - Lord Palmerston on Programming
Joel had another good article today. Lord Palmerston on Programming is about the fact that you need to know more and more to be a good programmer and that the skills are moving from bit pushing to framework/API knowledge.
-
Iteration #1 – Day #3 Wednesday 12/11/2002
Another standup and all is still well on day #3. We still don't have our bullpen and the hardware hasn't been ordered. But in the tradition of "do the simplest thing..." we are moving forward.
-
Iteration #1 – Day #2 Tuesday 12/10/2002
Another standup and all is still well on day #2. We still don't have our bullpen yet, but I am assured it will happen by tomorrow. Hardware has been approved and ordered and should be here by the end of the week baring any supplier shortages. The hardware we can work around until we get serious about processing our test data. In fact we are temporarily borrowing some servers from the dev lab and QA until the dedicated stuff arrives.
-
Iteration #1 – Day #1 Monday 12/9/2002
We had our first daily standup today and everything went smoothly. Everybody has well defined tasks to do to get the project started. Our bullpen facilities are still up in the air, but should be resolved soon. In any case not much coding is happening today, should be more tomorrow. I am interested to see how the first rounds of pairing go.
-
Iteration #0 Fiday 12/6/2002
With everyone in place with scheduled the first ever XP style planning game. I should mention that I decided to use XP as a concrete place to start since much has been written about XP and the team could read up off line
-
An Agile Preface
The company had already touted the virtues of iterative development and automated unit testing. However, the implementation of these practices was sporadic at best and nonexistent at worst. Iterations were thinly veiled waterfall practices with documentation updates starting to occupy large chucks of the iteration. Unit testing fared no better with only a couple of developers actually writing tests.
-
Building an Agile Team
Part of the reason I changed jobs recently was to be able to build an IT department based on agile principles. In order to better recreate the experience I've decided to post my impressions, what worked what didn't and things I'd like to adjust on our next iteration.
The company I work for now has an internal IT department that creates internal and customer facing products. When started the company was full of cowboy coders and heroics. This gave way fairly quickly to waterfall-ish style process which when I was brought on was starting to overwhelm the department to the point of jeopardizing important projects, mitigated only by individual heroics.
The Director of Engineering (a friend of mine) understood what was happening, but didn’t have the experience, or the time to personally lead the implementation of agile processes to bring his shop back on track. I did have some experience in leading agile teams and was ready to take on the bigger challenge this represented. After many hours of after hours discussions circumstances made it possible for me to come on full time and enact the proposed changes. One of the benefits of having the director work this change ahead of time was that by the time I came on board most of the political battles (executive-wise) had been fought. Now all that was left were the rank and file, a somewhat more challenging effort, but one I had dealt with before.
With the background out of the way, on with the show! -
Unexpected Data
While evaluating a product that massages my data (very large quantities - think multiple terabytes) I was becoming frustrated with the fact that the product couldn't handle my sample data set. Even with the vendor rep on-site we never got the entire data set processed so we could evaluate what the product actually did. I didn't think this should be a big deal, the data set wasn't that large (couple of megabytes of ASCII text), but was proprietary so I couldn't be sending it off to have their techies pour over it to see why their product kept choking on it.
I do remember my consulting days when applications would suddenly stop working and after hours of debugging find out that there was some unexpected data sending things out of kilter. In fact after awhile I started looking for "bad" data first when presented with certain scenarios.
Everything was really brought home when evaluating a competitor's product where everything worked right the first time on the same data set. The first product is more mature, has more features, more tuning options, etc, etc. But it doesn’t work on my data, even with their assistance. Because they assumed that all the incoming data would be cleansed and perfect and they skimped on the ability for their product to handle unexpected data, they are going to lose out on licensing revenue (a lot of revenue).
Defensive programming wins out over features.
One my peers today was pointing out a manual process that is a chokepoint. The manual process is there because some of our programs don't handle unexpected data very well. His now famous comment was "If we wrote better progams, we wouldn't have to do that". Amen.
How does one go about writing "better programs"? We are embarking on a crusade to bring automated unit testing to all our projects. A part of this will include having the QA engineers teach our developers about writing good tests including basics such as boundry testing so that unexpected data problems tend to go away as a class of problems. -
More SOAP
I relearned one of the reasons why we do RPC style architecture. I am working on a solution spike with an expensive (license and hardware requirements) piece of software and wanted someone else to play with it to get a sense of the data that was being manipulated. So I created an installer and used it to put the software on another machine, easy as pie. Of course it didn't work right away because all the 3rd party dependencies weren’t captured correctly.
After futzing for about an hour, running back and forth between machines everything was working fine. Except now another person wanted to play with it as well. I didn't want to kill an hour or more every time I revised the spike so my users could see what had been done.
Luckily Thanksgiving came upon us and I was forced away from my machine for a couple of days and clarity returned. My first thought was to bag it all and redo everything as a web page, but it seemed like wasted time to recreate all my previous GUI work and run into who knows how many snags to save a couple of hours. Then I remembered I could have my cake and eat it too by only deploying my rich GUI (via .NET no-touch deployment) keeping my customers up-to-date and putting all the problem API calls and configuration files on my development box where I could keep an eye on them behind a SOAP interface.
Now granted I haven't yet made this change, and I haven't decided if SOAP or .NET remoting is the best choice. Nevertheless I can see several advantages, not the least of which is that I can abstract my interface to the service I am building and (with SOAP) can trivially create proxy classes to manage the communications. Anything that saves me coding time is tops in my book. -
Integration
The company where I currently work uses a large number of third party components, which is not unusual for someone in our space. In fact it would be far to expensive to develop and maintain many of these components ourselves. The one unifying aspect of these components is that they are all ActiveX/COM based and play well with our development environments.
However, we are looking at some new technology that is dependant on Java RMI where the COM integration solution is using the "java" moniker with the CreateObject method. i.e. Set o = CreateObject("java:Java.Util.Date"). Unfortunately this requires using the Microsoft JVM which doesn’t support RMI out of the box (there is a patch available from IBM). Also MS is not maintaining the JVM and Java 1.4 and above is not supported. The final nail is that object creation with monikers doesn’t seem to be supported in .NET.
Another product in the same space supports COM directly, but in testing with .NET the Interop seems to be leaking memory at an astounding rate, making it non-viable.
Where to go from here? Our next solution spike is to investigate the "greatest application integration technology ever invented by man" - otherwise known as SOAP. The hope is to isolate the peculiarities of each product in an environment that it is compatible with, and additionally insulate ourselves from change a little. -
Leaving blogger
Blogger introduced me to weblogging, but I am ready to move on. Scott Watermasysk has kindly provided space on his .NET hosted solution. I should be moving most of my content from blogger in the next week.
