JDeveloper

I got a comment from someone from the Oracle team that works on the JDev Modeler on my past post. I was just going to post another comment, but hey, since I actually got some attention on my lame little blog, it probably deserves a full post.

Dai responded and was wondering what was giving me problems with generating from JDev. First of all, I have to say that I'm totally flattered that he read the post and responded -- especially since I was just whining into the Black Hole of the Internet.

First, let me say that I'm totally flattered that you read my whining -- "I'm not worthy..." The JDev Modeler ROCKS.

Here's the trouble that I end up having with the generating (in version 11.1.1.0.0).
I have to choose between 'CREATE, REPLACE or ALTER.' Thus, if I've created a table and made a change to a different table, I have to generate them separately. I'd prefer that it check the connection and generate a delta. Actually, this has been my only frustration. And, if I were working on one table at a time, it wouldn't be a big deal. Yesterday, I was attempting to do just that -- create foreign keys to two existing tables, alter some other existing tables and create several new ones. Basically, I pulled in a few tables into a database diagram, made some changes and enhancements and tried to implement them. What I ended up doing was dropping the two tables that I meant to create foreign keys to and then failing to create the full set of objects. Happily, this was in Dev.

Which brings me to one of my FAVORITE features in JDev Modeler. I love that it generates the sql script. However, I would prefer to get the script always -- even when it fails to run. That way, I can look at the script and fix the script. The reason that this is my favorite feature is that I love the point and click way of rolling out changes -- but only in Development. For Production, it should be from a script.

In fact, this is one of my favorite features in SQLDeveloper as well. They have been very good to (almost) always providing a way to see a script of any change that you are making through the UI. This is a fantastic feature. As I've mentioned, i feel strongly that the script is the only way to roll the code into test and production.

At this point, I should probably confess that I've spent a few years developing with Designer. So, I was spoiled by being able to point the generator at a database connection, have it generate a delta script WITHOUT applying it, then I could go apply and test the script. Nice feature.

But again, as a former Designer user, I LOVE the JDev er. Don't tell the SQLDeveloper er team, but I like the JDev version better. Yes, it does less. However, I love that it will create a sequence and trigger for a Primary Key column with the click of a button. That's just ONE example of how the JDev Modeler is more usable. Another confession -- I stopped using SQLDeveloper er once I found out that they were going to charge for it (and since I knew that JDev already had one that rocks for free). I've been a Contractor several times and I find that it pays to be able to use as many free tools as possible, especially in an environment where a company is paying MEGABUCKS for their Enterprise Oracle license and doesn't want to hear about another Oracle license fee.

Dai, I want you to know that despite my complaints, I LOVE JDev er. I love SQLDeveloper as well (have I mentioned that it hangs a couple of times a day and I have to kill it?).

Of course, now I'm comparing my own whining with my previous post about User Expectations. Developers are probably the hardest crowd to please as far as User Expectations go. Not only do I want the custom street rod, but I want it for free, too. :)

Thanks for reading -- "I'm not worthy..." :)

SQLDeveloper -- Continued Whining

OK, so SQLDeveloper is a free tool from Oracle. I really like it, but am still waiting to see some wrinkles ironed out. For example, it hangs at least twice a day and has to be killed. The PL/SQL formatting still has a LOT to be desired (in fact, the tool seems to be just treat PL/SQL as if it were straight SQL). It still has problems with the File Navigator, importing and exporting Excel spreadsheets, etc. The great thing was that until a year ago, SQLDeveloper was making fairly steady progress. So, if you saw a bug, there was some hope that it would get fixed -- at least partially -- in the next release.

SQLDeveloper is built from JDeveloper -- also free. JDeveloper is fine for Java, but not so hot for PL/SQL (hence, SQLDeveloper, which does better with SQL but still struggles with PL/SQL).

JDeveloper has a data modeler. It's actually quite nice, but has a few quirks -- like the fact that generating is a pain in the butt.

SQLDeveloper Data Modeler is not free, is not built from JDeveloper's data modeler, and is not part of SQLDeveloper. In fact, it appears to be totally unrelated. In testing the pre-release version, it looked like it was some dead Oracle product that got revived and assigned.

And the really crappy thing? Well, it appears that the SQLDeveloper team has been so busy building the SQLDeveloper Data Modeler (instead of just integrating the one that's already in JDeveloper), that each new version of SQLDeveloper has almost nothing in it.

And why are they doing this? Apparently so they can charge for SQLDeveloper Data Modeler. Did I mention that JDeveloper has a free Data Modeler?

??????????

Oracle, you confuse me.

Computer Code and User Expectations

I sling code for a living. However, what I've realized is that users expect

1. The Code should anticipate their needs and "just do the right thing."
2. It should be as custom, fast and beautiful as a hand-built street rod.
3. It should be as cheap, reliable and efficient as a Honda Civic.
4. Every project should be delivered on time, no matter how many times the custom requirements change.
   

If you can't meet those expectation, then you're an idiot. However, the only people that can explain why all of that is so impossible are the very ones that are saying it is impossible. Thus, nobody believes them. It's kinda like the people who don't believe that NASA put a man on the moon because the only verification available is through NASA.

Here's the weird thing. Writing computer programs is still very much in its infancy. When you look at cars, even thirty years ago, they weren't expected to go more than 100,000 miles without major issues. Now, 200,000 without major issues is the expectation.

Cars can be mass-produced mostly because pretty much all cars are solving the same problem. How to get people and stuff from one location to another. There are variations as to how fast , how efficiently, or how stylishly the people and stuff will get moved around, but all those automobiles are really just solving the same problem. However, computer programs are being written to solve any problem that anyone can think of. Kinda tough to mass-produce that. Thus, as long as we are solving new problems, the technology to automatically solve them will be somewhat flaky, unreliable and buggy. Once we have been solving the same problem for over 100 years (like we do with cars), then it should be pretty easy to reliably solve that problem. Kind of a boring problem, but easy to solve.

Keep using your brain, it's only going to get more valuable.

--Og