April 29th, 2008 cschneid
Since I’m using Slicehost for my VPS hosting, and I’m cheap, I only have 256 megs of ram to work with. I run lighttpd, which then forces me to use php-cgi (via fastcgi) as the php executable. All of this is then running on Gentoo.
Anyway, what I’m getting to is how to setup PECL-APC (php accelerator / bytecode cache) on this platform.
Turns out all the scary messages in FAQs saying APC doesn’t work with CGI interfaces don’t apply to the fast-cgi implementation that Lighttpd uses.
emerge -uDv php5/pecl-apc
And then you’re done.
Hopefully my rambling was enough to get you going. To tweak, go check out /etc/php/php5-cgi/ext/apc.ini
Also, to verify this whole thing, you need a phpinfo() page… like:
<?php phpinfo(); ?>
Posted in Linux, System Admin | No Comments »
April 29th, 2008 cschneid
I am working on a project at work where I am the sole programmer, and also the project manager. It’s a small app, but it still requires the whole design and support documentation to go along with it.
So the question is: what is the correct level of documentation for a small project?
My thoughts so far are to:
- Limit the amount of writing - no reason to give somebody dozens of pages of junk if I could have said it in two.
- Limit the aging of the docs. There’s nothing worse than inaccurate documentation.
- Limit the restatement of what the code is actually doing. This is a small app, if somebody wants to know how I did something, they can pull up the code and see. That’s not to say I won’t discuss architecture, or external interfaces, but that I won’t say “this class does X” and “to do that, call this method on Y”.
- Have two separate documents. One is the business requirements and analysis document, the other is a support document. The idea is that support doesn’t need the requirements, they want step-by-step fixes of common problems, and maybe pointers to DB schemas and such.
Posted in Project Management | No Comments »