In addition to these six points, tool support is also important.
I would make a slight ammendment to point 3. It's not the maturity at the time of your decision, it's the maturity at the time of your expected release date. Obviously, that would be a projection into the future which is uncertain. It is also uncertain to assume that the maturity of a framework is always increasing.
Wrong. It does not explain what belongs to a silo. I see the word silos - nominative or accusative plural, but no posessive singular.
Ah, you're not technical. That explains the spelling correction. Here is the relevant excerpt.
The companies that survived the influx of designers and marketing folks often relegated the survivors to their own separate silos. Marketing people got one org tree, developers got another. Artists and usability folks in most cases were shoved in random back corners to rot in black despair. Many groups were so busy protecting their domain that it was surprising that software got released at all. Release dates slipped by multiple years as the development talent stagnated is a cesspool of misplaced process.
Permit me to translate for you. Marketing is in one silo. Development is in another silo. Artists and usability folks are in their own silo. The marketing and development silos each have more political power than the artists/usability silo. The word silo here is not to be taken too literally. On a farm, you would put grain in one silo and hay in another. You wouldn't mix them up. The reference here indicates that members of these professions don't communicate well. Misunderstandings ensue and feelings get hurt. The response to that is they stop trying to communicate at all. The isolation of these professions causes a lack of communication that results in inefficiency and missed deadlines.
Their developer APIs are the best of any major offering.
That was interesting. Thanks for the link. It looks like yahoo is usingJSON for their wire protocol. I find that to be interesting for two reasons. The first is that it is not an XML based protocol. The second reason is that JSON is also the wire protocol for the ironically named AJAX.NET.
I wonder who else is developing JSON based APIs and if that is going to be the next big thing?
Although I was programming on other computers before then, the first "class B computing device" that I actually owned was the HP41CV which I upgraded with a card reader and extended memory and used it to program an unbeatable tic-tac-toe application. Wh00t!
May I intrude here with a recommendation of Randy Komisar's "The Monk and the Riddle?" The main character of this book has close relationships with various VS interests. In the story, he tries to help a fledgling startup acquire VC money with advice about their business plan. He also talks about the "deferred life plan" versus the "real life plan" and that your business should be something you are passionate about and not just all about the bottom line.
Right. Also, the original poster expressed a desire for ease of installation. I detected that perhaps a simpler development model might also be desireable. Perhaps that is why so many posters here claim that VB is the way to go. If programmatic image generation is required, then VB is no simpler than Tcl/Tk. There is about the same amount of cognitive overhead to the Tk Canvas widget than there is to the System.Drawing.Graphics object.
Of course, if the original poster needs an editable grid, then that's a different story.
Last year, the company that I am working for had an interest in implementing a CMS system for in-house purposes. I ended up evaluating both the Plone/Zope and MSFT's SP/CMS application stacks. I used to work for a portal infrastructure ISV so it was not a big stretch for me to do this.
I was amazed at how lacking the proprietary (and fairly expensive) stack was and at how wonderfully feature rich and complete the open source stack turned out to be. It was a no-brainer to pick Plone/Zope over SP/CMS yet the CEO balked over the OSS choice because of the perceived lack of support. We ended up dropping the whole thing.
there are very few things I could say that IntelliJ does that Eclipse doesn't in the Java editor
I haven't kept up with either product. Three years ago, everyone in the Java shop that I was working in at that time always picked IntelliJ over Eclipse. They all swore by the refactoring support that IntelliJ had.
Has Eclipse caught up with IntelliJ with regards to refactoring support?
I have problems with JSF...Everything is a post...The web is transactional, not event driven
You're not going to like ASP.NET either. The reason why these two technologies are being compared here is precisely because they both attempt to make the web development experience (which, as you say, is transactional) look more like a windowing application development experience (which is event driven).
I guess that the theory why this type of approach is popular is that there are many developers out there who are having trouble transitioning from event driven coding to transaction driven coding. I don't know if that's really true or not. I, myself, had no trouble making the paradigm shift but that may be because I was coding back in the transactional days of timesharing with 3270 and curses style screens. Everything old is new again.
I see your point regarding using source code control for change comments. The issue that I have run into putting change comments in the code itself is one that also happens over time and multiple changes.
Here is an example, let's say you change line 188 to fix defect 2287. Next week, another developer needs to change the same line to fix defect 3012. Does that developer append on to your comment or overwrite your comment? What if the developer completely changed line 188 so that your changes were lost?
I guess that there is no perfect answer so you end up putting change comments in both the code and in the CVS (or similar) system. The downside of that is the wasted resources and potential for error in duplicitous effort.
Code comments are only one form of developer documentation. Other forms include design and discovery docs (e.g. UML) and change comments (e.g. this change fixes bug 2938). Put design/discovery docs in an Intranet collaboration site. Wiki or any CMS such as Plone are good technologies for this. Put change comments in your source code control system.
Code comments should answer why, not what. As stated elsewhere, commenting is not a replacement for compentency. Any compentent developer can read most business application style programming and figure out what is going on. What you cannot read from the code was that meeting where some influential user or other relevant stakeholder insisted on a certain approach or placed high value on a certain outcome.
Code comments should not insult the intelligence of your average programmer. If you are coding a simulated annealing or genetic programming algorithm, then providing a URL to the appropriate material in the code is sufficient. If you are looping through some recordset for search or data aggregation purposes (which is about 90% of your business application coding), then you don't really need to provide a comment to the affect that that is what you are doing.
The bi-directional code gen approach does seem to be popular with the Borland and IBM camps. My guess is that approach is perceived to be desireable from that class of developers who have trouble grasping the highly abstract concept of Model Driven Software Development. You have a bug with a page so you fix the template but you have to be careful that your fix doesn't break the other pages generated by that template. It can be very tricky with certain types of bugs.
MSFT goes the "wizard" route which saves the keystrokes for a one-time template driven code gen. It's much easier to implement than the bi-directional route and adresses the same keystroke saving need at least initially. I find that I'm able to get by with the wizardly MSFT approach as long as I keep strict on the "full separation of concerns" and "loose coupling" stuff. If you minimize the need to make changes to the wizard output, then you don't lose much when you need to run the wizard again.
The maintain the generator and the input to the generator but never touch the output of the generator approach is the most flexible and adaptable but requires the smartest developers.
I tried PyDev for Eclipse but couldn't get the debugging to work. When I installed plone, I found PythonWin in the program files menu. That's the best editor/debugger that I have found for python development so far. It is much faster than Eclipse. Statement completion is spotty for those who like that sort of thing. PythonWin is also Windows only whereas PyDev for Eclipse is cross platform. PythonWin can edit/debug any python program. It is not really tied to plone.
Here's two more cases. I'm editing a document for "what if" purposes and I forgot to do the "save as" first. This happens a lot in spreadsheets. The second case is typical in customer order applications where the operator sets up a complicated order with a customer only to have the customer cancel out when the total is revealed and the customer must present the credit card number.
For another low fidelity mockup tool, try inkscape. Mockups and prototypes are two different animals. There is no interactivity with mockups unless they are talked though by a facilitator with the relevant stakeholders. This is called a paper prototype. A real prototype is an actual application that can be executed. It is usually somewhat limited in capability and tends to have nothing designed in it for scalability, security, portability, performance, etc. As stated earlier, prototypes can be throw away or not. If not throw away, then the tools you use for the prototype are the exact same tools that you are planning to use for the real thing.
This kind of attitude I am certain holds back many people who would be adopters and great supporters of Linux.
True
All of this isn't to say there aren't crappy VB coders - but there are just as many crappy C, C++, Perl, Python, etc coders as there are crappy VB coders.
I think that a more meaningful correlation can be drawn between coding talent and toolset than between coding talent and language. A good dividing line seems to be painting GUI. A talented coder can do it by hand. An untalented coder needs a screen painter tool. I believe that there are more untalented VB coders than there are C++ coders because Microsoft does a better job at selling VB than Trolltech does at selling Qt Designer.
Another meaningful correlation just may be between coding talent and number of programming languages. Untalented VB coders know only VB. Talented VB coders most probably know multiple development languages and application stacks. So the need for a VB tool in Linux is not a significant driver for increasing adoption of Linux. The machine O.S. becomes irrelevant once you learn Java.
...amazed thy MySQL has been able to gain the popularity it has without features like stored procs...
Many ISVs sell products that are DB vendor neutral yet still use a relational database. In that scenario, you always use the "lowest common denominator" approach. This results in CRUD style SQL embedded within the code and the relational DBMS used as a fancy ISAM. Everything else is handled procedurally within the app itself. The performance hit of always using dynamic SQL is offset by copious amounts of caching.
That is why MySQL has been so popular. If customer X has religion over DB vendor Y, then ISV Z plugs their app into that and the deal is saved. If customer X has no religion with regards to DB vendor, then ISV Z uses MySQL and folds the cost (which is minimal) into the cost of their product.
Slashdot Mirror
In addition to these six points, tool support is also important.
I would make a slight ammendment to point 3. It's not the maturity at the time of your decision, it's the maturity at the time of your expected release date. Obviously, that would be a projection into the future which is uncertain. It is also uncertain to assume that the maturity of a framework is always increasing.
Has anyone here tried Open Architecture Ware?
Ah, you're not technical. That explains the spelling correction. Here is the relevant excerpt.
The companies that survived the influx of designers and marketing folks often relegated the survivors to their own separate silos. Marketing people got one org tree, developers got another. Artists and usability folks in most cases were shoved in random back corners to rot in black despair. Many groups were so busy protecting their domain that it was surprising that software got released at all. Release dates slipped by multiple years as the development talent stagnated is a cesspool of misplaced process.Permit me to translate for you. Marketing is in one silo. Development is in another silo. Artists and usability folks are in their own silo. The marketing and development silos each have more political power than the artists/usability silo. The word silo here is not to be taken too literally. On a farm, you would put grain in one silo and hay in another. You wouldn't mix them up. The reference here indicates that members of these professions don't communicate well. Misunderstandings ensue and feelings get hurt. The response to that is they stop trying to communicate at all. The isolation of these professions causes a lack of communication that results in inefficiency and missed deadlines.
You're welcome.
On the server side ...
You got me on the spelling error. To answer your first question, you should just RTFA.
Scrum is another development process that attempts to address the "silo's of expertice" problem.
That was interesting. Thanks for the link. It looks like yahoo is using JSON for their wire protocol. I find that to be interesting for two reasons. The first is that it is not an XML based protocol. The second reason is that JSON is also the wire protocol for the ironically named AJAX.NET.
I wonder who else is developing JSON based APIs and if that is going to be the next big thing?
Although I was programming on other computers before then, the first "class B computing device" that I actually owned was the HP41CV which I upgraded with a card reader and extended memory and used it to program an unbeatable tic-tac-toe application. Wh00t!
May I intrude here with a recommendation of Randy Komisar's "The Monk and the Riddle?" The main character of this book has close relationships with various VS interests. In the story, he tries to help a fledgling startup acquire VC money with advice about their business plan. He also talks about the "deferred life plan" versus the "real life plan" and that your business should be something you are passionate about and not just all about the bottom line.
Actually, you'll learn
Don't forget the product placement angle.
Right. Also, the original poster expressed a desire for ease of installation. I detected that perhaps a simpler development model might also be desireable. Perhaps that is why so many posters here claim that VB is the way to go. If programmatic image generation is required, then VB is no simpler than Tcl/Tk. There is about the same amount of cognitive overhead to the Tk Canvas widget than there is to the System.Drawing.Graphics object.
Of course, if the original poster needs an editable grid, then that's a different story.
I just did. Thanks for the idea. Here was their response.
1) We don't build any Plone-based systems, so if that's a requirement, you needn't bother sending the RFP to us.Last year, the company that I am working for had an interest in implementing a CMS system for in-house purposes. I ended up evaluating both the Plone/Zope and MSFT's SP/CMS application stacks. I used to work for a portal infrastructure ISV so it was not a big stretch for me to do this.
I was amazed at how lacking the proprietary (and fairly expensive) stack was and at how wonderfully feature rich and complete the open source stack turned out to be. It was a no-brainer to pick Plone/Zope over SP/CMS yet the CEO balked over the OSS choice because of the perceived lack of support. We ended up dropping the whole thing.
I haven't kept up with either product. Three years ago, everyone in the Java shop that I was working in at that time always picked IntelliJ over Eclipse. They all swore by the refactoring support that IntelliJ had.
Has Eclipse caught up with IntelliJ with regards to refactoring support?
You're not going to like ASP.NET either. The reason why these two technologies are being compared here is precisely because they both attempt to make the web development experience (which, as you say, is transactional) look more like a windowing application development experience (which is event driven).
I guess that the theory why this type of approach is popular is that there are many developers out there who are having trouble transitioning from event driven coding to transaction driven coding. I don't know if that's really true or not. I, myself, had no trouble making the paradigm shift but that may be because I was coding back in the transactional days of timesharing with 3270 and curses style screens. Everything old is new again.
I see your point regarding using source code control for change comments. The issue that I have run into putting change comments in the code itself is one that also happens over time and multiple changes.
Here is an example, let's say you change line 188 to fix defect 2287. Next week, another developer needs to change the same line to fix defect 3012. Does that developer append on to your comment or overwrite your comment? What if the developer completely changed line 188 so that your changes were lost?
I guess that there is no perfect answer so you end up putting change comments in both the code and in the CVS (or similar) system. The downside of that is the wasted resources and potential for error in duplicitous effort.
In addition, consider the following points.
The bi-directional code gen approach does seem to be popular with the Borland and IBM camps. My guess is that approach is perceived to be desireable from that class of developers who have trouble grasping the highly abstract concept of Model Driven Software Development. You have a bug with a page so you fix the template but you have to be careful that your fix doesn't break the other pages generated by that template. It can be very tricky with certain types of bugs.
MSFT goes the "wizard" route which saves the keystrokes for a one-time template driven code gen. It's much easier to implement than the bi-directional route and adresses the same keystroke saving need at least initially. I find that I'm able to get by with the wizardly MSFT approach as long as I keep strict on the "full separation of concerns" and "loose coupling" stuff. If you minimize the need to make changes to the wizard output, then you don't lose much when you need to run the wizard again.
The maintain the generator and the input to the generator but never touch the output of the generator approach is the most flexible and adaptable but requires the smartest developers.
I tried PyDev for Eclipse but couldn't get the debugging to work. When I installed plone, I found PythonWin in the program files menu. That's the best editor/debugger that I have found for python development so far. It is much faster than Eclipse. Statement completion is spotty for those who like that sort of thing. PythonWin is also Windows only whereas PyDev for Eclipse is cross platform. PythonWin can edit/debug any python program. It is not really tied to plone.
Here's two more cases. I'm editing a document for "what if" purposes and I forgot to do the "save as" first. This happens a lot in spreadsheets. The second case is typical in customer order applications where the operator sets up a complicated order with a customer only to have the customer cancel out when the total is revealed and the customer must present the credit card number.
For another low fidelity mockup tool, try inkscape. Mockups and prototypes are two different animals. There is no interactivity with mockups unless they are talked though by a facilitator with the relevant stakeholders. This is called a paper prototype. A real prototype is an actual application that can be executed. It is usually somewhat limited in capability and tends to have nothing designed in it for scalability, security, portability, performance, etc. As stated earlier, prototypes can be throw away or not. If not throw away, then the tools you use for the prototype are the exact same tools that you are planning to use for the real thing.
True
All of this isn't to say there aren't crappy VB coders - but there are just as many crappy C, C++, Perl, Python, etc coders as there are crappy VB coders.I think that a more meaningful correlation can be drawn between coding talent and toolset than between coding talent and language. A good dividing line seems to be painting GUI. A talented coder can do it by hand. An untalented coder needs a screen painter tool. I believe that there are more untalented VB coders than there are C++ coders because Microsoft does a better job at selling VB than Trolltech does at selling Qt Designer.
Another meaningful correlation just may be between coding talent and number of programming languages. Untalented VB coders know only VB. Talented VB coders most probably know multiple development languages and application stacks. So the need for a VB tool in Linux is not a significant driver for increasing adoption of Linux. The machine O.S. becomes irrelevant once you learn Java.
correct
Many ISVs sell products that are DB vendor neutral yet still use a relational database. In that scenario, you always use the "lowest common denominator" approach. This results in CRUD style SQL embedded within the code and the relational DBMS used as a fancy ISAM. Everything else is handled procedurally within the app itself. The performance hit of always using dynamic SQL is offset by copious amounts of caching.
That is why MySQL has been so popular. If customer X has religion over DB vendor Y, then ISV Z plugs their app into that and the deal is saved. If customer X has no religion with regards to DB vendor, then ISV Z uses MySQL and folds the cost (which is minimal) into the cost of their product.