> > 1. I had to get the next version of ant to ask it to pass a -ea to the java compiler.
> -ea? Its not a javac option. And you can add any compiler argument like with the tag. Maybe you mean the -ea enable assertions feature of the java program. yes, that didnt come out till after java1.4, but you could still do it by hand.
Yeah, it was assertions, I can't reacall the details, all I know is that our build broke when we added assertions and I couldn't teach ant how to pass in the right args to something, must have been java for the test target.
I don't buy it that I have to use ant if I'm developing in java but thats the way the world has gone. I don't see where the big win is except thats what all the IDE's are built around. I suppose ant offers a more portable build environment but I generally don't care (and there's always cygwin).
Maybe my real problem is that nasty build.xml that was thrust upon us on that project back in 2002 (and, yes, makefiles can get pretty ugly too).
Yeah, OK Xemacs sucks up memory bit kicks ass on a reasonable box and eclipse is a dog on the same box - maybe I'm misusing the word "bloat". How's "has poor interactive performance in comparison".
Dunno what you hava against something thats easy to read and understand. I'm not tweaking makefiles all the time but I do add to them, and create new ones as the project gets bigger. For instance, as new classes are added, they get added to the makefile. It allows for fine control of what gets built vs other code that may land in the same directory (path finding, test code, etc).
Again, I don't know ant but my impression has been that ant just starts up the tree and sucks in every.java file it finds. Often OK but not always.
I also get that the idea is to use a tool to configure your build.xml, well, I don't want to. When developers use tools like this, they learn how to use the tool, not how things work. A developer is forced to understand how things work when they have to create/maintain makefiles as new packages/classes are added to the system. Tools that magically put everything together for you make you dumber (or keep you from getting smarter).
I use Xemacs, JDE, and make on Linux to create commercial products in java/jsp.
At my last job, back on 2002, ant forced me to hate it when:
1. I had to get the next version of ant to ask it to pass a -ea to the java compiler.
2. We had this crazy huge build.xml file that was created for our project. It started off life as a rats nest and only got worse from there (OK, probably not ant's fault but it had the same effect on me). On top of it being huge, its in XML which is way hard to read compared to a makefile.
3. I never could figure out how to ask ant to echo the compile line. Make echos it by default and I like it that way.
That was three strikes.
On my current project we are using make but one of them whipper snappers came along and made a build.xml file for the project. Its just one big, ugly, build.xml but it is much faster. The project has 30 or so small, easy to read/understand, makefiles (and I figured out how to make it go much faster on a clean build but its still not as fast as ant).
Sure, make has its quirks (e.g. the tab thing) but I figured all thouse out 15 years ago.
I tried Eclipse last fall after seeing an interesting presentation on it. I tried it for a couple of days but it felt so bloated that I soon abandoned it.
I never read this book but I was subjected to a group of geeks who not only read the book but took a class on it. After that it was like they were all trying to sell me a used car. I found myself washing my hands all the time. Maybe they got better at it after they practised on me.
Many of them returned to normal after a while but not all. Those who remained in the fold got put on projects with names like "Vision 2000" and had titles like "Communications Champion"... Be careful on this one.
One of the articles, I can't recall which, stated that NASA executed the package (whatever that is) delivered to them by ESA. It seems like there should have been a Cassini simulator to test these packages on. That, plus a checklist with an entry like "Receiver A on".
I would have run it on a sim at ESA and on a sim at NASA (the package should come with a checklist) and with independant review and verification to boot.
"I think every kid should be forced to do one year of grunt work somewhere before going to college. I don't care if it is Peace Corps, picking up trash along the highway or working a minimum wage slot at the 7-11. I know a bit of 'real world' experience would have helped me focus in class."
This is exactly what it took for me: I dropped out of high school as soon as I turned 17 and joined the Air Force. I have to say that the Air Force was very good to me but it didn't take me long to figure out that I had made some mistakes. When I did get to college I had some motivation (three years later but I had already taken many classes, including three semesters of Calculus).
After motivation, its all about curiosity and focus. You can't learn much if you can't find any interest in the subject. Usually its not that the subject is uninteresting (err... except for foreign languages), its that you haven't looked hard enough at it. Developing that curiosity is way easier than cheating, if you are cheating then you have given up and its just a grind.
1. I am a FIRST Lego League coach for middle school. Its great stuff and kids love it. Tons of work. I have also assisted with the HS FIRST robotics competition. Also great stuff. In both cases it can be difficult to rope in the less geeky but its possible. Some find the geek inside and thrive. Its cool to watch.
Stuff I think about doing later:
2. Teach them how to program a microcontroller and use it to control motors, leds, etc. (STAMP or OOPIC are pretty easy). Build something fun.
3. Get a group of kids and head to the dump. At our dump there is always a pile of old PC's and monitors, every one I have ever left with has worked fine. Have each kid find an old junker or two to work on. Bring it back to class and help each work through getting it to come back to life, then hand out the fedora CD's (or whatever). Teach them how to set it up as a web server/web development platform/firewall/whatever.
I was contracting when it was good back in the 90's. I miss it. Not because of all that stuff above about 1099 vs W2, getting insurance (don't forget disability), etc., etc., etc. Not that it isn't Important. It is very important. Do the math and don't forget to budget time for vacation, sick time, Social Security, etc.
But here's what I loved about contracting: You get paid for when you are working and you don't get paid when your not:
Up against a deadline? They pay. You are there with all those full-timers getting there dinner on their own time. They pay you and you get the dinner too. I always used to tell my boss, if I'm here, and I'm not eating lunch, you are paying me.
But there's more: perfomance appraisal time is when they renew the contract, no BS. No BS company meetings, no six-sigma/Q+/pick-your-quality-program nonsense, no company gatherings on your time, they don't want you there and you (well, I) don't want to be there. I like doing my job, they can keep all that other crap.
You are there to do X and thats what you do. When X is done, and If they like you, they find Y for you to do. Its a good system.
That much said, here in the Boston area, rates still seem way down (but I haven't been looking all that hard either).
Finally, if you go through an agency, ask them what their mark-up is. Most will refuse but some do answer. If they refuse, I'll ask if its more than 35% (high typical on a W2). Most will answer that with a no but some will be lying. I have known agencies back in the day to mark up by as much as 65%. I doubt they can get away with that now. Its best to talk to someone that has worked with a particular agency to find out if they are good or bad.
Boat anchors rock! I too have a Hallicrafters S-38, along with a few others. Hallicrafters, especially the S-38, had style and performance. A few pics here:
If you have never used a restored and tuned up AM/SW radio like these, you don't know how good AM can be. Of course the content isn't what it used to be.
Valid point. This is where management comes in. Fix the plan if its wrong or becomes wrong and dicide where to take the hit: features, date, or otherwise (but throwing resources at a project to make up time is usuall couter-productive in the short term).
Good managers are a rare thing. I have never had a good manager that has never written any code (CYA: maybe one) though I have had many bad managers that have written code.
Of course, my opinion of a good manager may differ from that of upper management.
I have been programming for pay since 1987. I have been on a few successful projects and plenty of flops. Success happens for many reasons but one important reason for success is that management needs to have a clue about how software is made and what the customer needs.
The problem is that it all comes down to compromises. Making the right compromises is the difference between success and failure. Its making that decision between slipping on the schedule and dropping feature X.
All too often, clueless management either takes the "just do it" attitued, the "just slip it" attitude, or the delegate it to the wrong person attitude.
Having a manager with a clue goes a long way. Beyond that, the formula is simple.
1. Have written requirements. 2. Have a due date. 3. Make a plan (architecture, design, & milestones). 4. Do what the plan siad. 5. Make compromises as necessary to make your date (try real hard not to change the date). 6. Review and test (have peer reviews, unit tests, integration tests, etc.).
Assemble a team of motivated individuals who do not have alternate agendas. Reward people with money (sometimes known as time). You can keep all the high achievers with attitudes, I'll take the worker bees thank you very much.
George Bush has a solution and he told us all about it at the last debate: He will retrain us!
He has made available copious piles of cash to remold our now useless software development skills into something useful, like, ahhhh... word processing!
It looked to me (and my co-workers at the time) like a giant, breathing N. I still rememer the first time I saw it. What a gas. It was soon replaced by the shadowy/spacey N (which I like better, but it would be fun to see that breathing N again).
It was in that browser/Solaris that I experienced the first big US terror incident: Oaklahoma City. I think I was on Opera/Linux for 9/11.
From what I can tell (and I work at a _big_ company as a software developer), e-mail, ppt, word, spread sheets, and surfing are 99% of what is used on the desktop. Databases and their ilk are generally run elsewhere (thats what crystal reports is, right?).
For all those desktoppy things, one of the big Linux distros would be fine. The problems are in compatability. There is a perception that Open Office is inferior because it can sometimes have problems reading the excessively tarted up ppt and word files (usually this is stuff that ought to be in an ascii file but thats a separate issue).
So OpenOffice gets the "Its not ready for prime time" rap. The only way to overcome this is for OpenOffice to be better than word, etc. Its Not there yet (plus, it has a bloaty feel to it while the M$ apps are seeming snappy these days).
Another major issue in getting big companies to switch are what to do the droves of ITbots running around with fistfulls of M$ CDs. Most of them haven't a clue about Linux. Some seem interested, the rest are just clickers and will have a difficult time making the transistion. It requires an investment in training and a certain measure of uncertainty. This makes it a tough sell.
All that said, I run RedHat 9.0 on my desktop and get by just fine (when I installed Linux, IT disowned me but thas OK). My tactic for dealing with stuff I can't read is to ignore it. If its important, someone will yell and I'll boot into M$ to read it (which I haven't had to do for months).
If we can't do it all at once, we can do it once desktop at a time.
Errr... I got lost when we divided by the software engineer but:
I have done CMMI and I am not a fan of heavy process done in the heavy handed way CMMI is done. Its a great way for extra levels of management to justify themselvs. That much said, CMMI does ask developers to do important things (and don't quote me, this is just what it means to me):
1. Coding standards 2. Unit testing (automate it!) 3. Peer reviews 4. System testing
CMMI makes you do all of that and document it. The paperwork is over the top but the result is better software.
The big winners are having unit test code that aims for 100% coverage and real peer reviews (the many eyes approach). The peer reviews can be initially painful but everyone learns their bad habits quickly and soon gets out of them.
The downside is that it comes with a whole crew of managers, inspectors, auditors, validators, finger pointers, and beurocrats who are working hard to justiy their existance by beating up the developers and their code as much as possible.
In the end, it all comes down to common sense: plan what you are going to do. Do it carefully. Test it. Ask your peers to review it and learn from their comments. Put it all together and test it again. Remember your problems so you don't repeat them.
Re:IDE - Editor or round trip engineering tool?
on
Java IDEs?
·
· Score: 1
If you are working on NT and would rather not, the combination of Cygwin, XEmacs, and jdee can't be beat (though I did have some issues getting the debugger working a few months ago). The only thing missing from this combination is a gui layout editor. I have been doing it by hand and it sucks. What I would give for XDesigner and a Motif form right now!
The other developers here have been using Forte but I find it to be more of a hinderance than a help.
I have to agree on the UML piece too. If I had Rose I would be using it but I'm stuck with a whiteboard (can't save, can't look at other peoples designs). Rose is expensive ($2500 last I checked). We used it at my last job and it not only makes you a better designer but it also helps new developers come up to speed fast. Beats the hell out of reading code.
Slashdot Mirror
> > 1. I had to get the next version of ant to ask it to pass a -ea to the java compiler.
> -ea? Its not a javac option. And you can add any compiler argument like with the tag. Maybe you mean the -ea enable assertions feature of the java program. yes, that didnt come out till after java1.4, but you could still do it by hand.
Yeah, it was assertions, I can't reacall the details, all I know is that our build broke when we added assertions and I couldn't teach ant how to pass in the right args to something, must have been java for the test target.
I don't buy it that I have to use ant if I'm developing in java but thats the way the world has gone. I don't see where the big win is except thats what all the IDE's are built around. I suppose ant offers a more portable build environment but I generally don't care (and there's always cygwin).
Maybe my real problem is that nasty build.xml that was thrust upon us on that project back in 2002 (and, yes, makefiles can get pretty ugly too).
Yeah, OK Xemacs sucks up memory bit kicks ass on a reasonable box and eclipse is a dog on the same box - maybe I'm misusing the word "bloat". How's "has poor interactive performance in comparison".
.java file it finds. Often OK but not always.
Dunno what you hava against something thats easy to read and understand. I'm not tweaking makefiles all the time but I do add to them, and create new ones as the project gets bigger. For instance, as new classes are added, they get added to the makefile. It allows for fine control of what gets built vs other code that may land in the same directory (path finding, test code, etc).
Again, I don't know ant but my impression has been that ant just starts up the tree and sucks in every
I also get that the idea is to use a tool to configure your build.xml, well, I don't want to. When developers use tools like this, they learn how to use the tool, not how things work. A developer is forced to understand how things work when they have to create/maintain makefiles as new packages/classes are added to the system. Tools that magically put everything together for you make you dumber (or keep you from getting smarter).
I use Xemacs, JDE, and make on Linux to create commercial products in java/jsp.
At my last job, back on 2002, ant forced me to hate it when:
1. I had to get the next version of ant to ask it to pass a -ea to the java compiler.
2. We had this crazy huge build.xml file that was created for our project. It started off life as a rats nest and only got worse from there (OK, probably not ant's fault but it had the same effect on me). On top of it being huge, its in XML which is way hard to read compared to a makefile.
3. I never could figure out how to ask ant to echo the compile line. Make echos it by default and I like it that way.
That was three strikes.
On my current project we are using make but one of them whipper snappers came along and made a build.xml file for the project. Its just one big, ugly, build.xml but it is much faster. The project has 30 or so small, easy to read/understand, makefiles (and I figured out how to make it go much faster on a clean build but its still not as fast as ant).
Sure, make has its quirks (e.g. the tab thing) but I figured all thouse out 15 years ago.
I tried Eclipse last fall after seeing an interesting presentation on it. I tried it for a couple of days but it felt so bloated that I soon abandoned it.
I never read this book but I was subjected to a group of geeks who not only read the book but took a class on it. After that it was like they were all trying to sell me a used car. I found myself washing my hands all the time. Maybe they got better at it after they practised on me.
Many of them returned to normal after a while but not all. Those who remained in the fold got put on projects with names like "Vision 2000" and had titles like "Communications Champion"... Be careful on this one.
One of the articles, I can't recall which, stated that NASA executed the package (whatever that is) delivered to them by ESA. It seems like there should have been a Cassini simulator to test these packages on. That, plus a checklist with an entry like "Receiver A on".
I would have run it on a sim at ESA and on a sim at NASA (the package should come with a checklist) and with independant review and verification to boot.
You forgot to escape it!
$ make o\'reilly
make: *** No rule to make target `o'reilly'. Stop.
Hmmm....
$ cat ${35bucks} | make o\'reilly
make: *** No rule to make target `o'reilly'. Stop.
bash: ${35bucks}: bad substitution
Hmmm... I guess not me either.
"I think every kid should be forced to do one year of grunt work somewhere before going to college. I don't care if it is Peace Corps, picking up trash along the highway or working a minimum wage slot at the 7-11. I know a bit of 'real world' experience would have helped me focus in class."
This is exactly what it took for me: I dropped out of high school as soon as I turned 17 and joined the Air Force. I have to say that the Air Force was very good to me but it didn't take me long to figure out that I had made some mistakes. When I did get to college I had some motivation (three years later but I had already taken many classes, including three semesters of Calculus).
After motivation, its all about curiosity and focus. You can't learn much if you can't find any interest in the subject. Usually its not that the subject is uninteresting (err... except for foreign languages), its that you haven't looked hard enough at it. Developing that curiosity is way easier than cheating, if you are cheating then you have given up and its just a grind.
1. I am a FIRST Lego League coach for middle school. Its great stuff and kids love it. Tons of work. I have also assisted with the HS FIRST robotics competition. Also great stuff. In both cases it can be difficult to rope in the less geeky but its possible. Some find the geek inside and thrive. Its cool to watch.
Stuff I think about doing later:
2. Teach them how to program a microcontroller and use it to control motors, leds, etc. (STAMP or OOPIC are pretty easy). Build something fun.
3. Get a group of kids and head to the dump. At our dump there is always a pile of old PC's and monitors, every one I have ever left with has worked fine. Have each kid find an old junker or two to work on. Bring it back to class and help each work through getting it to come back to life, then hand out the fedora CD's (or whatever). Teach them how to set it up as a web server/web development platform/firewall/whatever.
4. Profit!
I was contracting when it was good back in the 90's. I miss it. Not because of all that stuff above about 1099 vs W2, getting insurance (don't forget disability), etc., etc., etc. Not that it isn't Important. It is very important. Do the math and don't forget to budget time for vacation, sick time, Social Security, etc.
But here's what I loved about contracting: You get paid for when you are working and you don't get paid when your not:
Up against a deadline? They pay. You are there with all those full-timers getting there dinner on their own time. They pay you and you get the dinner too. I always used to tell my boss, if I'm here, and I'm not eating lunch, you are paying me.
But there's more: perfomance appraisal time is when they renew the contract, no BS. No BS company meetings, no six-sigma/Q+/pick-your-quality-program nonsense, no company gatherings on your time, they don't want you there and you (well, I) don't want to be there. I like doing my job, they can keep all that other crap.
You are there to do X and thats what you do. When X is done, and If they like you, they find Y for you to do. Its a good system.
That much said, here in the Boston area, rates still seem way down (but I haven't been looking all that hard either).
Finally, if you go through an agency, ask them what their mark-up is. Most will refuse but some do answer. If they refuse, I'll ask if its more than 35% (high typical on a W2). Most will answer that with a no but some will be lying. I have known agencies back in the day to mark up by as much as 65%. I doubt they can get away with that now. Its best to talk to someone that has worked with a particular agency to find out if they are good or bad.
Boat anchors rock! I too have a Hallicrafters S-38, along with a few others. Hallicrafters, especially the S-38, had style and performance. A few pics here:
http://retro-tronics.com/radio.php
If you have never used a restored and tuned up AM/SW radio like these, you don't know how good AM can be. Of course the content isn't what it used to be.
Want to build something with tubes? Go here: http://www.funwithtubes.com/
Mayby Window$ is Unix under the covers! They just "tweaked" a bit to get the blue screens and to ummm... alter performance.
Valid point. This is where management comes in. Fix the plan if its wrong or becomes wrong and dicide where to take the hit: features, date, or otherwise (but throwing resources at a project to make up time is usuall couter-productive in the short term).
Good managers are a rare thing. I have never had a good manager that has never written any code (CYA: maybe one) though I have had many bad managers that have written code.
Of course, my opinion of a good manager may differ from that of upper management.
I have been programming for pay since 1987. I have been on a few successful projects and plenty of flops. Success happens for many reasons but one important reason for success is that management needs to have a clue about how software is made and what the customer needs.
The problem is that it all comes down to compromises. Making the right compromises is the difference between success and failure. Its making that decision between slipping on the schedule and dropping feature X.
All too often, clueless management either takes the "just do it" attitued, the "just slip it" attitude, or the delegate it to the wrong person attitude.
Having a manager with a clue goes a long way. Beyond that, the formula is simple.
1. Have written requirements.
2. Have a due date.
3. Make a plan (architecture, design, & milestones).
4. Do what the plan siad.
5. Make compromises as necessary to make your date (try real hard not to change the date).
6. Review and test (have peer reviews, unit tests, integration tests, etc.).
Assemble a team of motivated individuals who do not have alternate agendas. Reward people with money (sometimes known as time). You can keep all the high achievers with attitudes, I'll take the worker bees thank you very much.
George Bush has a solution and he told us all about it at the last debate: He will retrain us!
He has made available copious piles of cash to remold our now useless software development skills into something useful, like, ahhhh... word processing!
It looked to me (and my co-workers at the time) like a giant, breathing N. I still rememer the first time I saw it. What a gas. It was soon replaced by the shadowy/spacey N (which I like better, but it would be fun to see that breathing N again).
It was in that browser/Solaris that I experienced the first big US terror incident: Oaklahoma City. I think I was on Opera/Linux for 9/11.
From what I can tell (and I work at a _big_ company as a software developer), e-mail, ppt, word, spread sheets, and surfing are 99% of what is used on the desktop. Databases and their ilk are generally run elsewhere (thats what crystal reports is, right?).
For all those desktoppy things, one of the big Linux distros would be fine. The problems are in compatability. There is a perception that Open Office is inferior because it can sometimes have problems reading the excessively tarted up ppt and word files (usually this is stuff that ought to be in an ascii file but thats a separate issue).
So OpenOffice gets the "Its not ready for prime time" rap. The only way to overcome this is for OpenOffice to be better than word, etc. Its Not there yet (plus, it has a bloaty feel to it while the M$ apps are seeming snappy these days).
Another major issue in getting big companies to switch are what to do the droves of ITbots running around with fistfulls of M$ CDs. Most of them haven't a clue about Linux. Some seem interested, the rest are just clickers and will have a difficult time making the transistion. It requires an investment in training and a certain measure of uncertainty. This makes it a tough sell.
All that said, I run RedHat 9.0 on my desktop and get by just fine (when I installed Linux, IT disowned me but thas OK). My tactic for dealing with stuff I can't read is to ignore it. If its important, someone will yell and I'll boot into M$ to read it (which I haven't had to do for months).
If we can't do it all at once, we can do it once desktop at a time.
Errr... I got lost when we divided by the software engineer but:
I have done CMMI and I am not a fan of heavy process done in the heavy handed way CMMI is done. Its a great way for extra levels of management to justify themselvs. That much said, CMMI does ask developers to do important things (and don't quote me, this is just what it means to me):
1. Coding standards
2. Unit testing (automate it!)
3. Peer reviews
4. System testing
CMMI makes you do all of that and document it. The paperwork is over the top but the result is better software.
The big winners are having unit test code that aims for 100% coverage and real peer reviews (the many eyes approach). The peer reviews can be initially painful but everyone learns their bad habits quickly and soon gets out of them.
The downside is that it comes with a whole crew of managers, inspectors, auditors, validators, finger pointers, and beurocrats who are working hard to justiy their existance by beating up the developers and their code as much as possible.
In the end, it all comes down to common sense: plan what you are going to do. Do it carefully. Test it. Ask your peers to review it and learn from their comments. Put it all together and test it again. Remember your problems so you don't repeat them.
If you are working on NT and would rather not, the combination of Cygwin, XEmacs, and jdee can't be beat (though I did have some issues getting the debugger working a few months ago). The only thing missing from this combination is a gui layout editor. I have been doing it by hand and it sucks. What I would give for XDesigner and a Motif form right now!
The other developers here have been using Forte but I find it to be more of a hinderance than a help.
I have to agree on the UML piece too. If I had Rose I would be using it but I'm stuck with a whiteboard (can't save, can't look at other peoples designs). Rose is expensive ($2500 last I checked). We used it at my last job and it not only makes you a better designer but it also helps new developers come up to speed fast. Beats the hell out of reading code.