After suggestions for algorithms, products or anything else in the arena of high performance name matching.
Background - we allow our clients to upload a list of names to our systems, and then we screen those names against a list we hold on our side looking for matches. Ballpark figures are ~500K uploaded records being compared against >5M on our side.
We've currently got a couple of ways of doing this, from a Sql DB & Entity Framework (no giggling at the back), to a full on in-memory dictionary with all possible parts of every name broken out and indexed (I said no giggling).
I'm looking for high performance, high accuracy matching, and it would be nice if I could also do things like distance matching (probably using Levenstein), but the core matching needs to be as fast as possible.
I'm considering an in-memory Sql instance (not ideal), Apache Solr (not sure, never used it) etc and I was wondering if any of you had experience and could make some recommendations
C# has already designed away most of the tedium of C++.
On the various types of match, we have some rules defined around things like aliases, diminutives etc, so we could express those in a rules engine, or if I have to code this up myself, then in the C# - completely agree that if I do end up doing it myself, ordinals etc are the way to go...
I'm not really after advice on the actual matching, more the sort of infrastructure I can put around it to make it as fast as possible...to be honest, if there's something "off the shelf" that would be ideal lol...
C# has already designed away most of the tedium of C++.
I am doing a project and the circuit is ready with me..
I just referred
where the programming code is given as a picture which is not clear
so I need the same programming code. please help in this
This is both a specific question about my quandary and a "philosophical" discussion about making a switch mid-project.
I'm working on a project with lots of different UI "screens"/Windows, and it's getting ridiculous to open and close the windows, as the user moves to earlier "screens". I am however a month into the project, (a few hours every week, as this is a side-project), so I'm afraid I might have to re-design and re-code too much to do the switch. (I'm sorry to say that I haven't used pages before, so I know nothing of the time it would take).
The basic requirements
This is a customer tracking program for a car-wash facility. It needs first a login "screen", which either leads directly to the "user" landing "screen", or brings up options to either open the admin "screen" or the "user" "screen". Admin is just a single "screen", that has information about the users and options, nothing complex. the "user landing screen" is a "hub" leading to "screens" doing things like:
Adding new customers
Reserving a timeslot
Perform a transaction
Looking up costumer information
with every "screen", by necessity, having multiple it's own sub-"screens".
At this point I have 7 windows, some that are on top of others, and some that replaces others. The actual code is divided around willy-nilly, (I'll have to do a clean-up before I'm releasing it). I have had some end-user tests, and it seems that it's a little bit confusing where to go, though I wasn't told that it was confusing. I had plenty of negative constructive feedback on other things, so I think they might be used to fumbling about, (Excel sheets was the previous "system" they had). However, I saw the fumbling about, and it irritated me, that I designed something that's inefficient.
Should I change it to a page-design or keep it as it is?
In general, should anybody change something like this in the middle of a project?
Please discuss, I'm not looking for some specific solution, but rather advice
Your post reads as if you are not sure of all the requirements yet? You are just coding this up as you go? If you are running into problems about the User Interface and usability it is likely you are not sure enough of your problem area. I would expect you to start having other problems with the application in time. Especially if your requirements start shifting.
If you are using WPF then you should have been using MVVM. (Or MVC in Winforms). This should allow you to reorganize the screens without too much effort. If you are going to do it, now would be the time before you've any nasty deadlines to meet.
If your users are struggling with your UI, you have to respond to that otherwise they will just revert back to their old methods - the ubiquitous spreadsheet. Again, take a step back and review all their processes to get an idea of how you should structure the UI.
Get feedback by drawing diagrams of the screens you envisage, perhaps with annotations of validations etc. Then prototype the screens using mocking to provide dummy data. Then deliver the final thing. Something like that ...
Part of this mess is that I keep getting "oh, and could we get this feature"-messages. This all started as just a more "visual" way record information. Also the Excel approach lead to a few situations where a day's or week's worth of records were deleted, having a UI that is "layer 8 proof" is simple enough, tacking on a lot of "stuff", though simple in a website, in desktop development, it's maybe not more difficult, but it isn't the same thing.
I'm basically doing this as a favor, so time isn't critical. or I wouldn't be asking questions, but rather just make a messy program, and do an "update" after having re-done it in some other way.
Since my field of expertise is mostly web-related, the methodology of desktop application development isn't something I've really studied. And so MVVM isn't something I've seen as anything more than the separation of the UI dev team and back-end functionality dev team, and therefore not something a single programmer should focus on, (I might have to spend some time on the Microsoft Virtual Academy or similar).
I have been trying to get feedback on sample layouts and I've requested drawings of what they envision, but it is kinda like that The Outmeal comic about web-design: How a web design goes to hell.
I think I'll redo it all, and make it more MVVM, or at least move everything away from the "code behind", so I make it usable regardless of how I do the UI in the end.
Keep in mind that it is sometimes easier to run multiple instances of an app than to create a "multi-window" app that meets a given user's "multi-tasking" requirements.
It does seems though that you need to spend more time with the user "while" you are developing your app (incremental development with a feedback loop) instead of waiting to be "surprised" by the user's response to your app later on.
I wish I could spend more time with the users. And the couple of times I have been by, it's like they are in presence of a god, (I'm not kidding, you'd think they had seen magic each time I've brought a new iteration of the program), they keep telling me "this is great" and "you do what you feel is the best", so I'm tempted to make it as a console application just to get some actual feedback.
What do you do when nobody has any idea of what they want except in terms of functionality, (and they keep tagging on new requirements)?
But that is our job ... take "functional requirements" and translate them into a workable solution; which could be a combination of manual and automated procedure.
There will always be new requirements; you simply assign them a priority and catalog them while working on the core requirements. If the original analysis was performed correctly, you will have a core functionality around which you build. If a "new" requirement comes along that causes you to rethink your "core", then the original analysis / design missed its mark.
I find that when I truly understand the user's requirements and write the software in such a way that "I" would be pleased to use it, the user's response to the product has always been positive. One still needs to go back to the user at regular intervals to demo the product and get feedback. And if you cannot demo something new at least once a week, then the problem has not been partitioned properly.
While providing an architectural solution proposal, what do I need to include under section - "Dimensioning & Configuration"? Specific example for ASP.NET + SQLServer scenario would be helpful. Thanks in advance!
Its framework development for automation test system from initial phase(vb .net and oops). so that below layers can communicate with each other but in some protected way.. and can be handled
seperately without affecting others functionality.
3. class libraries(few functions is accessible from testscripts, and few from other libraries and then remaining critical functions(e.g truning OFF the hardware) are inaccesible ).
below is the control flow.
User--->Application(StartTest and generateReport)-->TestScripts(for 200 testcasess)->Libraries which includes Testscripts functions+Interface libraries(Measuring instruments & Device under test ).
i am looking for
1. How to share data across layers in restrictive way...
2. what are the oops concepts(this perspective as well) that can help.
I cannot go with the certain design patterns(MVC,factory pattern..etc) also,since defining the framework data is happening parallel.
I`ve been interested in architecture and design for about 10 years and read a lot of blogs and literature on the subject. Could you give me some titles of books about it? May be I haven`t read it yet and want to learn about something new which is worth attention!