That's what the client asked for. They specifically requested that we find a way to integrate Bricolage (a backend product) with phpBB, a front-end product. The bulletin board has a significantly different look and feel because they set that up and manage it, we don't. Our software does some nifty tricks like automatically spawning a new forum thread for every story, but other than that, we have no control over what they do with this software.
In this regard, I think this is a great example. Our low-cost backend software allowed them to choose a free, open source front-end piece of software and work just fine. Many CMS systems don't allow that. If it looks different, you'll have to talk to them about it. As for the same content in two different threads: they have control over how that stuff is managed. Talk to them.
But what do I know, i'm just some Slashdot schlub.
No, you have a valid point. There have been clients who have not been terribly happy about this. Many of them are expecting all sorts of front-end bells and whistles. As a result, we also provide consultation for those who want those bells and whistles but don't want to shell out the dough of some expensive front-end package.
For example, we recently did Spin.com. These folks came in, knew what they wanted and knew that there was no need to drop a quarter million+ for it (many of our competitors easily run into six figures.) In order to handle some of their front end needs, we integrated phpBB for the bulletin boards and Google Search as their search engine. They get the extras, but still no expensive framework to complicate things.
One key difference between Bricolage and Zope is that we (Bricolage) are entirely back-end. Once we serve the content, there's no overhead of some framework slowing things down. The people can choose to use any technology they want to drive the front end (many folks use PHP). Heck, if they are having performance problem on the front end, they can switch to a different technology and still use Bricolage to manage things on the back end. Many content management systems do not allow this. This is a huge benefit of Bricolage.
Basically, it allows you to manage information on a large scale and present it in a uniform, consistent manner. It's usually as a Web page, but it can be used to manage to RSS feeds, email, newsgroups, etc (and simultaneously, too. One document can be transformed and sent to all of those.) For example, the bulk of our customers use it to ensure their Web sites have a consistent look and feel and data goes through a proper "workflow" process. It's more suitable for large companies that absolutely must manage their data.
For example, a journalist might enter a story in Bricolage and check it in. However, depending on the needs of the company, it's probably not published at that point. Some companies require copy editors to proof the stories and others require a legal department to approve the stories. At that point, a story might get moved to a "publish desk" where a new crop of stories get published, it might get kicked back for revision or it might be published on the spot. By guaranteeing that an appropriate process is followed, content can be managed in a way that suits the needs of an organization.
I should add that I can hardly begin to cover it's features. We have competitors who charge (and get!) six figures for the product we give away for free.
Side note: my father, whose been a programmer for years, doesn't get this. He keeps asking "if it's so good, why do you give it away?" I don't think he'll ever "get" open source:)
It's not "just an app that help (sic) them write news stories to publish on the Web." I can see how you might can get that idea from the screenshots, but as the guy David hired to help develop the next version, I can assure you that this is not correct. When we say (pardon the buzzwords) "enterprise-class content management system", we mean it. It's "Enterprise Class" because it scales to meet the needs of large-scale content management (which can be a multimedia archive instead of text, if you prefer.) Radio Free Asia, Portugal Telecom and the Rand Corporation, and many others who need scalable products have turned to Bricolage because it handles the load.
Further, just because it has a Web front end does not mean that it's just for the Web. We can associate the content with "output channels" that can put out any type of content that a computer can produce. You can manage a print magazine or a bank of monitors in Bricolage, if you so desire. Don't judge the product by screenshots.
OK, maybe my thoughts on this matter are a bit simplistic, but if you consider the Malthusian Catastrophe (sometimes known as the Malthusian Dilemma), it boils down to two things:
Our planet has limited resources
We're using them
While, in theory, some would argue we should adopt economies based upon sustainability rather than growth, I think it's more realistic to say that this will only happen when we have no choice. In the meantime, in our never-ending quest for resources, we can look at those two bullet points and notice that the real limiting factor isn't "resources", but "our planet."
I certainly don't believe we can solve our population problems via space exploration, nor do I think it's likely we're soon going to be in a position to utilize enough space-based resources to make a difference at the bottom of our gravity well. However, we can still spread the human race further and increase our chances of survival (as mentioned in the article) by ensuring that some humans are not dependent on our planet's resources.
But as a last ditch effort to sway those Harvard business school types who really don't understand the long-term benefits we get from space exploration, here's a short list of technologies have been directly a direct result or space research or greatly enhanced by said research:
Apologies in advance if I have misunderstood you, but...
I think you may be missing an important point here. In older languages, you'll find that the bulk of the work was often thrust on the programmer because the programmer was far cheaper than the computer. One need look no further than the horror of JCL and COBOL to see a high level language that still required inordinate amounts of fiddling by the programmer to get it to play nicely with the computer.
Today, we find that the programmer is far more expensive relative to the computer. Simple economics dictates that shifting much of the load from the programmer to the programming language will save money. However, that's not the end of the story. Some applications need raw speed. Others do not. Choosing Python or Perl for device drivers or ray tracing is probably not a good idea. Choosing C or C++ for processing log files is also probably a bad idea (though not always.) An "always/never" dogmatic approach to language choice means that one cannot choose the best tool for the job, but is instead forced to twist every problem in such a way that your favored language is an appropriate solution (or, perhaps just as common, to simply ignore those areas where your favored language is a bad choice.)
In other words, don't be dogmatic. Dogmatism implies that you won't consider new ideas and that's almost always an error, even if the beliefs that you hold as true are true. Developer performance, processor performance and language performance are all factors that should be considered.
Thanks Matt. Really, though, many in the/. crowd just want a chance to take someone down a peg. And while my story's true, you have to admit, it's pretty weird. I can understand a few people doubting me.
I really have no idea. The fact that one of them had a credit card check in his pocket suggests they went through my recycling and found something I forgot to tear up. However, maybe they found something some other way? I just don't know.
I'm looking forward to the police report. One of them (the guy who first walked into the lobby, not the blond kid) swore that he didn't do anything. The blond one seemed rather calm. The police separated them into different cruisers, perhaps so they couldn't get their stories straight. If one of them confesses, I'm sure that will be in the report and then I'll know. Of course, everyone will know, too, as I intend to post the reports as soon as I can.
The final nail for your coffin is that this guy is a known person in PERL circles. He isn't some nameless, faceless teen-something trying to feel important.
You're absolutely correct. I'm a named, faced, mid-thirties guy trying to feel important:)
Wrong answer. Thank you for playing. We have wonderful consolation prizes for you (or not.)
For what it's worth, and as I noted earlier in this thread, I'm actually fairly well-known in the Perl community. I'm a grant manager for the Perl Foundation, a scheduled speaker at the next OSCON, and an occasional technical book reviewer for O'Reilly. If I dared to create a lie this huge, my reputation would be ruined. I generally get job offers because of who I am. That would go away. Regardless of what you may think of my story, I'm not so stupid as to make this up.
They did have a photocopy of ID of one of the thieves. However, the registration (made through hotels.com) was still billed to me. And as for your info about the credit card companies, I know nothing about your experience, but it is vastly different from mine. If you have any credit cards, call and ask to speak to their fraud department (or, more likely, navigate through all of the damned menus they have.) I'm sure they'll be happy to set you straight.
Actually, I mentioned that Costco.com put the charge through with an incorrect expiration date, not an expired one. An expired date is generally kicked out immediately (I've written CC processing software). An incorrect date isn't necessarily kicked back, but it can be checked and it should be.
In this case, I happen to be "Curtis Poe", a grant manager for The Perl Foundation and in the small world of Perl, I'm moderately well-known. If I were caught making up stories like this, my reputation, and possibly my career, would be ruined.
Also, I hope to post the police report when I get it.
That's what the client asked for. They specifically requested that we find a way to integrate Bricolage (a backend product) with phpBB, a front-end product. The bulletin board has a significantly different look and feel because they set that up and manage it, we don't. Our software does some nifty tricks like automatically spawning a new forum thread for every story, but other than that, we have no control over what they do with this software.
In this regard, I think this is a great example. Our low-cost backend software allowed them to choose a free, open source front-end piece of software and work just fine. Many CMS systems don't allow that. If it looks different, you'll have to talk to them about it. As for the same content in two different threads: they have control over how that stuff is managed. Talk to them.
But what do I know, i'm just some Slashdot schlub.
No, you have a valid point. There have been clients who have not been terribly happy about this. Many of them are expecting all sorts of front-end bells and whistles. As a result, we also provide consultation for those who want those bells and whistles but don't want to shell out the dough of some expensive front-end package.
For example, we recently did Spin.com. These folks came in, knew what they wanted and knew that there was no need to drop a quarter million+ for it (many of our competitors easily run into six figures.) In order to handle some of their front end needs, we integrated phpBB for the bulletin boards and Google Search as their search engine. They get the extras, but still no expensive framework to complicate things.
One key difference between Bricolage and Zope is that we (Bricolage) are entirely back-end. Once we serve the content, there's no overhead of some framework slowing things down. The people can choose to use any technology they want to drive the front end (many folks use PHP). Heck, if they are having performance problem on the front end, they can switch to a different technology and still use Bricolage to manage things on the back end. Many content management systems do not allow this. This is a huge benefit of Bricolage.
Basically, it allows you to manage information on a large scale and present it in a uniform, consistent manner. It's usually as a Web page, but it can be used to manage to RSS feeds, email, newsgroups, etc (and simultaneously, too. One document can be transformed and sent to all of those.) For example, the bulk of our customers use it to ensure their Web sites have a consistent look and feel and data goes through a proper "workflow" process. It's more suitable for large companies that absolutely must manage their data.
For example, a journalist might enter a story in Bricolage and check it in. However, depending on the needs of the company, it's probably not published at that point. Some companies require copy editors to proof the stories and others require a legal department to approve the stories. At that point, a story might get moved to a "publish desk" where a new crop of stories get published, it might get kicked back for revision or it might be published on the spot. By guaranteeing that an appropriate process is followed, content can be managed in a way that suits the needs of an organization.
I should add that I can hardly begin to cover it's features. We have competitors who charge (and get!) six figures for the product we give away for free.
Side note: my father, whose been a programmer for years, doesn't get this. He keeps asking "if it's so good, why do you give it away?" I don't think he'll ever "get" open source :)
It's not "just an app that help (sic) them write news stories to publish on the Web." I can see how you might can get that idea from the screenshots, but as the guy David hired to help develop the next version, I can assure you that this is not correct. When we say (pardon the buzzwords) "enterprise-class content management system", we mean it. It's "Enterprise Class" because it scales to meet the needs of large-scale content management (which can be a multimedia archive instead of text, if you prefer.) Radio Free Asia, Portugal Telecom and the Rand Corporation, and many others who need scalable products have turned to Bricolage because it handles the load.
Further, just because it has a Web front end does not mean that it's just for the Web. We can associate the content with "output channels" that can put out any type of content that a computer can produce. You can manage a print magazine or a bank of monitors in Bricolage, if you so desire. Don't judge the product by screenshots.
OK, maybe my thoughts on this matter are a bit simplistic, but if you consider the Malthusian Catastrophe (sometimes known as the Malthusian Dilemma), it boils down to two things:
While, in theory, some would argue we should adopt economies based upon sustainability rather than growth, I think it's more realistic to say that this will only happen when we have no choice. In the meantime, in our never-ending quest for resources, we can look at those two bullet points and notice that the real limiting factor isn't "resources", but "our planet."
I certainly don't believe we can solve our population problems via space exploration, nor do I think it's likely we're soon going to be in a position to utilize enough space-based resources to make a difference at the bottom of our gravity well. However, we can still spread the human race further and increase our chances of survival (as mentioned in the article) by ensuring that some humans are not dependent on our planet's resources.
But as a last ditch effort to sway those Harvard business school types who really don't understand the long-term benefits we get from space exploration, here's a short list of technologies have been directly a direct result or space research or greatly enhanced by said research:
I've ranted a bit more about this in one of my journals.
Apologies in advance if I have misunderstood you, but ...
I think you may be missing an important point here. In older languages, you'll find that the bulk of the work was often thrust on the programmer because the programmer was far cheaper than the computer. One need look no further than the horror of JCL and COBOL to see a high level language that still required inordinate amounts of fiddling by the programmer to get it to play nicely with the computer.
Today, we find that the programmer is far more expensive relative to the computer. Simple economics dictates that shifting much of the load from the programmer to the programming language will save money. However, that's not the end of the story. Some applications need raw speed. Others do not. Choosing Python or Perl for device drivers or ray tracing is probably not a good idea. Choosing C or C++ for processing log files is also probably a bad idea (though not always.) An "always/never" dogmatic approach to language choice means that one cannot choose the best tool for the job, but is instead forced to twist every problem in such a way that your favored language is an appropriate solution (or, perhaps just as common, to simply ignore those areas where your favored language is a bad choice.)
In other words, don't be dogmatic. Dogmatism implies that you won't consider new ideas and that's almost always an error, even if the beliefs that you hold as true are true. Developer performance, processor performance and language performance are all factors that should be considered.
Thanks Matt. Really, though, many in the /. crowd just want a chance to take someone down a peg. And while my story's true, you have to admit, it's pretty weird. I can understand a few people doubting me.
Heh. See you Sunday, Mark :)
I really have no idea. The fact that one of them had a credit card check in his pocket suggests they went through my recycling and found something I forgot to tear up. However, maybe they found something some other way? I just don't know.
I'm looking forward to the police report. One of them (the guy who first walked into the lobby, not the blond kid) swore that he didn't do anything. The blond one seemed rather calm. The police separated them into different cruisers, perhaps so they couldn't get their stories straight. If one of them confesses, I'm sure that will be in the report and then I'll know. Of course, everyone will know, too, as I intend to post the reports as soon as I can.
You're absolutely correct. I'm a named, faced, mid-thirties guy trying to feel important :)
Wrong answer. Thank you for playing. We have wonderful consolation prizes for you (or not.)
For what it's worth, and as I noted earlier in this thread, I'm actually fairly well-known in the Perl community. I'm a grant manager for the Perl Foundation, a scheduled speaker at the next OSCON, and an occasional technical book reviewer for O'Reilly. If I dared to create a lie this huge, my reputation would be ruined. I generally get job offers because of who I am. That would go away. Regardless of what you may think of my story, I'm not so stupid as to make this up.
They did have a photocopy of ID of one of the thieves. However, the registration (made through hotels.com) was still billed to me. And as for your info about the credit card companies, I know nothing about your experience, but it is vastly different from mine. If you have any credit cards, call and ask to speak to their fraud department (or, more likely, navigate through all of the damned menus they have.) I'm sure they'll be happy to set you straight.
Actually, I mentioned that Costco.com put the charge through with an incorrect expiration date, not an expired one. An expired date is generally kicked out immediately (I've written CC processing software). An incorrect date isn't necessarily kicked back, but it can be checked and it should be.
I know the feeling. I love my G4 iBook, but it runs about as fast as a one-legged greyhound. Setiathome doesn't seem like a good choice.
No worries. I don't get riled up too easily. At least not online. I've embarrassed myself a time or two doing that, so I try to avoid it now.
That's a fair question.
In this case, I happen to be "Curtis Poe", a grant manager for The Perl Foundation and in the small world of Perl, I'm moderately well-known. If I were caught making up stories like this, my reputation, and possibly my career, would be ruined.
Also, I hope to post the police report when I get it.
Yup. I'm the same Ovid.