Make the filtering less of an on/off choice and more of a fuzzy choice, preferably with a user-selectable threshold.
And is it any coincidence that that is starting to sound more and more like/.?
What would make for a better solution? (Score: 5, Pornographic)
The best filter is your own two eyes (Score: 2, Political)
Really a neural net? (Score: -1, Educational)
The only rational assumption can be that this is a trial run to ensure that they can land an asteroid *directly* on target next time, when they choose to wipe Slough off the face of this green and pleasant land.
Heck 99% of the fun would be trying to build one of these.
Yes. Unfortunately, programs like this are made for the fun of the watching audience, who pay for the programs, and that's 1% of the fun. Why watch a handful of robots wandering around an arena trying to locate each other and failing when you can see Hypnodisc rip something to pieces?
(Yes, I'd find it interesting too. But only if we got to see source code...)
I mean, Sun had every right to come back in the same way... And it was pretty cool... Mostly, it made MS look stupid, very quickly.
Far be it from me to defend Microsoft in any way, but that, of course, was the whole point. Make Microsoft look stupid, while carefully skirting around the inadequacies (and there are inadequacies, as even a hardened Java-zealot like myself would admit) in Sun's model. This is FUD countering FUD, not Sun showing us all how rational and logical they can be.
Of course, it probably counts for something that Sun's FUD is a lot more entertaining and convincing than Microsoft's, and certainly I believe it's closer to the truth. In the same way that Berlin is closer to my flat than Los Angeles.:^)
I tend to find PINE preferable to most graphical e-mail clients anyway, of course. It's fast and easy to use, I can access it from anywhere, and it isn't prone to all these nasty e-mail viruses. And if I want to view that ugly 'enhanced' content that only spammers seem to send, a tap of the return key loads it into Lynx.:^)
However, why should I as a user type Configuration instead of etc?
You wouldn't. You would type Co<TAB>.
Of course, the simple solution is surely just to set up symlinks to these directories. That way you don't have to type them correctly more than once. It's easy enough to do the same for application names.
On an almost related note, does anyone else remember an IBM mainframe application called DWIM, standing for Do What I Mean (not what I say)? It did a great job of detecting typos and suggesting what you might actually have wanted to type. I'm sure someone could come up with a shell that worked on similar principles...
It is a pitty that your web site is written for analysts and wankers because I would really like to use it to learn more about the Java platform particulary in relation to e-commerce/web-applications.
It's not a pity for analysts (and wankers) who want exactly the sort of information you're complaining about, presented in the style that you're complaining about. Developers, I'm assuming, are expected to have enough intelligence to track down the Java Developer Connection, where they would find a clear and concise introduction to EJBs. Or, if they wanted something a lot more in depth, they'd take a look at the EJB specification, which thanks to the good design of Sun's site is merely three clicks away from the front page of the Java site.
The page that you complain about (http://java.sun.com/j2ee/overview.html) is a relatively good non-technical overview of J2EE, and doesn't pretend to be anything else. However, having found it, a quick click on 'documentation', followed by 'tutorials' takes you to yet another developer-level introduction to J2EE which seems to fit your requirements a lot better.
The only problem I see with the information provided is that it's not great for impatient developers who can't be bothered to look round the site. Perhaps if you'd spent more time reading the navigation options than 'mindless marketing drivel' then you'd have found what you wanted more quickly.
Incidentally, I always find that you get better results when complaining about issues like this if you at least run your mail through a spell-checker first. ('pitty', 'particulary', 'nosence' etc.) It's always helpful to make a good impression when what you have to say is inherently negative.
Nethack was never my thing, but as soon as I can get my homebrew DC devkit working properly I'm planning on putting together a quick port of ZAngband...
To be honest, it's a little more like the PSX Net Yaroze scheme, which made cut down development kits available to the general public and educational establishments. In that case it was an official product, supported by Sony. In this case it's unofficial, and Sega's anti-piracy measures may make it more difficult in the future.
Rumours have been around for a while of a PS2 Yaroze, though there's nothing confirmed on that front. Console hackers are allegedly starting to make progress on PS2 programs as well (though still at the level of 'Hello World'...)
Either way it's cool, and as soon as I get some spare time I'll be digging out a suitable cable and starting to put together some DC programs...
Exactly so. In fact, it's possible to build a much more reliable and maintainable solution by trying to avoid having code in the JSP at all where possible. Three elements that go towards achieving this goal are:
Servlet controllers
Put control code into a servlet, which then uses a JSP (or a series of JSPs) to provide the presentation side of things. The servlet can then trivially carry out pre- and post-processing on the request, as well as carrying out the actual logic behind the operation (or more likely delegating this to EJBs...)
JavaBeans
There's a reason they put that <jsp:usebean> tag in there, you know. If you wrap the data to be displayed in a JavaBean, then you don't even need any Java experience to access it - just use the property get and set actions. Avoid <jsp:setproperty property="*"> like the plague, though.;^)
Custom tags
Take that final step towards separating style from content by using well-designed custom tags. This way you can hide the Java implementation from people whose sole concern is the HTML view.
But of course. I thought it was a well-known fact that Santa's a Linux zealot. Why else would he enter houses through the chimney simply in order to avoid using the Windows?
Your examples really aren't relevant in this case. Firstly, it's actually easier for an automated process to generate text from RTF than the other way round, since the RTF document must include additional mark-up. Your second example is even further from the mark - you obviously can't create the required PNG file from a text file (or not easily), so it's not a good storage mechanism. However, given a well-defined XML document structure it becomes trivial to use XSL to transform it into a LaTeX document representing the same data, or an HTML document, or some other custom format. And XML is intended to be used for this very purpose.
I've actually been through this process at work - we shifted from using a proprietary file format for our invoices to using an XML representation which can then be used to generate a range of views, from HTML for viewing on the intranet to LaTeX for printing and sending to customers. It's a great solution, and it means that we're not tied down to using LaTeX - at a later stage we can change to another document format, and all that needs to be changed is the XSL document for all of our invoices to be available in the new format. If the documents were originally stored in LaTeX format, we would not be able to do this - a change in the output format would require all the invoices to be re-entered (as was the case when we switched *from* the first proprietary format) or a large amount of custom code to be written.
Define 'as good a job as'. Mozilla does a better job than IE5 at conforming to most HTML and releated standards (HTML, you remember - that thing which browsers are supposed to render, yes?)
If your definition of compatibility is 'doing everything like IE5 does', then of course Mozilla doesn't do everything as well as IE5. Then again, with this model IE5 has a bit of an unfair advantage. Yes, there's a certain influence on Mozilla to ape IE5 in every respect, right down to supporting the same 'features' (Not bugs. Definitely not bugs...), but if that's the case then it's always destined to play catch-up. The real aim has to be to support the standards laid down by the W3C (which Mozilla already does better than IE5 in most respects, before a release-level version) and provide ease of use and a good set of features - which you may or may not agree that it does - to me in most (but by no means all) cases it already outpaces IE5 on this front as well.
Nice try. I run Mozilla on a range of operating systems (not being a single-system zealot like yourself). The version I keep most up to date is installed on a Windows 2000 partition - my laptop boots with equal ease to Win2K, Win95 and Linux. On *all* platforms Netscape 6 is inferior to the Mozilla nightly builds at or around the launch date. The fact remains that the NS6 release came before the browser was ready for prime-time, and the feature freeze came even before that. Hence the reliability problems that a lot of people have had with NS6. Note that I have no problem at all with Mozilla, and that I use it in preference to Internet Explorer under Windows. That doesn't make a buggy, advertising-ridden release with a fatally flawed installer any more excusable.
The difference is in the purpose of the markup - XML is (generally, with a good design) syntactic markup. LaTeX is entirely structural markup, specifying not *what* a particular element is, but how it is to be displayed. As a result, XML is easier to tailor to a particular application's needs - from the XML document you can trivially create the equivalent LaTeX document. The same does not hold true the other way round.
Mozilla should be trying to be so good that you start seeing "Mozilla 6 needed" on web sites
You miss the entire point of the Mozilla project with this statement. The websites shouldn't say "Mozilla 6 needed". They should say "HTML 4.0 required" - it's all about standards, not individual applications. Backwards compatibility is less of an issue because of this - if the aim is to make sure that standards work correctly, then breaking those standards in order to ensure backwards compatibility is a bad thing, not a laudable goal.
The problem is that the Netscape 6 release is the worst possible publicity that Mozilla could receive - it's buggy, and as the original poster suggests it shows a complete disregard for quality issues. While Mozilla is a perfectly competent browser (for those who are willing to accept it as a *pre-release* piece of software) and has replaced IE on my machine entirely, a lot of people are only seeing the NS release, which is giving them a bad impression, and thus reflecting negatively on Mozilla, and on open-source applications in general.
Yes, NS have done a good thing in supporting the open-source approach to Mozilla. But they have done *nobody* (including themselves) any favours by conceding to the pressure and releasing a product for the scrutiny of the general public before it's ready.
AIUI, milestones represent branches from the trunk - development on the trunk continues as code approaches a milestone release, but it doesn't make sense to just finalise the code and release it as-is, warts and all.
A further point - not only will Mozilla work better in the future because the hardware baseline will be set higher, but also because optimisation is not currently a priority on the project - following most sensible programming guidelines the emphasis is on elegant code, and optimisation will come later. I fully expect the release version of Mozilla (or 1.0, at least) to be a lot easier on system resources in general - once the application is feature complete it's possible to sort out performance issues.
Agreed. LaTeX is bound to be a frequently suggested alternative, but IMHO it's the wrong answer: XML has been designed for exactly this purpose, and it fits your needs perfectly.
XML can easily (dare I suggest it, trivially) be transformed into XML documents - in fact, this is the approach my current employers take for a number of types of business documents - XML is the format for representing the data, and LaTeX or HTML or whatever can become the format used for making this available to the user - XSL transformations allow us to take a language-independent set of data and translate it into a document in a suitable format.
If you want true independence from propietrary data formats (and open source applications can have data formats that are just as restrictive as closed source applications to most users) then XML is the only real choice right now - a well defined XML document should be readable even *without* a parser, and with a well-defined DTD and a series of appropriate XSL files, you can select your own viewer application. What could possibly be better? Certainly not Word, StarOffice, LaTeX or any of the other competitors in this arena.
Slashdot Mirror
What would make for a better solution? (Score: 5, Pornographic)
The best filter is your own two eyes (Score: 2, Political)
Really a neural net? (Score: -1, Educational)
Conker's Bad Fur Day is about as far from mature as it's possible to get, of course. :^)
If you want mature games on N64, look at Goldeneye, Resident Evil 2, Sin and Punishment etc.
Besides, the whole argument is pretty specious anyway: the best games appeal to *all* ages, and Nintendo make some of the best games out there.
Because silver bullets are way too expensive...
The only rational assumption can be that this is a trial run to ensure that they can land an asteroid *directly* on target next time, when they choose to wipe Slough off the face of this green and pleasant land.
Yes. Unfortunately, programs like this are made for the fun of the watching audience, who pay for the programs, and that's 1% of the fun. Why watch a handful of robots wandering around an arena trying to locate each other and failing when you can see Hypnodisc rip something to pieces?
(Yes, I'd find it interesting too. But only if we got to see source code...)
Presumably either RiscBSD or ARMLinux will run on this with a 'little' reworking.
Far be it from me to defend Microsoft in any way, but that, of course, was the whole point. Make Microsoft look stupid, while carefully skirting around the inadequacies (and there are inadequacies, as even a hardened Java-zealot like myself would admit) in Sun's model. This is FUD countering FUD, not Sun showing us all how rational and logical they can be.
Of course, it probably counts for something that Sun's FUD is a lot more entertaining and convincing than Microsoft's, and certainly I believe it's closer to the truth. In the same way that Berlin is closer to my flat than Los Angeles. :^)
I tend to find PINE preferable to most graphical e-mail clients anyway, of course. It's fast and easy to use, I can access it from anywhere, and it isn't prone to all these nasty e-mail viruses. And if I want to view that ugly 'enhanced' content that only spammers seem to send, a tap of the return key loads it into Lynx. :^)
10PRINT"Hello, world!"
:^)
18 bytes. Runs under RISC OS perfectly.
Do I win a prize?
You wouldn't. You would type Co<TAB>.
Of course, the simple solution is surely just to set up symlinks to these directories. That way you don't have to type them correctly more than once. It's easy enough to do the same for application names.
On an almost related note, does anyone else remember an IBM mainframe application called DWIM, standing for Do What I Mean (not what I say)? It did a great job of detecting typos and suggesting what you might actually have wanted to type. I'm sure someone could come up with a shell that worked on similar principles...
It's not a pity for analysts (and wankers) who want exactly the sort of information you're complaining about, presented in the style that you're complaining about. Developers, I'm assuming, are expected to have enough intelligence to track down the Java Developer Connection, where they would find a clear and concise introduction to EJBs. Or, if they wanted something a lot more in depth, they'd take a look at the EJB specification, which thanks to the good design of Sun's site is merely three clicks away from the front page of the Java site.
The page that you complain about (http://java.sun.com/j2ee/overview.html) is a relatively good non-technical overview of J2EE, and doesn't pretend to be anything else. However, having found it, a quick click on 'documentation', followed by 'tutorials' takes you to yet another developer-level introduction to J2EE which seems to fit your requirements a lot better.
The only problem I see with the information provided is that it's not great for impatient developers who can't be bothered to look round the site. Perhaps if you'd spent more time reading the navigation options than 'mindless marketing drivel' then you'd have found what you wanted more quickly.
Incidentally, I always find that you get better results when complaining about issues like this if you at least run your mail through a spell-checker first. ('pitty', 'particulary', 'nosence' etc.) It's always helpful to make a good impression when what you have to say is inherently negative.
Nethack was never my thing, but as soon as I can get my homebrew DC devkit working properly I'm planning on putting together a quick port of ZAngband...
To be honest, it's a little more like the PSX Net Yaroze scheme, which made cut down development kits available to the general public and educational establishments. In that case it was an official product, supported by Sony. In this case it's unofficial, and Sega's anti-piracy measures may make it more difficult in the future.
Rumours have been around for a while of a PS2 Yaroze, though there's nothing confirmed on that front. Console hackers are allegedly starting to make progress on PS2 programs as well (though still at the level of 'Hello World'...)
Either way it's cool, and as soon as I get some spare time I'll be digging out a suitable cable and starting to put together some DC programs...
Exactly so. In fact, it's possible to build a much more reliable and maintainable solution by trying to avoid having code in the JSP at all where possible. Three elements that go towards achieving this goal are:
Put control code into a servlet, which then uses a JSP (or a series of JSPs) to provide the presentation side of things. The servlet can then trivially carry out pre- and post-processing on the request, as well as carrying out the actual logic behind the operation (or more likely delegating this to EJBs...)
There's a reason they put that <jsp:usebean> tag in there, you know. If you wrap the data to be displayed in a JavaBean, then you don't even need any Java experience to access it - just use the property get and set actions. Avoid <jsp:setproperty property="*"> like the plague, though.
Take that final step towards separating style from content by using well-designed custom tags. This way you can hide the Java implementation from people whose sole concern is the HTML view.
But of course. I thought it was a well-known fact that Santa's a Linux zealot. Why else would he enter houses through the chimney simply in order to avoid using the Windows?
Your examples really aren't relevant in this case. Firstly, it's actually easier for an automated process to generate text from RTF than the other way round, since the RTF document must include additional mark-up. Your second example is even further from the mark - you obviously can't create the required PNG file from a text file (or not easily), so it's not a good storage mechanism. However, given a well-defined XML document structure it becomes trivial to use XSL to transform it into a LaTeX document representing the same data, or an HTML document, or some other custom format. And XML is intended to be used for this very purpose.
I've actually been through this process at work - we shifted from using a proprietary file format for our invoices to using an XML representation which can then be used to generate a range of views, from HTML for viewing on the intranet to LaTeX for printing and sending to customers. It's a great solution, and it means that we're not tied down to using LaTeX - at a later stage we can change to another document format, and all that needs to be changed is the XSL document for all of our invoices to be available in the new format. If the documents were originally stored in LaTeX format, we would not be able to do this - a change in the output format would require all the invoices to be re-entered (as was the case when we switched *from* the first proprietary format) or a large amount of custom code to be written.
Define 'as good a job as'. Mozilla does a better job than IE5 at conforming to most HTML and releated standards (HTML, you remember - that thing which browsers are supposed to render, yes?)
If your definition of compatibility is 'doing everything like IE5 does', then of course Mozilla doesn't do everything as well as IE5. Then again, with this model IE5 has a bit of an unfair advantage. Yes, there's a certain influence on Mozilla to ape IE5 in every respect, right down to supporting the same 'features' (Not bugs. Definitely not bugs...), but if that's the case then it's always destined to play catch-up. The real aim has to be to support the standards laid down by the W3C (which Mozilla already does better than IE5 in most respects, before a release-level version) and provide ease of use and a good set of features - which you may or may not agree that it does - to me in most (but by no means all) cases it already outpaces IE5 on this front as well.
Nice try. I run Mozilla on a range of operating systems (not being a single-system zealot like yourself). The version I keep most up to date is installed on a Windows 2000 partition - my laptop boots with equal ease to Win2K, Win95 and Linux. On *all* platforms Netscape 6 is inferior to the Mozilla nightly builds at or around the launch date. The fact remains that the NS6 release came before the browser was ready for prime-time, and the feature freeze came even before that. Hence the reliability problems that a lot of people have had with NS6. Note that I have no problem at all with Mozilla, and that I use it in preference to Internet Explorer under Windows. That doesn't make a buggy, advertising-ridden release with a fatally flawed installer any more excusable.
The difference is in the purpose of the markup - XML is (generally, with a good design) syntactic markup. LaTeX is entirely structural markup, specifying not *what* a particular element is, but how it is to be displayed. As a result, XML is easier to tailor to a particular application's needs - from the XML document you can trivially create the equivalent LaTeX document. The same does not hold true the other way round.
You miss the entire point of the Mozilla project with this statement. The websites shouldn't say "Mozilla 6 needed". They should say "HTML 4.0 required" - it's all about standards, not individual applications. Backwards compatibility is less of an issue because of this - if the aim is to make sure that standards work correctly, then breaking those standards in order to ensure backwards compatibility is a bad thing, not a laudable goal.
The problem is that the Netscape 6 release is the worst possible publicity that Mozilla could receive - it's buggy, and as the original poster suggests it shows a complete disregard for quality issues. While Mozilla is a perfectly competent browser (for those who are willing to accept it as a *pre-release* piece of software) and has replaced IE on my machine entirely, a lot of people are only seeing the NS release, which is giving them a bad impression, and thus reflecting negatively on Mozilla, and on open-source applications in general.
Yes, NS have done a good thing in supporting the open-source approach to Mozilla. But they have done *nobody* (including themselves) any favours by conceding to the pressure and releasing a product for the scrutiny of the general public before it's ready.
AIUI, milestones represent branches from the trunk - development on the trunk continues as code approaches a milestone release, but it doesn't make sense to just finalise the code and release it as-is, warts and all.
A further point - not only will Mozilla work better in the future because the hardware baseline will be set higher, but also because optimisation is not currently a priority on the project - following most sensible programming guidelines the emphasis is on elegant code, and optimisation will come later. I fully expect the release version of Mozilla (or 1.0, at least) to be a lot easier on system resources in general - once the application is feature complete it's possible to sort out performance issues.
Agreed. LaTeX is bound to be a frequently suggested alternative, but IMHO it's the wrong answer: XML has been designed for exactly this purpose, and it fits your needs perfectly.
XML can easily (dare I suggest it, trivially) be transformed into XML documents - in fact, this is the approach my current employers take for a number of types of business documents - XML is the format for representing the data, and LaTeX or HTML or whatever can become the format used for making this available to the user - XSL transformations allow us to take a language-independent set of data and translate it into a document in a suitable format.
If you want true independence from propietrary data formats (and open source applications can have data formats that are just as restrictive as closed source applications to most users) then XML is the only real choice right now - a well defined XML document should be readable even *without* a parser, and with a well-defined DTD and a series of appropriate XSL files, you can select your own viewer application. What could possibly be better? Certainly not Word, StarOffice, LaTeX or any of the other competitors in this arena.