|
Hi,
I have a "philosophy" of interface design, which I am continually modifying: it's been an interest going back to SmallTalk on the Xerox Alto.
I am highly critical of many design aspects of Windows up to and including version 7.
Equally critical of the "bright chiclet auto-expanding" graphic chotchkas of the current Mac UI desktop (but, that's a "religion," after all).
In your response above I find a dis-jointed potpourri of the ideas of "Save," "Apply," "revert (undo)," "multiple revert (undo)," and "restore application setting defaults for the whole banana." Not to mention the ideas of saving complete, or partial, "snapshots" of part, or the entire, state, of an application.
Each of those implementation details, imho, will be more or less appropriate depending on application design, purpose, security concerns, etc., and level of sophistication of end-users. The "security fence" I'd want a System Admin to be in, where changing a setting that might affect a hundred computers on a network needs a rigorous confirmation process, is irrelevant to TextPad or Angry Birds 
In some cases you want highly specific undo/redo facilities with a perhaps user-configurable history mechanism (as PhotoShop does for undoing graphic operations per document, for example, where the end user can specify the number of history states to be maintained) for certain types of UI actions, but have no need for such mechanisms with other properties of the application.
And the kind of configuration/settings I am speaking about are not trivial, self-evident, modifications like the background color of selected text in an editor application, like UltraEdit.
The trivial case in which "Okay" is "okay:" is one in which there is a simple binary choice affecting one user setting or preference, or where the visual cues in the settings area show you exactly what you are going to get when you do click "Okay: like in UltraEdit's compex configuration panel for setting the foreground and background colors of no less than ten text parameters. However UltraEdit also has a 'Save' button on that modal dialog that will auto-increment, and you can then re-open any previously saved configuration, which is quite handy ... no need to type an "original name" every time for each new configuration saved.
As I've carefully explained in my original post, and in my comments to other posts on this thread, I think there is a continuum of confirmation-requirement by the end-user that varies with the context in which the application is used.
The program examples you mention, including Visual Studio, have some absolutely grotesquely stupid design decisions. UltraEdit, while my tool of choice, for all text editing, in use every day, scatters its complex configuration UI's across multiple top-level menu items. To me "WinAmp" is the design equivalent of a Pachinko machine
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
Hi there,
Anyone knows the best way to use barcode in an inventory and POS system? I mean should I simply just read the barcode and use the Part number as an ID (Primary key) for the item, or is there a better way?
Thanks.
|
|
|
|
|
First step is to investigate "bar code". These days there are many variations.
You probably mean a UPC code which is a specific form and type of bar code.
I suspect that you probably don't want it as the primary key because it might need to be changed. You might want to also consider what happens in the following scenarios.
1. The cashier must manually enter the code but they enter it wrong. How does this impact inventory? How is a correction handled? (Think of fraud control in terms of this.) What happens to returns? What happens to returns if it was corrected before the return happened?
2. The cashier scans a item but the UPC code is not found in the database - now what?
|
|
|
|
|
Omar Rwemi wrote: I mean should I simply just read the barcode
Yes. Most scanners will input the code as if it were entered by the keyboard.
Omar Rwemi wrote: and use the Part number as an ID (Primary key) for the item, or is there a better way?
Yes. Add an identity-field (or a guid) as a primary key, and put an index on the part number
Bastard Programmer from Hell 
|
|
|
|
|
Each item in inventory should have a unique identifier, but don't count on each having a unique bar code. Manufacturers frequently change bar codes, and you'll often need to have several equally valid barcodes associated with a single item. Another thing to keep in mind is that sometimes a clerk will scan a barcode associated with a case lot, rather than the single item code. I had this happen when I was managing inventory at Ace Hardware. Fluorescent tubes came in a case of 30, and the case had a barcode different from the one printed on each individual tube. Somebody entered the case code into the system as an alternate to the one used for individual tubes, and some of our clerks sold cases at the single tube price. An honest customer pointed out the error, not an observant clerk (of which we apparently had none), but only after we came up short about 1500 tubes. 
Another thing to keep in mind is that a single item can come from multiple vendors and manufacturers; this happens a lot for generic items. For instance, we use a ball clevis rated at 30,000 pounds for stringing power lines. There are at least 6 manufacturers of this item, and except for cosmetic differences, they are all the same. We stock one item number, but each will have a different part number (for ordering purposes), and a different barcode.
This is actually a very complex kind of program to create, and there are a number of other caveats to beware of, especially if you plan to incorporate features like automatic ordering and receiving. Different vendors stock items with different order multiples, and the conversions between unit counts and order amounts can drive you crazy.
Will Rogers never met me.
|
|
|
|
|
Very good point, and you are correct. I've programmed POS systems for years. We used what we called an "alias" table for this. Ideally, you will store a system generated unique ID for your product in an items or products table. Then you will supply both a module and an import function to maintain your alias table for storing keyed values associated with your products.
ie:
CREATE TABLE ALIASES(
ID INTEGER IDENTITY(1,1) NOT NULL,
ALIAS NVARCHAR(50) NOT NULL,
XREF_ID INTEGER NOT NULL,
ALIAS_TYPE INTEGER NOT NULL,
DESCRIPTION NVARCHAR(100))
Note I used "XREF_ID" rather than a PRODUCT_ID. Keep in mind this table can be used for more than products. For instance, you may want to store aliases for customers, or vendors, or any other things people will look up stuff with. This is where the ALIAS_TYPE comes into play. These types can be maintained by a maintenance module associated with an ALIAS_TYPES table. This allows for dynamic growth of the system and modularization of your cross references.
I used an IDENTITY field for simplicity. But as Roger noted, it is probably better to use a GUID or some other form of unique value (i.e. STORE_NO + '-' + IDENTITY).
Getting back to the "Barcode" topic... you can store your Barcodes / UPC Codes / Model IDs / whatever in this ALIASES table and give them an appropriate type for searching on.
modified 6-Mar-12 0:36am.
|
|
|
|
|
Thanks everybody for the reply, lots of good info there, thanks
|
|
|
|
|
As a general rule, I avoid using business data as primary keys. The reason is, some time or the other they're susceptible to change. I understand that modern databases allow cascading updates, but I still feel that it is not an elegant idea and is not worth the pain and effort. I prefer using system-generated keys like GUIDs, IDENTITY columns (and SEQUENCE in Oracle). They're guaranteed to be unique and does not need to change at any point in time.
Don't forget to create an index on your barcode number, though.
|
|
|
|
|
Shameel wrote: As a general rule, I avoid using business data as primary keys
Ahhhh hah hah hah hah slap eh oh sorry...
A general rule - it is a cast iron, I will shoot you rule here, and I don't even have a gun. Absolutely NO flexibility in this rule is allowed - ever. The number of times I have gone, oh just this one, and had it come back and bite me is embarrassing.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hi All,
I am developing an antivirus scanner module for new security tool, in C++ for the windows operation system.
I have a need for database/list of viruses information so my tool be able to detect them.
Does any one know where i can buy/download a list like that with license to use in my tool.
I hope this is the right forum....
Thanks a lot,
Ram.
|
|
|
|
|
I've never seen an offer for such a list.
Furthermore, those lists are volatile; AntiVirus software manufacturers tend to update their data a couple of times a week. How will you organize that?
|
|
|
|
|
First of all, thanks for the reply.
I will have a team that investigate new threats over time.
But i need a list like that for old virus, that probably exist here and there....
Thanks,
Ram.
|
|
|
|
|
Luc Pattyn wrote: AntiVirus software manufacturers tend to update their data a couple of times a week daily.
FTFY
|
|
|
|
|
I am not sure about full list/database but if you visit the websites of the major anti-virus providers you should be able to find lots of useful information.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Thanks for the reply and the information.
|
|
|
|
|
Ram Shmider wrote:
I have a need for database/list of viruses information so my tool be able to detect them.
..scanning a file for a signature isn't the "hard" part that these people solve[^], it's getting those signatures.
Ram Shmider wrote: Does any one know where i can buy/download a list like that with license to use in my tool.
You're always welcome to download ClamWin[^], and build on it's database. You can even look at the sourcecode to see how it's done. If you use that database, your software might fall under the GPL license, dunno - you'd have to check with someone who knows about legal stuff.
A quick consultation with the Almighty Google revealed that Norton's database[^] might be "free" to. It might reveal more if you consult it after sacrificing some bacon.
Bastard Programmer from Hell 
|
|
|
|
|
Thanks a lot for the information, i will check it.
|
|
|
|
|
Hello, everyone, this is my first question in codeproject, please forgive me for my bad English.
Currently, I was working on designing a system which will store some data in local PC(ATM machine).
The customers(banks) hope we providing a security mechanism which can make sure any data recorded in PC was not changed by anyone.
I learned from internet and I fail to find a good way to handle it. Since we know if we have the right to visit the pc, we can changed the data, even though we can add MAC field for each records recorded.
I know that a third party CA organization would be involved to add proof to my application, but it is not allowed by my customer.
Any suggestion is welcome and highly appreciated.
|
|
|
|
|
in your database use datetimestamp field
|
|
|
|
|
Thanks for response, could you please detail it more specific.
|
|
|
|
|
Calculate a hash-key and store it in another table with a reference to your original table. If anyone modifies the data, it'll result in a different hash-key than the one that you stored.
Bastard Programmer from Hell
|
|
|
|
|
Hi Eddy, thanks a lot for that response, and I am glad to say you and I have a same understanding on that Issue.
From my previous thought, I think I can at least add a column in the data table, and record the hash key in this column, whereas you mean we can record the hash key in another table.
I think your idea is a little better than me, since if someone delete one row from data table the correlation will be broken for the foreign key doesn't match.
I want to know if tamper man change the data and meanwhile he/she change the hash key, how can we prove the data was not changed.
|
|
|
|
|
songbo07 wrote: I want to know if tamper man change the data and meanwhile he/she change the
hash key, how can we prove the data was not changed.
If the hacker can generate a new hash, you're toast. If the tamper-man has the seal of King Midas - he'll be King Midas.
It's the same as logging who's accesssing your Linux-machine - if a hacker gains root-access, they can change the logs as they like and the logs become useless. Hence the suggestion to store it somewhere else (with limited access).
songbo07 wrote: From my previous thought, I think I can at least add a column in the data table,
and record the hash key in this column, whereas you mean we can record the hash
key in another table.
I think your idea is a little better than me,
since if someone delete one row from data table the correlation will be broken
for the foreign key doesn't match.
Not only that; if a hacker sees a column with something that resembles a hash, he/she will focus on that column. If you got .NET code that's not obfuscated, then it might become very easy to break it.
Another layer of security could be added by adding auditing[^], but this requires a licensed version of Sql Server 2008 (not available for Sql Express, but you could leave a trace running there). Additionally, you can have the logs being written to an encrypted drive as suggested by Microsoft.
..and no, there is no fool-proof lock. The idea is to make it as hard as possible, just as you lock the doors around your house. Ask the bank, even their vault is vulnerable to attack in certain (yet hard to create) circumstances.
Bastard Programmer from Hell
|
|
|
|
|
He wants to PREVENT from people modifying the data. Not to KNOW if someone modified it.
Plus, if someone can modify the data, she can also calculate the hash and modify it too. And then you wont even KNOW!
My answer is, use asymmetric encryption. Encrypt data with banks public key. And only the bank can retrieve the data then.
|
|
|
|
|
krumia wrote: He wants to PREVENT from people modifying the data. Not to KNOW if someone modified it
Hmz, might have missed that bit.
krumia wrote: Plus, if someone can modify the data, she can also calculate the hash and modify it too. And then you wont even KNOW!
With the salt in another location, I would now.
krumia wrote: My answer is, use asymmetric encryption. Encrypt data with banks public key. And only the bank can retrieve the data then.
Bastard Programmer from Hell
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
