Seems to me like OQO is killing itself just fine without any help.
I've wanted one for a year and a half, but the ever-receding launch date has gotten out of hand. I know they were accepting pre-orders at some point. Wonder if those people will ever see an OQO or thier money...
[quote]A study last year by Meta Group Inc. in Stamford, Conn., found that 55% of IT workers with mainframe experience are over 50 years old.[/quote]
All your mainframe operators are belong to retirement home. They are on the way to senility. You have no chance to update cobol make your time.
*ITS A JOKE. I PLAN ON WORKING TILL IM 80*
Seriously though, I hope mainframe skills make a comeback, properly infused with the spirit of freedom that UNIX and minicomputers have given us. It's no fair that the old timers get to play with all the kick ass hardware. Just imagine a beowulf... Oh fsck it...
"It may be me, but I would rather have a cheaper, lighter notebook with a long (8 hours or there abouts) batterylife than a HDTV+DVD-player combo with a computer attaced. But hey, each to his or her own."
Ditto
check out http://www.dynamism.com. Japanese laptops with a US warranty.
The sharp MM1 looks sweet, and it doubles as a USB2 hard drive.
[quote] And the List thing is tired. We all know that Java is limited. It's limited compared to C++, it's limited compared to Lisp. Ya know what? That's a good thing. For......y because people haven't had to manage teams of developers who aren't populated throughout with brilliant coders, capable of writing fast, functional readable code in languages that leave n degrees of freedom....
Of course, when I'm working on my own time on my own projects, I far prefer to use a manly language like C++, or a pleasant language like Python. [/quote]
For what its worth, on these points, I totally agree with you.
Aspect oriented programming is moderately useful, though, if it isn't built into the language (and, in java, it isn't) it can be cumbersome to work with.
In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.
By and large, the more I work in java, and the more I work in Lisp, I realize how lacking java is in dynamic behaviors. The lisp guys yawned when OO became all the rage because, well, it is so easy to do in lisp. If AOP gets big in java, they will yawn at that too:
"Oh, so functions and try blocks are your boundry block for inserting aspect oriented code? Well, *every parenthisis* is ours. Put that in your JVM and smoke it."
All of those things, ALL of them, are designed to make SQL be able to imitate the operations which are naturally atomic in an object programming model. SQL created the solution, yes; but it also created the problem.
Ditto for transactions.
Really? Sub-selects are atomic at the object model level? Come again?
So some new Object database tarted up with fancy-schmancy new terminology suddenly makes transactions easy? Multiple updates to an object graph from multiple threads in a transactional manner become, somehow, easier? _rolls eyes_ Riiiiiiiight...
Instead, you have programmers who can do all that work. It's what they're paid for.
Great! As a programmer who _can_ do all that work, I'll be happily employed forever! Oh wait, daily hot backups kinda suck to be around for. And chucking stored procs for intensive operations kinda sucks. Oh well, at least I'll be able to bill at twice what a competent dba can.
The first part is true. The second part is laughable.
*smiles* Less laughable than the notion that a wet-behind-the-ears-yet-another-stab-at-an-object- database scales well.
A good part of the purpose of this solution is to make those possible. The article discusses them in depth.
In reading the article I didn't see any arguments/methods that all the good-ol' object database guys haven't offered as the Holy Grail as well. I agree O/R impedence sucks. But code like this:
User u = (User) ((UserManager)
prevayler.system()).getUsers().get(login);
Well, you'll forgive me if I'm not impressed. Get all users? And what about in big ol' databases, when not everything can live in memory?
Look, I hate, hate, HATE jdbc as much as the next guy. But the object database guys have been around for years now and they aren't winning much in mainstream business, and, when I've worked with them, there have been serious tradeoffs in scalability, query expressiveness and data store management. Enough so that, though it might guarantee my employment to do so, I don't recommend them to my boss.
Depending on your circumstances, you may find that the tradeoffs are worth it, but, in my experience, the people who would recommend this are either: vendors themselves, consultants who want to remain employed at high rates forever or bored programmers.
Given that the probability that any/.er reads an article is inversely related to the size of the article, I have computed that exactly:.00000000000000000003243523426092345%
This is not a new idea. There are all sorts of object databases out there. (Versant springs to mind).
The main problems I see with object databases:
1) SQL is incredibly powerful. You give up *a lot* of power when you go from sql semantics to object semantics. Sub-selects, group bys and optimized stored procedures, to name just a few things. All the object language query constructs I've seen fall far short of these. (As a side note, most O/R tools make a hash of it as well.)
2) You immedately make a massive reduction in the number of database administrators who will be willing and/or capable of helping you out in your project.
3) Scaling is always a question. With oracle, it just isn't.
4) Backup, redundancy, monitoring, management, etc. Most mature relational databases have very good tools for doing these infrastructure activities. Developers often forget about banal things like this, but they are crucial for the long term health of IT systems.
Don't get me wrong. Every time I construct some nasty query and go through the mind-numbing process of moving the results into an object, I think to myself "There has to be a better way!", but I've looked at the O/R tools and the object database out there and, sadly, I don't feel they are worth the trade off.
Right on. So don't test against the database directly. Use mock objects. Since you're doing J2EE, I reckon you're using JDBC in your session beans, or you're using a bunch of entity beans, or you've got some sort of DAOish layer somewhere. Any of those can be mocked up in one way or another; give it a whirl.
Two problems with this:
You have to put a mock layer into your application and actively maintain that layer, keeping up with the changes that occur in your data layer. When a test case fails, is it because your logic is wrong, or is it because the mock layer doesn't accurately reflect the database layer?
You won't catch any problems with the data layer. Say you introduce some ass-backwards logic that accidentally saves a duplicate into a primary key column. You won't see this if you use a mock data access layer. Say you know a select should return x number of values. How can you test this without actually going agaist a database? Etc.
In the case of PMD, what appears to be a framework/tool, Unit Tests are probably a dream. With database-based J2EE apps, less so.
At the same time, I like the idea enough to make another dash at it. We'll see how it goes.
If you do XP all the way through, the pair programming, short iterations, and especially the unit tests will minimize the "late stage bug fixing". You did have unit tests, right?
Unit testing, at least on most of my projects, just isn't possible. The reason: The database. I work for a financial firm writing internal j2ee apps that hit enormous databases (yeah, even the development databases) with diverse users. There is just no way that, on a short iteration cycle, I can assume that the state of the database can be reset to some baseline in any sort of timely manner.
I'd love to be able to host the database on my own computer and engage in rapid prototyping as some XP'ers suggestion, but there's just no way. Maybe on smaller projects, or on framework projects, or on shrink wrapped products. But not in my line of work.
Not that I don't love the idea of Unit Testing. I do. I just haven't seen it provide much more than trivial benefit to any of the projects I've worked on.
Then again, maybe I'm an idiot. (Actually, on second thought, I *am* an idiot.)
The disagreement (if it is even that) hinges on the definition of society. Whereas you say "Land rights benefit individuals. Individuals make up society. Therefore land rights benefit society.", I say "Land rights benefit individuals. Land rights can be used in such a way that the sum benefit to the individual exerciser of them will benefit *less* than the sum detriment to society. Therefore land rights may not benefit society."
I have little problem with land rights not benefiting society as a whole, and even less of a problem with the core legal concepts of the Declaration of Independence benefiting society. It is the individual to whom these are given by, in my case, God. That isn't to say that a society founded on those principals wouldn't be a good society, it is just to say that the fact that it is a good society is a secondary benefit to the individuals freedoms, which are the prime justification for the laws.
Also, regarding "Law should benefit everyone equally": I don't believe this. I believe that law should apply *justice* equally, but, really, I could give a rats about benefits.
At the core, it looks like we are having a classic utilitarian vs. idealist (in the classical sense) debate. I'll tip my hat to a thoughtful utilitarian.
I guess I was being a bit pedantic, just pointing out that not *all* laws are for the benefit of society. Land rights, for example, are often used in a way that is detrimental to society but beneficial to the individual.
As far as patent law goes, I think we (and pretty much the rest of the/. readership) are in agreement: Patents and copyrights are *not* inherent, inalienable rights granted to us by [Insert Metaphysical Crutch Here]. They are granted by a society for the benefit of society so that inventors/creators will have a greater impetus to invent/create. When such laws start actively inhibiting invention/creation, as they currently are, it is time to revisit them.
Actually, like all laws in a democracy, patents are supposed to be solely for the benefit of society. Laws are only made to benefit individuals and corporations as far as the end result of those laws is a benefit for society (or, rather, the voters).
We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness
Hmmm. May be wrong, but our homies in the Founding generation seem awfully focused on the individual. Not to say that I think current IP laws are a good idea, but I think it is a dangerous (and European) idea that laws are created solely for the benefit of an abstract society, rather than, at least occasionally, to guard the freedoms of the individual against the ever-advancing claims of "society".
In what context? NTLM authentication over the web (between IE and a java based app server) is available at http://jcifs.samba.org. This is a great solution for "single signon" for intranet applications.
Of course, it goes without saying, that this protocol is not internet safe
The JCIFS team even includes a delightful filter than you can plug in so request.getRemoteUser() will return DOMAIN_NAME\user_name. Realy good stuff for intranet development.
Now, if only 'zilla will get NTLM support in 1.3...
Do Slashdot readers think that the theories used to teach (and learn) programming lead to programmers that tend to approach problems with a 'black box', or 'virtual machine' mentality without considering the entire system?
Well, programming is, at its root, about controlling complexity. A good program (not that *I've* written one) will have sub-components within it that largely act as black boxes to one another. It is a great and rare skill to recognize where the boundries are in your program and establish them early, to avoid painful refactoring later.
In my experience, it is when something *isn't* a black box that things can get seriously fsked. "What? I set a global variable and now the app seg faults when I click that drop down?" Ahhh, not "black boxy" enough.
My perspective is from a higher level than embedded though. Embedded is a whole different game, although the "controlling complexity" insight of higher level programming languages no doubt sill applies (as far as it can go)
"The rules of this business are changing fast," Mr. Andreessen says, vehemently poking at his tuna salad. "When we come out of this downturn, high tech is going to look entirely different."
*gag* Off Topic, but has *anyone* become as much of a caricture of themselves as Andreessen?
This business is changing fast? Look entirely different? Thanks for the tip Marc.
Slashdot Mirror
"It's kind of nice to have something of a "star to navigate by" in the person of RMS"
Yup. Just always keep the star to your left...
Cheers,
prat
Seems to me like OQO is killing itself just fine without any help.
I've wanted one for a year and a half, but the ever-receding launch date has gotten out of hand. I know they were accepting pre-orders at some point. Wonder if those people will ever see an OQO or thier money...
In concept, of course, the idea just rocks.
Cheers,
prat
_looks up from work on tomcat_
_thinks to self: People still care about EJBs? Who knew?_
_goes back to work on tomcat_
(I exaggerate, for comic effect, of course)
Cheers,
prat
From the article:
[quote]A study last year by Meta Group Inc. in Stamford, Conn., found that 55% of IT workers with mainframe experience are over 50 years old.[/quote]
All your mainframe operators are belong to retirement home. They are on the way to senility. You have no chance to update cobol make your time.
*ITS A JOKE. I PLAN ON WORKING TILL IM 80*
Seriously though, I hope mainframe skills make a comeback, properly infused with the spirit of freedom that UNIX and minicomputers have given us. It's no fair that the old timers get to play with all the kick ass hardware. Just imagine a beowulf... Oh fsck it...
Cheers,
prat
When I see the prefix "meta" I reach for my gun...
Cheers,
prat
And next you'll be telling me that Linux is a challenge to Solaris and Windows...
Er, wait a sec...
Cheers,
prat
Oh, because, it goes without *saying* that no rational person could oppose stem cell research.
/.
Look, if you believe in a soul, stem cell research is, at *least*, problematic. If you don't believe in a soul, ask yourself why murder is wrong.
Materialist scientistic arrogance is such an ugly and prevalent thing here on
To hell with my karma,
prat
With so many clients deploying on Windows, who needs to waste time putting in a back door?
Its built right into the OS.
Cheers,
prat
"It may be me, but I would rather have a cheaper, lighter notebook with a long (8 hours or there abouts) batterylife than a HDTV+DVD-player combo with a computer attaced. But hey, each to his or her own."
Ditto
check out http://www.dynamism.com. Japanese laptops with a US warranty.
The sharp MM1 looks sweet, and it doubles as a USB2 hard drive.
Cheers,
prat
wouldn't that be
(setf (get-former-interns xerox)
(append (get-former-interns xerox) you)?
(wink me)
(cheers)
prat
[quote] ... ...y because people haven't had to manage teams of developers who aren't populated throughout with brilliant coders, capable of writing fast, functional readable code in languages that leave n degrees of freedom. ...
And the List thing is tired. We all know that Java is limited. It's limited compared to C++, it's limited compared to Lisp. Ya know what? That's a good thing. For
Of course, when I'm working on my own time on my own projects, I far prefer to use a manly language like C++, or a pleasant language like Python.
[/quote]
For what its worth, on these points, I totally agree with you.
Cheers,
prat
Aspect oriented programming is moderately useful, though, if it isn't built into the language (and, in java, it isn't) it can be cumbersome to work with.
In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.
By and large, the more I work in java, and the more I work in Lisp, I realize how lacking java is in dynamic behaviors. The lisp guys yawned when OO became all the rage because, well, it is so easy to do in lisp. If AOP gets big in java, they will yawn at that too:
"Oh, so functions and try blocks are your boundry block for inserting aspect oriented code? Well, *every parenthisis* is ours. Put that in your JVM and smoke it."
Cheers,
prat
*laugh*
Billy-boy, we's talkin' right past one anotha patna.
Hows about this: We agree that OODB's (and O/R systems) are tools with tradeoffs. They may be appropriate for some projects.
Of to write more nasty JDBC and bitch and moan about it...
Cheers,
prat
All of those things, ALL of them, are designed to make SQL be able to imitate the operations which are naturally atomic in an object programming model. SQL created the solution, yes; but it also created the problem.
Ditto for transactions.
Really? Sub-selects are atomic at the object model level? Come again?
So some new Object database tarted up with fancy-schmancy new terminology suddenly makes transactions easy? Multiple updates to an object graph from multiple threads in a transactional manner become, somehow, easier? _rolls eyes_ Riiiiiiiight...
Instead, you have programmers who can do all that work. It's what they're paid for.
Great! As a programmer who _can_ do all that work, I'll be happily employed forever! Oh wait, daily hot backups kinda suck to be around for. And chucking stored procs for intensive operations kinda sucks. Oh well, at least I'll be able to bill at twice what a competent dba can.
The first part is true. The second part is laughable.
*smiles* Less laughable than the notion that a wet-behind-the-ears-yet-another-stab-at-an-object- database scales well.
A good part of the purpose of this solution is to make those possible. The article discusses them in depth.
In reading the article I didn't see any arguments/methods that all the good-ol' object database guys haven't offered as the Holy Grail as well. I agree O/R impedence sucks. But code like this:
User u = (User) ((UserManager) prevayler.system()).getUsers().get(login);
Well, you'll forgive me if I'm not impressed. Get all users? And what about in big ol' databases, when not everything can live in memory?
Look, I hate, hate, HATE jdbc as much as the next guy. But the object database guys have been around for years now and they aren't winning much in mainstream business, and, when I've worked with them, there have been serious tradeoffs in scalability, query expressiveness and data store management. Enough so that, though it might guarantee my employment to do so, I don't recommend them to my boss.
Depending on your circumstances, you may find that the tradeoffs are worth it, but, in my experience, the people who would recommend this are either: vendors themselves, consultants who want to remain employed at high rates forever or bored programmers.
YMMV, of course,
prat
This page is 230.09 KB (235617 bytes)!!!
/.er reads an article is inversely related to the size of the article, I have computed that exactly: .00000000000000000003243523426092345%
Given that the probability that any
of the readership has actually read this one.
Cheers,
prat
This is not a new idea. There are all sorts of object databases out there. (Versant springs to mind).
The main problems I see with object databases:
1) SQL is incredibly powerful. You give up *a lot* of power when you go from sql semantics to object semantics. Sub-selects, group bys and optimized stored procedures, to name just a few things. All the object language query constructs I've seen fall far short of these. (As a side note, most O/R tools make a hash of it as well.)
2) You immedately make a massive reduction in the number of database administrators who will be willing and/or capable of helping you out in your project.
3) Scaling is always a question. With oracle, it just isn't.
4) Backup, redundancy, monitoring, management, etc. Most mature relational databases have very good tools for doing these infrastructure activities. Developers often forget about banal things like this, but they are crucial for the long term health of IT systems.
Don't get me wrong. Every time I construct some nasty query and go through the mind-numbing process of moving the results into an object, I think to myself "There has to be a better way!", but I've looked at the O/R tools and the object database out there and, sadly, I don't feel they are worth the trade off.
Just my opinion,
prat
Is the cost of edgimicatin' users.
Every time I try to edgimicate my wife, she tells me to go to hell and reinstall XP on the damn 'puter.
Cheers,
prat
In the case of PMD, what appears to be a framework/tool, Unit Tests are probably a dream. With database-based J2EE apps, less so.
At the same time, I like the idea enough to make another dash at it. We'll see how it goes.
Cheers,prat
Unit testing, at least on most of my projects, just isn't possible. The reason: The database. I work for a financial firm writing internal j2ee apps that hit enormous databases (yeah, even the development databases) with diverse users. There is just no way that, on a short iteration cycle, I can assume that the state of the database can be reset to some baseline in any sort of timely manner.
I'd love to be able to host the database on my own computer and engage in rapid prototyping as some XP'ers suggestion, but there's just no way. Maybe on smaller projects, or on framework projects, or on shrink wrapped products. But not in my line of work.
Not that I don't love the idea of Unit Testing. I do. I just haven't seen it provide much more than trivial benefit to any of the projects I've worked on.
Then again, maybe I'm an idiot. (Actually, on second thought, I *am* an idiot.)
Cheers,prat
The disagreement (if it is even that) hinges on the definition of society. Whereas you say "Land rights benefit individuals. Individuals make up society. Therefore land rights benefit society.", I say "Land rights benefit individuals. Land rights can be used in such a way that the sum benefit to the individual exerciser of them will benefit *less* than the sum detriment to society. Therefore land rights may not benefit society."
I have little problem with land rights not benefiting society as a whole, and even less of a problem with the core legal concepts of the Declaration of Independence benefiting society. It is the individual to whom these are given by, in my case, God. That isn't to say that a society founded on those principals wouldn't be a good society, it is just to say that the fact that it is a good society is a secondary benefit to the individuals freedoms, which are the prime justification for the laws.
Also, regarding "Law should benefit everyone equally": I don't believe this. I believe that law should apply *justice* equally, but, really, I could give a rats about benefits.
At the core, it looks like we are having a classic utilitarian vs. idealist (in the classical sense) debate. I'll tip my hat to a thoughtful utilitarian.
Cheers,
prat
Agreed on point 1.
/. readership) are in agreement: Patents and copyrights are *not* inherent, inalienable rights granted to us by [Insert Metaphysical Crutch Here]. They are granted by a society for the benefit of society so that inventors/creators will have a greater impetus to invent/create. When such laws start actively inhibiting invention/creation, as they currently are, it is time to revisit them.
Clarified on point 2.
Agreed on point 3.
I guess I was being a bit pedantic, just pointing out that not *all* laws are for the benefit of society. Land rights, for example, are often used in a way that is detrimental to society but beneficial to the individual.
As far as patent law goes, I think we (and pretty much the rest of the
Cheers,
prat
We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness
Hmmm. May be wrong, but our homies in the Founding generation seem awfully focused on the individual. Not to say that I think current IP laws are a good idea, but I think it is a dangerous (and European) idea that laws are created solely for the benefit of an abstract society, rather than, at least occasionally, to guard the freedoms of the individual against the ever-advancing claims of "society".
In what context? NTLM authentication over the web (between IE and a java based app server) is available at http://jcifs.samba.org. This is a great solution for "single signon" for intranet applications.
Of course, it goes without saying, that this protocol is not internet safe
The JCIFS team even includes a delightful filter than you can plug in so request.getRemoteUser() will return DOMAIN_NAME\user_name. Realy good stuff for intranet development.
Now, if only 'zilla will get NTLM support in 1.3...
Cheers,prat
Well, programming is, at its root, about controlling complexity. A good program (not that *I've* written one) will have sub-components within it that largely act as black boxes to one another. It is a great and rare skill to recognize where the boundries are in your program and establish them early, to avoid painful refactoring later.
In my experience, it is when something *isn't* a black box that things can get seriously fsked. "What? I set a global variable and now the app seg faults when I click that drop down?" Ahhh, not "black boxy" enough.
My perspective is from a higher level than embedded though. Embedded is a whole different game, although the "controlling complexity" insight of higher level programming languages no doubt sill applies (as far as it can go)
Cheers, prat*gag* Off Topic, but has *anyone* become as much of a caricture of themselves as Andreessen?
This business is changing fast? Look entirely different? Thanks for the tip Marc.
Cheers,
prat