Comments for Ancient Programming http://www.ancientprogramming.com What I encounter in my software part of life is in danger of being commented upon here Thu, 29 Jul 2010 23:22:18 +0000 http://wordpress.org/?v=2.6.3 Comment on Best practise when handling tags and branches (using subversion) by Jacob von Eyben http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-104 Jacob von Eyben Fri, 28 May 2010 08:53:20 +0000 http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-104 @Clay McCoy: You have a point, as a specific revision can't be changed, hence is perfect as a reference to a specific version of the software. One rinkle I found about using revisions as a unique marker of a version is that a revision is only unique inside a specific repository. If you - like I had to do lately - migrate (dump/load) a sourcetree into an existing repository, you code will be recommitted and retrieve new revision numbers. Then you need another unique identifier (I know that a copy in the tags doesn't force uniqueness) @Clay McCoy:
You have a point, as a specific revision can’t be changed, hence is perfect as a reference to a specific version of the software.

One rinkle I found about using revisions as a unique marker of a version is that a revision is only unique inside a specific repository.
If you - like I had to do lately - migrate (dump/load) a sourcetree into an existing repository, you code will be recommitted and retrieve new revision numbers. Then you need another unique identifier (I know that a copy in the tags doesn’t force uniqueness)

]]> Comment on How to create macros for maven-site-plugin by Ayesha Noorda http://www.ancientprogramming.com/2008/06/05/how-to-create-macros-for-maven-site-plugin/#comment-102 Ayesha Noorda Mon, 17 May 2010 22:26:47 +0000 http://www.ancientprogramming.com/2008/06/05/how-to-create-macros-for-maven-site-plugin/#comment-102 gives thanks !! really article! gives thanks !! really article!

]]> Comment on Any good maven support for Google Appengine? by SN http://www.ancientprogramming.com/2009/06/05/any-good-maven-support-for-google-appengine/#comment-99 SN Fri, 08 Jan 2010 16:06:00 +0000 http://www.ancientprogramming.com/?p=29#comment-99 Vote here if you are looking for maven support in GAE http://code.google.com/p/googleappengine/issues/detail?id=1296 Vote here if you are looking for maven support in GAE
http://code.google.com/p/googleappengine/issues/detail?id=1296

]]> Comment on Logging sql statements and parameters using hibernate by Morten Holm http://www.ancientprogramming.com/2009/11/12/logging-sql-statements-and-parameters-using-hibernate/#comment-90 Morten Holm Fri, 13 Nov 2009 07:02:17 +0000 http://www.ancientprogramming.com/?p=33#comment-90 log4jdbc (http://code.google.com/p/log4jdbc/) is another candidate for the job. Same thing. Change the driver - prepend the entire jdbc url with 'jdbc:log4' and you are running. log4jdbc (http://code.google.com/p/log4jdbc/) is another candidate for the job. Same thing. Change the driver - prepend the entire jdbc url with ‘jdbc:log4′ and you are running.

]]> Comment on Best practise when handling tags and branches (using subversion) by [轉載]Subversion 從入門到精通 - 國際認證-考試信息 http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-89 [轉載]Subversion 從入門到精通 - 國際認證-考試信息 Mon, 02 Nov 2009 08:40:57 +0000 http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-89 [...] Subversion 實務好習慣 【Best practise when handling tags and branches (using subversion) 】Posted by jeyben：操作 tags 與 [...] [...] Subversion 實務好習慣 【Best practise when handling tags and branches (using subversion) 】Posted by jeyben：操作 tags 與 [...]

]]> Comment on fixedformat4j api - bring on your feedback! by Shakir Gusaroff http://www.ancientprogramming.com/2008/03/17/fixedformat4j-api-bring-on-your-feedback/#comment-42 Shakir Gusaroff Fri, 30 May 2008 14:58:28 +0000 http://www.ancientprogramming.com/2008/03/17/fixedformat4j-api-bring-on-your-feedback/#comment-42 Hey jeyben, I have got the following run time exception when I run your tutorial: C:\Documents and Settings\gusaros\Desktop\fixformat>java FixedTesting Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/lo gging/LogFactory at com.ancientprogramming.fixedformat4j.format.impl.FixedFormatManagerIm pl.(FixedFormatManagerImpl.java:48) at FixedTesting.main(FixedTesting.java:30) Thank you. Hey jeyben, I have got the following run time exception when I run your tutorial:

C:\Documents and Settings\gusaros\Desktop\fixformat>java FixedTesting
Exception in thread “main” java.lang.NoClassDefFoundError: org/apache/commons/lo
gging/LogFactory
at com.ancientprogramming.fixedformat4j.format.impl.FixedFormatManagerIm
pl.(FixedFormatManagerImpl.java:48)
at FixedTesting.main(FixedTesting.java:30)

