Ideal Web Development Environment?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Richard Levasseur

    Ideal Web Development Environment?

    (Forewarning, most of these problems and solutions come from being the
    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.)

    (Additionally, this may or may not fit in this group, but I know
    there's bright people here, and it is largely PHP development centric)

    Any time I've done web development, I've always been plagued by some of
    the intrinsic differences between it and 'classical' development. I've
    solved most of the problems and simply want to share/get feedback, but
    at the same time I'm wondering how you guys solve these problems,
    namely:
    - Fast speed of development and deployment
    - Shared codebase
    - Layer seperation (logic, business, presentation, dev, staging,
    production, etc)
    - Tool support (editors and ide's that satisfy me)

    Now, the ideal environment, in my opinion anyways, would allow me (or a
    team) to:
    - Do development, staging, and release all without having to worry
    about the other.
    - Identify dependencies between projects and code bases.
    - Code versioning
    - API documentation
    - Obviously: easily write the code, ie: a good editor.
    - Receive bug reports easily

    Some of the solutions to these problems and environment requirements
    are as simple as good programming etiquette and a bit of discipline,
    but other's are not, also, allow me to clarify a bit.

    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.
    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.

    Development/Staging/Production:

    Ideally, I would like to be able to independently develop my code
    (under the same conditions as productions, ie: path, php variables,
    server settings, etc), merge it with everyone else's changes, then put
    this into a staging environment for regression testing and QA, then
    finally release into the production environment. (Ideally,
    development, staging, and production would all be on seperate computers
    so that dev/staging can be hosed wheen needed, but this isn't always
    possible.)

    This is relatively easy to do with Apache, Subversion, and a couple
    shell scripts:
    - Setup a development server with per-user directories in Apache and
    rewrite user directories to a vhost. Ideally, it would be to a
    subdomain host, but sometimes this isn't possible (because IT refuses
    to setup subdomain DNS entries, for example), in which case you can
    redirect to different port numbers. These per-user directories provide
    each developer with his own space in which to run the project, and,
    with .htaccess files, change server settings as may be necessary during
    development.
    - 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.
    - Create a staging server in Apache and write a shell script to export
    the specified revision to it and run automated tests. Revision intead
    of tagged version in case you needed to roll back a release and tests
    here because development can happen very rapidly and this is the 'QA'
    phase.
    - 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)

    * 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)
    * In my situation i'm the only developer, so i skipped the staging
    server.
    * 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_%
    * 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
    * Fittingly, data is backed up three times a day (morning, noon and
    night - when you come back from lunch and your boss is asking if the
    database has an 'undo,' they're delighted when you say it can go back a
    few hours), as well as before every live release. With a small-medium
    sized database this isn't really that much after it has been
    compressed. Every day is maybe 3 megabytes, rotated monthly.
    * This sounds like a lot of overkill and more work for just a single
    dev, but I work every other day (just a student, part time), and it is
    much easier to compare previous version releases in viewVC, update the
    live website (portions not handled by the script, apache changes,
    permissions, etc), then ssh in and run ./goLive.sh. Subversion also
    helps you remember what you wrote the other day when you come in with a
    hangover or are otherwise burned out.

    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?

    Code Versioning:
    I talked about this above. Essentially a system to track all changes
    to code. I use Subversion and am quite happy with it; some use CVS,
    whatever floats your boat. This is also much more reliable than
    relying on, say, dreamweaver to tell you when something has been
    changed or checked out or some such. It would be nice to have per-file
    comments in commit logs, though, especially for web development where
    changes can be minor.

    Bug Reports:
    I'd love to have something like Bugzilla, but my managers and users
    would be far too intimidated by such a beast. Currently, I have a
    simple 2 input form (subject/text) they fill out that gets emailed
    directly to me. It works well as I have my email client flag, tag, and
    bag them to specific folders and priorities. But:
    - That wouldn't work too well if it was more than me
    - My bosses (hell, sometimes me) like to know if it was fixed,
    recieved, etc, and I find it a tedious and time consuming to reply
    'thanks' to every bug report and 'done' to every completed item. I'd
    like to be able to say 'go to intranet.com/status to see where I am and
    what i'm up to.'
    - It is also harder to track and identify bugs when they're simply
    text in an inbox, too. Seeing a lot of similar bug reports might help
    me improve my own writing and processes.
    - I also would rather say 'Fixed Bug #14729' than 'Fixed issue with
    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.

    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.

    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)
    - 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, 2:
    in the event the remote data is damaged). This would also mean it may
    have to upload via ftp or other access method.
    - Live syntax checking of the file (ala Eclipse, where it underlines
    the errors like a spell check). This also reinforces the need to save
    a backup because a network over a VPN can be very slow sometimes,
    causing the editor to lag severely.
    - Syntax Highlighting, the best thing since forever.
    - Autocomplete/Intellisense of native PHP functions as well as user
    defined functions.
    - JavaDoc tooltip for variables and functions
    - Regular expression searching of files *that display in a seperate
    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. Dreamweaver has this...but its not
    alphabetized, incredibly frustrating. It is also nice to have right
    click menu's that let you do this (as in VS)
    - Format code, because I'm a format-nazi. Not as you type mind you,
    that's annoying.
    - Be able to open include()'d files *with path checking* with right
    click. Typically i set the php_include path to search the standard
    includes directory, avoiding use of include($dir/common.php). VS.php
    has this, but its broken.
    - A second code window built in. It may sound odd, but sometimes I
    want to look at two seperate files, or two portions of the same file
    within the same window to visually compare or use as reference. And
    not all of us have two monitors. VS can do this, I think, as can
    Dreamweaver (kinda, but only within the same file and the view resets
    randomly)
    - A file browsing pane if it includes the shell's right click menu or
    some really nifty functionality. Namely, subversion controls and 'open
    with...' Most of the time I have a file explorer window open for one
    reason or another, anyways.

    * No editor does all this, none that I know of, they are all missing
    something. VS.php has great syntax and checking, but horrible
    deployment options. Dreamweaver will use ftp, and has great
    HTML/Javascript support, but lacks satisfactory PHP support (at least,
    after i've used vs.php and Eclipse). Then again, I bet vim does - but
    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.

    Anyways, that leaves us with only a few questions and problems i've not
    quite worked out:
    - Managing config files appropriately (so new, blank ones don't
    overwrite older configured ones)
    - Keeping the database structure in sync with the .sql files
    - Finding a kick ass editor that doesn't cost a bunch of money (cough,
    VS: $1500+), and does enough to make the job easier (I honestly
    consider DW the baseline as it does everything just good enough to keep
    me happy).
    and finally:
    - How does everyone deal with the problems of web development? My
    solution works, but it is somewhat ragtag and hacked together. Insight
    is welcome.

  • Kenneth Downs

    #2
    Re: Ideal Web Development Environment?

    Richard Levasseur wrote:
    [color=blue]
    > (Forewarning, most of these problems and solutions come from being the
    > 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.)
    >[/color]

    Well, my solutions came from being the Lead Systems Architect on a c/s app
    with 20 programmers on two continents. My goals were the same as yours,
    and so I started Secure Data Software and we have created our solution,
    Andromeda.


    [color=blue]
    > Any time I've done web development, I've always been plagued by some of
    > the intrinsic differences between it and 'classical' development. I've
    > solved most of the problems and simply want to share/get feedback, but
    > at the same time I'm wondering how you guys solve these problems,
    > namely:
    > - Fast speed of development and deployment[/color]

    Minimize Code, maximize data. Repeat ruthlessly throughout the entire
    process.
    [color=blue]
    > - Shared codebase
    > - Layer seperation (logic, business, presentation, dev, staging,
    > production, etc)[/color]

    We create a database specification, and a builder creates the database (an
    upgrade is done the same way, it just changes and adds what is necessary).
    All business rules are implemented in the server, so it is safe to be
    accessed from any source. The UI runs off the same spec that was used to
    build the database, for all standard tables we have zero UI coding.

    Custom coding is for those pages whose unique requirements demand something
    other than plain-vanilla [New] [delete] [Lookup] etc. Examples we have
    done include a calendar and a custom tabbe'd complex set of tables.
    [color=blue]
    > - Tool support (editors and ide's that satisfy me)[/color]

    Personally I like Jedit. Have no use for ide's really.
    [color=blue]
    >
    > Now, the ideal environment, in my opinion anyways, would allow me (or a
    > team) to:
    > - Do development, staging, and release all without having to worry
    > about the other.[/color]

    Well these are just the same operation at different scales. A programmer
    committing a single change to a scratch database is the same operation as a
    big server getting a fresh codebase and huge database structure changes.
    With Andromeda the same tool does it all.
    [color=blue]
    > - Identify dependencies between projects and code bases.[/color]

    I thought this would be big when I created it, but it has not been. When
    you focus heavily on a database specifications and automations,
    dependencies are reduced.
    [color=blue]
    > - Code versioning[/color]

    ditto
    [color=blue]
    > - API documentation[/color]

    The site I pointed to above, http://docs.secdat.com, has auto-generated docs
    out of source code.

    But the big win is that you want your emphasis to be on the data dictionary,
    which is used to build the database. Then the docs are an HTML runout of
    the database specification, taken right out of the data dictionary tables.
    [color=blue]
    > - Obviously: easily write the code, ie: a good editor.[/color]

    We provide an XML file that does color editing for jedit. Sorry, no others,
    that's the editor we use.
    [color=blue]
    > - Receive bug reports easily[/color]

    I like to get personal emails when there is a failed trx on any system
    created by me.
    [color=blue]
    > * 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[/color]

    This will never scale past 4 programmers. Or perhaps 6 well-discplined
    ones.
    [color=blue]
    > 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?
    >[/color]

    Think of it as a data problem. If you could specify -- in tables --
    everything that was supposed to happen in your database, then finding
    dependencies is an SQL Query.
    [color=blue]
    > Code Versioning:
    > I talked about this above. Essentially a system to track all changes
    > to code. I use Subversion and am quite happy with it; some use CVS,
    > whatever floats your boat. This is also much more reliable than
    > relying on, say, dreamweaver to tell you when something has been
    > changed or checked out or some such. It would be nice to have per-file
    > comments in commit logs, though, especially for web development where
    > changes can be minor.
    >[/color]

    I've done this at large scales, and it is a terminal effort. As long as you
    are managing code instead of data you will hit endless opaque barriers.

    [color=blue]
    > Bug Reports:
    > I'd love to have something like Bugzilla, but my managers and users
    > would be far too intimidated by such a beast. Currently, I have a
    > simple 2 input form (subject/text) they fill out that gets emailed
    > directly to me. It works well as I have my email client flag, tag, and
    > bag them to specific folders and priorities. But:
    > - That wouldn't work too well if it was more than me
    > - My bosses (hell, sometimes me) like to know if it was fixed,
    > recieved, etc, and I find it a tedious and time consuming to reply
    > 'thanks' to every bug report and 'done' to every completed item. I'd
    > like to be able to say 'go to intranet.com/status to see where I am and
    > what i'm up to.'[/color]

    Just another database app. If you can add a table and have a maintenance
    for with zere code, make your own bug tracking system.
    [color=blue]
    >
    > 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.[/color]

    Anything requiring discipline will break down as the team grows, eventually
    resulting in horrible effects.

    The only way to prevent these things is to have the documentation and the
    coding be the same effort. Automation is your friend as well because when
    you give programmers tools to do thing then the tools can track what is
    being done.


    --
    Kenneth Downs
    Secure Data Software, Inc.
    (Ken)nneth@(Sec )ure(Dat)a(.com )

    Comment

    • Colin McKinnon

      #3
      Re: Ideal Web Development Environment?

      Richard Levasseur wrote:
      [color=blue]
      > (Forewarning, most of these problems and solutions come from being the
      > 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.)
      >[/color]
      I've never had to cope with *all* those at the same time - at least not
      doing real development work. Good luck.
      [color=blue]
      > - Fast speed of development and deployment
      > - Shared codebase[/color]
      Don't go there. By all means re-use code, but if it's seperate projects then
      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).
      [color=blue]
      > 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.[/color]

      You really want to keep the old ones too.
      [color=blue]
      > 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.[/color]

      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.
      [color=blue]
      > - 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.[/color]

      Always pushing out the bleeding edge version to a shared development box
      sounds a bit dangerous to me.
      [color=blue]
      > - 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)[/color]

      I prefer to do this by replicating from the tested environment.
      [color=blue]
      > * 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)[/color]

      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.
      [color=blue]
      > * 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_%[/color]

      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.
      [color=blue]
      > * 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[/color]

      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.
      [color=blue]
      >
      > 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?
      >[/color]

      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 ;).
      [color=blue]
      > Bug Reports:[/color]
      <snip>[color=blue]
      > - I also would rather say 'Fixed Bug #14729' than 'Fixed issue with
      > 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.
      >[/color]
      Sometimes simple can be good. Like I said I like RT, but there's LOTS of
      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.
      [color=blue]
      > 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.[/color]

      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.
      [color=blue]
      >
      > 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)[/color]

      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.
      [color=blue]
      > - 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,[/color]

      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.
      [color=blue]
      > - Syntax Highlighting, the best thing since forever.[/color]
      Vim, emacs.
      [color=blue]
      > - Autocomplete/Intellisense of native PHP functions as well as user
      > defined functions.[/color]
      I would have thought the latter to be highly improbable if not impossible
      with a dynamically typed language.
      [color=blue]
      > - Regular expression searching of files *that display in a seperate
      > 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.[/color]
      ctags
      [color=blue]
      > Then again, I bet vim does - but
      > 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.
      >[/color]
      gVim! (Vi +menus +windows).
      [color=blue]
      > 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.
      >[/color]

      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!
      [color=blue]
      > - How does everyone deal with the problems of web development? My
      > solution works, but it is somewhat ragtag and hacked together. Insight
      > is welcome.[/color]

      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.


      Comment

      • Richard Levasseur

        #4
        Re: Ideal Web Development Environment?

        Colin McKinnon wrote:[color=blue]
        > Richard Levasseur wrote:
        >[color=green]
        > > (Forewarning, most of these problems and solutions come from being the
        > > 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.)
        > >[/color]
        > I've never had to cope with *all* those at the same time - at least not
        > doing real development work. Good luck.[/color]

        lol, need more than luck ;). Government job, though, go figure.
        [color=blue][color=green]
        > > - Fast speed of development and deployment
        > > - Shared codebase[/color]
        > Don't go there. By all means re-use code, but if it's seperate projects then
        > use a seperate codebase.[/color]

        Perhaps, but if i did that, i would have, easily, 10x the code base to
        maintain (every project would have different versions of the same files
        every project uses). Trade off I guess.

        My latest approach is to make every function or group of functions its
        own file, so if i need to just keep one file, i can drop it in the
        projects directory and it'll use that one instead of the one from the
        standard include directory. (Not to mention this makes it easier to
        maintain commonly used functions)
        [color=blue]
        > 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).[/color]

        RT - Interesting, this would have been useful last year when they hired
        an intern to make something like this in pagemaker pro (or whatever
        that mac thing is called, can't recall exactly)

        PHPUnit and Rephlux looks interesting, too, I'll give those a try when
        i get the chance.
        [color=blue][color=green]
        > > 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.[/color]
        >
        > You really want to keep the old ones too.[/color]

        The old ones are kept by the version control.
        [color=blue][color=green]
        > > - 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.[/color]
        >
        > Always pushing out the bleeding edge version to a shared development box
        > sounds a bit dangerous to me.[/color]

        I think you misread - the latest is only put on the shared development
        box after your changes have been verified by you (psuedo client side,
        in this case) and then committed. You don't
        edit-save-commit-refresh-repeat, you just save-refresh-test. You
        commit your code to the dev box after you're done testing in your
        sandboxed area of the dev box.

        Psuedo client side because your 'client side' is really just a seperate
        location on the dev server, so as to avoid having to install apache,
        php, database, third party tools, onto your own computer (which could
        be impossible or a PITA in some cases).
        [color=blue][color=green]
        > > - 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)[/color]
        >
        > I prefer to do this by replicating from the tested environment.[/color]

        Can you clarify?
        [color=blue][color=green]
        > > * 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)[/color]
        >
        > 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.
        >[/color]

        Its the config for the application, not 'system wide' settings (though
        i suppose the same concept would apply to them).
        Maybe an example would clarify:
        /www/myapp/core.php: include('config .php');
        /www/myapp/config.php

        Then in config.php you have all the constants, servers, aliases,
        permissions, etc etc.
        Thats fine and dandy, but what if you need to change some of those
        values to do some debugging, or include alternate files? In my case,
        define('DEBUG', 1), define('DEVELOP MENT', 1) will modify some standard
        functions and methods so that they behave differently: queries give
        full error messages, email won't be sent out, certain conditions are
        treated as fatal instead of just warnings, etc.

        If you change config.php, then you'll have to revert before you commit
        to avoid any changes to the file. But then what if you've added
        something to config.php? Now you have to go through and remove your
        debug stuff. Tedious to say the least. Thats what user.dev.php is for
        - applying user changes to the config without having to fiddle with the
        actual config file.

        The other situation is to handle differences between the dev server and
        the staging/live server. Stupid little things, you know? Like someone
        forgot to set the default include_path correctly, or something wacky is
        going on with the server that is easily fixed with a config file change
        while someone else fixes the root of the problem. Thats what
        server.dev.php is for.

        This way, you're able to: not change the version'd config.php, avoiding
        any possible confusion why config.php was updated without meaniful
        changes, and not having to deal with tedious back tracking when you do
        need to update config.php, and not having to worry about an update
        overwriting any custom values you had in the config for your own
        development.

        Though, now that i think about it, it might be easier to have ./dev on
        the include path, however, the dev configs are meant to simply override
        the existing include. If './dev' was added to the include path the dev
        file would have to be a full copy of the original config file. It also
        wouldn't allow per-user and per-server config overrides. Also, how
        could you conditionally include the configs? If you need to turn DEGUG
        or DEVELOPMENT off for some reason, you'd have to change the include
        path, which would come with, imo, more complications than simply
        manually conditionally including a couple files in the main config
        file.

        Niether seems ideal, imo. Mine is pretty complicated, though, it may
        be easier to simply have ./dev on the include path.
        [color=blue][color=green]
        > > * 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_%[/color]
        >
        > 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.
        >[/color]
        Let me clarify:

        Ideally, you'd have a database server for development and a database
        server for production - two completely seperate entities so you don't
        hose the real data. Not everyone is so lucky, though.

        In my situation, I only have one physical server and there is no chance
        of getting a second. In MySQL, you can create masks for permissions to
        apply to. % is synonomous with *. So if I give you permission on
        databases dev_%, you can modify dev_foo, dev_bar, but not foo and bar.
        Your table names stay the same, as you are operating on tables in a
        database, you don't care what database, just so long as the table names
        are the same. In Postgres you could simply connect to seperate
        postgres databases and use the schemas as databases (since you can do
        schema.table in postgres).

        It isn't the most elegant hack and has a few caveats: It makes cross
        database queries a little tricky. On the dev server you want
        dev_accounts.us ers.last_name., but in the code you'll want to write
        accounts.users. last_name. So unless you have some globals or equiv
        defining the database names, then you have to manage this manually or
        come up with a way to obtain the database name you would *want* connect
        to. Could be tedious. Its not my favorite solution, either - it would
        probably be better to start another process of the database on a
        different port using a seperate config file.

        An alternate method is to abstract the database structure into code so
        that you just do $ACCOUNTS_DB->getDatabaseNam e();, and override
        $ACCOUNTS_DB if necessary. Funnily enough, I have set of classes that
        completely abstracts a database and its structure into objects like
        this. But sadly, its new and no projects have been able to fully use
        it, yet.
        [color=blue][color=green]
        > > * 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[/color]
        >
        > 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.
        >[/color]

        I remember seeing something like that on phpclasses, but never got
        around to trying it out.
        It would be nice to script the changes.
        [color=blue][color=green]
        > >
        > > 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?
        > >[/color]
        >
        > 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 ;).
        >[/color]

        What would be nice is if PHPDoc had an option to implicitly add a @uses
        tag for every function call. I manually document important ones, but
        sometimes...i just want to know how many things use something to know
        if i should or shouldn't fiddle with something ;)
        [color=blue][color=green]
        > > Bug Reports:[/color]
        > <snip>[color=green]
        > > - I also would rather say 'Fixed Bug #14729' than 'Fixed issue with
        > > 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.
        > >[/color]
        > Sometimes simple can be good. Like I said I like RT, but there's LOTS of
        > 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.
        >[/color]

        Thats not such a bad idea - sounds like some good work for the new
        intern.
        [color=blue][color=green]
        > > 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.[/color]
        >
        > 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.
        >[/color]

        I was a little vague, let me clarify:
        The wiki is for the user manual, PHPDoc is for the API documentation.
        I chose to use a wiki for the user manual instead of the PHPDoc
        tutorial/example tags for a few - reasons:
        - The user manual is for my users, who, if there is any sort of
        function signature on the page, I fear they will become confused and
        will stop reading immediately. A wiki is much friendlier looking than
        any of the PHPDoc templates i've seen. While I have little faith
        they'll figure out what [[Foo|bar]] does, I think they are much less
        intimidated by [[Foo|bar]] than public static mixed function foo(string
        $bar, [mixed $foo=NULL]) ;)
        - The users can edit the manual themselves and add notes in the future.
        My users have dozens of stickies detailing the most simplistic tasks.
        How to search for records, print them as PDFs, where to print them,
        options to set before printing, etc etc etc. Total amount of clicks is
        about 2 or 3, and there isn't much I can do about that in the PHP code,
        and I don't feel it belongs in the PHPDocs (which are more intended for
        the developer than user).
        - Its faster than regenerating the PHPDocs for minor revisions. It
        takes at least 30 minutes for PHPDoc to go through all my code.
        Partial due to the hardware, partially because of the codebase, and i'm
        sure it isn't configured optimally, i've only recently installed it.
        [color=blue][color=green]
        > >
        > > 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)[/color]
        >
        > 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.
        >[/color]

        I should have clarified: by IDE i just mean a set of tools you use. I
        don't use an IDE per se, but I have a set of tools and programs that
        help me. It'd be great if we could mix and match all our favorite apps
        into a single program, but thats quite a pipe dream!
        [color=blue][color=green]
        > > - 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,[/color]
        >
        > 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.
        >[/color]

        Even on windows? My work does not provide any linux client to VPN in
        with. The alternative is to SSH in and work directly on the server,
        but sometimes I like to have an offline copy in case the internet goes
        down.
        [color=blue][color=green]
        > > - Autocomplete/Intellisense of native PHP functions as well as user
        > > defined functions.[/color]
        > I would have thought the latter to be highly improbable if not impossible
        > with a dynamically typed language.
        >[/color]

        I though that, too, but the VS.php plugin does a remarkable job at
        guessing correctly. It is probably my favorite plugin for php
        development ever. I only wish i could use it with any editor.
        [color=blue][color=green]
        > > - Regular expression searching of files *that display in a seperate
        > > 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.[/color]
        > ctags
        >[/color]

        Clarify? The wikipedia article on it doesn't tell me much, and its
        quite late to go googling.
        [color=blue][color=green]
        > > 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.
        > >[/color]
        >
        > 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!
        >[/color]

        This also ties back to project dependancies. It'd be nice to just have
        it server parse the config and core methods and not have to parse/load
        all the presentational code which won't be run. This is sorta related
        to design methodology, i guess, too. Core functionality and
        functionality should be seperate anyways. And personally, I despise
        templates. I secretly would rather write some java gridbag than invoke
        Smarty.
        [color=blue][color=green]
        > > - How does everyone deal with the problems of web development? My
        > > solution works, but it is somewhat ragtag and hacked together. Insight
        > > is welcome.[/color]
        >
        > 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.
        >[/color]

        I wish I could, but I think it would be more trouble than it is worth.
        Not on my end, but with everyone else having to deal with whatever i
        gave them. I've almost got everyone using firefox, though ;)
        [color=blue]
        > C.[/color]

        Thank you Colin!

        Comment

        • jussij@zeusedit.com

          #5
          Re: Ideal Web Development Environment?

          Richard Levasseur wrote:
          [color=blue]
          > Tool Support (Editors):[/color]

          Lets see how the Zeus for Windows IDE stacks up to
          the test.
          [color=blue]
          > - Support Subversion (or CVS, as the case may be)[/color]

          Yes and No. Zeus can talk to CVS and any other version
          control that supports the SCC interface.
          [color=blue]
          > - Save a backup/second copy of the file to another
          > location every save[/color]

          Yes. Use the Options, Editor Options menu, backup panel.
          [color=blue]
          > - Live syntax checking of the file[/color]

          No.
          [color=blue]
          > - Syntax Highlighting, the best thing since forever.[/color]

          Yes.
          [color=blue]
          > - Autocomplete/Intellisense of native PHP functions
          > as well as user defined functions.[/color]

          Maybe - The intellisense in Zeus is fully configurable
          for example:





          So if you have access to the PHP source code it
          should be possible to add some sort of auto complete.
          [color=blue]
          > - JavaDoc tooltip for variables and functions[/color]

          No.
          [color=blue]
          > - Regular expression searching of files *that display
          > in a seperate area*[/color]

          Yes, I think so.
          [color=blue]
          > - Jump to functionality.[/color]

          Yes.
          [color=blue]
          > Visual studio has *alphabetized* dropdowns[/color]

          Yes. Zeus can jump to any definition held in the tags
          database.
          [color=blue]
          > - Format code, because I'm a format-nazi. Not as you
          > type mind you, that's annoying.[/color]

          Maybe. Zeus has auto indenting. It is also very easy to
          integrate code pretty tools into Zeus:



          [color=blue]
          > - Be able to open include()'d files *with path checking*
          > with right click.[/color]

          Yes. Right click "Open Include File" popup menu or using
          the View, "Open Include File" menu or via a keyboard key.
          [color=blue]
          > - A second code window built in.[/color]

          Yes. Window Split menu
          [color=blue]
          > - A file browsing pane[/color]

          Yes. Drives Navigator panel

          Two features you failed mention are templates and some
          sort of integrated help feature.

          I find the code templates invaluable:



          and I could not live without the Zeus Quick Help feature:


          [color=blue]
          > * No editor does all this, none that I know of[/color]

          Zeus seems to go quite close ;)

          Jussi Jumppanen
          Author: Zeus for Windows IDE


          Comment

          Working...