Java also makes it difficult to use a lot of other things, including other APIs, that exist in the host system, due to it's nature of trying to establish a standard that works across all platforms. Much of the Java API appears to be re-inventing the wheel so it has a coffee color. Now that's not a bad thing, because it does provide a uniform way for a Java program to do stuff instead of trying to access methods in other languages (which, for reasons of portability, it would surely want to deny exists).
Your statement, though, is like trying to say that the Java API is where the value is, and not the Java language. How would you feel if you were faced with another language that had an equally vast API?
Personally, I've felt that the vast Java API is overkill.
Actually, I looked at 3 or 4 such books in a bookstore a couple months ago. My impression was that JSP was horrendously complex, and IMHO needlessly so. I felt all that configuration and detail pur performance at risk, as well as administrative sanity. JSP definitely does not follow the KISS principle. It seems to go out of its way to avoid it.
You might want to explain the benefit of all those config variables, for I don't see it.
So why not have a template engine that can take a tag and find the logic element as a
dynamically loaded one-function library module (avoiding a fork), or as a class file,
or as a binary executeable, or as a script, or as a static sub-document?
The way I'm planing my design is that each document node in a document hierarchy would specify the search starting point.
The name taken from the tag is the search target.
If the node is a directory, the search is for a file within that directory.
If the node is a file, the search is first for a file with the node name and tag name combined,
and then for the tag name alone in that directory.
The search will then extend through parent directories up to the document root.
And then a list of alternate directories would be searched.
The search stops when the named logic element is found.
This would allow some logic to have scope over the whole site or a large branch of it,
while some smaller areas can have the logic substituted with a variation just for that part.
For example, you can create a single logic element to output the selected ad banner HTML and put that logic element in the document root.
References to it by tags in documents anywhere in the site hierarchy would then use the one at the document root.
One special branch can then include a different logic element to change the ad banner logic for that branch without changing the tags the presentation designer put in to specify where the ad banner falls into the page layout.
Actually the documents would be searched the same way, too.
I just don't want to force everything into a single language.
I'm of the belief in using the right tool for the job,
even if that means some parts of the site are done differently than other parts.
I might do database logic in Java but dynamically generate graphical image files with C.
That's a fairly standard model.
That's not specific to Java, J2EE, or Tomcat.
What you do get is that in some environments, the 2nd and 3rd are not separated (or maybe not very well).
PHP comes to mind.
I built this site with PHP in one day and it was my first PHP project.
The backend (1st in your list) was written in C and a shell script and not built on a usual SQL DB engine.
It just consists of a cron triggered script that fetches backend data with lynx and reformats it with a different
C program customized for each site (some in text format and some in RDF which was added later).
The PHP code can be seen here.
But I have concluded that fully integrated logic and presentation is not a good thing.
And I've also concluded that more than one class of logic can and should exist in a single presentation.
The logic to select the banner ad should be separate from the logic to summarize some news on the side rail,
while yet different logic selects the main forum body (in an example forum site).
I feel all those elements should be discrete reusable elements of logic.
The ad banner selector could be used on other pages, for example.
The page would then be built for layout and style much as a regular static web page would be,
with tag elements to notate where other "sub-presentations" go.
Those can then be other static elements, or logic (dynamic) elements.
I have thought this was what JSP was supposed to be about, and the logic elements would be servlets.
But I don't see where it has to be done in Java.
Now that doesn't mean I hate Java.
I admit I dis-like C++, but not Java.
I do OO design and code it in C, but I haven't found any real advantage to doing it in C++.
But I've done some programming in Pike, which I believe is better OO than C++ (but also has some limitations).
Java looks to be the current state of the art in reasonably clean OOL.
The trouble I have with Java is the JVM.
I don't feel the whole portable environment thing is necessary for statically maintained applications.
What I mean by that is something that stays where it is sufficiently long term to make a compilation worth while (a day).
To make downloadable applications to run in a web browser, portability is now more needed since a site needs to be able
to deliver something on demand that works on many different platforms.
But for this I don't feel that a compiled to byte code environment is the right way to go.
If Java had been compiled down to a stack engine environment somewhat like Forth, or maybe just use Forth,
then I would have agreed with it.
Basically, my goal for the server side is to have an environment that allows working with elements in the binary
format of the host machine compiled from C or Java (for my choices) or any other language (compiled to binary like C++,
precompiled like Perl, or interpreted at run time like Bash) that can run on the host, and integrate those as logic
elements in a template based server engine.
I see Java as a good choice in the system, but I also believe it should be that, a choice.
cgi requires forking an external process, tomcat throws up a new thread inside of a virtual machine process that is already running which is much less overhead than the cgi fork. also it is faster to develop inside java as well as being safer in general (no memory leaks, better object-oriented design etc.)
Besides having all of the disadvantages of cgi, gcj is not a perfect rendition of java. Last I checked it was still missing a number of key pieces including good multi-threading and reflection.
I'm currently designing a new server which will eliminate the forking in certain cases.
Assuming you don't have a switch-userid problem (which would require some kind of forking somewhere)
the way it would work is that a piece of logic would be coded in C and compiled not into an executeable but into a simple
module file with a.so extension.
The template processor would parse for tags (and I have planned a parsing cache for static templates)
in the template, and for those it finds, it would "call" the appropriate element for that tag.
That could be another template (recursion loop detection engaged) or some logic.
If the logic is the.so file, then it would be loaded as a dynamic library right then and called directly in the same process.
If the logic is an executeable file (or a module owned by a different user in a switch-userid situation),
then it would be run in a forked process.
The point of the design is that all the elements can be made from any kind of executeable element the host OS can handle.
And that would include Java, either as a binary compiled module (if I can figure out how to do that),
a binary compiled executeable, or as a class file run by the appropriate byte code engine.
You're thinking of templating engines, and there are many around. Probably more by co-incidence than anything else, the ones I've come across have all been written in Java, and co-operate nicely with Servlets (this is where Tomcat fits in).
But the concept of a "template engine" as you understand it, doesn't specifically require Java, and could be done in say C? So Tomcat is a "template engine"? And the templates are in XML?
Have a look around at Velocity, Webmacro, FreeMarker or Tea (see my earlier post above, or Google for them), and have fun!
I'm sure I can find them. But conceptually, what are they? Are they template engines? Servlet processors (if there is such a term)? Ya know, a "concepts document" (that specifically does not depend on the reader already understanding the abstract concepts it's expected to explain) would go a long way to clarify things here for me. A "concepts document" is, unfortunately, a very rare thing in most things.
You don't need them per say. But a lot server-side applications are written as servlets.
What is the advantage of doing a servlet? Just to be programming in Java?
Yes, but I don't think that really answers the question you're asking. A "servlet" is just the affectionate term for a server-side Java application. "Servlet" implies Java the same way "applet" does.
You can write server-side applications in any of these languages, they're just not called servlets.
So what does Tomcat have to do with this? If I write in Java and compile it to a host machine executeable binary format instead of a class file, and run it under the CGI mechanism, would it still be called a servlet?
So why can't I just compile my code after I write it, and run it that way? And why do I have to mix code and content? Why can't I have content (be it HTML or XML) and logic (be it in Java or C or any other language) as separate but cooperative entities, such as with tags in the content to describe to the logic where output pieces go? You're talking about some good things, but I'm still looking for why Tomcat is the only, or best, way to have this.
I'd agree that fewer processes is better than more processes, given other things being equal. But is that because of performance issues? I've run benchmarks on the overhead of forking processes, and I was able to reach forking rates of over 9000 per second in Linux 2.4.7 on an 800 Mhz Pentium-III. While the overhead is non-zero, I think I'd focus on other matters where performance is an issue.
Now for Java. I like the Java language. I don't like the Java run time environment. Portability-after-compile is unimportant to me. I have not started to work with it yet, but I look forward to using gcj.
Separating application functionality from user interface is already a known idea, and it can be done many ways to make the components pluggable. Do people believe that Tomcat has an exclusive on this concept?
With regard to your discussion of Foo and Foo2, I don't know what you are referring to. Why can't one do this in another language other than Java? And if in Java, why is it that Tomcat is a necessary part of this?
I do worry about the apparent documentation problems. One of the things I have found that really slows down projects, whether a programming project or an administrative project, is non-existant, confusing, vague, or misleading documentation. What is it that "jetspeed" does? I'm sure it's not reading your mind and generating code ahead of your typing.
I really want to know this stuff. I want to pin down just what it is that makes all this better. And I want to isolate the different aspects of it, for example the servlets, the environment, the language, to see which of those aspects contribute what to the benefits, and to compare how those aspects can contribute by themselves. Tomcat is more than one thing, but where's the synergy? It's not obvious to me, and I hope people are not presuming it is obvious to everyone.
Can someone tell me what is it that Tomcat 4.0 (or any other version) lets me do that cannot be done otherwise?
I know there must be something for them to put all this effort into it, but I cannot see it.
If you're tempted to say "well if you can't see it, you won't understand it" then I'll say you probably
don't understand it for yourself and you're doing it for the fad value of it.
Simply recording what I do in one GUI session won't really describe how I might want those actions to vary on the basis of varying conditions, either inside or outside the application, or even between multiple applications if the script is driving 2 or more (for example to extract data from one and put it into another in some special way that simple cut and paste won't accomplish).
If the COM interface from a script to an application is truly complete and flexible, then it should be possible for the "script" (probably better done in C/C++/Java for this) to run an application on one machine, and present a GUI on another, and "replicate" the application that way, or even make it available to another script there via the same COM interface rules. If COM integrates network access, then it could already do this. Apparently the way Windows makes everything be a DLL has some power (but also security risks) to it.
I have advocated separating user interface presentation from programming logic, as have many others. Unlike COM, my advocacy is to connect the separation via a protocol rather than a mere API (but there should be a standard API, too). Properly done, one program on the client end would be all you'd need for all applications, where the app logic runs on a separate server, in much the same way as one browser is all you need for quite a number of documents (but HTTP and HTML don't really do it well beyond documents).
I'd also like to know how you got your posting to be on Wednesday December 31, @06:00. Maybe a billennium bug at/. ?
This is one of the reasons I refuse to do work as a developer in most cases. My professional work is systems and network administration, although my 2 decades of programming does (except in the last few months) get me plenty of calls to come interview for some programming job. Right now I have enough cash and contract work to hang on for the next 2 to 3 years, so I'm working on developing something for my own business idea. Interestingly, while I thought I'd have plenty of time to do it right, I even feel my own pressure to get it done and get it to market sooner. That is a fact of life. The concept of getting things to market sooner really is valid from a business perspective, despite how much the geek in me says that's crap. At least during the economic downturn, it's less likely that competitors are doing as much that will compete against me, so I can take a little time to get this done right.
And another job is probably not going to be waiting for very long. Any business that has enough work to need to hire another person is probably very concerned about making deliverables to their customers (or else they would just have the existing staff do it and save money on salaries). Given they probably got 500 resumes for the job, and interviewed 20 excellent candidates of which they might well like to hire the best 5 to 10 if they had the open slots, if you get the offer, you better take it right then or risk losing it to #2 who is probably just as good as you are anyway. Then you can decide if it is worth explaining it to your old boss during the exit interview (if you even bother with one).
I agree. Don't give management a decision to make. That just gives them more power whether they say "yes" or they say "no". Instead, keep the decision making to yourself. You decide if you can do things like create better tools on your own time, or if you just want to walk. Maybe you can tell them why on the way out, but personally, I wouldn't even bother. Usually if they can't figure it out on their own, they won't understand it when explained by someone who doesn't talk MBA-speak (which I'm assuming you can't do if you asked this question of slashdot in the first place).
The problem could be that it takes time to build this kind of good, flexible, reusable, modular components. I've done the same thing myself. But rarely can this be done on employers time (who do you bill for the time... when there's enough work to keep everyone busy). One might try to argue to management that if they spend a couple weeks putting together some slick modular tools, that over the course of the next few months it will pay back well with even faster deliverables. But when business is rolling in and customers are saying "the other company promised it in 3 days, but if you can deliver it in 2 days, you've got the deal" then management is loath to pay people for what to them seems risky. The answer may be to put together those tools on your own time, put them on some not-well-announced project on sourceforge using a "pen name" as the owner, then come to management one day and say "Hey look what I found, I think we can use this and speed up our work. We should try this out before anyone else discovers it". And the fact that it is already out there on sourceforge would prevent them from trying to take ownership of work done on your own time.
The problem with software reuse may not be that the software is bad, but rather, that it isn't just right for the new site. For example, a script that displays selected records from a database may format it in a fixed format that looks fine on the first site, but looks crappy on the second site. Now software like that isn't all that reusable, but really good software that can be plugged in well would have to handle a lot of different things that take time to put together. And if you're billing time to customers, while it may be tempting to bill one customer for the time it takes to develop something that customer doesn't really need, management won't like that when the customer says the hours were way too many for what he got. The end result is each customer is minimized and good portable reusable software doesn't happen. If there was down time available to do stuff not specifically for any one customer, then that could be used to put together good reusable software. But as long as business is coming in, I'm sure the employers want to deliver to those customers and not lose them.
I see this as building more opportunity for the future. If businesses are cranking out crappy web sites today, then in the next year or two, some site owners will eventually realize that and have to look for someone to re-design it. Thus there will be more turnover of work to come during the economic recovery. Since the economic mess was caused by the MBA types, I say stick it to 'em and let them pay for the recovery.
I'd have to fully agree with this. In this economy, a business that is making some success (and don't forget, business success is always measured at the bottom line) isn't about to go making "risky" changes.
If you are the kind of person who really believes that quality matters, my suggestion is, rather than tell that to your bosses, just look around for other possibilities. If you can find a new employer that is more in line with your thinking, then go for it. And the other possibility is to start your own business. Then you can really see if that concept flies as a business model.
Send me a list of the web sites. I'll email the owners at various randomly selected times over the course of the next 30 to 100 days with the message "Your web site sucks!".
Gee, and I thought much of the blame was on so many artists coming from the world of print media (e.g. paper brochure layout) to the web (e.g. electronic brochure layout) and not having a clue about basic concepts of adaptable layout (not dynamic, necessarily, just the ability to adapt to different window sizes, different fonts, different widgets, etc). But it has become clear that much of the blame, if not most, is on the part of the programmers (and more likely their managers) for producing crap that doesn't even have the capability to do the right thing.
I've found many a GUI app that had really good graphical layout, sometimes awesomely cool stuff, and did shit when it came to what the coded logic was. But then again, you shouldn't expect protein and vitamins in candy.
Tell me how well linuxhomepage.com does on your web browser in your preferred window size (as long as it's not itsy bitsy) on your desktop with your fonts and widgets.
You'd be surprised. Managers do seem to have the concept of negative numbers when it comes to deciding how long it will take to get a project done. "We promised this to the customer the last thursday before the last monday three weeks ago, so this needs to be delivered on time."
Will IBM Visual Age work with development of Java code to be compiled with gcj or some other direct (not class file) compiler? Or is it dependent on the JVM and class files? And will the resultant source package compile on most major UNIX platforms (I'm into distributing the source code and getting tight compiles, not messing around with the JVM environment)?
I'd rather have boxed code instead of colored code. I find boxes easier to read (with thin lines, of course). I'd want to have the loops boxed. Keywords can be colored, and that helps some, as long as I can control the colors (I have a certain vision problem that requires me to control the colors to be able to see).
Slashdot Mirror
Java also makes it difficult to use a lot of other things, including other APIs, that exist in the host system, due to it's nature of trying to establish a standard that works across all platforms. Much of the Java API appears to be re-inventing the wheel so it has a coffee color. Now that's not a bad thing, because it does provide a uniform way for a Java program to do stuff instead of trying to access methods in other languages (which, for reasons of portability, it would surely want to deny exists).
Your statement, though, is like trying to say that the Java API is where the value is, and not the Java language. How would you feel if you were faced with another language that had an equally vast API?
Personally, I've felt that the vast Java API is overkill.
Actually, I looked at 3 or 4 such books in a bookstore a couple months ago. My impression was that JSP was horrendously complex, and IMHO needlessly so. I felt all that configuration and detail pur performance at risk, as well as administrative sanity. JSP definitely does not follow the KISS principle. It seems to go out of its way to avoid it.
You might want to explain the benefit of all those config variables, for I don't see it.
Excellent description!
So why not have a template engine that can take a tag and find the logic element as a dynamically loaded one-function library module (avoiding a fork), or as a class file, or as a binary executeable, or as a script, or as a static sub-document? The way I'm planing my design is that each document node in a document hierarchy would specify the search starting point. The name taken from the tag is the search target. If the node is a directory, the search is for a file within that directory. If the node is a file, the search is first for a file with the node name and tag name combined, and then for the tag name alone in that directory. The search will then extend through parent directories up to the document root. And then a list of alternate directories would be searched. The search stops when the named logic element is found. This would allow some logic to have scope over the whole site or a large branch of it, while some smaller areas can have the logic substituted with a variation just for that part. For example, you can create a single logic element to output the selected ad banner HTML and put that logic element in the document root. References to it by tags in documents anywhere in the site hierarchy would then use the one at the document root. One special branch can then include a different logic element to change the ad banner logic for that branch without changing the tags the presentation designer put in to specify where the ad banner falls into the page layout. Actually the documents would be searched the same way, too.
I just don't want to force everything into a single language. I'm of the belief in using the right tool for the job, even if that means some parts of the site are done differently than other parts. I might do database logic in Java but dynamically generate graphical image files with C.
I think they are only refered to as servlets if they exist as Java bytecode. But I'm not sure why you'd want to do what you describe here. :)
Actually my goal is more to do template logic elements as modules dynamically loaded and called in the same process, as briefly described here.
That's a fairly standard model. That's not specific to Java, J2EE, or Tomcat. What you do get is that in some environments, the 2nd and 3rd are not separated (or maybe not very well). PHP comes to mind.
I built this site with PHP in one day and it was my first PHP project. The backend (1st in your list) was written in C and a shell script and not built on a usual SQL DB engine. It just consists of a cron triggered script that fetches backend data with lynx and reformats it with a different C program customized for each site (some in text format and some in RDF which was added later). The PHP code can be seen here.
But I have concluded that fully integrated logic and presentation is not a good thing. And I've also concluded that more than one class of logic can and should exist in a single presentation. The logic to select the banner ad should be separate from the logic to summarize some news on the side rail, while yet different logic selects the main forum body (in an example forum site). I feel all those elements should be discrete reusable elements of logic. The ad banner selector could be used on other pages, for example. The page would then be built for layout and style much as a regular static web page would be, with tag elements to notate where other "sub-presentations" go. Those can then be other static elements, or logic (dynamic) elements.
I have thought this was what JSP was supposed to be about, and the logic elements would be servlets. But I don't see where it has to be done in Java. Now that doesn't mean I hate Java. I admit I dis-like C++, but not Java. I do OO design and code it in C, but I haven't found any real advantage to doing it in C++. But I've done some programming in Pike, which I believe is better OO than C++ (but also has some limitations). Java looks to be the current state of the art in reasonably clean OOL.
The trouble I have with Java is the JVM. I don't feel the whole portable environment thing is necessary for statically maintained applications. What I mean by that is something that stays where it is sufficiently long term to make a compilation worth while (a day). To make downloadable applications to run in a web browser, portability is now more needed since a site needs to be able to deliver something on demand that works on many different platforms. But for this I don't feel that a compiled to byte code environment is the right way to go. If Java had been compiled down to a stack engine environment somewhat like Forth, or maybe just use Forth, then I would have agreed with it.
Basically, my goal for the server side is to have an environment that allows working with elements in the binary format of the host machine compiled from C or Java (for my choices) or any other language (compiled to binary like C++, precompiled like Perl, or interpreted at run time like Bash) that can run on the host, and integrate those as logic elements in a template based server engine. I see Java as a good choice in the system, but I also believe it should be that, a choice.
I'm currently designing a new server which will eliminate the forking in certain cases. Assuming you don't have a switch-userid problem (which would require some kind of forking somewhere) the way it would work is that a piece of logic would be coded in C and compiled not into an executeable but into a simple module file with a .so extension.
The template processor would parse for tags (and I have planned a parsing cache for static templates)
in the template, and for those it finds, it would "call" the appropriate element for that tag.
That could be another template (recursion loop detection engaged) or some logic.
If the logic is the .so file, then it would be loaded as a dynamic library right then and called directly in the same process.
If the logic is an executeable file (or a module owned by a different user in a switch-userid situation),
then it would be run in a forked process.
The point of the design is that all the elements can be made from any kind of executeable element the host OS can handle.
And that would include Java, either as a binary compiled module (if I can figure out how to do that),
a binary compiled executeable, or as a class file run by the appropriate byte code engine.
You're thinking of templating engines, and there are many around. Probably more by co-incidence than anything else, the ones I've come across have all been written in Java, and co-operate nicely with Servlets (this is where Tomcat fits in).
But the concept of a "template engine" as you understand it, doesn't specifically require Java, and could be done in say C? So Tomcat is a "template engine"? And the templates are in XML?
Have a look around at Velocity, Webmacro, FreeMarker or Tea (see my earlier post above, or Google for them), and have fun!
I'm sure I can find them. But conceptually, what are they? Are they template engines? Servlet processors (if there is such a term)? Ya know, a "concepts document" (that specifically does not depend on the reader already understanding the abstract concepts it's expected to explain) would go a long way to clarify things here for me. A "concepts document" is, unfortunately, a very rare thing in most things.
You don't need them per say. But a lot server-side applications are written as servlets.
What is the advantage of doing a servlet? Just to be programming in Java?
Yes, but I don't think that really answers the question you're asking. A "servlet" is just the affectionate term for a server-side Java application. "Servlet" implies Java the same way "applet" does.
You can write server-side applications in any of these languages, they're just not called servlets.
So what does Tomcat have to do with this? If I write in Java and compile it to a host machine executeable binary format instead of a class file, and run it under the CGI mechanism, would it still be called a servlet?
So why can't I just compile my code after I write it, and run it that way? And why do I have to mix code and content? Why can't I have content (be it HTML or XML) and logic (be it in Java or C or any other language) as separate but cooperative entities, such as with tags in the content to describe to the logic where output pieces go? You're talking about some good things, but I'm still looking for why Tomcat is the only, or best, way to have this.
I'd agree that fewer processes is better than more processes, given other things being equal. But is that because of performance issues? I've run benchmarks on the overhead of forking processes, and I was able to reach forking rates of over 9000 per second in Linux 2.4.7 on an 800 Mhz Pentium-III. While the overhead is non-zero, I think I'd focus on other matters where performance is an issue.
Now for Java. I like the Java language. I don't like the Java run time environment. Portability-after-compile is unimportant to me. I have not started to work with it yet, but I look forward to using gcj.
Separating application functionality from user interface is already a known idea, and it can be done many ways to make the components pluggable. Do people believe that Tomcat has an exclusive on this concept?
With regard to your discussion of Foo and Foo2, I don't know what you are referring to. Why can't one do this in another language other than Java? And if in Java, why is it that Tomcat is a necessary part of this?
I do worry about the apparent documentation problems. One of the things I have found that really slows down projects, whether a programming project or an administrative project, is non-existant, confusing, vague, or misleading documentation. What is it that "jetspeed" does? I'm sure it's not reading your mind and generating code ahead of your typing.
I really want to know this stuff. I want to pin down just what it is that makes all this better. And I want to isolate the different aspects of it, for example the servlets, the environment, the language, to see which of those aspects contribute what to the benefits, and to compare how those aspects can contribute by themselves. Tomcat is more than one thing, but where's the synergy? It's not obvious to me, and I hope people are not presuming it is obvious to everyone.
And why do I need servlets? And is Java the only way to do servlets? Why not servlets in say, C or Perl or TCL or Lisp or whatever?
Can someone tell me what is it that Tomcat 4.0 (or any other version) lets me do that cannot be done otherwise? I know there must be something for them to put all this effort into it, but I cannot see it. If you're tempted to say "well if you can't see it, you won't understand it" then I'll say you probably don't understand it for yourself and you're doing it for the fad value of it.
I want to know what the advantage is over say:
"Government thinking" is a contradiction of terms. That is especially so in Canada.
Simply recording what I do in one GUI session won't really describe how I might want those actions to vary on the basis of varying conditions, either inside or outside the application, or even between multiple applications if the script is driving 2 or more (for example to extract data from one and put it into another in some special way that simple cut and paste won't accomplish).
If the COM interface from a script to an application is truly complete and flexible, then it should be possible for the "script" (probably better done in C/C++/Java for this) to run an application on one machine, and present a GUI on another, and "replicate" the application that way, or even make it available to another script there via the same COM interface rules. If COM integrates network access, then it could already do this. Apparently the way Windows makes everything be a DLL has some power (but also security risks) to it.
I have advocated separating user interface presentation from programming logic, as have many others. Unlike COM, my advocacy is to connect the separation via a protocol rather than a mere API (but there should be a standard API, too). Properly done, one program on the client end would be all you'd need for all applications, where the app logic runs on a separate server, in much the same way as one browser is all you need for quite a number of documents (but HTTP and HTML don't really do it well beyond documents).
I'd also like to know how you got your posting to be on Wednesday December 31, @06:00. Maybe a billennium bug at /. ?
This is one of the reasons I refuse to do work as a developer in most cases. My professional work is systems and network administration, although my 2 decades of programming does (except in the last few months) get me plenty of calls to come interview for some programming job. Right now I have enough cash and contract work to hang on for the next 2 to 3 years, so I'm working on developing something for my own business idea. Interestingly, while I thought I'd have plenty of time to do it right, I even feel my own pressure to get it done and get it to market sooner. That is a fact of life. The concept of getting things to market sooner really is valid from a business perspective, despite how much the geek in me says that's crap. At least during the economic downturn, it's less likely that competitors are doing as much that will compete against me, so I can take a little time to get this done right.
And another job is probably not going to be waiting for very long. Any business that has enough work to need to hire another person is probably very concerned about making deliverables to their customers (or else they would just have the existing staff do it and save money on salaries). Given they probably got 500 resumes for the job, and interviewed 20 excellent candidates of which they might well like to hire the best 5 to 10 if they had the open slots, if you get the offer, you better take it right then or risk losing it to #2 who is probably just as good as you are anyway. Then you can decide if it is worth explaining it to your old boss during the exit interview (if you even bother with one).
I agree. Don't give management a decision to make. That just gives them more power whether they say "yes" or they say "no". Instead, keep the decision making to yourself. You decide if you can do things like create better tools on your own time, or if you just want to walk. Maybe you can tell them why on the way out, but personally, I wouldn't even bother. Usually if they can't figure it out on their own, they won't understand it when explained by someone who doesn't talk MBA-speak (which I'm assuming you can't do if you asked this question of slashdot in the first place).
The problem could be that it takes time to build this kind of good, flexible, reusable, modular components. I've done the same thing myself. But rarely can this be done on employers time (who do you bill for the time ... when there's enough work to keep everyone busy). One might try to argue to management that if they spend a couple weeks putting together some slick modular tools, that over the course of the next few months it will pay back well with even faster deliverables. But when business is rolling in and customers are saying "the other company promised it in 3 days, but if you can deliver it in 2 days, you've got the deal" then management is loath to pay people for what to them seems risky. The answer may be to put together those tools on your own time, put them on some not-well-announced project on sourceforge using a "pen name" as the owner, then come to management one day and say "Hey look what I found, I think we can use this and speed up our work. We should try this out before anyone else discovers it". And the fact that it is already out there on sourceforge would prevent them from trying to take ownership of work done on your own time.
The problem with software reuse may not be that the software is bad, but rather, that it isn't just right for the new site. For example, a script that displays selected records from a database may format it in a fixed format that looks fine on the first site, but looks crappy on the second site. Now software like that isn't all that reusable, but really good software that can be plugged in well would have to handle a lot of different things that take time to put together. And if you're billing time to customers, while it may be tempting to bill one customer for the time it takes to develop something that customer doesn't really need, management won't like that when the customer says the hours were way too many for what he got. The end result is each customer is minimized and good portable reusable software doesn't happen. If there was down time available to do stuff not specifically for any one customer, then that could be used to put together good reusable software. But as long as business is coming in, I'm sure the employers want to deliver to those customers and not lose them.
I see this as building more opportunity for the future. If businesses are cranking out crappy web sites today, then in the next year or two, some site owners will eventually realize that and have to look for someone to re-design it. Thus there will be more turnover of work to come during the economic recovery. Since the economic mess was caused by the MBA types, I say stick it to 'em and let them pay for the recovery.
I'd have to fully agree with this. In this economy, a business that is making some success (and don't forget, business success is always measured at the bottom line) isn't about to go making "risky" changes.
If you are the kind of person who really believes that quality matters, my suggestion is, rather than tell that to your bosses, just look around for other possibilities. If you can find a new employer that is more in line with your thinking, then go for it. And the other possibility is to start your own business. Then you can really see if that concept flies as a business model.
Send me a list of the web sites. I'll email the owners at various randomly selected times over the course of the next 30 to 100 days with the message "Your web site sucks!".
Gee, and I thought much of the blame was on so many artists coming from the world of print media (e.g. paper brochure layout) to the web (e.g. electronic brochure layout) and not having a clue about basic concepts of adaptable layout (not dynamic, necessarily, just the ability to adapt to different window sizes, different fonts, different widgets, etc). But it has become clear that much of the blame, if not most, is on the part of the programmers (and more likely their managers) for producing crap that doesn't even have the capability to do the right thing.
I've found many a GUI app that had really good graphical layout, sometimes awesomely cool stuff, and did shit when it came to what the coded logic was. But then again, you shouldn't expect protein and vitamins in candy.
Tell me how well linuxhomepage.com does on your web browser in your preferred window size (as long as it's not itsy bitsy) on your desktop with your fonts and widgets.
You'd be surprised. Managers do seem to have the concept of negative numbers when it comes to deciding how long it will take to get a project done. "We promised this to the customer the last thursday before the last monday three weeks ago, so this needs to be delivered on time."
Will IBM Visual Age work with development of Java code to be compiled with gcj or some other direct (not class file) compiler? Or is it dependent on the JVM and class files? And will the resultant source package compile on most major UNIX platforms (I'm into distributing the source code and getting tight compiles, not messing around with the JVM environment)?
When you find a bug in your program, your best command line tool is the "rm" command. :-)
I'd rather have boxed code instead of colored code. I find boxes easier to read (with thin lines, of course). I'd want to have the loops boxed. Keywords can be colored, and that helps some, as long as I can control the colors (I have a certain vision problem that requires me to control the colors to be able to see).