Thank you.

]]> Comment on fixedformat4j api - bring on your feedback! by Ancient Programming » Blog Archive » Fixedformat4j released! http://www.ancientprogramming.com/2008/03/17/fixedformat4j-api-bring-on-your-feedback/#comment-40 Ancient Programming » Blog Archive » Fixedformat4j released! Sun, 25 May 2008 21:11:00 +0000 http://www.ancientprogramming.com/2008/03/17/fixedformat4j-api-bring-on-your-feedback/#comment-40 [...] fixedformat4j api - bring on your feedback! [...] [...] fixedformat4j api - bring on your feedback! [...]

]]> Comment on fixedformat4j api - bring on your feedback! by Felipe Gonçalves Coury http://www.ancientprogramming.com/2008/03/17/fixedformat4j-api-bring-on-your-feedback/#comment-25 Felipe Gonçalves Coury Thu, 20 Mar 2008 23:31:35 +0000 http://www.ancientprogramming.com/2008/03/17/fixedformat4j-api-bring-on-your-feedback/#comment-25 Hey jeyben, I have a great, working library that does what you intend on doing with your library. Wouldn't you like to join forces instead or splitting in two different ways? Take a look: http://tinyurl.com/32cybz And for code refer the original version, in Portuguese: http://blog.felipecoury.com/jep/2008/02/java-text-import-export.html Please e-mail me if you think it's a good idea to join forces. Best regards, Felipe Coury. Hey jeyben,

I have a great, working library that does what you intend on doing with your library. Wouldn’t you like to join forces instead or splitting in two different ways?

Take a look:
http://tinyurl.com/32cybz

And for code refer the original version, in Portuguese:
http://blog.felipecoury.com/jep/2008/02/java-text-import-export.html

Please e-mail me if you think it’s a good idea to join forces.

Best regards,
Felipe Coury.

]]> Comment on fixedformat4j api - bring on your feedback! by Jonathan O'Connor http://www.ancientprogramming.com/2008/03/17/fixedformat4j-api-bring-on-your-feedback/#comment-24 Jonathan O'Connor Thu, 20 Mar 2008 11:32:35 +0000 http://www.ancientprogramming.com/2008/03/17/fixedformat4j-api-bring-on-your-feedback/#comment-24 Many years ago I worked on <a href="http://www.jpos.org" rel="nofollow">jPOS</a>. This library processes ISO-8583 records. This format has all sorts of interesting ideas. It would be great if your library could parse these types of records. Some ideas: 1. Allow conditional fields. E.g. If field1 has value x, then field 2 exists. 2. Support inheritance ala discriminator fields in JPA. This is a different way to support conditional fields. 3. Your idea of annotating fields is a great idea. How about using the same idea to support reading fixed-column CSV files. Have fun! Many years ago I worked on jPOS. This library processes ISO-8583 records. This format has all sorts of interesting ideas. It would be great if your library could parse these types of records. Some ideas:
1. Allow conditional fields. E.g. If field1 has value x, then field 2 exists.
2. Support inheritance ala discriminator fields in JPA. This is a different way to support conditional fields.
3. Your idea of annotating fields is a great idea. How about using the same idea to support reading fixed-column CSV files.

Have fun!

]]> Comment on Best practise when handling tags and branches (using subversion) by Clay McCoy http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-22 Clay McCoy Wed, 19 Mar 2008 15:31:21 +0000 http://www.ancientprogramming.com/2008/03/15/best-practise-when-handling-tags-and-branches-using-subversion/#comment-22 I'm always surprised that the Subversion convention of trunk/tags/branches top level directories is still considered a best practice. Especially when there is nothing fundamentally different about tags and branches in this case. They are both just copies that can be committed to. I'm constantly surprised how few people realize this, and how the Subversion culture enforces this misunderstanding. The only way to have a true immutable tag is to reference the revision number. Doing this with svn:externals or piston is a nice way to group specific versions of projects for a release. So the main Subversion best practice that I recommend is to use revision numbers more. Use them for tags, since it is the only way to really lock down what you are depending on. Use them for internal release numbers for similar reasons rather than coming up with an alternate numbering strategy (which I have never seen work). Use them for your build. Or use an SCM solution that has real tags and branches (among other advantages) like Git. I used to work with a guy who didn't understand SCM (even though it was his job). He would constantly call for code freezes when he wanted to do a release. He never understood why I would get frustrated with him for expecting the developers to actually stop developing because he didn't understand how to manage the SCM appropriately. I’m always surprised that the Subversion convention of trunk/tags/branches top level directories is still considered a best practice. Especially when there is nothing fundamentally different about tags and branches in this case. They are both just copies that can be committed to. I’m constantly surprised how few people realize this, and how the Subversion culture enforces this misunderstanding.

The only way to have a true immutable tag is to reference the revision number. Doing this with svn:externals or piston is a nice way to group specific versions of projects for a release.

So the main Subversion best practice that I recommend is to use revision numbers more. Use them for tags, since it is the only way to really lock down what you are depending on. Use them for internal release numbers for similar reasons rather than coming up with an alternate numbering strategy (which I have never seen work). Use them for your build. Or use an SCM solution that has real tags and branches (among other advantages) like Git.

I used to work with a guy who didn’t understand SCM (even though it was his job). He would constantly call for code freezes when he wanted to do a release. He never understood why I would get frustrated with him for expecting the developers to actually stop developing because he didn’t understand how to manage the SCM appropriately.

]]>