Re:JDO vs EJB Entity Beans?
on
Java Data Objects
·
· Score: 3, Insightful
I think your rant against EJB probably has more to do with entity beans than EJB in general. You can actually use JDO as the persistence layer from session beans, and that's pretty much what my company does. We wrote our own JDO-like code which works pretty well. Perhaps I'll pick this book up to see if it's worth switching, or maybe just to get some ideas to enhance our JDO-like code.
Re:It depends - and not in investment banking
on
Eclipse 2.1 Released
·
· Score: 1
I hear that. I write more Perl programs than Python or Ruby just because of CPAN. For some reason, Perl just feels right when I begin a job, but then I realize I need to make hashes of arrays of hashes and I just want to slit my wrists. I'd kill for better complex datatype support in Perl.
Re:It depends - and not in investment banking
on
Eclipse 2.1 Released
·
· Score: 1
Finally, someone posts a moment of clarity. I've been coding in Java at work for four years, and have found it to be much more cumbersome and time consuming than the projects I do in Python, Ruby and Perl on the side. Java is just really mediocre in all categories, except for library support. However, Perl and Python are also very strong in that area.
I'm really hoping Paul Graham finishes Arc in the next century so that Lisp might have a chance to thrive again.
I actually managed to get my hands on a bit of beaver while at Caltech, though I've had my hands on quite a bit more since leaving. So much for your "never seeing the real thing" theory.
I fail to see how 96 kHz audio is useful even for home theater. The human ear cannot hear 48 kHz sounds...any sampling rate over 44 KHz (= 22 kHz maximum frequency) is useless overkill. The 24 bit samples make a lot more sense than the 96 kHz sampling rate to me.
Yeah, now that I've used it a bit more, I've found a couple of crashes and some bugs, but it's still useable. It's much better than Netscape 4.7, which I put up with for years.
Not to mention galeon 1.2 is broken in sid right now because of C++ library issues.
You can fetch and try Galeon 1.3.3. I'm using it now on Debian and haven't seen it crash yet (I haven't used it for long, though). The only thing I haven't figured out how to do yet is set the toolbar to icons only (no text).
Did anyone else find the full version somewhat lacking after playing the demo for weeks? It was just that after you had unlimited time, you actually needed to calm down and play nicely so that you'd stay alive.
With the demo, you had only a short amount of time, and you could _almost_ finish all four missions successfully in the time given, if you were really fast. Attempting to get all four in one insane speed-mayhem rush was the most fun I've had playing a video game, _ever_. The full version just didn't provide the same level of excitement.
Some of them are in a NOC (Inflow) and the others are in our office, on a UPS. It's not the power. We have been bitten by the 400 MHz 8 MB cache problem, but that's not the only problem we've hit. We've had motherboards replaced because the serial port failed, we've had 4 or 5 power supplies replaced, several CPU's, and on and on. It's maddening. Frankly, I don't want to find out if they've fixed it in their new line of products. We've started to realize the power of commodity hardware and we're leveraging it. For the price we'd have to pay to upgrade all of our equipment and run on it for 4 years, we could buy new top-of-the-line Intel equipment every year. Given Moore's law, that's a winning proposition.
I think the real confusion here is the assumption that the board and the nail must be orthogonal. It's unfortunately a very vague problem...if you were hammering into the end of the board, I'd say they're parallel. If you hammer into the center, orthogonal. The vector of the nail is pretty straightforward (effectively 1-dimensional), but there could be three different vectors assigned to the board.
OO languages aren't especially known for their brevity. If it had been written in a functional language, I might buy that something pretty amazing had been done in 350 lines, but still--350 lines is 350 lines. It's just not possible to solve a problem as complex as a database in 350 lines. You couldn't even begin to _state_ the problem in 350 lines.
EJB is the most over-hyped, overpriced, worthless technology I have come across in recent years. We started coding with entity beans and found them to be so ridiculously slow and had so many random, weird problems with them that we yanked them all out (non-trivial! We had something like 40 of them at the time) and used session beans only. Performance jumped a whole lot, and then we realized that we were basically just doing JDBC. The session bean really wasn't doing much for us, just connection pooling and relatively simple transaction management. The "benefits" of EJB are too marginal for words.
Too bad the Sun of yesteryear isn't the same today. The hardware they're making these days fails more than anything I have ever seen. Our 3 E420R's and E4500 have had so many parts on them replaced that it sickens me. Good thing we payed for that expensive support contract...
Do you think that this has never been thought of? This is how software development started. It was abandoned because it does not work. Much of the research in software engineering has simply tried to identify the things which make software engineering so much different from conventional types of engineering.
In the Mythical Man Month, Fred Brooks identifies the "essential difficulties" of software development as complexity, conformity, changeability, and invisibility. I'll explain each of these terms.
Complexity: Software does not benefit from repetition. Many other forms of engineering benefit from being able to repeat small elements or scale them into larger elements to scale the project. In software, reptition is eliminated as much as possible through functions and procedures. Scaling-up a software project necessarily involves increasing the number of distinct components. As the number of components increases, the number of possible states and interactions between those components increases non-linearly. It's also important to note that this complexity is the essence of the software. Creating a simplified model of the software is generally useless, unlike in physics.
Conformity: The complexity of a software system often stems from the need to conform to arbitrary constraints (the beloved "Requirements" document). Software needs to interface with external systems, software, formats, and rules, all of which are specified without rhyme or reason. This complexity cannot be removed through any design decision.
Changeability: Software is under constant pressure to change because it is easier to change than physical, manufactured products. People have an inherent understanding that they cannot ask for a complete redesign of a bridge. Their lack of understanding of software development does not keep them from asking for software changes which may require a complete redesign, however.
Invisibility: This one is a little hard to explain, but is closely related to complexity. Software systems are so complex that a useful, comprehensive graph or diagram of them cannot be created. UML diagrams are cute, but you need several different types of them to be able to see the whole picture, and any diagram for a reasonably large system with one type of view of all it's interactions would be ridiculously huge. Couple this with the fact that you need many such diagrams, some of which are not even planar (difficult or impossible to represent in 2 dimensions), and you start to see the problem. The human mind has very powerful visual processing; the engineer gains much by being able to visualize her system. While other types of engineers are able to visualize their systems, unfortunately, software developers cannot.
The right click is handy when selecting large volumes of text (multiple screenfuls). This is actually very useful, but *very* unintuitive. I used xterm and rxvt for about five years before I learned how to do this. Frankly, I'm with the GNOME team in leaving it out. It's just such awkward behavior and so inconsistent that it doesn't belong. However, I also happen to like it, and for that reason I use xterm instead of gnome-terminal. I don't see why this guy keeps bitching about gnome-terminal instead of just using something else. Just because it's the "standard" doesn't mean you have to use it, as long as you know there's an alternative! The people who don't know that alternatives exist will probably appreciate the consistency of gnome-terminal.
Gnome 1.4 is very nice. 2.0 still has a long way to go. I wish they wouldn't turn off so many Solaris users by giving them something half-baked. Then again, if they're willing to put up with CDE, they're probably willing to use _anything_.
While I agree that it would hurt nVIDIA to release the source, thereby helping ATI, it certainly wouldn't hurt customers. Imagine if *all* hardware companies had free, open access to top-notch driver, OpenGL, and GLX implementations. The quality of drivers for every card would improve. Hardware companies would be sharing ideas, so we'd get better hardware. This is definitely good for the consumer!
The only people hurt by this scenario are those who currently have an advantage in software. They would be forced to compete solely on their hardware brilliance. But aren't we talking about hardware companies, anyway?!
This is the whole point of free software. Free and open access to software improves the quality of software for all. Free software's greatest obstacle will always be the status quo: they're being treated quite well by the current system, and see no need for a change.
Always try to keep in mind that even if the current system is good (e.g. nVIDIA's linux drivers are high quality), it's not necessarily the best system. Linux would certainly be better off if nVIDIA "handed [ATI] the code on a platter." I don't see why you're against it, unless you're a stockholder in nVIDIA.
Do you really think you're the first person to come up with the idea that everything in software engineering would work if it just copied practices from other engineering disciplines? It's been tried. People have been trying to make it work since the beginning.
Well, it seems that you haven't been following the results, so I'll fill you in:
Traditional engineering practices fail miserably when applied to software engineering.
Everyone would like to understand why, and through this understanding, develop new practices which prove successful in the software arena.
XP isn't necessarily the solution, but at least it's honest. XP admits that it is "glorified hacking" (not directly). But it also asserts that glorified hacking is a better solution to the software problem than traditional engineering practices.
Nothing too magical there. Granted, it's kind of weird to figure out which name you should look up in JNDI at any given time, but all the necessary pools are made more or less automagically.
Jetty does serve HTTP, but it's mostly a servlet/JSP container, just like Tomcat. It actually uses Jasper, which is the JSP implementation from Tomcat. It has a very nice and fast servlet implementation, however.
JBoss 3.0 bundles Jetty by default, but builds with Tomcat bundled are also available. Prior to 3.0, JBoss was available without any servlet container, but packages with Tomcat and Jetty were available; the Tomcat builds were the most popular.
Slashdot Mirror
I think your rant against EJB probably has more to do with entity beans than EJB in general. You can actually use JDO as the persistence layer from session beans, and that's pretty much what my company does. We wrote our own JDO-like code which works pretty well. Perhaps I'll pick this book up to see if it's worth switching, or maybe just to get some ideas to enhance our JDO-like code.
I hear that. I write more Perl programs than Python or Ruby just because of CPAN. For some reason, Perl just feels right when I begin a job, but then I realize I need to make hashes of arrays of hashes and I just want to slit my wrists. I'd kill for better complex datatype support in Perl.
Finally, someone posts a moment of clarity. I've been coding in Java at work for four years, and have found it to be much more cumbersome and time consuming than the projects I do in Python, Ruby and Perl on the side. Java is just really mediocre in all categories, except for library support. However, Perl and Python are also very strong in that area.
I'm really hoping Paul Graham finishes Arc in the next century so that Lisp might have a chance to thrive again.
Who modded this offtopic? Apparently you haven't seen Orgazmo. Parent is right on target and damn funny! As long as you get the reference, that is.
I actually managed to get my hands on a bit of beaver while at Caltech, though I've had my hands on quite a bit more since leaving. So much for your "never seeing the real thing" theory.
Yes, and the highest frequency that can be accurately reconstructed from a signal sampled 40 kHz is 20 kHz.
I fail to see how 96 kHz audio is useful even for home theater. The human ear cannot hear 48 kHz sounds...any sampling rate over 44 KHz (= 22 kHz maximum frequency) is useless overkill. The 24 bit samples make a lot more sense than the 96 kHz sampling rate to me.
Yeah, now that I've used it a bit more, I've found a couple of crashes and some bugs, but it's still useable. It's much better than Netscape 4.7, which I put up with for years.
Not to mention galeon 1.2 is broken in sid right now because of C++ library issues.
You can fetch and try Galeon 1.3.3. I'm using it now on Debian and haven't seen it crash yet (I haven't used it for long, though). The only thing I haven't figured out how to do yet is set the toolbar to icons only (no text).
Other than that, it looks great!
Did anyone else find the full version somewhat lacking after playing the demo for weeks? It was just that after you had unlimited time, you actually needed to calm down and play nicely so that you'd stay alive.
With the demo, you had only a short amount of time, and you could _almost_ finish all four missions successfully in the time given, if you were really fast. Attempting to get all four in one insane speed-mayhem rush was the most fun I've had playing a video game, _ever_. The full version just didn't provide the same level of excitement.
Some of them are in a NOC (Inflow) and the others are in our office, on a UPS. It's not the power. We have been bitten by the 400 MHz 8 MB cache problem, but that's not the only problem we've hit. We've had motherboards replaced because the serial port failed, we've had 4 or 5 power supplies replaced, several CPU's, and on and on. It's maddening. Frankly, I don't want to find out if they've fixed it in their new line of products. We've started to realize the power of commodity hardware and we're leveraging it. For the price we'd have to pay to upgrade all of our equipment and run on it for 4 years, we could buy new top-of-the-line Intel equipment every year. Given Moore's law, that's a winning proposition.
I think the real confusion here is the assumption that the board and the nail must be orthogonal. It's unfortunately a very vague problem...if you were hammering into the end of the board, I'd say they're parallel. If you hammer into the center, orthogonal. The vector of the nail is pretty straightforward (effectively 1-dimensional), but there could be three different vectors assigned to the board.
Of course Sun's marketing material shows almost perfect scalability. Don't believe everything you read out a marketing department, though.
OO languages aren't especially known for their brevity. If it had been written in a functional language, I might buy that something pretty amazing had been done in 350 lines, but still--350 lines is 350 lines. It's just not possible to solve a problem as complex as a database in 350 lines. You couldn't even begin to _state_ the problem in 350 lines.
EJB is the most over-hyped, overpriced, worthless technology I have come across in recent years. We started coding with entity beans and found them to be so ridiculously slow and had so many random, weird problems with them that we yanked them all out (non-trivial! We had something like 40 of them at the time) and used session beans only. Performance jumped a whole lot, and then we realized that we were basically just doing JDBC. The session bean really wasn't doing much for us, just connection pooling and relatively simple transaction management. The "benefits" of EJB are too marginal for words.
Too bad the Sun of yesteryear isn't the same today. The hardware they're making these days fails more than anything I have ever seen. Our 3 E420R's and E4500 have had so many parts on them replaced that it sickens me. Good thing we payed for that expensive support contract...
In the Mythical Man Month, Fred Brooks identifies the "essential difficulties" of software development as complexity, conformity, changeability, and invisibility. I'll explain each of these terms.
The right click is handy when selecting large volumes of text (multiple screenfuls). This is actually very useful, but *very* unintuitive. I used xterm and rxvt for about five years before I learned how to do this. Frankly, I'm with the GNOME team in leaving it out. It's just such awkward behavior and so inconsistent that it doesn't belong. However, I also happen to like it, and for that reason I use xterm instead of gnome-terminal. I don't see why this guy keeps bitching about gnome-terminal instead of just using something else. Just because it's the "standard" doesn't mean you have to use it, as long as you know there's an alternative! The people who don't know that alternatives exist will probably appreciate the consistency of gnome-terminal.
Gnome 1.4 is very nice. 2.0 still has a long way to go. I wish they wouldn't turn off so many Solaris users by giving them something half-baked. Then again, if they're willing to put up with CDE, they're probably willing to use _anything_.
Reckon so, but Lloyd is the only tolerable north hovse, at least from a skurve's point of view.
The only people hurt by this scenario are those who currently have an advantage in software. They would be forced to compete solely on their hardware brilliance. But aren't we talking about hardware companies, anyway?!
This is the whole point of free software. Free and open access to software improves the quality of software for all. Free software's greatest obstacle will always be the status quo: they're being treated quite well by the current system, and see no need for a change.
Always try to keep in mind that even if the current system is good (e.g. nVIDIA's linux drivers are high quality), it's not necessarily the best system. Linux would certainly be better off if nVIDIA "handed [ATI] the code on a platter." I don't see why you're against it, unless you're a stockholder in nVIDIA.
Well, it seems that you haven't been following the results, so I'll fill you in:
Traditional engineering practices fail miserably when applied to software engineering.
Everyone would like to understand why, and through this understanding, develop new practices which prove successful in the software arena.
XP isn't necessarily the solution, but at least it's honest. XP admits that it is "glorified hacking" (not directly). But it also asserts that glorified hacking is a better solution to the software problem than traditional engineering practices.
Hear hear! We've been bitten by these bastards, too. I can't believe anyone would actually promote such a terrible system.
What's so hard about Orion's connection pooling? My data-sources.xml looks like this:
name="Oracle" />
<data-sources>
<data-source
class="com.evermind.sql.DriverManagerDataSource"
location="oildexBMTPool"
xa-location="jdbc/xa/OracleXADS"
ejb-location="oildexPool"
connection-driver="oracle.jdbc.OracleDriver"
username="phiggins"
password="phiggins"
url="jdbc:oracle:oci:@hubd1"
inactivity-timeout="30"
max-connections="50"
</data-sources>
Nothing too magical there. Granted, it's kind of weird to figure out which name you should look up in JNDI at any given time, but all the necessary pools are made more or less automagically.
Jetty does serve HTTP, but it's mostly a servlet/JSP container, just like Tomcat. It actually uses Jasper, which is the JSP implementation from Tomcat. It has a very nice and fast servlet implementation, however.
JBoss 3.0 bundles Jetty by default, but builds with Tomcat bundled are also available. Prior to 3.0, JBoss was available without any servlet container, but packages with Tomcat and Jetty were available; the Tomcat builds were the most popular.