Teamprise will be exhibiting at TechEd 2008 Developer in Orlando, June 3 - June 6. If you're interested in Team Foundation Server or source control with Java, you should stop by booth 1426 and say hello.
We'll be giving demos of the new Teamprise 3 and all it's great new features. Hope to see you there!
It's been a long time since I updated my blog, in part because I'm lazy, but mostly because we were busy putting the finishing touches on Teamprise Client Suite 3.0. We're very proud of our 3.0 release, it's got a lot of great new features, and we think you'll be very happy with it.
If you're in the greater Chicagoland area next week, I've been invited to the Chicago VSTS User Group to give a tour of the new version of Teamprise. If you're interested in how Team System can play nice with Java developers, I suggest you stop by and check it out:
The meeting begins at 5:30 PM at the Microsoft Chicago (Loop) Offices:
77 W Wacker Dr, Suite 2300
Please RSVP if you're going to attend.
Even if you can't make it next week, be sure to check out the Chicago VSTS User Group, or another user group near you. It's a great resource if you're a VSTS or Team Foundation Server user!
Microsoft's currently launching the newest version of Team Foundation Server as part of Visual Studio 2008. There are launch events all across the US (as well as in many other parts of the world), so if you're interested in the new features in TFS 2008, check out the events near you at Microsoft's
"Heroes Happen Here" site.
Teamprise will be exhibiting at the Chicago launch event tomorrow, March 11. We're in booth 47 - stop by and say hi if you're attending.
Even better -- our very own Martin Woodward will be presenting at the Dublin launch event tomorrow. Be sure to check him out if you're attending out there.
Otherwise, there are still plenty of events in a city near you - be sure to go check out what's new in TFS 2008!
I got a flyer in the mail for the RSA Conference 2008. Since I enjoy cryptography - and despite the fact that I know next to nothing about it - I was interested.
But I'm not going to lie, I'm really put off by the advertising. This year's theme for the conference is Alan Turing. How this conference has been going on for 14 years and ignored him up to now is a mystery to me. (They made a carrier pigeon the theme in 1997. That's right, a carrier pigeon apparently did more for security than Turing.)
But now that RSA has finally decided to recognize the man, they're doing some stupid advertising around it: What Would Turing Do? Which, frankly, would make a cool bumper sticker, and I would have been impressed... if they had just asked the question and not tried to answer it.
Instead, they give some odd answers that show that their marketing department never bothered to talk to a developer - or even a read a Turing biography. Their answers are frequently bizarre and have nothing to do with Turing: he would "have a raging sushi addiction", "be a huge Dr. Who fan" and would "collect rare Phillip Glass vinyl". (Yes, they also didn't bother to google "Phillip Glass" to realize that they misspelled his name.)
This is the company that was founded by three math PhDs who invented the RSA public key algorithm the RC block ciphers, and the MDx hash functions. And they're suggesting that he would "recite the far reaches of imaginary numbers to pass the time"? I'd like to think that would be beneath Turing... hell, it would be beneath me. (A googleplex times i. A googleplex plus one times i. See, not very satisfying is it?)
Very disappointing.
Especially since it's obvious that really, Turing wouldn't care about sushi or Bill Gates. He'd be far too busy enjoying the liberal sexual mores of this fine time we live in.
Gluing C and Java together isn't particularly difficult - JNI is a well-designed bridge to the world of native code. Simple tasks are straightforward, and more complex ones are still possible. Surprisingly, it's quite easy to debug as well.
When working on native code, I tend to make all my code work in C first - debug it, write some native test cases, and ensure that everything works. Then I write a little JNI glue to make it accessible from Java. This has worked surprisingly well, and given few surprises. But what happens when something goes wrong?
For example: I was writing some ugly Win32 code to do some various things that can only be done in C. Despite my aversion to programming in Windows, I whipped up some native code to access what I needed. I wrote some test cases to confirm that everything worked, and I was pretty happy with myself, until I realized that all the work I had done was on ANSI C strings (ie, null-terminated char arrays.)
Regardless, I tied it up to my Java with some JNI code just to watch it fail when I passed in Unicode strings.
I'm not particularly well-versed in the intricacies of Unicode, and even less so Win32 programming with its WCHARs and PSEC_WCHARs and nasty habit of #define'ing function names to those that end in W. So I wasn't real sure of exactly what I needed to change to make my native code Unicode friendly. It sure would be nice if I could debug this in VisualStudio.
Attaching to a running process in gdb is easy - and it's easy to provide debugging symbols for that process. VisualStudio is a little less straightforward, but just as easy.
First, make sure that your DLL is emitting debugging symbols. Ensure that you're passing these flags to the compiler and linker:
CFLAGS:-Od -DDEBUG -D_DEBUG -Zi
LFLAGS:-DEBUG
Build your native DLL and ensure that a .PDB file was created - this is the debugging information for your library. Run your java application.
Open VisualStudio and setup your symbols. Go to Tools -> Options, and open the Debugging -> Symbols pane. Add a new PDB location which points to the PDB file that was created from your build.
Now you can attach to your java process by going Tools -> Attach to Process.
Finally, you can load the source (ensure that this is the source you built from, in the same directory as your PDB file) and set breakpoints, etc.
Engadget has an article on how to remove the Windows BSOD icon in 10.5. They seem to think that removing it is a good idea - since it's "so pompous and galling".
I call shenanigans. Pompous? Maybe. Galling? Give me a break.
It's true, Microsoft would never do something like this. Mostly because Microsoft cares precious little about interoperability with other network filesystems. CIFS is good enough for everybody - how's that for smug?
I suggest ignoring the whiners and embracing the BSOD icon. And then take it a step further: install xscreensaver and use the BSOD screensaver. Then smile when people tell you "there's something wrong with your computer!"
Sorry for the late notice, but if you're free on Wednesday evening, this might be interesting.
Teamprise was invited to present at this month's Chicago VSTS Users Group to discuss using TFS from within the Eclipse IDE and from non-Microsoft platforms. I'm excited to make a fool of myself speaking in public (and excited to learn that a VSTS Users Group exists in Chicago.)
I'll be speaking with David Dugan who's a Senior Consultant for Sogeti. David will be discussing accessing TFS from older versions of Visual Studio.
Maybe I'll see you there!
A lot's been made of the various frustrations that go along with running Windows Vista. I won't rehash them, mostly because I'm not able to. My frustration is with installing the damnable Operating System:
Perhaps this dialog doesn't look particularly strange, until you realize that the install disc only included four CD images:
(This was the MSDN install for Vista.)
(From the Matchbook Museum)
So you're developing Eclipse RCP applications, and you're excited about moving your RCP app to the Eclipse 3.3 framework...
Wait, you're not? Then this post probably doesn't interest you too much.
But if you are, there are some UI changes in the way Eclipse 3.3 starts up that you should be aware of.
Likely, your application has a subclass of WorkbenchAdvisor, probably called something like YourWorkbenchAdvisor. And this is doing various useful things like creating views and setting preferences, all that good stuff. And maybe you're overriding WorkbenchAdvisor.postStartup() to do some useful things after the Workbench has started.
Maybe one of those useful things happens to be raising a Dialog. In versions past, this would have worked fine for you. In Eclipse 3.3, you may be in for a rude awakening. Despite the name, the Workbench has not started and the UI is not fully functional when YourWorkbenchAdvisor.postStartup() is called.
In particular: other threads cannot call back into the UI thread with Display.asyncExec() or Display.syncExec(). The UISynchronizer will queue up any runnable you post on to the UI thread to run once it actually has started. This can present a problem if the dialog you raise fires off a background thread to do some work.
For example, in Teamprise Explorer our login dialog has an option to test your connection to the TFS server. This involves firing off a background thread to look at your network settings, try to connect, etc. The results of these test are then posted back to the dialog using Display.asyncExec().
What happens in Eclipse 3.3? Since the login dialog was started from our postStartup() method, the UISynchronizer hasn't started. So when we call Display.asyncExec() to display our results, they're put in a queue to display once the UI has fully started. This, of course, only occurs after you've closed the login dialog, at which point there's no dialog to display these settings to.
Ouch.
To combat this, you should move any UI code out of YourWorkbenchAdvisor.postStartup(). You can either do this by putting your code in the UI queue to execute as soon as the Workbench starts fully, or you can move it out of postStartup() entirely and use a different hook to raise your UI once the Workbench is started.
These options are both sort of a hack, so you're welcome to use whichever you find less obscene:
Display.asyncExec() before the Workbench startup has completed, your Runnable will be queued to run after the Workbench has started, but this is only true if it's called from a thread other than the UI thread. So you need to get off the UI thread to post this into the queue. Firing off a new thread from your postStartup() method should do the trick:
new Thread(new Runnable() {
public void run()
{
Display.asyncExec(new Runnable() {
public void run()
{
// do something on the UI thread
// after Workbench startup
}
});
}
}).start();This will put your inner Runnable on the UI queue to execute as soon as Workbench startup is complete. (Had you called Display.asyncExec() from the current thread, it would execute immediately.)
If you don't like the idea of stuffing a Runnable inside another Runnable, there's a second option:
WorkbenchAdvisor.eventLoopIdle() to call your code the first time the UI is idleWorkbench.runUI(), you'll see that the UISynchronizer isn't started until right before a call to Workbench.runEventLoop(). So hooking in to WorkbenchAdvisor.eventLoopIdle() is your first opportunity to execute code once the UI thread is properly started.
Adding this to YourWorkbenchAdvisor should be sufficient:
private static ThreadLocal eventLoopStarted = new ThreadLocal() {
protected Object initialValue()
{
return Boolean.FALSE;
}
};
private void start()
{
// do something on the UI thread after Workbench startup
}
public void eventLoopIdle(Display display)
{
// the ui is now started, we can do our work
if(eventLoopStarted.get().equals(Boolean.FALSE))
{
// call any post-startup UI
start();
eventLoopStarted.set(Boolean.TRUE);
}
else
{
// default: yield cpu until new events enter the queue
super.eventLoopIdle(display);
}
}I'm synchronizing on the eventLoopStarted flag, which is probably not necessary since only the UI thread should be calling eventLoopIdle(). But proof of thread-safety is left as an exercise for the reader.
Also, if you override eventLoopIdle(), be sure you call back to the base class or call Display.sleep(). Unless, of course, you like burning up your processor whilst doing nothing.
There you go - with just a bit of hackery, you should be able to move your RCP application over to Eclipse 3.3 and still get all the same UI at application startup time.
