Win a copy of Emmy in the Key of Code this week in the General Computing forum!

Grant Gainey

Ranch Hand
+ Follow
since Oct 16, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Grant Gainey

Originally posted by Mark Spritzler:


Yeah, and the more that things change, the more they stay the same. Tricked by Circumstances.

Mark


Heh. OK, so the French was perhaps a bit...pretentious. Esp. since I had to look it up to make sure I had the correct spelling.

I blame teh intarwebs...

Grant
13 years ago

Originally posted by Ulf Dittmer:
Come on Max, don't leave us hanging: what was yesterdays debacle you mention? Spill the beans... Or have I missed some Sun news?


After seeing Max's note, I just went back to JDC and poked around for a while. Looks like there was a period of people discovering and playing with various JavaScript bugs allowed by the software interpreting JS in messages, followed by an "upgrade" to the Forum L&F that makes the forum harder to read and navigate, but with prettier/splashier graphics. (And which may or may not have fixed the various bugs being reported)

Which is to say, it appears to be identical to the situation that finally caused me to drop the JDC fora like a hot rock almost a year ago.

Plus ca change, plus c�est la meme chose, I guess. Sigh.

Grant
13 years ago

Originally posted by Jim Yingst:
[MXS]: What's IN the pie?

Well... have you seen Sweeney Todd?


Mmmmm...priest.

Grant
13 years ago
MMm, I think Rohit is close.

I'm assuming that rootroot is a class-variable that is intended to hold the root of your tree. If so, then your code overwrites root as it traverses the tree. I suspect this is bad.

Try this - in the else clause, before the while (cont) {, add a line Then, replace every instance of root inside the while with currentNode. See if that changes the behavior.

Good luck,
Grant
13 years ago

Originally posted by Paul Clapham:
The "decomposition" part of this Unicode report should get you started.


Now that is very cool - will need to read in detail tonight.

Meyer - ahh, I understand the requirement now. Apologies if I sounded snippy - I've seen too many systems implemented where the designer was trying to "get rid of all these stupid marks", because they had no concept of anything other than ASCII.

Grant
13 years ago

Originally posted by Meyer Florian:

Unfortunately, �, �, �, �, �, �, � and same uppercase characters (and many more) are recognized as letters. Is there a way in java to convert � to A, � to E and so on?

M�ller must result in MULLER and not MLLER or MUELLER...


Ummm...why would you want to do that? If someone's name is M�ller, they're going to be unhappy if it's shown as MULLER - that's not their name. All those characters up there aren't just "aeiou with funny marks" - they're different characters, just as if they were x's and z's.

The only reason I can think of for doing what you're attempting is to store the names as 7-bit ASCII, which is a really US-centric view of data.

At any rate - assuming you're really stuck on this path, the only thing I can think of would be to have a mapping table somewhere of "Weird non-US characters that Those Durn Furriners shouldn't be using" to "The Five Vowels The Computer Gods Intended".

But be prepared for your users to complain bitterly about you changing their names...

Good luck,
Grant
13 years ago

Originally posted by Alan Moore:
I did say I wrote it for my own use. And I'm sure the OP's (stated) requirements are incomplete; he didn't even say whether letters should be sorted case-sensitively or not. But this class should at least give him a good start on solving his problem.



Fair enough.

Originally posted by Alan Moore:
I don't see this as trying to do more than one thing at a time; it's just another way of sorting strings. Unless you're saying that, instead of using strings, the OP should create a custom data object with a string field and a numeric field. If that's an option, I agree it would be a better way to go.



Again, fair enough. I think I was reacting to too many prior episodes of "All I Want It To Do Is This Really Simple Thing" - and then, as one asks questions just like yours above (whitespace? punctuation? case-sensitive? more than one 'numeric' inside the string? scientific notation? sign characters? floating point? hexadecimal??), one finds that the real requirement is for the person asking the question to actually think through the implications of their design.

And I do think your Comparator above is a very nifty thing. May need to add it to my toolbox, if you don't mind.

Grant
[ April 14, 2006: Message edited by: Grant Gainey ]
13 years ago
OK, I found the articles I was thinking about. If you have any interest in how people communicate using the kind of software we're having this discussion on (and you are interested, or you wouldn't be reading this thread!), you MUST read these two essays:

A Group Is Its Own Worst Enemy
and
Social Software and the Politics of Groups

Clay Shirky is a smart guy.

Grant
[ April 13, 2006: Message edited by: Grant Gainey ]
13 years ago

Originally posted by Alan Moore:
Grant, converting digit sequences to numbers is the obvious approach, but it has a major flaw: what if the number is too large to be represented as an int or long? The character-by-character approach also seems cleaner and more efficient to me.

Well, your code is certainly thorough! I think it's overkill for the OP's requirements (which, admittedly, are possibly not complete). If your digit-strings are more than 20 digits, you'll need more than a long - although if I really wanted to worry about that, I'd probably just convert to using BigInteger for it, rather than rolling my own.

But I think the real issue underlying this discussion is one of flawed design. Anytime I see code that wants to do more than one thing at a time, it suggests to me that I haven't stated the problem correctly.

Just my US$0.02,

Grant

[Edited because there is a difference between "you'll need a long" and "you'll need more than a long", and I are a idiot.]
[ April 14, 2006: Message edited by: Grant Gainey ]

13 years ago
An interesting, if sad, thread. I joined the Sun forums in 1997, but haven't posted for over a year and only drop in now and then to see if anything's changed. It has not, alas.

Somewhere I have a link to an article on "Social Software", into which category both the Ranch and the Sun Forums fall. It classified such things into "Strictly Moderated", "Inconsistently Moderated," and "Unmoderated", and pointed out that "Inconsistently Moderated" was the worst possible case for building community. As has been pointed out, the Sun fora these days are poster children for the downfall of inconsistent moderation.

I don't post a lot here yet, either. I miss the old community, and between work and real life, haven't been able to spend enough time here yet to feel like I'm really a part of this one. Like any other move, it takes time to meet your neighbors .

I actually agree with the original poster that a lot of the remaining regulars at the Sun fora are quick off the mark with the flamethrowers. Someone up-thread was quite eloquent as to the reason(s), though. My observation is that, even now, if a new poster shows up, asks a question in a reasonable way and shows that they've a) done a certain amount of their own work, and b) are aware of basic etiquette when asking for help from volunteers, they get reasonable responses.

Heaven help them if it looks like they're asking for homework help, though...

Grant
13 years ago
The problem is that you're trying to sort both lexicographically and numerically at the same time.

Sorting by string, "2" comes AFTER "100", just like "b" comes after "aaa". If you interpret the strings as numbers, then it's clear that 2 comes before 100.

Your requirement needs it both ways. Sounds like you need a Comparator that can split the strings into an alpha prefix (which appears to be optional) and a numeric remainder, do a lexicographic compare() on the alpha portion, and convert the nueric portion to Integer and compare() them numerically.

Does that help?

Grant
13 years ago
Several comments:
  • You're reinventing Password-Based Encryption (PBE), badly. Do some research on PBE algorithms - JCE supports at least a couple, although I don't recall exactly which ones offhand.
  • You're converting your ciphertext directly into a String. This is Bad. If you really must transform it into something readable/printable, use Base64. If it doesn't need to be transmitted over a String-only channel, just leave the byte[] alone and transmit that.
  • You're encrypting the whole document at once with one doFinal() call. This means you have to have the whole file in memory, twice - once for the plaintext, and once for the ciphertext. Ow. Study Cipher.update() - or better yet, CipherInputStream/CipherOutputStream, and let Java do the heavy lifting for you. (And yes, I know this is just a sample - but the whole point of a sample is to get the pathways correct)
  • If you rely on one password, regardless of who the customer is - then there's little point in doing this encryption. If anyone gets a hold of a copy of your program, regardless of what language you write it in and how hard you try to obfuscate it, they'll have access to your key. Five minutes later, everyone in the world can be assumed to have access to it.

  • If you really want to get this stuff right, I'd suggest finding a copy of Bruce Schneire et.al.'s, "Practical Cryptography". It'll help you avoid a lot of the mistakes you're about to make.

    Regarding what you require of the customer - hm. The Java-to-exe path doesn't sound very efficient to me. If you think your customers won't have the JRE available, then you might want to write the client in some other language (C or C#, maybe), and distribute that. Assuming you implement the encryption correctly, the algorithms don't care what language they're invoked from.

    Or, you might provide an HTTPS upload service that lets the customer transmit the file(s) directly to your server. Set up the HTTPS channel correctly, and the whole encryption issue goes away completely...

    One final note - 3DES is painfully slow and no longer very secure. I'd go with AES, personally.

    Good luck,
    Grant
    13 years ago
    Well, let's be a little pedantic here - in the sample shown, there is no encrypting going on. MD5 is a digest algorithm, not a cipher. That means it's one-way only.

    The idea here is to avoid sending the actual password over the air (which is considered rude in security circles). The digest is exchanged as a means for the "other side" to prove that they know the password, without needing the password itself.

    In this specific case - the server, upon receiving the response and knowing what password the user has on the server(ew), generates the matching MD5 on its part and compares to what the user sent. If there is a match, the user must have entered the right password as part of building the response.

    Does that help?
    Grant
    In the typical case for browsers, HTTPS servers are expecting "anonymous" communication. In this case, the client doesn't have its own keypair. HTTPS defines a protocol for the two sides to communicate using a session-level keypair for the client, created on the fly as part of the communication handshake.

    Only if the server is expecting "client authentication" does the client-side need to have its own keypair generated and certificate stored in the client keystore. This is something of a pain to set up; I haven't had to do it in a long time, and don't have the procedures for IE handy, but you can certainly find it out with a little Googleing.

    At a high level, tho - the browser's certificate store is a list of who the client trusts, and the keystore is who the client is. If the server doesn't care who you are, you don't need the latter.

    Does that help?
    Grant
    13 years ago