Re: Ideal Web Development Environment?
- From: Colin McKinnon <colin.thisisnotmysurname@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 24 May 2006 22:29:39 GMT
Richard Levasseur wrote:
(Forewarning, most of these problems and solutions come from being theI've never had to cope with *all* those at the same time - at least not
only developer in a 1 server department with no budget, few resources,
unresponsive IT, and non-technical managers, so thats where I'm coming
from.)
doing real development work. Good luck.
- Fast speed of development and deploymentDon't go there. By all means re-use code, but if it's seperate projects then
- Shared codebase
use a seperate codebase.
I'd say the basic tools for real PHP development are:
code editor
documentation generator
unit test kit
bug tracker
continious integration kit
style rules
version control (be it policy or software)
For that I favour:
Vim
PHP Documentor
PHPUnit
RT
Rephlux
A homegrown document
(different things in different contexts including a homegrown solution and
CVS).
When I originally started, this elaborate process was the really simple
way we all started with: rename index.php to index1.php, modify
index1.php, make sure it works, overwrite index.php with the new one.
You really want to keep the old ones too.
Then it developed into having a vhost for development (but no seperate
sql server - oh the nightmare and white knuckle rollercoaster ride of
having to make structural changes to a live database), and finally I
setup this elaborate staging/dev/release system which has made my life
much easier.
So many organisations just don't get the idea of FOSS - one of the great
things about it is that potentially every developer can have a full
application stack with multiple environments configured on their desktop
machine. This is my prefered starting point. Then code goes to one or more
test environments before being marshalled into Live.
It also makes for a much cleaner permissions model - user has full access to
their own machine, are in the same group as the webserver on the next step
(files rw-rw-r--) then deployed read only to Live.
- Setup a Subversion server with a post-commit hook that updates the
development server with the latest version (as a working copy,
preferablly), so that everyone can see what the 'final' version looks
like.
Always pushing out the bleeding edge version to a shared development box
sounds a bit dangerous to me.
- Create a production server in Apache and write a shell script to
export the specified tagged version, as well as a shell script to apply
patches. Ideally, no person should have to touch the production by
hand, except to alter config files (which don't change much, once
setup)
I prefer to do this by replicating from the tested environment.
* A few notes about this setup:
* Config Files: There have to be many types of config files. One for
the user (this isn't versioned) so he can override settings as
necessary without changing the versioned config file. One for the
development server (this isn't versioned as well) so it can override
necessary settings. One for the production server. The production
server config file conditionally includes the user and dev config files
if they exist and the globals are appropriately define()'d. A problem
I haven't quite solved is that production configs will be overwritten,
so the shell script (that copies from subversion to the server) needs
to detect when it has changed to save the old one and notify the person
(ala Gentoo's emerge)
hmmm. How much config is there? I prefer to maintain multiple include
directories becoming increasingly general as you go along the include path
- that way you can override, say an application include file by specifying
a file of the same name in the host-specific directory.
* In cases where you don't have a dedicated SQL server for each of
development and production, I've found that creating a development
account with access on dev_%
I was with you at the first sentence in that paragraph, but lost you on the
second. Although I understood the first paragraph, I have trouble believing
it. You build your application by structuring data. Where that is not
enough you write more complex queries. As a last resort you write code in a
procedural language. The first two are critically dependant on having a
test database. There's lots of ways of managing different versions of code.
There's only one way to manage different database schemas.
* This doesn't quite work for handling SQL changes. If a table was
added, modified, etc, then releases must be manually compared and notes
checked for changes to the .sql defintion files, then the live database
updated accordingly
There's code on PHPClassess for replicating a MySQL database structure.
Having said that, it's kinda broken. (Diogo, if you're listening - you
going to put in my patches?).
Even when it does work, I often find its better to think about updates as
part of the deployment process - and script the changes.
Identifying dependencies between projects:
No software I know of does this, really, except grep. The goal is to
identify other places that might be affected by changes in common code
(utilities.php, user authentication code, etc). Grep isn't so bad at
it, really, but it would be nice to have a tool that did this, ya know?
Been there. When I used to write MS-Access applications I had a database
which managed that (when I remembered to keep it up to date). Where I work
now, there's a tool they use from Quest which is OK. Good idea for a
software project though. You can build CASE tools ion PHP you know ;).
Bug Reports:<snip>
- I also would rather say 'Fixed Bug #14729' than 'Fixed issue withSometimes simple can be good. Like I said I like RT, but there's LOTS of
auto select not submitting when user entered malformatted data into the
wrong field' in change logs. Makes me sound cool and I feel like i'm
getting somethign done. Plus, management likes seeing a slew of 'Fixed
Bug #whatever' instead of technical jargon they don't understand.
tools written in PHP for this kind of thing. I don't get why you don't just
bolt your front-end on to bugzilla.
API Documentation:
This is really a matter of discipline while coding: remembering to
write the javadoc syntax. The API can be autodocumented with the
post-commit hook on commits. Ideally, it would be nice to integrate
this into a wiki to preserve code changes and api documentation
changes, as well as provide a means of easily editing and commenting
the docs.
Sounds a bit impractical having updates to the content driven from different
sources (source code and wiki). Go back and read the manual for your
documentation tool of choice. PHPDocumentor and doxygen are capable of a
lot more than just minimal class and method labelling.
Tool Support (Editors):
I've yet to find an editor that satifies me fully. Everything has
something nice, but they are all lacking something I really want.
Ideally, it would:
- Support Subversion (or CVS, as the case may be)
Why? Personally I've never found a sensible reason for using an IDE (unless
you count Unix as an IDE). Sure there's lots of silly reasons - like its
inconvenient not to.
- Save a backup/second copy of the file to another location every save
(1: network drives over VPN can be slow, causeing the editor to lag,
This ain't going to happen. However if I were faced with the problem and had
control over my end, it'd be quite simple to set up some scripting funky
distributed filesystems to work around this.
- Syntax Highlighting, the best thing since forever.Vim, emacs.
- Autocomplete/Intellisense of native PHP functions as well as userI would have thought the latter to be highly improbable if not impossible
defined functions.
with a dynamically typed language.
- Regular expression searching of files *that display in a seperatectags
area* (ala Dreamweaver, NOT like visual studio, where it flags the
line)
- Jump to functionality. Visual studio has *alphabetized* dropdowns
that help you jump between classes, functions, and methods within a
file, and it is incredibly helpful.
Then again, I bet vim does - butgVim! (Vi +menus +windows).
i want to use my mouse, not memorize another hundred thousand commands
and keypresses. Web devs have to do that enough between php, sql,
javascript, html, shell, config files, and god knows what else.
Layer Seperation:
I know there are template languages and such out there, but I've never
gotten a chance to use them much. How well they work I don't really
know. But with things like AJAX autocomplete, it would be nice to
seperate config, core functionality, and presentation so a simple
autocomplete box doesn't need to have the server load the entire class
and subsequent includes.
I was going to say that in the absence of graphic designers there's little
reason to use a template system but then again my pet project PfP Studio is
all about pushing so much more into the presentation layer!
- How does everyone deal with the problems of web development? My
solution works, but it is somewhat ragtag and hacked together. Insight
is welcome.
Format your harddisk and install Linux. You will hate it for 3 months, after
6 months you'll be at least as productive as you are now and soon after
you'll hope you never have to go back to MS. Its just so much easier to
automate stuff, to link events to processes, to move files and data around.
C.
.
- Follow-Ups:
- Re: Ideal Web Development Environment?
- From: Richard Levasseur
- Re: Ideal Web Development Environment?
- References:
- Ideal Web Development Environment?
- From: Richard Levasseur
- Ideal Web Development Environment?
- Prev by Date: Re: odd fsockopen behavior
- Next by Date: Re: file_get_contents on Server 2003 IIS 6.0
- Previous by thread: Re: Ideal Web Development Environment?
- Next by thread: Re: Ideal Web Development Environment?
- Index(es):
Relevant Pages
|
