Pages: 1 ... 5 6 7 ...8 ... 10 ...12 ...13 14 15 ... 19

04/14/06

  04:07:35 pm, by   , 18 words  
Categories: Agile

The Additional Software Tester's Axiom

My co-worker Dustin pointed this post out to me with the following addition.

Axiom VI: Testing? What testing?

04/04/06

02/17/06

  09:09:07 am, by   , 137 words  
Categories: General, Programming, Testing, Agile, Utilities

HanselMinutes #4

Scott Hanselman has started a podcast called HanselMinutes to talk tools and utilities. Episode #4 on Continuous Integration caught my attention because of 2 names mentioned during the discussion of the Ruby Watir library. Both Dustin Woodhouse and Travis Illig got mentioned because of tools they have written to integrate the Watir functionality at development or test time. Travis wrote RubyTestExecutor which hooks Ruby/Watir scripts up with NUnit. Dustin wrote WatirNUt which is a utility that creates a portable, testable NUnit binary wrapper around Watir test scripts and supporting files.

These two individuals and their tools are interesting to me because they both work on teams I manage and I'm excited to see my guys pushing the envelope.

Scott was also kind enough to mention me as one of the local XP experts (my 30 seconds of podcast fame).

01/18/06

  06:57:11 am, by   , 686 words  
Categories: Programming

SqlConnection Connection String Parameter Keywords & Values

I can never find this info, so I'm filing it away.

Name
Default
Description
Application Name
  The name of the application, or '.Net SqlClient Data Provider' if no application name is provided.

AttachDBFilename
-or-
extended properties
-or-
Initial File Name
 
The name of the primary file, including the full path name, of an attachable database. If this setting is specified, the Initial Catalog setting must also be specified.
The database name must be specified with the keyword 'database'.
Example:
Data Source=.; Initial Catalog=; Integrated Security=true;AttachDBFileName=c:\MyFolder\MyDb.mdf 

Update:
You can use the following syntax to attach a database that lives in your "Data" directory:
AttachDBFileName=|DataDirectory|MyDb.mdf 
Connect Timeout
-or-
Connection Timeout

15

The length of time (in seconds) to wait for a connection to the server before terminating the attempt and generating an error.

Current Language

 
The SQL Server Language record name.

Data
Source
-or-
Server
-or-
Address
-or-
Addr
-or-
Network
Address

 
The name or network address of the instance of SQL Server to which to connect.

Encrypt

'false'

When true, SQL Server uses SSL encryption for all data sent between the client and server if the server has a certificate installed. Recognized values are true, false, yes,
and no.

Initial Catalog
-or-
Database


 
The name of the database.

Integrated Security
-or-
Trusted_Connection

'false'

When false, User ID and Password are specified in the connection. When true, the current Windows account credentials are used for authentication.

Recognized values are true, false,
yes, no, and sspi (strongly recommended), which is equivalent to true.

Network Library
-or-
Net

'dbmssocn'

The network library used to establish a connection to an instance of SQL Server. Supported values include dbnmpntw (Named Pipes), dbmsrpcn (Multiprotocol), dbmsadsn (Apple Talk), dbmsgnet (VIA), dbmslpcn (Shared Memory) and dbmsspxn (IPX/SPX), and dbmssocn (TCP/IP).

The corresponding network DLL must be installed on the system to which you connect. If you do not specify a network and you use a local server (for example, "." or "(local)"), shared memory is used.

Packet Size

8192

Size in bytes of the network packets used to communicate with an instance of SQL Server.

Password
-or-
Pwd


 
The password for the SQL Server account logging on (Not recommended. To maintain a high level of security, it is strongly recommended that you use the Integrated Security or Trusted_Connection keyword instead.).

Persist Security Info

'false'

When set to false or no (strongly recommended), security-sensitive information, such as the password, is not returned as part of the connection if the connection is open or has ever been in an open state. Resetting the connection string resets all connection string values including the password. Recognized values are true, false, yes, and no.

User ID


 
The SQL Server login account (Not recommended. To maintain a high level of security, it is strongly recommended that you use the Integrated Security or Trusted_Connection keyword instead.).

Workstation ID

the local computer name

The name of the workstation connecting to SQL Server.

Connection Lifetime

0

When a connection is returned to the pool, its creation time is compared with the current time, and the connection is destroyed if that time span (in seconds) exceeds the value specified by Connection Lifetime. This is useful in clustered configurations to force load balancing between a running server and a server just brought online.

A value of zero (0) causes pooled connections to have the maximum connection timeout.

Connection Reset

'true'

Determines whether the database connection is reset when being drawn from the pool. For Microsoft SQL Server version 7.0, setting to false avoids making an additional server round trip when obtaining a connection, but you must be aware that the connection state, such as database context, is not being reset.

Enlist

'true'

When true, the pooler automatically enlists the connection in the creation thread's current transaction context. Recognized values are true, false, yes, and no.

Max Pool Size

100

The maximum number of connections allowed in the pool.

Min Pool Size

0

The minimum number of connections allowed in the pool.

Pooling

'true'

When true, the SQLConnection object is drawn from the appropriate pool, or if necessary, is created and added to the appropriate pool. Recognized values are true, false, yes, and no.

11/30/05

  07:30:00 am, by   , 206 words  
Categories: Events

Wayne Allen to Speak at Software Association of Oregon (SAO) Developer SIG on 11/30/2005

