http://citconf.com/wiki/api.php?action=feedcontributions&user=203.217.69.89&feedformat=atomCitconWiki - User contributions [en]2024-03-29T13:13:16ZUser contributionsMediaWiki 1.35.11http://citconf.com/wiki/index.php?title=Dynamic_Build_Languages&diff=493Dynamic Build Languages2007-07-29T06:42:13Z<p>203.217.69.89: /* Capistrano for Java deployment? */</p>
<hr />
<div>''"Harnessing the power of magic..."''<br />
<br />
Facilitated by Josh Price and Tom Adams<br />
<br />
= Build Tools =<br />
<br />
== What's the current state of Java build tools? ==<br />
<br />
Performance is not always optimal. <br />
<br />
=== ant ===<br />
* programming in xml doesn't make sense<br />
* big ball of ant problem<br />
** the 9000 line "untouchable" collection of build script<br />
* few conventions <br />
** lots of rope to hang yourself<br />
* hard to refactor<br />
* ill-conceived <br />
** even JDD has disowned it<br />
<br />
=== maven ===<br />
* good conventions but hard to diverge from the norm<br />
** simple things are simple<br />
** moderate things are really hard (write a plugin)<br />
** hard things are virtually impossible<br />
* too much voodoo<br />
* not enough docs <br />
** hard to find where/how to configure things<br />
* kind of buggy <br />
** (I think this was attributed to plugins)<br />
* declarative model is too strict <br />
** flexibility is needed here<br />
* appeals to the less experienced <br />
** can get yourself in trouble if you assume it all just works<br />
<br />
== What can Java learn from Ruby? ==<br />
<br />
=== rake ===<br />
* testing your build?<br />
** once it gets really big you need to be able to reason about your build. <br />
** tests could allow you to refactor/optimise/etc without breaking anything<br />
* we really need a first class language for flexibility<br />
** programming in xml doesn't make sense<br />
** pure declarative model solves some problems but reduces flexibility<br />
* auto include of rake files allows easy factoring<br />
* possible to separate the definition of dependencies - who depends on me?<br />
* builtin namespaces (ie db:*, test:*)<br />
* plugins in ruby are really simple<br />
** monkey patching<br />
* file dependency checking is built in<br />
** what changed? do it anyway not optimal speed<br />
* auto checking of timestamps<br />
<br />
= Deployment tools =<br />
<br />
== Capistrano for Java deployment? ==<br />
<br />
* posix only (no windows yet)<br />
** installing cygwin is a solution<br />
** write adapters for the commands used (ssh, ftp, etc)<br />
* version 2.0 just released<br />
* peepcode demo (http://topfunky.com/clients/peepcode/free-episodes/peepcode-free-deprec.mov)<br />
** building ubuntu box remotely via ssh<br />
** using the deprec gem (http://www.deprec.org/)<br />
* convincing management that using a Ruby tool on a Java project is a good thing<br />
** it's often easier to just do it and show the benefits<br />
** ask for forgiveness rather than permission<br />
<br />
=== Links ===<br />
<br />
* http://www.capify.org/upgrade/whats-new<br />
** The Event framework look particularly interesting<br />
* http://www.iseff.com/2007/03/capistrano-and-java.html<br />
* http://www.oreillynet.com/ruby/blog/2007/04/capistrano_20_not_just_for_rai.html</div>203.217.69.89http://citconf.com/wiki/index.php?title=Fragile_Test&diff=491Fragile Test2007-07-29T05:38:18Z<p>203.217.69.89: </p>
<hr />
<div>== Less Fragile Tests ==<br />
<br />
=== Tests ===<br />
<br />
* Asserts<br />
** Component<br />
** Integration<br />
* Functional<br />
** UAT<br />
* Non-Functional<br />
** Perf<br />
** Security<br />
** Usability<br />
* See ISO 9126<br />
<br />
=== Good Tests ===<br />
<br />
* Pass Repeatedly<br />
** Timing (e.g. Selenium)<br />
** External Dependencies<br />
*** External Systems<br />
**** Reliability<br />
**** Availability<br />
*** Data<br />
**** Set Values<br />
**** Incorrect State<br />
** Heavy Mocking<br />
*** Utility to build mocks<br />
*** Easy switching mock to real<br />
<br />
=== Bad Tests ===<br />
* Hidden cause of failure<br />
** Visible Replay using TimeSnapper<br />
* Visible Replay<br />
* Dump state data at failure<br />
<br />
<br />
=== Tool advice ===<br />
* Time Snapper<br />
* EasyMock<br />
* Pretend Classes<br />
* DBUnit gets prod snapshot regularly (security issues: scrubbing) Table dependancies makes it a significant task<br />
<br />
=== Data ===<br />
* Domain (name, addr, etc class pulled from DB<br />
* (abstracted data from test)<br />
* Data Driven Approach<br />
* Fitness Integration Testing <br />
<br />
Strong correlation between importance of tests depending on the types of testing and what kind of thing you are doing (Product type development = high focus on test vs bespoke = low focus<br />
<br />
<br />
=== Suggestion ===<br />
* Use a virtual machine, setup - refresh test machine using VMWARe to simulate MSG based, 20 mins business transactions<br />
<br />
=== Test Data Repository ===<br />
* Used keyword substitution to create the real data<br />
<br />
=== Typical Data ===<br />
* Edge / Border cases, Exception testing<br />
<br />
=== Broken windows ===<br />
* Continually failing, low priority tests/defects cause a 'Broken windows' effect which degrades the value of CI.</div>203.217.69.89http://citconf.com/wiki/index.php?title=Fragile_Test&diff=490Fragile Test2007-07-29T05:37:02Z<p>203.217.69.89: </p>
<hr />
<div>= Less Fragile Tests =<br />
<br />
== Tests ==<br />
<br />
* Asserts<br />
** Component<br />
** Integration<br />
* Functional<br />
** UAT<br />
* Non-Functional<br />
** Perf<br />
** Security<br />
** Usability<br />
* See ISO 9126<br />
<br />
== Good Tests ==<br />
<br />
* Pass Repeatedly<br />
** Timing (e.g. Selenium)<br />
** External Dependencies<br />
*** External Systems<br />
**** Reliability<br />
**** Availability<br />
*** Data<br />
**** Set Values<br />
**** Incorrect State<br />
** Heavy Mocking<br />
*** Utility to build mocks<br />
*** Easy switching mock to real<br />
<br />
== Bad Tests ==<br />
* Hidden cause of failure<br />
** Visible Replay using TimeSnapper<br />
* Visible Replay<br />
* Dump state data at failure<br />
<br />
<br />
== Tool advice ==<br />
* Time Snapper<br />
* EasyMock<br />
* Pretend Classes<br />
* DBUnit gets prod snapshot regularly (security issues: scrubbing) Table dependancies makes it a significant task<br />
<br />
== Data ==<br />
* Domain (name, addr, etc class pulled from DB<br />
* (abstracted data from test)<br />
* Data Driven Approach<br />
* Fitness Integration Testing <br />
<br />
Strong correlation between importance of tests depending on the types of testing and what kind of thing you are doing (Product type development = high focus on test vs bespoke = low focus<br />
<br />
<br />
== Suggestion ==<br />
* Use a virtual machine, setup - refresh test machine using VMWARe to simulate MSG based, 20 mins business transactions<br />
<br />
== Test Data Repository ==<br />
* Used keyword substitution to create the real data<br />
<br />
== Typical Data ==<br />
* Edge / Border cases, Exception testing<br />
<br />
== Broken windows ==<br />
* Continually failing, low priority tests/defects cause a 'Broken windows' effect which degrades the value of CI.</div>203.217.69.89http://citconf.com/wiki/index.php?title=Dynamic_Build_Languages&diff=489Dynamic Build Languages2007-07-29T05:28:23Z<p>203.217.69.89: /* Capistrano for Java deployment? */</p>
<hr />
<div>''"Harnessing the power of magic..."''<br />
<br />
Facilitated by Josh Price and Tom Adams<br />
<br />
= Build Tools =<br />
<br />
== What's the current state of Java build tools? ==<br />
<br />
Performance is not always optimal. <br />
<br />
=== ant ===<br />
* programming in xml doesn't make sense<br />
* big ball of ant problem<br />
** the 9000 line "untouchable" collection of build script<br />
* few conventions <br />
** lots of rope to hang yourself<br />
* hard to refactor<br />
* ill-conceived <br />
** even JDD has disowned it<br />
<br />
=== maven ===<br />
* good conventions but hard to diverge from the norm<br />
** simple things are simple<br />
** moderate things are really hard (write a plugin)<br />
** hard things are virtually impossible<br />
* too much voodoo<br />
* not enough docs <br />
** hard to find where/how to configure things<br />
* kind of buggy <br />
** (I think this was attributed to plugins)<br />
* declarative model is too strict <br />
** flexibility is needed here<br />
* appeals to the less experienced <br />
** can get yourself in trouble if you assume it all just works<br />
<br />
== What can Java learn from Ruby? ==<br />
<br />
=== rake ===<br />
* testing your build?<br />
** once it gets really big you need to be able to reason about your build. <br />
** tests could allow you to refactor/optimise/etc without breaking anything<br />
* we really need a first class language for flexibility<br />
** programming in xml doesn't make sense<br />
** pure declarative model solves some problems but reduces flexibility<br />
* auto include of rake files allows easy factoring<br />
* possible to separate the definition of dependencies - who depends on me?<br />
* builtin namespaces (ie db:*, test:*)<br />
* plugins in ruby are really simple<br />
** monkey patching<br />
* file dependency checking is built in<br />
** what changed? do it anyway not optimal speed<br />
* auto checking of timestamps<br />
<br />
= Deployment tools =<br />
<br />
== Capistrano for Java deployment? ==<br />
<br />
* posix only (no windows yet)<br />
** installing cygwin is a solution<br />
** write adapters for the commands used (ssh, ftp, etc)<br />
* peepcode demo (http://topfunky.com/clients/peepcode/free-episodes/peepcode-free-deprec.mov)<br />
** building ubuntu box remotely via ssh<br />
** using the deprec gem (http://www.deprec.org/)<br />
* convincing management that using a Ruby tool on a Java project is a good thing<br />
** it's often easier to just do it and show the benefits<br />
** ask for forgiveness rather than permission</div>203.217.69.89http://citconf.com/wiki/index.php?title=Dynamic_Build_Languages&diff=488Dynamic Build Languages2007-07-29T01:05:23Z<p>203.217.69.89: </p>
<hr />
<div>''"Harnessing the power of magic..."''<br />
<br />
Facilitated by Josh Price and Tom Adams<br />
<br />
= Build Tools =<br />
<br />
== What's the current state of Java build tools? ==<br />
<br />
Performance is not always optimal. <br />
<br />
=== ant ===<br />
* programming in xml doesn't make sense<br />
* big ball of ant problem<br />
** the 9000 line "untouchable" collection of build script<br />
* few conventions <br />
** lots of rope to hang yourself<br />
* hard to refactor<br />
* ill-conceived <br />
** even JDD has disowned it<br />
<br />
=== maven ===<br />
* good conventions but hard to diverge from the norm<br />
** simple things are simple<br />
** moderate things are really hard (write a plugin)<br />
** hard things are virtually impossible<br />
* too much voodoo<br />
* not enough docs <br />
** hard to find where/how to configure things<br />
* kind of buggy <br />
** (I think this was attributed to plugins)<br />
* declarative model is too strict <br />
** flexibility is needed here<br />
* appeals to the less experienced <br />
** can get yourself in trouble if you assume it all just works<br />
<br />
== What can Java learn from Ruby? ==<br />
<br />
=== rake ===<br />
* testing your build?<br />
** once it gets really big you need to be able to reason about your build. <br />
** tests could allow you to refactor/optimise/etc without breaking anything<br />
* we really need a first class language for flexibility<br />
** programming in xml doesn't make sense<br />
** pure declarative model solves some problems but reduces flexibility<br />
* auto include of rake files allows easy factoring<br />
* possible to separate the definition of dependencies - who depends on me?<br />
* builtin namespaces (ie db:*, test:*)<br />
* plugins in ruby are really simple<br />
** monkey patching<br />
* file dependency checking is built in<br />
** what changed? do it anyway not optimal speed<br />
* auto checking of timestamps<br />
<br />
= Deployment tools =<br />
<br />
== Capistrano for Java deployment? ==<br />
<br />
* posix only (no windows yet)<br />
** installing cygwin is a solution<br />
** write adapters for the commands used (ssh, ftp, etc)<br />
* peepcode demo<br />
** building ubuntu box remotely via ssh<br />
* convincing management that using a Ruby tool on a Java project is a good thing<br />
** it's often easier to just do it and show the benefits<br />
** ask for forgiveness rather than permission</div>203.217.69.89http://citconf.com/wiki/index.php?title=Dynamic_Build_Languages&diff=487Dynamic Build Languages2007-07-29T00:46:39Z<p>203.217.69.89: </p>
<hr />
<div>''"Harnessing the power of magic..."''<br />
<br />
Facilitated by Josh Price and Tom Adams<br />
<br />
= Build Tools =<br />
<br />
== What's the current state of Java build tools? ==<br />
<br />
=== ant ===<br />
* programming in xml<br />
* big ball of ant<br />
* few conventions lots of rope to hang yourself<br />
* hard to refactor<br />
* ill-conceived<br />
<br />
== maven ==<br />
* too much voodoo not enough docs<br />
* simple things are simple<br />
* moderate things are really hard (write a plugin)<br />
* hard things are virtually impossible<br />
* kind of buggy<br />
* good conventions but hard to diverge from the norm<br />
* declarative model is too strict<br />
* appeals to the less experienced<br />
<br />
== rake ==<br />
* testing your build?<br />
* need a first class language<br />
* file dependency - what changed? do it anyway not optimal speed<br />
* auto checking of timestamps<br />
* separate the definition of dependencies - who depends on me?<br />
* auto include of rake files easy factoring<br />
* builtin namespaces<br />
* plugins in ruby simple <br />
<br />
= capistrano for java deployment =<br />
<br />
* posix only - no windows<br />
* peepcode - building ubuntu -ssh<br />
<br />
* convincing management?</div>203.217.69.89http://citconf.com/wiki/index.php?title=Dynamic_Build_Languages&diff=478Dynamic Build Languages2007-07-28T10:37:35Z<p>203.217.69.89: </p>
<hr />
<div>"Harnessing the power of magic..."<br />
<br />
<br />
= Build Tools =<br />
<br />
What's the current state of play?<br />
<br />
== ant ==<br />
* programming in xml<br />
* big ball of ant<br />
* few conventions lots of rope to hang yourself<br />
* hard to refactor<br />
* ill-conceived<br />
<br />
== maven ==<br />
* too much voodoo not enough docs<br />
* simple things are simple<br />
* moderate things are really hard (write a plugin)<br />
* hard things are virtually impossible<br />
* kind of buggy<br />
* good conventions but hard to diverge from the norm<br />
* declarative model is too strict<br />
* appeals to the less experienced<br />
<br />
== rake ==<br />
* testing your build?<br />
* need a first class language<br />
* file dependency - what changed? do it anyway not optimal speed<br />
* auto checking of timestamps<br />
* separate the definition of dependencies - who depends on me?<br />
* auto include of rake files easy factoring<br />
* builtin namespaces<br />
* plugins in ruby simple <br />
<br />
= capistrano for java deployment =<br />
<br />
* posix only - no windows<br />
* peepcode - building ubuntu -ssh<br />
<br />
* convincing management?</div>203.217.69.89http://citconf.com/wiki/index.php?title=Dynamic_Build_Languages&diff=477Dynamic Build Languages2007-07-28T10:36:13Z<p>203.217.69.89: New page: "Harnessing the power of magic..." = Build Tools = What's the current state of play? == ant == programming in xml big ball of ant few conventions lots of rope to hang yourself hard to ...</p>
<hr />
<div>"Harnessing the power of magic..."<br />
<br />
<br />
= Build Tools =<br />
<br />
What's the current state of play?<br />
<br />
== ant ==<br />
programming in xml<br />
big ball of ant<br />
few conventions lots of rope to hang yourself<br />
hard to refactor<br />
ill-conceived<br />
<br />
== maven ==<br />
too much voodoo not enough docs<br />
simple things are simple<br />
moderate things are really hard (write a plugin)<br />
hard things are virtually impossible<br />
kind of buggy<br />
good conventions but hard to diverge from the norm<br />
declarative model is too strict<br />
appeals to the less experienced<br />
<br />
== rake ==<br />
testing your build?<br />
need a first class language<br />
file dependency - what changed? do it anyway not optimal speed<br />
auto checking of timestamps<br />
separate the definition of dependencies - who depends on me?<br />
auto include of rake files easy factoring<br />
builtin namespaces<br />
plugins in ruby simple <br />
<br />
= capistrano for java deployment =<br />
<br />
posix only - no windows<br />
peepcode - building ubuntu -ssh<br />
<br />
convincing management?</div>203.217.69.89http://citconf.com/wiki/index.php?title=CITCONAsiaPacific2007Sessions&diff=476CITCONAsiaPacific2007Sessions2007-07-28T10:32:16Z<p>203.217.69.89: /* 15:15 Topics */</p>
<hr />
<div>== 10:00 Topics ==<br />
<br />
#[[CI Fundamentals]]<br />
#[[Fragile Test]]<br />
#[[5 Schools of Testing]]<br />
<br />
== 11:15 Topics ==<br />
<br />
#[[Simplifying Mock Object Testing]]<br />
#[[How to convince management that CI & Test is a good thing?]]<br />
# ?<br />
<br />
== 14:00 Topics ==<br />
<br />
#[[What is the right mix of practices and tools for introducing CI]]<br />
# ?<br />
<br />
<br />
== 15:15 Topics ==<br />
<br />
# [[Dynamic Build Languages]]<br />
<br />
== 16:30 Topics ==<br />
<br />
# ?<br />
<br />
<br />
== 17:45 Topic ==<br />
<br />
[[CitConNa2007Retrospective | Retrospective]]</div>203.217.69.89http://citconf.com/wiki/index.php?title=CITCONAsiaPacific2007Sessions&diff=475CITCONAsiaPacific2007Sessions2007-07-28T10:31:48Z<p>203.217.69.89: /* 15:15 Topics */</p>
<hr />
<div>== 10:00 Topics ==<br />
<br />
#[[CI Fundamentals]]<br />
#[[Fragile Test]]<br />
#[[5 Schools of Testing]]<br />
<br />
== 11:15 Topics ==<br />
<br />
#[[Simplifying Mock Object Testing]]<br />
#[[How to convince management that CI & Test is a good thing?]]<br />
# ?<br />
<br />
== 14:00 Topics ==<br />
<br />
#[[What is the right mix of practices and tools for introducing CI]]<br />
# ?<br />
<br />
<br />
== 15:15 Topics ==<br />
<br />
# DynamicBuildLanguages<br />
<br />
== 16:30 Topics ==<br />
<br />
# ?<br />
<br />
<br />
== 17:45 Topic ==<br />
<br />
[[CitConNa2007Retrospective | Retrospective]]</div>203.217.69.89