Re: Content management systems
On Tue, 09 Apr 2002 10:17:00 -0400 Aaron Ross [EMAIL PROTECTED] wrote: For community sites, use Slash - the engine behind slashdot (http://www.slashcode.com) - there's even a book about it. You should also check out scoop (http://scoop.kuro5hin.org/), the engine that runs Kuro5hin.org. It's also written for modperl, and IMHO has some extra community features that makes it better than slash for more democratic sites where there are no editors like on /. who decide what stories get posted. Oh, and it does have diaries. ;-) Does anyone know of a more portal oriented engine? in addition to discussions and articles, a calendar, object level access control, polls, approval based content management. A friend has to put together a community portal site for the university he works for, on biological terrorism, no less! So far, we have been unable to find anything in perl that provides the functionality needed. The ArsDigita code seems pretty good, but it's seems to be somewhat adrift and sloppy at this point. have you looked at openacs, http://www.openacs.org? marc Zope provides lot of features, but seems to be a closed little world, ie. it's own db and it's own templating language. Anybody know of something in mod_perl with this out of the box functionality in addition to content management? -- aaron
Re: mod_perl vs. C for high performance Apache modules
I know this sounds kind of simple minded but why not bench test the site, set everything up in the office get a good switch plug the site into 1 port and 5-10 client boxes with some load testing software and plug it in to the same switch and beat the crap out of it. After you do this for a while and find all the hot spots show it to the customer and go here it works. marc - Original Message - From: Matt Sergeant [EMAIL PROTECTED] To: Jeff Yoak [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 15, 2001 3:24 AM Subject: Re: mod_perl vs. C for high performance Apache modules On Fri, 14 Dec 2001, Jeff Yoak wrote: All, I wasn't sure what volume of response to expect when I originally wrote. Thank you all for the comments that you all are making. They are helping. Given that the response is fairly high, I'm waiting for stuff to roll in rather than replying to each of you. Don't think it is falling on unappreciating ears. :-) To respond to a few recurring comments / questions: Me? I've spent most of the last four years working on mod_perl-based stuff and most of the last eight working with Perl. Actually I've worked with folks who were involved with some of the projects you've mentioned, having been at idealab!, a parent of eToys and CitySearch. One of the original (THE original?) developer at CitySearch was probably the most helpful mentor / teacher I've ever worked with. I programmed in C a lot early in my career, but at this point I couldn't write anything substantial without brushing up, and frankly wouldn't care to. It just isn't as fun to work with C. But then, the argument, But if you used C, you wouldn't get to work with ME! may not convince some of these people with their values all screwed up... ;-) Actually that would be my argument. When you're getting investors in, the primary thing they should be looking to buy into is the quality of the people there, not necessarily the code, because only one out of those two can be fixed easily (even in our current times, totally replacing a programming team is a difficult thing to do). I write C. I write Perl. And I combine them both to good effect. But, I wouldn't even consider writing anything but time critical routines in C - I do as much as possible in Perl for the following reasons: - It's fast enough. - It's safer. - It has a built in test harness (Test::Harness). - It's more fun. - It's faster to develop in. - It's OO, and that saves me time and effort. - It has an infinitely better community than C. The last point is probably my favourite, though probably means bugger all to an investor. -- !-- Matt -- :-Get a smart net/:-
Re: Upgrading mod_perl on production machine (again)
make 2 directories: /opt/local1 and /opt/local/2 do an original install in /opt/local1, perl http mod_perl what ever packages you need etc. when it is time to upgrade do a new install in /opt/local2 of what you need, run the httpd on an off port, i.e. port 8765, until you get the new stuff working correctly. turn off the old httpd and move the new httpd to port 80, now you have achieved upgrade with a clean name space. when you are sure that everything is working backup /opt/local1 and delete all the files in it. the next upgrade you need to do use /opt/local1 as the build area. marc - Original Message - From: "rolf van widenfelt" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: "Bill Moseley" [EMAIL PROTECTED] Sent: Friday, January 19, 2001 3:09 PM Subject: Re: Upgrading mod_perl on production machine (again) face it, you are trying to perform surgery on a live subject... with all the Makefiles you'll be making, (httpd, modperl, perl...) you're bound to slip on one of them and install over some of your existing stuff. i went thru a conflict like this once, and avoided it by simply getting a second machine, and installing all the new stuff there. but, if someone can offer a procedure for setting up two independent httpd+modperl+perl environments on one machine it would be pretty interesting! (sorry, if this was already outlined in the responses last Sept) -rolf Bill Moseley [EMAIL PROTECTED] writes: This is a revisit of a question last September where I asked about upgrading mod_perl and Perl on a busy machine. IIRC, Greg, Stas, and Perrin offered suggestions such as installing from RPMs or tarballs, and using symlinks. The RPM/tarball option worries me a bit, since if I do forget a file, then I'll be down for a while, plus I don't have another machine of the same type where I can create the tarball. Sym-linking works great for moving my test application into live action, but it seems trickier to do this with the entire Perl tree. Here's the problem: this client only has this one machine, yet I need to setup a test copy of the application on the same machine running on a different port for the client and myself to test. And I'd like to know that when the test code gets moved live, that all the exact same code is running (modules and all).
Re: Concurrenty access to a log file!!!
I don't know if this helps but when you log something add the process ID to the log message. Then you should be able to trace what process is running what, look at : http://httpd.apache.org/docs/mod/mod_log_config.html#formats to tell you how to set up custom log formats, %p gives you the pid, there are some other things that could be useful to you as well. And just use Apache's standard logging. marc - Original Message - From: Edmar Edilton da Silva [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, 8. December 2000 14:46 Subject: Concurrenty access to a log file!!! Hi all, I have installed on my machine the mod_perl module and exists a lots perl scripts running under mod_perl. I am doing some tests and I need that all call to these perl scripts write in a log file. How can there are a lots scripts running to the same time, I need to control the processes of write. Please, can anyone give me any hint about it? Is there any doc on the Internet that I can use? Thanks for all help... Edmar Edilton da Silva Bacharel em Ciência da Computacão - UFV Mestrando em Ciência da Computacão - UNICAMP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
I don't know about that, getting the correct version of perl, mod_perl. apache and all the preconfigured modules together and configuring cpan... as apposed to installing DBD::Postgres(uses XS), hell I could stick gcc postgres and open ldap in the package. krap I just gave my self more work. Here is the list so far: apache postgres openldap perl mod_perl libnet configure CPAN DBI DBD::CSV DBD:Pg BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs glibc, I think berkelyDB perl module GCC gmake This gives you a nice base system and everything you need to add stuff to it. Now I have 2 questions for the list: 1: is this a good idea or a waste of my time 2: did I forget anything marc - Original Message - From: barries [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED] Cc: mod_perl list [EMAIL PROTECTED]; Marc Spitzer [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 7:12 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. you get a basic prototyping db and you can add other drivers as you need them. And the package needs to specify the version of gcc it was built with, so you can add dso's and/or perl XS modules. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Thanks for pointing that out, or I could just use compress. As far as the $$$ goes you need to spend money to start a business lets see if there is a market first. Another thing we could add is interbase to the list or break it up into 3 or more packages that are integrated out of the box, call it rev 2( with no rev 1 yet). here is what I see if I do that later: 1: apache/perl/modperl/dbi/dbd for all supported db and there client code/ldap client 2: open ldap/berkelydb 3: postgress 4: interbase 5: mysql ... more stuff here N: auxiliary package gcc/gmake and what ever else these components would all have to work out of the box with each other, I install 1 on my web server and 2 on my ldap box and it works or I install both on 1 box and it works. Everything should go under 1 directory /opt/something/(apache|ldap|postgress) etc. This will be a good deal of not fun work though. The way to idiot proof something is to not listen to idiots, this is where it goes and that is the end of it. Give people a list of where each default is web root, datafiles for interbase postgres openldap in a step by step pre install guide and have them start at step 1 and go to step N and you have installed the package(s) you need. marc - Original Message - From: Jimi Thompson [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 13:40 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) Marc, In order to be kind to newbie's, you will need to mention tar and gnu zip which don't come standard on some flavors of Unix. In my case Solaris 2.6 only has tar. Zip must be installed. Also, you are going to need to at least point them to documentation. Maybe we could make extra $$$ selling tech support for your bundle (a la Red Hat)??? The extra cabbage could go to buying ads. I think the goal of the "total installation" should be something akin to M$ Office if you are aiming at the corporate/business user. PHB's like things that they feel like they can control. I have no idea how you could idiot proof this, though, unless you set LOTS of defaults. Marc Spitzer wrote: I don't know about that, getting the correct version of perl, mod_perl. apache and all the preconfigured modules together and configuring cpan... as apposed to installing DBD::Postgres(uses XS), hell I could stick gcc postgres and open ldap in the package. krap I just gave my self more work. Here is the list so far: apache postgres openldap perl mod_perl libnet configure CPAN DBI DBD::CSV DBD:Pg BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs glibc, I think berkelyDB perl module GCC gmake This gives you a nice base system and everything you need to add stuff to it. Now I have 2 questions for the list: 1: is this a good idea or a waste of my time 2: did I forget anything marc - Original Message - From: barries [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED] Cc: mod_perl list [EMAIL PROTECTED]; Marc Spitzer [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 7:12 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. you get a basic prototyping db and you can add other drivers as you need them. And the package needs to specify the version of gcc it was built with, so you can add dso's and/or perl XS modules. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jimi Thompson Web Master L3 communications "It's the same thing we do every night, Pinky." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [certification]
I agree with Eric, for consultants you should focus on skills and brains and for employees you should focus on BRAINS. They will be there long enough to pick up the skills and pay you back for the time you spent training them. Remember smart people learn fast so it is not that much time spent on training. Also this will build loyalty and that translates into lower turnover. marc ps I have never done any hiring in my life. - Original Message - From: Eric Strovink [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 12:52 Subject: Re: [certification] Somebody wrote: If I'm way off base, please let me know. I'm spending considerable brain power on this idea and if I'm wasting it, I need to know. I don't have much spare brain power and I could use it to try to figure out my wife . . . You're way off base. Figure out the wife. I've never hired a "certified" engineer, and almost without exception the ones I've come across were empty sacks of shit. In fact, I've had great success doing exactly the opposite, and *hiring the wrong guy*. Take a person who's been writing compiler back ends for the last 10 years. This person is constantly pigeonholed by every headhunter out there into yet another compiler job, and he'd give his eye teeth to do something different. You hire him for something completely different, and he ends up being the most enthusiastic and productive person you've got, because everything's new and exciting to him. And believe me, folks, if he can write the back end to a compiler, he can figure out mod_perl. Or, I could hire Ferd over here, with a limp certificate from Randal saying he's passed some clever little test on the six most obscure ways to mumble. Uh, no thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
what about emacs? It has syntax high lighting/coloring/indenting, easy use of version control, the ability to do compile goto error line(fix) then debug, menu's that work under gui or tty and a bunch of features that I have not even learned yet. The version control is what sold me it is trival to use it and that sold me. marc - Original Message - From: brian moseley [EMAIL PROTECTED] To: Matthew Kennedy [EMAIL PROTECTED] Cc: mod_perl list [EMAIL PROTECTED] Sent: Wednesday, 6. December 2000 15:39 Subject: Re: mod_perl advocacy project resurrection On Wed, 6 Dec 2000, Matthew Kennedy wrote: ActiveState has built an Perl/Python IDE out of Mozilla: http://www.activestate.com/Products/Komodo/index.html too bad it's windows only :/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
the only thing I would add is DBI and DBD:::CSV, you get a basic prototyping db and you can add other drivers as you need them. And the package needs to specify the version of gcc it was built with, so you can add dso's and/or perl XS modules. I am more a sys admin then a programmer but I would be willing to build a Solaris package for this. IFF I find the time I would also look into doing it for FreeBSD and possibility OpenBSD, they both use the same packaging standard. I will not have time to start this for about 2 weeks though. Please keep in mind that I have no experience with mod_perl so I would need some noble soul to test the krap out of it. marc spitzer - Original Message - From: kevin montuori [EMAIL PROTECTED] To: Aaron E. Ross [EMAIL PROTECTED] Cc: Dave Rolsky [EMAIL PROTECTED]; brian moseley [EMAIL PROTECTED]; mod_perl list [EMAIL PROTECTED] Sent: Wednesday, 6. December 2000 17:17 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) Aaron E Ross writes: aer the possibility of being able to untar one package to get aer mod_perl w/ persistent db connections, [c.] is very glamorous! agreed. but fundamentally impossible. what database are you going to provide persistent connections to? mysql? not on my solaris box you're not, unless you're going to include mysql in your distribution. besides, i want sybase. ok, so skip the database and use DBM files, gdbm's everywhere, right? again, not (standard, anyway) on solaris. so, package up gdbm too. you can see where that's going. i think providing a mod_perl framework in which applications can be written is a noble idea. i think recommending a particular solution is great -- lots of people who hack mod_perl day in and day out can't keep up with all the new modules/products, a summary of what's available would be useful to new programmers and veterans alike. i also think that this is a case of walking before running: putting together a summary document of mod_perl development environments (mason, axkit, ao, c.) has (to the best of my knowledge) eluded us so far, the notion that we could bundle some together and get them to work is pie in the sky thinking. whoever said that packaging all this stuff together (i think it was MS or BM) is extremely difficult is absolutely correct. in my current shop, we have enough trouble creating packages that work on both solaris 6 and 8 without any modification, and we're pretty good at this sort of thing. bundling *just* mod_perl and apache in one package that can be build and installed by pushing a button seems like an excellent short term goal. for some people just starting out, you'd be a folk hero if you provided just this. (i'm not down on the idea really, but if packaging is going to be considered as a form of advocacy, it'd be nice if we attacked it in easy to digest chunks. starting with the two packages, and perhaps a couple sample applications and moving on from there.) aer except for transaction management, which is apparently of aer questionable value, i don't think anyone is claiming that transaction management is of questionable value -- when you need it, you need it; there's no substitute. (unless you consider reconciling databases by hand a substitute.) cheers, k. -- kevin montuori support independent booksellers -- http://www.booksense.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] HTTP::GHTTP
Simple useful things get adopted quickly, more complex useful things take more time. marc - Original Message - From: "Matt Sergeant" [EMAIL PROTECTED] To: "clayton cottingham" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 22, 2000 1:37 PM Subject: Re: [ANNOUNCE] HTTP::GHTTP On Wed, 22 Nov 2000, clayton cottingham wrote: man that is one crazy module! in under ten minutes i had the thing running! kudos again to you matt! I'd be happy if it wasn't turning out to be more popular than AxKit! *sigh* :-) -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Putting together the TPC mod_perl track
what is AO? thanks marc - Original Message - From: "Nathan Torkington" [EMAIL PROTECTED] To: "Matt Sergeant" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 01, 2000 12:14 PM Subject: Re: Putting together the TPC mod_perl track Matt Sergeant writes: Since its getting towards the end of the year, should we be thinking of putting together a mod_perl track for TPC? I've got a room allocated to mod_perl for two days of conference at the next OScon. With this group's blessing I'd like to call it "the mod_perl conference", as nobody else is offering mod_perl this kind of exposure. It'll be mentioned in TPC advertising, but it won't be a Perl or Apache track of the conference: it'll be labelled and promoted as mod_perl only. The low-hanging fruit (obvious topics) will be: * Doug MacEachern on mod_perl 2 * Matt on AxKit (also likely to make an appearance in the XML track) * Brian on AO (please please dark gods let AO come to fruition) * talk(s) on how to do good things with Apache::ASP * mod_perl + backhand = ass-kicking * Tips for developing or tuning HTML::Mason sites * Case studies showing how big companies use mod_perl This latter is an important part of the Perl conference. Many companies who would never 'fess up to using Perl seem quite happy to send employees to speak at conferences. Their talks end up as a big advertisement for Perl, and lets us name-drop the company as a Perl user. I see no reason why the same shouldn't happen with mod_perl. Nat
Re: High-volume mod_perl based ecommerce sites?
Well forcing you to write objects does not mean you know how to write good objects. With that said here is my very small cookbook: 1: know your tools, what they can and cannot do AND what they should and should not do. 2: when you get the problem try to understand it before you start the design 3: design before you code 4: code it the way you would want it done if you were getting someone else's code to fix 5: version control aka CVS 6: write code, write lots of code and get some peer review if possible 7: review your own code Most of the bad code I have seen and written is caused by a lack of self discipline on the part of the team( 1 or 100 people). Cutting corners always costs you time or if you do it right you do it once. Good luck marc - Original Message - From: Jason Bodnar [EMAIL PROTECTED] To: Neil Conway [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, May 25, 2000 11:28 PM Subject: Re: High-volume mod_perl based ecommerce sites? I'm probably a novice programmer, at least by the standards of most of the people on this list. I'm 16, and since I haven't taken Computer Science at university yet, I'm a bit lacking in 'formal programming education'. I'd rather not form bad habits - is there any advice anyone can give me on how to write, clean Perl (OO or otherwise)? Are there any good books I can pick up? Probably the best way to learn good OO Perl is to learn Java or C++. As Gunther said, other languages are much more strict so they force you to write good OO stuff. I had been programming with Perl 4 before Java came out and had never done any OO stuff. I actually argued against OO with a friend. I tried to learn Perl OO but it didn't click. I taught myself Java since it was the cool thing to do and then went back to Perl OO. I think my Perl OO is better from knowing Java first. Definitely read the perltoot (Tom's OO Tutorial). I've heard alot of good things about Damian Conway's OO Perl book but I haven't read it myself. The advanced perl programming book has a nice section on OO. But, learning OO in a Java or C++ context would probably be the best way to start. -- Jason Bodnar + Tivoli Systems = [EMAIL PROTECTED]
