Slashdot Mirror


User: bdmm

bdmm's activity in the archive.

Stories
0
Comments
5
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 5

  1. Re:I thought ARM on ARM: The Non-Evil Monopolist · · Score: 1

    I thought we were an autonomous collective.

  2. LifeShirt has been around a while on A Black Box for People · · Score: 2, Informative

    Similar item in the form factor of a shirt, links on this page to videos of the shirt:

    LifeShirt Demos

  3. Re:Ever read the mythical man month? on How To Deal With (Techie) Prima Donnas · · Score: 1

    I hope you're writing that with tongue planted firmly in cheek. If not you're writing that with your head planted firmly in your...

    There is no way any company should ever trust one person (no matter how good) with architecting large parts of a system on their own. Every succesful project I have worked on was the result of cooperation, good communication and diligent work. This cooperation encompasses the users who dictate needs, the developers who write it and the testers (yes, our sworn enemies) who beat the living crap out of our creation.

    In contrast my most miserable experiences have been on projects where we mortals were divied out our tasks as the architectural gods saw fit. Needless to say these projects were less impressive then they could have been or were outright failures.

    That said, each company has to look at why they have a prima donna on staff. Some are brought in and others are created by the company.

    I have seen companies that demand an experienced leader be brought in to "see the project through". Willing to overpay for an impressive resume an "expert" is brought in who knows the programming paradigm du jour but has little or no domain knowledge of the business problem.

    The other extreme to this case seems to be the small or midsize company that is usually behind the curve (technologically) and has pressed someone into service writing systems that may or may not be technically sound. These techies usually have the businees knowledge and resent the intrusion of technical types coming in to look over their shoulder. Thus they become prima donnas because their (solely) inside knowledge of the system makes them indispensable.

    So before management heads out to slay the dragon they need to make sure they are incubating the next generation...

  4. Depends on what you're using and doing... on dB Choices - Oracle, DB2 or Something Else? · · Score: 1

    You're choice of DBMS depends primarily on these items:

    1. Price
    2. Platform
    3. Support
    4. Your Industry

    Taking each one briefly, Oracle ain't cheap and DB2 isn't either, but it's cheaper than Oracle.

    Platform - Since you're on the Lintel platform either should work well.

    Support - Both DBs are well supported, most of my experience is with Oracle - once you get past first-level support Oracle actually does a very good job.

    Industry - I work in the clinical trials industry (humans only) and 90% of the all members use Oracle for one thing or another, therfore we use Oracle.

    Also, take the advice I've seen here and hire a DBA to perform setup of your instance. It will save you many problems later. If you will be running a distributed DB consider a full-time DBA.

    It doesn't sound like you are considering anything else, that's good. MySQL lacks many of the features of any enterprise-level DBMS packages, it doesn't even have row indexing.

    I've worked for IBM running M$ SQL Server, Oracle 8i and dabbled briefly in DB2 for benchmarking. Overall I would trust my data to Oracle before any other DB out there - period. With Oracles recent price drop (30%) Oracle 9i falls more in line with the others. It's also much easier to find Oracle experience than any other.

  5. What about documentation?.... on Driving Out Costs with Open Source Tools? · · Score: 1

    My only gripe to date, albeit small, is the quality of the documentation I've seen. I have recently been working with Apache HTTP Server, Tomcat and JBoss only to find all of the documentation either woefully out of date with the current rev or contradictory.

    Case in point: how to make Tomcat v3.2.2 play with Apache v1.3.20. Within the same doc set for Tomcat it gives 2 or more conflicting setup suggestions to make these guys play nicely together.

    For all their evils...well, at least a good number of them...OK, only a few they did in 1988...Microsoft docs are usually(!) spot on.

    While this does not discourage me (take that Bill G!) it certainly detracts from the TCO of these applications while I spend my time scratching my little pea brain or persuing the boards for the correct method.