4,042 reputation
1020
bio website None
location North Carolina
age 49
visits member for 3 years, 9 months
seen 10 hours ago
Software Engineer

1d
comment Similar problem to word break
Permutation problems tend to require a LOT of comparisons. Unless you come up with a slick algorithm for your particular problem then the next obvious approach is to try and filter the data to smaller subsets. Thus, you could probably do a first pass filter where you can eliminate the strings in the list that are obviously not going to be a good match. Maybe count the number of matching characters and drop those below some dynamically determined threshold? If that still leaves too many then apply a 2nd filter to whittle things down. Try and hash A to make lookups/comparisons quicker.
Oct
16
comment Designing classes the right way
Do a little reading up on "Graph Theory" and how to do various types of graph walking and you will find this problem has been solved many-many times already.
Oct
16
comment When does one hard-code actual data values into the code as opposed to using a DB?
@gbjbaanb:For most applications a RDBMS is WAAAAAY overkill, even for otherwise quite extensive systems. Not to mention that they are slow and require a fair amount of effort to maintain and integrate with. "ini" files don't provide any type safety, you have to write the parser yourself and you have to write your own type checking. XML Config files, at least in .Net, get all the benefits provided by either of your preferred options essentially FOR FREE. So your assertion that a XML config file is always a worse choice couldn't be more wrong.
Oct
14
answered Dealing with conflicting project requirements
Oct
14
comment More requirements in a single use case - correct?
1 FR does not equal 1 UC. Typically what you'd do is write the use-cases and then figure out what requirements can be derived from the use-cases and that most certainly will not be a 1 to 1 mapping. Each use-case will result in quite a few requirements. However, from your examples, I'd say FR01 "User Login" is the use-case, but FR02 would be an alternative scenario. FR03 would be its own Use-Case. OR you can simply have "User Authentication" use-case that contains all 3 as separate scenarios. There's no hard and fast rules, just what is most useful. More use-cases is definitely not better.
Oct
14
comment What are the advantages of non-text based programming languages?
I think the question can be improved by possibly explaining what you mean by "non-text based" programming languages. I originally thought graphical programming but now I'm not so sure because maybe you are referring to lambda calculus-like programming instead. Unfortunately, while I personally find this an interesting question I can't figure out how to turn it into a question that meets the guidelines.
Oct
14
comment What are the advantages of non-text based programming languages?
Does a WYSIWYG editor sort of explain the answer? The idea is to hide the "computery" stuff so the developer can focus on what they are actually trying to create instead of getting bogged down in the details of the programming language. Let the computer worry about those details. While there are some quite useable graphical programming environments, I don't think anyone has come up with the "home-run" idea just yet. Probably because we are still stuck with 2D interfaces. Maybe as technology advances towards being holodeck-like then the graphical IDE's strengths will shine.
Oct
13
revised What's the advantage of auto-property initializers without primary constructors?
edited body
Oct
13
comment How do you solve issue of consistency in concurrent and distributed application (built around Bankers Dilemma)?
@Integralist:Did you read up on "Transaction Processing"? Commit and Rollback are the key concepts that end the transaction. Other intermediate transaction states are "temporary" until they are committed or rolled back. Those intermediate states are dependent on what action(s) you are trying to perform. Bar withdraws 5, immediately withdraws 5 from Baz but that transaction might have a "pending" state assigned to it. That way if dispensing the 5 to Bar fails then the 5 could be rolled back and if Foo tries to withdraw 10 it'll find that there's only 5 remaining and reports a failure.
Oct
13
comment How do you solve issue of consistency in concurrent and distributed application (built around Bankers Dilemma)?
IMO, if you are going to use an explicit problem for your example then you should probably use explicit descriptive names and not use Foo/Bar/Baz. It makes the question easier to follow and I think because of that you'll get better answers.
Oct
9
comment Use case diagram, the system scope
FYII:I still see implementation in your use-cases. "System shows a form/Customer enters the amount/through an outlet". Those are design/implementation details. They don't belong in use-cases. "Customer requests to withdraw money" covers the form and amount. "System distributes money to customer" leaves room for design/implementation decisions but still says the same thing as "through an outlet".
Oct
9
comment Use case diagram, the system scope
FYI:I've found the easiest way to handle "login" type processing is to create a separate "Customer Login" use-case. Then make that a pre-requisite for the other use-cases. This reduces clutter by avoiding the extends/includes problem you had asked about in another question. That way your above use-case would simply begin with "Customer requests to withdraw money".
Oct
9
comment Use case diagram, the system scope
The use-case describes the interactions on the boundaries of the system you are writing the use-case for. Use-cases have different "levels". Each "system" should have its own set of use-cases. The use-cases for each level shouldn't be combined. Thus, if the software you are writing the use-cases for does not do any of the card reader processing then those steps don't belong in your system's use-case descriptions. However, those steps would be described in the use-cases intended for the overall system. But you aren't developing the overall system so no need for them in your use-cases.
Oct
8
comment How often should internal applications be deployed?
Ask yourself the reverse question and you might find the answer for your particular situation. What do you have to gain by delaying releases? Do you have to run some time consuming validation regression testing before a release? If so, then getting more fixes in before a release is more efficient, so periodic releases is a logical choice. If not, then what's the point of delaying if the code is just going to essentially "sit-there". Might as well get people using it and testing it for you ASAP.
Oct
8
comment Use case diagram, the system scope
I had to upvote because you essentially said the same thing as my comment that I apparently posted at the same time as your answer. Anyways, you should add one thing to your answer to make it "THE" answer. Point out that it doesn't matter if Registered User is a person, a computer, a signal or a clock. At the use-case level you don't care. So don't concern yourself with it. At design time, you are likely going to create a class that represents the RegisteredUser and that's where you'll provide the hooks for the different types of initiators to kick off the use-case action.
Oct
8
comment Use case diagram, the system scope
You need to capture all the external actions on the boundary of your system for the unit of work you are describing in your use-case. Generally, time is about the only "internal computer component" that becomes an actor. I'm sure there's some specific cases where it might be applicable but a good rule of thumb is if the computer is part of the system you are building then it isn't an actor. If you are focusing on does the computer initiate this or a user when creating your use-cases then you probably are delving into too much detail. The actor is a role not necessarily a real thing.
Oct
7
comment How to organise and label methods, intended for debug?
@Sven:I read the description and thought nothing but embedded, multithreaded and real-time so there had to be some hints. Anyways, I was more directly giving you examples of where a debugger is not appropriate because you stated "I can't imagine a system where you can't use a debugger".
Oct
7
answered Extension in use case diagram: Library management example?
Sep
29
comment When should something be a class? And are my chosen classes good OO design?
FYI:Use-Cases should be talking about the problem domain and not the implementation. So your use-cases shouldn't be talking about parsers, APIs, URLs, links and disks. Those are all implementation decisions. You'll find your model turns out a lot cleaner and easier to understand once you leave out the implementation details.
Sep
29
comment Is creating subclasses for specific instances a bad practice?
Here's a sort of related question where the OP seems to believe the opposite of conventional wisdom. programmers.stackexchange.com/questions/253612/…