Leaderboard

Often the time spent for low priority tickets would better be used for refactoring the code - even if the only benefit is the developers better understanding the code and ease maintaining it. That might not impact your customers directly, but definitely on the long term. First implementing that low priority ticket instead may as well have the opposite effect.

There's no easy answer to this question, and it's one I've battled with for 20+ years. If it's a trivial change (< 10 min to code and test) and I think it's relevant (not all customer feature requests are, we have to evaluate how they apply to all users) I'll often just go ahead and do it immediately after reading the ticket. It's appreciated by customers, but a double edged sword, the more you do it the more they ask 😉

In my case (self-employed) this is actually wanted/needed as it means the customer is engaged and more chance it will be a long time customer.

Internal error are produced when the compiler is confused (Read: bugged). Sometimes it result from earlier error. The best thing to do is quit the IDE, manually delete all DCU (I don't remember if D7 already had the "clean" function. If yes, use it before stopping the IDE). The restart the IDE and compile everything. If this doesn't work, maybe you should use a newer compiler. Now there is the "community Edition" which is "pro" version, free of charge for everyone including business (Up to US$5000,- gross revenue).

I tried to keep the post as short as possible, but I guess it won't be possible My English is not very technical (or good), I must use some examples to help me explain. The client side platform has "ready to use frames" with editors placed at design time. Some frames are easy to create at runtime, I won't talk about those. Others not so easy (Customer, Orders, Contract, Services, Billing etc). So I derive from the my baseFrame and drop the corresponding controls at Design time. This is almost the only thing I can do. My users have different monitor resolutions, some have some sight problems, and sometimes Windows cannot natively display some information in a way they can read it. So in my application offer them a way to choose their favorite fonts and font sizes (some of them uses Tahoma 20 bold for normal label/editors). For this reason, I must resize the form in order to fit them as "designed". There other factors too, like for example skins (Some customer want me to design skin to match their logo, company colors and stuff ). Anyway, this is strictly handled on the client side. But as any other application there are some restrictions applied to users ( or modules). Fields they can't edit, or fields they can't see. Those are the definitions coming from the server. At server side, there are some "hard validation rules", like for example StartDate must be Less or equal do EndDate. This kind is still hard coded and I guess this falls into your strong binding UI Definition. I try to keep those to a minimum. But there are some soft rules that applies depending on the user ( or module ). For example, I must check if document number is valid when editing data on Module A, but that same document is optional for Module B, so no validation is required. Yet again, this rule can apply to Customer A, but Customer B wants both modules A and B to validate the document number. The way I implemented it all I have to do assign the "IsRequired" for that particular document number field of module A and Module B accordingly to that customer needs. The server side platform (REST API with JSON) is handling complex requests (Definition + Data) only from my client side platform. Third party system integrate with my server platform using another authorization scheme and a different REST API route. No UI Presentation to deal with. So far, no customer requested complex browser features. The mobile side is pretty simple too. Data entry is not practical at all so the UI must be very well thought, objective, touchy, battery and processor friendly. The only thing the app receives is Data, no definition or maybe some soft rules definition to display some nice glyph to the user in the next few months. Mobiles get their own set of "forms". This was a way I found to deal with all this UI presentation logic. This is just an example to help illustrate. I'm sure there are better ways to manage it, that's why I like it here! Always learning a better way to implement things Clément

Google Offers Financial Support to Open Source Projects for Cybersecurity: https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html I nominated The Indy Project since it's used by so many commercial Delphi-based projects. If others could do the same, it might help the cause. Or, suggest other libraries for support.