Slashdot Mirror
A First Look At Red Hat Developer Studio
juanignaciosl writes "The first beta of Red Hat Developer Studio was published yesterday. RHDS seems promising. This IDE is a bunch of Eclipse plugins that comes from the fusion of JBoss IDE and Exadel Studio. The main advantages it offers are: JSF development improved, in particular integrating RichFaces and Ajax4JSF libraries; Seam (next J2EE middleware standard?) integration; and plugins for JBoss, Hibernate... Here are my first impressions."
those who don't and think they do, post on slashdot.
2 1337 4 u!
That's not the submitter's problem. You need to bone up on some acronyms, or you'll never make a goodJavaProgrammer. Here's a quick lesson in what you should do:
Write a thousand different programs using acronyms that start with J that do nothing except fuck up the data as it's being transmitted between the database and your application. Then, you have to write automated tools that also are acronyms that start with J and contain the word "Bean" in there somewhere, and those exist to generate parts of those previously mentioned thousand programs.
Then, write some Swing components that have nothing to do with all of this, and call those by almost exactly the same names, so that people get confused and can't do a proper Google search for documentation. Name an IDE after the Swing components, too.
Finally, call it all "middleware," give it yet ANOTHER name and bundle it all together, making sure that everything breaks if you don't include fifty different XML configuration files in the proper directory hierarchy that changes with each version.
Then when all of this doesn't work for more than one project because it's hopelessly complex, do it all over again and call it the next greatest revolution in Java middleware.
If moderation could change anything, it would be illegal.
Trolltech's suite so far has been the best one I've seen yet but has licensing issues. I've tried KDevelop and it's not that bad, but still not great. The ones I've seen for gnome have been even harder.
A good IDE for developing GUI applications, should help the developer a bit more with the GUI stuff and not make it mandatory that you know every call to every function of every widget for whatever library that package supports. If you knew that, might as well stick with Emacs/vi/nano and code it. Which it seems is how most development is done. (which isn't bad) but makes it harder for someone else starting out and wanting to give it a try.
Whole new bunch of acronyms are coming down the pipe. I don't think all are web, and may not be associated with a particular OS or file format. Microsoft just trade marked, patented and are looking for fast track ISO approval of the following:
This according to an attorney in their IP department, M. Poppins.
The sound of it is quite atrocious.
Does anyone have insight on these?
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
Actually, I was being a bit facetious.
People actually DO get J2EE apps to work. Here is a very informative instructional video by some Japanese researchers who show how it's done:
J2EE Example
If moderation could change anything, it would be illegal.
> Seriously, do these flavor of the month java libraries mean anything to anyone?
Yes, they make them specifically for no-talent hacks on slashdot can sneer at them and say how they could write a distributed transaction backend with reliable multicast messaging using PHP and MySQL in a week.
Hey everyone.. I work on the JBossTools and RHDS Team and just wanted to give some community-level info about our project.
p _id=22866&package_id=242269&release_id=531957
Red Hat Developer Studio is our commercial offering of the JBossTools open source project (formerly known as JBossIDE), which has a vibrant community of users and contributors. You can check out our project(s) at the following URLs:
JBossTools main page: http://jboss.org/tools
JBossTools blog: http://jbosstools.blogspot.com/
JBossTools 2.0.0.beta3: http://sourceforge.net/project/showfiles.php?grou
RHDS 1.0.0.beta1 (based on JBossTools 2.0.0.beta3): http://www.redhat.com/developers/rhds/index.html
Feel free to drop by #jbosstools on freenode, we'd love to hear from you!
arcane for life
Me too. I think that's what happens when you try to make a all-in-one solution without realizing there's a tradeoff between power and flexibility. You either make something that's too specific to be useful so that users have to constantly fight against design decisions you made, or something that requires almost as much work to make it do what you want than writing it from scratch would.
The ridiculously complex configuration files are a symptom of moving as many design decisions as possible out to the last possible moment. Complexity isn't reduced, it's just in a different place.
Which, ironically, makes the whole thing that much more complex, since now you have multiple places things can go wrong.
I tried using this stuff years ago, and found it wasn't close to worth the hassle, especially for a single developer. I just did a search for "J2EE success story," and the vast majority of hits were about a small team of Python programmers replacing large J2EE teams that failed to produce a working product.
But maybe I'm wrong, and the people who know much more than I do about this can list a hundred different projects where J2EE saved the company. It just seems like it's overhyped and people are really much more concerned about the scaffolding they're using than the work that they're supposed to be doing with it.
If moderation could change anything, it would be illegal.
I'm not convinced that this is entirely Java/J2EE's fault as much as it is that big corporations love Java and hate Python (and Perl) and have "big-corporatized" Java. Java was actually pretty cool when it first came out... if big industry embraced Python today, by tomorrow you'd see an explosion of PBPEL, P2EE, PDBC, PFaces, PSF and PMS applications and by the next day you'd be assigned to a committee to evaluate the product vendors to find the scalable enterprise solution that was the best fit for your business integration challenges. After a month of vendor selections, you'd narrow the candidates down to the top two contenders, and they'd pitch their expertise in the field, and then your company would sign a multi-million dollar contract with one of them. Then you'd start the process of trying to figure out how to get around the inherent limitations of the "solution" and do plain-old Python programming inside the "container" without it being too obvious to the higher-ups that that's what you're doing...
Proud neuron in the Slashdot hivemind since 2002.