Difference between revisions of "Chris Gough"

From CitconWiki
Jump to: navigation, search
(New page: = Chris Gough = I'm a technical manager for the Federal Government (Department of the Environment and Water Resources). I'm coming to CITCON because I am in the process of rethinking our t...)
 
(rv to Revision as of 04:47, 10 August 2007)
 
(7 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
= Chris Gough =
 
= Chris Gough =
I'm a technical manager for the Federal Government (Department of the Environment and Water Resources). I'm coming to CITCON because I am in the process of rethinking our testing strategy, and I suspect CI could be an important feature of that. My contact details are:
+
[http://www.citconf.com/wiki/index.php?title=CITCONAsiaPacific2007Registrants Attendee, CITCON Asia Pacific 2007]
* phone: +61 2 6274 2011
+
* fax: +61 2 6274 1105 (shared, make sure it's addressed to me and has a page count)
+
* mobile: 0418 441 605 (use this at CITCON, of course)
+
* email: chris.gough@**************.gov.au (can you guess the domain?)
+
  
== Background ==
+
I'm a CI newbie, and these are the sessions I attended:
Specifically, for the last few years I have manage support, development and maintenance of systems used (by the Approvals and Wildlife Division) to administer the Environmental Protection and Biodiversity Conservation Act of 1999 (EPBC Act). Before this gig I used to teach at the Canberra Institute of Technology (Software Development Department). Before that, I was a developer (> 10 years).
+
  
* [http://www.environment.gov.au/ Department of the Environment and Water Resources]
+
* [http://www.citconf.com/wiki/index.php?title=CI_Fundamentals CI Fundamentals] - The right place for me to start.
* [http://www.environment.gov.au/epbc/ EPBC Act at The Department]
+
* [http://www.citconf.com/wiki/index.php?title=Simplifying_Mock_Object_Testing Simplifying Mock Object Testing] - I learned what mock-objects were in the hallway outside this meeting so much of the discussion went over my head - however I did leave the room with an idea of what, why, and how to use mock objects. Monkey-see, monkey-do. The next step on that journey will probably be to sniff out the mockery in the rails test framework (I'm a rails newbie too).
* [http://www.cit.act.edu.au/bit/softwaredevelopment/ Department of Software Development, CIT]
+
* [http://www.citconf.com/wiki/index.php?title=What_is_the_right_mix_of_practices_and_tools_for_introducing_CI What is the right mix of practices and tools for introducing CI] Highly relevant for me; a lot of information for one session, especially since the nature of the topic means there will be different opinions and "every tool that somebody in the room likes or found useful" is clearly not the right mix to start with. I left with lots of web links to look up, which is the most I could every hope from a session like this.
 +
* [http://www.citconf.com/wiki/index.php?title=Clover2 Clover2] For me, a random look at a sample tool (a test coverage metric generator). Interesting, I can see how it would be useful.
 +
* [http://www.citconf.com/wiki/index.php?title=Using_Dynamic_Languages_for_Writing_Tests Using Dynamic Languages for Writing Tests] Had secretly hoped to see an example of python rig testing a J2EE app in a CI context. I saw a Groovy one instead...  [http://citconf.com/wiki/index.php?title=Tomjadams Tom Adams'] demonstration of Domain Specific Language in a testing context will change the way I create software.
  
== My CI story ==
+
I had a great CITCON experience, definitely better than an old-fashioned conference.
 
+
We suffer from "packaging and deployment" bottlenecks, I figured CI would force the developers to streamline the build automation and keep it working. I also hope that it would contribute to a better culture arround configuration and change management, and of course push the automated testing front and centre. Our unit-test coverage is patchy, basically M&C layers are OK (J2EE with EJB.v3 on JBOSS, standard stuff) but V (Facelets/MyFaces with a smattering of JSP) only has token automated tests, still largely manual (expensive, slow, yuck). It feels like "I have to run hard to stay where I am" to maintaining this level of coverage at the moment, but still don't feel confident going into maintenance without the DEV team on hand.
+
 
+
I expect to quadruple the amount of Java code in production over the next three years. At the moment we have one non-trivial J2EE app in production/maintenance, development starting soon on another one, and another compelling business case in circulation.
+
 
+
What's unique about developing software for the Federal Government is the impedance mismatch between the basic assumptions of agile, iterative methodologies and the fundamentally waterfall procurement processes that, by law, we have to follow. I've come to learn more about CI and Testing, but am more likely to be able to contribute to discourse in that space if anyone's interested.
+

Latest revision as of 13:21, 1 April 2008

Chris Gough

Attendee, CITCON Asia Pacific 2007

I'm a CI newbie, and these are the sessions I attended:

  • CI Fundamentals - The right place for me to start.
  • Simplifying Mock Object Testing - I learned what mock-objects were in the hallway outside this meeting so much of the discussion went over my head - however I did leave the room with an idea of what, why, and how to use mock objects. Monkey-see, monkey-do. The next step on that journey will probably be to sniff out the mockery in the rails test framework (I'm a rails newbie too).
  • What is the right mix of practices and tools for introducing CI Highly relevant for me; a lot of information for one session, especially since the nature of the topic means there will be different opinions and "every tool that somebody in the room likes or found useful" is clearly not the right mix to start with. I left with lots of web links to look up, which is the most I could every hope from a session like this.
  • Clover2 For me, a random look at a sample tool (a test coverage metric generator). Interesting, I can see how it would be useful.
  • Using Dynamic Languages for Writing Tests Had secretly hoped to see an example of python rig testing a J2EE app in a CI context. I saw a Groovy one instead... Tom Adams' demonstration of Domain Specific Language in a testing context will change the way I create software.

I had a great CITCON experience, definitely better than an old-fashioned conference.