|
I`m not sure which branch this subject belongs to, D&A seems `general` enough so I`m attaching my question here. The question is is there a difference between the algorithms that operate with bits and those created for a quantum computer?
|
|
|
|
|
You can't approach Quantum Computing procedurally. (Sort of like one big simultaneous equation with all possible solutions until it's collapsed into one ... "optimum" solution).
Quantum Computing Vs. Classical Computing In One Graphic - CB Insights Research
"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
|
|
|
|
|
Thanks for feedback Gerry
|
|
|
|
|
The quantum computer mechanics work on the qubit which is a two-state quantum-mechanical system that is one of the simplest quantum systems and the bit refers to the binary digit system which is basically a unit of the amount of information in computer.
|
|
|
|
|
I have a WPF app that is part of a basic n-tier design. UI <=> BL <=> DAL. It's been under construction for a while and we just keep adding features to it.
At some point in the future, 6 months or so, the BL and DAL will be hosted in a Web API in IIS on the client's server.
Right now, parts of the UI are VERY slow. There is a Project view with a detail section on top and sub tabs below. All of the data is being brought back as soon as the project is opened, and it takes a long time.
I want to do some refactoring, such as:
- Lazy load the sub tabs. However, some tabs cannot be loaded unless data from other tabs is there. Other tabs are stand-alone.
- Everything is synchronous. Make back end calls async.
- If a tab's data is changed, for the most part the other tabs don't know about it. A few raise a changed event, but for the most part, the Project needs to be reloaded. Changes from other users are not reflected at all until the Project is reloaded. So I could keey the local data synchronized, but for data from other users, provide change notification somehow.
These are the top 3 issues. The big one is the load/save time.
For the Project opening load time and save time issue, one idea I've had is to create a 'package', which would just be a class with only the data that is needed to load the Project, and asynchronously call that when the tab is opened. Then, lazy load tabs as needed. They also would use the package concept to get only the data needed to populate that tab, which could be one or more lists of entities.
On save, load & send the Package class with only the data that has changed back to the DAL.
I'd like to hear what you guys think.
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I don’t know if this will work or not but it might change the way you think about it.
BL can be as fat (memory wise) as you want.
Think of each tab or just implement each tab as a separate page where it’s tab is highlighted/active and all of the other tabs are listed but have 0 data or even elements loaded.
The tab label is disabled if it is not possible to load it yet.
Why load stuff or try to keep it up to date if it is not visible? With 12 tabs, you could have 12*11 update patterns to keep track of.
The only concern becomes if an action on a tab updates a shared header area.
|
|
|
|
|
I have an application that reads a directory's files, displays them in a grid, and offers a toolbar with buttons that invoke functions that apply to all the files in the grid.
In the following code, reduced to its essentials, when the user clicks the Trim button in the toolbar, toolTrim_Click executes, opening the form that collects the options for the Trim operation, and then invoking the method that trims the pages from the list of files. That method then invokes for each file the method that trims the pages from that particular file. The async part is just to keep the window draggable.
private async void toolTrim_Click(object sender, EventArgs e)
{
var form = new TrimOptions();
DialogResult result = form.ShowDialog();
if (result == DialogResult.OK)
{
await Task.Run(() => filesList.TrimPages(form.trimFirst, form.trimLast, form.ifBlank));
}
form.Dispose();
}
public void TrimPages(bool trimFirst, bool trimLast, bool ifBlank)
{
for (int entry = 0; entry < TotalPDFs; entry++)
{
FileEntry thisFile = list[entry];
thisFile.Trim(trimFirst, trimLast, ifBlank);
}
}
public void Trim(bool front, bool back, bool ifBlank)
{
} What would be the pros and cons of refactoring the above code like this? The difference is that we move opening the options form to the class that manages the list of files instead of keeping it in the main form class.
private async void toolTrim_Click(object sender, EventArgs e)
{
await Task.Run(() => filesList.TrimPages());
}
public void TrimPages(bool trimFirst, bool trimLast, bool ifBlank)
{
var form = new TrimOptions();
DialogResult result = form.ShowDialog();
if (result == DialogResult.OK)
{
for (int entry = 0; entry < TotalPDFs; entry++)
{
PDFEntry thisFile = list[entry];
}
}
}
public void Trim(bool front, bool back, bool ifBlank)
{
} It seems to me that the class that manages the list of files should be the class that collects the various operation options, but I don't know which is the best practice, or what the implications are of doing it the second way.
modified 2-Jan-22 19:11pm.
|
|
|
|
|
I see no reason to use a modal dialog. You could use a regular form and encapsulate ALL the related logic in the form.
Alternatively, create a static class with a single entry point that wraps the logic and dialog.
Component-based design.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Well, I'm using modal dialogs for the various forms that collect user input because, while any of those forms is open, the user should not be able to focus on any other form. It's like Word's Font dialog.
I suppose I could put all related code in each form. Then the Rename Files form would have its own code that renames files, and the Trim Pages code would have its own code that trims pages from the files.
But I understood from my Google "research" that forms should just be data input and validation devices. I thought it was better practice to have a class that deals with the collection (files, invoices, parts, whatever) that contains the logic for managing the collection, and separately a class for the individual item within the collect that would contain the logic for operating on the item.
|
|
|
|
|
A "form" (i.e. Window / view) is an interface for the user to your app; it is not limited to "data input and validation".
Parts of that interface include the screen, keyboard, mouse, joystick, "touch", etc.
And the app you described was not a "data entry application"; it was a utility for manipulating files; which may or may not need to be modal.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Thanks for the input. You had suggested putting all the code in the form, but that violates the principle of separation of concerns.
I know the application I described is not a "data entry application." I didn't describe it as such. The question was really about code organization, not about form modality or the definition of user interface.
Please let me know if you have any answer to the question posed as is.
I confess I have not read the Analects, but I love and know by heart its first line.
The Master said: To study and at due times practice what one has studied, is this not a pleasure?
|
|
|
|
|
Keep the GUI classes separate. I prefer your original code over the proposed change.
What if you want to build a console version of this app where you pass a wild card and an operation? Keeping the GUI separate would allow this to work without hassle.
<cmd> 2021*.pdf -trim first last blank
|
|
|
|
|
Thanks for the sanity check! Yes, keeping the GUI classes separate makes sense.
|
|
|
|
|
I have a question about creating a software documentation. I hope I'm at the right place .
The problem:
I have to document a DB application before the implementation. The document must address not only the developers, but also other departments (who do not need to know the technology behind it; mainly non-developers). The tool doesn't need to support code generation (beside 8., that is optional); i.e. there is no need to generate HTML/JavaScript/CSS/etc. The document has to serve 2 main goals:
1. presenting the UI-prototype also for non-developers
2. collecting every name of the DB-fields used by the specific UI-elements of the mockup, and describing the behavior of the final application (in a plain text but with a reference to the specific DB-field)
If the UI-prototype has been approved, the implementation will begin using the name of the DB-fields and description of the behavior, collected in 2. .
I'm searching for a documentation/modelling/prototyping tool (I'm not sure what is the correct term for it) with the following abilities:
1. specify the DB-fields by name.
2. create mockups (simple GUI pages) and if you click (or mouse over, ...) on the individual elements (like input-fields, buttons, etc.) in the mockup, you should see the associated DB-field. An example: someone defines a mockup for the search with 2 fields that you can search for (ID, name).
3. you should be able to describe actions (in plain text). E.g. a mockup has the button Delete to delete elements from the DB that are older than 1 month. The description text should be able to refer to the DB-field affected by this operation. The text would be: "delete all items from {Mytable.Orders} that are older than 1 month.". Everything between {} is the name of the DB-field. The purpose of this is to ensure that if this field is renamed in the document, then it SHOULD be renamed in the description text also.
4. you should be able to define roles. E.g. the mockup ABC defines 3 DB-fields if you have the role of Admin. But if you have the role of User, then this mockup should ONLY define 1 DB-field. I would like to use the same mockup for Admin and for User .
5. the whole document should be searchable for certain DB-fields (to see in which mockups this field is used).
6. the tool should be free and run on at least one of the platforms: Windows / Linux / Web.
7. the whole document (with mockups, DB-field assignments) have to be saved in a format (PDF or HTML / JPG, or similar).
8. it would be nice if you could save the assignment of the DB-fields in JSON.
9. you should be able to describe the transition between mockups. If you e.g. click on Button A on the mockup ABC, the mockup DEF gets opened.
10. if you add a new DB-field to a mockup, a warning should appear if this DB-field is already being used in another mockup.
11. it would be nice (doesn't necessarily have to be) if you could display sample data in the mockups. E.g: you enter "Test" as "Name" in the previously defined search mockup, then a list will be displayed on this mockup (= creating an interactiv mockup).
It would be good if the first 7 feature could be fulfilled.
Thanx for any hint, or recommendation.
|
|
|
|
|
I usually "start" with spread sheets for the db fields / tables when I have to do a "walkthrough", and go from there. I guess you start be looking for a free spread sheet app.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
The only tools to support that sort of functionality come with enterprise type pricing ie $10,000s+, wait make that a bloody big plus!
The bank I worked for used one such tool and it required a consultant to set it up and a dedicated team to maintain it. Even then it did not do all the requirements you have posted.
I always found a prototype (wpf) to be the better solution. Most of my prototypes were converted to production systems. I once did a PT in 3 months that then took a team of 10+ developers over a year to turn into a production web system.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Using Windows-Presentation-Foundation could be also a good idea.
Do you allow me some additonal questions ?
That means, you design a Windows-GUI, generate code (C# i guess) and compile it to an executable ?
Do i need deep programming knowledge for that ?
Did you use Visual Studio to make the prototype ?
The tool you used, is it possible to export the prototype to a combination of screenshots/XML/text/... ?
Thanx in advance,
Daniel
|
|
|
|
|
I see you have limited knowledge of the environment, WPF is a desktop user interface, like winforms. It is NOT a presentation tool like powerpoint or the myriad of other such tools.!
And yes you will need a deep knowledge of c# and WPF to achieve a prototype within a reasonable timeframe.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Given a structure of DB -> DAL -> Web API -> client (Blazor and possibly mobile)
Do the DAL and Web API need to be asynchronous?
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
With a client in the picture, synchronous implies sitting at a locked screen. With perhaps not even a progress bar.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Anything that calls out to an external system, whether that's a DB query, a network request, or even accessing files on disk, should really be asynchronous. Why tie up a thread waiting for a request to complete when you could let the OS tell you when it's finished and let your thread get on with something else instead?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yeah when one applies a few brain cells the answer is obvious - browser paints the screen and then fills the data control
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I loathe synchronous design for the reasons described in the "Synchronous Messaging" section of this article[^].
|
|
|
|
|
I have a WPF app that has a a BL and A DAL.
I'm finding that I have code that I need to call from multiple places, such as computing the Sales Tax for a Purchase Order. I would need to do this in the DAL when I retrieve a PO, and also in the UI when creating a PO.
So, I thought that putting such code in the BL is a good place as any, and also about creating a Service Layer that just contains common, non-business logic.
I'd like some feed back.
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I'm working on a WPF app. My UI, BL, and DAL are all in one solution and each assembly is installed locally on each user's PC.
I typically have code like this in my ViewModel SaveChanges:
private void SaveChanges()
{
foreach (var job in Jobs.Where(x => x.IsDirty).ToList())
{
if (job.Id == 0)
{
DAL.AddJob(job);
}
else
{
DAL.UpdateJob(job);
}
}
foreach (var deletedId in deletedJobIds)
{
DAL.DeleteJob(deletedId);
}
}
Functionally this works, but it has some underlying issues:
- It requires looping over each changed entity and calling either Add or Update. Then I have to call delete.
- At some point soon I will need to move the BL & DAL to a Web API.
So I'm considering the following change. The DAL methods would look like:
private void SaveChanges()
{
DAL.SaveJobs(Jobs.Where(x => x.IsDirty).ToList(), _deletedJobIs);
}
In a stateful Windows app, each entity is an object ref so I can set the newly added Id's in the DAL and it will be available back in the VM.
But if I use the single AddUpdate method in a WebAPI, how to I get back the Id's of the newly added items?
One of the primiary goals of these changes is is to reduce the amount of calls the the back end.
I'd like to hear suggestions on best preactices for this.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
modified 9-Aug-21 13:29pm.
|
|
|
|
|