Search Results

Search found 6 results on 1 pages for 'artb'.

Page 1/1 | 1 

  • Is committing/checking code everyday a good practice?

    - by ArtB
    I've been reading Martin Fowler's note on Continuous Integration and he lists as a must "Everyone Commits To the Mainline Every Day". I do not like to commit code unless the section I'm working on is complete and that in practice I commit my code every three days: one day to investigate/reproduce the task and make some preliminary changes, a second day to complete the changes, and a third day to write the tests and clean it up^ for submission. I would not feel comfortable submitting the code sooner. Now, I pull changes from the repository and integrate them locally usually twice a day, but I do not commit that often unless I can carve out a smaller piece of work. Question: is committing everyday such a good practice that I should change my workflow to accomodate it, or it is not that advisable? ^ The order is more arbitrary and depends on the task, my point was to illustrate the time span and activities, not the exact sequence.

    Read the article

  • Is committing/checking in code everyday a good practice?

    - by ArtB
    I've been reading Martin Fowler's note on Continuous Integration and he lists as a must "Everyone Commits To the Mainline Every Day". I do not like to commit code unless the section I'm working on is complete and that in practice I commit my code every three days: one day to investigate/reproduce the task and make some preliminary changes, a second day to complete the changes, and a third day to write the tests and clean it up^ for submission. I would not feel comfortable submitting the code sooner. Now, I pull changes from the repository and integrate them locally usually twice a day, but I do not commit that often unless I can carve out a smaller piece of work. Question: is committing everyday such a good practice that I should change my workflow to accomodate it, or it is not that advisable? Edit: I guess I should have clarified that I meant "commit" in the CVS meaning of it (aka "push") since that is likely what Fowler would have meant in 2006 when he wrote this. ^ The order is more arbitrary and depends on the task, my point was to illustrate the time span and activities, not the exact sequence.

    Read the article

  • Does anyone have a good example/sample of "goto" spaghetti code? [closed]

    - by ArtB
    I've read a lot about how GoTo was considered harmful and removed for other control structures that were more intuitive. Does anyone have a good example / sample of goto spaghetti code? Preferrably, the sample code should be difficult to follow, but realtively easy when rewritten into more conventional control structures. I know I could try to write you some of my own, but I've never really used goto and don't think I could due justice to the headaches its abuse can lead to. I want this for didactic purposes to train junior developers on what to avoid. Mainly, to point to illustrate how OOP is taking the same idea to next logical consequence. EDIT: by good example I mean code that is terrible to read and abuses it, rather than code that uses goto for reasonable optimization

    Read the article

  • In BASH, are wildcard expansions guaranteed to be in order?

    - by ArtB
    Is the expansion of a wildcard in BASH guaranteed to be in alphabetical order? I forced to split a large file into [10Mb pieces][1] so that they can be be accepted by my Mercurial repository. So I was thinking I could use: split -b 10485760 Big.file BigFilePiece. and then in place of: cat BigFile | bigFileProcessor I could do: cat BigFilePiece.* | bigFileProcessor In its place. However, I could not find anywhere that guaranteed that the expansion of the asterisk (aka wildcard, aka '*' ) would always be in alphabetical order so that .aa came before .ab ( as opposed to be timestamp ordering or something like that ). Also, are there any flaws in my plan? How great is the performance cost of cating the file together?

    Read the article

  • How good is my method of embedding version numbers into my application using Mercurial hooks?

    - by ArtB
    This is not quite a specifc question, and more me like for a criticism of my current approach. I would like to include the program version number in the program I am developing. This is not a commercial product, but a research application so it is important to know which version generated the results. My method works as follows: There is a "pre-commit" hook in my .hg/hgrc file link to .hg/version_gen.sh version_gen.sh consists solely of: hg parent --template "r{rev}_{date|shortdate}" > version.num In the makefile, the line version="%__VERSION__% in the main script is replaced with the content of the version.num file. Are there better ways of doing this? The only real short coming I can see is that if you only commit a specfic file, version.num will be updated, but it won't be commited, and if I tried to add always committing that file, that would result in an infite loop (unless I created some temp file to indicate I was already in a commit, but that seems ugly...).

    Read the article

  • How to get the Doctype Declaration in Xerces-C when using SAX2 ?

    - by ArtB
    I am using SAX2 from Xerces-C to read an XML document. However, I would like to check the Doctype declaration (if there is any) to make sure that the XML file is in the format I am expecting. I have tried the unparsedEntityDecl and notationDecl methods from the DTDHandler, and EntityResolver seems to be more low-level than what I am looking for. My motivation is for this is to be able to confirm that the input is of the format I am expecting so that I can differentiate between documents which produce no output and those that are entirely of the wrong format.

    Read the article

1