Dear Lazyweb,
I have a macro I am writing for MS Project 2007 that I want to take advantage of the Team integration in the TFS add-in for Project.
I want to be able to use the object model of the Team toolbar’s Link button to link two project tasks associated TFS work items in TFS. I can’t seem to figure out what the COM (is it even COM?) object is that is providing the object model for the Project add-in.
And no, recording a macro doesn’t work since when I try the macro comes out empty (nothing in the toolbar registers in the macro recorder).
Update: Found this link and this link wich gets me half way there, but probably not good enough. I want to be able to link individual tasks together without bringing up the link UI behind the link button. I think I might have to do it all manually (invoking TFS libraries from custom code). sigh.
At work at the moment we are going through the process of verifying the binaries and their call-trees on one of the production servers that’s been on a delta-upgrade-cycle-only release plan for a long time (delta-upgrade-cycle-only: the process of only releasing changed files to a live environment and never doing a full refresh).
I don’t agree with the philosophy of delta-upgrade-cycles-only. I think you should periodically do a full system refresh on every live system, and it should be an integral part of software develpoment and release process.
More often than not, people don’t do this because it’s too hard to either know what’s out there on their live server, or to deploy the full system with any confidence. Those reasons just aren’t good enough. Continuing on with delta-upgrades only treats the symptom, not the cause.
So in the mean time much pain for us as we ensure that the series of binaries and configuration files on this live server haven’t strayed too far from the “ideal” in our Continuous Integration system. I remembered recently that I happend to have a Pro License to the tool NDepend lying around unused, so we’ve decided to put it to use in the process of our analysis. More on that tool when we’ve put it through it’s paces.
What’s the point of this rant?
The whole point of Continuous Integration is that you are always able to reconstruct/test/verify your fully integrated system directly from your development environment. This panacea is actually achievable (I’ve done it before) in a new software team on a new clean project. But the hardest part of adopting Continuous Integration is jury-rigging it to existing build and deployment systems on legacy platforms. Finding the compromise between practicality and delivering a functional system, and idealism and tearing the whole system down and starting from scratch is a very delicate operation indeed.
Slightly belated, but this note indicates SVN 1.5.0 is out. I’ve been waiting for this release so that I can get a hold of the svn merge tracking functionality, which apparently is only foundational in 1.5.0. Apparently they’ll fill out the merge tracking functionality in 1.5.1 and subsequent releases.
So I’ve been working with the Flash guys in the design team at work now for a few months, trying to help them become more effective collaborative Flash developers. It’s not necessarily been the easiest process in the world as there have been a number of concepts that would be straight forward to most regular devs, but not necessarily Flash devs.
Some of the things we’ve gone through are concepts like:
- Using SCM systems to store the code in a central location
- Design Patterns (in particular the MVC and Command Factory seem to get allot of use)
- Multiple simultaneous checkouts of text source files (or “how to develop without individual checkouts”)
- Visually diffing two versions of a source file
And so on. Along the way I’ve actually had to learn a hell of a lot more Action Script than I would have thought I needed to and seen my fair share of Flash ugliness. I’ll probably do a whole series of these little rants, but this week in particular we kept coming across and trying to work around the same infuriating issue.
This has to do with Flash 8 (Action Script 2) and using the FileReference object to perform a multipart form POST to a server, that is, when you try to do a form submission that has a file upload in it and you care about the status of the submit. On most web systems this is probably a common occurrence; “Send us your picture and 25 words why you think you should win the …”. Sounds like a relatively straight forward thing to do in Flash, and in fact it’s not that difficult to code up.
The problem comes when your server tries to process the form upload/submission and send back some information to the Flash client about whether or not the submission succceeded (think form field validation). In theory a file upload is just another http request and the Flash client should have the ability to read the text in the response body. No such luck. It seems that in Flash 8, the FileReference object doesn’t expose the http response body upon completion, I don’t think the Flash architects thought it was useful. What the?
Why go to all the trouble to build a multipart form submission capability inside Flash and then decide not to pass on the response to the Flash client? What possible reason could they have for such a glaring omission of useful information in a standard web-type request/response scenario.
And just for clarity, we have a constant pressure to try and use the minimum version of Flash required to perform our particular task, so while this problem has been fixed in Flash 9, it’s rather annoying to have to change our system to use a whole later version of Flash for functionality that should have been there in the beginning.
So I ran into this application over on codeplex the other day: SvnBridge. I’m impressed.
I’ve been using Subversion since the mono project adopted it many years ago, and was an instant convert. At the time the only real SCM systems I’d used before that were Visual Source Safe (VSS) or cvs. Subversion was such a breath of fresh air. (I’ll save my rant for any dev team with more than two devs in it that’s still using Source Safe when subversion is available for another time.)
Anyhow since then I’ve pretty much adopted or championed subversion use at any place I worked at because for some strange reason they all seemed to still be using Source Safe even with it’s issues with network access, VPN access, scalability, database corruption and uselessly slow history retrieval (I know I lied when I said I’d save the rant for later).
I continued to be impressed with the availability of tools to use with subversion from client side (tortoisesvn, ankhsvn) to server side (viewvc, mantisbt, redmine, reviewboard) which combined together help make an end-to-end high performance software development environment and process (I’ll definitely save those discussions for more posts to come).
Anyhow, now that Microsoft has released Team Foundation Server (TFS) it’s worth considering that most teams will be moving from VSS to TFS. And all indications are that a correctly configured TFS system is everything that VSS wasn’t.
So to get to the originally intended point of this post, svnbridge enables you to run a local svn server (in your taskbar) that actually proxies all it’s calls to a TFS system. This enables your developers to continue working locally with an svn working folder and therefore be able to use all the other svn integrated tools you may have included in your development process, while having your source code repository actually sit in TFS.
Now it’s relatively fresh software, in that it’s only just been released but I’ve actually used svnbridge and was impressed with how it does a direct mapping for most svn SCM operations to TFS operations including the obvious commit messages, branches and revision sets.
Recent Comments