Yep.. at around 10:15 am PDT, a 6.0 tembler hit about 150 miles south of where I am. It was certainly a rockin' and a rollin'. You can see more information here. This is an automatically updated page so you'll need to hit it soon because the information will probably be cleared soon.
Michael Swindell just posted to BDN, this article regarding the NDA license that was shipped with the BorCon preview. So for all you folks out there remaining tight-lipped about the content of your copy of the Diamondback preview, the floodgates are now open. Sorry for the confusion, folks. You can now post blog entries, articles, newsgroup messages, screenshots, whatever. The preview was a whirl-wind last minute thing, so there was bound to be a few mistakes. Just remember that this is a pre-release copy of Diamongback, so expect things to change considerably between the preview and the final public release.
Looks like TOndrej has snagged a posting I made from the borland.public.delphi.non-technical newsgroup and made a blog entry about it. I honestly thought that the “-r” command-line switch was actually documented. Maybe Delphi 8?
Danny has posted some information on our analysis of the problems that folks are having with the .NET 1.1 SP1 update that was just released a few weeks ago. Now before you get your knickers in knot, we will at least release an interim patch to get folks back on track. However it will take some time for us to fully regress any changes before releasing an “official” update. The problem is, as Danny stated, we simply don't know at this point what the correct fix should be. The worst thing we could do at this point is to bow to all that borland.public.delphi.non-technical pressure and rush a fix out the door. We need to step back, take a deep breath, and attack the problem calmly. We certainly don't want to make the situation worse. I recommend to all those folks that seem to be using this as an excuse to break out the flame-throwers, to take that same tactic. Slow down and take a deep breath. There is truth in the old adage, “haste makes waste.”
For all those that attended Borcon, and esspecially those that attended the Diamondback Preview/Meet the Team session on Monday evening, what was your opinion of the format? Did you like the “fair” style format where you could walk up directly to different areas where the team members were sitting and talk directly with them. What about the “blip-vert” demos prior to the breakout? As a data point, I've already gotten some feedback that it was very well received. I think we'll probably keep that format for the next few years at BorCon (depending upon how many of the engineers we can drag to the conference and where it takes place).
I just completed my second iterration of my What's New in Diamondback presentation. I was pleased that a whole new crowd showed up. That gave me a chance to cover all my favority bits of Diamondback (read: the bits I worked on ;-).. I went over the resurrection of the VCL floating designer, true drag-n-drop development (you can now actually drag a component from the tool palette onto the form). The IDE now again also supports multiple editor windows as before. The ASP.NET and WinForms designers remain embedded.
One of my favorite features is called SyncEdit. If you've ever used recent versions of JBuilder, you have probably seen this feature. Basically you select a block of code and and a little button appears in the gutter indicating that SyncEdit mode is available. When you press the button, the Editor changes modes by highlighting the block a little differently, parses the marked block and highlights all the common identifiers within the block. Now when you edit one of these identifiers, all the others are also changed simultaneously. You can then press tab to move between each ident.
Then there is refactoring. This works not only within the entire project (even throughout units that are not specifically part of the project), but across projects within the same project group. For instance if you rename a public type or some other symbol in a C# assembly that is referenced by a Delphi for .NET project, and that Delphi project references that particular symbol, then it will also be refactored as well!
Lots-o-debugging ehhancements are also on the way. Better stack tracing. Better breakpoint window; added a toolbar, inplace editing of the breakpoint condition and pass counts, and a checkbox to quickly enable/disable a breakpoint. You can now also simultaneously debug a Win32 application and a .NET application within the same project group. Through a bit of finagling, you can also debug both Win32 and .NET within the same process! This is great for folks who are using a Win32 application in which the CLR is hosted. Such as the Diamondback IDE itself.
I haven't even touched on all the new ASP.NET, VCL, database, DBWeb, etc.. enhancements. For more information you can check out the various “live” bloggers that were covering the sessions as they were happening. There's probably more, but Google and Technorati haven't discovered them yet.
Nick Hodges
Robert Love
Joe White
Dr. Bob
Jim McKeeth
Marco Cantu
Craig Stuntz
Paul Gustavson
Danny has posted a good bit of information and request to all you “live” bloggers out there feverishly tapping away at your keyboard while in the middle of a presentation. He make some very good points and a couple of requests as well. Since Danny and I do actually talk quite a bit, we both agree that the “live” blogging that is taking place at this year's Borland Conference, is great and we don't want to discourage it at all. We've both been “live” blogged at each of our sessions, so we'd like to be able to use some of the blogsphere tools out there to find out who's linking to our blogs. So please make sure you include a link to the author's website or blog URL when you post your blog entry. Keep up the information flowing!
I'm sitting here in Nick Hodges' Preconference tutorial on Creating Custom ASP.NET Components in Delphi. Nick is a very engaging presenter (somewhat of an odd statement since I am sitting here writing about his talk ;-). Since I don't work directly with the ASP.NET stuff on a daily basis, I figured I could probably learn a thing or two. So far Nick is able to draw some keen analogies to how the traditional Delphi developer can view custom component construction for ASP.NET. The guts of ASP.NET component creation is quite complex, but Nick is able to break it down so that you're not overwhelmed with that complexity. Good job, Nick!
Now for the obligatory Diamondback plug ;-). Nick is using Diamondback in his presentation and so far I've only seen one case where he's had to restart the IDE, and one other case of an error dialog. And he's almost done with the tutorial. With four hours of heavy IDE usage, add in the attacking demo gremlins, it seems to be holding up quite well.
I just finished attending day one of the Preconference Tutorials at this year's Borland Conference. I attended Danny's talk about .NET 2.0 and John Kaster's talk, Overview of Diamondback. I like sitting in the back and work on my own presentation because I can also see what they've covered, guage the audience reaction so that I can get a feel for what I should concentrate on in my own talk. Looks like the IDE stuff was one of the hottest tickets. But then again maybe I'm a little biased ;-).. If you want to know what was covered in Danny's talk this morning, Nick has a great summary of all the hot bits. I'm almost done with my own slides and was able to pare them down to under 50. I will probably do more demos in between a lot of the slides. I still don't know if 1:15 is enough time. John Kaster was unable to get through even half of his 218 or so slides in the four hours of his precon tutorial! So if you're at the conference, I may have to split my one talk into a part I and a part II. I'm scheduled for a repeat on Wednesday, but may have to use the Wednesday talk as a continuation. This all depends on the how well things go Monday. I'll try and post again tomorrow, once I decide who's talk to crash and heckle ;-)
We're currently scrambling to complete all those last minute details you always forget in preparation for this year's Borland Conference. I'm finalizing the slides for my presentations, “What's New in Diamondback.” By all counts this is going to be one memorable conference. I hope to be giving some daily updates regarding the conference. Maybe even post some photos.
The following was posted by Roy Nelson as a way to get Delphi 8 back up and going with .NET 1.1 SP1. Please note that this is a “shotgun” fix and has not been verified by Borland QA, so your mileage may vary:
1) delete all *.dc* (BUT just make a copy of your $(BDS)lib BEFORE deleting all the *.dc* files)in the $(BDS)lib dir and $(BDS)libdebug dir (do not touch the other files eg. .resource, .res and .nfm files)
2) go to the $(BDS)source dir and run the makefile file with "default" and "debug" options.
So from command prompt in the $(BDS)source dir you run
"make default debug" (without the quotes)
3) delete all old *.dc* in you project dir and re-build.
4) in VCL projects you might still see issues but all you need to do is remove the references to the VCL assemblies in the project pane and then do a re-build of the project.
5) if you still see any compiler error, either remove the offending assembley from the references and do a re-build.
It seems that there are more reports coming in regarding SP1 for .NET 1.1. For now, I would recommend holding off any deployments for SP1 on development systems. There are several “shotgun” approaches to fixing this issue, but until we have a better understanding what the exact problem is, I cannot recommend these approaches just yet.
Is it possible to create 100% bug free software? Theoretically, I suppose it is possible. But then again, how would you know if you've actually acheived it? Design, specs, pre-conditions, post-conditions, unit-testing, test cases, metrics, audits, are all designed to mitigate the introduction of software defects. Unit-testing is designed to break down a problem into managable pieces with test cases that are tailored to that one little bit of code. The idea is that if you have well designed test cases that thoroughly cover a particular domain and all those tests pass, when you begin putting all these pieces together, you run less risk of introducing more defects because each “unit” is solid. This philiosophy is core to XP (Extreme Programming).
I'm not going to try and burst any bubble surrounding XP as I agree with many of its tenets. What I am going to do, however, is try and and least poke at the myth that it is possible to achieve 100% defect free software. Given enough time and resources, I think you may be able to reach 99.999999...%, but there is no way to really know whether or not you've reached the panacea of 100%. I'm talking on a macro level here folks. Systems that are reasonably sized, not some dinky sized program that does nothing but spit out “Hello World” and terminate. Let's say a normal application has upwards of 1000 “units” (I'm not talking “units” in the Delphi sense, but the minimum testable block of actual code). Complex applications may be 100 times that size. As you begin to assemble these “units“ you are multiplying the permutations of both input data and output results. There are also the unforseen interactions that take place when two pieces are brought together. Just like some chemicals react violently when mixed, you can have these various “units“ come together and create some pretty wierd and wonderful smells and colors. Design and architecture is most definately needed in order to mitigate the chances of a meltdown. But then again, it is those pesky humans who dream up these designs and architecture. This is also where another recent methodology, patterns, is gaining favor... but that is a topic for another time...
What I think happens when folks tout the 100% defect free mantra, they completely miss the human factor that is involved. Bottom line is this; Humans are not perfect and will make mistakes. They also miss the practicality and marketability of such a system. There is a delicate balancing act. The customer says, “I want the software I use to solve a problem and operate as specified or as I expect.” Those same folks also want as many features as possible to make they're life easier when using the software. Where the balancing act comes in is with that one thing all of us have the same amount of; Time. The software producer wants to minimize the amount of time it takes to get their goods to market in order to gain or maintain a competitive advantage. The customer also wants a timely release of the software because the sooner they can use it the sooner they themselves can begin to become competitive. Schedules, Feature lists, deadlines, etc.. all serve to push a product out the door, whereas defects are the opposing forces that serves to push the delivery in the opposite direction. The difficult part is knowing when to press harder on the accelerator and when to put on the brakes.
This is where experience, intuituin (yes, I said intuition...), and solid metrics all come together to help you make those critical descisions. One factor in determining what defects to focus on fixing and which ones to let slide come from understanding your customers in a broad sense. Given a particular defect, we can use the previous tools (experience, intuition, metrics, etc...) to determine a defect's “surface area.” The “surface area” of a defect is a somewhat subjective combination of the severity of the defect, its location, frequency and a smattering of other metrics thrown in, including a subjective risk metric and the current point in the delivery cycle. Suppose in your testing phase you encountered a defect that occured each time you open a file? Suppose opening and processing files is one of the primary functions of this application. It is very likely that nearly all users of the application will encounter this defect. Suppose this defect is that it injects random data into the file when it is opened. The location combined with the severity and the frequency all combine to create a very high “surface area” defect. On the opposite end of the scale, suppose there is a defect that only occurs when certain rare operaions are performed on a file and ojly if that file contains a sequence that is encountered in a statistically miniscule number of files. One could easily conclude that this defect, while it may have a very high severity (say, it causes file corruption), in all it has a relatively small “surface area.” No, we don't actually grab our calculators and begin feeding values into some magic formula, but rather it is a mental excercise that usually takes place whithin a small group, ranging from two-ten people. Making any change to the code also carries a certain degree of risk. Changing a commonly used routine can carry a very high risk because of the potential for wide ranging destabilization. This risk also increases in a somewhat inverse geometric proportion to the remaining time on the schedule.
“OK Bauer! Where are you going with all this?” There has been a lot of interesting discussions out on the borland.public.delphi.non-technical newsgroup about the disposition of all the defects reported in Quality Central. They range from “Just fix everything reported in QC” to “Let's vote on the ones that hurt us the most” to “Borland ignores QC” First of all, we do frequently “mine“ Quality Central for defects. Many of them are transferred to our internal database (yes, they remain tethered). All this data is used to help us determine the relative “surface area” of a given defect. If we notice that it came from QC, that metric is used in these mental calculations. Believe it or not, we have even been known to factor in data gleened from just lurking through the various Borland newsgroups. In fact this should be evidenced by the fact that Steve Trefethen, recently made a request for someone to gather together a list of defects from QC. He even posted a detailed feedback message stating that some of the bugs have now been fixed and will be available in the next Delphi release (shameless BorCon plug here..).
“You bozo! That doesn't help me now!” Sadly, you're right. But then again, if you'd followed along to this point you'd have seen that there are a lot of factors that go into deciding what we fix and what we don't and why. Then there is also the fact that we can't fix what we don't know about. Also, QC is not the only metric we use in determining what features to implement and what defects to fix. Those are the drawbacks to having a publically available database. There also tends to be a mob-mentality. The positive side of a publically available database, especially one that allows commenting and voting, is that it tends to self-regulate. The community as a whole can help weed out all the random cruft that will inevitably fill the database.
“I don't want excuses, I just want my bug fixed!“ This may all sound like I'm standing on my soapbox and telling you all how rough we have it... OK may be I am a little, but hey, it's my blog after all ;-). I just see that there seems to be a small vocal subset of people who like to cast stones. Perspective plays a huge role here. To many folks, it is just this one little bug, it shouldn't take that long, right? Many times a bug fix takes much more time to research its impact than the time it takes to apply the fix. We have to evaulate a fix not just in terms of a given test-case, but also figure out if there are other similar cases that this fix can address, or if it will have a negative net effect on the product.
It has also been commented that the QC bugs should take a higher priority that internally reported bugs. While it seems that would be the best move politcally, many times it would simply steal time away from other more critical, higher “surface area“ defects. “Then just delay your ship dates.“ Here's a very sticky one... While there have been releases in the past where ship dates are dictated to the team and we had to make those dates and clean up the bodies later, that hasn't been the case recently. While we are still given guidelines and target quarters, we for the most part control our own schedule as a team. Make no mistake, there is still a schedule that is communicated to many other teams. They must know this information in order to align their groups' work to match our team's schedule as closely as possible. Groups such as marketing and sales need to know with a high degree of certainty when we'll release the product. All of these are factors that go into determining the “surface area“ of a defect. We could argue for days on the relative weight of each factor in the “surface area“ calculation. But the bottom line is that we have a lot of very experienced people that understand and know the product down to the individual lines of code that know how to make these determinations. Do we make mistakes? You bet we do.
You can take away what you will from the above meandering drivel, but I'd like to think that most developers who uses our products for producing market driven, (internally developed and used software also has a “market”) software has had to make these same determinations regarding a defect's “surface area.” You've also had to factor in schedules and deadlines when determining this information.
Again, you should really try and attend this year's Borland Conference where you'll hear about the next Delphi release, codenamed, Diamondback. You'll also begin hear about our [Borland's] roadmap. You can bet that Delphi is going to be a critical part of Borland's roadmap.
This is very interesting... Apparently this person was fired from Friendster for blogging. http://troutgirl.com/blog/. Danny wrote a nice little comment about the potential blogging ramifications over here. Note that neither Danny nor myself actually provided a direct link to Friendster. I, at least, don't want to drive any traffic to their site. I suppose you could say that is what we think of that.
