I second the recommendation for LIDS. I've been using it for the last couple of years.
It's a bit of a pain to install, but it's worth it. Even a root compromise in, say, named means that the black hats can only touch the files that I've explicitly said named can touch.
I've never heard of anybody getting around it, but even if they eventually could, I'd still keep it. It seems the quality of hackers has dropped off since my youth; the breakins I've taken a look at have often been stopped by very minor difficulties (e.g., where the system doesn't allow HTTP out when they try to get their tools, so they just give up).
Well, sometimes I will be working with a OSS software package and I see a way to make a little change to make it better, or fix a bug. Why should any employer/client worry about that?
They probably shouldn't. Most of the open-source packages I use are in the category of "infrastructure"; my clients have no interest in, say, competing with Struts, so there should be no problem releasing improvements to it.
But the client (or employer) is the one who gets to make that decision. You can check the terms of your particular contracts, but by and large software developed on somebody else's nickel belongs to them. It is illegal for you to just up and give it away, and you could put an open source project in serious danger by letting them incorporate code to which they have no rights.
In my experience, this is pretty hard to get in a contract up front, but pretty easy to get once a client is comfortable with me.
What do you really get from paying the big boys big money?
I have a sneaking suspicion I'd come out way ahead financially and operationally if I take the money I save on huge up-front licensing and ongoing per-seat licensing and split it between the business and a support fund, and if we run into a problem we can't handle it's time to hire one of the developers of the software to fix it for us, or in the case of JBoss use the Core Developer's consulting service.
In my experience, that's not a bad way to bet.
I think the large-company support contracts are tuned for supporting the average large corporation developer, who may be moderately smart, but has no bravery whatsoever. What you're buying is the right to ask a lot of dumb questions and have them answered by a patient and friendly person.
Through perseverance, one can also eventually get real problems solved via large-company support contracts, but generally the level of effort required is so large that it's eaiser just to sort things out on your own. Unless you are an important client, of course, in which case you can lean on your sales rep to lean on support. But you don't get that kind of pull from buying a support contract on its own.
I find that open-source developers are a much better deal. One, they're people who are doing the work because they wanted to; paying them to do more work on it is a happy thing for all concerned. Two, they do not have large bureaucracies or sales teams to feed. And three, $10k to your average open source developer is an amount of money that merits notice. Places like IBM and BEA find more than that just by looking under the couch cushions.
The purpose of application servers is to have a canned infrastructure capable of handling these problems well. There are many other plumbing considerations that application servers keep track of...
you missed the point by a mile, the main purpose of the application server is to hold your business logic tier in a multi tier application, so you have a database-vendor neutral application, and the option to use multiple clients like web, standalone desktop applictions, mobile devices etc..etc.., scalability and mangeability are just bonuses...
Don't be silly.
Even if one isn't ever going to change your database, and even if you will have only one type of client, using an application server can be helpful, because of the (hopefully) solid infrastructure they can provide.
And even if one isn't using an application server, it's good design practice to design things in a tiered fashion. You can, and should, keep the business logic pretty separate from the interface code. The same goes for the persistence layer. There's no reason to drop $100k on an app server just to keep your code separate.
That said, I have so far never actually seen a use of EJBs that wasn't a giant clusterfuck. I'm in the middle of rewriting a web app that was built with EJBs, and it's pathetic; using their expensive app server and their expensive Sun hardware, they can serve maybe 60 pageviews a minute.
I'm tearing most of that cruft out and just using Hibernate, a great open-source object/relational persistence layer. One need notdto anything weird to one's objects (no special interfaces, no common base classes, no weird methods). It's swell.
But had I my druthers, I'd have used Prevayler. Their whole dataset is maybe 1 GB. For that, you don't even need a database; you can just keep it all in RAM.
Why add autoboxing to make containers look more "natural with POD types, then ignore the crying need to operator overloading in scientific and engineering applications? Why one piece of syntactic sugar as opposed to another?
I'd guess because Java is focused on the business software market. That's not to knock scientific apps, but Sun's a for-profit company, and it looks like they've decided that enterprise software is the market for Java, and so everybody else takes a back seat.
Re:The problem: Improving programmer productivity
on
Preview of Java 1.5
·
· Score: 0
to make a quantum leap in expressiveness you need a dynamically typed scripting language
Amen to that. It would be lovely to see them take a hint from Ruby.
But I doubt it will happen soon. The whole point of Java is to be the new COBOL, by which I mean it's a language explicitly designed to be relatively safe for mediocre programmers. I find that technically abhorrent, but it's pretty savvy from a busines perspective; by keeping sharp tools out of the hands of idiots, you end with a lot less blood spilled.
That's fixing the wrong problem, of course. The right place to fix a people problem is with the people, not with technology. If you have a strong team that's doing incremental development and is doing what it takes to keep defects below, say, one per programmer-month, then Java's no-sharp-edges approach mainly gets in the way.
With test-first development, regular code reviews (or, better, pair programming), and multiple layers of tests (unit tests and integration tests plus end-to-end black box tests written by a separate QA team) then things like static typing and checked exceptions hinder far more than they help.
But until most programmers are professional enough to adopt quality-focused practices, I don't think a more expressive language has a hope of going mainstream.
I do a big chunk of my development in Java, and as far as I'm concerned, the pace of improvement in the language is glacial. If I recall correctly, Java 1.3 came out in Q1 2000; Java 1.4 came out in Q1 2002. 1.5 isn't due out until the the first half of 2004.
At JavaOne 2000, there was a session on the Collections classes that was overflowing, and it seemed obvious then that generics were needed, and that it couldn't be done well without changes in core Java. I find it mainly disappointing that it takes 4+ years to go from "obviously needed" to "available".
About the only thing I've seen in the Java world that changes quickly is the open-source projects that provide useful stuff. My favorite example is Hibernate, a good object/relational mapping layer.
It seems to me that languages like Java and C# really don't need them.
I can't say for C#, but I'd love them for Java.
Contrast Java's arrays with it collections. Arrays are strongly typed; if you try to put something other than a String into a String array, you'll get an immediate failure. With a List or a Set, though, even if the collection is only supposed to contain Strings, you can put any damned thing you want in.
There are two problems with this. One is that using the collections, your code is littered with casts. In the case where everybody's following the contracts for an object, those casts are useless. And when somebody violates a contract by putting the wrong kind of object in a List, the failure appears later, and possibly much later, making damned hard to find where the bug really is.
That's exactly the sort of mindless but anal bookkeeping that computers do well and humans do poorly. Good languages (which I hope Java might one day be) take burdens like that off of the programmers, leaving them more time to think about the important bits.
I don't want the government making laws about Internet content.
It's about behavior, not content.
Not sure about a difference? Try taking a bullhorn to a quiet residential neigborhood at 4 am. Whatever content you decide to read, even if it's the bill of rights, the cops will be happy to arrest you, and no judge will say boo.
Yeah, that sounds too high, at least for "typical" speeds. Racers certainly can do 30mph on the flat for a while, and obviously anyone can exceed those speeds given a sufficient downhill, but "typical" speeds for bike traffic are probably more like 10-20mph.
Thanks to my trusty bike computer, I can tell you that I average about 10 mph in traffic, with a typical moving speed 12-15 mph and peaks in the 18-20 mph range. During rush hour I beat all busses and maybe a third of cars; during times of light traffic, I'm about even with the busses and slightly slower than cars.
This is in San Francisco; in other cities, YMMV. (Heh, first time I've said that and had it be literally what I meant.)
Telling the computer when I'm done with an object is a simpler solution (to me, anyway) than having to tweak runtime parameters.
Simpler? Sure, if you have just a few objects. But with a lot of objects, it's much, much, much more complicated. As anybody who has spent hours running down a malloc/free error in somebody else's code can tell you.
If you can't use new and delete or free and malloc correctly, then there's probably a lot of other things you can't do well either.
Welcome to the human condition.
I have a limited amount of attention and effort I can spend. The whole point of computers is to take the boring parts and have a machine do them, freeing me to think about the important, interesting parts. For the kind of stuff I code, memory allocation is in the boring category about 99.99% of the time. For the 1 time in 10,000 where it really matters, then fine, I'll write native code. But the rest of the time, let the machines do the donkey work.
For example, I do not see how things would become much more dangerous in Java if you added a delete operator to complement the new operator.
You can make the same argument about a lot of things in Java. E.g., multiple inheritance or platform-dependent code. The theory behind Java is that there are some features that a) take an expert to use properly, b) are dangerous when novices try to use them, and c) complicate things a lot when they exist. So Java doesn't allow those, or at least makes it hard enough to get to that only the experts bother (e.g., JNI).
This sort of daddy-knows-best behavior is annoying, and absent business considerations, I wouldn't put up with it. But if I'm going to have to inherit the code bas of J. Random Programmer, I'd rather it be in Java, because although it's impossible to write really brilliant code, it just can't end up as bad as in C or Perl.
Yes, there is a risk of a legitimate messages being blocked, if the sender does not understand the "confirmation request" mail sent by TDMA, is not willing to answer it (think mailing lists)
Yeah, if I ever thought about using TMDA, having to deal with other people using it has completely turned me off it.
A number of times somebody has posted to a mailing list asking for help. I've answered them privately, only to get a "please jump through the following hoops" message. Fuck that.
There's no way I'd use it, as email is often how clients first make contact with me. I'm unwilling to risk offending or irritating my correspondents, especially when it could mean many dollars lost.
That aside, wouldn't the proper solution be to fix the bug, rather than covering it up by treating the symptom?
Wouldn't the proper solution be to do both? I do a lot of automated testing of my code, both during development and as monitoring of existing systems. I find this improves quality, as it multiple ways to detect and isolate bugs.
I think the trick is to make the failure-recovery actions visible. For example, I once was having problems with Apache seizing up on a high-volume site. I wrote something that hit the site every few seconds; when the lockups happened Apache would be immediately restarted and the team would get email.
Since we were getting notice of failures, it gave us good data about what was going on, and prompted us to fix the problem. Better, because we knew we had a safety net, we were much braver in our experimentation, letting us learn more quickly.
As far as reliability, RAM is more vulnerable to transient things like cosmic radiation. ECC memory will take care of most single-bit problems (there are lots of them...), but all it can do for multi-bit failures is determine that yes, your data is screwed.
This is just a silly argument. It applies equally to in-RAM and on-disk databases. The "on-disk" databases still use RAM with the assumption it just works, and any well-tuned database will keep your most important data in RAM anyhow. And the "in-RAM" databases that I've used do snapshotting and transaction logging to disk.
In either case, if RAM becomes corrupted in a way the hardware doesn't detect, you probably won't notice. If you do notice, about all you can do is try to recover the right data from backups.
Finally, consider the problem of catastrophic system failure. If the power goes out, your RAM dies but your hard disk is still safe. If it is worse (say your facility burns down) then it is much easier to recover data from the charred remnants of a hard disk than from the charred remnants of a DRAM chip.
If somebody is keeping data in a fashion where the best option is to sift through smoldering ashes, find a charred piece of hardware, and hope to hell that somebody in a clean room can pull the data off, then either a) the data isn't important, or b) that person is a dolt.
The right thing to do is to have backups and, if disaster recovery time is important, hot spare servers in a separate location. Thanks to today's cheap bandwidth, it's even possible to keep your servers running transactions in parallel, so that the spare hardware is constantly up to date and doublechecking the work of the primary system. Of course, COTS software is probably 15 years away from taking advantage of that, but it's certainly a possibility in a custom system.
Spam is most definitely an area where very large financial gain is possible. This obviously precludes spammers being "low-rent" sleezebags.
Even if somebody lives in a high-rent place, they can be a low-rent sleazebag. Hollywood is full of them, for example. And that the gain is possible doesn't mean that all spammers get it; the spammers I've taken the time to track down and talk to have often made very little from it.
Generalizations like this do *not* further the anti-spam cause.
Well, actually, they do, especially when they're true. It makes it much easier from a PR and lobbying perspective to be able to say paint spammers as beyond the pale.
I recently chatted with a fellow who's in the on-line porn industry. Although he doesn't spam, he knows a number of spammers. He seemed quite convinced that they were sleazebags. I've met a few myself, and all of them, excepting the once who were just plain clueless, were all sleazebags.
And all the ones I've seen profiled in the press were pathetic excuses for human beings, too. Like the guy in Minnesota, who previously was a cop. Until he got busted for selling drugs to children, that is.
So if you know some spammers who are smart, upstanding, concerned citizens, hey, share the details with us. I'd be fascinated to find once who is a vegan pacifist buddhist. No, scratch that, I'd be fucking floored.
The purpose of email is to facilitate communication. That's it.
Very true. And spam hinders that. I'm getting 2:1 spam vs real mail these days, and it's only getting worse. If I can get rid of a bunch of spam, that will improve email's power to facilitate communication by some factor; let's call it x. Now if that action also impedes communication for some users and we call that y, then using your theory, we should take that action in the cases where x > y.
In my experience, rejecting mail from poorly maintained networks (no PTRs, invalid HELO strings, or on various RBLs) results in a net increase in facilitated communication.
If I send a piece of mail, I generally have no control whatsoever over, or even knowledge of, the bits and pieces that make up the delivery chain.
I can't speak to your knowledge, but you're wrong about the control. If your ISP isn't maintaining their network properly or is spewing spam and gets on RBLs, then you should change your ISP. Last I checked, very few ISPs are using assault weapons to keep their customer base from defecting.
postal service institutes a new regulation
I hate to undermine your frothing here, but this sort of thing goes on all the time.
Any calls without valid caller ID to my phones get diverted to a service called Privacy Manager. I throw away about 90% of my paper mail unopened; if it looks like junk mail, out it goes. The postal service places a large number of restrictions on what you can mail and where you can mail it from. The customs service treats packages and travellers from Canada very differently from those that come from Colombia. Many places (e.g., California, Australia) strongly restrict the kinds of food and plants you can bring in. And let's not forget the travel restrictions, trade restrictions, and quarrantines brought on by diseases like BSE, hoof-and-mouth, and most recently, SARS.
All of these involve using simple, approximate rules to sort the good from the bad. This isn't perfect, but people deal with it because perfect is awfully expensive. It happens all the time, and the exponentially growing flood of spam means that it will happen with email, too.
insufficient time combined with constantly changing requirements? In that case, given time to really do things right could make a difference.
Every project I've ever been on has insufficient time combined with changing requirements. I'm not even sure if I've heard of a project where that wasn't the case.
Given that, I think it's our responsibility to create the necessary space to do good work. Now I only offer clients two options. One is building 100% solid software. The other is building cheap, throwaway prototypes that come with absolutely no guarantees.
As far as I can tell, there's nothing in between. Software that is allowed to be only 95% solid rapidly decays until you reach critical mass. Or, in a lot of corporate situations, you put all your effort into holding together a system that is at the brink of critical mass, leaving you almost no time for improving the code. So if we're going to write garbage, we might as well do it honestly from the start, rather than sneakily or accidentally.
Now convincing bosses and clients that there are only two options isn't easy. But it's a fuck of a lot easier than spending six months working 60 hour weeks trying to keep a crappy code base together while hacking in features according to a release schedule put together by some blowdried doofus in marketing, whose interest in your wellbeing is limited to hoping you don't have a heart attack before the ship date.
I've never had the pleasure of working on a project where there was anybody to say "no" to the customer's latest wacky, impractical, last-minute ideas
You should look into the Extreme Programming practice known as the Planning Game.
The basic notion is that you break a product down into a bunch of little bite-sized features. Each one of these mini-features, called a story, and is written on an index card. The businesspeople can ask for whatever they want, and the programmers estimate it. If the estimate is more than a few days of work, then suits and geeks collaborate to break it down into separate cards that are just a few days in size.
Then the suits get to put the cards into a big stack, ordered by their notions of what's most important, and the developers must build them, a few cards at a time, in that order. The suits may designate any point in the stack as a point where the software gets shipped.
Note the important separation of powers: the suits get to order anything they want. The developers get to say how much it costs. This lets the suits, as they seem to enjoy, have endless meetings about which features get into which releases, while the developers are off coding away on the features that are at the top of the stack. If the business decides that they want to change priorities on stuff a ways down in the stack, that's not a problem; the developers haven't gotten there yet. and if they want to change something already built, that's ok too, as it's a new card that they have to schedule just like everything else.
Although there's a little more to XP scheduling, that's the essence of it. And it sounds too simple to work. But I've done it on several high-pressure projects, and the business analysts and execs have taken to it every time. They love it, as it gives them complete control over the schedule. And the developers love it, because they're not the bad guys anymore; there only job is to make solid stuff, not to resolve impossible scheduling dilemmas. Ok, I'll stop. But if people have more questions, feel free to ask, either here for via email. After years of building software the hard way, I'm absurdly happy that building software doesn't have to hurt.
It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.
That's true only if you don't plan to do anything differently.
I recently got called into consult on a project. They have a bunch of code. They need new features by August. Question #1 is, "Do we start over?"
The current code base mostly works, but it is complete spaghetti code. No architectural coherence, hugely inefficient, absolutely no tests, lots of copy and paste, insane use of exceptions, etc, etc, etc. My first conclusion is that the existing code is totaled.
But there isn't time to rewrite it all by the deadline and get the new features in. So we compromised with the businesspeople. Working together, we designed the new features in such a way that we touch as little of the old code as possible. Features that required modifying old code got very high estimates, so the suits deferred most of them. Further, all new code will be developed with full unit tests and functional tests, with energetic refactoring so that the architecture is solid. This gives us a good foundation to build from.
Then, after the release, we'll see what we can do with the old code. Thanks to a highly interactive estimation process (XP's Planning Game), the business people really get that touching old code is expensive. And we've also explained that hacking new stuff into existing code is throwing good money after bad; when asking for those features, they frequently ask how much of the effort can be reused. So they're almost as interested in getting rid of the old stuff as we are.
So my tips for a rewrite are:
Don't rewrite everything at once. Do it in a way where you can provide a stream of new releases, rewriting as you go.
Make the economic case for a rewrite clear. If you're getting a paycheck for this, you're obligated to help them get the best value for their money.
Don't do the same old thing. Figure out why the current code base sucks, and take clear steps not to repeat their errors. E.g.,
write unit tests and functional tests (preferrably before you write the code)
continuously refactor your code
do code reviews and design reviews (or, better, pair programming).
Measure the difference you're supposedly making. If your bug rates, design metrics, code metrics, reliability of hitting estimates, and performance aren't clearly better than the existing product, then maybe you're doing a rewrite for the wrong reasons.
Be humble. The reason the current code base sucks is that the last chumps got in over their heads. Be sure that you aren't doing the same. Remember, they probably looked at the previous old system and said, "Gosh, we could rewrite this and make it so much better!"
Make sure this is the last rewrite. Sure, future requirements always mean that parts of the app will be changed. But make sure the code never gets so stinky that it needs to be tossed. Every couple of months call in somebody from outside the team to review things and give you an honest checkup.
After a lot of research, I recently both the Archos Recorder 20, and I love it. The software in ROM isn't so great, but that's OK, as there is Rockbox, an open-source project that has very good software that is getting better all the time. When you plug it into your computer, it's just a USB hard drive, so you can manage your music with whatever you want (I just use rsync to sync from my main box to the portable).
The price also seemed great to me; the 20 gig model was circa $200 from Harmony. And even if I never do it, the fact that if somethings annoys me enough I can just go in and fix the code myself is a damned good feature.
I'm just curious, but how did your trader friends figure out when to SELL? After BSchool, I did exactly what you describe, and found I could buy things just fine, but giving up on the stock was the tricky bit.
The glib answer I give is that we used cutting-edge neural networks. But since this is Slashdot, I'll reveal the truth: We had good traders.
How they got that way, I dunno. The best traders were street-smart guys with nerves of steel who had been doing it for years. If you asked them why they did any particular trade, they'd be willing to talk about all sorts of economic, business, and financial issues. But then the honest ones would say, "Hell, I don't know. I just felt like it was time to sell."
To get more traders, we'd start with fresh youngsters. They'd clerk for a while, and then we'd put them in the pits under supervision. Either they got it or they didn't.
The reason I don't normally explain this is that everybody thinks that they are pretty smart, that they can get it. Especially geeks. But this is a lot like watching the Olympics on TV and saying, "Hey, I can run and jump. I could do that!"
But stepping into the ring with professional traders is worse than just turning up at the Olympics and giving it a go. Because you're not just going up against the best people in the world; you're also going up against all the advantages that money can buy. It's like showing up as a natural human at an Olympics where the athletes from rich countries have all the performance enhancing drugs and maybe some cyborg body parts.
Obviously, I'm comfortably in index funds now, and not really paying attention to the market. Whatever keeps my mind off my 401k.
That's exactly the way to do it. It'll never make you rich, but it guarantees that you won't be begging for change when you retire, which is exactly where the OP is headed.
Dude? Seriously. How about a nice savings account? maybe some cd's, short term bond funds? How's your credit card debt?
No shit. I used to work for real financial traders, doing risk management systems. We thought the day traders were great comedy.
Note to the OP: If you're so sure you're right about your vast financial acumen and your ability to go up against trained professionals backed by billions of dollars, then prove it by playing a little game.
Instead of trading with real money, just pretend. Keep track of all your trades, deducting for fees, commision, spread, and the other sorts of friction. If you can make pretend money for three months, and do better than a good fund, then you might be ready to swim with the sharks.
Otherwise, just admit to yourself that you are playing the ponies, that you are playing a big, fun, but very expensive video game.
And either way, only gamble with money you can afford to lose. If you have trouble telling the difference, then put the rest of your money in the hands of a friend and tell them not to let you have it for trading. Because an awful lot of people who thought they were pretty smart have ended up losing their houses, their retirement savings, money from family and friends and, quite literally, their shirts. And often, when they did something illegal to get the money, they even lost their freedom.
2 billion sounds like a big number, but it's still only 10-30 spams for the typical AOL user.
You think AOL has circa 100 million users? Got some stats to back that up? My recollection is it's more like a third of that, meaning an average of 60 per user.And growing exponentially, with no end in sight.
But even at 10-30, that's still quite a bit when you only get a couple of real messages a day and check your email a couple of times a week, as is typical for the AOL types that I know.
2 Billion emails divided by 180 spammers equals approx 11 millions emails per spammer per day *just to AOL alone*.
The word I hear from a reliable source is that to do spamming as a viable business, you must be sending at least 10 million spams per day.
So if the low end of the bell curve is circa 10m, it's easy to believe that AOL's share of that can peak at an average of 11m per major spammer. It would make sense for spammers to focus on AOL users, both because there's a lot of 'em in one place and because they are, uh, less sophisticated than your average internet user.
Slashdot Mirror
LIDS
I second the recommendation for LIDS. I've been using it for the last couple of years.
It's a bit of a pain to install, but it's worth it. Even a root compromise in, say, named means that the black hats can only touch the files that I've explicitly said named can touch.
I've never heard of anybody getting around it, but even if they eventually could, I'd still keep it. It seems the quality of hackers has dropped off since my youth; the breakins I've taken a look at have often been stopped by very minor difficulties (e.g., where the system doesn't allow HTTP out when they try to get their tools, so they just give up).
Well, sometimes I will be working with a OSS software package and I see a way to make a little change to make it better, or fix a bug. Why should any employer/client worry about that?
They probably shouldn't. Most of the open-source packages I use are in the category of "infrastructure"; my clients have no interest in, say, competing with Struts, so there should be no problem releasing improvements to it.
But the client (or employer) is the one who gets to make that decision. You can check the terms of your particular contracts, but by and large software developed on somebody else's nickel belongs to them. It is illegal for you to just up and give it away, and you could put an open source project in serious danger by letting them incorporate code to which they have no rights.
In my experience, this is pretty hard to get in a contract up front, but pretty easy to get once a client is comfortable with me.
What do you really get from paying the big boys big money?
I have a sneaking suspicion I'd come out way ahead financially and operationally if I take the money I save on huge up-front licensing and ongoing per-seat licensing and split it between the business and a support fund, and if we run into a problem we can't handle it's time to hire one of the developers of the software to fix it for us, or in the case of JBoss use the Core Developer's consulting service.
In my experience, that's not a bad way to bet.
I think the large-company support contracts are tuned for supporting the average large corporation developer, who may be moderately smart, but has no bravery whatsoever. What you're buying is the right to ask a lot of dumb questions and have them answered by a patient and friendly person.
Through perseverance, one can also eventually get real problems solved via large-company support contracts, but generally the level of effort required is so large that it's eaiser just to sort things out on your own. Unless you are an important client, of course, in which case you can lean on your sales rep to lean on support. But you don't get that kind of pull from buying a support contract on its own.
I find that open-source developers are a much better deal. One, they're people who are doing the work because they wanted to; paying them to do more work on it is a happy thing for all concerned. Two, they do not have large bureaucracies or sales teams to feed. And three, $10k to your average open source developer is an amount of money that merits notice. Places like IBM and BEA find more than that just by looking under the couch cushions.
Don't be silly.
Even if one isn't ever going to change your database, and even if you will have only one type of client, using an application server can be helpful, because of the (hopefully) solid infrastructure they can provide.
And even if one isn't using an application server, it's good design practice to design things in a tiered fashion. You can, and should, keep the business logic pretty separate from the interface code. The same goes for the persistence layer. There's no reason to drop $100k on an app server just to keep your code separate.
That said, I have so far never actually seen a use of EJBs that wasn't a giant clusterfuck. I'm in the middle of rewriting a web app that was built with EJBs, and it's pathetic; using their expensive app server and their expensive Sun hardware, they can serve maybe 60 pageviews a minute.
I'm tearing most of that cruft out and just using Hibernate, a great open-source object/relational persistence layer. One need notdto anything weird to one's objects (no special interfaces, no common base classes, no weird methods). It's swell.
But had I my druthers, I'd have used Prevayler. Their whole dataset is maybe 1 GB. For that, you don't even need a database; you can just keep it all in RAM.
By a similar process we can calculate that 99% of all ocean-front homes are pirated.
Looking at how people who can blow $10m on a house get their money, that seems to be accurate.
Why add autoboxing to make containers look more "natural with POD types, then ignore the crying need to operator overloading in scientific and engineering applications? Why one piece of syntactic sugar as opposed to another?
I'd guess because Java is focused on the business software market. That's not to knock scientific apps, but Sun's a for-profit company, and it looks like they've decided that enterprise software is the market for Java, and so everybody else takes a back seat.
to make a quantum leap in expressiveness you need a dynamically typed scripting language
Amen to that. It would be lovely to see them take a hint from Ruby.
But I doubt it will happen soon. The whole point of Java is to be the new COBOL, by which I mean it's a language explicitly designed to be relatively safe for mediocre programmers. I find that technically abhorrent, but it's pretty savvy from a busines perspective; by keeping sharp tools out of the hands of idiots, you end with a lot less blood spilled.
That's fixing the wrong problem, of course. The right place to fix a people problem is with the people, not with technology. If you have a strong team that's doing incremental development and is doing what it takes to keep defects below, say, one per programmer-month, then Java's no-sharp-edges approach mainly gets in the way.
With test-first development, regular code reviews (or, better, pair programming), and multiple layers of tests (unit tests and integration tests plus end-to-end black box tests written by a separate QA team) then things like static typing and checked exceptions hinder far more than they help.
But until most programmers are professional enough to adopt quality-focused practices, I don't think a more expressive language has a hope of going mainstream.
Java changes every couple of months
Sorry, but what are you talking about?
I do a big chunk of my development in Java, and as far as I'm concerned, the pace of improvement in the language is glacial. If I recall correctly, Java 1.3 came out in Q1 2000; Java 1.4 came out in Q1 2002. 1.5 isn't due out until the the first half of 2004.
At JavaOne 2000, there was a session on the Collections classes that was overflowing, and it seemed obvious then that generics were needed, and that it couldn't be done well without changes in core Java. I find it mainly disappointing that it takes 4+ years to go from "obviously needed" to "available".
About the only thing I've seen in the Java world that changes quickly is the open-source projects that provide useful stuff. My favorite example is Hibernate, a good object/relational mapping layer.
It seems to me that languages like Java and C# really don't need them.
I can't say for C#, but I'd love them for Java.
Contrast Java's arrays with it collections. Arrays are strongly typed; if you try to put something other than a String into a String array, you'll get an immediate failure. With a List or a Set, though, even if the collection is only supposed to contain Strings, you can put any damned thing you want in.
There are two problems with this. One is that using the collections, your code is littered with casts. In the case where everybody's following the contracts for an object, those casts are useless. And when somebody violates a contract by putting the wrong kind of object in a List, the failure appears later, and possibly much later, making damned hard to find where the bug really is.
That's exactly the sort of mindless but anal bookkeeping that computers do well and humans do poorly. Good languages (which I hope Java might one day be) take burdens like that off of the programmers, leaving them more time to think about the important bits.
I don't want the government making laws about
Internet content.
It's about behavior, not content.
Not sure about a difference? Try taking a bullhorn to a quiet residential neigborhood at 4 am. Whatever content you decide to read, even if it's the bill of rights, the cops will be happy to arrest you, and no judge will say boo.
Yeah, that sounds too high, at least for "typical" speeds. Racers certainly can do 30mph on the flat for a while, and obviously anyone can exceed those speeds given a sufficient downhill, but "typical" speeds for bike traffic are probably more like 10-20mph.
Thanks to my trusty bike computer, I can tell you that I average about 10 mph in traffic, with a typical moving speed 12-15 mph and peaks in the 18-20 mph range. During rush hour I beat all busses and maybe a third of cars; during times of light traffic, I'm about even with the busses and slightly slower than cars.
This is in San Francisco; in other cities, YMMV. (Heh, first time I've said that and had it be literally what I meant.)
Telling the computer when I'm done with an object is a simpler solution (to me, anyway) than having to tweak runtime parameters.
Simpler? Sure, if you have just a few objects. But with a lot of objects, it's much, much, much more complicated. As anybody who has spent hours running down a malloc/free error in somebody else's code can tell you.
If you can't use new and delete or free and malloc correctly, then there's probably a lot of other things you can't do well either.
Welcome to the human condition.
I have a limited amount of attention and effort I can spend. The whole point of computers is to take the boring parts and have a machine do them, freeing me to think about the important, interesting parts. For the kind of stuff I code, memory allocation is in the boring category about 99.99% of the time. For the 1 time in 10,000 where it really matters, then fine, I'll write native code. But the rest of the time, let the machines do the donkey work.
For example, I do not see how things would become much more dangerous in Java if you added a delete operator to complement the new operator.
You can make the same argument about a lot of things in Java. E.g., multiple inheritance or platform-dependent code. The theory behind Java is that there are some features that a) take an expert to use properly, b) are dangerous when novices try to use them, and c) complicate things a lot when they exist. So Java doesn't allow those, or at least makes it hard enough to get to that only the experts bother (e.g., JNI).
This sort of daddy-knows-best behavior is annoying, and absent business considerations, I wouldn't put up with it. But if I'm going to have to inherit the code bas of J. Random Programmer, I'd rather it be in Java, because although it's impossible to write really brilliant code, it just can't end up as bad as in C or Perl.
Are you new here? Usually people call this kind of thing a meme.
Meme is a more general term, like gene. Urban legend is a more specific term, like virus.
Yes, there is a risk of a legitimate messages being blocked, if the sender does not understand the "confirmation request" mail sent by TDMA, is not willing to answer it (think mailing lists)
Yeah, if I ever thought about using TMDA, having to deal with other people using it has completely turned me off it.
A number of times somebody has posted to a mailing list asking for help. I've answered them privately, only to get a "please jump through the following hoops" message. Fuck that.
There's no way I'd use it, as email is often how clients first make contact with me. I'm unwilling to risk offending or irritating my correspondents, especially when it could mean many dollars lost.
That aside, wouldn't the proper solution be to fix the bug, rather than covering it up by treating the symptom?
Wouldn't the proper solution be to do both? I do a lot of automated testing of my code, both during development and as monitoring of existing systems. I find this improves quality, as it multiple ways to detect and isolate bugs.
I think the trick is to make the failure-recovery actions visible. For example, I once was having problems with Apache seizing up on a high-volume site. I wrote something that hit the site every few seconds; when the lockups happened Apache would be immediately restarted and the team would get email.
Since we were getting notice of failures, it gave us good data about what was going on, and prompted us to fix the problem. Better, because we knew we had a safety net, we were much braver in our experimentation, letting us learn more quickly.
As far as reliability, RAM is more vulnerable to transient things like cosmic radiation. ECC memory will take care of most single-bit problems (there are lots of them...), but all it can do for multi-bit failures is determine that yes, your data is screwed.
This is just a silly argument. It applies equally to in-RAM and on-disk databases. The "on-disk" databases still use RAM with the assumption it just works, and any well-tuned database will keep your most important data in RAM anyhow. And the "in-RAM" databases that I've used do snapshotting and transaction logging to disk.
In either case, if RAM becomes corrupted in a way the hardware doesn't detect, you probably won't notice. If you do notice, about all you can do is try to recover the right data from backups.
Finally, consider the problem of catastrophic system failure. If the power goes out, your RAM dies but your hard disk is still safe. If it is worse (say your facility burns down) then it is much easier to recover data from the charred remnants of a hard disk than from the charred remnants of a DRAM chip.
If somebody is keeping data in a fashion where the best option is to sift through smoldering ashes, find a charred piece of hardware, and hope to hell that somebody in a clean room can pull the data off, then either a) the data isn't important, or b) that person is a dolt.
The right thing to do is to have backups and, if disaster recovery time is important, hot spare servers in a separate location. Thanks to today's cheap bandwidth, it's even possible to keep your servers running transactions in parallel, so that the spare hardware is constantly up to date and doublechecking the work of the primary system. Of course, COTS software is probably 15 years away from taking advantage of that, but it's certainly a possibility in a custom system.
Spam is most definitely an area where very large financial gain is possible. This obviously precludes spammers being "low-rent" sleezebags.
Even if somebody lives in a high-rent place, they can be a low-rent sleazebag. Hollywood is full of them, for example. And that the gain is possible doesn't mean that all spammers get it; the spammers I've taken the time to track down and talk to have often made very little from it.
Generalizations like this do *not* further the anti-spam cause.
Well, actually, they do, especially when they're true. It makes it much easier from a PR and lobbying perspective to be able to say paint spammers as beyond the pale.
I recently chatted with a fellow who's in the on-line porn industry. Although he doesn't spam, he knows a number of spammers. He seemed quite convinced that they were sleazebags. I've met a few myself, and all of them, excepting the once who were just plain clueless, were all sleazebags.
And all the ones I've seen profiled in the press were pathetic excuses for human beings, too. Like the guy in Minnesota, who previously was a cop. Until he got busted for selling drugs to children, that is.
So if you know some spammers who are smart, upstanding, concerned citizens, hey, share the details with us. I'd be fascinated to find once who is a vegan pacifist buddhist. No, scratch that, I'd be fucking floored.
The purpose of email is to facilitate communication. That's it.
Very true. And spam hinders that. I'm getting 2:1 spam vs real mail these days, and it's only getting worse. If I can get rid of a bunch of spam, that will improve email's power to facilitate communication by some factor; let's call it x. Now if that action also impedes communication for some users and we call that y, then using your theory, we should take that action in the cases where x > y.
In my experience, rejecting mail from poorly maintained networks (no PTRs, invalid HELO strings, or on various RBLs) results in a net increase in facilitated communication.
If I send a piece of mail, I generally have no control whatsoever over, or even knowledge of, the bits and pieces that make up the delivery chain.
I can't speak to your knowledge, but you're wrong about the control. If your ISP isn't maintaining their network properly or is spewing spam and gets on RBLs, then you should change your ISP. Last I checked, very few ISPs are using assault weapons to keep their customer base from defecting.
postal service institutes a new regulation
I hate to undermine your frothing here, but this sort of thing goes on all the time.
Any calls without valid caller ID to my phones get diverted to a service called Privacy Manager. I throw away about 90% of my paper mail unopened; if it looks like junk mail, out it goes. The postal service places a large number of restrictions on what you can mail and where you can mail it from. The customs service treats packages and travellers from Canada very differently from those that come from Colombia. Many places (e.g., California, Australia) strongly restrict the kinds of food and plants you can bring in. And let's not forget the travel restrictions, trade restrictions, and quarrantines brought on by diseases like BSE, hoof-and-mouth, and most recently, SARS.
All of these involve using simple, approximate rules to sort the good from the bad. This isn't perfect, but people deal with it because perfect is awfully expensive. It happens all the time, and the exponentially growing flood of spam means that it will happen with email, too.
insufficient time combined with constantly changing requirements? In that case, given time to really do things right could make a difference.
Every project I've ever been on has insufficient time combined with changing requirements. I'm not even sure if I've heard of a project where that wasn't the case.
Given that, I think it's our responsibility to create the necessary space to do good work. Now I only offer clients two options. One is building 100% solid software. The other is building cheap, throwaway prototypes that come with absolutely no guarantees.
As far as I can tell, there's nothing in between. Software that is allowed to be only 95% solid rapidly decays until you reach critical mass. Or, in a lot of corporate situations, you put all your effort into holding together a system that is at the brink of critical mass, leaving you almost no time for improving the code. So if we're going to write garbage, we might as well do it honestly from the start, rather than sneakily or accidentally.
Now convincing bosses and clients that there are only two options isn't easy. But it's a fuck of a lot easier than spending six months working 60 hour weeks trying to keep a crappy code base together while hacking in features according to a release schedule put together by some blowdried doofus in marketing, whose interest in your wellbeing is limited to hoping you don't have a heart attack before the ship date.
I've never had the pleasure of working on a project where there was anybody to say "no" to the customer's latest wacky, impractical, last-minute ideas
You should look into the Extreme Programming practice known as the Planning Game.
The basic notion is that you break a product down into a bunch of little bite-sized features. Each one of these mini-features, called a story, and is written on an index card. The businesspeople can ask for whatever they want, and the programmers estimate it. If the estimate is more than a few days of work, then suits and geeks collaborate to break it down into separate cards that are just a few days in size.
Then the suits get to put the cards into a big stack, ordered by their notions of what's most important, and the developers must build them, a few cards at a time, in that order. The suits may designate any point in the stack as a point where the software gets shipped.
Note the important separation of powers: the suits get to order anything they want. The developers get to say how much it costs. This lets the suits, as they seem to enjoy, have endless meetings about which features get into which releases, while the developers are off coding away on the features that are at the top of the stack. If the business decides that they want to change priorities on stuff a ways down in the stack, that's not a problem; the developers haven't gotten there yet. and if they want to change something already built, that's ok too, as it's a new card that they have to schedule just like everything else.
Although there's a little more to XP scheduling, that's the essence of it. And it sounds too simple to work. But I've done it on several high-pressure projects, and the business analysts and execs have taken to it every time. They love it, as it gives them complete control over the schedule. And the developers love it, because they're not the bad guys anymore; there only job is to make solid stuff, not to resolve impossible scheduling dilemmas.
Ok, I'll stop. But if people have more questions, feel free to ask, either here for via email. After years of building software the hard way, I'm absurdly happy that building software doesn't have to hurt.
That's true only if you don't plan to do anything differently.
I recently got called into consult on a project. They have a bunch of code. They need new features by August. Question #1 is, "Do we start over?"
The current code base mostly works, but it is complete spaghetti code. No architectural coherence, hugely inefficient, absolutely no tests, lots of copy and paste, insane use of exceptions, etc, etc, etc. My first conclusion is that the existing code is totaled.
But there isn't time to rewrite it all by the deadline and get the new features in. So we compromised with the businesspeople. Working together, we designed the new features in such a way that we touch as little of the old code as possible. Features that required modifying old code got very high estimates, so the suits deferred most of them. Further, all new code will be developed with full unit tests and functional tests, with energetic refactoring so that the architecture is solid. This gives us a good foundation to build from.
Then, after the release, we'll see what we can do with the old code. Thanks to a highly interactive estimation process (XP's Planning Game), the business people really get that touching old code is expensive. And we've also explained that hacking new stuff into existing code is throwing good money after bad; when asking for those features, they frequently ask how much of the effort can be reused. So they're almost as interested in getting rid of the old stuff as we are.
So my tips for a rewrite are:
The Archos is the way to go.
After a lot of research, I recently both the Archos Recorder 20, and I love it. The software in ROM isn't so great, but that's OK, as there is Rockbox, an open-source project that has very good software that is getting better all the time. When you plug it into your computer, it's just a USB hard drive, so you can manage your music with whatever you want (I just use rsync to sync from my main box to the portable).
The price also seemed great to me; the 20 gig model was circa $200 from Harmony. And even if I never do it, the fact that if somethings annoys me enough I can just go in and fix the code myself is a damned good feature.
I'm just curious, but how did your trader friends figure out when to SELL? After BSchool, I did exactly what you describe, and found I could buy things just fine, but giving up on the stock was the tricky bit.
The glib answer I give is that we used cutting-edge neural networks. But since this is Slashdot, I'll reveal the truth: We had good traders.
How they got that way, I dunno. The best traders were street-smart guys with nerves of steel who had been doing it for years. If you asked them why they did any particular trade, they'd be willing to talk about all sorts of economic, business, and financial issues. But then the honest ones would say, "Hell, I don't know. I just felt like it was time to sell."
To get more traders, we'd start with fresh youngsters. They'd clerk for a while, and then we'd put them in the pits under supervision. Either they got it or they didn't.
The reason I don't normally explain this is that everybody thinks that they are pretty smart, that they can get it. Especially geeks. But this is a lot like watching the Olympics on TV and saying, "Hey, I can run and jump. I could do that!"
But stepping into the ring with professional traders is worse than just turning up at the Olympics and giving it a go. Because you're not just going up against the best people in the world; you're also going up against all the advantages that money can buy. It's like showing up as a natural human at an Olympics where the athletes from rich countries have all the performance enhancing drugs and maybe some cyborg body parts.
Obviously, I'm comfortably in index funds now, and not really paying attention to the market. Whatever keeps my mind off my 401k.
That's exactly the way to do it. It'll never make you rich, but it guarantees that you won't be begging for change when you retire, which is exactly where the OP is headed.
Dude? Seriously. How about a nice savings account? maybe some cd's, short term bond funds? How's your credit card debt?
No shit. I used to work for real financial traders, doing risk management systems. We thought the day traders were great comedy.
Note to the OP: If you're so sure you're right about your vast financial acumen and your ability to go up against trained professionals backed by billions of dollars, then prove it by playing a little game.
Instead of trading with real money, just pretend. Keep track of all your trades, deducting for fees, commision, spread, and the other sorts of friction. If you can make pretend money for three months, and do better than a good fund, then you might be ready to swim with the sharks.
Otherwise, just admit to yourself that you are playing the ponies, that you are playing a big, fun, but very expensive video game.
And either way, only gamble with money you can afford to lose. If you have trouble telling the difference, then put the rest of your money in the hands of a friend and tell them not to let you have it for trading. Because an awful lot of people who thought they were pretty smart have ended up losing their houses, their retirement savings, money from family and friends and, quite literally, their shirts. And often, when they did something illegal to get the money, they even lost their freedom.
2 billion sounds like a big number, but it's still only 10-30 spams for the typical AOL user.
You think AOL has circa 100 million users? Got some stats to back that up? My recollection is it's more like a third of that, meaning an average of 60 per user.And growing exponentially, with no end in sight.
But even at 10-30, that's still quite a bit when you only get a couple of real messages a day and check your email a couple of times a week, as is typical for the AOL types that I know.
2 Billion emails divided by 180 spammers equals approx 11 millions emails per spammer per day *just to AOL alone*.
The word I hear from a reliable source is that to do spamming as a viable business, you must be sending at least 10 million spams per day.
So if the low end of the bell curve is circa 10m, it's easy to believe that AOL's share of that can peak at an average of 11m per major spammer. It would make sense for spammers to focus on AOL users, both because there's a lot of 'em in one place and because they are, uh, less sophisticated than your average internet user.