My best code is written between the hours of 7am and 10am. I typically get to work at 7am and don't see anyone in the office or have any meetings until 9 or 10am. But I'm a morning person so that probably goes without saying. What time of day is your best code written?
Tuesday, March 27, 2007
Over at the CodeGear Job listings I wanted to point out that we are in search for a Publication Engineer. Of course we are also looking to fill other positions, but I really want to find someone for this position so we can make our documentation better. If you are interested then send your resume in.
I have been tagged by Chee Wee to write 5 of my favorite things in Delphi 2007.
1. Lots of bug fixes!
2. An F1 key that actually works. This includes the entire process behind the documentation as well. If you run into any cases that don't work please file a bug in QC and let me know about it.
3. The fact that Delphi 2007 is completely backwards compatible with Delphi 2006. This means all components built with Delphi 2006 don't need to be recompiled and IDE plugins should all just work! This is the first time this has been done and while there are a lot of changes that I'd like to make to VCL and the IDE that would have broken backwards compatibility I think this is an important feature.
4. It is fast. It reminds me of Delphi 7 only with more cool editor features. Since Delphi 7, this is the first version I'm installing at home. That's how much I like it!
5. And the best for last. All of the community projects and Delphi built applications that were created because Delphi existed but have been used to make a better Delphi. By shipping using the FastCode string comparison routines. With these Changes we have seen 100% performance increase, or 50% decrease (whichever way you want to look at it) when building with a version of Doc-O-Matic that has been built with Delphi 2007.
Saturday, March 24, 2007
If it's funny you have to laugh. A few months ago I posted the new Apple commercial with Vista which wouldn't have been so funny if it weren't true. Well here are two commercials by Novell that are Pro-Linux.
Friday, March 23, 2007
As I've stated earlier, in a four part series about the new help, the help system is now built using Doc-O-Matic. Chris White and I are working with Markus Spoettl of toolsfactory where we decreased the built time of our help from more than 12 hours to just over 3 hours. Recently Marcus upgraded from Delphi 2005 to Delphi 2007 and sent us the new version of Doc-O-Matic and we noticed the built went from just over 3 hours to about 1.5 hours! That is over a 50% increase in performance. As it turns out there were a few performance enhancements made between Delphi 2005 and Delphi 2007. In Delphi 2006 we started shipping with the popular FastMM decreasing memory fragmentation which is a huge benefit when loading 30,000 XML files. And now in Delphi 2007 we ship some of the super popular Fastcode string comparison routines! This is simply awesome!
Posted by Chris Bensen at 10:00 AM
Thursday, March 22, 2007
Sometime around Delphi 6 and C++Builder 5 there was a change made to Automation Servers (components written as an EXE) where they would automatically register themselves. This caused all sorts of problems for Vista UAC and just wasn't the correct thing to be doing. So for Delphi 2007 the code for Automation Servers to automatically register themselves has been removed. You are now required to run your Automation Server with the /regserver option. Example: "MyAutoServer.exe /regserver".
Tuesday, March 20, 2007
Add another CodeGear R&D Engineer, Seppy Bloom, to the blogging masses. Seppy has some great insight to share about VCL and the new Vista features found in Delphi 2007 for Win32. Keep an eye out for some good information to start getting posted to his blog.
Friday, March 16, 2007
As you all (probably) know we've been putting in some very late nights and early mornings working on the finishing touches for Delphi 2007. Everyone has been drinking lots of extra coffee, hot chocolate, tee and soda just to stay awake. I guess this didn't have the desired affect management was looking for so David I brought in a crate of Twinkies. Seriously, at least 30 boxes. I don't know what happened but I came in yesterday morning to find my neighbor David Lock crowned Twinkie
Boy King! Now they are even easier for people to get to as they walk by reach hand out and grab. No more walking ot the break room and bending over to pick up the unsuspecting Twinkie. Around hear I hear Ho-Hos are better than Twinkies. What's your favorite snack?
Posted by Chris Bensen at 7:42 AM
Wednesday, March 14, 2007
Earlier today we had the CodeRage session on the Delphi 2007 Documentation where we had a few questions if there is documentation on Open Tools API and 3rd party help. I wanted to take this oportunity to mention that we do look in QC for what developers want to see in future versions of Delphi. So if there is a help topic that you don't see or would like more information on go to QC and enter a new request or vote on an existing one.
Posted by Chris Bensen at 5:00 PM
Tuesday, March 6, 2007
There are three primary pieces to help; the help viewer, the action of invoking the help from the IDE, and the glue between the IDE and the help viewer. If you press F1 and don't get help, is the IDE failing, is the content not written, delivered or found, or is the glue between the IDE and help viewer failing?
Testing is one of the most difficult tasks of the documentation process. As is typical with testing, more can always be done. Currently we have tests that test pressing F1 on all the components, all the properties and events of each component in the object inspector, errors, messages and warnings in the compiler message view and most dialogs. Each page that is displayed is tested to see if the title is what was expected to hopefully provide more accuracy to the content. I say "hopefully" because there really is no guarantee without sitting a human down and having them press the F1 key and read the content that is displayed in the help viewer. What we are looking for here is do we get a reasonable page.
But what makes our reference documentation so difficult to test is sometimes you really don't get the page that you expect. For example, create a default application with the following:
TForm1 = class(TForm)
If you press F1 with your cursor over TForm1 you will still get help even though it is a class only defined in your application. The help will be for TForm. I'll discuss more about this in Part IV, but depending on where you are in the IDE the RTTI and compiler are used in conjunction with the help function ContainsHelpKeyword. So the results when you press F1 may vary. Well, they won't once the help is locked down and isn’t changing, but while the help is being written they may vary.
I have also been working on a unit test for interaction between the help viewer and the IDE for testing the glue code that binds the two. This test consists of the help code in the IDE as a stand-alone application that can interact with the help viewer. Given a list of keywords and context IDs we can inspect the help to make sure those individual pages are present in the build help. This also allows us to test a help build quickly without loading the IDE to make sure our changes worked or not.
Also for obvious reasons we rely on humans to make sure the content is accurate. Kudos to all you field testers and developers out there using Delphi. Thank you for all your bug reports!
Monday, March 5, 2007
One of the exciting things about CodeGear is the ecosystem that has been built up around. The C/C++ compiler is used build the C/C++ compiler. The C/C++ compiler is used to build the Delphi compiler. Delphi is used to build the IDE (sure the IDE is also built with C/C++, C# and J#, but it primarily is Object Pascal). Then all you Delphi customers out there build all the fabulous products and plugins like Doc-O-Matic and InstallAware that we are able to use to build more Delphi! There are of course other cool applications like Skype.
I know I'm leaving out a whole laundry list of applications written with Delphi. These were just the first few that came to mind because I was using them today.
The translation process is a lot of work. If you start thinking about it and all the permutations and possibilities you can go mad. Especially in a system where anyone can author content in any language.
The old system we had in place took a lot of human processes which is prone to errors. So I wanted to go with a very simple straight forward system. We initially write our doc in English and translate it to German, French and Japanese. The system also needs to be extensible for Piglatin and Klingon. In previous releases the documentation was locked down two or more months prior to shipping then sent out for translation. This cycle we are doing simship, which means everything must be done at the same time or have very little lag behind the English version. One of the luxuries the translation team had was they had more time to fix bugs. This means that the doc was out of sync with the English versions which caused me a lot of headaches for comparison reasons. One of the things I do is compare the structure of the XML files to make sure that same file in all four languages is the same. I keep around MD5 hashes of each one so I can compare and know if one changed. Since we are now using subversion new possibilities have opened up because we can ask subversion about the files in the repository and add properties to each file.
The most important tool I've written generates translation packs. Translations packs are bunches of English XML files that are sent to a translation agency and come back in German, French, Japanese, Piglatin or Klingon. The main goal of this tool was that I didn't want to run the process, so it needed to be something easy. One button and a progress bar is always simple to use so I dropped a button on the form, added a progress bar and a memo for errors/warnings, double clicked on the button and started writing some code. The process when the button is clicked is pretty simple:
- gather all the .xml files in the repository
- remove any files that are in a not to be translated list (this is an override list)
- remove any files that weren't modified
- remove any files with the subversion property of translate=false
- force include any files with the subversion property of translate=true (if found then remove it, only want to force include once)
- zip the new files up into a .zip file
- zip the modified files up into a .zip file
At the moment there is no process for tracking each file through the system to make sure it gets translated. That is on the list of things to do along with finding an agency that can translate into Klingon.
Posted by Chris Bensen at 10:00 AM
Friday, March 2, 2007
Copyright © 2007 Chris Bensen. All rights reserved.
Even though we are working on the next version of Delphi I like to get out when I can and take some photos. Here is a photo I took at Natural Bridges State Park in Santa Cruz. The tidepools are amazing there. If you ever get a chance try and time a low tide with sunset and go to Natural Bridges tidepools, you wont regret it!
Thursday, March 1, 2007
Just today I was brought in to investigate a bug where midas.dll wasn't registering correctly when registered with "tregsvr midas.dll". The problem was on a fresh system a new Remote Data Module couldn't be created because the COM subsystem couldn't find IAppServer registered in the registry. IAppServer is an interface in the Midas type library. It turns out that midas.dll was changed for updates to Delphi 2006 Update3 and Delphi 7 (not sure which update version) and this bug was introduced. You can test this by running "tregsvr midas.dll" on a clean system and searching the registry for IAppServer. You can solve this problem by running both "tregsvr midas.dll" to register the information required to do a CoCreateInstance, and also running "tregsvr -t midas.dll" to register the type library.