How about just buying the %$#@! DVD, taking it home, and copying it there? For a small $15-20 investment, you can avoid all of this nonsense and can aim the video camera at your *own* TV until your nuts fall off in copy-thefting glee. Or just burn a copy of the DVD and leave it at that. After all, if you're going to violate copyright laws, why not go for quality?
What boggles my mind is who in the world is even doing this? Movie theaters I understand. But retail stores? That just doesn't make any sense. But then, again, not much with the **AA has lately.
I wonder how much time, effort and money is wasted on legislation such as this. We're it not for the fact that I am quickly slipping into a lunch-induced food coma, I'd look up the state appropriations and voting records of the Ohio state representatives and see for myself.
What a model of government Ohio has become. I only wish that my state would solve all of its problems such as unemployment, rampant property taxes, failing school systems, pollution, congestion, crumbling infrastructure, etc, etc, so that it could focus its energies on such pablum as **AA flights of corrupt and perverted fantasy.
Some places where I have consulted have been stacking developers 2 or 3 to a cube for years. Too many times, I've seen 6 to 10 developers crammed into a small, converted conference room. All in the name of saving money and "increasing" productivity. All it succeeds in doing is lowering moral and slowing production.
Sam *did* look into the mirror. He makes mention of it in the Scouring. I just re-read the trilogy and, as luck would have it, finished it today, so it's still fresh in my mind.
Re:Languages need novices, novices need good books
on
Bitter EJB
·
· Score: 2, Interesting
Hmmm....perhaps, then, Java is not a language for beginners. Not all tools should be for the novice. While I have known many beginners who have done just fine with Java, if it presents a problem for you, find another language. Visual Basic perhaps.
Of course, one could also argue that folks would be a lot better off starting with Assembler, moving to C, and then to Java. Especially with Assembler, at least *then* they would have an understanding of what actually goes into an I/O instruction as trivial as "print". It's wonderful that your language of choice makes it so easy to do something such as "input a$", but when it doesn't work, do you even know why?
For those who are so inclined, Java allows you to get down and examine the compiled code instruction by instruction. Can your language? I'm not trying to suggest that Java is necessarily better, I'm just tired of amateurs like yourself insisting that it's a bad language. It's not. You don't like the fact that you are forced to adhere to the OO paradigm? Use a different language. You don't like the fact that Java compartmentalizes functionality into packages and gives you access to a deeper level of ability and interaction with the operating system? Use a different language. You don't like the fact that low-level system calls are sacrificed at the expense of portability, a feature that many of us *do* need? Use a different language.
I have no desire to start a flame war, here. But it is crucial to accept the fact that different languages exist for different purposes. Languages like VB are great for quickly getting a GUI-based app up and running. Perl and Python are fantasic for kicking out small CGI-based apps. But for building large-scale, scalable, distributed applications, I'll take Java and, where appropriate, EJB every time.
I've noticed that you have made several posts in this thread denoucing both EJB and Java as a whole. I have to wonder why you are so persistent in this battle when you are clearly not a Java developer. The book, Bitter EJB, is clearly for EJB/Java developers. The review was written for the book. This thread exists for the review. Thus, the thread is for EJB/Java developers. Why do you continue to participate in a discussion that you have freely admitted aren't in support of?
As for the language itself, it has become apparent to me, from reading back over your posts, that you either are not a professional programmer, or that you did not spend an adequate amount of time evaluating Java. Again, not every language is right for every person, just as not every tool is right for every job. Still, I'm at a loss as to why you are being so persistent in displaying your ignorance about Java, EJB, and distributed architecture in general.
Care to comment?
Re:EJB is REALLY Bitter
on
Bitter EJB
·
· Score: 1
Hi Bruce! =)
I think that both of the Bitter Books are excellent resources and I would highly recommend them to anyone serious about Java development. Many of the lessons in both books transcend Java and are applicable to other languages as well.
A silly argument, really. The Perl/Python/Ruby compilers wrap the same logic around your print statement that Java requires you to enter on your own. While at first, this might seem like a great advantage, it limits the ways in which the code can be used.
Placing the hello world code in a main statement specifies a distinct context in which that code is to be used. It could just as easily be as simple as:
System.out.println("hello world");
Now, before you start clacking away at your keyboard, saying that all you have to use is the print keyword in [insert language here], you can do this with Java, too.
public void print(String s) {
System.out.println(s); }
Then, invoke it as such:
print(s);
Easy! This is, of course, a very trivial example and should not be taken as a serious measure of any language's capability. The mere fact that someone has already created this method for you in your language of choice does not make that language superior.
If it did, then BASIC was the greatest language ever devised.
Deployment Descriptor Portability
on
Bitter EJB
·
· Score: 1
Yes, Java is "write once, run anywhere." The deployment descriptors are often portable provided that you do not use any of the server-specific extensions. Of course, this limits the value of investing in such servers as WebSphere and WebLogic whose value-add are those extensions. Keep in mind, however, that it is Java code that is promised to be portable, not configuration files.
In EJB 1.0, there was no portability to speak of, as the descriptors were compiled classes. EJB 1.1 introduced a standardized XML format which has helped.
The bottom line, of course, is that true portability of hand-coded deployment descriptors does not exist. Nonetheless, for anything but the most trivial of projects (such as those found in books), you really should be using a build tool for the deployment descriptors. There are many out there, some of them even free. XDoclet (http://sourceforge.net/projects/xdoclet/) is one such tool.
The end rule is: portability, like any other aspect of development, must be planned.
Re:EJB is REALLY Bitter
on
Bitter EJB
·
· Score: 2, Informative
Well, here I go, throwing away my mod points to respond to this flamebait....
First, let me see if I understand your criticism correctly. Distributed architecture is a very complex and advanced form of software architecture. There is not merely one simple solution for all requirements, but an entire host of options to ensure that the right system is built to solve the problem at hand. This might include distributed components (EJB), but might also include CGI-based services (Java Servlets), asynchronous message-based services (Java Messaging Service), socket-based services (sockets, RMI), and much more. J2EE (Java 2 Enterprise Edition) addresses all of these (with RMI covered by the core Java API), of which EJB is one small part.
Your complaint seems to be that EJB is difficult and provides too many options. You seem to feel that.NET or DCOM is a better solution with its "one size fits all" solution. Of course, you don't actually state which is better, merely, you are blindly proselytizing another vendor's product line.
Regardless, your statement that EJB provides you with 1000's of choices is patently false. In actually, you have a small handful of options from which to choose. In fact, if you take a look at the.NET platform, those choices are rather similar.
For those who aren't familiar with EJB, you basically have a choice between objects that maintain stateful data on the current user session and those that don't (stateful and stateless beans). Of these, you also have a choice of whether a componet represents business logic (session beans) or data (entity beans). Finally, of the data components, you can have the EJB engine (called a "container") manage persistence for you or you can do it yourself ("container-managed persistance" and "bean-managed persistance"). Lastly, introduced in EJB 2.0, you can have components that respond to asynchronous messages. By my count, that is 6 options. Go nuts, throw in "local interfaces", and you have 7 options.
That's a far cry from 1000's.
It sounds to me like you merely glanced over the API's which are provided for two primary purposes. One, for those who wish to develop components for use within the EJB framework, there is a small set of interfaces and objects. Two, for those who wish to develop their own EJB container (e.g. JBoss, Websphere, WebLogic), the remainder of the API's interfaces are provided.
I have developed countless EJB-based systems so I have the experience upon which to draw when I say that EJB is not complex. Neither is.NET. Hell, CORBA isn't all that difficult when you get down to it.
Distributed architecture is complex. Please do not confuse the design with the implementation.
Oh, and lest you question my qualifications, I have co-authored two books on EJB and Distributed Architectures, as well as having given many lectures on both at various conferences.
The Messenger Service allows one machine to send text messages to another, typically through the NET SEND command, although I think that it can be done through the Windows API as well. This is commonly used by Admins to notify users of important system events (e.g. server reboot). As a developer, I have used it to send messages to clueless users who clog up the printer queues with stalled print jobs that are hours old and long since forgotten.
As a side note, I used the messenger service to write an Instant Messenger (IM) client that ran under NT 3.5 back in 1996.
Perhaps they should instead try to make movies that are good enough that people will want to see them in the theaters...
That was always my complaint about Honda and Toyota. Perhaps they should instead try to make cars that are good enough that people will want to buy them, rather than steal them.
Justify it anyway that you want. Stealing is still stealing.
I have read the article. I also know the legal system. They would sue both the school and the student, as well as other possible parties involved, as has happened in the past with similar situations.
>But the way our legal system works, they can go on claiming both for a while until it looks like...
...they will be driving the student into bankruptcy from legal fees due to nonsense claims such as this, thereby serving as a warning to anyone else who might consider pointing out that the Emporer does not have any clothes.
It might interest you to know that many subsidized housing complexes include broadband service as part of an educational initiative. Not far from where I live, one such housing project even has a lab with 30 workstations (donated from various companies) so that the kids have a place to work on their homework.
I have to make a small complaint here. I don't seem to be able to get the sitefinder page when I enter in an unregistered domain name. Not the links above nor just random garbage. I merely get a "Could Not Connect to Remote Server" message.
No sooned did I make my post than I read the next article on/.: announcing the latest efforts of the RIAA to ensure that no high school kid will ever be able to attend college by suing them for $50,000. On second thought, *F* buying CDs. I don't need to fund this kind of harrassment and nonsense.
I, for one, am very happy to see Universal taking this course of action. I have bought maybe 4 or 5 CDs in the past year, due to two reasons. One, there hasn't been much released in the past year that I have been all that interested in and two, the list price of nearly $20 kills any chance of an impulse buy. I haven't been getting my music from P2P, I've simply been going without. With over 1,000 CDs in my collection, I have not wanted for a lack of music.
Hopefully, as has been stated elsewhere here, this will start a trend to bring music prices back down to a more realistic level.
Your comment was very informative; while I was aware that the power plant was off-line, I did know the reasons. However, the fact still remains that too many companies integrate their critical systems with their common networks. It is not FUD (what was it that I was trying to create FUD over, anyway) but an observation based on my professional experiences. Not with this power company, mind you, but with a host of corporations that I have worked with in the past. Other examples cited by the media also indicate that this is a prevalent problem.
It's a shame that you did not stand behind your comment convincingly, however. Perhaps, next time, you won't be an AC when you flame people and, instead, will "think about the children."
Reading through the article, I'm concerned by the severity of some of the failure examples cited. In particular, that relating to the disabling of a nuclear power plant's monitoring system. Maybe I should wait until after I have had my coffee but, at risk of embarrassing myself, I have to ask. Why in the world is an energy company's critical system attached to its common network? Why would they configure their network topology in such a way that would permit an email-borne virus to infiltrate such a critical system? What are they achieving via NetBEUI that cannot otherwise be accomplished via SSL-based socket communications? (I'm assuming the NetBEUI part but, other than file-sharing, I can't imagine any other purpose.)
Slashdot Mirror
How about just buying the %$#@! DVD, taking it home, and copying it there? For a small $15-20 investment, you can avoid all of this nonsense and can aim the video camera at your *own* TV until your nuts fall off in copy-thefting glee. Or just burn a copy of the DVD and leave it at that. After all, if you're going to violate copyright laws, why not go for quality?
What boggles my mind is who in the world is even doing this? Movie theaters I understand. But retail stores? That just doesn't make any sense.
But then, again, not much with the **AA has lately.
I wonder how much time, effort and money is wasted on legislation such as this. We're it not for the fact that I am quickly slipping into a lunch-induced food coma, I'd look up the state appropriations and voting records of the Ohio state representatives and see for myself.
What a model of government Ohio has become. I only wish that my state would solve all of its problems such as unemployment, rampant property taxes, failing school systems, pollution, congestion, crumbling infrastructure, etc, etc, so that it could focus its energies on such pablum as **AA flights of corrupt and perverted fantasy.
Some places where I have consulted have been stacking developers 2 or 3 to a cube for years. Too many times, I've seen 6 to 10 developers crammed into a small, converted conference room. All in the name of saving money and "increasing" productivity. All it succeeds in doing is lowering moral and slowing production.
This isn't socialization. It's Veal-ization.
Sam *did* look into the mirror. He makes mention of it in the Scouring. I just re-read the trilogy and, as luck would have it, finished it today, so it's still fresh in my mind.
Hmmm....perhaps, then, Java is not a language for beginners. Not all tools should be for the novice. While I have known many beginners who have done just fine with Java, if it presents a problem for you, find another language. Visual Basic perhaps.
Of course, one could also argue that folks would be a lot better off starting with Assembler, moving to C, and then to Java. Especially with Assembler, at least *then* they would have an understanding of what actually goes into an I/O instruction as trivial as "print". It's wonderful that your language of choice makes it so easy to do something such as "input a$", but when it doesn't work, do you even know why?
For those who are so inclined, Java allows you to get down and examine the compiled code instruction by instruction. Can your language? I'm not trying to suggest that Java is necessarily better, I'm just tired of amateurs like yourself insisting that it's a bad language. It's not. You don't like the fact that you are forced to adhere to the OO paradigm? Use a different language. You don't like the fact that Java compartmentalizes functionality into packages and gives you access to a deeper level of ability and interaction with the operating system? Use a different language. You don't like the fact that low-level system calls are sacrificed at the expense of portability, a feature that many of us *do* need? Use a different language.
I have no desire to start a flame war, here. But it is crucial to accept the fact that different languages exist for different purposes. Languages like VB are great for quickly getting a GUI-based app up and running. Perl and Python are fantasic for kicking out small CGI-based apps. But for building large-scale, scalable, distributed applications, I'll take Java and, where appropriate, EJB every time.
I've noticed that you have made several posts in this thread denoucing both EJB and Java as a whole. I have to wonder why you are so persistent in this battle when you are clearly not a Java developer. The book, Bitter EJB, is clearly for EJB/Java developers. The review was written for the book. This thread exists for the review. Thus, the thread is for EJB/Java developers. Why do you continue to participate in a discussion that you have freely admitted aren't in support of?
As for the language itself, it has become apparent to me, from reading back over your posts, that you either are not a professional programmer, or that you did not spend an adequate amount of time evaluating Java. Again, not every language is right for every person, just as not every tool is right for every job. Still, I'm at a loss as to why you are being so persistent in displaying your ignorance about Java, EJB, and distributed architecture in general.
Care to comment?
Hi Bruce! =)
I think that both of the Bitter Books are excellent resources and I would highly recommend them to anyone serious about Java development. Many of the lessons in both books transcend Java and are applicable to other languages as well.
All in all, a fantasic effort.
A silly argument, really. The Perl/Python/Ruby compilers wrap the same logic around your print statement that Java requires you to enter on your own. While at first, this might seem like a great advantage, it limits the ways in which the code can be used.
Placing the hello world code in a main statement specifies a distinct context in which that code is to be used. It could just as easily be as simple as:
System.out.println("hello world");
Now, before you start clacking away at your keyboard, saying that all you have to use is the print keyword in [insert language here], you can do this with Java, too.
public void print(String s) {
System.out.println(s);
}
Then, invoke it as such:
print(s);
Easy! This is, of course, a very trivial example and should not be taken as a serious measure of any language's capability. The mere fact that someone has already created this method for you in your language of choice does not make that language superior.
If it did, then BASIC was the greatest language ever devised.
Yes, Java is "write once, run anywhere." The deployment descriptors are often portable provided that you do not use any of the server-specific extensions. Of course, this limits the value of investing in such servers as WebSphere and WebLogic whose value-add are those extensions. Keep in mind, however, that it is Java code that is promised to be portable, not configuration files.
In EJB 1.0, there was no portability to speak of, as the descriptors were compiled classes. EJB 1.1 introduced a standardized XML format which has helped.
The bottom line, of course, is that true portability of hand-coded deployment descriptors does not exist. Nonetheless, for anything but the most trivial of projects (such as those found in books), you really should be using a build tool for the deployment descriptors. There are many out there, some of them even free. XDoclet (http://sourceforge.net/projects/xdoclet/) is one such tool.
The end rule is: portability, like any other aspect of development, must be planned.
Well, here I go, throwing away my mod points to respond to this flamebait....
.NET or DCOM is a better solution with its "one size fits all" solution. Of course, you don't actually state which is better, merely, you are blindly proselytizing another vendor's product line.
.NET platform, those choices are rather similar.
.NET. Hell, CORBA isn't all that difficult when you get down to it.
First, let me see if I understand your criticism correctly. Distributed architecture is a very complex and advanced form of software architecture. There is not merely one simple solution for all requirements, but an entire host of options to ensure that the right system is built to solve the problem at hand. This might include distributed components (EJB), but might also include CGI-based services (Java Servlets), asynchronous message-based services (Java Messaging Service), socket-based services (sockets, RMI), and much more. J2EE (Java 2 Enterprise Edition) addresses all of these (with RMI covered by the core Java API), of which EJB is one small part.
Your complaint seems to be that EJB is difficult and provides too many options. You seem to feel that
Regardless, your statement that EJB provides you with 1000's of choices is patently false. In actually, you have a small handful of options from which to choose. In fact, if you take a look at the
For those who aren't familiar with EJB, you basically have a choice between objects that maintain stateful data on the current user session and those that don't (stateful and stateless beans). Of these, you also have a choice of whether a componet represents business logic (session beans) or data (entity beans). Finally, of the data components, you can have the EJB engine (called a "container") manage persistence for you or you can do it yourself ("container-managed persistance" and "bean-managed persistance"). Lastly, introduced in EJB 2.0, you can have components that respond to asynchronous messages. By my count, that is 6 options. Go nuts, throw in "local interfaces", and you have 7 options.
That's a far cry from 1000's.
It sounds to me like you merely glanced over the API's which are provided for two primary purposes. One, for those who wish to develop components for use within the EJB framework, there is a small set of interfaces and objects. Two, for those who wish to develop their own EJB container (e.g. JBoss, Websphere, WebLogic), the remainder of the API's interfaces are provided.
I have developed countless EJB-based systems so I have the experience upon which to draw when I say that EJB is not complex. Neither is
Distributed architecture is complex. Please do not confuse the design with the implementation.
Oh, and lest you question my qualifications, I have co-authored two books on EJB and Distributed Architectures, as well as having given many lectures on both at various conferences.
Oh, and I found Unix very easy to learn. =)
I own a VL-200. It has a rotary accessory that does glassware and other cylindrical objects.
The Messenger Service allows one machine to send text messages to another, typically through the NET SEND command, although I think that it can be done through the Windows API as well. This is commonly used by Admins to notify users of important system events (e.g. server reboot). As a developer, I have used it to send messages to clueless users who clog up the printer queues with stalled print jobs that are hours old and long since forgotten.
As a side note, I used the messenger service to write an Instant Messenger (IM) client that ran under NT 3.5 back in 1996.
Dead link.. Damn my eyes!
>>Where is Pankin's complaint generator?
Uhh, right here? =)
Perhaps they should instead try to make movies that are good enough that people will want to see them in the theaters...
That was always my complaint about Honda and Toyota. Perhaps they should instead try to make cars that are good enough that people will want to buy them, rather than steal them.
Justify it anyway that you want. Stealing is still stealing.
I have read the article. I also know the legal system. They would sue both the school and the student, as well as other possible parties involved, as has happened in the past with similar situations.
As for the cash, that's what investors are for.
>But the way our legal system works, they can go on claiming both for a while until it looks like...
...they will be driving the student into bankruptcy from legal fees due to nonsense claims such as this, thereby serving as a warning to anyone else who might consider pointing out that the Emporer does not have any clothes.
Is Canada hiring?
Just one more reason to do away with an antiquated filing system.
Gee, and here I thought that I had just done a really good job "stealthing" my firewall.... =)
It might interest you to know that many subsidized housing complexes include broadband service as part of an educational initiative. Not far from where I live, one such housing project even has a lab with 30 workstations (donated from various companies) so that the kids have a place to work on their homework.
I have to make a small complaint here. I don't seem to be able to get the sitefinder page when I enter in an unregistered domain name. Not the links above nor just random garbage. I merely get a "Could Not Connect to Remote Server" message.
*Sigh*. I never get to have any fun...
Like my savings account, it's been slashdotted.
>>the strongest word is still the word "free"
Off-topic, yeah, I know, but I'd rather acknolwedge your Negativland reference than just throw you an anonymous mod point!
No sooned did I make my post than I read the next article on /.: announcing the latest efforts of the RIAA to ensure that no high school kid will ever be able to attend college by suing them for $50,000. On second thought, *F* buying CDs. I don't need to fund this kind of harrassment and nonsense.
I, for one, am very happy to see Universal taking this course of action. I have bought maybe 4 or 5 CDs in the past year, due to two reasons. One, there hasn't been much released in the past year that I have been all that interested in and two, the list price of nearly $20 kills any chance of an impulse buy. I haven't been getting my music from P2P, I've simply been going without. With over 1,000 CDs in my collection, I have not wanted for a lack of music.
Hopefully, as has been stated elsewhere here, this will start a trend to bring music prices back down to a more realistic level.
Your comment was very informative; while I was aware that the power plant was off-line, I did know the reasons. However, the fact still remains that too many companies integrate their critical systems with their common networks. It is not FUD (what was it that I was trying to create FUD over, anyway) but an observation based on my professional experiences. Not with this power company, mind you, but with a host of corporations that I have worked with in the past. Other examples cited by the media also indicate that this is a prevalent problem.
It's a shame that you did not stand behind your comment convincingly, however. Perhaps, next time, you won't be an AC when you flame people and, instead, will "think about the children."
Reading through the article, I'm concerned by the severity of some of the failure examples cited. In particular, that relating to the disabling of a nuclear power plant's monitoring system. Maybe I should wait until after I have had my coffee but, at risk of embarrassing myself, I have to ask. Why in the world is an energy company's critical system attached to its common network? Why would they configure their network topology in such a way that would permit an email-borne virus to infiltrate such a critical system? What are they achieving via NetBEUI that cannot otherwise be accomplished via SSL-based socket communications? (I'm assuming the NetBEUI part but, other than file-sharing, I can't imagine any other purpose.)