Considering that Java has been (probably) the most used language for a while, you get a lot of crap. So, here's my "crap filter" list of what you should learn to really hop into the JVM ecosystem.
Books:
1. Effective Java, 2nd edition, by Josh Bloch
This covers most of the twists and turns of the basics that an experienced programmer would need. I wouldn't worry about getting a simpler book.
2. Java Concurrency in Practice
Understanding the JVM model of concurrency is important, and this is the only guide that had a pretty in-depth look into the subject. The Sun documentation absolutely sucks at covering concurrency.
Dependency injection is the most recent thing that makes Java a very powerful language for building large appications. And Guice is by far the best implementation of DI. (Yeah, you could learn Spring, but I just don't care for it.)
I hate Hibernate. But it basically set the standard for EJB3. If you know Hibernate, it's not a very hard road to learn all the other "enterprise" crap.
On the other hand, any substantial server-based solution probably uses a ORM solution like Hibernate.
There is a ton of projects under the Jakarta umbrella these days. The first one to try out is the commons-lang libraries, which provide very easy to use toString. equals, and hashCode implementations that are 'good enough' 99% of the time. Why do you need those? Read Effective Java.:)
Scala is my favorite "non-Java" JVM language by far. For me, the scala interpreter is how I learn APIs. In fact, most of my new code is in Scala, not Java.
3. Groovy, JRuby
Just some more used non-Java JVM languages. I've used JRuby a bit, but have moved on to Scala. It's still a significant project, however.
Wicket is the simplest page-based Web framework I've ever used. I just find it easier to navigate than Rails. If you really want an ORM-based solution, go for the Databinder extensions. Databinder will get you coding in a couple of minutes.
We have several different clusters, and a bunch of machines that need to transfer data around. I learned how to set up a restlet server that was integrated with Guice in a couple of hours, and now, have a very easy means to script together many different servers.
I agree that there's more opportunity for niches to develop with the web then with brick and mortar. But the idea of "hits" still applies; just to a more focused audience.
Ergo, I think the "long tail" argument is incorrect. Yes, you see niche stuff (like my EDM example) getting momentum on the web, each niche starts to develop it's own little hierarchy of best-sellers, and only after it gets enough traction to generate identity and trust. The difficulty lies in making connections through the meme.
It seems to me that the only time you're going to see an obscure product selling better on the web is when it's on a page that's focused on a niche. This is just because most web sites with a large stock make it hard to find quality niche products. You really have to dig to find gems sometimes; and digging isn't what folks seem to do a lot of on the web unless the product's expensive or the digging is fun to do.
A music example is electronic dance music. I don't go to iTunes for this stuff, because all the major retailers have extremely limited stock, and the stuff they have is all mixes and it's usually crappy "anthem" tunes. But I've found websites like etn.fm that play EDM I do like, and a store (beatport.com) that sells it, so when I'm looking for EDM, I'll check out those sites for what's best in my nice. But there's still the "hit effect" in place, so to speak; I'm far more likely to check out the popular EDM in play.
If people master a search method that allows you to regularly find what you consider "good", that would probably change the "hit effect". But we're talking about a search tool that can understand people's opinions and current emotional state. I doubt we're going find that anytime soon. Though I'm sure Google's trying.
Well, considering that "product lifetime" discussions are more about process than tools, you're probably not going to see any development tool talk about how it makes maintenance easier. That being said, I've found lots of very good tools related to project maintenance. Continuous integration systems like CruiseControl are fantastic for helping build a very solid, maintanable project.
But for products, you need to have the entire company be on the same page. The company needs to measure and keep everyone on the same page. The only kind of metrics I've ever seen for "product success" are sales figures, which is pretty lame and can be misleading. That aligns your definition of "success" with just making an initial sale; not necessarily making it easy to upgrade, ergo, all the company is concerned with is making more sales; everything else is a cost.
IDE's are great for getting past a lot of details of computer languages. It seems that there's a general consensus that a beginner working with an IDE will lose these details... but I have to think, "so what"?
Actually, so what is the goal of your course? Is it learning a language to know it's details, or learning to use a tool to solve problems? I can see valid reasons for both approaches.
Focusing on the language ability is a tremendous skill that forces people to understand the weaknesses and strengths of their selected tool. It's a critical trait I look for in a professional programmer, because that guy you hire that doesn't understand the language ends up writing code that you have to fix or rewrite. But then again, this is school, not work. And focusing on the language can also be a very dry subject to many people.
Focusing on solving problems can be a great way to inspire interest. If you can find interesting problems, your classwork will have a nice "approchability". The best problems also inspire the students to find their own nuances. Ergo, say you're going to make a pong-like game. This is great, since your inspired students may actually take on tweaking the game quite a bit to make it do different things: add more pads, more balls, obstacles, etc. If you can get to a "theme and variations" aspect to your problems, the students will probably learn more than hammering them with language details. (And, in fact, it may serve to have them find out the language details on their own, and asking good questions...)
I guess I'm coming from the opinion that school is not there to create professional programmers. But some people, and students, go to class just for that reason. Ergo, it's a grey area. But my advice is to use the IDE, and have the students do something complicated, rather than making them jump through hoops.
I had the exact same thought: why are they forcing Apple to support someone else's proprietary DRM scheme? The article leads me to believe this is just a "you should support anything anybody builds" sort of statement. (This may be a skewed interpretation of the author.)
My thought is that it should support open formats - say ogg. (Maybe they're trying to force Apple to license their format with others.) But trying to force someone else's proprietary format - even if it's "popular" with other businesses - is just going to result in Microsoft getting a big boost in market share. It seems like lawmakers are just concerned about ease of use, blind to principles of the electronic market.
Both arguments are oversimplifying the problem; usability can't be summed up into single metrics. People are complex things. What's "usable" can vary wildly depending upon the person. Often, when folks say "usable", they usually mean "intuitive". As in, the person can walk up and figure things out without thinking.
Should Linux work like Windows, or be it's own dog? Well, it depends entirely upon who you're marketing towards. If it's ex-Windows users, then it's a resounding yes. So, if you're Linspire, you want a Windows-like app so that your user base can do things like they always have. But if you're not, then you need to figure out who's going to use it, then tune to their needs.
Methinks that "what the Linux interface should be" is a little silly, since its not even a single platform. I'd just prefer more options that do things like remove the desktop interface metaphor, stuff like that. Not sure what exists today in the various HCI labs nationwide.
Look at the "Statement of Principles", and then look at the names at the bottom of the page. This site has several major members of the Bush administration.
My opinion:
What bugs me about PNAC is the focus on "moral clarity". This group is out to divide the world into "team players" and "enemies". While it can be effective at rallying support against a presence, it does nothing for our world image.
"Moral clarity" is culturally defined. This administration is very clearly out to change the world based on it's own world view. It is an extremely dangerous and agressive stance to take, and can create as many enemies as it neutralizes them.
It's this kind of language which indicates the definition of our two party system along religious lines. Morality and religion are such polarizing issues. They push people into voting for someone based on issues that will effect public policy indirectly, at best.... And since I want to see less of it in policymaking, I'm voting against the Bush administration. Egads. See, I'm feeling forced to vote for an issue I don't think is truly important. This is why voting blows.
Anyhow, back to PNAC, and it's effects. If the Bush administration frees up significant resources and stablizes Iraq, mark my words, the millitary effort is far from over. This is going to cost the world dearly over the long term.
(My screen got jumbled... i hope this isn't a duplicate post.)
My job has been to create a version control system that solves exactly this problem and automates others. Right now, it uses CVS, but is based off of a system that used PVCS and ClearCase.
Our revision system starts with release labels. Each directory gets tagged to a particular release label. Baselines, then are groups of release labels.
When a developer releases, their changes are branched off of the release label the directory started at. Then, the latest release is merged into their changes (if a later release from the one the branch is based off of occured). If everything still checks out, the branch is merged to the main development tree.
We have two scripts that make this process very simple: a commit and a release. The commit will take the current directory and create a users branch. This is for moving between trees - the developer now has a sandbox label they can update to. The release, which calls commit to make the user branch, handles both passes of merging.
I've noticed that CVS is not the greatest system for handling branches. It's ability to detect common ancestors is, well, flaky. I'm eagerly awaiting the release of Subversion, since my company really doesn't have the ooodles of $$ for ClearCase.
Also, note that when a developer releases, we also collect information which can link this release to a bug tracking slip. We also collate the release notes for releases. Ergo, you want to make a patch for your product, it's easy to collect all of the notes of changes and then create a single ChangeLog (which you usually want to edit a bit).
The system actually has been extended to handle multiple streams of development. This allows us to bugfix released versions of the product while making later changes, and smoothing the bugfix integration between releases. Adding this feature is both an enormously complex task and a huge timesaver for a large development team. You'd definitely push the bounds of what CVS can handle at this point.
Just some thoughts. This isn't a simple issue, but can have a solution that is simple to use.
I've been the admin of a Unix-style development environment on Win32. Basically, we've got a single Linux box running Apache, Postgres, and CVS (our bug tracking and CM tools), then all the clients are running Cygwin. This has been very effective for a team that was once around 30 developers, and I would recommend it to anyone. (Just make sure the Linux server has got the fastest hard drive you can find.)
There were definitely growing pains, however, and I still haven't come up with the a comfortable solution of automated upgrades of everyone's Cygwin environment. Upgrading the different Cygwin-based OS applications is a bit of a pain. I've considered writing a Windows Installer version of the Cygwin installer, or attempting to get all of those tools in some kind of rsync setup. I haven't found the best setup yet.
On the flip side, we're now porting some of our apps to Linux (and eventually Solaris when we can afford it). The build environment has got around 50-60 different scripts or so, and I've only had to customize three of them. That kind of portable environment is probably worth looking into this kind of tool setup if you're interested in cross-platform development.
OK, so a couple of statements were a little out of wack. Here's at least one correction:
Yeah, NMAKE is not a earlier version of GNUmake, but most of it's features are at a state where GNUmake was a while ago - for instance, NMAKE has to inline files whereas GNUmake can include them.
OK, now that I got _that_ out of the way, let me explain...
First off, there are two things I like about Visual Studio, which tends to typify IDEs, and those are the dialog editor and the debugger. The rest of the bells and whistles really don't give me much. But I see this sentiment echoed earlier - most people like some kind of GUI tool for developing the actual GUI interface, and a debugger with lots of information at once capabilities. These things are not unique to Visual Studio, but here's one thing that is:
Project Files.
I've overheard that internally, the boys at M$ regard Visual Studio as more of a toy. Supposedly, instead they use a modified version of nmake. (Hopefully one that doesn't just inline files... man that's annoying.) I completely agree with this sentiment. While Visual Studio can import nmake files yet, nmake is about the only other option you have. And what's the other option?
Project Files.
If you have to generate any kind of sizable project, the Project File setup is about as irritating as it gets. For large projects, you want to specify 99% of the build rules necessary in one place, then when you want to create a new library, just specify what kind of target it is and let your build system fly. Project Files instead center most of their rules around the leaft projects. This just causes integration headaches like you wouldn't believe unless your developer staff is really disciplined.
Not to mention, you're also choosing a build solution that is 100% not compatable with any other platform solution. NMake even doesn't port very sensibly to a GNUmake setup, mostly because it's really old version of GNUmake.
Now, admittedly, you can reset the custom commands in Visual Studio, but then, it becomes a hassle if you want to provide more than just two targets (typically all, and clean). For instance, we like to remove the MIDL step from the generic sequence, so we now have an includes target on top of all and clean. All of a sudden, the folks at my job who are still using visual studio have to find a new button to map.
On the other hand, most IDEs aren't as relagated like VS to a crappy build environment. Most can be edited, but personally, I'd still like to be able run a command line like XEmacs from the IDE. This is because we tend to create more targets (like test) and add components that aren't necessarily written in a compiled language. Make is just a handy tool for automating pretty much anything. I have yet to have an IDE that was extensible like this, and personally, this saves me way more time than having to use the integrated debugger or dialog editor. (WinDBG, anyone? And it's still fairly easy to whip out a dialog when necessary - and c'mon what percentage of your time is used writing dialogs?)
So, in the end, I think that VS, which I would be willing to bet is the main IDE in use out there, does not save time at all in a large project. I've even heard that projects using VS don't even run baselines (which is probably because they're using VSS which doesn't allow you to retrieve whole projects set to a tag... what was M$ thinking?...) On my personal experience, projects that don't run baselines hit massive integration problems. Thus, I'm at the point of banning VS inside my company.
On the other hand, if the IDE was designed to thinly wrap a make system, essentially being a powerful editor like Emacs with a integrated debugger, command shell, and dialog editor, I'd probably use it. But I have yet to find this tool.
The survey also found that 77.2 percent of the developers surveyed chose Red Hat Linux as the distribution for use with a Web server or Web application server. This is more than three times the 21.8 percent who selected SuSE Linux or Mandrake. Caldera OpenLinux and FreeBSD followed, with 21.4 percent and 20.4 percent, respectively, the data showed.
OK, 77.2 + 21.8 + 21.4 + 20.4 = 140.8 %
Apparently, this is some kind of new version of statistics.
Slashdot Mirror
Considering that Java has been (probably) the most used language for a while, you get a lot of crap. So, here's my "crap filter" list of what you should learn to really hop into the JVM ecosystem.
Books:
1. Effective Java, 2nd edition, by Josh Bloch
This covers most of the twists and turns of the basics that an experienced programmer would need. I wouldn't worry about getting a simpler book.
2. Java Concurrency in Practice
Understanding the JVM model of concurrency is important, and this is the only guide that had a pretty in-depth look into the subject. The Sun documentation absolutely sucks at covering concurrency.
APIs
1. Guice http://code.google.com/p/google-guice/
Dependency injection is the most recent thing that makes Java a very powerful language for building large appications. And Guice is by far the best implementation of DI. (Yeah, you could learn Spring, but I just don't care for it.)
2. Hibernate http://hibernate.org/
I hate Hibernate. But it basically set the standard for EJB3. If you know Hibernate, it's not a very hard road to learn all the other "enterprise" crap.
On the other hand, any substantial server-based solution probably uses a ORM solution like Hibernate.
3. Apache's Commons http://commons.apache.org/ and Jakarta http://jakarta.apache.org/
There is a ton of projects under the Jakarta umbrella these days. The first one to try out is the commons-lang libraries, which provide very easy to use toString. equals, and hashCode implementations that are 'good enough' 99% of the time. Why do you need those? Read Effective Java. :)
Interesting stuff:
1. Hadoop http://hadoop.apache.org/
Hadoop is an open-source implementation of Google's MapReduce idea.
2. Scala http://scala-lang.org/
Scala is my favorite "non-Java" JVM language by far. For me, the scala interpreter is how I learn APIs. In fact, most of my new code is in Scala, not Java.
3. Groovy, JRuby
Just some more used non-Java JVM languages. I've used JRuby a bit, but have moved on to Scala. It's still a significant project, however.
4. Web application frameworks: Wicket http://wicket.apache.org/ + Databinder http://databinder.net/
Wicket is the simplest page-based Web framework I've ever used. I just find it easier to navigate than Rails. If you really want an ORM-based solution, go for the Databinder extensions. Databinder will get you coding in a couple of minutes.
5. Restlet http://restlet.org/
We have several different clusters, and a bunch of machines that need to transfer data around. I learned how to set up a restlet server that was integrated with Guice in a couple of hours, and now, have a very easy means to script together many different servers.
I agree that there's more opportunity for niches to develop with the web then with brick and mortar. But the idea of "hits" still applies; just to a more focused audience.
Ergo, I think the "long tail" argument is incorrect. Yes, you see niche stuff (like my EDM example) getting momentum on the web, each niche starts to develop it's own little hierarchy of best-sellers, and only after it gets enough traction to generate identity and trust. The difficulty lies in making connections through the meme.
It seems to me that the only time you're going to see an obscure product selling better on the web is when it's on a page that's focused on a niche. This is just because most web sites with a large stock make it hard to find quality niche products. You really have to dig to find gems sometimes; and digging isn't what folks seem to do a lot of on the web unless the product's expensive or the digging is fun to do.
A music example is electronic dance music. I don't go to iTunes for this stuff, because all the major retailers have extremely limited stock, and the stuff they have is all mixes and it's usually crappy "anthem" tunes. But I've found websites like etn.fm that play EDM I do like, and a store (beatport.com) that sells it, so when I'm looking for EDM, I'll check out those sites for what's best in my nice. But there's still the "hit effect" in place, so to speak; I'm far more likely to check out the popular EDM in play.
If people master a search method that allows you to regularly find what you consider "good", that would probably change the "hit effect". But we're talking about a search tool that can understand people's opinions and current emotional state. I doubt we're going find that anytime soon. Though I'm sure Google's trying.
Well, considering that "product lifetime" discussions are more about process than tools, you're probably not going to see any development tool talk about how it makes maintenance easier. That being said, I've found lots of very good tools related to project maintenance. Continuous integration systems like CruiseControl are fantastic for helping build a very solid, maintanable project.
But for products, you need to have the entire company be on the same page. The company needs to measure and keep everyone on the same page. The only kind of metrics I've ever seen for "product success" are sales figures, which is pretty lame and can be misleading. That aligns your definition of "success" with just making an initial sale; not necessarily making it easy to upgrade, ergo, all the company is concerned with is making more sales; everything else is a cost.
IDE's are great for getting past a lot of details of computer languages. It seems that there's a general consensus that a beginner working with an IDE will lose these details... but I have to think, "so what"?
Actually, so what is the goal of your course? Is it learning a language to know it's details, or learning to use a tool to solve problems? I can see valid reasons for both approaches.
Focusing on the language ability is a tremendous skill that forces people to understand the weaknesses and strengths of their selected tool. It's a critical trait I look for in a professional programmer, because that guy you hire that doesn't understand the language ends up writing code that you have to fix or rewrite. But then again, this is school, not work. And focusing on the language can also be a very dry subject to many people.
Focusing on solving problems can be a great way to inspire interest. If you can find interesting problems, your classwork will have a nice "approchability". The best problems also inspire the students to find their own nuances. Ergo, say you're going to make a pong-like game. This is great, since your inspired students may actually take on tweaking the game quite a bit to make it do different things: add more pads, more balls, obstacles, etc. If you can get to a "theme and variations" aspect to your problems, the students will probably learn more than hammering them with language details. (And, in fact, it may serve to have them find out the language details on their own, and asking good questions...)
I guess I'm coming from the opinion that school is not there to create professional programmers. But some people, and students, go to class just for that reason. Ergo, it's a grey area. But my advice is to use the IDE, and have the students do something complicated, rather than making them jump through hoops.
I had the exact same thought: why are they forcing Apple to support someone else's proprietary DRM scheme? The article leads me to believe this is just a "you should support anything anybody builds" sort of statement. (This may be a skewed interpretation of the author.)
My thought is that it should support open formats - say ogg. (Maybe they're trying to force Apple to license their format with others.) But trying to force someone else's proprietary format - even if it's "popular" with other businesses - is just going to result in Microsoft getting a big boost in market share. It seems like lawmakers are just concerned about ease of use, blind to principles of the electronic market.
Both arguments are oversimplifying the problem; usability can't be summed up into single metrics. People are complex things. What's "usable" can vary wildly depending upon the person. Often, when folks say "usable", they usually mean "intuitive". As in, the person can walk up and figure things out without thinking.
Should Linux work like Windows, or be it's own dog? Well, it depends entirely upon who you're marketing towards. If it's ex-Windows users, then it's a resounding yes. So, if you're Linspire, you want a Windows-like app so that your user base can do things like they always have. But if you're not, then you need to figure out who's going to use it, then tune to their needs.
Methinks that "what the Linux interface should be" is a little silly, since its not even a single platform. I'd just prefer more options that do things like remove the desktop interface metaphor, stuff like that. Not sure what exists today in the various HCI labs nationwide.
If you're an American, and you haven't seen this website, I strongly encourage you check it out.
... And since I want to see less of it in policymaking, I'm voting against the Bush administration. Egads. See, I'm feeling forced to vote for an issue I don't think is truly important. This is why voting blows.
Project for the New American Century
Look at the "Statement of Principles", and then look at the names at the bottom of the page. This site has several major members of the Bush administration.
My opinion:
What bugs me about PNAC is the focus on "moral clarity". This group is out to divide the world into "team players" and "enemies". While it can be effective at rallying support against a presence, it does nothing for our world image.
"Moral clarity" is culturally defined. This administration is very clearly out to change the world based on it's own world view. It is an extremely dangerous and agressive stance to take, and can create as many enemies as it neutralizes them.
It's this kind of language which indicates the definition of our two party system along religious lines. Morality and religion are such polarizing issues. They push people into voting for someone based on issues that will effect public policy indirectly, at best.
Anyhow, back to PNAC, and it's effects. If the Bush administration frees up significant resources and stablizes Iraq, mark my words, the millitary effort is far from over. This is going to cost the world dearly over the long term.
(My screen got jumbled... i hope this isn't a duplicate post.)
My job has been to create a version control system that solves exactly this problem and automates others. Right now, it uses CVS, but is based off of a system that used PVCS and ClearCase.
Our revision system starts with release labels. Each directory gets tagged to a particular release label. Baselines, then are groups of release labels.
When a developer releases, their changes are branched off of the release label the directory started at. Then, the latest release is merged into their changes (if a later release from the one the branch is based off of occured). If everything still checks out, the branch is merged to the main development tree.
We have two scripts that make this process very simple: a commit and a release. The commit will take the current directory and create a users branch. This is for moving between trees - the developer now has a sandbox label they can update to. The release, which calls commit to make the user branch, handles both passes of merging.
I've noticed that CVS is not the greatest system for handling branches. It's ability to detect common ancestors is, well, flaky. I'm eagerly awaiting the release of Subversion, since my company really doesn't have the ooodles of $$ for ClearCase.
Also, note that when a developer releases, we also collect information which can link this release to a bug tracking slip. We also collate the release notes for releases. Ergo, you want to make a patch for your product, it's easy to collect all of the notes of changes and then create a single ChangeLog (which you usually want to edit a bit).
The system actually has been extended to handle multiple streams of development. This allows us to bugfix released versions of the product while making later changes, and smoothing the bugfix integration between releases. Adding this feature is both an enormously complex task and a huge timesaver for a large development team. You'd definitely push the bounds of what CVS can handle at this point.
Just some thoughts. This isn't a simple issue, but can have a solution that is simple to use.
-T
I've been the admin of a Unix-style development environment on Win32. Basically, we've got a single Linux box running Apache, Postgres, and CVS (our bug tracking and CM tools), then all the clients are running Cygwin. This has been very effective for a team that was once around 30 developers, and I would recommend it to anyone. (Just make sure the Linux server has got the fastest hard drive you can find.)
There were definitely growing pains, however, and I still haven't come up with the a comfortable solution of automated upgrades of everyone's Cygwin environment. Upgrading the different Cygwin-based OS applications is a bit of a pain. I've considered writing a Windows Installer version of the Cygwin installer, or attempting to get all of those tools in some kind of rsync setup. I haven't found the best setup yet.
On the flip side, we're now porting some of our apps to Linux (and eventually Solaris when we can afford it). The build environment has got around 50-60 different scripts or so, and I've only had to customize three of them. That kind of portable environment is probably worth looking into this kind of tool setup if you're interested in cross-platform development.
OK, so a couple of statements were a little out of wack. Here's at least one correction:
Yeah, NMAKE is not a earlier version of GNUmake, but most of it's features are at a state where GNUmake was a while ago - for instance, NMAKE has to inline files whereas GNUmake can include them.
OK, now that I got _that_ out of the way, let me explain...
First off, there are two things I like about Visual Studio, which tends to typify IDEs, and those are the dialog editor and the debugger. The rest of the bells and whistles really don't give me much. But I see this sentiment echoed earlier - most people like some kind of GUI tool for developing the actual GUI interface, and a debugger with lots of information at once capabilities. These things are not unique to Visual Studio, but here's one thing that is:
Project Files.
I've overheard that internally, the boys at M$ regard Visual Studio as more of a toy. Supposedly, instead they use a modified version of nmake. (Hopefully one that doesn't just inline files... man that's annoying.) I completely agree with this sentiment. While Visual Studio can import nmake files yet, nmake is about the only other option you have. And what's the other option?
Project Files.
If you have to generate any kind of sizable project, the Project File setup is about as irritating as it gets. For large projects, you want to specify 99% of the build rules necessary in one place, then when you want to create a new library, just specify what kind of target it is and let your build system fly. Project Files instead center most of their rules around the leaft projects. This just causes integration headaches like you wouldn't believe unless your developer staff is really disciplined.
Not to mention, you're also choosing a build solution that is 100% not compatable with any other platform solution. NMake even doesn't port very sensibly to a GNUmake setup, mostly because it's really old version of GNUmake.
Now, admittedly, you can reset the custom commands in Visual Studio, but then, it becomes a hassle if you want to provide more than just two targets (typically all, and clean). For instance, we like to remove the MIDL step from the generic sequence, so we now have an includes target on top of all and clean. All of a sudden, the folks at my job who are still using visual studio have to find a new button to map.
On the other hand, most IDEs aren't as relagated like VS to a crappy build environment. Most can be edited, but personally, I'd still like to be able run a command line like XEmacs from the IDE. This is because we tend to create more targets (like test) and add components that aren't necessarily written in a compiled language. Make is just a handy tool for automating pretty much anything. I have yet to have an IDE that was extensible like this, and personally, this saves me way more time than having to use the integrated debugger or dialog editor. (WinDBG, anyone? And it's still fairly easy to whip out a dialog when necessary - and c'mon what percentage of your time is used writing dialogs?)
So, in the end, I think that VS, which I would be willing to bet is the main IDE in use out there, does not save time at all in a large project. I've even heard that projects using VS don't even run baselines (which is probably because they're using VSS which doesn't allow you to retrieve whole projects set to a tag... what was M$ thinking?...) On my personal experience, projects that don't run baselines hit massive integration problems. Thus, I'm at the point of banning VS inside my company.
On the other hand, if the IDE was designed to thinly wrap a make system, essentially being a powerful editor like Emacs with a integrated debugger, command shell, and dialog editor, I'd probably use it. But I have yet to find this tool.
... whew, that was one kind of rant...
OK, 77.2 + 21.8 + 21.4 + 20.4 = 140.8 %
Apparently, this is some kind of new version of statistics.
(Man, I thought I was working hard giving 110%.)
Gee, I'm looking for a job right now. Maybe in their exuberance about history they'll feel forgiving....