No IBM isn't doing any funny business. They actually did skip 1.2.x and have now released a 1.3, a version still officially in Early Release at Sun. Oh and a nit: it's not the compiler really, it's the jvm, associated libraries and the other tools (like javadoc). You can still use jikes (rocks!) with 1.2.x or 1.3 same was with 1.1.x because the byte codes are still the same.
Have you looked at JDE? http://sunsite.auc.dk/jde/
It rocks (=
Promotion: We're not promoting ourselves
on
Motif's Not Dead
·
· Score: 1
Fountain says, "As commercial engineers, we don't plug our own names or reputations with the software that we sell. There's nothing in X-Designer or the manual sets to say who wrote it."
Well, that's because the corporate behemoths you work for won't let you, and if they did you know you made so many compromises and cut so many corners you wouldn't want to put your name on it anyway.
But say, he does go on about X-designer and his boook. But he's not promoting himself, nope.
I gotta give props to this one. Did you use "exactly the same set of operating system, software, fonts, video drivers, printer drivers, paper and ink cartridges", or exactly how was it "rendered into rubbish" with Word95? Let's be charitable and pretend you and the customer had used the same version of Word... what fonts did you select? What colors? What screen (or printer) resolution did you write to? Was it rubbish visually or printed (Never mind WSYIWYG!)? This is the reason real professional printers have settled on things like the Pantone color matching system.
Sorry my 3000-page document writer friend, but from my perspective you're missing some elements of due diligence, and your complaint doesn't cover these omissions.
Slap an ODBC System DSN for MySQL onto your designer's boxes, let them create linked tables. It's deep in tedious details to work out and the setup is a bit error-prone, but once done it's trivial to link tables in Access.
BTW, you do know how horribly insecure the FrontPage extensions are, yes?
This isn't terribly interesting. Lots of large corporations demand and get source code escrow clauses when they buy major mission-critical software from vendors. And lots of RFPs specify adherence to industry standards.
As for the former -- I've never quite seen the point. The idea is that if the company making the software tanks you're not stuck with software you can't fix. But really, what are you gonna do? It would take an army of developers to figure out the code and find a fix. Unless you also get all the internal development docs and hire the (presumably out-of-work) programmers from the company, you're still stuck with lame-duck code.
A really actually useful form of online manual would be one that is integrated with the program functionality. Let me explain. The best IDEs these days have pretty spiffy facilities for popping up lists of methods and parameters to complete the code you just entered. Say if while writing some java I declare a String variable someResult and then later as I'm writing code I type someResult then after short pause my IDE will pop up a list of all the methods available for String. Now that is a smart start, but what if I could also twiddle a mouse button on a key and have it pop open the entire javadoc for the class or method? Now we're getting somewhere. OK, the String class is simple and familiar I don't need it, but what about, say, JMenuItem -- yes, I expect to see not only the methods it defines but also inherited.
You could extend this to other programs besides IDEs, but the point is to have allow the user to access the relevant (important point!) docs without interrupting the workflow.
That's the key that makes paper manuals beat online all the time. By the time I've had a decent manual a few weeks, it's dog-eared, highlighted, annotated with my handwriting, etc. In otherwords, I've extracted out of it the parts that meet my needs and organized them for easy recall. Until I can do that online (and I need to be able to actually see the results of my usage -- I'm a visually oriented person -- all at once when I pull out the book) I reserve online docs merely for quick reference when I already know what I want, e.g. what exactly is the order of paramaters to that function?
Quick comment re: PDF files -- they suck to read online, so you just push printing off onto the customers. Someone else will have to work out the economics of that.
Printed manuals are still necessary -- there's just something about being able to bookmark, dogear and flip back and forth around a physical book that online manuals can't duplicate.
Now, having said that, I find that probably 99% of the 'manuals' out there are useless. I know how they get made (like sausage and legislation, you don't want to know) and why they suck so bad. Half the documentation I prefer is in the form of an aftermarket book by O'Reilly or similar publisher. Most manuals focus too much on telling you merely how to invoke a certain function without saying why you'd want to do it, or how you go about actually solving a problem or accomplishing a task with the program.
In short, if all you've got is a functional reference, fine, just build a help file or javadoc and be done with it; don't expect your users to be happy with that though. If you have real manual that shows me how to go about doing real work, better print it -- and don't make me waste my company's expensive laser printer resources on it.
So N$I proposes.banc, to be managed by a group of financial interests,.shop to be managed by european domain registrants, but it will keep.com,.org and the other TLDs it currently has a monopoly on? Puhleeze. They're just trying to throw a bone to ICANN while they maneuver to keep profiting. If I were the feds I'd declare their current DNS database public property (because you and I and all the other US taxpayers already bought it) and let N$I figure out how to compete in a real capitalist setup.
Excuse me, when did/. become another forum for lazy students to post messages asking others to do their homework for them? I've been seeing these sorts of messages on Usenet since 1988 and the usual response would be: get your lazy butt to a library and when you've actually done some research come back and ask specific pertinent questions and we'll be glad to talk.
If you don't believe in any sort of management methodology, then ponder the following scenario.
A coworker, not necessarily your boss, but someone you have a cordial working relationship with, comes to you with a need for a project of some size, and asks you to help out. She wants to know how long it will take you.. a week? a month? three months? How many people besides you will she need to get working on? What skills do they need? What other resources do you need -- software, hardware, etc?, she asks. Suppose it's obvious that it won't be a one week task, but rather involved. She wants to know periodically how well you are doing. Are you behind because something you need isn't available? Are there questions about what you are doing that weren't obvious when you first took on the task?
How are you going to give her your answers? What criteria can you use to tell her accurately how long it will take, and to know as you are going along if you are going to meet that target date?
How will someone keep track of what was requested and whether or not those needs have been addressed?
If you can't give good answers, if you make mistakes in saying how long it will take or what resources you need, your coworker will be upset, you'll look bad, and life will be rotten. You don't really want to try to work 100 hours in the last 5 days before you said you'd have it finished do?
Finding ways to answer these questions are what these 'methodologies' are all about. If you can't come up to this level of expertise, you're not a good professional.
I don't approve of 'traffic laws' and I feel that things like stop signs, speed limits, one-way streets, etc, aren't worth the time it takes to learn them. Why can't we just all go as fast as we want any way we want? The good drivers just end up going slow, roundabout routes to get where they are going just because too many drivers don't know how to even steer. It's all just an excuse for bloated civil engineering companies and overpaid traffic engineers to pump the driving public for money. Creative drivers who could actually get somewhere and find new routes that others can use are held back.
Big, busy, expensive shopping malls should be scared of e-commerce, especially this time of year. My hunch is that this year will be a blockbuster for online sales, as more people say screw the crowds and the hassle of malls when you can get the same things via the web, and packaged, wrapped, and shipped directly to the recipient for you. I mean really when you are shopping for some things sure you want to see, hold and try them on, but if it's a gift then you've got the size and a pretty good idea of what it looks like, and you know the recipient can exchange it if it's not quite right.
Having said that, I think it's stupid and irresponsible for the mall owners to try to fight it. They're not going to protect their business that way. Who wants to go to a mall to buy the same cookie-cutter items from the same cookie-cutter stores that you can get online? If malls started to line up non-chain merchants who actually had unique items to sell, then people might have a reason to go back. Until then, it's point-click-buy.
humans at the same spiritual level as computers
on
Can Computers Pray?
·
· Score: 2
Nevermind all the stuff in the article about whether computers can think or believe in God or ever ponder their own existence. The interesting quote in the article is when Skeddle (who is herself a Roman Catholic) says "If I can teach a computer to do that, then, technically, a computer has reached the same spiritual level as many Catholics". She might as well have said "Jews", or "Buddhists", or "Baptists", or "Hindu". In all faiths there are people at a level where rote repetition of a formulaic summation of beliefs is the whole of their faith. Clearly, Skeddle is not at that level.
In fact her work seems to be prodding people to reflect on this kind of religious practice, "she hopes to inspire visitors to think about their own beliefs". Prayer as recitation or supplication or petitionary is only one small aspect of it.
Do you ever reach find some place without distractions -- a park or your backyard, a place where you are relaxed, comfortable, and restive but not sleepy, and then simply turn your attention to whatever is nice, and let your thoughts drift in and out, neither chasing them or pushing them away? Computers can't do that (and probably never will), but humans can, and that's the realization to take from Skeddle's work.
The most interesting line of comments that has popped up is the one associating unmaintainable code with specific languages. Notice though that the article specifically mentions Java, which is among the clearest languages today (though not without its faults).
What differentiates maintainable code from spaghetti code is not just whether or not the syntax of the language allows for obfuscated code, or if all of the variables and functions are documented and clearly named, if some code conventions are followed or if it has been run through a beautifier, but whether the code was written with a clearly thought-out and documented design.
If the programmer has actually taken the time to think about the data structures, the algorithms, and the classes(or program sections if you aren't using an OO language), then the code becomes truly understandable. This is not to say that you can then ignore good programming techniques -- they are still necessary -- but that documenting every function, variable and data structure in a program that is otherwise a crufty mess is pretty much a waste of effort. Try it sometime -- look at the source code for Perl, and have the perlguts man page and Gisle Aas's wonderful illustrated guide to Perl's internals handy, and you'll get the idea.
I've seen code in lots of languages that would be considered 'maintainable' if all it took was strictly following a convention, but in fact was frustratingly difficult to maintain because the programmer didn't have a clear design for the system.
[project scientist Eric] "Korpella says the project will not release its source code, and the program is being rewritten to make it harder to alter."
Now, all the arguments about needing consistent results, and not being able to generate units fast enough to keep up (but then why can't they optimize the splitters on the server, too??) and what could be characterized as a mistake by the project's race-horse results postings goes out the window with this statement. Project programmers are *actively* working against the people the need to help them. The lingering doubts I had about running the client on my systems have been iced -- I won't run it any more.
"All the major vendors are hedging their bets with Linux," Giga's Quandt says. Linux needs to become more scalable and be able to handle symmetric multiprocessing, she says. (emphasis added).
Seriously, though, if Jikes and IBM's jdk for Linux are good indicators, their support for Linux should ensure it a long and robust future.
I learned about jikes a few months ago at my (NT-based) employer and was pleased to discover that it also ran on my RedHat Linux box at home, and yes, it IS fast. So fast I had to check to make sure that it actually compiled the files. The difference is that sun's javac is implemented mostly in java itself, while jikes is C++ (owch)
At the same time I discovered IBM's JDK for Linux , and I prefer it over Blackdown. The IBM jdk requires native threads, so if that's an issue get the Blackdown green threads jdk. (It's at 1.1.8, I hope their 1.2 shows up soon).
For you Visual Age fans, IBM has a Linux version available for preview now also.
IBM may be be the best Java tools company out there.
Item 10 of the Agreements section of the Registry Agreement says "NSI shall not be entitled to claim any intellectual property rights in data in the registry supplied by or through registrars other than NSI". Note that other than NSI clause. Its clear that NSI will still be able to claim copyright on its database.
I can say a lot of good things about Visual Age, the debugger is great, the source browser is very comprehensive, and I used it on one large project for almost eight months. However, I would not recommend it for Java development.
The generated Java for the visual development is about the worst of the IDEs -- very convoluted and voluminous. We were working with EJB and JDBC, and the integration of those tools, at least for the moment, is awkward and arduous to use.
Finally, I have to say that I come down on the side of not liking the versioning system. Once you understand open editions and releases it can work fine, but the CVS-style checkout/diff/checkin is more usable and flexible.
If they'd left even a couple of low-priority machines up and running and they stayed up the whole time, they coulda said "Linux: The O/S that can withstand a Hurricane". It's a no-lose bet either, because if the storm took them out no one could blame the O/S.
I found this nifty 1998 Annual Report at the USPS web site. They delivered 198 billion pieces of mail in 1998, 3.7% more than 1997. Most of the mail was First Class.
Slashdot Mirror
Huh? Keep up!
v /linux_faq.html
http://www-4.ibm.com/software/ad/vajava/
"VisualAge for Java runs on AIX, Linux, OS/2, OS/390, Windows 95 & Windows 98 and Windows NT."
http://www-4.ibm.com/software/webservers/appser
No IBM isn't doing any funny business. They actually did skip 1.2.x and have now released a 1.3, a version still officially in Early Release at Sun. Oh and a nit: it's not the compiler really, it's the jvm, associated libraries and the other tools (like javadoc). You can still use jikes (rocks!) with 1.2.x or 1.3 same was with 1.1.x because the byte codes are still the same.
Have you looked at JDE?
http://sunsite.auc.dk/jde/
It rocks (=
Fountain says, "As commercial engineers, we don't plug our own names or reputations with the software that we sell. There's nothing in X-Designer or the manual sets to say who wrote it."
Well, that's because the corporate behemoths you work for won't let you, and if they did you know you made so many compromises and cut so many corners you wouldn't want to put your name on it anyway.
But say, he does go on about X-designer and his boook. But he's not promoting himself, nope.
I gotta give props to this one. Did you use "exactly the same set of operating system, software, fonts, video drivers, printer drivers, paper and ink cartridges", or exactly how was it "rendered into rubbish" with Word95? Let's be charitable and pretend you and the customer had used the same version of Word ... what fonts did you select? What colors? What screen (or printer) resolution did you write to? Was it rubbish visually or printed (Never mind WSYIWYG!)? This is the reason real professional printers have settled on things like the Pantone color matching system.
Sorry my 3000-page document writer friend, but from my perspective you're missing some elements of due diligence, and your complaint doesn't cover these omissions.
Slap an ODBC System DSN for MySQL onto your designer's boxes, let them create linked tables.
It's deep in tedious details to work out and the setup is a bit error-prone, but once done it's trivial to link tables in Access.
BTW, you do know how horribly insecure the FrontPage extensions are, yes?
This isn't terribly interesting. Lots of large corporations demand and get source code escrow clauses when they buy major mission-critical software from vendors. And lots of RFPs specify adherence to industry standards.
As for the former -- I've never quite seen the point. The idea is that if the company making the software tanks you're not stuck with software you can't fix. But really, what are you gonna do? It would take an army of developers to figure out the code and find a fix. Unless you also get all the internal development docs and hire the (presumably out-of-work) programmers from the company, you're still stuck with lame-duck code.
A really actually useful form of online manual would be one that is integrated with the program functionality. Let me explain. The best IDEs these days have pretty spiffy facilities for popping up lists of methods and parameters to complete the code you just entered. Say if while writing some java I declare a String variable someResult and then later as I'm writing code I type someResult then after short pause my IDE will pop up a list of all the methods available for String. Now that is a smart start, but what if I could also twiddle a mouse button on a key and have it pop open the entire javadoc for the class or method? Now we're getting somewhere. OK, the String class is simple and familiar I don't need it, but what about, say, JMenuItem -- yes, I expect to see not only the methods it defines but also inherited.
You could extend this to other programs besides IDEs, but the point is to have allow the user to access the relevant (important point!) docs without interrupting the workflow.
That's the key that makes paper manuals beat online all the time. By the time I've had a decent manual a few weeks, it's dog-eared, highlighted, annotated with my handwriting, etc. In otherwords, I've extracted out of it the parts that meet my needs and organized them for easy recall. Until I can do that online (and I need to be able to actually see the results of my usage -- I'm a visually oriented person -- all at once when I pull out the book) I reserve online docs merely for quick reference when I already know what I want, e.g. what exactly is the order of paramaters to that function?
Quick comment re: PDF files -- they suck to read online, so you just push printing off onto the customers. Someone else will have to work out the economics of that.
Printed manuals are still necessary -- there's just something about being able to bookmark, dogear and flip back and forth around a physical book that online manuals can't duplicate.
Now, having said that, I find that probably 99% of the 'manuals' out there are useless. I know how they get made (like sausage and legislation, you don't want to know) and why they suck so bad. Half the documentation I prefer is in the form of an aftermarket book by O'Reilly or similar publisher. Most manuals focus too much on telling you merely how to invoke a certain function without saying why you'd want to do it, or how you go about actually solving a problem or accomplishing a task with the program.
In short, if all you've got is a functional reference, fine, just build a help file or javadoc and be done with it; don't expect your users to be happy with that though. If you have real manual that shows me how to go about doing real work, better print it -- and don't make me waste my company's expensive laser printer resources on it.
So N$I proposes .banc, to be managed by a group of financial interests, .shop to be managed by european domain registrants, but it will keep .com, .org and the other TLDs it currently has a monopoly on? Puhleeze. They're just trying to throw a bone to ICANN while they maneuver to keep profiting. If I were the feds I'd declare their current DNS database public property (because you and I and all the other US taxpayers already bought it) and let N$I figure out how to compete in a real capitalist setup.
Excuse me, when did /. become another forum for lazy students to post messages asking others to do their homework for them? I've been seeing these sorts of messages on Usenet since 1988 and the usual response would be: get your lazy butt to a library and when you've actually done some research come back and ask specific pertinent questions and we'll be glad to talk.
If you don't believe in any sort of management methodology, then ponder the following scenario.
.. a week? a month? three months? How many people besides you will she need to get working on? What skills do they need? What other resources do you need -- software, hardware, etc?, she asks. Suppose it's obvious that it won't be a one week task, but rather involved. She wants to know periodically how well you are doing. Are you behind because something you need isn't available? Are there questions about what you are doing that weren't obvious when you first took on the task?
A coworker, not necessarily your boss, but someone you have a cordial working relationship with, comes to you with a need for a project of some size, and asks you to help out. She wants to know how long it will take you
How are you going to give her your answers? What criteria can you use to tell her accurately how long it will take, and to know as you are going along if you are going to meet that target date?
How will someone keep track of what was requested and whether or not those needs have been addressed?
If you can't give good answers, if you make mistakes in saying how long it will take or what resources you need, your coworker will be upset, you'll look bad, and life will be rotten. You don't really want to try to work 100 hours in the last 5 days before you said you'd have it finished do?
Finding ways to answer these questions are what these 'methodologies' are all about. If you can't come up to this level of expertise, you're not a good professional.
I don't approve of 'traffic laws' and I feel that things like stop signs, speed limits, one-way streets, etc, aren't worth the time it takes to learn them. Why can't we just all go as fast as we want any way we want? The good drivers just end up going slow, roundabout routes to get where they are going just because too many drivers don't know how to even steer. It's all just an excuse for bloated civil engineering companies and overpaid traffic engineers to pump the driving public for money. Creative drivers who could actually get somewhere and find new routes that others can use are held back.
The original Adventure.
Having said that, I think it's stupid and irresponsible for the mall owners to try to fight it. They're not going to protect their business that way. Who wants to go to a mall to buy the same cookie-cutter items from the same cookie-cutter stores that you can get online? If malls started to line up non-chain merchants who actually had unique items to sell, then people might have a reason to go back. Until then, it's point-click-buy.
In fact her work seems to be prodding people to reflect on this kind of religious practice, "she hopes to inspire visitors to think about their own beliefs". Prayer as recitation or supplication or petitionary is only one small aspect of it.
Do you ever reach find some place without distractions -- a park or your backyard, a place where you are relaxed, comfortable, and restive but not sleepy, and then simply turn your attention to whatever is nice, and let your thoughts drift in and out, neither chasing them or pushing them away? Computers can't do that (and probably never will), but humans can, and that's the realization to take from Skeddle's work.
What differentiates maintainable code from spaghetti code is not just whether or not the syntax of the language allows for obfuscated code, or if all of the variables and functions are documented and clearly named, if some code conventions are followed or if it has been run through a beautifier, but whether the code was written with a clearly thought-out and documented design.
If the programmer has actually taken the time to think about the data structures, the algorithms, and the classes(or program sections if you aren't using an OO language), then the code becomes truly understandable. This is not to say that you can then ignore good programming techniques -- they are still necessary -- but that documenting every function, variable and data structure in a program that is otherwise a crufty mess is pretty much a waste of effort. Try it sometime -- look at the source code for Perl, and have the perlguts man page and Gisle Aas's wonderful illustrated guide to Perl's internals handy, and you'll get the idea.
I've seen code in lots of languages that would be considered 'maintainable' if all it took was strictly following a convention, but in fact was frustratingly difficult to maintain because the programmer didn't have a clear design for the system.
[project scientist Eric] "Korpella says the project will not release its source code, and the program is being rewritten to make it harder to alter."
Now, all the arguments about needing consistent results, and not being able to generate units fast enough to keep up (but then why can't they optimize the splitters on the server, too??) and what could be characterized as a mistake by the project's race-horse results postings goes out the window with this statement. Project programmers are *actively* working against the people the need to help them. The lingering doubts I had about running the client on my systems have been iced -- I won't run it any more.
Seriously, though, if Jikes and IBM's jdk for Linux are good indicators, their support for Linux should ensure it a long and robust future.
I learned about jikes a few months ago at my (NT-based) employer and was pleased to discover that it also ran on my RedHat Linux box at home, and yes, it IS fast. So fast I had to check to make sure that it actually compiled the files. The difference is that sun's javac is implemented mostly in java itself, while jikes is C++ (owch)
At the same time I discovered IBM's JDK for Linux , and I prefer it over Blackdown. The IBM jdk requires native threads, so if that's an issue get the Blackdown green threads jdk. (It's at 1.1.8, I hope their 1.2 shows up soon).
For you Visual Age fans, IBM has a Linux version available for preview now also.
IBM may be be the best Java tools company out there.
Item 10 of the Agreements section of the Registry Agreement says "NSI shall not be entitled to claim any intellectual property rights in data in the registry supplied by or through registrars other than NSI". Note that other than NSI clause. Its clear that NSI will still be able to claim copyright on its database.
I can say a lot of good things about Visual Age, the debugger is great, the source browser is very comprehensive, and I used it on one large project for almost eight months. However, I would not recommend it for Java development.
The generated Java for the visual development is about the worst of the IDEs -- very convoluted and voluminous. We were working with EJB and JDBC, and the integration of those tools, at least for the moment, is awkward and arduous to use.
Finally, I have to say that I come down on the side of not liking the versioning system. Once you understand open editions and releases it can work fine, but the CVS-style checkout/diff/checkin is more usable and flexible.
If they'd left even a couple of low-priority machines up and running and they stayed up the whole time, they coulda said "Linux: The O/S that can withstand a Hurricane". It's a no-lose bet either, because if the storm took them out no one could blame the O/S.
I found this nifty 1998 Annual Report at the USPS web site. They delivered 198 billion pieces of mail in 1998, 3.7% more than 1997. Most of the mail was First Class.