- Instant File Initialization – Killer Feature for SQL Server
- RAD Studio 10 Seattle Update 1 Available
- Bug fix list for RAD Studio 10 Seattle Update 1
- Delphi Blogs of the Week/Month #35
- More on ARC, Weak References, and Unsafe References in Delphi Mobile Compilers
- SQL Server Index Fragmentation In-depth
- A Look Back at PASS Summit 2015
- FireMonkey Paint Canvases
- IDE Fix Pack 5.94 released – RAD Studio 10 Seattle support
- October 2015 XE6 Hotfix Available
- Speaking at EKON 19 Next Week
- Running Delphi Applications on Android Intel
News, Blogs, and Tips
As I already blogged on the Embarcadero community site at community.embarcadero.com/blogs/entry/2015-rad-studio-delphi-and-c-builder-developer-survey, the 2015 edition of the yearly RAD Studio, Delphi, and C++Builder developers survey is available and will remain open 10 days, until August the 28th. The survey has 100 questions divided in 18 pages and we estimate it can take 30 to 45 minutes to take it.
This is the link:
In case you don't have time to go over all sections, you can skip a page, as only a limited numbers of questions require an answer to continue. In this case, please complete the pages you are most interested in. Of course, we'll appreciate if you have time to complete all pages.
We know your time is valuable and so we greatly appreciate your participation in this annual survey, which will significantly affect the product development and planning for the next 18 months. There are also new questions this year to help us better understand how you are using the product.
Here is an overview of the process the RAD Studio team uses for processing bugs reported by customers, and the current status. Over the recent years, the effort in fixing bugs and issues reported by customers has increased significantly. We have numbers from our internal bug tracking system that can shed some light.
Before we get to those numbers, however, it is important to understand how the RAD Studio team tracks and manages bugs, how they are categorized and processed. I won’t get to the details, but an overview will help explain the rest of the story.From Quality Central to Quality Portal
For many years, the customer-facing tool for reporting bugs was hosted as Quality Central at http://qc.embarcadero.com. This was an internally developed bug-tracking tool that mapped to the internal bug tracking system, RAID. It is still there, but don't use it any more.
Over the years, RAID was replaced with an instance of Atlassian Jira (https://www.atlassian.com/software/jira), and Quality Central was remapped to it. Since last year, the team introduced the new Quality Portal (http://quality.embarcadero.com), which is also based on Jira but has different configurations and settings. The current flow from Quality Portal to the internal system and back is very smooth and it is significantly improving the communication between the team and customers reporting bugs.Bugs Flow and Status
The second information worth knowing, before looking to the actual data, is the flow up bugs and their status over time. For this, I’m considering the current system (there were differences in the previous combinations).
When a bug gets reported, it is copied in the internal system and is validated by a QA (Quality Assurance) team member. He might open it and send to the proper developer, close it because it is not considered a bug but the expected behavior, a “test case” error, close because it cannot be reproduced, open it as a feature request for future consideration, ask for more information to the bug reporter, close it as duplicate of an existing issue… and a couple of other scenarios.
At that point, if the bug is open, it is assigned to a developer, who can provide a fix for it, but also suggest a temporary workaround, can decide this is expected, or suggest merging it with future work. An individual developer doesn’t actually do this process alone: There are team meetings, “bug council” meetings, and many steps to access and re-evaluate over time the priority of issues.
There are a couple of further considerations here. The first is that when a bug is closed internally, its status is not immediately reflected in the public system. The reason is simple: Telling a customer the bug is closed but he or she cannot get the fix would be of no value. The bug is marked fixed in the public system when a fix including the bug is released. This is why in the public system there are huge spikes of fixed followed by periods in which it seems nothing is done. The internal system, instead, tells a more complete story.
The second consideration is that a significant number of bug reports that are not considered “errors” in the current implementation, but requests to extend a given capability are kept in the system. While internally tagged as “feature requests” they stay open and look like bugs not being addressed. In theory we could close them indicating the feature works as "currently" designed, and open a separate internal request for enhancements.
The last and final consideration is here we are looking to publicly reported bugs, but you have to consider that the majority of bugs is reported internally by the QA team, other developer, or internal users (incuding myself). Our goal and more consistent effort, of course, is to fix bug before the software is released. So the internal numbers tells a different story, but for this blog post we are focusing only on bugs reported by customers.Let’s Get to the Data
With this picture in mind, I’ve recently dug some data and some graph that help understanding the current status and the extra effort done recently on RAS Studio quality.
Faster Resolution Time. The first graph shows the yearly average resolution time over the last 4 years. This is how many days it takes on average to resolve an issue. Thinks are improving significantly, I’d say.
70% of Reported Bugs Have Been Solved. If we consider all bugs that have been reported over the same time frame (from 2012) and came from customers, we get a real picture of the effort. If you add closed and resolved issues, it’s a 71% of the total. Many of the re-open issues are also partially closed (they might not be optimal or complete solutions). Also among the open issues there are 279 (at a recent count) marked as feature requests, which brings the real number of open bugs further down.Conclusion
There is certainly much more information we can dig in our system to show how many publicly reported bugs have been fixed over time in the various product areas. The new public bug tracking system is also making it easier to follow the bugs status and it’s ensuring a better communication between customers, quality assurance team, and development team.
The RAD Studio team is focused on further improving the process and devoting more resources in fixing issues. The trends have been encouraging, but this doesn’t mean we think our effort is good enough and we are going to stop here. On the contrary, we see a positive trend and want to keep focused on that direction, increasing the timeliness of bug fixes, their numbers, and (which is what really matters) the overall product quality.PS: Clarification on Closed Vs. Fixed Issues
Some of the comments (including a few I didn't approve) hint to the fact that not all "fixed" issues have been specifically addressed by the team, given some might have been duplicate or coud have ended as being considered "test case errors". So I dug some extra information. Out of that bucket of closed bugs, over 3,200 individual and distinct issues have been fixed with actual changes in code. Wiht is roughly half of all of the issues that have been addressed.
My latest book, Object Pascal Handbook, is now available in print on Amazon and other outlets. I finished the book 2 weeks ago, got my proof copy earlier this week, and given it was good, I gave it the green light. The book, in fact, is self-published through CreateSpace, where it is available at www.createspace.com/5559999 (this is the online store I earn more from, but Amazon is also quite good on margins).
On the Amazon.com site the book is www.amazon.com/Object-Pascal-Handbook-Marco-Cantu/dp/1514349949 (and already selling, given it is going up in places in the "Langauges and Tools" category under programming). You can buy it also from the UK site (www.amazon.co.uk/Object-Pascal-Handbook-Marco-Cantu/dp/1514349949) and the German one (www.amazon.de/Object-Pascal-Handbook-Marco-Cantu/dp/1514349949) in which case I understand they print the book in Europe and ship locally. Other Amazon stores should have it, and other non-Amazon sites should get it as well in the coming weeks.
Cover price is 46.50 US Dollars, 31.50 UK Pounds, 43.50 in Euro (but Amazon has it a little higher). The final book is well over 500 pages.
More information is at www.marcocantu.com/objectpascalhandbook/ although I still need to udpate that page with the buy links, the complete TOC and the index, and more information. Should be done in the coming days. Along with sharing more of the source code of the demos.
The ebook remains a free download for XE7 and XE8 registered users, and should be updated with the complete version (3 more chapters from the last draft) shortly. I'm considering making it available as a paid ebook as well, but not immediately.
For all developers that got stuck at Delphi 2007 and who want to upgrade to Windows 10 can now use the special “Windows 10 Edition” of IDE Fix Pack 4.4 for Delphi 2007. The “Windows 10 Edition” also supports Windows 8.1.
Requirement: Delphi 2007 December Update.
Name IDE Version File Size Downloads Added IDE Fix Pack 2007 4.3 (may work with Windows 8) 2007 IDEFixPack2007Reg43.zip 59.74 KB 5392 times 2011-08-20 IDE Fix Pack 2007 4.4 (Win8 is not supported) 2007 IDEFixPack2007Reg44.zip 61.85 KB 11175 times 2011-08-28 IDE Fix Pack XE2 4.5 XE2 UP2 only IDEFixPackXE2Reg45.zip 125.47 KB 2311 times 2011-11-02 IDE Fix Pack XE2 4.6.6 XE2 UP3 only IDEFixPackXE2Reg466.zip 152.4 KB 3561 times 2012-01-04 IDE Fix Pack 2007 4.4 Windows 10 Edition 2007 Dec.Update IDEFixPack2007Reg44Win10.7z 88.51 KB 1098 times 2015-08-04
Those who tried to use IDE Fix Pack on Windows 10 got the uncritical error message “failed: Faster IDE startup [IDE.Startup.Fast]” that appeared on every IDE start. The problem is that a byte sequence changed that IDE Fix Pack tries to find. Windows 10 uses “INT3” instead of “NOP” instructions to align functions and IDE Fix Pack 5.92 and earlier looked for “NOP”. The new 5.93 now allows both instructions.
IDE Fix Pack 5.93 only adds support for Windows 10 otherwise it is the same as 5.92.
For the next IDE Fix Pack I’ll work on the Delphi Win64 compiler’s performance. (not the generated code)
Name IDE Version File Size Downloads Added IDE Fix Pack 5.94 2009 (UP4) IDEFixPack2009Reg594.7z 179.96 KB 7 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) 2010 (UP5) IDEFixPack2010Reg594.7z 176.29 KB 5 times 2015-11-01 IDE Fix Pack 5.94 XE (UP1) IDEFixPackXEReg594.7z 162.23 KB 8 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) XE2 (UP4+HF1) IDEFixPackXE2Reg594.7z 236.08 KB 9 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) XE3 (UP2) IDEFixPackXE3Reg594.7z 190.48 KB 6 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) XE4 (UP1) IDEFixPackXE4Reg594.7z 192.67 KB 4 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) XE5 (UP2) IDEFixPackXE5Reg594.7z 191.81 KB 8 times 2015-11-01 IDE Fix Pack 5.94 (unsupported) XE6 (UP1) IDEFixPackXE6Reg594.7z 322.4 KB 7 times 2015-11-01 IDE Fix Pack 5.94 XE7 (UP1) IDEFixPackXE7Reg594.7z 334.91 KB 11 times 2015-11-01 IDE Fix Pack 5.94 XE8 (UP1) IDEFixPackXE8Reg594.7z 331.97 KB 13 times 2015-11-01 IDE Fix Pack 5.94 D10 IDEFixPackD10Reg594.7z 334.77 KB 23 times 2015-11-01
Name IDE Version File Size Downloads Added fastdcc 5.94 2009 (UP4) fastdcc2009v594.7z 77.29 KB 2 times 2015-11-01 fastdcc 5.94 (unsupported) 2010 (UP5) fastdcc2010v594.7z 84.28 KB 1 times 2015-11-01 fastdcc 5.94 XE (UP1) fastdccXEv594.7z 86.14 KB 3 times 2015-11-01 fastdcc 5.94 (unsupported) XE2 (UP4+HF1) fastdccXE2v594.7z 111.79 KB 3 times 2015-11-01 fastdcc 5.94 (unsupported) XE3 (UP2) fastdccXE3v594.7z 121.67 KB 2 times 2015-11-01 fastdcc 5.94 (unsupported) XE4 (UP1) fastdccXE4v594.7z 125.38 KB 1 times 2015-11-01 fastdcc 5.94 (unsupported) XE5 (UP2) fastdccXE5v594.7z 124.31 KB 3 times 2015-11-01 fastdcc 5.94 (unsupported) XE6 (UP1) fastdccXE6v594.7z 153.28 KB 3 times 2015-11-01 fastdcc 5.94 XE7 (UP1) fastdccXE7v594.7z 164.01 KB 4 times 2015-11-01 fastdcc 5.94 XE8 (UP1) fastdccXE8v594.7z 164.57 KB 5 times 2015-11-01 fastdcc 5.94 D10 fastdccD10v594.7z 164.58 KB 10 times 2015-11-01
- Added: Support for Windows 10
- What is the Delphi component that you can’t live without?
- The on demand replay for the "Extreme Cross-Platform .NET with Delphi Prism 2011" webinar is now available at http://forms.embarcadero.com/forms/AMUSCA1006DelphiPrism20116-2.
- I’ve always been a big Jeff Duntemann fan, because he’s a great writer, an interesting guy, and because he’s been a Pascal/Delphi fan from way back. (I was honored when he sent me an autographed copy of his excellent The Cunning Blood – a book I thoroughly enjoyed – back when the new Turbo products were released.) Anyway, Jeff has a new collection of short stories out called Cold Hands and Other Stories. You can get it on lulu.com – my favorite place to buy books.
- The US Geological Survey built it with Delphi.
If there is a bedrock, bottom line, everyone-should-follow-it-all-the-time rule in programming it is “The DRY Principle” – Don’t Repeat Yourself. This simple rule states that you should write code once and only once, and that you shouldn’t allow the same code to be used all over the place. Or, as the Wikipedia article deftly states: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." Put more simply, it means that you shouldn’t have the same thing repeated all over your code, but that you should create a single identifier and use that in the many places where it might be needed.
As a practical matter, the DRY principle in its most basic form tells us that we should, as a matter of course, not use literals in our code, but instead should declare constants (or resourcestring types as we’ll discuss in a minute) and use those instead. That way, if you need to change the value for something, you can do it in a single place instead of having to make multiple, error-prone changes throughout your existing code.
For example: Say you have a system that has an arbitrary number of required repetitions, say 17. You might end up writing a whole bunch of code like this:for i := 1 to 17 do begin ProcessStuff; DoSomeMoreStuff; end;
Now imagine that you have that kind of code all over the place, and then your boss comes around and says "Hey, we need to repeat all that stuff 18 times now, not just seventeen.” Well, if you haven’t followed the DRY Principle, you could very well end up with a lot of code to change. And don’t use search and replace, because what if you change the 17 that is part of a variable name or something? Things could get ugly fast.
Of course, the thing to do is to declare a constant:const NumberOfRepetitions = 17;
and declare your loops asfor i := 1 to NumberOfRepetitions do begin ProcessStuff; DoSomeMoreStuff; end;
and now when your boss switches things up, you have but one simple change to make, and all is well.
Now this is a pretty simple, basic thing to do, but I’m constantly surprised at how often I find myself forgetting to do it. (For instance, if you look through the code for TextScrubber, you’ll probably notice that I need to apply the DRY Principle to the TVersionInfo constructor in uTextScrubberTypes.pas.) You might be surprised how many literals you use in your code. I often take advantage of the syntax highlighting feature to scan code for specific colors for strings and numbers and replace them with constant values as much as possible. For instance, some code from TextScrubber used to look like this:procedure TStraightTextMainForm.InitializeMainFormInformation; var IniFile: TIniFile; begin IniFile := TIniFile.Create(IniFileName); try TextScrubberOptions.ClickChoice := TClickChoice( IniFile.ReadInteger('Options', cClickChoice, 0)); TextScrubberOptions.ShouldTrim := IniFile.ReadBool(cOptions, 'ShouldTrimText', False); finally IniFile.Free; end; end;
with a bunch of string literals. Instead, now, I’ve declared two constants in the uTextScrubberConsts.pas unitconst cOptions = 'Options'; cClickChoice = 'ClickChoice'; cShouldTrimText = 'ShouldTrimText'; cVersionLangCodePage = '040904E4';
and the new code looks like this:procedure TStraightTextMainForm.InitializeMainFormInformation; var IniFile: TIniFile; begin IniFile := TIniFile.Create(IniFileName); try TextScrubberOptions.ClickChoice := TClickChoice( IniFile.ReadInteger(cOptions, cClickChoice, 0)); TextScrubberOptions.ShouldTrim := IniFile.ReadBool(cOptions, cShouldTrimText, False); finally IniFile.Free; end; end;
Those constants are also used when I write out information to the INI file, so that I can change the value in one place if I need to, and so that I can know that there won’t be any typographical errors in my strings that will cause a bug. The same string value is always going to be used for the INI file entry.
Now let’s take a look specifically at strings. Strings are a bit special because they are very often used to communicate information, and as such, they frequently need to be translated into other languages through the process of “localization”. Windows provides an easy way to do this via string resources, and Delphi provides an easy way to create string resources via the resourcestring identifier. These strings are then created as resources, making them easy to translate. And “easy to translate” can often be, well, translated into “cheaper to translate” and that is a good thing.
Practically speaking, I apply this principle by placing as many const and resourcestring declarations as I can in a single file, thus centrally locating them for easy management and translation. In our case with the TextScrubber project, I’ve created a file called uTextScrubberConsts.pas and put constants and resource string values into it. If you look through the project code, you’ll probably notice that I need to apply the DRY Principle to the TVersionInfo constructor in uTextScrubberTypes.pas, even if it is keeping those constants within the unit.
One question that might get asked is “How do you choose what to make a const and what to make a resourcestring?” My answer is that as a general rule, any string that could change without changing the UI or the functionality of the code, make a const. Any string that, if changed, will trigger a change in UI or translation should be made a resourcestring. There are exceptions to that, of course. More simply, a rule to use that anything that might get translated should be a resourcestring.
Now, this is a pretty simple “pretty good practice” to follow, but for you folks who have not been following this principle, simply doing so can make your code more readable and maintainable.
- One of the cool features of Delphi Prism 2011 is the built-right-into-the-language support for Aspect Oriented Programming (AOP). John Moshakis has a nice blog post giving an example of exactly the kind of things that Aspects can to do make your code cleaner and easier to maintain: providing a data and domain object validation aspect. And he demonstrates it in a Silverlight application and using MVC. All in Delphi Prism. Which you can buy right now. Cool. I tell you, it’s never been a better time to be doing Delphi Programming.
- By the way,I am now making it my personal mission to put the phrase “DelphI Programming” into every one of my blog posts.
- If you are really into Delphi Programming, and would like to gain some insight into your code, you might be interested in the special reduced price being run by the folks at Peganza for their Pascal Analyzer 5.
- Yea! More Delphi Code Golf!
- The topic of newsgroup participation came up in our Delphi.non-technical group, and I mentioned that it appears that more people seem to be using StackOverflow to get answers to their questions. Craig Stuntz turned around and in his own inimitable way, proved that such is the case. I know that I check StackOverflow a couple of times a day, and try to make modest contributions. I endeavor to vote for good answers and to give good answers when I can. The cool part is that if you are only interesting in Delphi Programming questions, you can really make it “DelphiOverflow” by simply paying attention to the correct tags.
- Speaking of stuff on StackOverflow, Robert Love pointed out something I hadn’t seen before on there: Code-Golf. This is a question that asks a small development problem, and then folks post their answers in their favorite languages using as few characters as possible (low score wins, like in golf). Kind of fun. Robert threw in a Delphi answer for this question, and he inspired me to post my own Code Golf problem. So, if you are so inclined, I’d love to see a Delphi solution, though I’m sure it will be tough to compete with some of the command line scripting languages. Next time I’ll make the criteria be a command line EXE.
- Forgive me, but I found this quite funny. Please note the text bubble near the end. Now if she had decided to use Delphi, well, that might have been a different story. I am also reminded that Jack Bauer uses Delphi – and I strongly recommend against crossing Jack Bauer.
- I’ve mentioned that there is a new version of Delphi Prism – and one of it’s new features is the ability to put some C# code on the clipboard and paste it as Prism code. If any of you is interested in automating the process, there is a command line version of that tool available.
- Oh, and don’t worry, I haven’t given up on the “Pretty Good Practices” series. I’ve got a few drafts in the queue, but they are a bit tougher to write than the Random Thoughts items.
- Delphi Prism 2011 is now available for purchase. There are some very cool features in it, the biggest of which is integration into Visual Studio 2010 and complete support for the .Net 4.0 framework. It also includes CodeSite Delphi Prism Edition, which gives you an amazing view into your code. And here is another cool thing: Buy RAD Studio 2010 and get a free upgrade to Delphi Prism 2011.
- Delphi Programming is now at #9 with two up green arrows, and Objective-C has shot like a bullet into the Top 10.
- I think some of you have been hearing about the Tool Cloud. We have a web page that talks about it, including some PDF’s for your reading pleasure. Delphi and RAD Studio are going to become part of the Tool Cloud in the coming releases, and so you might want to check it out. Let me clear, though, that if you aren’t interested in the Tool Cloud, you don’t have to participate. You’ll still be able to get your Delphi like you always have. But if you are interested in the Tool Cloud for RAD Studio, there is a lot of interesting stuff going on there.
- Have you signed up for Delphi Live yet? We are looking forward to seeing you there.
- More good stuff from Marco about the under-appreciated (and under-utilized, even by us) Help Insight feature. For the record, I have provided copious Help Insight comments for TSmiley. I actually found it rather fun to write the comments, and I personally don’t mind them in the code and don’t view them as “clutter”. A cool IDE feature would be to “auto hide all XMLDoc comments” or something like that.
I had occasion to write a little routine called CoinFlip:function CoinFlip: Boolean; begin Result := Random > 0.5; end;
I don’t know why I found it mildly amusing. And I bet someone will tell me that it is slightly biased in one direction. Because it is. Anyway, thought you all might enjoy it, too.
- DataRage 2 is going on right now, and it is not too late to get involved.
- Delphi Prism 2011 will be generally available very soon, and Marc Hoffman has a good rundown on what you’ll get in this significant release. My favorite part is the support for VS2010 right as this new version is out. You give up nothing and get a lot with Delphi Prism.
- I thought this taxonomy of developer types was particularly insightful. Which one are you?
- Does your high school or university teach Delphi?
- Did I mention this earlier? We are conducting a survey to learn about the application development market – what are the challenges developers face as well as the technologies and tools they’re using. It’s not “The Delphi Survey”, but instead a more general survey about developers, processes, etc. We’d love your input.
- And if you are interested in the broader perspective about where Embarcadero is headed, you might be interested in this press release about our new XE line of products. RAD Studio will eventually become an “XE Product”, and so it should be of interest to you all. You can learn more about it via what is currently going on with some of the DatabaseGear tools in this video.