Cable TV providers suck. Plain and simple. They nickle-and-dime you to death, deny services, etc., etc., etc. Move to satellite and stop supporting these bastards.
James_Shields
@James_Shields
Best posts made by James_Shields
Latest posts made by James_Shields
-
RE: Cablevision WTF
-
RE: Forum Moderator WTF
I've lurked here a long time. Usually by the time I get to the forum, everything that I've wanted to say has already been said. I like how the boards are now. More moderation, especially if it is with a heavy hand, would make this place enterprisey.
-
RE: Totally new way of video editing
I've gone fro nutter to troll back to nutter with this guy. He just does too many stupid things to not be real.
-
RE: Airline Kiosks
@m0ffx said:
@tster said:
@chrismcb said:
Reminds me a few years ago when I was requesting a special phone number. I was told there was a surcharge for that. What was this charge for, I asked. "To search the database to make sure it didn't belong to someone else!"
Why would you expect a company to give you something for free? If I worked at a company and some dumb shit customer asked me why we charged him money to perform a service for him, I would tell him that it was to pay my salary so I could go stick it in the g-string of a dancer down the street.
Free market competition ought to mean that a service that costs a negligible amount to the company to cost a negligible amount to the customer.
Of course it doesn't, because the "free market" is a myth and/or an unattainable goal.
Yes, but how many phone companies are competing on the "we'll even search for your own damned special phone number" service? Last I looked, none.
Want a special number? Pay the special fee.
-
RE: Wikipedia is always so objective...
Yup, when someone cites Wikipedia (better known as Jimbo's Big Bag of Trivia), I see an old teacher's thick red pen circling their citation with the comment TRWTF+ next to the encircle cite.
-
RE: Barcodes have ZEROS?!?!!?!?
To those so stuck on numbers (which is a great indication that you haven't dealt with serious barcoding before), I want to know this:
1. Just how crappy is your database "server" if another 10MB of data is such a huge deal?
2. And how unbelievably crappy is your database "server" if serving up indexed short strings (14 bytes) takes orders of magnitude longer than serving up indexed numbers (6 bytes each, that's right, 12 and 13 digit numbers don't fit nicely in a 4-byte simple integer)?
Contrary to many of the simplistic notions here, UPC and EAN barcodes are intended to be taken as a whole. The zeros in front are significant and meaningful. Just scan them and use them. Why get clever? Why tempt fate? Unless your database server totally sucks, you're not going to get any real performance gains. You're not going to save any real space. Why not just leave things neat and tidy and use it verbatim? You know, magic cookie ... like a GUID or the primary key in a relational database.
Had the original developers just taken the barcodes verbatim and used them as is, none of this would be an issue. But, they got clever. And, that's where it all broke down. And, that's what some here are advocating. "Oh, I know better." Wrong.
They could've also done research and discovered UPC coupon codes. But, I suspect, that might've been just too hard. Imagine, using the right tool for the job.
-
RE: Untraceable
I've seen the trailer ... looks really stupid. Another "The Net". Networking Hacking Movie for Dummies.
-
RE: Barcodes have ZEROS?!?!!?!?
Nearly forgot. Since many stores now sell books, they must deal with ISBN numbers. An ISBN number may legitimately contain an "X". Note: "ISBN number" is just the terminology used by those who deal with them. Yes, it is technically not a number-number, but, that's what they use.
So, again, storing the SKUs are integers ... just bad juju.
-
RE: Barcodes have ZEROS?!?!!?!?
@tster said:
@WhiskeyJack said:
@imikedaman said:
Um, wow. Ignoring the fact that UPC codes don't actually work like that, using strings would be a *lot* slower (not 0.00001% like you suggest) and would take up more storage space. If the length of the UPC code was actually the issue, I'd just add a 1-byte length property and add an additional check to the existing code.
Why are you so set on using strings? It would require a large rewrite, it would be a lot slower, it would take up more space, and wouldn't even fix the actual problem since UPC codes don't work that way. You're being incredibly nasty to these people, yet their solution is elegant and fast and yours is worse in every way.
OK, I'll grant that UPC codes may not work that way, I admit I didn't look it up as I was going by my interpretation of the problem as written by the OP, which was that there were independent items with the same cardinal value, but differing numbers of leading zeroes, like "0000172" and "000172".
Yes, strings would be slower and take more space. I'm assuming that in the 21st century world of terabyte hard drives and multi-gigahertz CPUs, this isn't such an issue anymore. So it takes 12 ms instead of 13. I can live with that, if that's what it takes to solve the problem.
Now, like you say, if that's not how it's supposed to work, then obviously converting to strings won't help so this would be a moot point anyway.
Last time I checked, we make fun of companies that run in to problems and just throw more hardware at it. I think perhaps the company doesn't want to spend the money to buy all new hardware because some programmer is two stupid to realize that storing a 12 digit number as a string is a lot slower and takes up a lot more disk space (and bandwidth to a server) than storing it as numbers. Furthermore, it doesn't matter 2 shits if they are stored as strings or as numbers since the problem apparently is that two products have the exact same bar code.
Except that EAN is coming soon and UPC-A is just EAN with a 0 (zero) for the country code. If the store wanted to issue its own UPC-like codes, the UPC specification has a nice big section specifically devoted to coupon codes which are designed just for this reason.
Not only to mention that barcode data, in this usage of it, should be treated like a magic cookie. Don't modify it, don't think about its data type and how to optimize it, just use it.
And, put in me the "let's be real" camp when we talk about making things faster with numbers. Clearly, that didn't work, did it?
UPC-A numbers are 12-digits long. They can start with any digit. So, they require 10 hex digits. Or 5 bytes. Are people really insisting here that saving seven or eight bytes per record is a huge savings? A store might have a million SKUs. We're talking 8 megabytes. That's in the "so f-ing what" category.