OK, I'll answer that. Your biggest ever employer had sixteen distinct projects while you were working there. How many did they have the year before? How many little one off projects had been written over the course of the previous five years and were the people who wrote them even working for the company anymore.
See, SF and the idea of project trees like it isn't just for what is being worked on now, it's for all that legacy crap from people who are long gone. It's about not having to track down their hard drives to see if they still had a copy of some little file format translation tool and then seeing that they had three different ones and not knowing what the difference is between each of the three versions.
IBM's decision to roll their own UI for this rather than use Swing was a poor one. There is lots of experience out there with Swing development and it can work very very well (see the aforementioned NetBeans/Forte for an example of a complex UI implemented in Swing).
I think that it will cut down on the number of developers who want to work on the project (me for example) and will increase the learning curve for those who do. Not a recipe for success.
Re:Blech. Most of them are pretty bad.
on
Java IDEs?
·
· Score: 1
One thing that is crutial for NetBeans performance is sufficient memory. If you were to try it on a machine with only 128MB or (god forbid) 64MB of memory you would conclude that it runs like molasses. Make sure you have enough memory to run such a feature rich IDE before you do so.
P.S. For what it's worth, NetBeans/Forte is an excellent IDE if you like one with lots of bells and whistles. It's built in support for GUI editing, CVS, and Ant all seem wonderful to me. I was using it's Javadoc auto comment feature just yesterday to touch up some code.
If you like something bare and stripped so it will be blindingly fast then this is not for you. If you like an IDE with everything and the kitchen sink, then you really should give it a look.
It can take a lot of forms but I can give an example taken from my personal experience.
GameDev.net is run by a diverse group of people spread all over the U.S. A workflow system would allow us to take incoming emails for example or new news or article submissions and perform a sequence of tasks on them.
For example, all new email items could be directed to one individual who screens the email. The items that made it through the initial screening could go to whomever was designated as "email answerer" for that week. The resulting replies could be sent to another individual for approval and then the reply sent.
Incoming articles could send out a copy of the article to each person on a review committee. They could approve or decline approval but if a sufficient number approved the item it would be automatically posted to the site.
There are lots of examples of this but it basically has to do with data movement and editing among a variety of humans and automated processes. The movement is normally defined externally in some kind of program or script so individuals don't have to know what happens when they get a new email and hit the approve or disapprove button. They just do their job and the system moves the data to the next person or directly to its final destination without their having to be informed of every change in procedure.
Exactly. We aren't "demanding" anything either, but GameDev.net is soon going to have a source tree available that will allow game developers to put up chunks of code or whole libraries. After much deliberation we will be allowing the use of various licenses on the code but _not_ the GPL.
Unfortunately, games are nothing like operating systems and the vast majority of them require no printed manuals, no support (hopefully), and no regular distributions of CDs. As a result, the money making apparatus that makes Red Hat work is not practical for game developers and we don't want to see code get into use that forces open source on a game that may start out as a lark but end up being a commercial success (ala. CounterStrike).
To reiterate, the GPL can often be shown to be overboard as a license. As an author you should use what you feel comfortable with but your choice may limit the use of your work in ways you don't forsee and do not want.
So will Savannah be allowing projects that have licenses other than GNU licenses? For example, my own project on SF has a BSD license.
If not, it's not a very viable alternative.
OK, I'll answer that. Your biggest ever employer had sixteen distinct projects while you were working there. How many did they have the year before? How many little one off projects had been written over the course of the previous five years and were the people who wrote them even working for the company anymore.
See, SF and the idea of project trees like it isn't just for what is being worked on now, it's for all that legacy crap from people who are long gone. It's about not having to track down their hard drives to see if they still had a copy of some little file format translation tool and then seeing that they had three different ones and not knowing what the difference is between each of the three versions.
IBM's decision to roll their own UI for this rather than use Swing was a poor one. There is lots of experience out there with Swing development and it can work very very well (see the aforementioned NetBeans/Forte for an example of a complex UI implemented in Swing).
I think that it will cut down on the number of developers who want to work on the project (me for example) and will increase the learning curve for those who do. Not a recipe for success.
One thing that is crutial for NetBeans performance is sufficient memory. If you were to try it on a machine with only 128MB or (god forbid) 64MB of memory you would conclude that it runs like molasses. Make sure you have enough memory to run such a feature rich IDE before you do so.
P.S. For what it's worth, NetBeans/Forte is an excellent IDE if you like one with lots of bells and whistles. It's built in support for GUI editing, CVS, and Ant all seem wonderful to me. I was using it's Javadoc auto comment feature just yesterday to touch up some code.
If you like something bare and stripped so it will be blindingly fast then this is not for you. If you like an IDE with everything and the kitchen sink, then you really should give it a look.
It can take a lot of forms but I can give an example taken from my personal experience.
GameDev.net is run by a diverse group of people spread all over the U.S. A workflow system would allow us to take incoming emails for example or new news or article submissions and perform a sequence of tasks on them.
For example, all new email items could be directed to one individual who screens the email. The items that made it through the initial screening could go to whomever was designated as "email answerer" for that week. The resulting replies could be sent to another individual for approval and then the reply sent.
Incoming articles could send out a copy of the article to each person on a review committee. They could approve or decline approval but if a sufficient number approved the item it would be automatically posted to the site.
There are lots of examples of this but it basically has to do with data movement and editing among a variety of humans and automated processes. The movement is normally defined externally in some kind of program or script so individuals don't have to know what happens when they get a new email and hit the approve or disapprove button. They just do their job and the system moves the data to the next person or directly to its final destination without their having to be informed of every change in procedure.
Unfortunately, games are nothing like operating systems and the vast majority of them require no printed manuals, no support (hopefully), and no regular distributions of CDs. As a result, the money making apparatus that makes Red Hat work is not practical for game developers and we don't want to see code get into use that forces open source on a game that may start out as a lark but end up being a commercial success (ala. CounterStrike).
To reiterate, the GPL can often be shown to be overboard as a license. As an author you should use what you feel comfortable with but your choice may limit the use of your work in ways you don't forsee and do not want.