SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 42

Thread: Best practices?

Hybrid View

  1. #1
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Best practices?

    Hi.

    The main project I am working on has been running in it's present form for about two years. Because of this the development practices have reached a fair level of maturity/stagnation (delete as appropriate). I thought it might be time to review the types of things that we do and to say a few words on those we have found useful.

    1) Version control. Essential. We curently use CVS with tagged releases, but don't branch as the overhead for a small team doesn't seem worth it. We are looking at Sub-version at last. Waiting for an RPM install and mature CVS porting script before we risk the changeover.

    2) Scripted roll-out. Really nice. Originally just a way of keeping track of all the dependencies and libraries, this has grown to doing a roll-back if the tests fail. This means that failing test code should never go out and makes roll-outs more frequent and less of a trauma.

    3) Iterations. Our only management. Originally just a chunk of work with a measured "velocity" this is now planned as fixed two week intervals. The fixed interval makes us more willing to schedule refactoring work. We were a bit too goal oriented before.

    4) Shared code ownership. Essential. Anyone is allowed to edit anything and solve any problem.

    5) Unit testing. Essential. Allows us to refactor at will and is the enabler for shared ownership. Coding test first is universally preferred now.

    5) Stand up design sessions. Desirable. Gets all heads working on a problem. First choice is a whiteboard, second RRC cards and third UML. We should do this more often as we seem to inflict a lot of refactoring on ourselves due to coding too early.

    6) UML. For reference. Most of our diagrams are out of date, but we update them when starting something we haven't worked on for a while. They give us a clear starting point. This is our main top level documentation and is about two dozen diagrams in all. Our tool of choice is Dia.

    7) Refactoring. Constant. We expect to get things wrong and almost every iteration involves a refactoring task due to an issue raised/created in an earlier iteration. It is good to make time for this beyond doing it while you code.

    8) Pair programming. Do this on about 60% of code. We have a small office and so are sharing desks anyway. We are all willing converts to this way of doing things though. Quality rises sharply and productivity is pretty much the same as two individuals.

    9) Scripted server set-up. Insufficient. We can build a server with a single script (MySQL, Perl modules, Apache, the lot) in one go, but it just doesn't work for updating them. Investigating an RPM solution, possibly using Ximian's Red Carpet or a modified Apt-RPM tool.

    10) Code docs. Marginal. We had a home brew comment parser that is just too slow. As a result it doesn't get used. We have for ever been mindlessly creating the comment blocks ever since. We are going to try PhpDocumentor after porting the comment syntax, but I would be happy to delete the lot.

    11) Four day week. For sanity. Pairing is hard work, much more so than working alone. Much more than 35 hours of it and you are completely exhausted. It also means that the developers have time to do pet projects and investigate new ideas.

    So how do you do things?

    yours, Marcus
    Last edited by lastcraft; Oct 21, 2003 at 18:16.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  2. #2
    Sell crazy someplace else markl999's Avatar
    Join Date
    Aug 2003
    Location
    Manchester, UK
    Posts
    4,007
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice post
    It's interesting to see how a 'team' works together. I've always been a solo programmer working from home and although you try to have development practices such as the ones you describe i find it's just too easy to let things slip, especially documentation. I probably don't have enough personal discipline and should work on this.

    I've always wondered if development teams (PHP ones in particular) all work to such practices. Also how protective do you get of you own code? I'm very protective and not sure i could deal with someone else hacking at it, not because they might do it worse..or better, just that it won't be in my style

    The things i follow religiosly from your list are the CVS commits and the 4 day week..sometimes 3

  3. #3
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by markl999
    ...i find it's just too easy to let things slip, especially documentation. I probably don't have enough personal discipline and should work on this.
    If I rely on personal discipline then it just won't happen. For SimpleTest I am pretty much working alone. The way I keep things on track is by adding predicted times to my monthly TODO list and doing things iteratively. If I take too long then I am forced to drop a feature for that month. This disincentive keeps me plugging away as the release happens before the end of the month no matter what. Another constraint is test first. Do the test while you are fresh and do the code when you are tired.

    Quote Originally Posted by markl999
    I'm very protective and not sure i could deal with someone else hacking at it, not because they might do it worse..or better, just that it won't be in my style
    I thought I would be until I tried it. Pairing and refactoring help (you can change things you don't like). The real win is the team focus on tasks measured in tests and designs. The code itself becomes a means to an end rather than the end product itself.

    Your real fear is having to work with code that is a mess and finding out (from the pair partner) that you are writing just this type of code . After refactoring each other's code a few times you very rapidly agree a common approach that you can all buy in to.

    In short it turns into a non-problem.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  4. #4
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice post. You seem to have a good way of doing things, but could you tell me what you mean by " Scripted roll-out."?

    I do things in a similar way. I only work on my own projects, but I work on my own so don't have other developer's to co-ordinate with. I use Subversion - I think I already mentioned why in a different thread.

    I use Mr Project to manage my projects so I know what I'm supposed to be doing - otherwise I would just end up concentrating on the interesting code, and leave all the mundane stuff like writing documentation 'til last. It also helps me to work towards milestones. I try to organise it so that I have a milestone to hit every two or three weeks (but this depends on various factors like the size and complexity of the project). When I reach a milestone I usually find some way to reward myself

    I also use Dia and I have to agree with you - it's a great tool for creating UML and other diagrams. I create all my diagrams with it. Version 0.92 was released just a few days ago (if you didn't know). Layers and auto-routing are great additions.
    Last edited by sleepeasy; Oct 21, 2003 at 20:21.
    Always open to question or ridicule

  5. #5
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Quote Originally Posted by sleepeasy
    ...could you tell me what you mean by " Scripted roll-out."?
    I didn't write the scripts, but it goes something like this:
    1) Log in to server with ssh.
    2) Pull over the rollout script if it isn't there.
    3) Run rollout.pl with the necessary passwords.
    4) Sit back and watch the messages.
    5) That's it.

    The script put's up a place holder page while the site is down and then starts a CVS export. Once done it checks for schema changes and backs up the database if any. It then runs the make file in the exported code and then the system tests. The database is restored and if the rollout succeeded the old version is nuked. If it didn't the dead version is kept for investigation while the old one is restored. The place holder page comes down and everything goes live.

    Most of this is accompished with SymLink magic and ad hoc scripts.

    We wrote it about half way through the project and if I were to do it again I would write it at the beginning. It is a lot easier to create incrementally, and it completely changes your view or roll-outs. It also motivates you to do thorough system tests. If you know that the code you are writing will go live at the end of the week regardless, to a machine you have no personal experience of, boy do you feel nervous if you haven't done the test .

    Quote Originally Posted by sleepeasy
    I try to organise it so that I have a milestone to hit every two or three weeks (but this depends on various factors like the size and complexity of the project).
    I guess milestones are the same as iterations. Do you try to predict how long it will take before hand and then measure against acuality?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  6. #6
    SitePoint Zealot
    Join Date
    Aug 2003
    Location
    Sydney
    Posts
    187
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Like mark mentioned, i let things slip too. I've never worked in a team environment and would always like to, always have an extra hand around would be great, off load some work.

  7. #7
    SitePoint Evangelist
    Join Date
    Jul 2001
    Location
    Michigan, USA
    Posts
    414
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Excellent post Marcus. Though I am still attending university, it interested me greatly. Your points on pair programming are especially noted.

    Being a student who has almost entirely programmed solo, I haven't developed any standards of my own. Yeah, I know, it's terrible, and it leads to piss poor, scattered coding. I'd be interested hearing any suggestions anyone has for a lone ranger such as myself. I'm also looking to hear about anyone's experience about working with teams across the internet. It sure adds a whole new world of complexities.

    Marcus, I was also curious if some of the utilities you use for stuff are freely distributed. I know that CVS is open source (anyone know of a CVS server setup for a Windows machine?).

    At any rate, thanks for the great post. Hopefully, there'll be some great input here.

  8. #8
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Andy Tomaka
    Marcus, I was also curious if some of the utilities you use for stuff are freely distributed.
    All are except the post cards (RRC or CRC cards) and the whiteboard. See stuff by Scott Ambler, Ward Cunningham and Rebecca Wirfs-Brock on how to use these cheap disposable tools. Dia comes free with Linux and there is a Windows version too (you need Gtk). Watch out when you print a diagram for the first time .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  9. #9
    SitePoint Enthusiast Morgoroth's Avatar
    Join Date
    May 2003
    Location
    Canada
    Posts
    89
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Andy Tomaka
    Marcus, I was also curious if some of the utilities you use for stuff are freely distributed. I know that CVS is open source (anyone know of a CVS server setup for a Windows machine?).
    Andy, we use cvs on windows, its called cvsnt. We've only gotten it to work on NT4, but it supposedly works on XP and 2k (more likely 2k).

    We also use wincvs as our gui for cvs, because we're lazy, heh. (don't use tortoise, heh).

    Both are free and work on windows. Actually, cvsnt i think has also been ported to unix as well (ironic).

  10. #10
    SitePoint Evangelist
    Join Date
    Jul 2001
    Location
    Michigan, USA
    Posts
    414
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Morgoroth
    Andy, we use cvs on windows, its called cvsnt. We've only gotten it to work on NT4, but it supposedly works on XP and 2k (more likely 2k).

    We also use wincvs as our gui for cvs, because we're lazy, heh. (don't use tortoise, heh).

    Both are free and work on windows. Actually, cvsnt i think has also been ported to unix as well (ironic).
    Hey Morgoroth, thanks for the response. I've got the install files and everything, but I'm a bit clueless after that. I was curious if you knew of any crash course tutorials in using CVS and specifically WinCVS.

    And a general question: Is most of this stuff part of Extreme Programming? I haven't read up on it much but have heard a little bit about it. Is it something I should look into? Are there other similar programming styles that can work out as well too? I'm looking fomr some ways to easily improve my coding without adding a huge amount of time (isn't everyone ) Something without a huge learning curve and what not.

    Thanks!

  11. #11
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Like sleepeasy, I'd be interested in hearing more details about "scripted roll-out".

    Also interesting about the code documentation, I would have expected that to be really important with the shared code ownership thing.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  12. #12
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    I seem to have raised more questions than answers.

    Quote Originally Posted by samsm
    Also interesting about the code documentation, I would have expected that to be really important with the shared code ownership thing.
    I think the code comments are generally useful. In our case though we get information from UML and test cases as well. In addition the pairing means that knowledge is shared among us. The chances are you wrote a bit of all the code and so understand some of it already. Also the shared design sessions mean that even if you haven't worked on it directly, you rememeber the design issues. Code that cannot be understood gets refactored anyway.

    The upshot is that the time spent on comment blocks could have been spent testing, writing better code, talking, UMLling or refactoring. It is the weight of this that could potentially allow us to get away without the comments. We have yet to take that plunge though.

    yours, Marcus

    p.s. Stuff we don't do include wireframes, project management tools, FIT style testing frameworks and use cases. Do others have experience with these?
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  13. #13
    "Of" != "Have" bronze trophy Jeff Lange's Avatar
    Join Date
    Jan 2003
    Location
    Calgary, Canada
    Posts
    2,063
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When developing Deluxe Portal, we too have shared code ownership, we use Dreamweaver's built in File checkin/checkout capabilities.

    Code commenting isn't really something we consider to be essential, basically there is a list of functions in the file at the top, as well as a brief description of what it does.

    Generally speaking we only have 2 people working on the code though, so discussion about things usually happens either in a private forum or in MSN messenger.

    We have an active todo list of everything which needs to be done, and basically anyone can work on what they feel they want to do at the time. With this way, people get to work on something they'd like to, and it keeps things interesting instead of having to do one specific thing.
    Who walks the stairs without a care
    It shoots so high in the sky.
    Bounce up and down just like a clown.
    Everyone knows its Slinky.

  14. #14
    SitePoint Wizard Mincer's Avatar
    Join Date
    Mar 2001
    Location
    London | UK
    Posts
    1,140
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice post. Good to see people sharing experiences rather than just problem/fix threads.

    Quote Originally Posted by lastcraft
    4) Shared code ownership. Essential. Anyone is allowed to edit anything and solve any problem.
    Quote Originally Posted by lastcraft
    10) Code docs. Marginal. We had a home brew comment parser that is just too slow. As a result it doesn't get used. We have for ever been mindlessly creating the comment blocks ever since. We are going to try PhpDocumentor after porting the comment syntax, but I would be happy to delete the lot.
    It's interesting that you find these two can sit together. Shared code can usually only work [well] if your documentation is up to par. Why is a certain thing done in a certain way? One coder goes to fix problem A in section of code X and sees that the section of code that is causing the problem can be done in another way, so he changes it to method B to try and aliviate problem A. Of course, code X was done like that because if it was written using method B it caused a conflict with section Y.

    Result. Needless waste of time for not only the coder, but also the testers, and, after asking around the rest of the team to find him/her, the guy who originally coded it using method A, to find out why it was that he's done it like that.

    Regards,

    Matt.

    Edit:

    You posted that last post while I was posting mine

  15. #15
    SitePoint Addict been's Avatar
    Join Date
    May 2002
    Location
    Gent, Belgium
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice post. Good to see people sharing experiences rather than just problem/fix threads.
    /me agrees 100%

    I'm mainly doing 'solo work' myself, so I'm quite sure I'm not 'up to the level' here, but reading (and self-teaching) a lot has definitely changed the way I do things, but I'm far from 'there' yet. What follows is a rough sketch of how I'd might like to do things in the upcoming future:

    - Use version control, I've done a long time (much too long) without it, but now I am more than convinced it is absolutely essential. Have planned to setup cvs this weekend.

    - Write inline doc for the unit tests, write the test code, write the inline-doc for the code and then write the code. It's probably because I'm in an early stage of this process, but I've found that writing inline-doc (using phpDocumentor style) has improved my coding. Writing test code has not yet, unfortunately, evolved into a natural habit for me, so writing the inline documentation first has helped me immensly to stay on track and keep the code focused towards that I am trying to accomplish. But I know, documentation cannot be a substitute for unit tests.

    - Setup a test server. I'm pretty much in the dark here. I've setup a basic LAMP system (as found on most common hosting providers) where I deploy the project I'm working on. Since most projects I do are websites in php to deploy on hosting platforms, I have to admit this has worked sufficiently well for me: deploy locally, test, test, test and then ftp everything up to the server, changing the config variables (usually not a lot more than changing rootURL, base directories and all kinds of connection crudentials), check if the site works, and then remove the .htaccess passwd protection on the public server.
    Still it is very limited, and, as pointed out by Lastcraft, putting your code on a server you don't really know that good, is a very scary process to say the least.

    - Setup a basic bug-tracking system. Once a system is up, bugs will raise their ugly head, special situations that you haven't thought of in the test code (or are virtually none-detectable by unit tests), I think it's inevitable (and please please, correct me if I'm wrong, I would love to know how to learn to write bug-free code )

    Lastcraft, in your post, you don't mention any system(s) or method(s) for tracking bugs, would you mind to comment on that a bit further?

    Personally I think I'd just start out with a few scripts backed by a few tables in a db, a very simple system that brings the effort to report a bug down to an absolute minimum. I think that would be a quite logical starting point, it's no use to have a bugtracking system where reporting a bug takes so much effort that you'd rather fill in your tax papers
    Then go from there, and expand/refactor as needs arise, not keeping the primary intention (ie. keeping reporting bugs to a virtually effortless action)


    All this stuff, doing it purely by myself, takes such an enourmess amount of time that it scares me sometimes, but I am convinced that in the long run, it'll pay off in an increase in managebility and flexibility of code written.
    Also, if I'd be thinking of starting out a little business on my own, I already have made a half decent base to build a development infrastructure on (for example, there could be test-and other developers integrated with not that much of a hassle (not compared to the hassle it would take if I didn't do any of the formentioned stuff already)

    8) Pair programming. Do this on about 60% of code. We have a small office and so are sharing desks anyway. We are all willing converts to this way of doing things though. Quality rises sharply and productivity is pretty much the same as two individuals.
    Well, me, myself and I have been doing triplet programming for as long as I can remember, but apparently, it doesn't seem to pay off that well
    Seriously, I'd love to try PP, unfortunately no one in my direct programming-environment-neighbourhood is up to such a level where he or she sees the need for PP, and the part of them that know PHP is even smaller...

    I hope you won't find this arrogant, it certainly isn't my intention, but I'm thinking that the 'all developers in 1 place'-working environment is not so good for productivity, especially after reading Joel Spolsky about it:
    http://www.joelonsoftware.com/articl...000000068.html

    But, I'll put my 2 feet back firmly on the ground here, at the moment, it's still just 'solo work' for me, I probably don't know what I'm talking about
    Per
    Everything
    works on a PowerPoint slide

  16. #16
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by been
    Lastcraft, in your post, you don't mention any system(s) or method(s) for tracking bugs, would you mind to comment on that a bit further?
    Yep. That's because i forgot it . We have a custom support system that handles most queries. These are handed off to external support people unless they get a query that cannot be dealt with. The internal admin of this system is not up to par, and so we are funding (also externally) a rewrite of a more intelligent system. We simply don't have the time or office space to solve this in-house.

    Bugs in the system are fixed immediately, so bug tracking within our small office has not been needed yet. The "no broken windows" philosophy.

    Quote Originally Posted by been
    I hope you won't find this arrogant, it certainly isn't my intention, but I'm thinking that the 'all developers in 1 place'-working environment is not so good for productivity, especially after reading Joel Spolsky about it:
    http://www.joelonsoftware.com/articl...000000068.html
    Most of the article is from the PeopleWare book (Tom DeMarco) which is a must read if you run a company. Squaring up the "zone" behaviour with pairing is interesting. The problem with "zoning" is that you can be very productive in completely the wrong direction. Pairing replaces the "zoning" with a kind of "Hive mind" of two. You kind of "zone" together. Unfortunately this means that with two of you you are twice as likely to be interrupted and so both of you have to recover. Worth the productivity hit for the communication win.

    The shared behaviour can get so incestuous that one person can operate the mouse while the other uses the keyboard .

    We are actually looking to move out of our overcrowded office and to have one phone in a separate room. With our support outsourced our interuption rate isn't so bad. If anyone is involved in property, we would like a two room office (each 100sq.feet), plus conference room right next to a London tube station, pub, near the centre and with a lunchtime "pitch and put" nearby .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  17. #17
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If there isn't enough communication within a team environment then as demonstrated by Mincer you might as well forget about it

    A lot of developer's myself included simply like to do their own thing without external interest and/or pressures of trying to fit your style of scripting into someone else's perception of script style.

    Am I a mis-fit because of this ? Nope, just that I've never really seen the benifits of XP that's all I suppose

    But I suppose that why you have a project manager to manage all us developers aye ? If they're up to the job I suppose at the end of the day there shouldn't really be a problem huh ?

  18. #18
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    'all developers in 1 place'
    I'd have to kind of agree to that point as well; The whole planet [Earth that is ] has become a smaller place with cheap travel options, the Net and better communications;

    Why spend upto an hour going to work in the mornings and another hour at night when you can just as easilly work from home huh ?

    Fair enough you do not get to see your mates etc at work but isn't that why we have leasure time for ? As I see it there is a lot less pressure from working away from the office

  19. #19
    SitePoint Enthusiast
    Join Date
    Aug 2003
    Location
    Watford, UK
    Posts
    62
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi
    I work for a small company (2 other developers), so my thoughts are colored by that...

    Scripted rollouts - rock (if required...). We've only done this on one project that needed regular updates, but I would certainly do it again in similar circumstances. Probably the main difference for us was the lack of unit tests - we still had to check the site (real quick like) after the upload, fingers on the undo command...

    Shared code ownership - yes, but as people have mentioned, idiosyncracies in coding style can get you here. Coding standards can help prevent pointless cosmetic changes and hissy fits. Agreeing the standards can provide hours of fun ("but your brace style is rubbish!!!...."). We use (mostly) PEAR stds now.

    Unit testing - we've only gotten into this fairly recently. I'm absolutely converted to this way of working (I may have changed my mind in six months ). It's reassuring to be able to mess w/ code (the shared ownership thing) w/o worrying about breaking something that you don't know (or forgot) about. If tests fail, you find out very quickly where the problem is (and hopefully what it is...).

    Stand up design sessions - again, a recent thing for us (like 2 weeks). The Doctor's dead right about lack of communication w/i a team - we have problems with this that we're always trying to deal with, and the stand up design seems to help that. I also like the idea of pair programming (altho I think it'll be problematic w/ 3 developers) but it's not something we've tried yet.

    Code docs - PHPDocumentor is excellent, but docs still seem like a penance that ought to be observed. I will try harder...

    Project mgmt tools - One bad experience w/ MS Project put me off for life. Joel on Software (sorry for the lack of link) said (I think) that they're good if you're building a building. KISS, as always, seems the best course here.

    Wireframes - I'm currently an advocate:

    http://www.sitepointforums.com/showp...4&postcount=33

    I'm not entirely sure we're using them at the right point in development tho. We've used them to map out whole applications fairly early on - perhaps it would be better to work on one part at a time rather than make the client sign their life away all at once on our ill-founded ideas...

    One thing that I keep thinking about is continuous integration testing like that provided by CruiseControl:

    http://cruisecontrol.sourceforge.net

    Although I'm unsure how helpful it'd be w/ a small team. It's maybe something that I'll get round to some day.

    Another is using Phing for testing/doc generation/deployment. Again, someday...

    Oh yeah... four day week - you're just very, very jammy

    Cheers,

    Jon

  20. #20
    SitePoint Wizard Mike Borozdin's Avatar
    Join Date
    Oct 2002
    Location
    Edinburgh, UK
    Posts
    1,743
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well done Marcus. You seem to be use all the thing are told in Extreme Programming books.

  21. #21
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Mika
    Well done Marcus. You seem to be use all the thing are told in Extreme Programming books.
    Darn it my secret's out ! I'll have to go back to quoting the refactoring book instead.

    Actually we do differ slightly. We don't do integration tests as such, because we don't branch. Also we use more UML and less cards than a typical XP group, having been influenced by Agile Modelling and lately "Domain Driven Design" (Eric Evans).

    My XP leanings actually grew out of this project (Wordtracker), but others have been recruited since. One of the other developers even organises the London XP day conferences. He still won't let us in for free though .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  22. #22
    "Of" != "Have" bronze trophy Jeff Lange's Avatar
    Join Date
    Jan 2003
    Location
    Calgary, Canada
    Posts
    2,063
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Coding standards and a lot of communication between developers helps and code commenting becomes much less necessary.
    Who walks the stairs without a care
    It shoots so high in the sky.
    Bounce up and down just like a clown.
    Everyone knows its Slinky.

  23. #23
    SitePoint Enthusiast Morgoroth's Avatar
    Join Date
    May 2003
    Location
    Canada
    Posts
    89
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm not even fully sure how to use cvs myself

    We mostly use it with one repository, just checking out the files (getting a copy of the files off the server) and adding files to the server, to chare them. Doing a regular Update on areas to get the latest versions of files i need, or see if somone else Committed (submitted their changes to the server) something, and I'f I alreayd changed the file that was Committed, then cs tries to merge them (stick them together while retaining both versions changes... if it can't be done it warns you...).

    I hope that little bit of terminology helps... I don't really know of any good tutorials, but i'll look for some, and if anyone else has any that'd be great

    cvsnt, the cvs server, is hard to configure and isntall though... its an easy isntall on NT, just install it, set it up as a service, and then go into it, start the service and the other thing... create a repository, etc. Creating users is what confuses me, and choosing a protocol. We use sspi, and the users are nt users on the system, and cvsnt can detect and use those, or u might be able to specify your own, but u may have to use the pserver protocol. Installing it is hard, but on the site it has a good small tutorial I think, if not I'll dig it up...

    Wincvs is just a nice gui for the command line cvs, heh, but it works. Just think of it almost as an ftp program (you must connect and login to a server, and download and upload files) except its an ftp program that makes it very difficult to screw up your files (you can rollback a file to an older version, you can merge 2 peoples changes, etc).

    Yeah... other than that, I dunno... I think we could both use some tips form our linux cvs counterparts, heh,

  24. #24
    SitePoint Enthusiast
    Join Date
    Aug 2003
    Location
    Watford, UK
    Posts
    62
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    This tutorial on CVS for web projects helped me out:

    http://www.durak.org/cvswebsites/

    Cheers,

    Jon

  25. #25
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    I'd like to know how people in big companies are fairing.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •