Forgot your password?
typodupeerror
User Journal

Journal: Woah.

Journal by whynot4
I just saw a banner ad for Microsoft Visual Studio .NET on this site. What is up with that???
User Journal

Journal: Coding, Clients and the pursuit of the perfect meat...

Journal by whynot4

I downloaded Forte 3.0CE last night and installed it. It looks like it will be what I need out of the box. I'm trying to get JUnit to work with it (the plugin that is). Since I'm biased towards Sun's Java implementation, things will probably work how I expect them to.

As if the problems at my job weren't enough already, my old client is calling me asking about something I did for them 2 years ago (a complicated financial application). At the time, I was well-versed in this client's accounting procedures and processes. Having been away from it for a while will make it a little difficult to participate in discussion. But I need to do the right thing and pitch in.

The turkey frying pot is on it's way. I'm going to try to fry one for Super Bowl Sunday. Turkey is one of my favorites and having it baked and roasted before, I decided to experiment a little on my own. I smoked a turkey before Christmas and it turned out fantastic. Now, I need to fry one. I'm also wanting to smoke a pork loin roast. Mmmmm... Pork...

User Journal

Journal: Murphy's Law and IDEs...

Journal by whynot4

Why can't a software install ever go 100% right? I support a vendor tool and we went through an upgrade last night. The software needs to be installed on various different platforms. I had done a fair amount of work to automate the uploading of files to our Unix boxes and all that stuff. I even wrote a setup script to stop the daemon, set the file permissions for the executables, copy the old files off to a backout area, copy in the new files, run crontab and start the new daemon. Great idea in theory.

The daemon needs to run as root (scary isn't it?) so to stop and start it you need to issue 'sudo' and then the command. Well, scripting sudo is not so easy. Also, automatically registering the cron jobs failed for whatever reason. The only thing that did work right was copying the files and setting the permissions. Needless to say, most of the installations were done by hand on about 30 Unix boxes.

Then the client piece wasn't letting our customers log in. That was drastic. We came up with a workaround, but it's by no means secure. This really concerns me, but I have no choice right now. The enterprise must be able to move forward and there are a lot of people who need to use our tool....

I'm waiting on my vendor to call me back to corroborate our hypothesis for a permanent fix. This could take a while. In the meantime, I'm sitting here trying to assure our customers that everything is fine. I feel like such a liar.

I'm also trying to decide between eclipse and netbeans for a Java (and general) IDE. Currently, I'm using jEdit which, IMO, is good but could be better. I have installed a lot of the plugins, but they always fall a little short (the Class Wizard doesn't always work!!). Has anyone out there used either of the two?

User Journal

Journal: The road to Hell is paved with good intentions

Journal by whynot4

The Collections Framework in the Java 2 library is great. The API couldn't be any easier to use and it's easy to change implementations without having to do a lot of work retrofitting your code. I think that it fits most general programming needs.

However, there are a lot of problems with it too. For starters, there is no good built in implementation of a Stack. Yes, there is java.util.Stack , but that class extends java.util.Vector . This makes it easy to "forget" that you should use only push(Object o) and pop() by allowing you to use the methods in Vector like add(Object o, int index) and other non-Stack operations. This fact is pointed out in the book Effective Java and the author underscores that this was a bad design (inheritance violates encapsulation; composition preserves it).

The Collections Framework tries to do the right thing by providing 3 interfaces ( java.util.Set , java.util.List , and java.util.Map ). These interfaces have various implementations contained in the same package ( java.util.TreeSet , java.util.HashMap , java.util.LinkedList , etc.). All of these classes implement their named interfaces which is good and they all provide adequate functionality for most needs.

What is a real pain in the neck is that these containers (I say containers to mean all of those in the Collections Framework) are not synchronized out-of-the-box. It reduces overhead in high stress environments, but that does not assuage the inherent need for it. To make things a little better, there is a utility class called java.util.Collections that allows you to return a synchronized view of a container, but you can only access the container via the methods in the interface that said container implements.

What is the point of my rant? Since java.util.Stack does not meet my needs, I decided to re-implement a Stack using a java.util.LinkedList as the backing store. I chose java.util.LinkedList because it had methods that were best suited to do the job and it is reasonably fast for inserting and removing objects from the list. The problem was that the methods that I really need to implement the Stack in a straightforward way are not part of the java.util.List interface. I thought it would be okay and I took the hit. I successfully did that (any programmer worth their salt should be able to) and then moved on to a queue then a deque. It was during my testing of my queue that I got into a synchronization pitfall.

Let's suppose that I have one of my Queues managing several objects and let's say that I start two different Threads to manage objects entering and leaving the queue. Without synchronizing the object, I would most certainly have a corrupt data structure. So, I have to resort to manual synchronization. What's worse is that I have to obtain the lock on the data structure. Suddenly, my dream of a simple data structure with an easy to use API are gone.

I suppose I'll get over it. I may have to tweak those structures some, but I want to keep the usability of those structures at a very simple level. I can hide a lot of the synchronization issues under the API, but what does that do to my performance?

User Journal

Journal: COBOL/MVS is dead...

Journal by whynot4

Well, not really. COBOL, the language is still around, but my former id, COBOL/MVS is dead. I wished I wasn't so hung up on doing things the IBM way when I created that id a couple of years ago.

It was my fault anyway. I should've known better than to put a "/" in an id. I considered asking if I could get it changed, but the first question in the faq underscored that there are no exceptions for requests to change names in accounts.

It's a shame, really. That account is great. I wouldn't call it a "karma whore" account since really I never did any of that. In fact, some of my posts that I thought would be modded down as Troll scored fairly high. But I wanted to be able to journal using that account. The "/" killed that because if you cliked the "Last Journal on" link on a comment header, the server got confused and you went to "COBOL"'s user page.

So I thought why not start from 0 and build back up again? I know that this account will probably not be a moderator or meta-moderator like MVS was, but I'll still post. I've also set up this account to filter out the noise as much as possible.

Maybe I'll plead my case to the Slashdot team. I may not get anywhere, but I'll be satisfied that I tried.

I use technology in order to hate it more properly. -- Nam June Paik

Working...