Or, rather than thinly disguised duckspeak, it could simply be that Management is still stuck in an 1890's industry mentaility where the longer you run the machines and the harder you run them, the more output you get and the sooner you get it.
Human creative endeavor, however, doesn't work like a hamburger grinder. It develops at its own rate, and not infrequently, any attempt to accelerate that rate will actually cause it to jam up. Rather like the old joke that if you pull on the paper as it comes out of the printer, it will print faster.
Alchemy? Not even that much science. Say Astrology.
What good does it do knowing how people produce buggy code when the #1 reason for the buggy code is underqualified people being pushed under unrealistic conditions?
I, too thought "wired" as in "we apply electric shocks when they screw up". I'm sure at least 1 Dilbert cartoon already anticipated this.
... And on the other side, systems architects and engineers would need to step their game up...mandatory continuing education, etc.
Here's part of the problem. Long, long ago, there was this thing called "Certified Data Professional" Locally, some people tried to make a big deal of it, and I even knew 1 or 2 people who took the exam. In fact, I have the study guide.
But it didn't work then, and that was back when just knowing COBOL and basic I/O was good for the majority of the jobs. Unless, of course, you worked exclusively with FORTRAN, PL/1, RPG or Assembler. And then there's which OS to be proficient in JCL for. Or which brand of hardware: IBM, Univac, Burroughs, or one of the other "7 dwarfs".
The field has exploded since then. We have batch and interactive, multiple flavors of GUI systems, mobile devices, various and sundry web platforms - and I can't even count just the ones for Java, even before Ruby on Rails, Django, and on and on. We have scientific computing, AI, business processes, multiple database options, LDAP, virtualization, containers, clouds, Big Data - something new every week.
There's NO TIME to make a one-size-fits-all professional competence exam based on continuous learning. We're all learning different things, and we can't slow down because we're already at the point where we need to learn something else.
I have no solution, other than to notice that the cram-and-barf exam/cert solution is obviously worthless. The only certs I've seen that I'll credit are less on details and more on things like whether you can bring up a general-purpose Linux (or Windows) server in 4 hours.
I'd be inclined to simply make it a "web of trust" thing where to be certified, you needed a certain number of votes from people already in the club. Meaning that they're willing to risk their reputations that you're decently competent. But that, too has its flaws. Good Ole Boys get free passes and unwashed twerps with bad social skills get left out. And bad social skills are almost a badge of honor in IT!
Wait, wait. We're talking about different things here. In a dev house, as you call it, there's going to be different people with different jobs. The developer writes code and comments it, then there's a content writer who does the documentation. Also these tend to be for-profit organizations which don't do much OFSS (if any at all).
What a quaint 20th-Century concept.
We laid all those people off because we're "Lean". The developer's native language is Malayam and the documentation department was dissovled.
That's why I have a lot of respect for the "sloggers". The people who can work through the details, get them down and verify that they got them right.
Unfortunately, in commercial products these days, the documentation people likely got laid off when their duties were transferred to the developer along with the sysadmin, DBA and network administrator jobs.
In FOSS products, the big problem is that even if you get volunteers to do the docs, the people who know what the code is doing may not be talking to the people who write the docs. Or worse, have dumped the initial docs on them. From before all the major changes were made.
I've never seen JavaDocs that add anything to the source. It's okay if you need a list of methods or parameters, but usage is lacking.
Documentation needs to have several *working* examples (not snippets) from a simple Hello World to more sophisticated but still commonly used. A single example that illustrates every imaginable feature and use case is rarely helpful.
Blame Sun.
JavaDocs have the capability of being used to good advantage, but in actual use, they're really just a loose aggregation of API call specs. And for more recent javadocs, they're often even useless for that. One major product's javadocs are more a pointless muttering about internal implementation details than actual usage information. I've never seen a major library that could actually be properly used based on the information in the Javadocs alone.
Sun did mitigate the uselessness of JavaDocs by supplying tutorials, but the two weren't tied together in a meaningful way.
That works for grunts. But I am God. The last resort, and as such, empowered to directly touch and modify production, exempt from firewall and access rules. Not to mention major parts of the infrastructure. Whatver it takes to keep production going, even if it's only on 3 tires and a flat.
I try very hard to keep stuff like that switched off except in cases of dire need, but when we're in full crisis mode one "oops" moment can be very expensive. So that little extra bit of protection I get from having the critical definitions in the server and not in the webapp is geatly to be desired.
That stuff isn't kept in web.xml. The web.xml file is part of the binary and therefore if it was, my one-binary-for-all rule couldn't be followed.
I think you might have missed what I was really saying, since I wasn't quite clear.
I don't mean 1 build process for all. I mean that the exact same byte-for-byte binary is used for all. Because that's where the disasters generally happened. Accidentally dump the production binary into a test server and POW! The production database just got scrambled. And no, the DBA couldn't prevent it, because we're in the middle of a disaster recovery and the normal rules had to be relaxed to get back online ASAP. Or whatever.
Injection of environmental dependencies (which database, what security system, live-versus-simulated emailers) is quite possible for Java apps. It's done via the "server-dependent deployment descriptor", which has different names, formats, and contents depending on what brand and version of server you are using. After all, it's server-dependent.
There's also a "server-independent deployment descriptor". Most people know it as the WEB-INF/web.xml file.
In eclipse all that information is stored in the.classpath.xml file (not sure if it starts with a `dotâ)
If you're lucky. Then there's dynamic classloading. and other "clever" tricks.
You bring up another point, though. Doing separate builds for development, test, and production systems is also a no-no with me. I've seen what happens when the wrong build ends up in the wrong place.
My stuff is 1 build fits all. The test/production-dependent stuff is injected in as part of the deployment process, not embedded in the modules.
Sorry, but your claim that you can not build a Java project that originated in Eclipse, without having the same layout is not only nonsense it is bullshit.
First of all I assume you mean directory layout _above_ package level?
Then please explain me why a command line like: javac -sourcepath YOURSOURCE:FOLDERS:HERE -classpath JAR:FILES:AND:CLASSDIRECTORIES:HERE does not work on your system!
Building a project is more than just where you keep the source code.
My problems with project portability came from the fact that people would keep external libraries and data directories in various random locations on their filesystems and have those locations hard-coded into the project. Or worse yet, into their IDE configuration. Meaning no actual "project" file contained the critical resources. You essentiall had to be running a clone of the developer's machine.
It's not a language issue. I've had problems as bad or worse in C and other languages.
In fact, one of the things that gave me the most relief on that score was using Maven, since it's designed for projects to be self-contained with externally-injected dependencies rather that having a "Service Locator" model where you had to know where to find the external stuff.
Re:Tool complexity leads to learning the tool
on
Getting Back To Coding
·
· Score: 3, Insightful
The idea that the IDE becomes _necessary_ to access the code is spot on. We do code security reviews as part of our work, and, for example, most Java projects cannot be reviewed anymore without the Eclipse set-up that was used to produce them. That is pure insanity!
If I was in charge, I'd march around the whole office and generously apply boot to fundaments.
I got burned REALLY, REALLY bad in my Visual Studio days because it was difficult-to-impossible to get a makefile out of it, depending on which release you were working with, and once the IDE had been replaced with a newer version of the IDE, some projects couldn't make 1-line emergency fixes without either massive project rework or re-installing the old version of the IDE.
Moving to Java wasn't much better, because although the IDE in question wasn't Eclipse, projects couldn't be built without the IDE plus the same directory setup as the original developer.
Because of the expense and lost time at critical moments, I have a very strict policy that and project under my control must be buildable using a well-supported non-gui build system that can be set up and used in under 10 minutes with no external user system dependencies or other tweaking. In other words, Ant, Maven, or an equivalent product.
With this technology, a machine may actually be able to create a copy of itself that does not need any other parts added, nor will it need human assembly.
Well, you didn't expect Skynet to rely on humans to fabricate all those Terminators, did you?
You mean you've set up a large scale factory dedicated to the production of patented air and cunningly disguised it as a garden? You monster! Just think of the hard working companies who you're putting out of business, clearly you must be stopped. For America!
It's far worse than that. Trees don't just "produce" air. They need input! American Industry has worked long and hard to produce all that CO2 and they deserve to be compensated!
Also, the Monsanto auditors will be by shortly to ensure that each and every one of those trees is properly licensed.
What kind of Commie Talk is that? This is the 21st Century and Capitalism and the Free Market are Triumphant.
Everything is property and Must Be Monetized.
In fact, I'm sure that any day now someone will patent each and every individual air molecule on the planet and charge us royalties for breathing them.
We're already well on the way to doing that for water.
OK. I live in a city where the city itself maintained a special number for the sole purpose of accepting complaints about Comcast.
But the shenanigans reported are neither new nor unique to Comcast. Lots of companies have "Customer Retention Departments" whose sole purpose is to make cancelling as miserable an experience as possible.
I don't like seeking after misery, so I avoided opening a Comcast account to begin with. They may own almost all the market, but there are still less obnoxious alternatives.
Slashdot Mirror
Or, rather than thinly disguised duckspeak, it could simply be that Management is still stuck in an 1890's industry mentaility where the longer you run the machines and the harder you run them, the more output you get and the sooner you get it.
Human creative endeavor, however, doesn't work like a hamburger grinder. It develops at its own rate, and not infrequently, any attempt to accelerate that rate will actually cause it to jam up. Rather like the old joke that if you pull on the paper as it comes out of the printer, it will print faster.
Alchemy? Not even that much science. Say Astrology.
What good does it do knowing how people produce buggy code when the #1 reason for the buggy code is underqualified people being pushed under unrealistic conditions?
I, too thought "wired" as in "we apply electric shocks when they screw up". I'm sure at least 1 Dilbert cartoon already anticipated this.
I could care less. But not much less.
This chip would be overkill, an old 4004 would be sufficient.
A block of wood would be sufficient. A 4004 would be overkill.
I always automate.
Then I get laid off because "I'm not doing anything."
People who don't automate, and get paid by the hour to do the same thing over and over again stay on.
The wisdom of the propets is written on the subway walls.
And tenement halls.
That's a pretty ridiculous circular argument you have there.
It's called accepting the inevitable and attempting to minimize the damage.
... And on the other side, systems architects and engineers would need to step their game up...mandatory continuing education, etc.
Here's part of the problem. Long, long ago, there was this thing called "Certified Data Professional" Locally, some people tried to make a big deal of it, and I even knew 1 or 2 people who took the exam. In fact, I have the study guide.
But it didn't work then, and that was back when just knowing COBOL and basic I/O was good for the majority of the jobs. Unless, of course, you worked exclusively with FORTRAN, PL/1, RPG or Assembler. And then there's which OS to be proficient in JCL for. Or which brand of hardware: IBM, Univac, Burroughs, or one of the other "7 dwarfs".
The field has exploded since then. We have batch and interactive, multiple flavors of GUI systems, mobile devices, various and sundry web platforms - and I can't even count just the ones for Java, even before Ruby on Rails, Django, and on and on. We have scientific computing, AI, business processes, multiple database options, LDAP, virtualization, containers, clouds, Big Data - something new every week.
There's NO TIME to make a one-size-fits-all professional competence exam based on continuous learning. We're all learning different things, and we can't slow down because we're already at the point where we need to learn something else.
I have no solution, other than to notice that the cram-and-barf exam/cert solution is obviously worthless. The only certs I've seen that I'll credit are less on details and more on things like whether you can bring up a general-purpose Linux (or Windows) server in 4 hours.
I'd be inclined to simply make it a "web of trust" thing where to be certified, you needed a certain number of votes from people already in the club. Meaning that they're willing to risk their reputations that you're decently competent. But that, too has its flaws. Good Ole Boys get free passes and unwashed twerps with bad social skills get left out. And bad social skills are almost a badge of honor in IT!
Wait, wait. We're talking about different things here.
In a dev house, as you call it, there's going to be different people with different jobs. The developer writes code and comments it, then there's a content writer who does the documentation. Also these tend to be for-profit organizations which don't do much OFSS (if any at all).
What a quaint 20th-Century concept.
We laid all those people off because we're "Lean". The developer's native language is Malayam and the documentation department was dissovled.
A lot of things aren't fun or glamorous.
That's why I have a lot of respect for the "sloggers". The people who can work through the details, get them down and verify that they got them right.
Unfortunately, in commercial products these days, the documentation people likely got laid off when their duties were transferred to the developer along with the sysadmin, DBA and network administrator jobs.
In FOSS products, the big problem is that even if you get volunteers to do the docs, the people who know what the code is doing may not be talking to the people who write the docs. Or worse, have dumped the initial docs on them. From before all the major changes were made.
I've never seen JavaDocs that add anything to the source. It's okay if you need a list of methods or parameters, but usage is lacking.
Documentation needs to have several *working* examples (not snippets) from a simple Hello World to more sophisticated but still commonly used. A single example that illustrates every imaginable feature and use case is rarely helpful.
Blame Sun.
JavaDocs have the capability of being used to good advantage, but in actual use, they're really just a loose aggregation of API call specs. And for more recent javadocs, they're often even useless for that. One major product's javadocs are more a pointless muttering about internal implementation details than actual usage information. I've never seen a major library that could actually be properly used based on the information in the Javadocs alone.
Sun did mitigate the uselessness of JavaDocs by supplying tutorials, but the two weren't tied together in a meaningful way.
That works for grunts. But I am God. The last resort, and as such, empowered to directly touch and modify production, exempt from firewall and access rules. Not to mention major parts of the infrastructure. Whatver it takes to keep production going, even if it's only on 3 tires and a flat.
I try very hard to keep stuff like that switched off except in cases of dire need, but when we're in full crisis mode one "oops" moment can be very expensive. So that little extra bit of protection I get from having the critical definitions in the server and not in the webapp is geatly to be desired.
That stuff isn't kept in web.xml. The web.xml file is part of the binary and therefore if it was, my one-binary-for-all rule couldn't be followed.
I think you might have missed what I was really saying, since I wasn't quite clear.
I don't mean 1 build process for all. I mean that the exact same byte-for-byte binary is used for all. Because that's where the disasters generally happened. Accidentally dump the production binary into a test server and POW! The production database just got scrambled. And no, the DBA couldn't prevent it, because we're in the middle of a disaster recovery and the normal rules had to be relaxed to get back online ASAP. Or whatever.
Injection of environmental dependencies (which database, what security system, live-versus-simulated emailers) is quite possible for Java apps. It's done via the "server-dependent deployment descriptor", which has different names, formats, and contents depending on what brand and version of server you are using. After all, it's server-dependent.
There's also a "server-independent deployment descriptor". Most people know it as the WEB-INF/web.xml file.
In eclipse all that information is stored in the .classpath.xml file (not sure if it starts with a `dotâ)
If you're lucky. Then there's dynamic classloading. and other "clever" tricks.
You bring up another point, though. Doing separate builds for development, test, and production systems is also a no-no with me. I've seen what happens when the wrong build ends up in the wrong place.
My stuff is 1 build fits all. The test/production-dependent stuff is injected in as part of the deployment process, not embedded in the modules.
Sorry, but your claim that you can not build a Java project that originated in Eclipse, without having the same layout is not only nonsense it is bullshit.
First of all I assume you mean directory layout _above_ package level?
Then please explain me why a command line like: javac -sourcepath YOURSOURCE:FOLDERS:HERE -classpath JAR:FILES:AND:CLASSDIRECTORIES:HERE does not work on your system!
Building a project is more than just where you keep the source code.
My problems with project portability came from the fact that people would keep external libraries and data directories in various random locations on their filesystems and have those locations hard-coded into the project. Or worse yet, into their IDE configuration. Meaning no actual "project" file contained the critical resources. You essentiall had to be running a clone of the developer's machine.
It's not a language issue. I've had problems as bad or worse in C and other languages.
In fact, one of the things that gave me the most relief on that score was using Maven, since it's designed for projects to be self-contained with externally-injected dependencies rather that having a "Service Locator" model where you had to know where to find the external stuff.
The idea that the IDE becomes _necessary_ to access the code is spot on. We do code security reviews as part of our work, and, for example, most Java projects cannot be reviewed anymore without the Eclipse set-up that was used to produce them. That is pure insanity!
If I was in charge, I'd march around the whole office and generously apply boot to fundaments.
I got burned REALLY, REALLY bad in my Visual Studio days because it was difficult-to-impossible to get a makefile out of it, depending on which release you were working with, and once the IDE had been replaced with a newer version of the IDE, some projects couldn't make 1-line emergency fixes without either massive project rework or re-installing the old version of the IDE.
Moving to Java wasn't much better, because although the IDE in question wasn't Eclipse, projects couldn't be built without the IDE plus the same directory setup as the original developer.
Because of the expense and lost time at critical moments, I have a very strict policy that and project under my control must be buildable using a well-supported non-gui build system that can be set up and used in under 10 minutes with no external user system dependencies or other tweaking. In other words, Ant, Maven, or an equivalent product.
Unless I'm mistaken, one of the few remaining samples of smallpox is located in Atlanta.
Once it was a hallmark of wealth to be fat. Today, it's kinda the opposite. Times change.
Yeah. You hire a personal trainer.
The first thing that came to mind was "Won't eddy currents bypass the filter and reduce its effectiveness?
Then I saw the pictures.
They cheated and used fans with flat/concave shrouds. Most of the cheap chinese fans around here are more lens-shaped (convex).
Traditionally, having someone else do stuff for you was an indicator of how wealthy you were.
All very well to have the manor, but without a proper set of servants, where are you?
Shine one's own shoes and show up at the Opera with bootblack on one's hands? How terribly low-class!
Curiously enough, my home air purifier consists of an HEPA filter strapped in front of a fan. In a box.
With this technology, a machine may actually be able to create a copy of itself that does not need any other parts added, nor will it need human assembly.
Well, you didn't expect Skynet to rely on humans to fabricate all those Terminators, did you?
You mean you've set up a large scale factory dedicated to the production of patented air and cunningly disguised it as a garden? You monster! Just think of the hard working companies who you're putting out of business, clearly you must be stopped. For America!
It's far worse than that. Trees don't just "produce" air. They need input! American Industry has worked long and hard to produce all that CO2 and they deserve to be compensated!
Also, the Monsanto auditors will be by shortly to ensure that each and every one of those trees is properly licensed.
What kind of Commie Talk is that? This is the 21st Century and Capitalism and the Free Market are Triumphant.
Everything is property and Must Be Monetized.
In fact, I'm sure that any day now someone will patent each and every individual air molecule on the planet and charge us royalties for breathing them.
We're already well on the way to doing that for water.
OK. I live in a city where the city itself maintained a special number for the sole purpose of accepting complaints about Comcast.
But the shenanigans reported are neither new nor unique to Comcast. Lots of companies have "Customer Retention Departments" whose sole purpose is to make cancelling as miserable an experience as possible.
I don't like seeking after misery, so I avoided opening a Comcast account to begin with. They may own almost all the market, but there are still less obnoxious alternatives.