tag:blogger.com,1999:blog-64446092702517489542024-03-14T00:24:27.943-07:00Delphi Code MonkeyWarrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.comBlogger132125tag:blogger.com,1999:blog-6444609270251748954.post-60716857675844413552023-12-21T10:19:00.000-08:002023-12-21T10:19:31.743-08:00Dear Santa: My 2023 Delphi Christmas Wishlist<p> Dear Santa,</p><p>I have been a very good Delphi Developer this year, and I would like the following Delphi related items in my Festive Non Denominational Holiday Hoisery. </p><p>1. I would like Delphi to be able to work on my high DPI two monitor system without driving me crazy. That means having the Property Inspector draw its editor items where they belong instead of in some place that makes it impossible to use the property inspector, to alter components on forms.</p><p>2. I would like Delphi's IDE layout management system to be able to organize only the contents of the IDE window, not the top/left position of the IDE, nor which window it's visible on, because having the IDE jump around randomly among several profiles (startup, another one after projects are open, a third one after a project is running) drives me nuts. </p><p>3. I would like the IDE to be as stable as Delphi 7 was on large codebases. It's been decades and every few years, claims are made that this year's delphi is stable, finally. We were told that about every XE* release, Delphi 10, Delphi 10.4, Delphi 11, and now, Delphi 12. Still, working on large codebases means crashes, hangs and freezes.</p><p><br /></p><p>Thank you very much Santa Claus,</p><p>Yours sincerely</p><p><b><i>Delphi Code Monkey</i></b></p><p><br /></p>Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com2tag:blogger.com,1999:blog-6444609270251748954.post-13000733317586314152023-07-06T12:08:00.002-07:002023-07-06T12:08:25.214-07:00In Search of: The Ultimate Git GUI Client<p>You might thing that because of a post where I rant about Git's glitchiness that I hate git. I'm actually a pretty happy Git user, except when Git is having one of its moods.</p><p> I have been a long time TortoiseGIT user, and before that, I was a tortoise HG user, and before that, a TortoiseSVN user. In brief, the Tortoise family of version control GUIs main design philosophy is that Tortoise hooks itself deeply into the Windows Explorer. This has been both a source of its power, and a source of pain, since this original decision. The caching mechanisms it uses are part of the speed, and also part of the pain and bugs. Having Tortoise on your system means that Windows explorer (and your computer) is almost always doing work in the background to index your entire hard drive to find which folders are Git repositories and what the status of every working file in every folder is.</p><p>The good part is that once you accept the overall system issues, and perhaps slowness of your entire computer, and that you will periodically have to manage issues like the tortoise Cache needing a reset, you get always on "friction free" awareness that a file has been modified, just by looking at the icon decorations in windows explorer. This really is great. Except when it's not.</p><p>Recently, Windows 11 (my main developer workstation) started locking up when I log into my desktop, and I had to create a new user account and log into it in order to get to my desktop, which was hard to do, since Windows profile corruption was also preventing me getting to the windows desktop. I was eventually able to get a Task Manager up and to run a command prompt and launch other things, even though the Windows Explorer itself was refusing to initialize, open the start menu and taskbar, etc. The best I was able to do was figure out that this problem went away when I uninstalled Tortoise. I can't prove that Microsoft changed anything but I can say that I doubt a lot of the Explorer Shell team at MIcrosoft are checking for regressions for all the thousands of shell explorer extension API products out there that hook into Windows explorer. </p><p>While I think the folks who make Tortoise are wonderful, I can on longer trust that Microsoft will avoid touching things that have "always worked" and in Windows 11, breaking things wholesale, seems acceptable. Hiding most of the right click context menu content under a second level of right click menus, fine. If it makes some top level program manager at Microsoft happy; Hey look we simplified your Windows Experiences and made all those shell extensions (like 7Zip's one, and Tortoise, and others) just GO AWAY.</p><p>Right now the number one candidate to replace Tortoise Git as a GUI is Git Tower or Git Kraken. I'd be happy to hear comments from other people with suggestions.</p><p><br /></p>Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com7tag:blogger.com,1999:blog-6444609270251748954.post-47775685881281313802021-11-05T10:20:00.005-07:002021-11-05T10:27:45.023-07:00Windows 11, and Delphi 11 : How is it for everybody? You better move to Delphi 11 if you're going to update to Windows 11, and here's why...<p> So the future is here, Windows 11, and Delphi 11. Do you think the "everybody moved to 10 everything" and "everybody moved to 11 everything" all the same time is a coincidence?</p><p>Here's how it actually works:</p><p><br /></p><p>1. Something in the industry creates a buzz. What is it this week? Bitcoin? NFT? NFC? GUIDs? N-Tier Design? Message Queueing? The Internet of Things?</p><p>2. Everybody rushes to be "part of that". </p><p><br /></p><p>If you get hired at Embarcadero, or anywhere really, to sell anything, especially in the tech sector you'll get hauled into your bosses office regularly and someone who looks like they might belong in a Dilbert cartoon will tell you what the new thing is, that they read in their BossManagerMonthly magazine or blog, and tell you you need to get on top of it.</p><p>What is Windows 11? For microsoft it's a chance to make a set of controlled breaking changes to the Windows platform ecosystem. It's neither purely a "good" thing, nor purely a "bad/mediocre" thing. It's a necessary thing. </p><p>While Apple feels free to break everything all the time, every day, Microsoft has comitted to, and maintained a history of not breaking everything every day. And so there comes a time, when breaking changes and "flag days" have to happen. In true microsoft fashion, there are devices that will continue to run Windows 10, for the next few years, or longer. And also in true microsoft fashion, there are devices that will refuse to auto-upgrade for you but which you can force to update to Windows 11, via the media creation tool, with Microsoft's full blessing. You try it, you get the results and you get to see for yourself what Windows 11 does on your random pre-2020 consumer hardware.</p><p>So what is this post about? It's just a request for discussion. What has been your experience? Are you running Windows 11 and Delphi 11 and how is it?</p><p>I have one anecdote to report; It seems Delphi 10.4 debugger hangs a lot on Windows 11. Any attempt to set breakpoints and single step, the whole IDE (bds.exe) process hangs forever at 0% CPU. There do not appear to be wait chain analysis tools built into Windows 11 yet, and I'm not sure if I could do a wait chain analysis on BDS.exe from visual studio but I don't have visual studio on this box. </p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://lh3.googleusercontent.com/-NGrpJS9hv0Q/YYVlAjWe6oI/AAAAAAABAc8/KTir_UKqQEM4vT71Mxszx4N7sxCsrD29gCLcBGAsYHQ/image.png" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="532" data-original-width="615" height="240" src="https://lh3.googleusercontent.com/-NGrpJS9hv0Q/YYVlAjWe6oI/AAAAAAABAc8/KTir_UKqQEM4vT71Mxszx4N7sxCsrD29gCLcBGAsYHQ/image.png" width="277" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><b>The issue is reproducible with a trivial helloworld-from-delphi app in 10.4</b>, but is <b>more frequently reproducible </b>on the large 150+ megabyte exe apps I get paid to code, some of which load large non-trivial amounts of redistributables with, including openssl, chromium embedded (google chrome browser), and a lot of other stuff. These large apps are not fully portable to Delphi 11 without a large investment of time, and so I can't say if the same app will hang the debugger kernel in our large Delphi 11 apps. The main app being debug above is a 32 bit 169 megabyte exe that loads another 180 megs of 32 bit DLLs (Chromium "libcef" is over 100 megs of stuff). <p></p><p>In a trivial hello world app, Delphi 10.4.2 freezes about 50% of the time after I hit a breakpoint and then continue. Other 50% of time, it may recover and then when you end the debug session it will say "fatal debugger error" and ask that you shut down the IDE. THere's basically something fundamentally different in the Windows Kernel environment in Windows 11, and the Delphi 10.4 debugger is not up to speed with the changes in the platform. My tests are with Delphi 10.4 build 27.0.40680.4203 (delphi 10.4.2, all of Update2 installed) on Windows 11 pro build 21H2, osbuild 22000.258 (windows 11 initial release).</p><p><br /></p><p><br /></p>Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com5tag:blogger.com,1999:blog-6444609270251748954.post-30205505561242925222021-07-20T09:33:00.004-07:002021-07-20T09:37:13.333-07:00Did you know that the Raize Components (Rz*) by Ray Konopka are now in Getit under a completely inscrutable new moniker?<p> Would you have guessed what "Bonus KSVC 7" is, if you saw it in getit. No? Neither would I.</p><p>It turns out that if you are looking for Raize Components they're now called Bonus KSVC, and available as version 6.5 and 7 in GetIt.</p><p>Raize Components, as it was for over a decade, got renamed to Konopka Signature Controls in 2020. But one rename was not enough for the bright sparks at EmbarcIdera. Now it's been renamed again, this time it's called KSVC. Sure. And the word bonus was necessary to put in front in the title, because "raisins".</p><p>Naming things is one of the hard problems in Computer Science, I guess. </p><p>The components remain quite awesome, and since they're in GetIt, I can heartily recommend everyone check them out if you hadn't heard about them. There's still a discussion forum dedicated to them on the Raize.com site, but the product appears to have been 100% bought out by Embarcadero and is basically "part of Delphi now", which was a good move by Embarcadero. </p><p><br /></p><p><br /></p><p><br /></p><p><br /></p><p><br /></p>Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com0tag:blogger.com,1999:blog-6444609270251748954.post-30612490140402471122021-04-14T15:44:00.003-07:002021-04-21T09:54:07.879-07:00Rant: Git is not a version control system. But you're going to use it as one anyways.<p>I can hear you saying it.</p><p>" You're wrong, Delphi Code Monkey, Git <u>is</u> a version control system.".</p><p>Hear me out.</p><p>Git is not a version control system, it's a directed acyclical graph management system that happens to be possible (sometimes) to do version control with.</p><p>Every time you find something Git can't do, that it ought to do, for all of the billion people who probably use it and know it well, if you keep searching for ways, however torturous, to handle your issue, there is probably a way.</p><p>There is stashing, and submodules, branching, and merging, there are cherry picks, and there is rebasing, there are branching models and workflows like Git Flow. There's recursive submodule hell. There's local git cached state hell. There's ignore hell. There's Git's unix roots are showing on windows hell.<br />There's git config hell. There's unable to check out a branch because of local changes, and yet git status shows no files have changed, hell. If I sat here and thought back through the years of horrible things Git has done to me, one by one, I would probably scream.</p><p>There are a thousand fresh hells waiting for you. A thousand inscrutable (but usually googleable) error messages.</p><p>Here's the worst of the Git hells. Git lockin hell. Once you choose Git, well, it's Hotel California. You can "check out" but you can never leave. The world of software development is now, and probably always will be locked into some version of Git or other.</p><p>Git is not actually (much) of a version control system, but you're going to use it like it was, and you're going to learn to like it.</p><p><br /></p><p>Update: The point of this rant (and it mostly is just a ranty rant) isn't that you SHOULD NOT use Git, it's that the nature of Git is to expose all the guts to you, and to blow up with errors that are because the internals are in a bad place and Git leaves it for you to put Humpty Dumpty back together again, and that you are going to do that a LOT when you live and work all day, especially in a team of 5+ people, with Git. Perhaps if you are saying to yourself, "I don't have all these problems that other people talk about", it could be because (a) you're not using submodules, (b) you're not working with teams of 5+ comitters, and (c) you don't use a lot of branching, merging, rebasing, cherry-picking nor complex workflows like git-flow.</p><p><br /></p><p><br /></p>Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com10tag:blogger.com,1999:blog-6444609270251748954.post-77050769830513216772020-10-23T11:17:00.003-07:002020-10-23T11:17:32.860-07:00A few quick tips about Downloading Delphi 10.4.1 (sydney) and all future Delphi Releases for current active customers.<p>Probably this is old news but I didn't see the news whenever it hit, and so I'm posting this here in hopes that other people who hadn't realized that EDN/CodeCentral is no longer where you get your Delphi downloads from, will Get The Memo. Did you Get the Memo?</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://lh3.googleusercontent.com/-SjGIyOH5p04/X5MeNlkf_yI/AAAAAAAA8rM/Sv7UpmESyv848NeRR6iCP9hvF5MXCPWjQCLcBGAsYHQ/image.png" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="195" data-original-width="258" height="240" src="https://lh3.googleusercontent.com/-SjGIyOH5p04/X5MeNlkf_yI/AAAAAAAA8rM/Sv7UpmESyv848NeRR6iCP9hvF5MXCPWjQCLcBGAsYHQ/image.png" width="318" /></a></div><br /><br /><p></p><p> 1. Don't bother trying to find 10.4.1 Sydney in the old EDN products portal, the one with the url starting cc.embarcadero.com/reg/rad_studio. 10.4.1 isn't in there. I wouldn't be surprised if this site went away at some point. </p><p>2. If you have an active subscription the place to get 10.4.1 Sydney is from the My Embarcadero Portal using the same login credentials as your active subscriptions and your licenses are associated with. <a href="https://my.embarcadero.com/">https://my.embarcadero.com/</a></p><p>3. Even very old stuff like Delphi 7 isos is now on the new site. It does seem that the same file pile of your purchases from the Borland, or CodeGear, or the pre-Idera Embarcadero era, are all on there, and there's no loss of continuity, and as far as I can see, there's no reasons to complain about the change, it seems good.</p><p>It's nice to see that the ancient EDN stuff is finally being rebuilt. I still have some complaints about the download and install experience. For example, why isn't TeeChart available both from GetIt instead of only as a one-shot-miss-it-and-it's-gone a checkbox during initial install? </p><p><br /></p><p><br /></p><p><br /></p>Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com2tag:blogger.com,1999:blog-6444609270251748954.post-35965564148327962742020-07-22T20:20:00.004-07:002020-07-23T11:06:13.770-07:00Git with Delphi: The BasicsI wrote this blog post as I ran into a Delphi coder who was using some non-verson-control tool like Zip or DropBox to store their code. Now I'm not saying you shouldn't ever store code in zip files or upload code to dropbox, but that should not be your source of truth. This is a highly opinionated fly through of the basics that a non-git user should be aware of.<div><div><br /></div><div><b>WHY GIT? GIT IS THE STANDARD FOR SOURCE CONTROL</b></div><div><b><br /></b></div><div><b>What is source control? </b>Source control means having a single SOURCE OF TRUTH for what your code is. Ideally that single source of truth should be on a private or public repository hosted on a git server, like bitbucket, or gitlab.</div><div><br /></div><div><b>Why GIT? </b>There is literally nobody policing this, if you're a solo developer, pick whatever version control system you want, but if you pick anything other than Git, you're going to eventually probably regret it. There are network effects (an economics term, really) here. I'm not going to explain network effects. If you have to google that, go ahead.</div><div><br /></div><div><b>What is a source of truth? </b> Git provides a source of truth because all git commits have a "revision hash", a fingerprint that marks them uniquely. Git provides a way to say, for sure that if you have git commit A939B9.... (more digits omitted), you know exactly what content every single file in your produce source code contained. In order to be really sure about it you should actually also be using Continuous Integration instead of building things on your developer PC.</div><div><br /></div><div><b>What is CI (continuous integration)? </b>Another reason to use git is so that you can have your code built automatically whenever you change it and have that build happen in a controlled way, in a controlled and repeatable environment so that you actually know what you sent your customers, if you have customers. If you are working for a company that sells software, and the software binaries you put on customer PCs were built on your own desktop computer, and not on a build server, and your company is more than just one person, you also should be using Git, so you can get ready to be building your software from an automated build (CI) environment.</div><div><br /></div><div><b>What are these unit and integration tests things people talk about</b>? You have those right. If you have Git, and CI, and unit tests, you can be running those things every time your code builds. Are you beginning to see possibilities unfolding like flowers? If you are a single developer, having CI and unit testing, and continuous unit testing on every git commit, can really help you.</div><div><br /></div><div><b>How do I get started? </b>The rest of this post lays out a basic plan for getting started with Git.</div><div><br /></div><div><b>Wait I have objections... </b>Post them in the comments. I prefer subversion is an opinion, not an objection, but feel free to tell me that if you like. </div><div><br /></div></div><div><b>Step 1. </b> Sign up for an account on bitbucket.</div><div><b><br /></b></div><div><b>Step 2. </b>Download Source Tree. (The <b>easiest Git client to learn</b>, not the fastest, or most powerful, and not one you will stay with forever, SourceTree is good at holding new user's hands and getting them some critical early experience with version control, especially if you haven't used version control before and are coming from a background of using Zip or Dropbox to "back up" your code.)</div><div><b><br /></b></div><div><b>Step 3. </b>Create a dummy repository in bitbucket and clone it with source tree. Follow their tutorials.</div><div><b><br /></b></div><div><b>Step 4. </b>Create a delphi application with File -> New Application and commit that source code for the brand new main form right after the first time you save the project and main form and give them the NAME they are going to have for a while. </div><div><b><br /></b></div><div><b>Step 5. </b>Using your git GUI, Add and Commit the files to the local git repository. You have only now been working with your own files on your own hard drive so far.</div><div><b><br /></b></div><div><b>Step 6. </b>Push your commits up to the repo you created in bitbucket. Log into the bitbucket website and find the code on your bitbucket account in the repositories page. </div><div><b><br /></b></div><div><b>Step 7. </b>Go to a different computer (if you can) or a different folder on the same computer (if you only have one) and clone the repo to that location. Observe for yourself that Bitbucket is like a Transporter for Code. The code on my computer is now code on another person's computer. Yet another use for Git. Code transporter. Team coding enabler. Backup system. Historical log of what your code was over time. And a thousand other things. Once you have internalized and understood the value of even 5% of what a good version control tool can do for you, you will <b>never work without one.</b></div><div><b><br /></b></div><div><b>Step 8. </b>Make the application do something. Fibonacci sequences. Sorting interview question. Anything. Once it works, Commit the working code, explain the code you wrote in your commit messages always. <b>Get into good habits to start with so you don't have to learn the hard way.</b> Now mess the code up on purpose. Now using your Git Client (SourceTree or others) find the change and DO NOT COMMIT it, instead revert it. You have now observed another use for Git. The Time Machine. Any time you move your code in a way that makes it worse, you can just revert the change before you commit it. </div><div><br /></div><div><b>Step 9. </b>Make a bad change and commit it even though you know you just broke your app. Now find the way to revert a commit (get your code back to the way it was before the bad commit). I'm not going to tell you what the command is called, because I want you to figure it out for yourself. So git can not only be a time machine BEFORE BAD COMMITS it can also be a time machine to get you back code after bad commits.</div><div><br /></div><div><br /><b>Step 10.</b> Now learn about .gitignore. Do this before you import any real projects into git. Find out what .gitignore is and how to write expressions into it like *.dcu and *.local. Do not commit binaries (exes, dcus, dcps, bpls) into Git, unless you really really have to. In general, you should NEVER EVER commit a DCU for a .PAS file that is in the repo as you should be BUILDING that .DCU file from source. If your projects are badly configured (DCU Output folder is NOT set) then get used to setting the DCU Output folder option in Delphi to a sensible default for all your projects. Mine is .\dcu\$(Platform)\$(Config) so that I can have win32, win64, and even other non windows platforms all build and not have my dcus get mixed up. .gitignore is the place to code these dcu and exe output folders in so that when you add your source code into a git repo you do not commit the exes. If you really really want to store your ssl dlls in git, nobody is going to come and arrest you, but please for the love of the flying spaghetti monster, learn what .gitignore is and use it. Don't commit DCUs. Sermon endeth.<br /><br /><b>Step 11.</b> After you understand git ignore then take your source code folder and do a git init there, from source tree. Add things in small chunks. Not 10K files in one commit. Add one top level folder that contains less than 50-80 megabytes of content, at a time, if you can. Trust me you'll be glad you did this, if you have a 1 gigabyte project, please do not add 1 gigabyte of files in a single commit. After each commit, add more files until your repo is built. If you were previously using mercurial or subversion there are tools to keep your subversion and mercurial history and convert over to git. I'm not going to cover them but I know they exist and that they work as I've used a variety of them. I generally don't bother. I just start over with new history in git, and I go back and look at the old version control systems to see old versions.</div><div><br /></div><div><b>Step 12.</b> Get used to comitting all your code after you write it and writing GOOD COMMIT MESSAGES. A good commit message is a message that explains the purpose of your changes. If you are lazy here, your future self will hate you. You don't need that kind of rejection in your life. WRITE GOOD COMMIT MESSAGES NOW.</div><div><br /></div><div><b>Step 13.</b> Push after every commit until you have made it a habit.</div><div><br /></div><div><b>Step 14.</b> Delay using and learning about submodules, branching, tagging, and other topics in Git until everything I have said above is well ingrained and is part of your habits. Learn to use Diff tools, learn to merge, before you learn to branch. Imagine you learn to drive a car but you concentrated on learning how to drive fast before you're very good at steering and braking. Steering and braking are the ways you stay out of trouble. Merging, and diffing are ways to get out of trouble. Submodules, and branching are ways to get into it. Until you have the tools to sort yourself, just don't make the crazy advanced messes. Don't try to deploy and manage a Gitlab instance at cluster scale when you don't even know how to Diff two files, compare them, and solve merge conflicts.</div><div><br /></div><div>I believe the above will be helpful as I've written it, but I reserve the right to amend the advice above if anyone can point out ways in which the above might lead a new Git user astray. The happy path, of a contented Git user, is a gradual growth in competence with a powerful tool.</div><div><br /></div><div>Can git be frustrating? Yes. Is it complicated? Yes. Is it worth it to learn it? Also Yes.</div><div><br /></div><div>Are most of us going to do things wrong, and learn everything the hard way? Yes, because you are human. It's okay. </div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div>Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com12tag:blogger.com,1999:blog-6444609270251748954.post-27751055489230649762020-05-29T10:07:00.000-07:002020-05-29T10:07:07.545-07:00Please DO NOT use the Jedi JVCL JvCsvDataSet component. I wrote it and it's not safe.Once upon a time I was a Jedi JVCL developer. I contributed JvCsvDataSet, to the Jedi JVCL project.<div><br /></div><div>Unfortunately, I believe it has several internal design flaws and needs a total rewrite, and also may be incompatible with modern delphi Dataset field management.</div><div><br /></div><div>I do not have time to go debug the horrible memory and pointer bugs that are lurking deep inside it, but I believe the component should be deprecated.</div><div><br /></div><div>I wrote some of this code, some of it is based on very old code from a book written in 1998, and it's also been altered, both by me, and by other people, over its long history. I think it should be moved into a legacy folder and removed from a future JVCL version if no longer maintained.</div><div><br /></div><div>Like I am saying above, and I'm saying again, I don't have time to fix it, and I believe it's broken in Delphi 10.0, 10.1, 10.2, 10.3, and 10.4.</div><div><br /></div><div>If it's being used in a little utility program fine, but if you're building your app around this component, please rethink that. Please rip it out and use FireDac TFDMemData and write some other CSV import and export functions.</div><div><br /></div><div>Thanks.</div>Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com7tag:blogger.com,1999:blog-6444609270251748954.post-72535253749381887272020-03-24T09:57:00.006-07:002020-05-13T13:02:49.514-07:00Delphi Seattle becoming almost unusable on Windows Build 1909<div dir="ltr" style="text-align: left;" trbidi="on">
I have previously posted about fun adventures running insider preview builds of Windows 10, with Delphi. Now, I no longer run insider preview builds because the problems are just not worth it.<br />
<br />
However, as Microsoft believes your computer belongs to them once you put Windows 10 on it, you now have to deal with your "windows 10" (pronounced "Windows is like a box of chocolates, you never know what you're gonna get") system will daily, or weekly, break stuff and die randomly on you.<br />
<br />
In the midst of a global panic over a real virus, I would like to add that I feel that Windows 10 is a virus.<br />
<br />
I can't rely on Windows 10 not to :<br />
<br />
1. Ship new stuff I don't want.<br />
<br />
2. Turn back on options that I turn off, like windows defender realtime protection.<br />
<br />
3. Break production binary applications, for which I have no source code, most importantly Delphi itself, which I need to do my job.<br />
<br />
4. Work the same way on all the hardware I own. One build of windows will be a disaster and crash repeatedly, but work fine on other hardware I own. Build 1903 worked on one of my PCs but not the other, and now build 1909 works on one of my PCs and not the other.<br />
<br />
Most recently, I can no longer operate Delphi 10 seattle which is the version my employer's production codebases are relying on. (When you work in a team, by the way, one person can't just move versions, so if you suggest that I should move to a new delphi version, I'll just ignore you as we're going to do that when we all do that, as I belong to a team.)<br />
<br />
Here are three of the fun problems that I'm seeing:<br />
<br />
1. If ever you had to set up a new PC on a new windows build and get it going with Seattle, and Windows build 1909, good luck. To get a preview of the fun you'll have, you could rename (god forbid you should ever ever delete) the registry BDS\17 registry key, Delphi can not create a valid new setup and start up without crashing. You get an access violation in coreide230.bpl. If you have a valid backup of a working BDS\17 registry key, you can recover it. Anyone using Seattle on Windows 10, please keep backups of your BDS\17 key under your Current User registry settings.<br />
<br />
2. <b>(UPDATE:Fixed in recent Win10 quality update) </b>Delphi is unable to build our projects without dying during the write DCU phase randomly. This was always bad on some peoples computers, but usually not on mine, and now I can no longer operate the IDE and compile or build the main projects I need to compile for my day job.<br />
<br />
3. <b>(UPDATE: Happens less in build 1909 than build 1903, but still a problem.) </b>Delphi's debugger when reset, is hanging the Windows 10 1903 and 1909 kernel hard, on some systems, for some applications, mostly ones that seem to have certain DLLs loading and unloading in them.<br />
<br />
<br />
I'll post solutions if I find them, but if I don't, I'm going to move into a Win7 VM for all development, because Windows 10 is not something you can trust. What's most odd is I have a Win10 VM running build 1909 and this issue is NOT happening in the VM.<br />
<b><br /></b>
<b>UPDATE: On the latest quality update of Windows 10 build 1909, on the main machine that was having these issues, the problems with the bds.exe executing delphi compiler within the IDE (point 2) is resolved. <br /><br />UPDATE2: Still no workaround known for Point 1 other than to keep your working backups of registry in current user. <br /><br />UPDATE3: A new issue that is less grievous but still annoying has appeared. The USB User Mode Driver Framework has started hanging. The main symptom is that all USB attached peripherals including external mouse and keyboard stop working for about 30 seconds while some core Windows user mode driver framework bits restart themselves. I can trigger it by resetting the delphi debugger. Something about terminating the process being debugged, which may be holding onto a handle for some device driver related object somehow, seems to trigger a crash in a usb driver, which somehow then crashes the host process. </b><br />
<b> </b><br />
<br />
<b>UPDATE4: Although my main work machine is unaffected, build 1903 and build 1909 are "bricking themselves" (failing to boot) after something in the windows update process corrupts the boot time data storage area (BCD) of the Windows boot volume (Drive C). This happens repeatably on certain Lenovo Thinkpad hardware. I suspect a kernel-mode panic during boot due to a driver bug in the chipset drivers.</b><br />
<br />
<br />
<br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com9tag:blogger.com,1999:blog-6444609270251748954.post-31897430148186274892019-12-23T11:07:00.004-08:002019-12-23T11:09:51.907-08:00Bare Minimum Expert and Wizard Demos<div dir="ltr" style="text-align: left;" trbidi="on">
Bitbucket, instead of giving me free Mercurial hosting forever has decided to kill my Mercurial repos, of which I have hundreds.<br />
<br />
I converted two little ones today and wanted to make a quick post because I think many people may have looked for these minimal wizard and expert examples and have had a hard time finding them.<br />
<br />
Originally for the the Toronto Delphi user group I wrote some examples on how to start writing experts and wizards for Delphi:<br />
<br />
<a href="http://www.tdug.com/2016/04/april-meeting-follow-up-2/" rel="noreferrer" target="_blank">http://www.tdug.com/2016/04/<wbr></wbr>april-meeting-follow-up-2/</a><br />
<br />
I have recently converted the sample code from mercurial to git repos, and they are still on bitbucket but have new links:<br />
<br />
<br />
<br />
<a href="https://bitbucket.org/wpostma/helloworld_delphi_expert/src/master/">https://bitbucket.org/wpostma/helloworld_delphi_expert/src/master/</a> (git)<br />
<br />
<a href="https://bitbucket.org/wpostma/helloworld_delphi_wizard/src/master/">https://bitbucket.org/wpostma/helloworld_delphi_wizard/src/master/</a> (git)<br />
<br />
<br />
The abridged notes on the above examples are:<br />
<br />
<br />
1. You probably <b>don't </b>want to write a wizard. You <b>probably </b>want an expert. But you may want to know what a wizard is, versus an expert, and you may conceivably find some thing that really is better as a wizard. But mostly you probably want IDE experts if you want to add some feature to the Delphi IDE as a plug-in.<br />
<br />
2. The Wizard example is probably the one you want to download if you only grab one of the above. But go grab both. Free. No warranty expressed or implied. And no built in guarantee that I'll provide you with free technical support. You probably want to join an OTAPI focused Delphi mailing list or web forum, if you want help and support writing OTAPI (open Tools API) DLLs.<br />
<br />
<br />
Here are my notes on these code samples:<br />
<br />
<blockquote style="background: rgb(255, 255, 255); border: 0px; color: #333333; font-family: Georgia, "Bitstream Charter", serif; font-size: 16px; font-style: italic; margin: 0px; padding: 0px 3em; quotes: none; vertical-align: baseline;">
<div style="background: transparent; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">
<span style="background-color: transparent;">The recommended way to use the helloworld samples is to open them up and build them, then install them and try them, then poke around the code and find how an expert or wiard works by reading the samples/demos.</span></div>
</blockquote>
<br />
<blockquote style="background: rgb(255, 255, 255); border: 0px; color: #333333; font-family: Georgia, "Bitstream Charter", serif; font-size: 16px; font-style: italic; margin: 0px; padding: 0px 3em; quotes: none; vertical-align: baseline;">
<div style="background: transparent; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">
<span style="background-color: transparent;">There’s not so much code there, and almost all of it is important, except you can ignore the castalia parser code which was put in there just to make it easier to get it integrated when you want to have a pascal parser library in a real world expert, as shown in the last of the three demos.</span></div>
</blockquote>
<br />
<blockquote style="background: rgb(255, 255, 255); border: 0px; color: #333333; font-family: Georgia, "Bitstream Charter", serif; font-size: 16px; font-style: italic; margin: 0px; padding: 0px 3em; quotes: none; vertical-align: baseline;">
<div style="background: transparent; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">
</div>
<div style="background: transparent; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">
The first of our three demos, the hello world Wizard sample shows in Package (BPL) form, how to use the open tools api Wizard interface.</div>
</blockquote>
<br />
<blockquote style="background: rgb(255, 255, 255); border: 0px; color: #333333; font-family: Georgia, "Bitstream Charter", serif; font-size: 16px; font-style: italic; margin: 0px; padding: 0px 3em; quotes: none; vertical-align: baseline;">
<div style="background: transparent; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">
<b>Wizards may </b>seem easier to use but the limitations and annoyances of a BPL wizard are severe and it is not a recommended approach for most IDE plugin requirements.</div>
</blockquote>
<br />
<blockquote style="background: rgb(255, 255, 255); border: 0px; color: #333333; font-family: Georgia, "Bitstream Charter", serif; font-size: 16px; font-style: italic; margin: 0px; padding: 0px 3em; quotes: none; vertical-align: baseline;">
<div style="background: transparent; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">
The second demo, the hello world Expert sample shows in an Expert DLL form, how to use the most central open tools api Expert interfaces. It shows how to export the registration function from the DLL, how to integrate with the IDE about box and IDE splash screen including a little icon that shows while Delphi starts up, and how to add a menu item in the main menu and add a menu item in the project right click menu, how to integrate with the IDE Insight feature, and how to make keyboard shortcuts (hotkeys) work.</div>
</blockquote>
<br />
<br />
<blockquote style="background: rgb(255, 255, 255); border: 0px; color: #333333; font-family: Georgia, "Bitstream Charter", serif; font-size: 16px; font-style: italic; margin: 0px; padding: 0px 3em; quotes: none; vertical-align: baseline;">
<div style="background: transparent; border: 0px; margin: 0px; padding: 0px; vertical-align: baseline;">
<span style="background-color: transparent;">Finally at the TDUG meeting, I showed a <b>third demo </b>that actually tries to do something interesting using the open tools APIs. Since the above helloworld expert is only a skeleton, and while useful as a starting place for someone who wants to write a wizard, doesn’t actually do anything that you might want to do and is certainly not something you would find you couldn’t live without, I wanted to make a demo that while not yet an invaluable tool, shows some of the potential for wizards. This one implements a custom parser, grabs the currently selected editor window and checks the code inside for two kinds of problems. The first is incorrect use of the WITH statement. All uses of WITH are incorrect, and should be killed with fire. Secondly, it tries to line up your begin and end statements and see if they match up. If they don’t match up, it tells you. If your code is nicely formatted and free of With statements, it is pronounced good.</span></div>
</blockquote>
</div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com0tag:blogger.com,1999:blog-6444609270251748954.post-62118421003259980562019-10-01T10:30:00.000-07:002019-10-01T10:46:52.187-07:00The Single Worst Mistake any Software Product Based Company Can Make<div dir="ltr" style="text-align: left;" trbidi="on">
I am a long time follower and reader of Joel Spolsky. Way way back in 2000, he penned what has become a seminal blog post.<br />
<br />
<a href="https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/">Things You Should Never Do, Part 1</a><br />
<br />
It should be required reading for all leadership teams in all software companies, especially the small ones, because those are the ones most likely to commit Hari-Kari in the way described in the above post. I will quote it.<br />
<br />
<blockquote class="tr_bq" style="background-color: white; border: 0px; box-sizing: border-box; color: #404040; font-family: "Source Sans Pro", "Helvetica Neue", Helvetica, Arial, sans-serif; margin-bottom: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
<span style="font-size: x-small;">We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.</span><span style="font-size: x-small;">There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: <i style="box-sizing: border-box;">they are probably wrong.</i> The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:</span><span style="font-size: x-small;">It’s harder to read code than to write it.</span><span style="font-size: x-small;">This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it’s easier and more fun than figuring out how the old function works.</span></blockquote>
<br />
Here's something I've seen happen time and time again in my career.<br />
<br />
<blockquote class="tr_bq">
Manager Dave: Steve, why did we ship version 3.2 and break all our customer's ability to do business again? I thought once we hired QA people that would stop happening.<br />
Team Lead Steve (haggard, has had 3 hours sleep): Um, Dave, regressions in 3.2 were caused by the requirement in that release to rewrite a core module of our system to please one of our customers, that broke all three hundred installed customers.<br />
Manager Dave: Can you explain to me why that is?<br />
Team Lead Steve: Goes on to explain the concept of technical debt, makes reference to configuration spaces (parameter 310 is on, parameter 311 is off, parameter 312 is set to X, parameter 313 is set to Y).<br />
Manager Dave (cradling his head in his hands): So what do we do, Steve?<br />
Team Lead Steve: Well we could rewrite everything get rid of all the technical debt, refuse to add parameters to turn features on and off in 900 ways.</blockquote>
<br />
In my view, the thing that saves people from making the single worst mistake (the ground up rewrite, discussed in the blog post from Joel Spolsky) is that most people realize the economic disaster before they commit all their resources to it. Wait, we can't ship any minor updates to our customers for THREE YEARS? We won't HAVE any customers in three years.<br />
<br />
Another way the rewrite conversation comes up is when it's time to grow your team from four delphi devs to to five, and you can't find one that will move to Spooksville Indiana, and join your local team, and you aren't going to add remote team members. If you moved to C#, and rewrote, all your problems will be over, there are reams of unemployed C# developers everywhere, and you can probably grow your team to 20 people no problem, you just need to rewrite 9 million lines of code in C# that are currently in Delphi. <br />
<br />
There are still teams running on Delphi 7 and Delphi 5 because they can't figure out the complexities of moving up to modern unicode Delphi who think they can't manage the unicode transition, but they can successfully rewrite everything in C#.<br />
<br />
Note that there ARE times when I think you can rewrite, ground up, same language or different, same database or different. They are when all the following stars align:<br />
<br />
1. When you can keep your existing team working on your classic product, and start a parallel effort,. and afford to develop both in parallel for the years to a decade it will take before the new product can replace the old.<br />
<br />
2. When you don't just think you know your requirements, your designs and your use cases but you actually do know them. Most of the time you have a confirmation bias telling you that you know this stuff, but guess what, you're probably wrong here.<br />
<br />
The next thing, if the economics don't kill you, in a rewrite, that's gonna kill you is second system effect. Second System Effect is a term coined by Fred Brooks and is the title of one of the essays/chapters in the seminal book "The Mythical Man Month" that every senior developer or software team leader/manager should read.<br />
<br />
Joel says the same thing thus:<br />
<br />
<blockquote class="tr_bq">
<span style="font-size: x-small;"><span style="background-color: white; color: #404040; font-family: "source sans pro" , "helvetica neue" , "helvetica" , "arial" , sans-serif;">It’s important to remember that when you start from scratch there is </span><b style="background-color: white; box-sizing: border-box; color: #404040; font-family: "Source Sans Pro", "Helvetica Neue", Helvetica, Arial, sans-serif;">absolutely no reason</b><span style="background-color: white; color: #404040; font-family: "source sans pro" , "helvetica neue" , "helvetica" , "arial" , sans-serif;"> to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.</span></span></blockquote>
<br />
I have noticed that old code is scarred with bug fixes. And we don't like the look of it we wish it looked clean and rather like pseudo-code. The thing is the real world has lock conflicts, network timeouts, retries, user errors, windows defender locking and even altering your on-disk files, disk performance and corruption issues, video card bugs, USB driver glitches. Need I go on?<br />
<br />
The real world is a mess, and if your product works at all for your customers, it's amazing that you got that far. Don't blow it now. Fix your bugs, and clean your messes up. And you better stop digging new holes (increasing technical debt) before you can expect to see the old technical debts get paid off.<br /><br />One of the leading causes of technical debt is crazy features for ONE customer. You could rethink when and where you add custom hacks for one customer who is loud and persistent, and perhaps could accomplish their goals another way without breaking your product in half.<br />
<br />
Thinking carefully about Risk management, and careful heads-up planning is necessary to avoid killing your software products or your whole software company.<br />
<br />
Don't rewrite your code ground up.<br />
<br />
<br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com7tag:blogger.com,1999:blog-6444609270251748954.post-87037695341148903422019-09-05T13:18:00.003-07:002019-09-05T13:20:14.993-07:00Sivv Open Source Projects by Jason Southwell<div dir="ltr" style="text-align: left;" trbidi="on">
Just wanted to point out these open source projects written by Jason Southwell, who in addition to being a well known Delphi developer out there is also my boss! Hi!<br />
<br />
Anyways, I use these libraries where we both work, and I think you should all check them out.<br />
<br />
<br />
<a href="https://bitbucket.org/account/user/sivv/projects/OS">SIVV Open source is on bitbucket</a> ...<br />
<br />
A few example projects:<br />
<br />
<b><a href="https://bitbucket.org/sivv/chimera/src/develop/">Chimera Networking and JSON Library</a></b><br />
<br />
Chimera project includes chimera.json, a very fast JSON library, and a bayeux (pubsub) network protocol client, and other things.<br />
<br />
<a href="https://bitbucket.org/sivv/cocinasync/src/develop/"><b>CocinAsync</b></a><br />
<br />
Networking/threading/async library. It recently grew some new "flux" like capabilities for event driven programming.<br />
<br />
<a href="https://bitbucket.org/sivv/duckduckdelphi/src/master/">DuckDuckDelphi</a><br />
<br />
A nifty duck-typing facility built over delphi RTTI facilities. As the comments state in the project source:<br />
<br />
// Instead of:<br />
// if obj is TControl then<br />
// TControl(obj).Visible := True<br />
//<br />
// You can simply call<br />
// obj.duck.setTo('Visible',True);<br />
<br />
The call will do nothing silently instead of blowing up if you had done a bad runtime cast. It's a nice pattern.<br />
<br />
<br />
<br />
<i>Discussion and questions on these components is at this site:</i><br />
<br />
<a href="https://sivv.com/">https://sivv.com/</a><br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com1tag:blogger.com,1999:blog-6444609270251748954.post-12776444356740854422019-07-31T18:48:00.005-07:002019-07-31T18:53:23.189-07:00Source Control, Version Control, Change Control, and the Underlying Disciplines Thereof <div dir="ltr" style="text-align: left;" trbidi="on">
So, out there in the world of developers, Delphi and others, there are many schools of professionalism, around:<br />
<div>
<ul style="text-align: left;">
<li>Version Control Practices</li>
<li>Continuous Integration Practices</li>
<li>Release Management and Change Controls</li>
</ul>
<div>
<div>
Let's imagine there's a dial from 0 to 10, and at each number on the dial, there's a developer or team that is functioning at that Level of Versioning/CI/Release/Change practices.<br />
<br />
0. Dude with laptop, ships code from his laptop to customer pcs. </div>
<div>
<br />
1. Dude had a bad day and lost data. Decides to up his game to using Zip files. (For most of us old timers, I hope this day was back around 1991 for you.)</div>
<div>
<br /></div>
<div>
2. Dude sees the beauty of being able to check in, revert, commit. Dude is saved and has seen the Version Control System light. (This happened to you in about 1999, hopefully and your first version control system was Visual Source Safe, hopefully you are not still using that.)</div>
<div>
3. Dude realizes that checking in frequently is great. Dude has not realized that Branching is useful, or is using a tool in which branching is not very useful (like Subversion). Dude needs to learn new tools and practices, but doesn't want to.<br />
<br />
4. Dude is member of a team of Developers. This team works well together, so they have to know what branches are, and merges. None of them know what Continuous Integration is. The team builds and ship from a designated lead developer PC.<br />
<br />
<br />
5. Dude & Team had a bad day, and learned to love CI. The CI system is a bit sad but hey, we've got one, and that makes our Kung Fu better than teams that don't. No longer does The Dude ship code from his/her laptop to customers.</div>
<div>
<br />
<br />
6. The Dude and Team, do CI, and honestly tried to start Unit Testing, but that never really worked. There are millions of warnings and hints in the code. When the code somehow builds without an error, we hand it to QA then ship it. If you don't have dedicated QA people, you are still level 5, hire a QA, and have CI, and you're level 6. Congrats, you're probably above average in the Delphi world.</div>
<div>
<br /></div>
<div>
7. The Dude and the Whole Team are conscientious about cleaning up hints and warnings and is working on getting code under unit test. This is now better than about 60% of delphi shops.</div>
<div>
<br /></div>
<div>
8. Dude and Whole Team Always know what was shipped to customers, as each version like Version 1.6.7.85080 is known to correspond to a certain CI build which in turn corresponds to a known revision in version control. All the executables are re-tagged with versioninfo updating tools during builds. This is now better than about 70% of Delphi shops.</div>
<div>
<br /></div>
<div>
9. All the prior best practices are followed and also, All code that we build also passes tests or it doesn't go to human QA. These tests cover 10% or more of real bugs that QA would find. You are probably in the top 20 best Delphi shops in the whole world.<br />
<br />
<br />
10. All the prior best practices are followed and also,All code that we build also passes tests or it doesn't go to human QA. These tests cover 80% or more of real bugs that QA would find. You are a unicorn, and you probably don't exist, or you're working in Go or C++, not Delphi. </div>
<div>
<br />
<br />
<br />
So far, I'm not aware of ANY delphi shop that can claim to be in category 10, for even the top four largest codebases at your company. Typically a few products are in good shape, and the others are pretty rough. From comparing notes with other Delphi professionals, most best of breed Delphi shops are probably in categories 6-9 above, all of which are Pretty Good to Really Good, in my opinion. </div>
<div>
<br /></div>
<div>
But Pretty Good and Really Good is still basically much lamer than many Go, Ruby, and Java open source projects out there, that you can go inspect and see, are being built with levels of professional practices that far exceed what I am personally aware of within Delphi based teams. <b>If your Delphi teams blow away all the rest, please please write a blog post and explain how you do it.</b></div>
<div>
<br /></div>
<div>
Some truly impressive open source projects you can observe a whole higher level of practices going on include the C# roslyn compiler and the .net core open source project, the gitlab version control system (built in go, and ruby), Google Chrome, Firefox, and SQLITE, which has a truly impressive set of unit tests and change control practices around its C/C++ core. </div>
<div>
<br /></div>
<div>
I want to move on to the question of <b>WHY the best practices matter.</b></div>
<div>
<b><br /></b></div>
<div>
A lot of the principles that underly the best practices above should be obvious to most professional software developers, but sometimes these principles are left implicit, and not spelled out.</div>
</div>
</div>
<div>
<br /></div>
<div>
Here are some principles that lie beneath the practices above. I have seldom worked on a team that couldn't do something a bit better. The best teams were always asking, "how can we improve?". The worst teams were always trying not to think about it. </div>
<div>
<br /></div>
<div>
1. Change Control Disciplines : We want to not make accidental changes, or even have people intentionally commit things, that were not wanted. How are we going to minimize risk of accidental or just random developer "felt like doing something" and that ending up in our product without anyone being aware, or testing for it?</div>
<div>
<br /></div>
<div>
2. Quality Control Disciplines: How do we ensure we know the risk and the proper testing scope, for any release of software we work on?</div>
<div>
<br /></div>
<div>
3. Version Tagging Disciplines: Does everything contain what it says on the tin? Is version 1.0.3.10231 enough information to recover the exact source code set that was used? (If you used CI, and build 106 in jenkins, became installer-1.0.3.10231 , and you can see which git or svn revision that was, you can recover sources to any version in the field, and accurately patch it.)</div>
<div>
<br /></div>
<div>
4. Code Hygiene and Code Quality Disciplines : Do we fix warnings (especially the ones that lead to direct bugs, like uninitialized local variables) before we ship to customers? Do we keep warnings and hints very close to zero so that really bad stuff doesn't hide "in the weeds" in plain sight? Once all the real ugliness is out of the way, some teams graduate to Code Smells, and Refactoring, to get the architecture in a better place so the product can grow and change and not collapse under its own weight. Code Hygiene and Code Quality disciplines are a never-ending asymptotic series of goals and ideals, but within those disciplines is a path out of drudgery and fire-fighting leading towards coding quality software that your customers will love. </div>
<div>
<br /></div>
<div>
<br /></div>
<div>
There are more details and things to say about the kinds of disciplines involved in the points above, that are not even talked about, there's a lot to be said about how to move from ball of mud (classic delphi) to TDD and well-factored code that is not a ball of mud. Those are topics for another day.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
</div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com2tag:blogger.com,1999:blog-6444609270251748954.post-55648183892984434842019-07-22T13:17:00.003-07:002019-07-22T13:17:44.963-07:00New Idera/Embarcadero Forums<div dir="ltr" style="text-align: left;" trbidi="on">
Folks who might have still been on the ancient Newsgroups might not have ever used the reboot of the Embarcadero Support Forums, and those are gone now, and have been replaced by some very modern and nice looking Embarcadero/Idera support forums which are located here:<br />
<br />
<a href="https://community.idera.com/developer-tools/general-development/">https://community.idera.com/developer-tools/general-development/</a><br />
<br />
<br />
My old community login did not appear to get moved over but it only took a second to get registered, and the site appears to be fast, responsive and easy to use. I like it.<br />
<br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com1tag:blogger.com,1999:blog-6444609270251748954.post-82389401069109698472019-03-04T14:43:00.001-08:002019-03-05T09:00:39.364-08:00Windows 10 insider builds may interfere with Delphi 10 seattle IDE operation<div dir="ltr" style="text-align: left;" trbidi="on">
Other IDE versions may be affected. I will update this blog post if I figure it out.<br />
<br />
Here's what I think is happening:<br />
<br />
1. Something about environment variable handling has changed.<br />
<br />
2. The PLATFORM environment variable during an IDE build is somehow wrong.<br />
<br />
3. The IDE fails to build some or all projects after this Win10 feature update. (Currently in insider preview).<br />
<br />
4. One or more units contains a precompiler directive in the form {$I filename}. This is being included at some place where it is causing a problem. For example:<br />
<br />
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;">{$I versionchecks.inc}</span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;"><br /></span>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;">MANY many third party components (open source and commercial) contain checks of this kind, and some may suck the includes in in a certain standard place, like the very top of the unit.</span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;"><br /></span>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;">5. Putting a precompiler include before the Unit name appears to be problematic.</span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;"><br /></span>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;">5. Putting a precompiler $I directive after Uses keyword, in the middle of a Uses clause, appears to be problematic.</span><br />
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;"><br /></span>
<span style="background-color: white; color: #222222; font-family: "arial" , "helvetica" , sans-serif; font-size: x-small;"><br /></span>
Insider preview build 1903, build 18348.1 appears affected.<br />
<br />
Typical compiler error example:<br />
<br />
[dcc32 Fatal Error] XUNIT.pas(408): F2039 Could not create output file '.\dcu\Win32\Debug\XUNIT.dcu'<br />
<br />
or<br />
<br />
[dcc32 Fatal Error] F1026 File not found: 'YourProject.dpr'<br />
<br />
Workaround: Use the DPROJ option to use MSBUILD to compile externally. <br />
<br />
(Helps if MSBUILD from command line remains unaffected.)<br />
<br />
This is not reproducing on all windows machines for me.<br />
<br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com4tag:blogger.com,1999:blog-6444609270251748954.post-79318735717352864542018-12-17T08:39:00.004-08:002019-07-22T13:14:42.570-07:00GetIt is broken, please fix it Embarcadero<div dir="ltr" style="text-align: left;" trbidi="on">
Various people, including myself are having problems with GetIt returning license errors instead of installing the thing it should install. Even on free items like the Jedi JVCL library, you can get this error:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-lP-9_n2LV-E/XBfQgJuLcFI/AAAAAAAAyV8/_DmDaMvi3kAXZhY2KUVLGWpWOq3ry3nbQCLcBGAs/s1600/getit_lic.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="499" data-original-width="636" height="251" src="https://3.bp.blogspot.com/-lP-9_n2LV-E/XBfQgJuLcFI/AAAAAAAAyV8/_DmDaMvi3kAXZhY2KUVLGWpWOq3ry3nbQCLcBGAs/s320/getit_lic.png" width="320" /></a></div>
It's not a blocker when you can install Jedi yourself from source (clone the git repo, download a zip from sourceforge, but where it really affects the product is when you build an Android firemonkey app the first time. You get a prompt to install the tools with getit, and getit having failed, your only choice is to uninstall delphi and reinstall from the ISO, instead of from the web installer.<br />
<br />
I hope Embarcadero fixes this soon. If anyone knows a workaround to get Getit to function, I will edit this post, and I will update it once a fix is released. Above is with Delphi 10 seattle, which many projects I work on are using still.<br />
<br />
<b>UPDATE: I have heard from an Embarcadero person that a fix for this is unlikely. You can get the JEDI JCL without using GetIt, but some things like CodeSite (Embarcadero edition) are NOT available anywhere else, not even in the EDN Registered Users Downloads section. If anyone has a list of Seattle accessories/tool-installation downloads that are missing from EDN and no longer can be fetched from GetIt, I'll post links for workarounds here, as any appear.</b><br />
<b><br /></b>
<br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com3tag:blogger.com,1999:blog-6444609270251748954.post-68877892353851748942018-07-22T21:48:00.002-07:002018-07-22T21:48:44.029-07:00Delphi starter is back as "Delphi Community". Good news for all Delphi users. <div dir="ltr" style="text-align: left;" trbidi="on">
I am one of those codgers old enough to remember Delphi 6 personal, and
the Turbo Delphi era (the next free edition name for delphi), and Delphi
Starter, and each time the pattern is the same:<br />
<br />
1. Announce it.<br />
<br />
2. Hope it works.<br />
<br />
3. Wander away and lose interest.<br />
<br />
Let's hope that DOES NOT happen this time. Delphi needs this "free"
starter edition. I wholeheartedly agree with the wiser and saner heads
who will from time to time argue that this needs to come back if it's
currently in a hiatus. Not dead, you understand, just resting, like that
parrot in Monty Python.<br />
<br />
With or without a free edition DELPHI IS NOT DEAD, but with a free
edition it's healthier. We need a tools ecosystem, that's an essential
part of modern software development. A healthy ecosystem needs us to be
able to build free stuff for Delphi. With a free edition of Delphi, I
hope it will always be possible to run continuous integration servers,
for example, for open source projects written in and for Delphi
development, and not need to worry "how do I build and run its unit
tests and deliver the installers for our product/package". <br />
<br />
We need encryption libraries. We need REST server and rest client
frameworks and add-ons thereto. We need something approaching the
breadth and depth of the ecosystems of Java and .Net, if Delphi is to
continue to exist as a sensible way to work in a web-everywhere
connected world.<br />
<br />
So delphi Starter, ahem, Community, is back. I for one am glad.</div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com5tag:blogger.com,1999:blog-6444609270251748954.post-47549238970146074552018-02-23T14:56:00.002-08:002018-02-23T15:03:18.151-08:00Windows 10 Is Terrible<div dir="ltr" style="text-align: left;" trbidi="on">
You would think that Microsoft, and Apple, having some of the highest paid software engineers in the world, would generally deliver higher quality software, that makes its users happy.<br />
<br />
You will notice I didn't say Best Software Engineers. I think that such a term is meaningless. We are all human beings. The things we produce have bugs. And worse than that, because bugs were accidents, we hope, there are misfeatures. There are misbegotten elements in Windows, and Mac OS, that you cannot alter. They are part of choosing to use these products. There are serious problems in Linux, but there are literally no misbegotten elements in Linux that cannot be removed. You can literally do anything to Linux.<br />
<br />
But since most of the professional world runs on Windows, and most of the Creative World (including most of the music workstations, and pro digital photography world) lives on Mac OS, both mac and windows users have a common problem. You probably don't know, you even probably don't want to know, what your operating software does, and whether you do, or you don't, you can't fundamentally control it.<br />
<br />
I will write a separate post on my Linux focused blog on why Linux is terrible, but since most of my Delphi blog readers are, like me, stuck using Windows, either on your PC, or in a VM, this rant is mostly about why Windows 10 is terrible, and why staying on Windows 7 forever isn't an option either.<br />
<br />
<br />
<b>1. You don't actually control your computer anymore. </b><br />
<b><br /></b>
<b>1.1 You have no way to stop system reboots. </b>Hello, Microsoft Here. We've decided to reboot your machine. You can't say no. This is acceptable? Microsoft will of course counter that they give you some control now, you can say, well I'm working from 9 to 5, don't reboot then. And you can say I use my computer actively these days. You can't say, no, let me decide when to reboot. It kills me that even Microsoft employees get Windows 10 reboots while they are giving presentations on how great Windows 10 is. <br />
<br />
<b>1.2</b> <b>You can not disable Windows Defender, unless you want to install something worse.</b> You can temporarily disable the Windows Defender Realtime feature, but it is automatically re-enabled after an unspecified amount of time. From what I can see that time is about 1-2 hours. The service that you could have disabled in Windows 7 to prevent Windows Defender is no longer possible to disable unless you take extraordinary steps to grab permissions of registry keys, and do some low level hacking that could easily damage your Windows install.<br />
<br />
<b>1.3 You can not keep permissions on NTFS files anymore. </b>If you, like me, think that the C: drive root can and should contain folders that are writeable by a non-admin user, Microsoft disagress. They reset all folders that start with the root of the boot drive as part of the regular security sweeps of your system, and you can not disable this. This breaks several applications that I maintain and develop. It seems these sweeps are associated with windows updates, so when Windows 10 updates to a new kernel, it does these NTFS permission updates.<br />
<br />
<b>1.4 You can not be sure you'll have 100% of your CPU and disk bandwidth available, at any time. </b>Who is using all my computer's resources right now? Oh yeah, Microsoft. There are many privileged tasks that you can not fully control or stop, including superfetch, the trustedinstaller, and there are many that do not tell you they feel like using your whole computer that at least can be paused. The windows search feature, which is useful, is not configurable so that it doesn't use your valuable computer resources when you're trying to, say, write code and compile your applications in Delphi and then debug them.<br />
<br />
<br />
<br />
<br />
<b>2. Windows 10 is gathering information about your computer, and you don't know what it is.</b><br />
<br />
Some <a href="https://www.theverge.com/2017/4/5/15188636/microsoft-windows-10-data-collection-documents-privacy-concerns">information</a> has been revealed about what kind of data Microsoft collects, but you still can't opt out of this, and you don't know what data it sent from your computer. In the latest Creators Update you have some control over the level of data gathering, but Off is not an option. This is frankly, unacceptable. On my main Windows 10 box, the Privacy page in the Settings app, has some new options, but "opt out from all telemetry and data transmitted to Microsoft" is <b>not</b> one of them. I have to say, it is nice that there is a web page where you can view the data they have that is associated with any email address you may choose to log into that site with. But even they (and you) may not actually be aware of, and may not, via this web site, be able to say "we're not monitoring you". They can only say, "here's data we have for that microsoft account, associated with that email". <br />
<br />
They do not claim that the data you clear is everything. In fact, the EULA makes it clear that it's not. You can clear out your browsing history but not all your telemetry data. Why do I even care? Because it's a principle. Surveillance that is used to send your CPU load history, that can be used to see performance regressions, arguably helps Windows users. But it should be my choice to opt into even the most benign data collection programs. That your browsing history (for Microsoft Edge only) is clearable, is good. All they give you there, is good, assuming you trust them. It's just not enough. It's sort of a smokescreen. I'm not saying that they just pretend to delete data, but I am suggesting that the real picture might be a lot more complex than they want to admit publically. They don't actually know who had access to personally identifiable data, that may do something with it, that is an abuse. They can't because that's a human problem. The best procedure for privacy is to not collect data in the first place. Microsoft has become addicted to your data. It's their lifeblood, they admit that publically. They say it's the "lifeblood of Windows". No, it's the lifeblood of the new Microsoft. Your life.<br />
<br />
So why not stay on Windows 7? The ecosystem will continue to rot, and eventually it will become difficult to run Windows 7 on modern hardware. Microsoft has even started actively looking for ways to make Windows 7 <a href="https://www.theverge.com/2016/1/16/10780876/microsoft-windows-support-policy-new-processors-skylake">not runnable on new hardware</a>. Windows 7 is almost as bad as Windows 10, but at least, when you disable the Realtime mode in Windows Defender it stays disabled. Windows 7 is not ultimately a good solution. If you have Windows 10 Pro, you might find that the Group Policy editor provides a "close enough for rock and roll" method for disabling Windows Defender, via group policy. If you have Windows 10 home, that method is not available. Windows 7 has many of the same flaws (superfetch, boot time problems, update problems, windows defender problems) as Windows 10, but overall the symptoms are not as bad. The most egregious problems in Windows 10 are somewhat less of a problem in Windows 7. <br />
<br />
What is the solution? I don't have one. I'm just mad.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<b><br /></b>
<b><br /></b></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com8tag:blogger.com,1999:blog-6444609270251748954.post-13382613078158954822018-02-08T15:16:00.004-08:002018-02-09T13:38:25.941-08:00The Concise Delphi Coding Standard<div dir="ltr" style="text-align: left;" trbidi="on">
<b>The Concise Delphi Coding Standard (2018)</b><br />
<br />
1. Use the Delphi Source Code Formatter on New Units before you Check them In. When you touch a function keep its formatting style the same, or reformat the whole function with the Source Code Formatter. Only that one function you touched. Use your team's settings which are shared within your team.<b><br /></b><br />
<b><br /></b>
2. Do Not Randomly Reformat Entire Files because of Coding Standards. <b>If you need this point explained to you in detail, you need a lot of re-education about version control.</b><br />
<br />
3. <a href="http://delphicodemonkey.blogspot.ca/2014/06/i-officially-hate-hate-hate-with.html">Avoid WITH </a><br />
<br />
4. Avoid <b>obfuscation, </b>including unnecessary accidental complexity, avoid unreadable code, very long functions over 80 lines in length are completely unreadable, and are a form of obfuscation, as are placing things far apart that shouldn't be far apart. Avoid that.<br />
<br />
5. <b>Bend, don't break.</b> Do not start holy wars over spacing, indentation, and variable naming, or any other thing in any coding standard ever. Find a peaceful way to defer like everybody defers to the Graybeard, or whatever. Just bend, and go with the team. Do not turn coding into an emotional bloodsport.<br />
<br />
<b>Fin.</b><br />
<br />
<i><b>Postscript:</b> </i><br />
<i>There's actually only one thing in the above list that's explicitly delphi specific. But the VCL source code formatter's default settings are pretty reasonable. I prefer to add line breaks to uses clauses as that enhances readability, reformatting the following into one unit per line, which with the addition of Delphi namespaces makes Delphi uses clauses a lot more like reading the import list of a java or C# module:</i><br />
<br />
<br />
<span style="font-family: "Courier New", Courier, monospace;"><br /></span>
<span style="font-family: "Courier New", Courier, monospace;"><br />uses<br /> Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, Mask, ExtCtrls, AdvGlassButton;</span><br />
<br />
<br />
<br />
<br />
<br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com3tag:blogger.com,1999:blog-6444609270251748954.post-29442067448917753532018-01-31T12:26:00.001-08:002018-02-01T15:26:29.189-08:00How to Bring Delphi Back from Life Support<div dir="ltr" style="text-align: left;" trbidi="on">
I was recently commenting on Facebook and asked what could the community do to help Delphi get more popular again. My answer? Uh <b>Nothing.</b> <br />
<br />
A real change would start with the product actually getting a serious refresh, something probably that nobody can afford to do, and which Embarc<b>Idera </b>is extremely unlikely to fund.<br />
<br />
Cue up a nostalgic 80s song, maybe Glory Days, by Bruce Springsteen. Grab a beverage. I'm about to rant.<br />
<br />
<div>
The Glory Days of Delphi were from the Delphi 5 era until Delphi 2005, where the product foundered severely. 2005 was so bad, and 2006 was only slightly better, that few people could use it. To this day I encounter companies still using Delphi 5 or 6 or 7 because of this ancient developer and QA failure made in the tail end of the Borland era. Let's face it. Shipping Delphi 2005 was the worst thing that the management ever did to the product's reputation. Even worse than the well known shenanigans at their Sales level where they were pushing their (now dead) Java IDEs on their existing Delphi accounts.</div>
<div>
<br /></div>
<div>
The blowback from the instability of 2005 was actually less than the blowback for the UI changes. Developers (it me!) are a surly bunch. You moved my buttons. Damn you!</div>
<div>
<br />
Now the UI changes were <b>well intentioned, and well done</b>, and were intended to bring Delphi out of the Win3.1 era UI of Delphi 5 through 7, and into a docking style IDE, comparable with Visual Studio 2005. I like the new UI in 2005+ delphi editions better than the old UI, but the point is that the old IDE was more stable. <br />
<br />
<b>There has not YET been another full refresh of the IDE.</b> Delphi has continued to be usable, and a good productive tool, and while it's IDE architecture continues to look worse by comparison with its one time equals, it is now so far behind it's not even funny. Remember there are people using FoxPro and Visual Basic 6 IDEs and loading them up in Windows 10. We're more like them, than different, at the moment. The registry key where delphi gets installed gets a regular major version bump, we're at what 18.0 now? But <b>the IDE architecture is frozen in time.</b></div>
<div>
<b><br /></b></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://media.giphy.com/media/KaW6fNYZf6eSk/giphy.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="390" data-original-width="500" height="249" src="https://media.giphy.com/media/KaW6fNYZf6eSk/giphy.gif" width="320" /></a></div>
<div>
<b><br /></b></div>
<div>
<br /></div>
<div>
The bds.exe code of 2018 is mostly the same in operation, and contains most of the same assemblies and parts (binary dlls) as the bds code of 2005, with the addition of creaky refactoring code built in J# (yes JSharp, that no longer supported .net 2.0 language), error insight that doesn't work (due to having its own parser which doesn't parse all the language features, or even the compiler search path behaviour of the real compiler). The editor core in C++ is buggy to this day and crashes, and loses people's work. </div>
<div>
<br /></div>
<div>
<b>A lot of talented people worked really hard and fixed a lot of bugs, and Delphi XE8 and up, including the current Delphi 10.x series are very stable IDEs. Don't get me wrong. I appreciate that work.</b></div>
<div>
<br /></div>
<div>
But what we have here is a polished antique. The editor core is basically the code from Borland C++ for Windows' editor, from about 2001. The code is a legacy codebase, and it needs a total IDE overhaul.</div>
<div>
<br />
The delphi DCC32 and DCC64 compilers are relatively good compilers, excepting that there is no <b>significant OPTIMIZATION available for DCC64 still</b>. If you are familiar with the level of optimization work done in modern C++, and you compare it with Delphi in 2018, you're gonna be sad. I think that the Nextgen picture may be significantly more rosy with LLVM's optimizers at work, but that's never going to be an option when Nextgen was designed from the ground up to contain many breaking changes to your code, including string handling, and other fundamentals. <b>That's not gonna be pretty.</b></div>
<div>
<br /></div>
<div>
But the Compilers, classic and nextgen, produce really fast code, even though they are not at parity with say, the Visual C++ 2017 optimizing compilers. I'm actually fine with that. I actually still kind of <b> hate C++.</b> Pascal is a beautiful language.</div>
<div>
<b><br /></b></div>
<div>
<b>The bigger problem is the IDE is not very good. </b></div>
<div>
<br /></div>
<div>
Spend 16 full hours getting work done (pair programming) with a colleague who knows what they are doing in Visual Studio (perhaps with resharper or not), or IntelliJ IDEA and you will realize that what we mean when we say "IDE" in delphi is at a point similar to what <b>Most IDEs Were Capable of Circa 2005.</b></div>
<div>
<b><br /></b></div>
<div>
<b>Alright Smart-Ass What would You Do Differently?</b></div>
<div>
<b><br /></b></div>
<div>
Fair question. If you gave me a 6 million dollar development budget and two years I would rearchitect the IDE, but not the compiler, or the language specification:</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<b>1. Subprocesses are key. Yes, yes it will use more memory. It will crash less. Are you sold yet?</b></div>
<div>
<b><br /></b></div>
<div>
1.1. Make the editor core a subprocess (RADStudioEditor.exe). Less crashing. Large file search/replace should even be able to happen in background in parallel.</div>
<div>
<br />
1.2. Make the compiler and code completion engine a subprocess (RADStudioLanguageServicesEngine.exe). Kibitzing compilers, code completion and error insight compilers would share a single tokenizer/lexer and grammar.<br />
<br />
1.3. Make the IDE main window (shell) a lightweight shell written in Delphi (RadStudio.exe).<br />
4. Make the form designer also a subprocess (RADStudioFormDesign.exe). This subprocess would be capable of loading a set of BPLs needed to open the form.</div>
<div>
<br />
2. <b>First do no harm. Don't Tread On my DFMs. </b>I would fix the ancient frustration caused by failure to locate and install all BPLs that a form requires before you open a form. It would be possible to open a form without the damn thing DELETING YOUR COMPONENTS. Similarly, all the places where it asks you sixty million times in a row are you sure you want to delete your components would default to no, don't bug the user, and don't do destructive stuff, instead fall back gracefully and do nothing. Those fun times when you have to open task manager and kill delphi to get it to stop asking you 9 million questions. Good times.</div>
<div>
<br /></div>
<div>
3. <b>Stability is key. </b>When a BPL fails to load or segfaults, instead of the IDE going down, you would lose one DFM editor tab. </div>
<div>
<br /></div>
<div>
4. <b>Modern editor features. </b>Delphi's next IDE needs navigation and quick look features on par with IntellIJ IDEA and Visual Studio 2017.</div>
<div>
<br /></div>
<div>
5.<b> Unified compiler and code-completion (kibitzing) engines, with a single root grammar and Lexer. </b>The compiler and the code insight engine need to work similarly to the modern architectures used in Visual Studio and Visual Studio Code.</div>
<div>
<br /></div>
<div>
And a few things I would NOT do:</div>
<div>
<br /></div>
<div>
<div>
<b>1. We Don't Need No Stinking New Language Keywords because We Are Not Jealous of C++. </b>The language in Delphi is actually it's most important asset. Adding crap to the language is not gonna make it better. Delphi is kind of beautiful and clean, like Google Go. I actually think the syntax of anonymous methods is the ugliest part of the current language spec. I'd like to stop now before we end up with crap like they have to deal with in the latest C++ language spec. Delphi's module system, and runtime plus compile time typing system are better, in my opinion, than C++'s mostly compile-time-only type systems, and current lack (in 2017) of modules. I don't want to copy C# either.</div>
<div>
<br /></div>
<div>
<br /></div>
</div>
<div>
<b>2. Break stuff. </b>I would not break anyone's code, DFMs, .pas files, etc. Absolute compatibility is the only way to guarantee you can upgrade. The decisions already made to break stuff in nextgen, while I understand the difficulty that lead to the reluctant change, I still thing are going to be the undoing of the entire thing.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
Would 6 Million American Dollars be enough budget to do all the above? Would it take 2 years? That I don't know. I just know it would take a lot of work. And given that the business case for the above might be that the payoff would be around $4 million dollars, it remains probable and possible that doing all the above is a business mistake. </div>
<div>
<br /></div>
<div>
What I do know is that the above is the list of things being NOT fixed, are among the things that would make most young developers who know any other language, and even most old farts like me, want to Stay The Hell Away from the product.</div>
<div>
<br /></div>
<div>
When Delphi works, great, it's a joy to use. A proactive solution to the long term trouble with Delphi stability requires a modern multi process architecture, and a significant R&D commitment. It would also be nice if you still had some key developers who knew where all the bones are buried. If you didn't have all that, I'm just saying, that maybe six million dollars is still not enough to do the work above.</div>
<div>
<br /></div>
<div>
The market realities today are stark. You can get a trial of IntellIJ IDEA for free and run it for months, and you only pay a few hundred dollars for it if you buy it. Visual Studio Community is freely downloadable and is the default choice for Windows-Centric developers today, which is funny because WinForms and WPF still suck. </div>
<div>
<br /></div>
<div>
Delphi is a niche product today, an important and interesting one, but it's probably never going to be even 10% as popular as the big boys, ever again. I still think it's a great thing to build Win32 apps in, and I do wish it wouldn't eat my DFMs and my code on me.</div>
<div>
<br /></div>
<div>
Rant over. [Mic drop]</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://media.giphy.com/media/xT9DPhONuz1SpCONiM/giphy.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="300" data-original-width="300" src="https://media.giphy.com/media/xT9DPhONuz1SpCONiM/giphy.gif" /></a></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<i>Postscript: </i><span style="font-size: x-small;">A very senior Delphi Developer where I work pointed out that another core Delphi IDE design mistake is that the Library Path, and Component Installation Registry keys, and other similar items, exist at all, at a global level, which is not committable to source control, but which does affect your ability to open, share, and build codebases in Delphi on multiple developer machines, and that these settings should be per-project and be as files on disk, not in the registry. I agree with him heartily, and feel he was right when he said that is perhaps the single worst problem with the current IDE design. If I were to replace the existing crap, I would introduce a concept like Workspaces in most java IDEs, such as IntelliJ IDEA, to the Delphi world. A copy of the files and their workspace should be all you need to transport and build Delphi code anywhere. And it should be possible to load different versions of different components into different projects without the egregious workaround of <span style="font-family: "Courier New",Courier,monospace;"><i>bds.exe -Rsomething</i></span></span><br />
<br /></div>
<div>
<br /></div>
<div>
<b><br /></b></div>
<div>
<br /></div>
</div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com32tag:blogger.com,1999:blog-6444609270251748954.post-89163424044906662342017-09-12T15:21:00.005-07:002017-09-13T10:23:37.636-07:00Agile is Dead. Long Live Agility and Pragmatism.<div dir="ltr" style="text-align: left;" trbidi="on">
The luminaries who signed the original Manifesto for Agile Software Development in the 1990s have come back more recently, including Dave Thomas who said that "Agile is dead" in 2015, as part of his reflection on what went well, and what didn't go well, in the Agile Software movement they started.<br />
<br />
As often happens, practices which had an intent, a purpose, a meaning, and an effectiveness, can lose that purpose, meaning, and effectiveness. <a href="https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html">As Dave Thomas laments, the Values get lost behind the Implementation, and Agile Software Development, shortened ludicrously to just "Agile", has become that which it mocked, and sought to replace.</a><br />
<br />
That being said, I actually appreciate the core values that underpin the Agile manifesto, even while I advocate a <b>skeptical approach to all methodologies. Don't drink the kool aid. Question. Gather data. Use Data and your ability to Reason. </b>You can be a skeptic of ALL methodologies and also be a bit of a proficient practitioner of one of them, Agile or another.<br />
<br />
In my current team, we're actually doing a really light set of "Fairly Agile" practices. I've been on this team nine months now, and I really like the way we work. The things we do are things that give us lots of positive payback.<br />
<br />
Here they are:<br />
<br />
<i><b>1. Code Reviews</b></i><br />
<i><br /></i>
<i>Shipping code is reviewed (hopefully actually read) by more than one developer. We use a distributed version control system (git) and pull requests to do our code reviews. We use bitbucket. In my previous job we used git with gitlab, which also worked great.</i><br />
<i><br /></i>
<i><b>2. Light Daily Standups</b></i><br />
<i><br /></i>
<i>Our daily standups are in Slack (text chat) 3 days a week, and are video two days a week. Our team is mostly remote and disbursed. The video standups are much longer than the usual standup time. But since the team is distributed, and there are relatively few other meetings, we are able to spend a lot of each work day building things.</i><br />
<br />
<i><b>3.Lightweight "Paperless" Audit Trails : Slack All The Things. Don't Email.</b></i><br />
<br />
<i>We don't ship changes to code that aren't tracked in an issue tracker. We don't make discussions verbally, or in emails. We default to public place accessible by all employees (slack chat) for all architecture and UI changes. Emails are private and are thus problematic for the team, or else turn into an unsearchable tar pit, and may as well have never been sent, as you can never find anything.</i><br />
<br />
<i><b> 4. Pair up when you need it.</b></i><br />
<i><br /></i>
<i>We have a practice of teaming up with another developer whenever that would help get us unstuck, or do something that one person alone couldn't do. We don't do that frequently, but we don't do it NEVER. We do it when it works.</i><br />
<br />
I think these practices are great. I don't think we're doing everything perfectly. I think a certain amount of discontent is actually a core value for pragmatic/agile/high-quality software developer work. For example, I wish our codebase let us write more tests. That's something we probably can get to when our codebases are decoupled enough to permit unit testing.<br />
<br />
What is your core "Agility" and/or "Pragmatic" practices list? What do you think makes your software team work effectively?<br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com0tag:blogger.com,1999:blog-6444609270251748954.post-251677136032433362017-09-12T14:56:00.000-07:002017-09-12T15:02:33.960-07:00Cool Advanced Troubleshooting Technique - WinDbg<div dir="ltr" style="text-align: left;" trbidi="on">
I was having some problems with my Thinkpad laptop hanging. It didn't blue-screen. It just stopped updating the screen, and did not reboot. It seemed either that the entire video layer had hung, or that the kernel itself had hung (such as waiting on a spinlock forever), or that a critical subsystem of my computer had failed (since windows uses virtual memory heavily, such a problem can also be commonly caused by a storage layer failure, such as your primary boot hard disk).<br />
<br />
What's relevant to this delphi blog,. is that it was Delphi's own debugger that most commonly triggered the hang. Exiting the debugger, terminating a debug session, was the most common way to hang the system.<br />
<br />
I've watched a few of the videos on MSDN Channel 9 from the guys called <a href="https://channel9.msdn.com/Shows/Defrag-Tools"><b>Defrag Tools</b></a>. This is some serious low level technical know-how that these folks are dishing out. If you're into it, go check them out. <br />
<br />
Anyways after a bit of troubleshooting, I decided to try switching out various driver versions to see if I can make the hang go away. After trying the OEM Intel HD 520 graphics drivers from Intel's website, I was able to work inside Delphi all day today with NO crashes.<br />
<br />
<br />
This is not my first "Delphi + Video Driver" hell experience. About two years ago, I had a crazy set of bugs in Delphi that only reproduced with certain ATI/AMD video cards, and only in parts of my Delphi application using Microsoft Direct2D/DirectX. Direct2D surfaces would just stop rendering, and whatever parts of my delphi application were using Direct2D apis just stopped working. A couple years before that, I saw similar problems with GDI+, also on ATI/AMD video cards. And going way back about 20 years ago, in the WIndows 98 era, I remember there were bugs in ATI video cards of the era that broke the ability of the Win32 GDI layer to render transparent bitmaps.<br />
<br />
But this one is the first time I've had a Delphi program, or Delphi itself, plus a bad video driver, actually hang my entire system, requiring a cold reboot to recover.<br />
<br />
More details on my question on superuser.com <a href="https://superuser.com/questions/1249460/thinkpad-edge-series-laptop-keeps-freezing-on-windows-10-intel-hd-graphics-520">here</a>.<br />
<br />
Some suggested ways to get started:<br />
<br />
1. install the Windows 10 SDK to get WinDBG installed on your computer.<br />
2. on a system which generates BSODs, enable memory dumps on your computer in your System -> Advanced Startup Options. In systems which hang without a BSOD, learn how to enable the Scroll Lock key way to force a hang.<br />
3. watch a few Defrag Tools episodes to get the flavor of how to use WinDBG.<br />
<br />
Note that full memory dumps are huge. If you have 64 gigs of RAM a full dump will be more than 64 gigabytes in size. On my 1 tb disk with about when my total free space is less than 16 gigs, a Helpful windows feature will automatically delete my dumps so that windows doesn't fail to boot. Try to have at least twice your total memory free on your main hard drive before you try enabling full dumps. If you have 64 gigs of ram, make sure your primary windows boot disk has at least 128 gigs of free space. For just a bit of learning with Windbg, just enable some non-full-memory dumps so you can get the flavor of the WinDBG tool, and try entering some commands.<br />
<br />
There are two "sides" to WinDBG, the kernel side and the user space side. In the kernel side, you can view call stacks, thread states, change which CPU you are looking at, list NT native kernel level processes, and walk back in time to various saved states. In the user space side, you can see the Win32 level APIs, processes, and walk back to a time prior to the last saved exception to examine the state of your system before the last first chance exception. Besides being able to see C/C++ symbols from non-managed DLL/exe images, you can also use some extensions to be able to see things from inside the CLR, so you can troubleshoot problems with .net code.<br />
<br />
Unfortunately, the debug information format used by WinDBG is not the same debug information format that is produced by Delphi so this tool is not very helpful for debugging Delphi application crashes, unless you don't mind working with uninstrumented disassembled code with no debug symbols.<br />
<br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com1tag:blogger.com,1999:blog-6444609270251748954.post-73778512405728620512017-04-27T11:24:00.001-07:002017-04-27T11:32:02.383-07:00Some Quick Delphi Opinions<div dir="ltr" style="text-align: left;" trbidi="on">
A few quick bits of opinion, and a question for my readers:<br />
<br />
<br />
1. Be it resolved that third party tool companies that offer fantastic support are an essential part of any small shop (that uses Delphi or otherwise). Be it resolved that RemObjects is about as awesome in the support department as it gets. I've been a fan of DataAbstract and the RemObjects remoting SDK, for Delphi and for .NET, for a long time. Recently I was trying to upgrade an old project to use the latest version of RemObjects DataAbstract. The "remobjects connect" site where you get support is fantastic. Unlike a lot of places, you get answers (and if there's a bug, fixes) really really fast. Shout out to Marc Hoffman and the other excellent people at RemObjects here. You guys are great.<br />
<br />
2. It is essential to modern development to have a second editor, or two or three. The more editors you know, the better, up to the point of diminishing returns, which is about six editors, as far as I can see. I actually regularly use three editors even when working with a powerful IDE like Visual Studio or Delphi. There are things I can do with Notepad++ that I haven't learned to do with anything else. And for searching code, I just love Visual Studio Code, and it has a great Pascal plugin. And there are things I can do with VIM that other editors just can't do. If you haven't messed around with Visual Studio Code yet, please please download it and try it. You'll thank me. And if you're bored some day when you should be coding, try learning VIM. You'll accidentally become more productive, especially when you need to large or very precise edits across a large set of files. Agree with me here? Disagree? Discuss.<br />
<br />
3. Question for readers: Have you tried Delphi 10.2 tokyo on Linux yet? I'm planning to try that out soon. Will probably write about what I figure out when I have time to play with it.<br />
<br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com6tag:blogger.com,1999:blog-6444609270251748954.post-17873902243632543022017-04-06T11:57:00.001-07:002017-04-06T11:57:08.101-07:00Nick Hodges Book Bundle<div dir="ltr" style="text-align: left;" trbidi="on">
Just wanted to give a shout out to an Excellent Delphi Dude, Nick Hodges, who has recently made available a bundle of his three recent and very well done Delphi books, in a single bundle.<br />
<br />
I have actually only read two out of the three, but based on the quality of those, I can unhesitatingly recommend that you buy yourself a copy of these three <a href="https://leanpub.com/b/nicksdelphibookbundle/">excellent</a> resources for Delphi developers.<br />
<br />
Nick's book bundle is on leanpub <a href="https://leanpub.com/b/nicksdelphibookbundle/">here</a>.<br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com3tag:blogger.com,1999:blog-6444609270251748954.post-41598844632820006952017-03-21T17:25:00.000-07:002017-03-22T05:10:54.984-07:00Not Just Code Monkeys - Martin Fowler<div dir="ltr" style="text-align: left;" trbidi="on">
I recommend everyone watch Martin Fowler's 2014 talk, which was given to its original audience without a title, and the title was then explained and introduced at the end.<br />
<br />
It's called Not Just Code Monkeys.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/Z8aECe4lp44/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/Z8aECe4lp44?feature=player_embedded" width="320"></iframe><br />
<br />
<br />
Watch it first, and I have only two things to add, after you've watched it:<br />
<br />
1. I think that Martin Fowler's idea that we as developers need more of the attitude that formally licensed Engineering disciplines (Electrical Engineers, Mechanical Engineers, Civil Engineers) have, even though I am (like Fowler) a bit skeptical of formally licensing software developers.<br />
<br />
2. I think that software developers can be agents of social progress, and like Martin Fowler, think we have a duty to not co-operate in immoral and evil actions carried out with software. Bob Martin, another software developer and conference speaker I greatly admire, recently blasted developers who would, for example, do what the developers in the Volkswagen emissions scandal clearly did; To do something that they ought to have known was wrong. Sure, the bosses at the company should be held accountable. But it took technical skill to carry out that fraudulent activity, and engineers were complicit in the evil that was done.<br />
<br />
Don't be evil. And don't put your head down and just think of yourself as someone who slings code. You can make the world better. Or worse. Which will you do?<br />
<br />
<i>Update: A more recent example of evil in firmware: John Deere tractors now contain firmware which effectively blocks farmers from repairing their own tractors. Their <a href="https://www.deere.com/privacy_and_data/docs/agreement_pdfs/english/2016-10-28-Embedded-Software-EULA.pdf">license agreements</a> also say that you don't really own your tractor, you just have a license to use it according to their terms and conditions. This (rightly) angers a lot of farmers. You wouldn't catch me implementing that kind of crap in an embedded system. It's evil.</i><br />
<br /></div>
Warrenhttp://www.blogger.com/profile/04053407632823479165noreply@blogger.com0