So Outlook express will go away. I'm not going to shed many tears over it.
Still, how long will it take before the users who download Outlook Express stop hunting around on the net and installing it? I still have people reaching around in their directory (or desk drawer) of important stuff installing horribly old versions of Netscape 4.x (where x is a very small number) so they can use it's email reader.
Most of the users are bound to the one product they chose when they REALLY NEEDED it to work. During that crisis period, they put in the time and effort to get THAT product to work, and that's the extent of their software understanding. Microsoft may try to wash it's hands of Outlook Express, but I imagine a day (ten years from now)
Hey, could you look at my home computer? It seems I have an email problem.
Really? I thought that email was totally autoconfiguring on your system!
Yea, but for some reason, Outlook Express, says it can't connect to my Internet.
Imagine yourself computing along, and getting that annoying power outage. You see water flowing back into the case via the air pump hose. Desperately you reach for the power cord nested deep behind the back of the computer, but no! Before you can pull the plug, you friendly local power company manages to restore power in record time! BZZT!
Can't read the article, so if he does have a backflow valve, good for him!
This is going to ruffle a few feathers, but really I do mean well...
--- Begin Education Rant ---
If your only goal is to pass tests and get a good grade, and gather up some knowledge, then you would make a fine apprentice.
Unfortunately, if you desire the "really know" the stuff, and no amount of schooling is going to get you there, unless the schooling is directed toward education.
Education is what you were supposed to go to school to get, but all of the pressures placed on schools to get you ready for the workforce weakens the cirricula to the point where many educational programs are just "white-collar" apprenticeships. If you want education, you will have to challenge yourself to get one. Nobody can give you "insight" in a field as that's the gift you give yourself after you have had enough exposure to that field's challenged.
For some it's very little exposure to gain insight, for others it's a whole lot, and for many, they claim they have it far too early (and dangerously may have a very flawed understanding). Education is a work in progress, and by protecting your GPA, you make make yourself more "marketable" (only for that first job), but you won't necessairly make yourself any more educated.
If you're worried about the GPA, then take the class. You will put much more work into the subject than 80% to 90% of your classmates, and you will learn FAR more than they will. But if you only take the classes you know you can pass, you will leave with 4 years of your life wasted because you are only marginally better than when you entered.
Calculus is INCREDIBLY important, and from a philosopical point of view it might even be dangerous.:)
Imagine a field of mathematics that explicitly has at it's underpinnings the hypothesis that as you break up a line into smaller segments, eventually if you make each segment have no length, they still all add up to a lenght.
Philosopy aside, it's an INCREDIBLE tool for particular applications. Need the area of a sphere, no problem. A cone, still no problem. An oddly shaped object that looks like a art-deco running shoe? BIG problem, that is unless you use calculus.
I agree that you could go about understanding math the way you have, but it's like trying to reverse-engineer the ideas of the founding mathematicians. Often, it is easier to just read their works directly. Here's a few names, should you need somewhere to get started.
I haven't read all of them, but they are on my list. Some deal directly with mathematics, and others with aspects of physics, but remember that the two fields have been spurring each other forward over the centuries.
For those that are actually in classes, doing ALL of the problems in the textbook (not just the assigned ones) will nearly gurantee you pass far above your classmates and have a firm grasp on how to solve the problem at hand.
Although I get a good laugh out of your byline, I have to wonder...
How much is their stock inflated by dragging in customers they normally wouldn't have? For example, my local telco wasn't "able" to provide me with ADSL unless I managed to change my phone service and my long-distance service. They won't make any money from the long distance service (1 call in 4 years), but I remeber what a fight it was (in the media) to even have a choice of local providers.
Mabye I could have fought it, and mabye I couldn't. But it was definately portrayed as a "you HAVE to use us to use OUR ADSL" situation.
Re:Why is Open Source so RACIST?
on
Eclipse in Action
·
· Score: -1, Offtopic
Are you kidding? Developers hardly associate with other developers, even on the same project.
Re:Are they reinventing the wheel ?
on
Eclipse in Action
·
· Score: 4, Funny
As I don my flame-proof suit.
"No, it's an extension of vi!"
WARNING: The above message was intended to be humorous, the humor impaired should press the little X button in the top right hand corner to prevent confusion.
OpenOffice is an X applicaton, but it does not create "X" objects in the traditional sense.
Before JAVA 1.2 (AKA JAVA 2) the AWT toolkit used the underlying operating system's GUI environment to draw buttons, menus, and whatever to the screen. Eventually SUN got a lot of egg on it's face because the GUI environments for all of their supported platforms had bugs in them, and people would associate these bugs with JAVA, so JAVA seem to have a buggy GUI.
SUN's solution was to create SWING which draws all of the GUI components directly instead of passing them on to the underlying window subsystem. SUN's decision (back then) hinged on their inability to get the maintainers of the various platform-dependant GUI environments to fix GUI related bugs.
You may not know about the environment (aka polotics) that existed back then, but JAVA was being badmouthed as a "write once, debug everywhere" platform due to this situation. And one of the most uncooperative GUI groups they had to deal with was their competitor, Microsoft, who was trying to sink the JAVA language with a "MS Java" alternative.
So, in reality, yes, OpenOffice is an X application, but the button you are pressing is NOT an X object. So you cannot change it's look and feel using X, KDE, Gnome, or anything other than JAVA's published methods.
Considering that it usually takes months to get a book on the shelves after the last word was written, I hope we can excuse the inclusion of old software and old reference to "upcoming items" which have already been released.
Remember, there's marketing, proofreading, typesetting, printing, binding, warehousing, distribution, and shelving which all have to be done before you invest your time and money by buying it and reading it. Technology continually speeds up some of these steps, but it will never be automatic. It's just the price you pay for a printed book.
The web can provide you with the latest info, distro, whatever; however, it is a rare website which pours as much effort into one of its articles as a good author / editor / publisher is willing to put into a book.
Please respond to the OpenOffice team with your problems. Often they are already fixed, and updating your installation is all you need. However, you cannot expect them to fix something you never tell them about.
I like open source software. I like how it works. I like how I work when I'm using it. But using open source software is a bit of a social contract. Either pay back the developers with bug reports, or it shouldn't be important enough to complain about (to anyone).
Sometimes the bugs won't get fixed. Now THATS when you should REALLY complain!
Last I checked OpenOffice wasn't a kde application. This means that it does not use any of the kde configuration tools, nor will it be manipulated by any KDE specific configuration methods.
I believe that OpenOffice is a java application, but I'm not going to waste too much time in verifying this. If it is JAVA, then it probably uses Swing which can be customized, but not nearly as much as say, Motif. Swing uses a pluggable look and feel, but if you wish to "roll your own" PLAF, you'd better be in it for the long haul.
I have often heard the complaint that all of the GUI applications should be "themable" using the same methods (or APIs) so every app will look similar on someone's desktop. However, for this to work, we would all have to rely on only one distributor of this API which sort of defeats the whole purpose of providing different "choices" to end users and software developers.
I have a hard time understanding why it should be a primary business objective to make sure all of my windows are green to match my frog-loving background, but I won't deny that someone will want it, and they should get it.
I don't think it's sad. After all, I have a secret light socket which I've been developing without the use of standards committees.
If you wish to gain access to this light socket, you need to give me the electrical cord of the appliance of your choice, and I will route it through the 2x2x2 iron safe that protects my newly created intellectual property. If you throw tons of cash at me, I might allow you to look at the plug directly, but only on the condition that I can prevent you from telling anyone else about it (and I'm going to change it completely next year too!)
Of course, my plug's tolerances are incredible, so if you attempt to access it incorrectly, your lamps may flicker or totally self destruct. But hey, that's your problem! You should have paid me to use the "secret" plug which I won't show you.
I imagine that my competitors will have a fully working substitute interface in about 30 years. But I've still got the upper hand, hehehe.... See I've made the plug not work properly, so they'll actually have to include ALL of the BUGS for "full functionality"!
Ok, so it's a bit offtopic, but I think you're quote should be properly attributed to Sir Arthur Conan Doyle, as he used it extensively in his character Sherlock Holmes.
Not that software development is any less a mystery to those outside of coding circles.
I wish I have a vew mod points to throw your way. The comments about your local newspaper's site are quite apt. However...
I believe the onstar to be a "viable" product, because it produces important information (street directions) which is guranteed to be accessable by someone owning the system. The advertising aware "restruant" feature may not be even-handed, but it is guranteed to be available.
But if I buy a "enhanced browsing" cell phone, I have no gurantee that it will work with any given poster. I have to first find a "enhanced browsing enabled" poster. So I have a feature which is not guranteed to be available. After pointing this thing to a dozen posters and getting nothing, I will stop trying the feature until I see a poster indicating that it contains this "enhanced feature". Meanwhile many people will see this "enhanced" poster, but not have the cell phone / whatever to access the goods.
If I buy a new cell phone before I encounter this poster, or even after I encounter only a few of these posters, I will probably decide to get a cheaper model which doesn't provide this "feature" my experience tells me is "almost useless". If others lacking the "enhanced" cell phone fail to get a sense of "missing out" on the experience, they will probably not buy in either. Of course, how do you "miss out" on an experience you have no awareness of? Advertising!
Products like this need excellent planning at roll-out, or the budgets dry up well before the revenue rolls in.
Well, I can't really experiment on one of these devices without breaking the vacuum, so no, I cannot directly confirm my view.
However, the contrasting opinion on why this works included an explanation of the air molecules on the white side shifting to the dark side due to low pressure on the dark side. If this is supposed to be the main reason for rotation, the the logic is flawed.
If the black side of the vane is hotter, and it transfers it's heat to the air directly contacting it, the that air will be hotter. Hot air (before it expands) has a higer pressure than it would before it was heated. Expanding air is not picky about what it pushes, hence the black vane appears to provide the "thrust".
An explanation conatining air on the white side of the vane seeking out the low pressure on the dark side of the vane doesn't make much sense to me, because, if there was low pressure on the dark side of the vane, then the low pressure would seemingly equalize by sucking the vane (and everything else) toward it.
Low pressure on the dark side of the vane seems wrong, unless you can explain how the low pressure is selective about only sucking the air around the vane while actually propting the vane to rotate away from the low pressure.
A compairson of vanes to aircraft wings makes the alternate explanation oboviously wrong (but doesn't make my explanation any more "right") Aircraft are lifted because the wing experiences low pressure on the TOP side of the wing (in compairson to the bottom side of the wing)
Assuming the technology can be implemented without problems (which it should), I still see tons of launch problems.
Unless this can be launched in a big way, it won't be very useful. Users with enhanced cell phones / other viewers, will be frustrated with a lack of content to browse, and much content will go unviewd by people lacking compatible browsers. Even if the people have usable browsers, and the content is available, most of the population won't bother to learn how to use it. I mean, how many people are just getting around to setting their VCR/DVD clocks? (Not the slashdot crowd, of course! But they are more than us)
Plus, how many people are willing to look like a geek in public pointing their cell phone at a poster, while mashing on some "browse" button, because the bottom of the poster states "Hypertag Enabled, Point Here for More Information!"? If this is to succeed, that's what many, many people need to do.
If you mean a pratical working example, odds are you are already using one. MVC is used heavily in well designed (NOT VB) gui applications like window managers, or GUI toolkits. Unfortunatly Visual Basic teaches the world not to design the application, but rather to draw the interface, and then hang code off of it's events. As a result you typically see the handler methods grow in size and complexity as they have to handle the model, view and controller.
For a mini-demo, let me present the following pseudo-code examples.
Request Handler (Control):
doGet(request, response) {
User u = User.lookup(request.getParam(username));
if (!u.hasPermission(request.getParam(query))) {// forward the connection to a jsp "request denied page"
}
Book b = Book.getBook(request.getParam(Title), request.getParam(Author));
request.setAttribute("BookInfo", b);
RequestDispatcher dispatcher = servletContext.getRequestDispatcher("/JSP/BookDisp lay.jsp");
dispatcher.forward(request, response);
}
The Book object (Model):
{
static void initialize() {
connect to database / etc to get book info.
}
static Book getBook(title, author) {
return the correct book;
}
String getTitle() {
return title;
}
(and many other getProperty methods)
}
the JSP page (View):
{... html code here...
jsp:usebean id="BookInfo" class="model.Book" scope="request... more html...
jsp:getProperty name="BookInfo" property="title"... more html...
jsp:getProperty name="BookInfo" property="author"... more html
}
It's a very simple example, and as such, does very little, but hopefully you can gather the idea of MVC seperation from my quickly constructed (aka shoddy) example.
Try "Bitter Java" by Manning. I'm not saying that it has anything much better than a call to return to MVC, but it's written well, and it's code seems to be sanity-checked.
I checked out the "Problem with JSP" site, and many of the issues it raises are present in "Bitter Java". I don't agree that the JAVA bean tags are fundamentally worse (or better) than the alternative syntax templating provides, but the last example (manipulating the title) is a cop-out.
If the title is supposed to change in the header and footer, then the controller (which manipulates both the model AND the view) should pass the info along in a Java Bean. That would allow the header and footer to grab the title without the fear of "missing a semicolon" using the normal JSP bean extensions.
Some of their work is interesting, and I like the bit about loops, but a lot of it implys that they are complaining about badly coded JSP pages. I mean, a 30K JSP page? Only if you don't have any MVC, and inline the JSP at every opportunity.
After enought tags accumulate, you need to standardize on them, which usually results in a bit of bickering over what tag does X better.
Eventually all of your JSP pages become "Tag platform X" specific, requiring anyone else using the "enhanced" JSP environment to be careful about the introduction of new tags. As a final blow new developers will have no idea that tag FOO exists, and will have to be brought up to speed on your flavor of JSP.
All in all, tags seem to be the tool of those who would rework JSP into thier own sub-language. Encapsulating the data is the way to go, and Java Bean encapsulation seems to offer the best of both worlds. It provides a simplified tag interface for interaction with the Java Beans, and it prevents the development of various new "tag-based" JSP variants.
The real power of MVC here is the seperation of concerns. Seperation of concerns makes the code much easier to maintain and debug, but first let's address each of the elements.
Model - The things your computer udpates, or the actual representation of whatever your program is manipulating. For example, a public (book) library system would have Books as part of their model. Books could be checked in, checked out, they have a title, one or more authors, etc.
Controller - The code responsible for updating the model, and updating the view. For example, the controller decides what the view may or may not show, what parts of the model are manipulated, and what data from the model is exposed by the view.
View - The code responsible for providing the interface to a user. For example, a view might be a web page, a text based interface, a GUI based interface, or anything else that takes the user's input and provides them with a "View" of the model's data.
By seperating the concerns, maintenance is simplified. Is the book's title wrong? It's a problem in the model. Did someone ask for something but receive something else? You have bug in the controller. Are the Book titles filling out the Author slots, well you have a problem in your View.
The problem is in most "slap it together quick, so we can roll it out the door" code, all of these concerns are placed in the same module, which creates the following problem.
If you intend to only change one aspect of the program, you run the real risk of chaning all aspects of the program.
For example, you wanted to rearrange the GUI to make it more useable, but heaven help you, because now the database connection is acting funky. How much do you know as a GUI designer about database connections? Do you want to debug it? Who knew that your connection was stored with an int counter using the ubiquitous variable i? With MVC, you can safely avoid the most common pitfalls.
Although I won't comment on the usefullness of this book, I imagine that you can come up with at least 10 reasons books haven't disappeared with the invention of the web.
Let's face it, there's a lot of books which aren't much better than a collection of dispartate web pages. But how hard is it to recogonize that books and the web both provide information but to different markets due to the ways in which they can be used?
Slashdot Mirror
So Outlook express will go away. I'm not going to shed many tears over it.
Still, how long will it take before the users who download Outlook Express stop hunting around on the net and installing it? I still have people reaching around in their directory (or desk drawer) of important stuff installing horribly old versions of Netscape 4.x (where x is a very small number) so they can use it's email reader.
Most of the users are bound to the one product they chose when they REALLY NEEDED it to work. During that crisis period, they put in the time and effort to get THAT product to work, and that's the extent of their software understanding. Microsoft may try to wash it's hands of Outlook Express, but I imagine a day (ten years from now)
Hey, could you look at my home computer? It seems I have an email problem.
Really? I thought that email was totally autoconfiguring on your system!
Yea, but for some reason, Outlook Express, says it can't connect to my Internet.
Arrrggghhh....
Imagine yourself computing along, and getting that annoying power outage. You see water flowing back into the case via the air pump hose. Desperately you reach for the power cord nested deep behind the back of the computer, but no! Before you can pull the plug, you friendly local power company manages to restore power in record time! BZZT!
Can't read the article, so if he does have a backflow valve, good for him!
This is going to ruffle a few feathers, but really I do mean well...
--- Begin Education Rant ---
If your only goal is to pass tests and get a good grade, and gather up some knowledge, then you would make a fine apprentice.
Unfortunately, if you desire the "really know" the stuff, and no amount of schooling is going to get you there, unless the schooling is directed toward education.
Education is what you were supposed to go to school to get, but all of the pressures placed on schools to get you ready for the workforce weakens the cirricula to the point where many educational programs are just "white-collar" apprenticeships. If you want education, you will have to challenge yourself to get one. Nobody can give you "insight" in a field as that's the gift you give yourself after you have had enough exposure to that field's challenged.
For some it's very little exposure to gain insight, for others it's a whole lot, and for many, they claim they have it far too early (and dangerously may have a very flawed understanding). Education is a work in progress, and by protecting your GPA, you make make yourself more "marketable" (only for that first job), but you won't necessairly make yourself any more educated.
If you're worried about the GPA, then take the class. You will put much more work into the subject than 80% to 90% of your classmates, and you will learn FAR more than they will. But if you only take the classes you know you can pass, you will leave with 4 years of your life wasted because you are only marginally better than when you entered.
--- End Education Rant ---
Calculus is INCREDIBLY important, and from a philosopical point of view it might even be dangerous. :)
Imagine a field of mathematics that explicitly has at it's underpinnings the hypothesis that as you break up a line into smaller segments, eventually if you make each segment have no length, they still all add up to a lenght.
Philosopy aside, it's an INCREDIBLE tool for particular applications. Need the area of a sphere, no problem. A cone, still no problem. An oddly shaped object that looks like a art-deco running shoe? BIG problem, that is unless you use calculus.
I agree that you could go about understanding math the way you have, but it's like trying to reverse-engineer the ideas of the founding mathematicians. Often, it is easier to just read their works directly. Here's a few names, should you need somewhere to get started.
Euclid. Archimedes, Apollonius of Perga
Nicomachus, Gilbert, Galileo, Descartes
Pascal, Newton, Spinoza, Huygens
Lavoisier, Fourier, Faraday
I haven't read all of them, but they are on my list. Some deal directly with mathematics, and others with aspects of physics, but remember that the two fields have been spurring each other forward over the centuries.
For those that are actually in classes, doing ALL of the problems in the textbook (not just the assigned ones) will nearly gurantee you pass far above your classmates and have a firm grasp on how to solve the problem at hand.
More like +$30 for DSL service.
Yes, it WAS +$60, but prices keep dropping every day.
Although I get a good laugh out of your byline, I have to wonder...
How much is their stock inflated by dragging in customers they normally wouldn't have? For example, my local telco wasn't "able" to provide me with ADSL unless I managed to change my phone service and my long-distance service. They won't make any money from the long distance service (1 call in 4 years), but I remeber what a fight it was (in the media) to even have a choice of local providers.
Mabye I could have fought it, and mabye I couldn't. But it was definately portrayed as a "you HAVE to use us to use OUR ADSL" situation.
Are you kidding? Developers hardly associate with other developers, even on the same project.
As I don my flame-proof suit.
"No, it's an extension of vi!"
WARNING: The above message was intended to be humorous, the humor impaired should press the little X button in the top right hand corner to prevent confusion.
Personally, I never believe anything until I check it against my lucky, biorythmic, astrological, mood watch.
(Very loose memory adaption from an old Steve Martin standup routine).
OpenOffice is an X applicaton, but it does not create "X" objects in the traditional sense.
Before JAVA 1.2 (AKA JAVA 2) the AWT toolkit used the underlying operating system's GUI environment to draw buttons, menus, and whatever to the screen. Eventually SUN got a lot of egg on it's face because the GUI environments for all of their supported platforms had bugs in them, and people would associate these bugs with JAVA, so JAVA seem to have a buggy GUI.
SUN's solution was to create SWING which draws all of the GUI components directly instead of passing them on to the underlying window subsystem. SUN's decision (back then) hinged on their inability to get the maintainers of the various platform-dependant GUI environments to fix GUI related bugs.
You may not know about the environment (aka polotics) that existed back then, but JAVA was being badmouthed as a "write once, debug everywhere" platform due to this situation. And one of the most uncooperative GUI groups they had to deal with was their competitor, Microsoft, who was trying to sink the JAVA language with a "MS Java" alternative.
So, in reality, yes, OpenOffice is an X application, but the button you are pressing is NOT an X object. So you cannot change it's look and feel using X, KDE, Gnome, or anything other than JAVA's published methods.
Considering that it usually takes months to get a book on the shelves after the last word was written, I hope we can excuse the inclusion of old software and old reference to "upcoming items" which have already been released.
Remember, there's marketing, proofreading, typesetting, printing, binding, warehousing,
distribution, and shelving which all have to be done before you invest your time and money by buying it and reading it. Technology continually speeds up some of these steps, but it will never be automatic. It's just the price you pay for a printed book.
The web can provide you with the latest info, distro, whatever; however, it is a rare website which pours as much effort into one of its articles as a good author / editor / publisher is willing to put into a book.
Please respond to the OpenOffice team with your problems. Often they are already fixed, and updating your installation is all you need. However, you cannot expect them to fix something you never tell them about.
I like open source software. I like how it works. I like how I work when I'm using it. But using open source software is a bit of a social contract. Either pay back the developers with bug reports, or it shouldn't be important enough to complain about (to anyone).
Sometimes the bugs won't get fixed. Now THATS when you should REALLY complain!
Mabye if I throw a few million a year in advertising, say directed at the construction market....
:)
Now that would be evil
Last I checked OpenOffice wasn't a kde application. This means that it does not use any of the kde configuration tools, nor will it be manipulated by any KDE specific configuration methods.
I believe that OpenOffice is a java application, but I'm not going to waste too much time in verifying this. If it is JAVA, then it probably uses Swing which can be customized, but not nearly as much as say, Motif. Swing uses a pluggable look and feel, but if you wish to "roll your own" PLAF, you'd better be in it for the long haul.
I have often heard the complaint that all of the GUI applications should be "themable" using the same methods (or APIs) so every app will look similar on someone's desktop. However, for this to work, we would all have to rely on only one distributor of this API which sort of defeats the whole purpose of providing different "choices" to end users and software developers.
I have a hard time understanding why it should be a primary business objective to make sure all of my windows are green to match my frog-loving background, but I won't deny that someone will want it, and they should get it.
I don't think it's sad. After all, I have a secret light socket which I've been developing without the use of standards committees.
If you wish to gain access to this light socket, you need to give me the electrical cord of the appliance of your choice, and I will route it through the 2x2x2 iron safe that protects my newly created intellectual property. If you throw tons of cash at me, I might allow you to look at the plug directly, but only on the condition that I can prevent you from telling anyone else about it (and I'm going to change it completely next year too!)
Of course, my plug's tolerances are incredible, so if you attempt to access it incorrectly, your lamps may flicker or totally self destruct. But hey, that's your problem! You should have paid me to use the "secret" plug which I won't show you.
I imagine that my competitors will have a fully working substitute interface in about 30 years. But I've still got the upper hand, hehehe.... See I've made the plug not work properly, so they'll actually have to include ALL of the BUGS for "full functionality"!
Ok, so it's a bit offtopic, but I think you're quote should be properly attributed to Sir Arthur Conan Doyle, as he used it extensively in his character Sherlock Holmes.
Not that software development is any less a mystery to those outside of coding circles.
I wish I have a vew mod points to throw your way. The comments about your local newspaper's site are quite apt. However...
I believe the onstar to be a "viable" product, because it produces important information (street directions) which is guranteed to be accessable by someone owning the system. The advertising aware "restruant" feature may not be even-handed, but it is guranteed to be available.
But if I buy a "enhanced browsing" cell phone, I have no gurantee that it will work with any given poster. I have to first find a "enhanced browsing enabled" poster. So I have a feature which is not guranteed to be available. After pointing this thing to a dozen posters and getting nothing, I will stop trying the feature until I see a poster indicating that it contains this "enhanced feature". Meanwhile many people will see this "enhanced" poster, but not have the cell phone / whatever to access the goods.
If I buy a new cell phone before I encounter this poster, or even after I encounter only a few of these posters, I will probably decide to get a cheaper model which doesn't provide this "feature" my experience tells me is "almost useless". If others lacking the "enhanced" cell phone fail to get a sense of "missing out" on the experience, they will probably not buy in either. Of course, how do you "miss out" on an experience you have no awareness of? Advertising!
Products like this need excellent planning at roll-out, or the budgets dry up well before the revenue rolls in.
Well, I can't really experiment on one of these devices without breaking the vacuum, so no, I cannot directly confirm my view.
However, the contrasting opinion on why this works included an explanation of the air molecules on the white side shifting to the dark side due to low pressure on the dark side. If this is supposed to be the main reason for rotation, the the logic is flawed.
If the black side of the vane is hotter, and it transfers it's heat to the air directly contacting it, the that air will be hotter. Hot air (before it expands) has a higer pressure than it would before it was heated. Expanding air is not picky about what it pushes, hence the black vane appears to provide the "thrust".
An explanation conatining air on the white side of the vane seeking out the low pressure on the dark side of the vane doesn't make much sense to me, because, if there was low pressure on the dark side of the vane, then the low pressure would seemingly equalize by sucking the vane (and everything else) toward it.
Low pressure on the dark side of the vane seems wrong, unless you can explain how the low pressure is selective about only sucking the air around the vane while actually propting the vane to rotate away from the low pressure.
A compairson of vanes to aircraft wings makes the alternate explanation oboviously wrong (but doesn't make my explanation any more "right") Aircraft are lifted because the wing experiences low pressure on the TOP side of the wing (in compairson to the bottom side of the wing)
Assuming the technology can be implemented without problems (which it should), I still see tons of launch problems.
Unless this can be launched in a big way, it won't be very useful. Users with enhanced cell phones / other viewers, will be frustrated with a lack of content to browse, and much content will go unviewd by people lacking compatible browsers. Even if the people have usable browsers, and the content is available, most of the population won't bother to learn how to use it. I mean, how many people are just getting around to setting their VCR/DVD clocks? (Not the slashdot crowd, of course! But they are more than us)
Plus, how many people are willing to look like a geek in public pointing their cell phone at a poster, while mashing on some "browse" button, because the bottom of the poster states "Hypertag Enabled, Point Here for More Information!"? If this is to succeed, that's what many, many people need to do.
If you mean a pratical working example, odds are you are already using one. MVC is used heavily in well designed (NOT VB) gui applications like window managers, or GUI toolkits. Unfortunatly Visual Basic teaches the world not to design the application, but rather to draw the interface, and then hang code off of it's events. As a result you typically see the handler methods grow in size and complexity as they have to handle the model, view and controller.
// forward the connection to a jsp "request denied page"p lay.jsp");
... html code here... ... more html ... ... more html ... ... more html
For a mini-demo, let me present the following pseudo-code examples.
Request Handler (Control):
doGet(request, response) {
User u = User.lookup(request.getParam(username));
if (!u.hasPermission(request.getParam(query))) {
}
Book b = Book.getBook(request.getParam(Title), request.getParam(Author));
request.setAttribute("BookInfo", b);
RequestDispatcher dispatcher = servletContext.getRequestDispatcher("/JSP/BookDis
dispatcher.forward(request, response);
}
The Book object (Model):
{
static void initialize() {
connect to database / etc to get book info.
}
static Book getBook(title, author) {
return the correct book;
}
String getTitle() {
return title;
}
(and many other getProperty methods)
}
the JSP page (View):
{
jsp:usebean id="BookInfo" class="model.Book" scope="request
jsp:getProperty name="BookInfo" property="title"
jsp:getProperty name="BookInfo" property="author"
}
It's a very simple example, and as such, does very little, but hopefully you can gather the idea of MVC seperation from my quickly constructed (aka shoddy) example.
Try "Bitter Java" by Manning. I'm not saying that it has anything much better than a call to return to MVC, but it's written well, and it's code seems to be sanity-checked.
I checked out the "Problem with JSP" site, and many of the issues it raises are present in "Bitter Java". I don't agree that the JAVA bean tags are fundamentally worse (or better) than the alternative syntax templating provides, but the last example (manipulating the title) is a cop-out.
If the title is supposed to change in the header and footer, then the controller (which manipulates both the model AND the view) should pass the info along in a Java Bean. That would allow the header and footer to grab the title without the fear of "missing a semicolon" using the normal JSP bean extensions.
Some of their work is interesting, and I like the bit about loops, but a lot of it implys that they are complaining about badly coded JSP pages. I mean, a 30K JSP page? Only if you don't have any MVC, and inline the JSP at every opportunity.
I have to agree.
After enought tags accumulate, you need to standardize on them, which usually results in a bit of bickering over what tag does X better.
Eventually all of your JSP pages become "Tag platform X" specific, requiring anyone else using the "enhanced" JSP environment to be careful about the introduction of new tags. As a final blow new developers will have no idea that tag FOO exists, and will have to be brought up to speed on your flavor of JSP.
All in all, tags seem to be the tool of those who would rework JSP into thier own sub-language. Encapsulating the data is the way to go, and Java Bean encapsulation seems to offer the best of both worlds. It provides a simplified tag interface for interaction with the Java Beans, and it prevents the development of various new "tag-based" JSP variants.
MVC - Model View Controller
The real power of MVC here is the seperation of concerns. Seperation of concerns makes the code much easier to maintain and debug, but first let's address each of the elements.
Model - The things your computer udpates, or the actual representation of whatever your program is manipulating. For example, a public (book) library system would have Books as part of their model. Books could be checked in, checked out, they have a title, one or more authors, etc.
Controller - The code responsible for updating the model, and updating the view. For example, the controller decides what the view may or may not show, what parts of the model are manipulated, and what data from the model is exposed by the view.
View - The code responsible for providing the interface to a user. For example, a view might be a web page, a text based interface, a GUI based interface, or anything else that takes the user's input and provides them with a "View" of the model's data.
By seperating the concerns, maintenance is simplified. Is the book's title wrong? It's a problem in the model. Did someone ask for something but receive something else? You have bug in the controller. Are the Book titles filling out the Author slots, well you have a problem in your View.
The problem is in most "slap it together quick, so we can roll it out the door" code, all of these concerns are placed in the same module, which creates the following problem.
If you intend to only change one aspect of the program, you run the real risk of chaning all aspects of the program.
For example, you wanted to rearrange the GUI to make it more useable, but heaven help you, because now the database connection is acting funky. How much do you know as a GUI designer about database connections? Do you want to debug it? Who knew that your connection was stored with an int counter using the ubiquitous variable i? With MVC, you can safely avoid the most common pitfalls.
Although I won't comment on the usefullness of this book, I imagine that you can come up with at least 10 reasons books haven't disappeared with the invention of the web.
Let's face it, there's a lot of books which aren't much better than a collection of dispartate web pages. But how hard is it to recogonize that books and the web both provide information but to different markets due to the ways in which they can be used?