|
snorkie wrote: We're getting pressure from one of our customers to internationalize our software product
Basically if you want to sell in France and/or Quebec (Canada) you better be able to support French.
snorkie wrote: One of the devs wants to remove the resx files and put all translations in a database table (actually 3)
Certainly not something I would want to see happen.
The UI is going to just end up caching that every single time. What happens if someone does a browser refresh? Do you load each page or everything all at once? If you have 1,000 distinct text items on a new page do you really want to do a pass through cache (1,000 separate database calls.)
There would of course be process (not code) considerations for how it gets into the database during normal feature deliveries. Does it end up being treated as a database update which means there are also rollback considerations if a feature fails?
Same consideration applies to all non-prod boxes also such as Developer and QA.
What happens if the if the database is down?
I think the 'dev' that wants this should be required to write the conversion Epic along with all of the stories and designs needed to support it. Then cost it out and present that, the cost, to management. I suspect that will be nixed by management even presuming the 'dev' has the willingness and expertise to fully write out the plan. It should include at a minimum.
- Specific analysis of why this is better.
- How UI uses it. Specifically what needs to change in the UI.
- Performance impacts
- Deployment steps for changes
- Removing the old code.
- How this will be supported with current translation service.
snorkie wrote: There are also some database translations where we allow customization.
Presumably a customer can change this. That should not be a consideration for this case. However if a customer wants to support users with different language needs does that existing design account for that?
|
|
|
|
|
I'm looking for a replacement for the VLC Media Player, because it does not support IPv6. Here are some of my requirments:
- Supporting both IPv4 and IPv6
- Integration to WPF
- Sixteen Cameras
- Taking Snapshots
- Support audio and video codecs ( H.264 / H.265 and AAC / MP3 )
- RTSP and HLS Stream
- Playing DVR Data
- Start/Stop
- Debug Logs
- Custom Parameters
- Custom Menu for player
- Set volume
- Disable Keyboard/Mouse input
- Custom Menu for player
- Player Events
- Mediaplayer Events
- Track/Stream Info
- Set Crop Rectangle
- Select channel to play the audio(e.g., Left vs Right)
I've looked at LeadTools, which his pretty good and there documentation and support are nice, but it's expensive. I've also been looking at 'ffply'.
Anyone have an suggestions?
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
modified 20-Oct-23 15:00pm.
|
|
|
|
|
I'm working on a WPF app that connects to SharePoint.
From time to time, upon connecting, I get a 'Server not availale' exception. Sometimes I get the error while downloading data. It's intermittent and I can't seem to reproduce it. I restart the app and it works fine.
I could just catch it and retry, but I'd like to get your thoughts on the best way to deal with this.
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
If you're downloading "a lot of data" (or processing), you take "check points" so you don't have to "restart the app" from the beginning. This assumes the app (or "query") can restart / continue from a check point / sync point.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
GitHub - App-vNext/Polly[^] is "a .NET resilience and transient-fault-handling library that allows developers to express policies such as Retry, Circuit Breaker, Timeout, Bulkhead Isolation, and Fallback in a fluent and thread-safe manner."
As recommended by Microsoft[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
It is an external server. One should always design and code with the expectation that external calls will fail.
They can fail for the following known intermittent reasons.
1. The server is down
2. The network is having issues.
They can fail repeatedly for following reasons.
1. Something is incorrectly configured.
2. Your code is not correctly setting up the call. (Credentials, wrong message, invalid message, etc.)
There can be processing issues
1. The server never responds
2. The server takes too long (a timeout is exceeded.)
3. The server has an internal error and returns an error code.
4. The server returns an error code that suggests a retry is possible.
5. The server returns an error code that suggests a retry is not possible.
There can be other known/unknown reasons not in the lists above.
You can choose to implement a retry strategy but that can only work for some of the cases above.
The problem with retry strategies is the following
1. Are there situations where it must not be retried? For example if you just attempted to update the inventory by removing (data) 10 items do you want to keep retrying that again and again for every possible error? That could be a problem if the server is in fact succeeding (the 10 were removed) but then fails when attempting to format a correct response back to you.
2. Are there situations where it will never work so retries are pointless?
One must also evaluate what retry strategies can do to the entire enterprise. For example if simple retries are in place and there is a chain of 5 services that keep retrying (service A retries B which retries C etc) what happens to the original caller while they wait?
Even more complicated what happens with timeouts? If service B has three retries at 90 seconds each and service A also looks for timeouts then a single call to B would require a minimum timeout of 270 seconds in A. And B would need 3 of those. Presuming of course that A even knows that B is using a timeout like that.
|
|
|
|
|
You can find a solution in recommendations X.215/X.225 ... 
We did have a standardized solution to this 40 years ago, in 1984. But it was too ambitious - you couldn't give IT students a homework assignment of implementing the OSI Session Layer. You could have them making a primitive implementation of, say, (too) Simple Mail Transfer Protocol, (too) Simple Network Management Protocol or (too) Simple File Transfer Protocol. Besides, the Internet standards were freely available, while OSI specs were copyrighted and expensive. So the Internet Protocol Suite won the war against OSI.
In 1984, you may say that OSI Session was overkill (considering resources available at the time). If it had been generally available for 40 years, we certainly wouldn't have considered it overkill today. There might be running implementations out there, even today, but I don't know of any.
|
|
|
|
|
Posting an architecture/design question without a picture might be a challenge in itself but I'll have a go anyway
While a primary/secondary (previously master/slave) can be implemented by oneself I was wondering whether this doesn’t come out of the box in a container orchestration management system.
Requirements:
- High availability (redundancy) but doesn’t need scaling (capacity).
- Orchestration decides which one is Primary/Secondary (or Alternates (multiples)).
- Container and application (MyApp) knows whether its Primary/Secondary (or Alternates (multiples)).
- Only the primary application (MyApp) is communicating with the service x and the physical device(s).
- Only the primary application (MyApp) forwards the responses to the secondary (with a safe mechanism in
place) so that the secondary has all the data/states up to date at all times.
- Failover should happen within less than a second (e.g. 500ms).
Design:
|...Container Primary...|
|.......................| ------ Send Message -----------> |.....Service X.....|
|........[ MyApp ]......|
|.......................| < ----- Request/Response ------> |..Physical Device..|
....^...............|...
....|...............|...
..Check......Forward response from device
....|........so that secondary is always up to date
....|...............|...
....v...............v...
|..Container Secondary..|
|.......................|
|.......[ MyApp ].......|
|.......................|
Though I have left out the details I hope the overall requirements/concept is clear.
Questions:
- Is there a container orchestration management that handles primary/secondary concept?
- Most importantly will my application (MyApp) hosted in the container know when it's in what state (Startup, Sync, Primary, Secondary, PrimaryOnly)?
- How is it best implemented if there is an existing concept?
PKaelin
|
|
|
|
|
I don't think much of "forwarding". I prefer concurrent queues that "secondaries" subscribe to. It's naturally async; your design reflects only syncronous operations which have to stay in step.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Working on a WPF app. Currently, I have a table in SQL called Lookups that contains all kinds of lookup data.
Here is a set of that data called Employee Types.
<h2>Caption Category AppCode</h2>
Director of field Operations employee_types director_of_field_operations
Drafting employee_types drafting
Driver employee_types driver
Estimator employee_types estimator
Foreman employee_types foreman
General Forman employee_types general_forman
Office employee_types office
President employee_types president
Project Coordinator employee_types project_coordinator
Project Manager employee_types project_manager
System Administrator employee_types system_admin
Vice President
Each employee is assigned an Employee Type. I can the query for specific types of employees. For example, there is a Foreman report that gets all employees who's EmployeeTypeId is in the Lookups of AppCode 'foreman' or 'general_forman'. The AppCode is defined by me when I create new Lookup entries so I can reference them in code.
The problem is, now my client wants to be able to add and remove employee types via the UI.
I don't see how I can allow them to manage this list without the AppCode. I would have nothing to key off of when running reports or sending automated notifications to people in specific roles.
I can provide more detail if needed.
Any ideas on this?
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
When they create a new type (via a dialog) check for existing, then suggest a "code" based on the entered content after checking for an existing code.
This is the drawback of using a "code" and also storing different types of data in the same table - classic mistake. I know the argument that they are all lookups and they are all simple UNTIL THEY ARE NOT! You now have to faff about working around the problem instead of having an EmployeeType table with an ID as the primary key.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
But the problem is that my code can never know what the code is.
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
As Mycroft said, stuffing every lookup into a single "lookups" table is a bad idea. It makes life much harder when you want to evolve a single type of lookup.
Start by moving the employee types to its own table. The next step will depend on your precise requirements:
- If you only ever want to report on a specific group of employee types, then replace the
AppCode with a lookup to an "employee type group" table. When the user adds a new employee type, let them select the appropriate group, so that those types can be included in the relevant reports. - If you need more flexible grouping for your reports, add a many-to-many relationship between the employee type and the employee type groups. You can optionally let the user add the new types to one or more groups; if they don't, then those types won't be included in the reports.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
You have an application enum and now the requirement is to allow customers to manage the enum as well.
So first decision is one of these
1. Open it up entirely.
2. Allow them their own additional enums. Only the additions can be modified.
If the there is only one customer per table (how ever you designed that) then the caption can be under user control completely for all enums with the following rules
1. Must not be empty.
2. Must not be a duplicate of another.
Then the decision is how to store them. Probably easiest is going to be to add another column which flags it as a user value.
Then the other changes
1. Provide a UI to manage them. I would just show all of them. This is required to manage the caption anyways (above.) But also allows them to see groupings. The flag controls whether they can delete them. Naturally you will need a length limit.
2. Figure out how to allow the usage.
The second is tricky if you store them in another table. Such as a custom report. If so then you must either force them to remove the usage first before deleting or you must do it yourself.
|
|
|
|
|
... "and remove". Total disaster. Breaks referential integrity. The only way to "remove" "codes" is to "expire" them with a start and end date.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I am going to be creating a payment processing application using WPF for a client of mine. The app will prompt the user to select two files from a customer, crunch some numbers, and produce some output files. The input and output files will all be stored in SharePoint.
Here's the problem:
My client doesn't have a network. They store all their data in ShaarePoint, so there's no way for me to use a database.
The app has customer defintions, such as types of files, file layout info, processing options, etc. I can serialize all of this into an XML file, but problem is where to put the file? I could store it in SharePoint also, but there are multiple users. So if a user runs the app, starts making a change to a customer's configuration, then another user runs the app, makes a change, and saves BEFORE the first user is done, there will be lost data.
I'm open to suggestion
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
modified 7-Sep-23 11:29am.
|
|
|
|
|
I don't let "multiple users" change "configuration files". It's usually password protected and should be administered by a "responsible" person with the understanding "bad things will happen" if you fix it and it isn't broken.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
When I say config file here, I mean a serialized copy of the app's data. Since there's no database, then I need to store the app's data somehow, and a serialized file seems like the way to go.
But all users need access to that file, as it has to load on startup. And, each user could alter that data and save it.
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
Sharepoint is one big database. All those "lists" ... there all SQL tables. (Or views)
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
|
Not sure how that helps.
When I say config file here, I mean a serialized copy of the app's data. Since there's no database, then I need to store the app's data somehow, and a serialized file seems like the way to go. But all users need access to that file, as it has to load on startup. And, each user could alter that data and save it.
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
Quote: each user could alter that data and save it.
Fine, but that does not prevent you from storing it wherever you wish. The biggest drawback as I see it is allowing users direct access to modify a configuration file. Or do you mean that each user has a personal copy of the data?
|
|
|
|
|
No, there will be one serialized fiel that is read in on startup. But each user running it gets the data read in and could potentially change it. So how do I manage multiple people using that same XAML file?
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
Quote: So how do I manage multiple people using that same XAML file?
You don't; what you are offering is a recipe for disaster. Your application should read the file and then use a dialog/form to get any required changes from the user. As an experienced developer I am surprised you are considering such an option.
|
|
|
|
|
There IS going to be a dialog for Customers and their options. I didn't mean they will use an editor to change settings. But that doesn't solve the issue of more than one person modifying it at the same time.
Since this is just a serialized file (XML) that contains the app's info (List of customers and their processing options), and I likely can only store that file in SharePoint, then I'm stuck with how to keep users from overwriting each other's changes.
Scenerio: User A opens the app, which reads the app's data from SharePoint as a serialized collection. The user decides to modify a customer's settings and clicks save, which writes it back to SharePoint. User B then changes the same. User A's customer settings are now out of sync with user B.
In theory, theory and practice are the same. But in practice, they never are.”
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
