Just one correction: Swing was based in (large) part on Netscape's Internet Foundation Classes, which were Netscape's attempt to have a cross-platform GUI component set. Sun and Netscape worked out some deal and Sun took this over, and re-worked and re-branded it as the Java Foundation Classes. See the Wikipedia article here. Cheers! Patrick
where he interviews Dan Drake, co-founder of Autodesk. AD bought Nelson's company and tried to get Xanadu to work, but as Drake puts it, it was 3 orders of magnitude from completion. Interesting interview.
I'm active in two FOSS projects, both LGPL, and I think that outside of licensing and philosophy, the most important thing to teach is how one participates in these projects and how it's different from traditional models.
One of the two projects has a titular lead programmer (who started it), but the committers are all welcome to refactor heavily as long as a) they don't break the code, b) they are willing to listen to criticism and discuss their proposals and c) they maintain ownership and don't walk away before the work is finished and completely integrated.
On the other project, there is a separate "incubator" sub-project where new ideas are tested and demoed, discussion is based on that, proposals are made, and the changes then accepted into the main branch.
So how one contributes is one thing.
Another is that different from for-pay work, people may appear and disappear from the project over time, often doing a lot of work and then none for months at a time. It can be lonely--you might have a lot of energy, a lot of ideas, and almost no one to discuss them with. You may be on your own much of the time. The "community" feeling shows itself over long periods of time and during the release cycles.
There's also more direct acknowledgement of contributions by individuals than in for-pay work.
Last point would be that writing software is hard work, and if you're active on a project, you'll likely spend much time, many nights and weekends, writing code without compensation. That can lead to greater pride of ownership, but on the other hand, can lead to burnout as well.
I think the social aspects of FOSS development are some of the most interesting ones to talk about.
What sort of validation is provided? Anyone can come up with a protocol that is thinner than XML, XML wasn't meant to be small. XML is readable while still allowing for type checking (basic with DTDs, advanced with Schemas or RelaxNG). Why pass around objects if you aren't going to do type-checking?
I think this article is just the sort of information we need in the technology community. There has been too much hype about web services in from the marketing departments of IBM, Sun, Microsoft and others. I have the basic grasp of what it does and how it works, though haven't coded with it yet. Mehat's experiences sound very much like my experiences trying out a new, immature toolkit and finding it exciting (in promise) but frustrating (in reality and limitations). Without this sort of ground-level view, it's too hard to tell if web services is an important part of a system architecture, or whether it needs more time.
What I'm surprised at is that nobody on these discussions in the last few days (that I've read) has seen anything reasonable with SCO's position. Put aside the profit motive, the MS-connection, and all, and look at it this way. SCO has purchased a code base, and extended it themselves, that took many many years to solidify and can be used to run "enterprise" services (according to them). Their claim is that Linux could not possibly have achieved the level of stability and reliability if it had all been developed from scratch. Their investigations supposedly revealed that some person(s), apparently from IBM, directly lifted proprietary SCO code and submitted it to the kernel tree.
What's egregious is not that SCO is complaining, but that they are doing it in such a rude manner, looking for a quick buck. I think they have a right to complain if someone took code they owned, developed, nourished, and started giving it away for free--and not just binaries, but the source, which, once distributed on the net, is a non-secret forever more. It would be wrong of IBM to do that, wrong of any programmer to do that.
That said, going for such a large claim against IBM is a response not in line with the damage done to them--unless they can prove that by sharing that code, they lost their crown jewels, and market share because of that. For all we know, this may be code that's used only in very high-volume, large-memory systems, which would be hard to develop on one's own without extensive testing and years of development.
NASA has shown that it can pull together good science when that is its focus: Hubble, the Voyagers, other satellites. What it can not do is manage a complete space program with the vast number of engineering programs to oversee and coordinate.
I suggest the best thing at this point would be to start sub-contracting for systems which others have proven they can build reliably. The Russians, for example, have shown they can achieve reliable, high-capacity payload launches, plus they managed to keep a space station in orbit for a long time. Why not pay the Russian space agency, as a subcontractor, for handling some of this work, such as launching? It would allow NASA to focus on science, where we have good engineers anyway. Get rid of the shuttles! Declare victory and retreat! Nobody, absolutely nobody, thinks they are a good idea (or ever were).
One thought is that the purchaser--the company who wanted the website--didn't feel you'd covered the material well enough. The reason I'm suggesting this (with no insult implied to you), is what you wrote here on/. -- "The contract was not a complex project: a system comprised of database-generated web pages, with file submission and minor document management features." One thing I've found more and more in custom development is that companies are very nervous the more complex their projects get. As a result, they tend to turn to vendors who can assuage their fears about how things might go wrong. Is it possible you took the wrong tack? Maybe when they saw the $5K price, and especially if you said this was "no problem", they thought: uh-oh, he's going to miss something, he won't cover it all. Meanwhile, the other guys were talking about how they were addressing security and scalability and failover and whatever (even if they really weren't). For better or for worse, people sometimes like to be sold to; it increases the value of the thing in their eyes.
The other thing is how, in general, your rates will be judged based on prevailing market rates. If the prevailing market rate for the website's functionality is 100 hours at $150 per hour, then your bid would seem surprisingly (and suspiciously) low. One alternative is, if you are competing at that level, maybe throw in a bid for $12K with a number of useful features that they've been talking about but in a future release. Show them ow for the same (or slightly less) money, they will get much more. Otherwise, if their friends at other companies are spending around $15K for this work as well, they probably won't trust you to do it for $5K. And why should they? Generally, there's no free lunch.
This is an interesting discussion. I'm thinking about several sites that I've used in the past, and their products, and what I liked and didn't. My thoughts:
Good technical manuals: WebLogic is expensive, and I wouldn't use it for personal use, but they have great respect IMO for the developer. Their APIs are fully documented in clear, technical language, they have samples for everything useful, and many many FAQs. Their docs are also updated for new releases. I think good docs will make or break a product, unless it's so easy to use that command-line help is enough or it's "intuitive" (like WinZip on Windows)
Straightforward user interface:Even if you have the docs, the truth is I won't read them till I need them. I tend to install the thing and then browse around to see what I can do. If it's an editor, I start typing. If it's a drag and drop GUI builder, I start building. While there's something great about developing your own unique interface and way of looking at the world, at least allow for an "idiot's option" that gets me feeling productive; or, that the tool hasn't gotten in the way of what I'm doing. Kudos to tools like JEdit, for example, which I had up and running and compiling with in maybe an hour. Blahs to APIs like Xerces, which I can use, but which have an absolutely confusing API in some cases (how do you move an Element from one Document to another? where's the changeParent() call?)
Let the FAQs lead the way:A number of others posted that your should publish your knowledge base, but I'd also add that a good FAQ system is a good lead-in for developer interest in your newsgroups. Basically, it will draw people there even if the newsgroups are new. I suspect you'll also spend the early rollout manning the newsgroups yourself. Roll your answers into the FAQs; searching newsgroups is tedious work. The worst thing to find are newsgroups with many, many unanswered threads (like Sun's Java site) and scanty FAQs. JGuru has a very good set of FAQs.
Another suggestion: just change the name outright to something like "GNU". Not, "GNU/Linux", which sounds weird to my ear anyway. Just "GNU".
Isn't it true that without the hundreds? thousands? of programs written for the GPL under the GNU project, the Linux kernel would be largely useless? Why diss all those people? They chose to distribute their code as part of GNU, not as part of BSD, or in the public domain--they made an explicit choice.
Every time we just use the word "Linux" we're reinforcing more than one misunderstanding...
I've been thinking about this a lot in the last couple of years. As another thread here pointed out, much of the code in a standard custom business application (and I've built many custom ones) is not particularly specific to that business. There are many levels of application code for managing client processes, logging, demon processes, transactions, connections, etc.
Also, for some sub-domains within the larger problem domain, the data structures may be fairly generic as well. For example, the structures to manage customer accounts, mailing, payments, billing, things like that.
My argument is that there is no reason for a customer of mine to "own" those really generic portions of the app. There is no value in rewriting them for another customer, apart from an hourly rate. What the customer does "own" is the specifics of how they do business, and the data for their business.
Of course, there will be some businesses that will need fancy logic, for example routines to forecast inventory or sales; and those routines might be specific to them and a real competetive advantage.
So my new strategy, which I've used successfully once so far, is to contract with the customer to say that I (or my business) keep and reuse any parts of the code that are not specific to their business. To make it easier, I also put customer-specific into well-identified directories, packages, modules, etc.
I believe what customers are paying for is not the software (in the case of business applications) but my ability to understand their problems and model these into solutions on a software platform. The software is free; I bill for thinking.
what seems absent from this discussion is the notion of free speech, versus free beer.
my understanding of the Free Software Movement's origins are that RMS and colleagues were frustrated that they had no access to source code--thus they couldn't fix problems with software they used at work or school, even software which had been donated. they couldn't fix, learn from, couldn't write better versions, couldn't help their neighbors etc. anybody who's used commercial software should recognize this limitation. the four freedoms embodied in the FSM are about this--the ability to study other people's code, do something with it, change it, fix it.
if the kompany doesn't make source code freely available for their products (any of their products) then you, as a person who may be a programmer, are dependent on them to fix bugs, make changes, etc. you also can't learn from what they've done and come up with something better--something which may not even be a competing product. this type of relationship is frustrating to those of us who are forced to use commercial software packages that are buggy or limited in some way.
i think the question of the value of the software then becomes very difficult to place. software as a commercial product is valued based on its apparent usefulness, dominance in the marketplace, uniqueness, etc. i don't have proof, but i suspect that software is rarely just valued directly in relation to the cost to produce it. companies sell products at a loss to gain market share (thus opening up a wider market for other products), or in other cases, resell products they bought from another company who was already selling it, and where the development cost was either recouped or written off.
the FSM suggests that the value of a software package is not tied to the cost to produce it. this is implicit because as we all know, if the source code is made freely available (or at low cost) and documents are available, savvy users can roll their own distribution and share it, reducing the income of the original provider to (in principle) zero. so the question i have is then, what is the value of a piece of software, if we believe in the freedoms of the FSM?
1) Will.Net appeal more to gearheads who want n degrees of flexibility with their development systems? One of the *strengths* of Java (and C it's been said) is that the language is very simple and very restricted.
Does.Net need to be as complex as it is, or does Microsoft make it more complex (with proprietary architecture and design) to make achieve greater buy-in with developers. It's potentially very lucrative to become a.Net programmer in the next few years. But when you've done so, you'll be a specialist in just a huge bunch of Microsoft technologies. You'll never want to leave, like an Oracle administrator who never goes on to do anything else.
Or, do they make it that complex so that gearheads who like complexity will be attracted to it?
2) If the CLR can host many languages, will its restrictions affect how those languages can be used? Will they become just variations on a common theme? And will that be worse, in the long run, for the proliferation of languages with their own specialties, their own dialects, their own culture?
3) I don't know any Java programmers in the corporate world who will even look at this. I do suspect that a number of VB/(Visual) C++ programmers will love it, because they've been contrained in the last few years on web development using their current MS toolset. So, across the corporate/enterprise arena, we'll see more competition for large web development projects, possibly away from the J2EE fad we saw in the last few years. But maybe that will push more of the common development/architecture technologies for those applications become standardized and commoditized. And that could be good, given how expensive tools and components for the J2EE world are (and how those are a fraction of earlier enterprise technology costs).
I've been working on a project to document software engineering methodology and best practices (eventually to be published and freely available). The content is written in XML. I wrote the DTDs for the basic document types and XSL stylesheets for output to HTML. I've written a few docs already for the system (two, three dozen or more). Some notes on my experience.
1) Editing: I find the XML editors available online to be slow to use. I don't want to click on a tree to navigate through my document--too much mouse work--and I find the format for editing individual nodes is cumbersome if you have a complex document structure. I settled on using a good text editor (EditPlus, not free) with some templates for automatically inserting large node sections that are typically edited in a block. The editor has syntax-highlighting so it's easy to differentiate the XML from the content. I also have template files for quickly starting a new document of each type, with all the basic nodes already pasted within so I can open a new template and start typing.
2) Display: I wrote some simple XSL sheets to start with, that just displayed the XML in a readable, basic HTML format. I have my editor linked to a script that transforms the current XML on command, and opens the HTML in the same editor--so I can quickly preview the results. I use the Apache Xalan XSL processor with Java JDK 1.3. I also have an Apache/Jakarta Ant script to transform all documents on comment. Since I started, I have spent some time improving the layout, but writing a basic XSL for display is not difficult--I recommend having basic ones around (no gifs, simple tables, etc.) for no-nonsense preview of the content.
3) Navigation: I have specific tags in my docs (like reference or ext-reference for linking documents. The XSL generates the appropriate tag for navigation, based on attributes in the tag. My newer approach is to generate either static links or a link to a Java servlet with the page name; the servlet then handles the navigation request. The servlet approach has the advantage that it can eventually transform documents on the fly, allow you to specify a transformation type (e.g. pretty, simple, text-only) and even to pull content from a repository.
4) Content management: Right now I use directories to manage the content, since I support 5 document types, and use the file names to distinguish the content. I spent a bunch of time when I started figuring out the DTDs of the various document types so I would organize content most efficiently and with little or no duplication of intent. I recommend that approach--it's been a lot easier, when I want to write, to identify the document type I want, open a template, and start typing. I think this is where the first real effort comes, not in picking an editor, etc., but in deciding exactly how the information will be categorized. It's important to have searchable content, or content you need to introspect, to be pulled out from the main. For example, in using a reference tag, I can write a verification routine that checks the reference is valid (e.g. if a file, check that the file exists). I try to avoid writing anything I would need to parse out--for example, dumping a code sample write within a text block. I'd rather have a code-sample tag for easy identification.
I'd stress that the biggest hassle has been getting the XSL to work properly and generate readable XML, especially for more involved document structures. It's easy to break and hard to debug! In that vein, I recommend starting with very simple XSLs that output really really simple HTML and building up from there.
Some of my favorites are:
- The C Companion, by Allen Holub. Great discussion of the relationship between C, assembler and machine language.
- The Practical SQL Handbook, by Brown, Darnovsky, others. Great introduction to SQL programming and relational databases. Written for Sybase originally but highly portable.
- Designing Quality Databases Using IDEF1X Information Models, by T Bruce. Excellent discussion of what goes into designing a relational database, the conceptual analysis, classical problems, etc., from someone who's been there. A great introduction into the practice of analysis for people who need to analyze on a daily basis.
- Repetetive Strain Injury, by Pascarelli. 'nuff said.
-pdoubleya!
I work with Java on a daily basis. Some comments:
1) it's extremely portable with no recompilation. At one point I was coding in Microsoft J++ (without using MS extensions) and was able to copy my class files to a Sun server, where they ran with no problem. This was on a multi-tier app with a complex browser applet (using Netscape applet classes), over a CORBA layer, to a relational database. pretty amazing
2) Personally, I think Sun has done an excellent job of keeping Java standard across implementations, and at regulating APIs. Across the board, it takes me a few hours to learn a new API from Sun (and from most anyone else) because the style is so uniform. I think that's a plus.
3) I use Java in programming for businesses, which biases me greatly, I assume. For that purpose, it's excellent all-around. I can worry more about solving the problems and needs of the business, and not worry about (too many) platform-specific details.
just my thoughts.
You can do this, I think, writing a generic utility, because SQL databases should provide "system" or "catalog" tables that give meta-data about the user tables in the system. This means you can query the catalog tables to find out what user tables there are, what the relationships are between them, and what columns they have, then build and execute the SQL statements dynamically to extract the data. The trick is on the import. Unless the tables have exactly the same name and structure in both databases, you'll need to provide some mapping between them. If we assume they do have the same structure, you can use the same catalog tables to write CREATE statements (if necessary) and the INSERTs to load the data. Some tricks: need to watch out for indexes, table triggers, relationship constraints, all of which might prevent a clean load. Also need to check for datatype conversions as necessary. In Java, the JDBC libraries provide an abstraction for catalog information. However, each JDBC driver I've worked with implements this slightly differently, so beware. I found some functions wouldn't work with some drivers at all, and others returned catalog information in different ways (converting all object names to uppercase, for example, regardless of the case in the database). For portability, I'd probably model this as a set of classes that represented an idealized SQL database, then subclass as necessary for particular vendors (ms, mysql, sybase, whatever) to handle idiosyncrasies in naming, syntax, etc. This sounds like it could be a neat project.
Slashdot Mirror
Winzip
EditPlus
Teleport Pro
jEdit
SmartCVS
JDiskReport
FileZilla
PDFFactory
Patrick
Just one correction: Swing was based in (large) part on Netscape's Internet Foundation Classes, which were Netscape's attempt to have a cross-platform GUI component set. Sun and Netscape worked out some deal and Sun took this over, and re-worked and re-branded it as the Java Foundation Classes. See the Wikipedia article here. Cheers! Patrick
As a coincidence, Cringely just posted the latest episode of NerdTV (torrent file: http://pbs.org/cringely/nerdtv/mp4-torrent/redir/h ttp://distribution.nerdtv.net/video/ntv007/ntv007. mp4.torrent)
where he interviews Dan Drake, co-founder of Autodesk. AD bought Nelson's company and tried to get Xanadu to work, but as Drake puts it, it was 3 orders of magnitude from completion. Interesting interview.
I'm active in two FOSS projects, both LGPL, and I think that outside of licensing and philosophy, the most important thing to teach is how one participates in these projects and how it's different from traditional models.
One of the two projects has a titular lead programmer (who started it), but the committers are all welcome to refactor heavily as long as a) they don't break the code, b) they are willing to listen to criticism and discuss their proposals and c) they maintain ownership and don't walk away before the work is finished and completely integrated.
On the other project, there is a separate "incubator" sub-project where new ideas are tested and demoed, discussion is based on that, proposals are made, and the changes then accepted into the main branch.
So how one contributes is one thing.
Another is that different from for-pay work, people may appear and disappear from the project over time, often doing a lot of work and then none for months at a time. It can be lonely--you might have a lot of energy, a lot of ideas, and almost no one to discuss them with. You may be on your own much of the time. The "community" feeling shows itself over long periods of time and during the release cycles.
There's also more direct acknowledgement of contributions by individuals than in for-pay work.
Last point would be that writing software is hard work, and if you're active on a project, you'll likely spend much time, many nights and weekends, writing code without compensation. That can lead to greater pride of ownership, but on the other hand, can lead to burnout as well.
I think the social aspects of FOSS development are some of the most interesting ones to talk about.
Patrick
What sort of validation is provided? Anyone can come up with a protocol that is thinner than XML, XML wasn't meant to be small. XML is readable while still allowing for type checking (basic with DTDs, advanced with Schemas or RelaxNG). Why pass around objects if you aren't going to do type-checking?
Wasn't J. Pointdexter working on this problem over at DARPA? Creating a market of people betting on the next kernel release?
I think this article is just the sort of information we need in the technology community. There has been too much hype about web services in from the marketing departments of IBM, Sun, Microsoft and others. I have the basic grasp of what it does and how it works, though haven't coded with it yet. Mehat's experiences sound very much like my experiences trying out a new, immature toolkit and finding it exciting (in promise) but frustrating (in reality and limitations). Without this sort of ground-level view, it's too hard to tell if web services is an important part of a system architecture, or whether it needs more time.
p!
What I'm surprised at is that nobody on these discussions in the last few days (that I've read) has seen anything reasonable with SCO's position. Put aside the profit motive, the MS-connection, and all, and look at it this way. SCO has purchased a code base, and extended it themselves, that took many many years to solidify and can be used to run "enterprise" services (according to them). Their claim is that Linux could not possibly have achieved the level of stability and reliability if it had all been developed from scratch. Their investigations supposedly revealed that some person(s), apparently from IBM, directly lifted proprietary SCO code and submitted it to the kernel tree.
What's egregious is not that SCO is complaining, but that they are doing it in such a rude manner, looking for a quick buck. I think they have a right to complain if someone took code they owned, developed, nourished, and started giving it away for free--and not just binaries, but the source, which, once distributed on the net, is a non-secret forever more. It would be wrong of IBM to do that, wrong of any programmer to do that.
That said, going for such a large claim against IBM is a response not in line with the damage done to them--unless they can prove that by sharing that code, they lost their crown jewels, and market share because of that. For all we know, this may be code that's used only in very high-volume, large-memory systems, which would be hard to develop on one's own without extensive testing and years of development.
p!
NASA has shown that it can pull together good science when that is its focus: Hubble, the Voyagers, other satellites. What it can not do is manage a complete space program with the vast number of engineering programs to oversee and coordinate.
I suggest the best thing at this point would be to start sub-contracting for systems which others have proven they can build reliably. The Russians, for example, have shown they can achieve reliable, high-capacity payload launches, plus they managed to keep a space station in orbit for a long time. Why not pay the Russian space agency, as a subcontractor, for handling some of this work, such as launching? It would allow NASA to focus on science, where we have good engineers anyway. Get rid of the shuttles! Declare victory and retreat! Nobody, absolutely nobody, thinks they are a good idea (or ever were).
p!yaya
One thought is that the purchaser--the company who wanted the website--didn't feel you'd covered the material well enough. The reason I'm suggesting this (with no insult implied to you), is what you wrote here on /. -- "The contract was not a complex project: a system comprised of database-generated web pages, with file submission and minor document management features." One thing I've found more and more in custom development is that companies are very nervous the more complex their projects get. As a result, they tend to turn to vendors who can assuage their fears about how things might go wrong. Is it possible you took the wrong tack? Maybe when they saw the $5K price, and especially if you said this was "no problem", they thought: uh-oh, he's going to miss something, he won't cover it all. Meanwhile, the other guys were talking about how they were addressing security and scalability and failover and whatever (even if they really weren't). For better or for worse, people sometimes like to be sold to; it increases the value of the thing in their eyes.
The other thing is how, in general, your rates will be judged based on prevailing market rates. If the prevailing market rate for the website's functionality is 100 hours at $150 per hour, then your bid would seem surprisingly (and suspiciously) low. One alternative is, if you are competing at that level, maybe throw in a bid for $12K with a number of useful features that they've been talking about but in a future release. Show them ow for the same (or slightly less) money, they will get much more. Otherwise, if their friends at other companies are spending around $15K for this work as well, they probably won't trust you to do it for $5K. And why should they? Generally, there's no free lunch.
p!yaya
Good technical manuals: WebLogic is expensive, and I wouldn't use it for personal use, but they have great respect IMO for the developer. Their APIs are fully documented in clear, technical language, they have samples for everything useful, and many many FAQs. Their docs are also updated for new releases. I think good docs will make or break a product, unless it's so easy to use that command-line help is enough or it's "intuitive" (like WinZip on Windows)
Straightforward user interface:Even if you have the docs, the truth is I won't read them till I need them. I tend to install the thing and then browse around to see what I can do. If it's an editor, I start typing. If it's a drag and drop GUI builder, I start building. While there's something great about developing your own unique interface and way of looking at the world, at least allow for an "idiot's option" that gets me feeling productive; or, that the tool hasn't gotten in the way of what I'm doing. Kudos to tools like JEdit, for example, which I had up and running and compiling with in maybe an hour. Blahs to APIs like Xerces, which I can use, but which have an absolutely confusing API in some cases (how do you move an Element from one Document to another? where's the changeParent() call?)
Let the FAQs lead the way:A number of others posted that your should publish your knowledge base, but I'd also add that a good FAQ system is a good lead-in for developer interest in your newsgroups. Basically, it will draw people there even if the newsgroups are new. I suspect you'll also spend the early rollout manning the newsgroups yourself. Roll your answers into the FAQs; searching newsgroups is tedious work. The worst thing to find are newsgroups with many, many unanswered threads (like Sun's Java site) and scanty FAQs. JGuru has a very good set of FAQs.
Good luck! Let us all know when it's released.
p!yaya
Another suggestion: just change the name outright to something like "GNU". Not, "GNU/Linux", which sounds weird to my ear anyway. Just "GNU".
Isn't it true that without the hundreds? thousands? of programs written for the GPL under the GNU project, the Linux kernel would be largely useless? Why diss all those people? They chose to distribute their code as part of GNU, not as part of BSD, or in the public domain--they made an explicit choice.
Every time we just use the word "Linux" we're reinforcing more than one misunderstanding...
I've been thinking about this a lot in the last couple of years. As another thread here pointed out, much of the code in a standard custom business application (and I've built many custom ones) is not particularly specific to that business. There are many levels of application code for managing client processes, logging, demon processes, transactions, connections, etc.
Also, for some sub-domains within the larger problem domain, the data structures may be fairly generic as well. For example, the structures to manage customer accounts, mailing, payments, billing, things like that.
My argument is that there is no reason for a customer of mine to "own" those really generic portions of the app. There is no value in rewriting them for another customer, apart from an hourly rate. What the customer does "own" is the specifics of how they do business, and the data for their business.
Of course, there will be some businesses that will need fancy logic, for example routines to forecast inventory or sales; and those routines might be specific to them and a real competetive advantage.
So my new strategy, which I've used successfully once so far, is to contract with the customer to say that I (or my business) keep and reuse any parts of the code that are not specific to their business. To make it easier, I also put customer-specific into well-identified directories, packages, modules, etc.
I believe what customers are paying for is not the software (in the case of business applications) but my ability to understand their problems and model these into solutions on a software platform. The software is free; I bill for thinking.
p!yaya
what seems absent from this discussion is the notion of free speech, versus free beer.
my understanding of the Free Software Movement's origins are that RMS and colleagues were frustrated that they had no access to source code--thus they couldn't fix problems with software they used at work or school, even software which had been donated. they couldn't fix, learn from, couldn't write better versions, couldn't help their neighbors etc. anybody who's used commercial software should recognize this limitation. the four freedoms embodied in the FSM are about this--the ability to study other people's code, do something with it, change it, fix it.
if the kompany doesn't make source code freely available for their products (any of their products) then you, as a person who may be a programmer, are dependent on them to fix bugs, make changes, etc. you also can't learn from what they've done and come up with something better--something which may not even be a competing product. this type of relationship is frustrating to those of us who are forced to use commercial software packages that are buggy or limited in some way.
i think the question of the value of the software then becomes very difficult to place. software as a commercial product is valued based on its apparent usefulness, dominance in the marketplace, uniqueness, etc. i don't have proof, but i suspect that software is rarely just valued directly in relation to the cost to produce it. companies sell products at a loss to gain market share (thus opening up a wider market for other products), or in other cases, resell products they bought from another company who was already selling it, and where the development cost was either recouped or written off.
the FSM suggests that the value of a software package is not tied to the cost to produce it. this is implicit because as we all know, if the source code is made freely available (or at low cost) and documents are available, savvy users can roll their own distribution and share it, reducing the income of the original provider to (in principle) zero. so the question i have is then, what is the value of a piece of software, if we believe in the freedoms of the FSM?
p*ya*ya
1) Will .Net appeal more to gearheads who want n degrees of flexibility with their development systems? One of the *strengths* of Java (and C it's been said) is that the language is very simple and very restricted.
.Net need to be as complex as it is, or does Microsoft make it more complex (with proprietary architecture and design) to make achieve greater buy-in with developers. It's potentially very lucrative to become a .Net programmer in the next few years. But when you've done so, you'll be a specialist in just a huge bunch of Microsoft technologies. You'll never want to leave, like an Oracle administrator who never goes on to do anything else.
Does
Or, do they make it that complex so that gearheads who like complexity will be attracted to it?
2) If the CLR can host many languages, will its restrictions affect how those languages can be used? Will they become just variations on a common theme? And will that be worse, in the long run, for the proliferation of languages with their own specialties, their own dialects, their own culture?
3) I don't know any Java programmers in the corporate world who will even look at this. I do suspect that a number of VB/(Visual) C++ programmers will love it, because they've been contrained in the last few years on web development using their current MS toolset. So, across the corporate/enterprise arena, we'll see more competition for large web development projects, possibly away from the J2EE fad we saw in the last few years. But maybe that will push more of the common development/architecture technologies for those applications become standardized and commoditized. And that could be good, given how expensive tools and components for the J2EE world are (and how those are a fraction of earlier enterprise technology costs).
P *ya*ya
I've been working on a project to document software engineering methodology and best practices (eventually to be published and freely available). The content is written in XML. I wrote the DTDs for the basic document types and XSL stylesheets for output to HTML. I've written a few docs already for the system (two, three dozen or more). Some notes on my experience.
1) Editing: I find the XML editors available online to be slow to use. I don't want to click on a tree to navigate through my document--too much mouse work--and I find the format for editing individual nodes is cumbersome if you have a complex document structure. I settled on using a good text editor (EditPlus, not free) with some templates for automatically inserting large node sections that are typically edited in a block. The editor has syntax-highlighting so it's easy to differentiate the XML from the content. I also have template files for quickly starting a new document of each type, with all the basic nodes already pasted within so I can open a new template and start typing.
2) Display: I wrote some simple XSL sheets to start with, that just displayed the XML in a readable, basic HTML format. I have my editor linked to a script that transforms the current XML on command, and opens the HTML in the same editor--so I can quickly preview the results. I use the Apache Xalan XSL processor with Java JDK 1.3. I also have an Apache/Jakarta Ant script to transform all documents on comment. Since I started, I have spent some time improving the layout, but writing a basic XSL for display is not difficult--I recommend having basic ones around (no gifs, simple tables, etc.) for no-nonsense preview of the content.
3) Navigation: I have specific tags in my docs (like reference or ext-reference for linking documents. The XSL generates the appropriate tag for navigation, based on attributes in the tag. My newer approach is to generate either static links or a link to a Java servlet with the page name; the servlet then handles the navigation request. The servlet approach has the advantage that it can eventually transform documents on the fly, allow you to specify a transformation type (e.g. pretty, simple, text-only) and even to pull content from a repository.
4) Content management: Right now I use directories to manage the content, since I support 5 document types, and use the file names to distinguish the content. I spent a bunch of time when I started figuring out the DTDs of the various document types so I would organize content most efficiently and with little or no duplication of intent. I recommend that approach--it's been a lot easier, when I want to write, to identify the document type I want, open a template, and start typing. I think this is where the first real effort comes, not in picking an editor, etc., but in deciding exactly how the information will be categorized. It's important to have searchable content, or content you need to introspect, to be pulled out from the main. For example, in using a reference tag, I can write a verification routine that checks the reference is valid (e.g. if a file, check that the file exists). I try to avoid writing anything I would need to parse out--for example, dumping a code sample write within a text block. I'd rather have a code-sample tag for easy identification.
I'd stress that the biggest hassle has been getting the XSL to work properly and generate readable XML, especially for more involved document structures. It's easy to break and hard to debug! In that vein, I recommend starting with very simple XSLs that output really really simple HTML and building up from there.
-Pdoubleya
Some of my favorites are: - The C Companion, by Allen Holub. Great discussion of the relationship between C, assembler and machine language. - The Practical SQL Handbook, by Brown, Darnovsky, others. Great introduction to SQL programming and relational databases. Written for Sybase originally but highly portable. - Designing Quality Databases Using IDEF1X Information Models, by T Bruce. Excellent discussion of what goes into designing a relational database, the conceptual analysis, classical problems, etc., from someone who's been there. A great introduction into the practice of analysis for people who need to analyze on a daily basis. - Repetetive Strain Injury, by Pascarelli. 'nuff said. -pdoubleya!
I work with Java on a daily basis. Some comments: 1) it's extremely portable with no recompilation. At one point I was coding in Microsoft J++ (without using MS extensions) and was able to copy my class files to a Sun server, where they ran with no problem. This was on a multi-tier app with a complex browser applet (using Netscape applet classes), over a CORBA layer, to a relational database. pretty amazing 2) Personally, I think Sun has done an excellent job of keeping Java standard across implementations, and at regulating APIs. Across the board, it takes me a few hours to learn a new API from Sun (and from most anyone else) because the style is so uniform. I think that's a plus. 3) I use Java in programming for businesses, which biases me greatly, I assume. For that purpose, it's excellent all-around. I can worry more about solving the problems and needs of the business, and not worry about (too many) platform-specific details. just my thoughts.
You can do this, I think, writing a generic utility, because SQL databases should provide "system" or "catalog" tables that give meta-data about the user tables in the system. This means you can query the catalog tables to find out what user tables there are, what the relationships are between them, and what columns they have, then build and execute the SQL statements dynamically to extract the data. The trick is on the import. Unless the tables have exactly the same name and structure in both databases, you'll need to provide some mapping between them. If we assume they do have the same structure, you can use the same catalog tables to write CREATE statements (if necessary) and the INSERTs to load the data. Some tricks: need to watch out for indexes, table triggers, relationship constraints, all of which might prevent a clean load. Also need to check for datatype conversions as necessary. In Java, the JDBC libraries provide an abstraction for catalog information. However, each JDBC driver I've worked with implements this slightly differently, so beware. I found some functions wouldn't work with some drivers at all, and others returned catalog information in different ways (converting all object names to uppercase, for example, regardless of the case in the database). For portability, I'd probably model this as a set of classes that represented an idealized SQL database, then subclass as necessary for particular vendors (ms, mysql, sybase, whatever) to handle idiosyncrasies in naming, syntax, etc. This sounds like it could be a neat project.