http://db.sao.org/calendar2/event_description.htm?eventID=11/30/05

Agile software development is a conceptual framework for undertaking software engineering projects. There are a number of agile software development methodologies, such as those espoused by the Agile Alliance, a non-profit organization.

Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team reevaluates project priorities.

Join us as two experts from the developer’s world and one from university will present their findings on agile development. The goal is to raise awareness of some issues not widely known by the systems development community. Speakers at this event include Ward Cunningham of Cunningham & Cunningham, who is one of the Agile Alliance founders, Wayne Allen of Corillian and Gregory Rose of Washington State University – Vancouver.

11/29/05

  01:38:32 pm, by   , 60 words  
Categories: Agile, Misc

Speaking at SAO 11/30/05

For those of you in the Portland, OR metro area you might be interested in attending the SAO Developers SIG on Wednesday Nov 30, 2005 at 7:30am. The topic will be Agile Development - The Academic and Industry Perspectives. I will be sharing the stage with Ward Cunningham and Greg Rose. My topic will be "The Agile Customer".
Hope to see you there.

11/11/05

  04:27:11 pm, by   , 159 words  
Categories: Misc

Why Don't You Take Vacation?

Recently I have run into a number of people, both employees and consultants who can’t seem to separate themselves from their work while on vacation. This behavior is extremely mystifying to me. A related phenomenon is people who won’t/don’t use their vacation. I’ve identified 4 personalities that exhibit these tendencies.

  • William the Worker doesn’t have a separate identity from his work identity and feels lost doing something different than work tasks.
  • Essential Ellen believes that without her things will fall apart.
  • Charlie the Consultant feels the need to work wherever he is because of the financial pressures of hours not worked being hours not billed.
  • Hacker Helen loves her work so much she’d rather do it that anything else and typically works at home after work for "fun" regularly and vacations are no different.

Are you William, Ellen, Charlie or Helen? How do you justify working on vacation or not taking your vacation?

10/14/05

  02:10:34 pm, by   , 11 words  
Categories: Agile

10/13 Carnival of Agilists

10/11/05

  01:16:33 pm, by   , 678 words  
Categories: Agile Process Smells

Agile Process Smells: Solution Stories

One of the things that often happens when the product owner is technically savvy is that they start writing solution stories. That is they specify how something should be done technically rather than what should be done.

For example here is a story that states specifically how the task should be completed (solution):

Partition the customer history table horizontally

This story has been written by a customer who either knows a lot about physical database performance tuning or has talked to someone who does (or a least someone who tossed out a possible solution).

A better story that gets to the real business need (performance) is:

Ensure that saving updated customer information takes no more than 2 seconds on average

By knowing what the need is the developers can look at the whole system to see why saving the customer is taking longer than 2 seconds. This gives the developers latitude on how to solve the problem rather than boxing them in. In this particular case the real solution was fixing some logic in the trigger and adding an index.

What Make a Good Story?

Bill Wake has an article on the characteristics of a good story. He uses the acronym INVEST:

I Independent Stories are easiest to work with if they are independent. If they are independent we can schedule and build them in any order. This allows us to select stories with the highest value without worrying about all the expensive, low value dependent stories.
N Negotiable Negotiation is a key ingredient of agile development. Remember that agile methods are typically scope variable. That is the time line is fixed (iteration length) and the quality and scope are varied. A story is a placeholder for discussion. We need to be able to split, combine, tweak, clarify, etc stories at any time.
V Valuable Stories need to have real business value to the stakeholders. Typically this is the customer although there are other stakeholders (including the development organization). I like to see all stories expressed in ways that the primary stakeholder can understand the value provided by the story. The definition of "value" can vary somewhat from project to project and organization to organization.
E Estimable

If a story can't be estimated then the customer can't derive value or assign a priority to it. We don't need a precise estimate or a guarantee that the estimate will never change. But we do need a good enough estimate that is as accurate as current information allows.

S Small

Having small stories is a result of estimable and negotiable. The larger the story the harder it is to estimate, the less flexibility in negotiation. Each team has a "right size" story which tends to be in the several hours to several days ranges (in ideal time). Stories larger than this tend to fall into the "I don't really know" category.

T Testable

Stories need to be testable, otherwise how do you know the story is complete?

For more info on how to write better stories see Mike Cohn's book User Stories Applied or look at the sample chapter.

Aren't there Any Exceptions?

Of course there are. Most projects have constrains of some kind which are technical in nature. I.e. "Must support Oracle and MySQL" or "all logging will use our custom Log4Net appender". These are definitely solutions, but generally apply to all (or most) stories so I track them separately. I've heard of others using different colored cards to visually indicate the difference between feature stories and constraint stories. I also like to make a note on my feature stories if there is some particular reason to pay attention to a constraint, at least until the team gets a feel for where the constraints apply.

Solution Stories in the Wild?

What are the best examples of solution stories from your experience and how would you rewrite them to be "real" stories?

Agile principles at work
So which agile principles are at work in correcting this smell?

  • Developers create & estimate tasks
  • Developers self select tasks
  • Customers write good stories

1 ... 5 6 7 ...8 ... 10 ...12 ...13 14 15 ... 19

December 2017
Mon Tue Wed Thu Fri Sat Sun
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
 << <   > >>

Search

  XML Feeds

Real Time Web Analytics
powered by b2evolution CMS