Skip navigation.

coldfusion

Agile Development - article I wrote earlier in this year

|

I will be blogging more and more about agile development and SCRUM. here is an article I wrote a few months back, after CFUNITED:





CFUnited Session Review: Pragmatic ColdFusion: Build, Test, Deploy by John Paul Ashenfelter

Jul 03, 2007

by Doug Sims, CFUnited Correspondent


http://evenamonkey.com

This year I found myself attending CFUnited after only six days in a new job and my first experience working in an Agile/SCRUM environment. I left San Antonio armed with the agile development book from Microsoft Press. Needless to say, I gained more knowledge about agile development in a one hour session with John Paul Ashenfelter than I did reading the first four chapters of the book on the plane.

John Paul was able to sum up the basic principals of Agile Development in only 24 words in his Agile Manifesto:

Individuals and Interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Thank you, Mr. Ashenfelter. Awesome and concise, if I don't say so myself. First, let's expand upon these four goals in the Agile Manifesto, before discussing ways to meet some of these goals in practice.

Agile Goal: Individuals and interactions:

  • Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

  • Business people and developers must work together daily throughout the project.

  • The most efficient method of conveying information to and within a development team is face to face conversation.

  • Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

  • The best architectures, requirements and designs emerge from self-organizing teams.

  • At regular intervals the team reflects on how to become more effective, and then tunes and adjusts its behavior accordingly.

Agile Goal: Working Software

  • Our highest priority is to satisfy the customer though early and continuous delivery of valuable software.

  • Deliver working software frequently from a couple of weeks to a couple of months with a preference to the shorter timescale.

  • Working software is the primary measure of progress.

  • Continuous attention to the technical excellence and good design enhances agility.

  • Simplicity ? what is the simplest solution that will work in a given scenario?

Agile Goal: Customer Collaborations

  • Recognize that the customer/ end user is an active member of the development team.

  • Business people and developers must work together daily throughout the project.

Agile Goal: Responding to Change

  • Welcome changing requirements even late in development. Agile processes harness change for the customers competitive advantage.

  • At regular intervals, the team reflects on how to become more effective, and then tunes and adjusts its behavior accordingly.

In practice, what does this mean?

Produce working software: As this is the primary measurement of progress, give the customer constant access to the system, which is updated frequently.

Individuals and Interactions: The developers control the development process, including development tools, platforms, methodology

Customer Collaboration: Put the end user on your team. Collect user stories(personas), use short iterations and most importantly, make sure the application is always accessible.

Respond to Change: Embrace change in your development process. It's going to happen whether you plan for it or not, so better be prepared.

How to get Started:

Continuous integration has the quickest ROI (return on investment):

  • Start with source control.

  • Automate your deployment.

  • Start testing now. (New applications should focus on unit testing, while existing applications should focus on application testing.)

Investing in people is the biggest ROI:

  • books

  • conferences

  • training

  • work environment

  • Downtime, Vacation

After working in a traditional development environment for the last seven years, I am more excited that ever to be working in an Agile environment. It is truly a smarter way to develop software. SCRUM methodologies take this even one step further with daily stand-up meetings where each team member communicates what they accomplished the last day, what they plan to accomplish in the next day and any impediments that need to be cleared for progress to continue. In other words, no excuses/high productivity. In our stand-up meeting, we pull up all code committed to the source code repository from the day before on the overhead projector for review by all developers, Quality Assurance and the meeting facilitator. This makes for better software by default, as each developer knows that with every line of code written or modified, they will need to be able to communicate not only what the fix was, but also how and why this is the best solution to the issue at hand. In a popular add campaign a few years ago, Steve Jobs and Apple encouraged us to 'Think Different' when we were choosing a computer platform. After seeing the flaws in the traditional corporate development environment for the last seven years, thinking different about software development is a refreshing change.


Currently a Senior ColdFusion Developer for Harcourt Assessment in San Antonio, Doug Sims has developed enterprise level web application solutions for the heath care, education and broadcast industries. Besides delivering rich web applications and spending time with his family, he also has contributed music for the soundtracks of several independent films. His blog can be found at http://evenamonkey.com.

Application Generation - The Song!

|

My laptop does double duty as a DAW (digital audio workstation) and was working on song ideas on the flight to the Frameworks Conference last Feb. Since I am about to head back to bethesda for cfunited, I thought I would 'Release' a rough mix of that session. look for the download link below:
download
please feel free to leave your feedback.

Reactor.xml: Understanding the difference between 'relate' and 'link'

|

One of my favorite features of reactor (besides everything) is the ability to set up hasOne and HasMany relationships in your reactor.xml file and then be able to use iterators and get other related records and data from the record you are working with. setting up these relationship seems to be an area of confusion for people as they get started with reactor.

Relationships:

There are two basic relationship types: hasOne and HasMany to decide from. this should be an easy task if you already have a basic plan for the app. It may help if you imagine yourself as the object...I am a user object and I 'have many' roles or I am a user and I 'have one' address.

Relationship Types:

Inside the hasOne or hasMany tag, you can define the relationship type.

There are two basic types of reactor.xml relationship types, Reactor syntax calls these 'relate' and 'link'
This is HOW the objects are related. Either a direct relationship(relate) or through a linking table (link)

relate

This is when the Primary key(PK) of one table is used as a foreign key in a second table. This is the one to use if you are only involving 2 tables -with no linking table in the middle. In the below example the 'UserID' PK in the User table is a foreign key in the Reports table. In this instance the user 'Has Many' Reports using a relate tag:

<object name="User" >
    <hasMany name="Report">
        <relate from="UserID" to="UserID" />
    </hasMany>
</object>

this is the easiet to set up in reactor as you just need only define the two objects with a tag within the hasOne or hasMany

link

the 'link' syntax is for when you have a table in the middle like in the case of a user table, a role table and a table that links userID's to RoleID's (UserRole table) This requires three reactor object definitions. in this example: User, Role and UserRole
the user and role both 'have many' of each other:

<object name="User">
    <hasMany name="Role">
        <link name="UserRole" />
    </hasMany>
</object>
<object name="Role">
    <hasMany name="User">
        <link name="UserRole" />
    </hasMany>
</object>

The linking table (UserRole) has 2 hasOne definitions, relating back to the 2 PK's

<object name="UserRole">
    <hasOne name="User">
        <relate from="UserID" to="UserID" />
    </hasOne>
    <hasOne name="Role">
        <relate from="RoleID" to="RoleID" />
    </hasOne>
</object>

Syndicate content