Yesterday I saw both the best and the worst of chat coding. I'll explain the scenario first before I get into what happens. One screen in the management program displays for each therapist/worker how many hours were worked or meetings held by that person in the previous month. The data is displayed in an internal web browser control, where the contents are in hand-written HTML; this means that I wrote queries then took the values and enclosed their values with my own HTML. This code was written at least 10 years ago when we didn't have chat coding. It works very well so there's nothing worth improving (so I think).
Should the person running the program so desire, the monthly report for a therapist can be sent via email; this basically means taking the already written HTML code and enclosing it within an email. I wrote about this years ago. Not only that, the report is saved in the database so it can be retrieved at any time. A second screen displays a list of such saved reports within a given time period, and should one so desire, a report can be retrieved and shown in a third screen, which is simply a web browser.
All seemed to be fine until I noticed that the user reports that I had created and saved that day were appearing in the reports list without a subject (title). I then spent what seemed to be an hour chasing the problem with CP; it was frustrating because everything seemed to be ok, but it wasn't. Eventually I uploaded the screen's DFM file and CP saw immediately saw what the problem was: the field before the missing field was defined as a string field of length 20,000 characters when in fact it should be a blob. So I corrected the query and the parameter, and saved some more reports. These appeared with subject in the intermediate screen.
But when I tried to access the saved reports, I saw what is normally referred to as gibberish: Chinese characters flowed across the screen. Reports that had been created prior to yesterday (in fact, prior to the redefinition of the field as a blob) displayed correctly. CP decided that the problem was with the web browser component that is based on IE7, i.e. very old and not particularly compatible with unicode. So I replaced the web browser with the edge browser component that is the new standard component for displaying HTML ... and then discovered that the component itself did not appear on the form. Ah, said CP, you have to initialise the browser. No change. Ah, said CP, you have to wait for the browse to finish initialising before you can display your page. No change, the browser still does not appear. Ah, said CP, you need a specific dll that you probably have on your computer. Copy the file to your program's directory. No changed. Ah, said CP, download a new version from such and such a website and make sure that you have the correct version (32 bits or 64 bits). Even that didn't work and I'm not sure that I was even downloading what I needed.
Fortunately - if that is the correct word - we had an air raid alarm (two missiles fell not far away from us) so I could disconnect from the computer and think a little. When I returned, I told CP that we were returning to the old web browser component because this worked. I then discovered that the original text wasn't being saved in the blob field in unicode (I checked via the database manger) - it was being saved as ANSI - so I resurrected a routine from the database migrator1 and used it to save the text. This of course required that when the text is retrieved from the database, it also has to be converted. Finally the reports were being saved with subjects and could be shown correctly after retrieval from the database.
I then took the dog for a walk and thought about how I could turn the code that we had just written into a library routine. I was using the 'save' routine several times (and I suspect that I will need it again when I get to saving general emails) and it seemed excessive to write the same code over and over again, but it was also tightly coupled to a query. When I came back from the walk, I told this to CP who responded with a unit that included routines for saving and retrieving unicode blobs. A bit later, I required another similar routine that CP wrote which I added to the unit.
The book itself isn't too useful as it talks about tools and AI agents that I don't use and don't have access to. I am sure that they consider Delphi to be very old fashioned, but if it gets the work done then it's good. I want to quote two passages from the book.
When Gene first started vibe coding with Steve, Gene was convinced that the then-new OpenAI o1 model would be great at ffmpeg and could help him overlay captions onto video excerpts. That is to say, subtitles on YouTube clips. Two hours later, Gene ran around in circles, typing increasingly complex ffmpeg commands. The AI was more than wrong; It was confidently wrong. Thinking about that particular Sunday afternoon still causes Gene to clench his jaw. But he learned an important lesson on when to give up on using AI to solve certain types of problems. It was a crummy experience, but he learned from it because it was a crummy experience. You learn by doing.
Here are some other takeaways from this early vibe coding session: AIs are capable of handling small to medium tasks, including in less popular programming languages, and using fairly complex Unix command-line tools. You interact with AI as if it were a senior pair programmer who’s so distracted that they can make serious mistakes from time to time.
The book did inspire me to think of some tasks that I would like to look at after the migration has been finished. I would like to improve the visual aspect of the program: I am a person who thinks in terms of tables and not graphs, so the visual aspects aren't too important to me, but I would like to see how they can be improved. Another task is the problem of choosing multiple values for a parameter, i.e. instead of choosing one customer for a report, several customers can be chosen. I have this functionality but I want to see whether it can be improved. I have thought of one way already, and as this functionality is contained within one specific unit (but is used by many others), it would be quite easy to test.
I would also like to define metadata for the database. For example, if a report uses the field 'name' from the table 'customers' then automatically that field should have the title 'customer name' (in Hebrew) Similarly, 'surname' and 'forename' from table 'people' or 'name' from table 'therapists'. The fact that I want the title in Hebrew is incidental; even in English, the default name for customers.name is 'name', not 'customer name'.
Internal links
[1] 2075
| Title | Tags | ||
|---|---|---|---|
| 164 | The big chill | Films | |
| 239 | Pesach over the years | Jewish holidays, Obituary, Habonim, David Lodge, France | |
| 342 | I haven't disappeared off the face of the Earth | Peter Robinson, Van der Graaf Generator, Ian Rankin, Steig Larsson, BCC, Jo Nesbo | |
| 343 | The camino pilgrimage | David Lodge | |
| 466 | Nobel prize winner visits MBA | MBA | |
| 1019 | The label number bug | Priority tips |
No comments:
Post a Comment