I use MindBright's ssh applet to proxy SSH over HTTP. Once that's done, anything can be tunneled.
Joe
Increase Developer Productivity???
on
Java IDEs?
·
· Score: 1
1. Is developer productivity really a problem? Most shops I've seen, bad requirements or project management are a problem. Developers code on or a head of schedule. When the lines between coder, designer, and production deisgner are blurred, productivity goes down. Read "The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity", ISBN: 0672316498 .
2. You should be coding to standards. IDE shouldn't matter. Let each developer choose one's own, but support one for the inexperienced (any IDE, they all do the same thing).
Look at the success of EGCS and GCC. That was a successful split and merge. It led to a better GCC in the end while supporting both stable and advance versions of gcc in the interim.
There's no reason why the old software eeprom can't be saved and used for example in another truck which has had its software inadvertantly erased or damaged.
Yes there is. That's not how the upgrade works.
you bought a 450 hp engine in a fire truck.
you take your fire truck back for an engine upgrade.
now you have a 500 hp truck.
I don't know what eeprom you are talking about. You didn't buy a program, or rights to a program, nor will you find specs for the program and you will definitely void the waranty on your $150K truck by messing with your fuel map.
You upgraded the engine to 500hp and you lost the use of your 450 hp engine.
When you upgrade from WinNT to Win2000, you gained use of Win2000 and lost use of WinNT (assuming one OS per machine). Seems like the same deal to me.
Sure I hate the plan; I like getting more for my money than that, but it isn't unreasonable to license software like that.
If you sell your old 140hp internal combustion engine, you no longer have the right to install the 280hp internal combustion engine you've purchased as an upgrade.
Actually engine upgrades can be just software changes. Engines in trucks are often upgraded just by changing the fuel map. It cost more for the higher hp, and you can no longer use the old engine.
Wouldn't the acceleration of touching a flat surface be enough feedback? My problem with keyboards that don't have any feedback is that the signalling mechanism is not the acceleration of my finger tips, but instead some applied force that may or may not be the results of the acceleration of my finger tips.
At least Microsoft is singular, and they aren't in the position to sell me a car, book plane tickets, give me a loan, or offer me a long-distance plan.
Unix has many situations where trust of users has been implicit, if not outright designed in.
OK... Please explain.
Many Unix commands have failed to test user input, leading to the potential for problems ("passwd -f", for example, used to allow things like newlines, making it trivial to add your own r00t account).
So there was a bug? passwd surely wasn't designed to trust users to not put returns in their name field.
The "all or nothing" security model of Unix leads to a whole bunch of setuid programs, which means we have to trust the users, or at least trust our ability to code against every possible thing a user might try.
But Unix isn't all or nothing. Your installation may be. My machines, have a variety of accounts with different permissions for different parts of the file systems and could have different permissions for memory usage and cpu usage.
The three-level permission model (user, group, others)is pretty weak, and there's no standard way to implement ACLs to make up for it.
True, but again why does that that imply that Unix "trusts" the users?
Think of all of the ways to crack root on a Unix box.
Again, please explain this to me. The existence of bugs is not an indication that Unix was designed to trust the user. In the case of windows, it was designed as a single user operating system. It was designed to trust the single user, for example, users can modify system files. I'm not bashing MS, I'm bashing you. I think you are wrong with your assertion that Unix trusts the user.
A user account can not modify executable, delete others data, change the configuration of the system, fill the disks or on many unixes, use all the process slots or all the memory. When does Unix trust users?
OK, I'll give you that the MFC stuff we didn't completely rewrite, just modified stuff that the screen painter built. All the rest of the projects had hand coded GUIs.
I think we have a misunderstanding though. We didn't rewrite any provided components, we used the components in code that we wrote. we used the screen painter for prototypes, but the final code was hand coded, and much smaller, faster and easier to maintain than the screen painter stuff. The handcoded app was also portable across IDEs while the screen painter stuff often isn't.
Humans have solved conflicts using violence for hundreds of thousands of years. Why should we drop that great tradition now? Why should we forget its effect through suppression in the media? Is it better for me to take your stuff by way of bribery, legal trickery or by knocking you down and taking it? I suggest that the more honest approach is through the violence of knocking you down and taking it (it may result to that anyway).
Violence is an honest viable form of conflict resolution. I suggest that people learn when it is appropriate. Given that, it is not appropriate in school, in the houses of congress, or in the board room.
Violence may be appropriate when dealing with a group that has extremely different background and values from you own. Violence is a very basic conflict resolution style that everyone from Asian, to African, to European, to American Indian, to canine, to sheep, to lion understand. I would guess that any form of life capable of memory and self preservation, even alien, would understand violence.
Violence is in itself not wrong.
Are battling robots really violent? What's the difference if we settle our conflict through dumping money into lobbiest, or dumping our money into battlee bots; in the end, the organisation with the most money wins.
The customers on my last 5 GUI projects, ok all the GUI projects in my professional career, had such demanding GUI requirements that we couldn't build the app with a screen painter anyway. We built some prototypes with RAD tools, but then had to hand code MFC, OWL, AWT or Swing interfaces.
I've used VisualAge, VisualC++, VisualCafe, BorlandC++, Delphi, C++ Builder, and JBuilder and found this to b true in all of them. My most productive tools are API docs, emacs (but any complete editor like jEdit or vi would do), and a comand line compiler (debuggers and profilers are nice, but optional).
1) Then they are to busy to write requirements too. If they are to busy to explain what they want, then what can I do?
2) Actually I don't do much GUI work. A user may ask for a complex search, for instance I just did a name matching system for a reinsurance company. The users couldn't express how to search for a name, which one was a better match, how to order the results; they had been trying to write requirements for 3 years and had an unacceptably slow COBOL program that was patched together with duct tape as a result. I built a couple prototypes in SQL/JSP, explained to them how they worked, then we wrote down an english description of the algorythms for posterity. The final interface to the system is a stored procedure, but we captured the requirements using SQL and JSPs.
Users are not designers nor programmers. They don't know what is possible with systems, nor how hard certain things are to do with systems. My job is to solve information management problems; this usually results in systems changes, but sometimes only results in process changes.
Are you a programmer, or are you "providing solutions"?
You see, I think this whole thing with specs and software engineering is a hoax. Having the customer sign off on requirements, gives the development team an excuse point. The only way to completely spec a system is to write it. Any missing feature in the spec is a possible mistake or short for the development team. Now, if the spec writer can write down a spec that is as detailed as the final system, then why the hell didn't he/she write the system in a compilable language to start with and eliminate the chance of mistake due to translation from English to code?!
My favorite mode of developing systems, is to get high level requirements, then prototype, then prototype, then prototype, then prototype, then prototype, keeping in mind that rewrites will be necessary, but should be incremental (rewrite chunk A this week, then chunk B next week, so that I never have to ask for 6 months to rewrite the whole system). The way, the spec is the code. The user describes a feature, I show them my interpretation, they describe another feature, etc. Very little room for miscommunication.
I think that having a filesystem store meta data is stupid. (Now that I have you in the right frame of mind for a civil discussion!)
A filesystem is the ONLY place I have to store information in most OS's (so, I'm discounting raw devices). It should have the best performance for the lowest common denominator. If you want complex meta data, use a 'data'base. Databases are designed for storing and searching highly structured data; filesystems should be for named unstructured data.
If you think that a database is over kill for most applications, then define a database for me. Is Oracle a DB? DBM? XML?.INI file? A lisp file? I would argue that every file with a know structure is a database.
We do need to know what format the data is using, so the only additional peice of information that I need that is not in current metadata is the MIME type.
Image being a manager facing peers and your boss after machines you are incharge of were deflowered. Would you rather say "but, I had the long haired unshaved Linux admin who shows up for work around noon install 'snort'", or "but, I bought a secure Linux install from HP".
It doesn't have anything to do with technologies involved. It has to do with perception, and job preservation.
Is mainframe really the right term? I thought that mainframe usually refered to a IT machine like an IBM 390. One of my client's has a "mainframe" that is only 11 400 Mz processors. The Dell 8 way MSSQL server has more processing power. (and we have verified this with benchmarks and working with IBM.)
Isn't there a differnt term for a very fast computer? Maybe something like "super computer"?
It is to me. That one thing or other I've skipped in the past always comes back to bite me.
No. Every time you haven't been bitten, you haven't notice.
Our diference in opinion might be the environments. I work in IT shops, where we help business folks answer questions. Speed is very important. If they ask a question, that we can help them answer in one day, that is good. If next month the program doesn't work and it takes us 20 minutes to fix it, that isn't a large cost (we don't have large redeployment costs). Compare this to taking a week to answer the question and no bug fix a month later. The buggy version was better/cheaper/higher profit for the company.
But, I am being challenged in a project that is planned to have a 20 year life. How do you check for a nearly infinite number of failures in a distributed complex system (many servers with many clients, some users and some batch feeds)? We use transactions and high level exception handlers; if there is a failure anywhere we roll back the transaction and report the reason to the user. This may, in rare unexpected cases, cause 5 minutes of rework for the user, but the data will not be corrupted. If users get an error message that doesn't make sense to them, they report it. It makes sense to us, because it is a stack dump, indicating the exact nature of the failure. We put in new specific checks to report a more user friendly message. We save lots of LOC (which is time and other bugs, which is money) by only focusing on exceptions that really happen, and not doubling the size of the program checking for OutOfMemory conditions at every allocation (we have never had an out of memory condition; how much money have we saved by not checking?).
Checking all the return values and catching all the right exceptions takes time, both time initially to write the checks and time later to manage the 3 fold increase in LOC. It isn't always worth it.
Many times, the applications I write have life spans of less than 2 years. Most the time I let high level exception handlers deal with application errors. Most of the time this saves me time. Once in a while I get burned by that long lived program or scope creap that I underestimated and end up with a big program that should of had the checks in place.
In some situations where I've gone into an existing program, the checks were wrong simply because there was so much code that the developers got lost and ended up with crap. I've had to strip the checks out to understand the original intent and replace all the crap with a few high level handlers; later I added back some of the checks for more common errors.
This is why I make risky purchases at Best Buy. I always ask someone (anyone who will answer) if it will work with Linux, then if it doesn't, I take it back.
Of course, Taco probably doesn't need his $60 back that bad.
Slashdot Mirror
I will if I ever find out. uhm...what are the chances I'll find out that the defenders of the law are defending the law?
Joe
From the CIA the fact book
Taliban uses a plain white flag
How will we know when the try to surrender?
Joe
I linked to the commercial product. There is also an older GPL'd version of mindterm.
I use mindterm to VNC to my home box from any machine at any client site (using just applets, there is zero footprint).
Joe
Joe
1. Is developer productivity really a problem? Most shops I've seen, bad requirements or project management are a problem. Developers code on or a head of schedule. When the lines between coder, designer, and production deisgner are blurred, productivity goes down. Read "The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity", ISBN: 0672316498 .
2. You should be coding to standards. IDE shouldn't matter. Let each developer choose one's own, but support one for the inexperienced (any IDE, they all do the same thing).
Joe
Look at the success of EGCS and GCC. That was a successful split and merge. It led to a better GCC in the end while supporting both stable and advance versions of gcc in the interim.
Joe
Yes there is. That's not how the upgrade works.
I don't know what eeprom you are talking about. You didn't buy a program, or rights to a program, nor will you find specs for the program and you will definitely void the waranty on your $150K truck by messing with your fuel map.
You upgraded the engine to 500hp and you lost the use of your 450 hp engine.
When you upgrade from WinNT to Win2000, you gained use of Win2000 and lost use of WinNT (assuming one OS per machine). Seems like the same deal to me.
Sure I hate the plan; I like getting more for my money than that, but it isn't unreasonable to license software like that.
Joe
Actually engine upgrades can be just software changes. Engines in trucks are often upgraded just by changing the fuel map. It cost more for the higher hp, and you can no longer use the old engine.
Joe
I did. I've had it for about 18 months and wouldn't trade for any other car less an S2000 or boxter.
The only problem I have is there's no place to put the gun rack.(as ken pointed out.)
offtopic in Indiana,
Joe
Wouldn't the acceleration of touching a flat surface be enough feedback? My problem with keyboards that don't have any feedback is that the signalling mechanism is not the acceleration of my finger tips, but instead some applied force that may or may not be the results of the acceleration of my finger tips.
Joe
Not yet.
OK... Please explain.
Many Unix commands have failed to test user input, leading to the potential for problems ("passwd -f", for example, used to allow things like newlines, making it trivial to add your own r00t account).
So there was a bug? passwd surely wasn't designed to trust users to not put returns in their name field.
The "all or nothing" security model of Unix leads to a whole bunch of setuid programs, which means we have to trust the users, or at least trust our ability to code against every possible thing a user might try.
But Unix isn't all or nothing. Your installation may be. My machines, have a variety of accounts with different permissions for different parts of the file systems and could have different permissions for memory usage and cpu usage.
The three-level permission model (user, group, others)is pretty weak, and there's no standard way to implement ACLs to make up for it.
True, but again why does that that imply that Unix "trusts" the users?
Think of all of the ways to crack root on a Unix box.
Again, please explain this to me. The existence of bugs is not an indication that Unix was designed to trust the user. In the case of windows, it was designed as a single user operating system. It was designed to trust the single user, for example, users can modify system files. I'm not bashing MS, I'm bashing you. I think you are wrong with your assertion that Unix trusts the user.
I'm not an ass, but I play one on the 'net.
Joe
What? Could you please explain that statement?
A user account can not modify executable, delete others data, change the configuration of the system, fill the disks or on many unixes, use all the process slots or all the memory. When does Unix trust users?
Joe
I have a blind friend with a subscription to Playboy. It is delivered in braile.
Joe
OK, I'll give you that the MFC stuff we didn't completely rewrite, just modified stuff that the screen painter built. All the rest of the projects had hand coded GUIs.
I think we have a misunderstanding though. We didn't rewrite any provided components, we used the components in code that we wrote. we used the screen painter for prototypes, but the final code was hand coded, and much smaller, faster and easier to maintain than the screen painter stuff. The handcoded app was also portable across IDEs while the screen painter stuff often isn't.
Joe
Humans have solved conflicts using violence for hundreds of thousands of years. Why should we drop that great tradition now? Why should we forget its effect through suppression in the media? Is it better for me to take your stuff by way of bribery, legal trickery or by knocking you down and taking it? I suggest that the more honest approach is through the violence of knocking you down and taking it (it may result to that anyway).
Violence is an honest viable form of conflict resolution. I suggest that people learn when it is appropriate. Given that, it is not appropriate in school, in the houses of congress, or in the board room.
Violence may be appropriate when dealing with a group that has extremely different background and values from you own. Violence is a very basic conflict resolution style that everyone from Asian, to African, to European, to American Indian, to canine, to sheep, to lion understand. I would guess that any form of life capable of memory and self preservation, even alien, would understand violence.
Violence is in itself not wrong.
Are battling robots really violent? What's the difference if we settle our conflict through dumping money into lobbiest, or dumping our money into battlee bots; in the end, the organisation with the most money wins.
Just some Sunday morning banter.
Joe
I disagree.
The customers on my last 5 GUI projects, ok all the GUI projects in my professional career, had such demanding GUI requirements that we couldn't build the app with a screen painter anyway. We built some prototypes with RAD tools, but then had to hand code MFC, OWL, AWT or Swing interfaces.
I've used VisualAge, VisualC++, VisualCafe, BorlandC++, Delphi, C++ Builder, and JBuilder and found this to b true in all of them. My most productive tools are API docs, emacs (but any complete editor like jEdit or vi would do), and a comand line compiler (debuggers and profilers are nice, but optional).
Joe
1) Then they are to busy to write requirements too. If they are to busy to explain what they want, then what can I do?
2) Actually I don't do much GUI work. A user may ask for a complex search, for instance I just did a name matching system for a reinsurance company. The users couldn't express how to search for a name, which one was a better match, how to order the results; they had been trying to write requirements for 3 years and had an unacceptably slow COBOL program that was patched together with duct tape as a result. I built a couple prototypes in SQL/JSP, explained to them how they worked, then we wrote down an english description of the algorythms for posterity. The final interface to the system is a stored procedure, but we captured the requirements using SQL and JSPs.
Users are not designers nor programmers. They don't know what is possible with systems, nor how hard certain things are to do with systems. My job is to solve information management problems; this usually results in systems changes, but sometimes only results in process changes.
Joe
Which begs the question,
What is your job?
Are you a programmer, or are you "providing solutions"?
You see, I think this whole thing with specs and software engineering is a hoax. Having the customer sign off on requirements, gives the development team an excuse point. The only way to completely spec a system is to write it. Any missing feature in the spec is a possible mistake or short for the development team. Now, if the spec writer can write down a spec that is as detailed as the final system, then why the hell didn't he/she write the system in a compilable language to start with and eliminate the chance of mistake due to translation from English to code?!
My favorite mode of developing systems, is to get high level requirements, then prototype, then prototype, then prototype, then prototype, then prototype, keeping in mind that rewrites will be necessary, but should be incremental (rewrite chunk A this week, then chunk B next week, so that I never have to ask for 6 months to rewrite the whole system). The way, the spec is the code. The user describes a feature, I show them my interpretation, they describe another feature, etc. Very little room for miscommunication.
just now ramping up on coffee...
Joe
I think that having a filesystem store meta data is stupid. (Now that I have you in the right frame of mind for a civil discussion!)
.INI file? A lisp file? I would argue that every file with a know structure is a database.
A filesystem is the ONLY place I have to store information in most OS's (so, I'm discounting raw devices). It should have the best performance for the lowest common denominator. If you want complex meta data, use a 'data'base. Databases are designed for storing and searching highly structured data; filesystems should be for named unstructured data.
If you think that a database is over kill for most applications, then define a database for me. Is Oracle a DB? DBM? XML?
We do need to know what format the data is using, so the only additional peice of information that I need that is not in current metadata is the MIME type.
Joe
$3000 is nothing for a large company.
Image being a manager facing peers and your boss after machines you are incharge of were deflowered. Would you rather say "but, I had the long haired unshaved Linux admin who shows up for work around noon install 'snort'", or "but, I bought a secure Linux install from HP".
It doesn't have anything to do with technologies involved. It has to do with perception, and job preservation.
Joe
Is mainframe really the right term? I thought that mainframe usually refered to a IT machine like an IBM 390. One of my client's has a "mainframe" that is only 11 400 Mz processors. The Dell 8 way MSSQL server has more processing power. (and we have verified this with benchmarks and working with IBM.)
Isn't there a differnt term for a very fast computer? Maybe something like "super computer"?
Joe
No. Every time you haven't been bitten, you haven't notice.
Our diference in opinion might be the environments. I work in IT shops, where we help business folks answer questions. Speed is very important. If they ask a question, that we can help them answer in one day, that is good. If next month the program doesn't work and it takes us 20 minutes to fix it, that isn't a large cost (we don't have large redeployment costs). Compare this to taking a week to answer the question and no bug fix a month later. The buggy version was better/cheaper/higher profit for the company.
But, I am being challenged in a project that is planned to have a 20 year life. How do you check for a nearly infinite number of failures in a distributed complex system (many servers with many clients, some users and some batch feeds)? We use transactions and high level exception handlers; if there is a failure anywhere we roll back the transaction and report the reason to the user. This may, in rare unexpected cases, cause 5 minutes of rework for the user, but the data will not be corrupted. If users get an error message that doesn't make sense to them, they report it. It makes sense to us, because it is a stack dump, indicating the exact nature of the failure. We put in new specific checks to report a more user friendly message. We save lots of LOC (which is time and other bugs, which is money) by only focusing on exceptions that really happen, and not doubling the size of the program checking for OutOfMemory conditions at every allocation (we have never had an out of memory condition; how much money have we saved by not checking?).
Joe
Checking all the return values and catching all the right exceptions takes time, both time initially to write the checks and time later to manage the 3 fold increase in LOC. It isn't always worth it.
Many times, the applications I write have life spans of less than 2 years. Most the time I let high level exception handlers deal with application errors. Most of the time this saves me time. Once in a while I get burned by that long lived program or scope creap that I underestimated and end up with a big program that should of had the checks in place.
In some situations where I've gone into an existing program, the checks were wrong simply because there was so much code that the developers got lost and ended up with crap. I've had to strip the checks out to understand the original intent and replace all the crap with a few high level handlers; later I added back some of the checks for more common errors.
Joe
This is why I make risky purchases at Best Buy. I always ask someone (anyone who will answer) if it will work with Linux, then if it doesn't, I take it back.
Of course, Taco probably doesn't need his $60 back that bad.
Joe