Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment Re:No speed limits as well... (Score 2) 600

It amuses me that people think that crippling infrastructure is the way to increase safety. I'd say it's bloody obvious because the correlation is less speed = more safety.

So the next step is to replace those roads with cobblestones... I'm sure people will slow down and accidents will decrease even further.

The real innovation will be when you can drive safer and faster at the same time. Lines help with that, as do wider roads.

Comment Refactor strategy (Score 1, Informative) 197

When I want to refactor code, I first make sure we're working in a programming language that is suited for refactoring. That usually means it must be Java... nothing comes close in refactorability. It certainly rules out anything that isn't extensively checked by a compiler (eg. Javascript) -- there's always code paths that aren't covered in tests, and you rely on the compiler to warn you of potential problems in those.

Second, I make sure there are good tests available, not just unit tests but also integration tests. This is usually the case on projects I work on, or I won't be sticking around for long.

Third, I do refactors in tiny incremental steps. Usually it's like "remove one method", "remove a parameter", "add/remove an interface", "delete a class", "split a class", "move a method", "make a parameter required by moving it to a constructor", "make something immutable by removing its setter".

As soon as you do one of those, there are gonna be errors detected by the compiler. I ignore the ones in tests and quickly check the ones in real code to see if the refactoring does not have something I did not foresee that would be tough to fix. If there's something unforeseen, I think about what refactoring would be need to be done before this one that would make that easier to fix later.

Once it looks like it will work, I fix the errors in one class, then in its test, then run the test to see if nothing broke. Then I go to next class, until all the errors are gone (usually this takes around an hour for 50-200 errors when I started).

I then run all the tests, and if everything is ok, I make a commit of that refactor step. Then I start with the next incremental refactor step. At any time, I can merge the stuff with master and stop and work on something else, while still having some small benefits of the refactorings done so far.

In this fashion I've refactored existing code bases to use a different time/date system, refactored code to use two different models (instead of a unified one), made models slowly immutable (it's amazing how many problems you discover when you start doing that), etcetera.

Comment Re:proprietary vs postgres (Score 4, Interesting) 104

I've used both in commercial environments. Since we abstract everything away in Java using ORM layers, you hardly notice the "Oracle" underneath, so it's workable.

However, any direct contact with Oracle DB's reveals their ugly roots -- it seems the entire product is something bolted on top of an engine build in the 80's, with all kinds of quirks that nobody expects anymore of a modern DB. Here are some the quirks I hated:

- VARCHAR empty string is treated as NULL by Oracle. No switch to turn it off anywhere.
- Oracle does not do transactional DDL -- that is if I upgrade my database by dropping some tables and moving some data around, and the process fails halfway due to some inconsistency, you're left to sort it out on your own... no rollbacks.
- No database types for 32/64 bit integers, so there's often a mismatch with the type in the database and the type in your programs. No boolean type. No date type.
- Error messages are (were?) often of the kind "duplicate key violated" -- no additional info which key, which row or columns were involved
- Their tools feel like they were build in the 80's -- and the 3rd party tools aren't much better. Both mysql and postgresql have way better tools.
- Doing INSERTs in a Table which happens to have some foreign keys can result in "too many open cursors" -- what cursor? The internal one it created itself to check the foreign key? What do I care? This results in code that has to do COMMITS every 50 rows (or whatever you have configured the db with).
- Schemas, users, databases... it seems to be all the same in Oracle.
- Many settings in Oracle are global for all databases, but many of those settings would be much more useful if they could be set per database

Oracle however seems to have little interest in fixing these things and getting some good will from people that actually have to work with their systems. They only care about selling the big features, never mind that almost nobody needs them.

Try PostgreSQL -- by the time you feel it no longer fits your needs, consult and expert to look at how you do your queries and indices (the #1 cause of bad performance). If it still doesn't fit your needs after that, you might have a reason to try Oracle.

Slashdot Top Deals

"Remember, extremism in the nondefense of moderation is not a virtue." -- Peter Neumann, about usenet