Darian Miller

Since the actions all involve FReader, I'd move the method into FReader's class instead of TBla. I think it makes it much more readable (as the general rule of thumb is - the fewer dots the better) Also changed the method name as you suggested in the thread. Bonus issues: Changed Utc.IsZero to a new Utc.IsValidTimeEntry as that logic belongs to TMeasurementTime, not this method. Depending on the nature of the Reader, you might need to save the current position and restore it afterwards with a try/finally block to squash any changed-state issues. Also changed to use a Exception class scoped to the Reader. 'Seek' seems a little oddly named method here... more like a 'Goto' or RecordNumber assignment. (Maybe add a custom enumerator and use FOR/IN and get rid of the method call) Might also make a resource string for the exception text. procedure TReaderClass.GetFirstValidTimeEntry(out _UtcValid, _TimeByUtc:TMeasurementTime); var i:Integer; Utc:TMeasurementTime; begin for i := 0 to Count - 1 do begin Seek(i); Utc := Data.Time; if not Utc.IsValidTimeEntry then begin _UtcValid := Utc; _TimeByUtc := MeasurementTime(i); Exit; end; end; raise EMyReaderException.CreateFmt('%s has no valid entry', [DataFileName]); end;

NVMe drives ... SATA or PCIe? I have a PCIe... Samsung 970 EVO with 3500 MB/s Read and an older Samsung SSD 960 PRO with 2100 MB/s. These are fast, but apparently they can get twice as fast as that now. Might need to get a Christmas present to myself... 32GB of RAM should be plenty. If builds are only peaking 21% CPU then you are probably maxed out there too. You should be pretty speedy already. There are software optimizations... like Excluding your source and output folders from Antivirus.

Given enough RAM to dedicated to the O/S and at a few GB left over for apps, I think NVMe drives are rediculously fast and can be the best $-per-wow spent. They can read 7,000+ MB/s and write nearly as fast. They will put a pep in your step. I'm using Intel, but I see a Seagate Firecuda 530 with 7,300 MB/s sequential read and 6,900 MB/s seq. write which is enticing.

Refactoring remains broken with inline variables. I assume they are the probable cause of your particular failures. There are multiple issues with inline var refactoring, such as https://quality.embarcadero.com/browse/RSP-33176 I plan to stay away from using inline vars until the tooling catches up. (Also issues with debugger: https://quality.embarcadero.com/browse/RSP-23096) I've experienced some odd things in the RS11 IDE - for example, occasional structural highlighting fragments occur in the editor so I've temporarily disabled that feature as it gets too distracting. On the other hand, the IDE feels much more responsive and looks much cleaner.

Synopse documentation builder has some of this built-in which might help... not sure how standalone it is. @Arnaud Bouchez

https://quality.embarcadero.com/browse/RSP-28948 See note from Marco on RSP-28948: May 14, 2020 "The formatter is not related with CodeInsight and LSP and is an area we plan addressing next." The recently released RAD Studio 11 now only offers LSP for CodeInsight (classic codeinsight has been retired) so I hope that project is now considered 'done' and I would also hope that a new code formatter is on deck.

FWIW, there is apparently an effort: https://www.crossvcl.com/

Check out

That's probably less than 30 days for me. 🙂

I stay away from rebasing. It just feels like a dirty approach. Perhaps I just need to do it more often but I probably won't use it unless I'm forced to. I started out with a 'sneaker net' version control system as we didn't have a network. A couple times per day I would copy a few source files to a floppy, walk down the hall and hand it to the one other developer to copy to his machine (or he did it with me.) We would merge changes manually. (We split up tasks to specifically keep merging to a minimum.) After months of this, we finally put in a network and shared files from a single location and used MultiEdit to modify the source. It managed the read only lock on the file to prevent two people from accessing the same file. We kept up with file locks with VSS for about a decade and then moved to SVN for the next decade. Large project, built over 20 years with millions lines of source with 10 or more Delphi developers each committing multiple times per day. We kept merges to an absoulte minimum and were quite successful. For a long time, I directly managed the workflow and kept the merging to a minimum based on task assignment. I think it's kinda rediculous to even contemplate 5 people editing the same DFM and attempting to merge UI changes (but sometimes it did have to happen.) Most UI conflicts were basically minimized outside of the VCS. I'll follow whatever the workflow is of the next company, and may hit you up on advice on rebasing if they follow that approach!

+1 for Videos as they can play while you ware working on something else. My favorite part about youtube is the playback speed feature. I normally crank it up to 2, but scale back down on occasion as needed. Alister Christie is a good example of having to scale it back. He articulates his words pretty quickly so at a speed of 2 it's difficult to understand so he gets 1.5. After my kids showed me this feature, I nearly always use it now. I have a hard time watching someone speak now at a normal speed.

Ask Dave Farley - that's his quote (and assumedly a large factor in selling his CI/CD training services.) I said 'apparently' there has been studies to prove it. I took Dave at his word, but also hedged my statement as I foretold a response. If you are making money doing what you are doing, then you are obviously doing something right. If you want to make more, then perhaps some well defined tweaking will improve the situation - but as we have all seen time and time again, new managers trying to dramatically and quickly change workflows typically end up costing a lot of producitivty and rarely succeed. In the recent developer interview process, I was quizzed on Chesterton's Fence and software development. They were happy with my response. I do not advocate for wholesale changes for a working system. If there are ways to improve it, and there also exists valid business reasons to enact those changes, then they should be considered. In this thread, if one is struggling with the real costs of too many branches, or not enough branches, then I suggest you watch Dave's videos and see what insight he has. He's a pretty successful person in this area. You reduce the need for branches by introducing Feature Toggles, Dark Launching, and Branching by Abstraction, but you don't necessarily eliminate them.

As the videos I posted conclude, apparently it has been proven that software is developed more quickly and more robust with CI/CD techniques which involve few (if any) short-lived branches. I tend to agree with that concept. Every situation is different and success is measured in different ways. I know what has worked well for me and what has not. I leveraged that knowledge to help me retire at a fairly young age. But I'm heading back to work soon after a few years of inactivity as I simply enjoy to code and retirement is somewhat boring (especially in an extended pandemic which doesn't seem to want to end.) And the place I'm going to apparently uses branches heavily, so that's what I'll do. It obviously works for them as they have enviable market share and have been making software for 30+ years. It's difficult to argue with success. So whatever is working well for you, certainly keep doing that but there's nothing wrong with thinking about improvements. It would be foolish to change something that's working solely based on some video or forum message.

Which is why I said they become more painful as time progresses. Managing branches 'properly' typically becomes increasingly difficult as the number of branches increase as the change scope creeps up and conflicts quickly mulitply. Branches typically defer and increase the pain of merging. It's best not to branch at all unless you can guarantee isolation, but if you can do that, then you can use other methods to stick to the mainline.

I suggest you be careful managing 'many branches'. Merges become much more painful as time progresses. Choosing the appropriate branching method heavily depends on the type of product and how it's deployed to the users (and how many distinct active versions you maintain.) Since you are a single dev team - you get to pick the least painful, most productive way to maintain your software. Here's another reading source for you: https://trunkbaseddevelopment.com/ There is no 'perfect' way of doing things. One of my mantras has long been "Progress, Not Perfection" If you slowly get better over time, your cumulative progress will add up rather quickly. This counters the real fact that "change is painful" On my team, we went years avoiding pain and it just made things much worse. So it seems like you are on the right path - keep poking away and things will get better.