<!--{{{-->
<link rel='alternate' type='application/rss+xml' title='RSS' href='index.xml' />
<!--}}}-->
Background: #fff
Foreground: #000
PrimaryPale: #8cf
PrimaryLight: #18f
PrimaryMid: #04b
PrimaryDark: #014
SecondaryPale: #ffc
SecondaryLight: #fe8
SecondaryMid: #db4
SecondaryDark: #841
TertiaryPale: #eee
TertiaryLight: #ccc
TertiaryMid: #999
TertiaryDark: #666
Error: #f88
/*{{{*/
body {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}

a {color:[[ColorPalette::PrimaryMid]];}
a:hover {background-color:[[ColorPalette::PrimaryMid]]; color:[[ColorPalette::Background]];}
a img {border:0;}

h1,h2,h3,h4,h5,h6 {color:[[ColorPalette::SecondaryDark]]; background:transparent;}
h1 {border-bottom:2px solid [[ColorPalette::TertiaryLight]];}
h2,h3 {border-bottom:1px solid [[ColorPalette::TertiaryLight]];}

.button {color:[[ColorPalette::PrimaryDark]]; border:1px solid [[ColorPalette::Background]];}
.button:hover {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::SecondaryLight]]; border-color:[[ColorPalette::SecondaryMid]];}
.button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::SecondaryDark]];}

.header {background:[[ColorPalette::PrimaryMid]];}
.headerShadow {color:[[ColorPalette::Foreground]];}
.headerShadow a {font-weight:normal; color:[[ColorPalette::Foreground]];}
.headerForeground {color:[[ColorPalette::Background]];}
.headerForeground a {font-weight:normal; color:[[ColorPalette::PrimaryPale]];}

.tabSelected{color:[[ColorPalette::PrimaryDark]];
	background:[[ColorPalette::TertiaryPale]];
	border-left:1px solid [[ColorPalette::TertiaryLight]];
	border-top:1px solid [[ColorPalette::TertiaryLight]];
	border-right:1px solid [[ColorPalette::TertiaryLight]];
}
.tabUnselected {color:[[ColorPalette::Background]]; background:[[ColorPalette::TertiaryMid]];}
.tabContents {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::TertiaryPale]]; border:1px solid [[ColorPalette::TertiaryLight]];}
.tabContents .button {border:0;}

#sidebar {}
#sidebarOptions input {border:1px solid [[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel {background:[[ColorPalette::PrimaryPale]];}
#sidebarOptions .sliderPanel a {border:none;color:[[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel a:hover {color:[[ColorPalette::Background]]; background:[[ColorPalette::PrimaryMid]];}
#sidebarOptions .sliderPanel a:active {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::Background]];}

.wizard {background:[[ColorPalette::PrimaryPale]]; border:1px solid [[ColorPalette::PrimaryMid]];}
.wizard h1 {color:[[ColorPalette::PrimaryDark]]; border:none;}
.wizard h2 {color:[[ColorPalette::Foreground]]; border:none;}
.wizardStep {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];
	border:1px solid [[ColorPalette::PrimaryMid]];}
.wizardStep.wizardStepDone {background:[[ColorPalette::TertiaryLight]];}
.wizardFooter {background:[[ColorPalette::PrimaryPale]];}
.wizardFooter .status {background:[[ColorPalette::PrimaryDark]]; color:[[ColorPalette::Background]];}
.wizard .button {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryLight]]; border: 1px solid;
	border-color:[[ColorPalette::SecondaryPale]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryPale]];}
.wizard .button:hover {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Background]];}
.wizard .button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::Foreground]]; border: 1px solid;
	border-color:[[ColorPalette::PrimaryDark]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryDark]];}
	
.wizard .notChanged {background:transparent;}
.wizard .changedLocally {background:#80ff80;}
.wizard .changedServer {background:#8080ff;}
.wizard .changedBoth {background:#ff8080;}
.wizard .notFound {background:#ffff80;}
.wizard .putToServer {background:#ff80ff;}
.wizard .gotFromServer {background:#80ffff;}

#messageArea {border:1px solid [[ColorPalette::SecondaryMid]]; background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]];}
#messageArea .button {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::SecondaryPale]]; border:none;}

.popupTiddler {background:[[ColorPalette::TertiaryPale]]; border:2px solid [[ColorPalette::TertiaryMid]];}

.popup {background:[[ColorPalette::TertiaryPale]]; color:[[ColorPalette::TertiaryDark]]; border-left:1px solid [[ColorPalette::TertiaryMid]]; border-top:1px solid [[ColorPalette::TertiaryMid]]; border-right:2px solid [[ColorPalette::TertiaryDark]]; border-bottom:2px solid [[ColorPalette::TertiaryDark]];}
.popup hr {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::PrimaryDark]]; border-bottom:1px;}
.popup li.disabled {color:[[ColorPalette::TertiaryMid]];}
.popup li a, .popup li a:visited {color:[[ColorPalette::Foreground]]; border: none;}
.popup li a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border: none;}
.popup li a:active {background:[[ColorPalette::SecondaryPale]]; color:[[ColorPalette::Foreground]]; border: none;}
.popupHighlight {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
.listBreak div {border-bottom:1px solid [[ColorPalette::TertiaryDark]];}

.tiddler .defaultCommand {font-weight:bold;}

.shadow .title {color:[[ColorPalette::TertiaryDark]];}

.title {color:[[ColorPalette::SecondaryDark]];}
.subtitle {color:[[ColorPalette::TertiaryDark]];}

.toolbar {color:[[ColorPalette::PrimaryMid]];}
.toolbar a {color:[[ColorPalette::TertiaryLight]];}
.selected .toolbar a {color:[[ColorPalette::TertiaryMid]];}
.selected .toolbar a:hover {color:[[ColorPalette::Foreground]];}

.tagging, .tagged {border:1px solid [[ColorPalette::TertiaryPale]]; background-color:[[ColorPalette::TertiaryPale]];}
.selected .tagging, .selected .tagged {background-color:[[ColorPalette::TertiaryLight]]; border:1px solid [[ColorPalette::TertiaryMid]];}
.tagging .listTitle, .tagged .listTitle {color:[[ColorPalette::PrimaryDark]];}
.tagging .button, .tagged .button {border:none;}

.footer {color:[[ColorPalette::TertiaryLight]];}
.selected .footer {color:[[ColorPalette::TertiaryMid]];}

.sparkline {background:[[ColorPalette::PrimaryPale]]; border:0;}
.sparktick {background:[[ColorPalette::PrimaryDark]];}

.error, .errorButton {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Error]];}
.warning {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryPale]];}
.lowlight {background:[[ColorPalette::TertiaryLight]];}

.zoomer {background:none; color:[[ColorPalette::TertiaryMid]]; border:3px solid [[ColorPalette::TertiaryMid]];}

.imageLink, #displayArea .imageLink {background:transparent;}

.annotation {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border:2px solid [[ColorPalette::SecondaryMid]];}

.viewer .listTitle {list-style-type:none; margin-left:-2em;}
.viewer .button {border:1px solid [[ColorPalette::SecondaryMid]];}
.viewer blockquote {border-left:3px solid [[ColorPalette::TertiaryDark]];}

.viewer table, table.twtable {border:2px solid [[ColorPalette::TertiaryDark]];}
.viewer th, .viewer thead td, .twtable th, .twtable thead td {background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::Background]];}
.viewer td, .viewer tr, .twtable td, .twtable tr {border:1px solid [[ColorPalette::TertiaryDark]];}

.viewer pre {border:1px solid [[ColorPalette::SecondaryLight]]; background:[[ColorPalette::SecondaryPale]];}
.viewer code {color:[[ColorPalette::SecondaryDark]];}
.viewer hr {border:0; border-top:dashed 1px [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::TertiaryDark]];}

.highlight, .marked {background:[[ColorPalette::SecondaryLight]];}

.editor input {border:1px solid [[ColorPalette::PrimaryMid]];}
.editor textarea {border:1px solid [[ColorPalette::PrimaryMid]]; width:100%;}
.editorFooter {color:[[ColorPalette::TertiaryMid]];}

#backstageArea {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::TertiaryMid]];}
#backstageArea a {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
#backstageArea a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; }
#backstageArea a.backstageSelTab {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
#backstageButton a {background:none; color:[[ColorPalette::Background]]; border:none;}
#backstageButton a:hover {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
#backstagePanel {background:[[ColorPalette::Background]]; border-color: [[ColorPalette::Background]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]];}
.backstagePanelFooter .button {border:none; color:[[ColorPalette::Background]];}
.backstagePanelFooter .button:hover {color:[[ColorPalette::Foreground]];}
#backstageCloak {background:[[ColorPalette::Foreground]]; opacity:0.6; filter:'alpha(opacity:60)';}
/*}}}*/
/*{{{*/
* html .tiddler {height:1%;}

body {font-size:.75em; font-family:arial,helvetica; margin:0; padding:0;}

h1,h2,h3,h4,h5,h6 {font-weight:bold; text-decoration:none;}
h1,h2,h3 {padding-bottom:1px; margin-top:1.2em;margin-bottom:0.3em;}
h4,h5,h6 {margin-top:1em;}
h1 {font-size:1.35em;}
h2 {font-size:1.25em;}
h3 {font-size:1.1em;}
h4 {font-size:1em;}
h5 {font-size:.9em;}

hr {height:1px;}

a {text-decoration:none;}

dt {font-weight:bold;}

ol {list-style-type:decimal;}
ol ol {list-style-type:lower-alpha;}
ol ol ol {list-style-type:lower-roman;}
ol ol ol ol {list-style-type:decimal;}
ol ol ol ol ol {list-style-type:lower-alpha;}
ol ol ol ol ol ol {list-style-type:lower-roman;}
ol ol ol ol ol ol ol {list-style-type:decimal;}

.txtOptionInput {width:11em;}

#contentWrapper .chkOptionInput {border:0;}

.externalLink {text-decoration:underline;}

.indent {margin-left:3em;}
.outdent {margin-left:3em; text-indent:-3em;}
code.escaped {white-space:nowrap;}

.tiddlyLinkExisting {font-weight:bold;}
.tiddlyLinkNonExisting {font-style:italic;}

/* the 'a' is required for IE, otherwise it renders the whole tiddler in bold */
a.tiddlyLinkNonExisting.shadow {font-weight:bold;}

#mainMenu .tiddlyLinkExisting,
	#mainMenu .tiddlyLinkNonExisting,
	#sidebarTabs .tiddlyLinkNonExisting {font-weight:normal; font-style:normal;}
#sidebarTabs .tiddlyLinkExisting {font-weight:bold; font-style:normal;}

.header {position:relative;}
.header a:hover {background:transparent;}
.headerShadow {position:relative; padding:4.5em 0em 1em 1em; left:-1px; top:-1px;}
.headerForeground {position:absolute; padding:4.5em 0em 1em 1em; left:0px; top:0px;}

.siteTitle {font-size:3em;}
.siteSubtitle {font-size:1.2em;}

#mainMenu {position:absolute; left:0; width:10em; text-align:right; line-height:1.6em; padding:1.5em 0.5em 0.5em 0.5em; font-size:1.1em;}

#sidebar {position:absolute; right:3px; width:16em; font-size:.9em;}
#sidebarOptions {padding-top:0.3em;}
#sidebarOptions a {margin:0em 0.2em; padding:0.2em 0.3em; display:block;}
#sidebarOptions input {margin:0.4em 0.5em;}
#sidebarOptions .sliderPanel {margin-left:1em; padding:0.5em; font-size:.85em;}
#sidebarOptions .sliderPanel a {font-weight:bold; display:inline; padding:0;}
#sidebarOptions .sliderPanel input {margin:0 0 .3em 0;}
#sidebarTabs .tabContents {width:15em; overflow:hidden;}

.wizard {padding:0.1em 1em 0em 2em;}
.wizard h1 {font-size:2em; font-weight:bold; background:none; padding:0em 0em 0em 0em; margin:0.4em 0em 0.2em 0em;}
.wizard h2 {font-size:1.2em; font-weight:bold; background:none; padding:0em 0em 0em 0em; margin:0.4em 0em 0.2em 0em;}
.wizardStep {padding:1em 1em 1em 1em;}
.wizard .button {margin:0.5em 0em 0em 0em; font-size:1.2em;}
.wizardFooter {padding:0.8em 0.4em 0.8em 0em;}
.wizardFooter .status {padding:0em 0.4em 0em 0.4em; margin-left:1em;}
.wizard .button {padding:0.1em 0.2em 0.1em 0.2em;}

#messageArea {position:fixed; top:2em; right:0em; margin:0.5em; padding:0.5em; z-index:2000; _position:absolute;}
.messageToolbar {display:block; text-align:right; padding:0.2em 0.2em 0.2em 0.2em;}
#messageArea a {text-decoration:underline;}

.tiddlerPopupButton {padding:0.2em 0.2em 0.2em 0.2em;}
.popupTiddler {position: absolute; z-index:300; padding:1em 1em 1em 1em; margin:0;}

.popup {position:absolute; z-index:300; font-size:.9em; padding:0; list-style:none; margin:0;}
.popup .popupMessage {padding:0.4em;}
.popup hr {display:block; height:1px; width:auto; padding:0; margin:0.2em 0em;}
.popup li.disabled {padding:0.4em;}
.popup li a {display:block; padding:0.4em; font-weight:normal; cursor:pointer;}
.listBreak {font-size:1px; line-height:1px;}
.listBreak div {margin:2px 0;}

.tabset {padding:1em 0em 0em 0.5em;}
.tab {margin:0em 0em 0em 0.25em; padding:2px;}
.tabContents {padding:0.5em;}
.tabContents ul, .tabContents ol {margin:0; padding:0;}
.txtMainTab .tabContents li {list-style:none;}
.tabContents li.listLink { margin-left:.75em;}

#contentWrapper {display:block;}
#splashScreen {display:none;}

#displayArea {margin:1em 17em 0em 14em;}

.toolbar {text-align:right; font-size:.9em;}

.tiddler {padding:1em 1em 0em 1em;}

.missing .viewer,.missing .title {font-style:italic;}

.title {font-size:1.6em; font-weight:bold;}

.missing .subtitle {display:none;}
.subtitle {font-size:1.1em;}

.tiddler .button {padding:0.2em 0.4em;}

.tagging {margin:0.5em 0.5em 0.5em 0; float:left; display:none;}
.isTag .tagging {display:block;}
.tagged {margin:0.5em; float:right;}
.tagging, .tagged {font-size:0.9em; padding:0.25em;}
.tagging ul, .tagged ul {list-style:none; margin:0.25em; padding:0;}
.tagClear {clear:both;}

.footer {font-size:.9em;}
.footer li {display:inline;}

.annotation {padding:0.5em; margin:0.5em;}

* html .viewer pre {width:99%; padding:0 0 1em 0;}
.viewer {line-height:1.4em; padding-top:0.5em;}
.viewer .button {margin:0em 0.25em; padding:0em 0.25em;}
.viewer blockquote {line-height:1.5em; padding-left:0.8em;margin-left:2.5em;}
.viewer ul, .viewer ol {margin-left:0.5em; padding-left:1.5em;}

.viewer table, table.twtable {border-collapse:collapse; margin:0.8em 1.0em;}
.viewer th, .viewer td, .viewer tr,.viewer caption,.twtable th, .twtable td, .twtable tr,.twtable caption {padding:3px;}
table.listView {font-size:0.85em; margin:0.8em 1.0em;}
table.listView th, table.listView td, table.listView tr {padding:0px 3px 0px 3px;}

.viewer pre {padding:0.5em; margin-left:0.5em; font-size:1.2em; line-height:1.4em; overflow:auto;}
.viewer code {font-size:1.2em; line-height:1.4em;}

.editor {font-size:1.1em;}
.editor input, .editor textarea {display:block; width:100%; font:inherit;}
.editorFooter {padding:0.25em 0em; font-size:.9em;}
.editorFooter .button {padding-top:0px; padding-bottom:0px;}

.fieldsetFix {border:0; padding:0; margin:1px 0px 1px 0px;}

.sparkline {line-height:1em;}
.sparktick {outline:0;}

.zoomer {font-size:1.1em; position:absolute; overflow:hidden;}
.zoomer div {padding:1em;}

* html #backstage {width:99%;}
* html #backstageArea {width:99%;}
#backstageArea {display:none; position:relative; overflow: hidden; z-index:150; padding:0.3em 0.5em 0.3em 0.5em;}
#backstageToolbar {position:relative;}
#backstageArea a {font-weight:bold; margin-left:0.5em; padding:0.3em 0.5em 0.3em 0.5em;}
#backstageButton {display:none; position:absolute; z-index:175; top:0em; right:0em;}
#backstageButton a {padding:0.1em 0.4em 0.1em 0.4em; margin:0.1em 0.1em 0.1em 0.1em;}
#backstage {position:relative; width:100%; z-index:50;}
#backstagePanel {display:none; z-index:100; position:absolute; width:90%; margin:0em 3em 0em 3em; padding:1em 1em 1em 1em;}
.backstagePanelFooter {padding-top:0.2em; float:right;}
.backstagePanelFooter a {padding:0.2em 0.4em 0.2em 0.4em;}
#backstageCloak {display:none; z-index:20; position:absolute; width:100%; height:100px;}

.whenBackstage {display:none;}
.backstageVisible .whenBackstage {display:block;}
/*}}}*/
/***
StyleSheet for use when a translation requires any css style changes.
This StyleSheet can be used directly by languages such as Chinese, Japanese and Korean which need larger font sizes.
***/
/*{{{*/
body {font-size:0.8em;}
#sidebarOptions {font-size:1.05em;}
#sidebarOptions a {font-style:normal;}
#sidebarOptions .sliderPanel {font-size:0.95em;}
.subtitle {font-size:0.8em;}
.viewer table.listView {font-size:0.95em;}
/*}}}*/
/*{{{*/
@media print {
#mainMenu, #sidebar, #messageArea, .toolbar, #backstageButton, #backstageArea {display: none ! important;}
#displayArea {margin: 1em 1em 0em 1em;}
/* Fixes a feature in Firefox 1.5.0.2 where print preview displays the noscript content */
noscript {display:none;}
}
/*}}}*/
<!--{{{-->
<div class='header' macro='gradient vert [[ColorPalette::PrimaryLight]] [[ColorPalette::PrimaryMid]]'>
<div class='headerShadow'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
<div class='headerForeground'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
</div>
<div id='mainMenu' refresh='content' tiddler='MainMenu'></div>
<div id='sidebar'>
<div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>
<div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>
</div>
<div id='displayArea'>
<div id='messageArea'></div>
<div id='tiddlerDisplay'></div>
</div>
<!--}}}-->
<!--{{{-->
<div class='toolbar' macro='toolbar [[ToolbarCommands::ViewToolbar]]'></div>
<div class='title' macro='view title'></div>
<div class='subtitle'><span macro='view modifier link'></span>, <span macro='view modified date'></span> (<span macro='message views.wikified.createdPrompt'></span> <span macro='view created date'></span>)</div>
<div class='tagging' macro='tagging'></div>
<div class='tagged' macro='tags'></div>
<div class='viewer' macro='view text wikified'></div>
<div class='tagClear'></div>
<!--}}}-->
<!--{{{-->
<div class='toolbar' macro='toolbar [[ToolbarCommands::EditToolbar]]'></div>
<div class='title' macro='view title'></div>
<div class='editor' macro='edit title'></div>
<div macro='annotations'></div>
<div class='editor' macro='edit text'></div>
<div class='editor' macro='edit tags'></div><div class='editorFooter'><span macro='message views.editor.tagPrompt'></span><span macro='tagChooser'></span></div>
<!--}}}-->
To get started with this blank TiddlyWiki, you'll need to modify the following tiddlers:
* SiteTitle & SiteSubtitle: The title and subtitle of the site, as shown above (after saving, they will also appear in the browser title bar)
* MainMenu: The menu (usually on the left)
* DefaultTiddlers: Contains the names of the tiddlers that you want to appear when the TiddlyWiki is opened
You'll also need to enter your username for signing your edits: <<option txtUserName>>
These InterfaceOptions for customising TiddlyWiki are saved in your browser

Your username for signing your edits. Write it as a WikiWord (eg JoeBloggs)

<<option txtUserName>>
<<option chkSaveBackups>> SaveBackups
<<option chkAutoSave>> AutoSave
<<option chkRegExpSearch>> RegExpSearch
<<option chkCaseSensitiveSearch>> CaseSensitiveSearch
<<option chkAnimate>> EnableAnimations

----
Also see AdvancedOptions
<<importTiddlers>>
http://portal.acm.org/citation.cfm?id=1302496.1302946&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*pub
**2007
**Finlândia
**VTT Technical Research Center of Finland
**Maria Siniaalto
**Pekka Abrahamsson
*comparative case study
**of three software development projects
**object-oriented metrics
**result
***the effect of TDD on program design was not as evident as expected
***the test coverage was significantly superior to iterative test-last development
Tracking the Evolution of Ob ject-Oriented Quality Metrics on Agile Projects
Danilo Sato, Alfredo Goldman, and Fabio Kon 
Department of Computer Science 
University of São Paulo, Brazil 

Analisa 7 projetos ágeis segundo métricas de qualidade de código aferidas automaticamente. 
Dos 7 projetos, 5 foram desenvolvidos no ambiente da disciplina XP oferecida para alunos de graduação. 2 dos projetos são iniciativas de órgãos públicos brasileiros. Um dos projetos públicos tem um cenário especialmente complicado que tornou a adoção do XP mais complexa.

Os projetos são calssificados quanto à adoção de XP segundo o XPRadarChart.

This suggests 
that testing and refactoring are good practices for controlling size and complexity 
and these metrics are good indicators to be tracked by the team.

''As métricas utilizadas:''

Linesof Code(LOC)
Mc Cabe’s CyclomaticComplexity (v(G))
WeightedMethodsperClass (WMC)

LackOfCohesionOfMethods (LCOM)
    * Controversa, há uma referência a favor e uma contra
    * Não foi muito conclusiva

__hierarquia__
DepthofInheritanceTree (DIT)
NumberofChildren (NOC)

__acoplamento__
AfferentCoupling (AC)
EfferentCoupling (EC)

Binkley and Schach found that coupling measures are good predictors for main- 
tenance effort [6]

''conclusões''
Os projetos com menor adoção de XP (como o 7) possuem métricas inferiores de qualidade.

duas linhas para trabalhos futuros:
- medir defeitos e bugs e relacionar com essas medidas
- comparar projetos xp com outros projetos

http://portal.acm.org/citation.cfm?id=1195306&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*pub
**2006
**David Scott Janzen
**EUA
*the first comprehensive evaluation of how TDD affects software architecture and internal design quality.
*Formal controlled experiments were conducted
**in
***undergraduate and graduate academic courses
***a professional training course
***with in-house professional development projects in a Fortune 500 company.
**over 230 student
**almost five hundred software projects
***ranging in size from one hundred to over 30,000 lines of code
**+ a case study
***of fifteen software projects
****developed
*****over five years
*****in a Fortune 500 corporation.
**resultados
***TDD approach are likely to improve some software quality aspects at minimal cost 
****over a comparable test-last approach.
*****TestLast
***statistically significant differences in the areas of code complexity, size, and testing
***internal quality differences can substantially improve
****external software quality (defects)
****software maintainability
****software understandability
****software reusability
***mature programmers prefer the test-first approach
****than test last
***a pedagogical approach
****test-driven learning (TDL)
*****integrates TDD instruction at all levels
******from early programming instruction through professional continuing education
****results indicate some differences between beginning and mature developers
*****reluctance by early programmers to adopt the TDD approach
***establishes a benchmark and framework for future empirical studies
****By providing the first substantial empirical evidence on TDD and internal software quality
http://portal.acm.org/citation.cfm?id=1007512.1007523&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*pub
**2004
**MIT Computer Science & Artificial Intelligence Lab, Cambridge, MA
**EUA
**David Saff
**Michael D. Ernst
*continuous testing
**rodam automaticamente em background enquanto se programa
***like infinitest, autotest
**a controlled human experiment
***evaluate whether students using continuous testing are more successful in completing programming assignments
***We also summarize users' subjective impressions and discuss why the results may generalize
***results
****indicates that the tool has a statistically significant effect on success in completing a programming task
*****but no such effect on time worked
*****Participants using continuous testing were three times more likely to complete the task before the deadline than those without
****Participants using continuous compilation were 2x as likely to complete the task
*****providing empirical support to a common feature in modern development environments
****Most participants found continuous testing to be useful and believed that it helped them write better code faster
*****90% would recommend the tool to others
*****The participants did not find the tool distracting
****intuitively developed ways of incorporating the feedback into their workflow
http://portal.acm.org/citation.cfm?id=1302496.1302947&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*pub
**2007
**India
**Atul Gupta
***Indian Institute of Technology Kanpur, India
**Pankaj Jalote
***Indian Institute of Technology Delhi, India
*abstract
**evaluate the impact of TDD on various program development activities 
***like designing, coding, and testing
***controlled experiment
**we compare it with the conventional way of developing the code
**In a single-factor block design
***two groups of students
****developed two moderately sized programs
****following the two development-styles under study
*****TDD
*****tradicional
**results suggest that TDD helps in reducing overall development effort and improving developer's productivity
***whereas the code quality seems to be affected by the actual testing efforts applied during a development-style.
http://portal.acm.org/citation.cfm?id=952532.952753&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*pub
**2003
**North Carolina State University, Raleigh, NC
**EUA
**Boby George
**Laurie Williams
*we ran a set of structured experiments with 2 groups
**24 professional pair programmers
**2 grupos
***one group developed code using TDD
***the other a waterfall-like approach
**both groups developed a small Java program
**results
***We found that the TDD developers produced higher quality code

****passed 18% more functional black box test cases
***TDD developer pairs took 16% more time for development
***A moderate correlation between time spent and the resulting quality was established upon analysis
***It is conjectured that the resulting high quality of code written using the TDD practice may be due to the granularity of TDD
****which may encourage more frequent and tighter verification and validation
***the programmers which followed a waterfall-like process often did not write the required automated test cases after completing their code
****might be indicative of the tendency among practitioners toward inadequate testing
***supports that TDD has the potential of increasing the level of testing in the industry
BrianMarickTestingForProgrammers
EmmanuelMuloDesignForTestability
StenviAutomatedTestStrategyConsulting
''Ordem cronológica:''

2003
AnInitialInvestigationOfTestDrivenDevelopmentInIndustry 
AssessingTestDrivenDevelopmentAtIBM
ImplicationsOfTestDrivenDevelopmentAPilotStudy

2004
AnExperimentalEvaluationOfContinuousTestingDuringDevelopment

2005
OnTheEffectivenessOfTheTestFirstApproachToProgramming
SoftwareArchitectureImprovementThroughTestDrivenDevelopment

2006
EmpiricalValidationOfTestDrivenPairProgrammingInGameDevelopment
DrivingSoftwareQualityHowTestDrivenDevelopmentImpactsSoftwareQuality
EvaluatingAdvantagesOfTestDrivenDevelopmentAControlledExperimentWithProfessionals
EvaluatingTheEfficacyOfTestDrivenDevelopmentIndustrialCaseStudies
ResultsFromIntroducingComponentLevelTestAutomationAndTestDrivenDevelopment
AnEmpiricalEvaluationOfTheImpactOfTestDrivenDevelopmentOnSoftwareQuality
OnTheInfluenceOfTestDrivenDevelopmentOnSoftwareDesign

2007
DoesTestDrivenDevelopmentImproveTheProgramCode_AlarmingResultsFromAComparativeCaseStudy
AnExperimentalEvaluationOfTheEffectivenessAndEfficiencyOfTheTestDrivenDevelopment
AComparativeCaseStudyOnTheImpactOfTestDrivenDevelopmentOnProgramDesignAndTestCoverage

2008
RealizingQualityImprovementThroughTestDrivenDevelopmentResultsAndExperiencesOfFourIndustrialTeams
DoesTestDrivenDevelopmentReallyImproveSoftwareDesignQuality

2009 (jah!!!    :-o )
EmpiricalInvestigationTowardsTheEffectivenessOfTestFirstProgramming
BertolinoTestChalenges
BernerObservationsAutomatedTest
CemKanerOngoingRevolution
PettichordDesignForTestability
MuloDesignForTestability

DaniloSatoMetricasAgeis
AgilcoopEvolutionMetricsAgileProjects

FowlerRefactoring
*pub
**2003
**EUA
**E. Michael Maximilien
***IBM Corp. and NCSU, Raleigh, NC
**Laurie Williams
***North Carolina State University, Raleigh, NC
*we built a non-trivial software system
**based on a stable standard specification
**using a disciplined, rigorous unit testing
**build approach based on the test- driven development (TDD) practice
**results
***reduced our defect rate by about 50 percent compared to a similar system that was built using an ad-hoc unit testing approach
***The project completed on time
****with minimal development productivity impact
***the suite of automated unit test cases created via TDD is a reusable and extendable asset that will continue to improve quality over the lifetime of the software system
***test suite will be the basis for quality checks
****will serve as a quality contract between all members of the team
(warning: conteúdo muito flúido aqui, ainda...)

Por enquanto, estou com os seguintes assuntos em mente:
- DesenvolvimentoAgil, ExtremeProgramming
- TestesAutomaticos ([[TDD]], [[BDD]])
- Refactoring
- [[Testabilidade]]

Também são de meu interesse:
- DSLs
- CodingDojo
- Colaboratividade e trabalho em equipe (TheWorldCafé, OpenSpaceTechnology, Coaching, RedesSociais)
BehaviourDrivenDevelopment
Uma variação do TDD onde existe a preocupação com "como" orientar a escrita dos testes em si.

Nesse caso, prega-se que os testes devem "orientados" aos comportamentos esperados do sistema.

Além disso, existe uma tendência em se aproximar a definição, manutenção, compreensão dos testes dos usuários, gerentes de produto e projeto, etc. criando uma ligação forte entre o levantamento de requisitos e os testes. Testes passam a ser considerados especificações executáveis.

Com isso, a linguagem dos testes - que são programas escritos em linguagens de programação - passam a tomar uma forma mais amigável, mais parecida com uma linguagem natural minimamente estruturada.

Faz-se uma relação de que [[BDD]] = [[TDD]] + [[DDD]] (DomainDrivenDesign), no sentido de que cria-se uma linguagem ubiqua, comum a programadores e stakeholders não-técnicos, o que aumenta e torna mais direta a comunicação entre os envolvidos no projeto.
Oi, 

  Estou usando esse espaço para manter disponíveis minhas pesquisas para meu projeto de mestrado.

  Estou listando os AssuntosDeInteresse de uma forma geral, mas vou manter também o TemaDoProjeto com a visão que estou tendo atualmente.
  
  Alguns ArtigosLidos inicialmente, embora eu já tenha coletado mais um monte (ArtigosEfeitosTDD)
  Tem alguns ArtigosALer (mas tem um inbox mais completo no meu freemind)

   Comecei a fazer também uma ClassificaçõesDosArtigos
Observations and Lessons Learned  
from Automated Testing 
 
Stefan Berner, Roland Weber, and Rudolf K. Keller* 
Zühlke Engineering AG 
Zürich-Schlieren 
Switzerland 
{sbn, row, ruk}@zuehlke.com 
----

Descreve observações feitas em 12 projetos sobre automação de testes

''__Descreve brevemente 5 projetos__''
* Project A: System to Manage Distribution of Assets
* Project B: Java-Based Application Platform
* Project C: Point of Sale System for Life Insurances
* Project D: Sales Support for Tailored Industrial Facilities
* Project E: System Test Automation for Control System

''__observações e experiências__''
* Estratégia de automação de testes normalmente é inapropriada
** Misplaced or Forgotten Test Types
** Wrong Expectations
** Missing Diversification (Tool Usage is Restricted to Test Execution)
* Os testes são muito mais repetidos do que norlamente se espera
* A capacidade de executar testes automáticos diminui se os testes não são usados
** failure patterns (4 fases)
* Testes automáticos não substituem os testes manuais

* ''Testabilidade é um requisito não funcional normalmente esquecido''
** design for testability
*** dificuldades em testar
****                falta de camadas (testar isoladamente)
****                dificuldade de mockar
****                poucos assert no próprio código (auto diagnóstico)
****                mensagens de erros incompreensíveis
***            razões
****                faltam requisitos
****                design inadequado para testabilidade (problema pouco investigado. exemplo: [11])
**        design of test environment
***            instalação e configuração manual do sistema sob teste
***             falta de acesso a infra. ex: scm
***             execução dos testes não é visível o suiciente para o testador

*    Manutenção do testware é difícil
**        arquitetura pouco documentada
**        oportunidades de reuso desperdiçadas
**        testware desestruturado
**        testware não testado


''__sinopse e consequencias__''
    tabela
        relaciona as observações e experiências com os projetos
    adote uma estratégia de testes explícita
    projete visando testabilidade
    itegre seu software diariamente
    aplique boas práticas de engenharia


''__Referências interessantes__''

[4] Fewster, M., D. Graham. Software Test Automation:  Effective use of test execution tools. ACM Press, 1999.  
[7] http://www.quest.com/jprobe/ <http://www.quest.com/jprobe/>
[8] Kaner, C. Architectures of Test Automation. Software  Testing, Analysis & Review Conference (Star) West, San  Jose, CA, Oct 2000.
[9] Kaner, C. Improving the Maintainability of Automated Test  Suites. Software QA, 4(4), 1997.
 [10] Myer, G. J. The Art of Software Testing. New York: Wiley  & Sons, 1979. (''natureza destrutiva dos testes'')
[11] Pettichord, B. Design for Testability. Proc. of Pacific  Northwest Software Quality Conference, Oct 2002. (PettichordDesignForTestability)
[12] Pettichord, B. Seven Steps to Test Automation Success.  http://www.pettichord.com (Revised version of a paper  presented at STAR West, San Jose, Nov 1999). (''testes com pouco uso. perdemos a confiança neles)
''Software Testing Research: Achievements, Challenges, Dreams''
Antonia Bertolino 
Istituto di Scienza e Tecnologie dell’Informazione “A. Faedo” 
Consiglio Nazionale delle Ricerche 
56124 Pisa, Italy 
antonia.bertolino@isti.cnr.it

----

A autora traça um panorama geral das realizações (achievements), dos sonhos e dos desafios (para se realizar esses sonhos), em 4 áreas de pesquisa:
* Universal TestTheory
* Test based modeling
* 100% automatic testing
* efficacy-maximized test theory

Os desafios descritos são ainda relacionados a 6 perguntas básicas relativas aos testes (porque, como, quanto, o que, onde, quando). Com isso a autora traça um gráfico 2D sintetizando todos os assuntos tratados em uma página.

Algumas realizações e desafios abraçam mais de uma questão e/ou área de pesquisa, então não vou tentar expressar o gráfico todo aqui. Vou apenas lista-los:
* Realizações
** testing process
** reliability testing
** protocol testing
** oo testing
** component based testing
** test criteria
** comparison among criteria

*Desafios:
** explicit test hypotheses
** test efectiveness
** compositional testing
** empirical body of evidence
** model-based testing
*** derivar testes a partir dos modelos (uml por exemplo)
** anti-model-based testing
** test oracles
** test input generation
** ''domain-specific test approaches''
** ''on-line testing''
*** testar o software rodando na produção
** ''controlling evolution''
*** testar componentes em evolução (regressão)
** ''leveraging user population and resources''
*** coleta dados testes na produção
** testing patterns
*** teste é caro (we lack up-to-date and reliable references) (value-based software engineering,  Boehm)
** undestanding the cost of testing
** education of software testers
** emerging developing paradigms
** functional and extra-functional

(os negritos representam aqueles que mais me interessaram, à primeira vista)
Apresentação, slides.
The Ongoing Revolution in Software Testing 
Cem Kaner, J.D, Ph.D. 
Software Test & Performance Conference, December 8, 2004 

----


Reflete sobre algumas premissas do livro

        TestingComputerSoftware <http://www.amazon.com/Testing-Computer-Software-2nd-Kaner/dp/0471358460>
            segunda edição
                1999


''__assertions widely made__''

* The Role of testers
**            Testers are THE advocates of quality on a project.
**            Test groups should evolve into quality assurance groups.
**            The test group should have the power to block release if product quality is too low.
**            Testers and programmers have conflicting interests.
**            The test group should work independently of the programmers.
**            Testers should push their project teams to follow "appropriately professional development models," like the Waterfall, that require people to THINK before they act.
**            Testers should base test cases on documented characteristics of the program.
***                If the software documentation is inadequate for this, testers should assert a quality control function and demand better specification and requirements documentation.
**            The primary reason to test is to find bugs.
**            The primary reason to test is to prove the program works correctly.

* The planning and documentation
**            Testers should specify the expected result of every test, in advance.
**            Exploratory testing, if done at all, should be done only by experts.
**            There should be at least one thoroughly documented test for every requirement item or specification item.
**            Testers should design most or all tests early in development.
**            Testers should design all tests for reuse as regression tests.
**            Testers should document manual tests in great procedural detail so that they can be handed down to less experienced or less skilled testers.
**            Testers should document each test case individually, ideally storing them in a test case management system that describes the preconditions, procedural details, postconditions, and basis (such as trace to requirements) of each individual test.

*The practice of testing
**            Testers should assume that the programmers did a light job of testing and so should extensively cover the basics (such as boundary cases for every field).
**            Testers should develop automated tests at the user interface level.
**            Testers should design tests without knowledge of the underlying code.
**            Testers should design the build verification tests, even the ones to be run by programmers.
**            Most testers don't need to be programmers, because they only have to specify how the external program will behave in their tests. Testing tools will allow business experts to develop automated tests without having to program.
**            The pool of tests should cover every line and branch in the program, or perhaps every basis path.
**            All failures must be reported into a bug tracking system and carefully counted.
**            We can measure the individual effectiveness of software testers by counting how many bugs they find, perhaps with an adjustment for bug severity.
**            We can tell how close we are to release of the product by examining the bug curve that shows bug finds per week.
CicloPDCA
também conhecido como CicloDeDemming

''Plan Do Check Act''

Ciclo de atividades que direciona o trabalho.

Em projetos de software "ágeis", esse ciclo é projetado em vários níveis, desde o processo de escrita de código, usando [[TDD]], até o planejamento semestral, mensal, semanal, diário.
Praticamente todos os ArtigosEfeitosTDD são EstudosDeCaso

* ''O que mediu?''
** [[pesquisa]] subjetiva preenchida pelos programadores
** [[produtividade]]
** [[cobertura]] dos testes sobre o código
** [[qualidade]] (aqueles que ainda não identifiquei se é interna ou externa)
** [[qualidadeExterna]]
** [[qualidadeInterna]]

* ''em que contexto mediu?''
** [[comEstudantes]], [[emCursos]], ou com algum FundoPedagogico;
** [[naIndustria]]
** [[continuousTesting]]
** [[bowling]] - os que usaram o problema do score do boliche
** [[game]] - desenvolvimento de jogos

* ''O que compara?''
** TddWaterfal
** [[testFirstLast]]

* ''resultados''
** TddCoberturaAumenta
** TddMaisEfetivo
** TddMenosDefeitos
** TddQualidadeAumenta
** TddQualidadeIndiferente
** TddQualidadePiora

** TddProdutividadeAumenta
** TddProdutividadeIndiferente
** TddProdutividadeDiminui




* ''Autores'' (alguns q chamaram a atenção a princípio)
** [[janzen]]
** [[kaufmann]]
** [[maximilien]]
** [[Saiedian]]
** [[wiliams]]
** [[Siniaalto]]

* ''Cronológico:''
** [[2003]]
** [[2004]]
** [[2005]]
** [[2006]]
** [[2007]]
** [[2008]]
** [[2009]]

* ''Nacionalidade''
** [[EUA]]
** [[espanha]]
** [[italia]]
** [[finlandia]]
** [[India]]
** [[polonia]]
** [[suecia]]


É um ambiente coletivo de treinamento de práticas de programação. O nome Dojo foi apropriado dos antigos centros de treinamento em artes marciais.

O grupo (5, 6 programadores) se reúne em um ambiente de "laboratório" ou "sala de aula", com um computador ligado a um projetor, de modo que dois programadores possam sentar-se no comando do computador e os demais possam assistir ao que os dois estão fazendo no telão.

[img[http://farm3.static.flickr.com/2300/2261026040_a432723747.jpg?v=0]]

Cada reunião de poucas horas tem o intuito de resolver (ainda que parcialmente) um desafio de programação proposto, usando TDD e PairProgramming. 

Os programadores sentam-se dois a dois no comando do computador e programam enquanto os demais assistem. Depois de alguns minutos uma pessoa da platéia toma o lugar de um dos programadores, criando um ciclo de revezamento onde todos assistem e participam da resolução do problema.

Ao final, o grupo faz uma análise do resultado da sessão, revisando e discutindo alguns pontos relacionados ao que aconteceu.


- Não sei se existem referências científicas sobre Dojo ainda...
Tem essa: http://groups.google.com/group/dojo_sp/web/CodingDojoSP-2008.pdf 

- Ainda não sei qual a origem do CoddingDojo... Deve ter referência em algum site

- Existem comunidades mundiais de grupos Dojo que se relaciona virtualmente pela internet (ex: http://www.codingdojo.org )
DomainDrivenDesign
Tese de mestrado do Danito T. Sato, disponível em http://www.teses.usp.br/teses/disponiveis/45/45134/tde-06092007-225914/

Agosto de 2007

*1. Introduçao 
*2. Métodos Ageis
*3. Métricas de Acompanhamento
**3.1. Definições
**3.2. Classificações
***3.2.1. Objetiva/Subjetiva
***3.2.2. Quantitativa/Qualitativa
***3.2.3. Organizacional/Acompanhamento
**3.3. O Que Medir?
***3.3.1. Abordagem Objetivo-Pergunta-Métrica
***3.3.2. Abordagem Lean 
***3.3.3. Retrospectivas 
***3.3.4. Características de Uma Boa Métrica Ágil
**3.4. Discussão
**3.5. Exemplos 
***3.5.1. Medidas
***3.5.2. Métricas Organizacionais
***3.5.3. Métricas de Acompanhamento
**3.6. Considerações Finais
*4. Estudo de Caso
**4.1. Método e Métricas
**4.2. Projetos
***4.2.1. Formato de Apresentação
***4.2.2. Considerações
***4.2.3. Fatores de Contexto em Comum (XP-cf )
***4.2.4. Projetos Acadêmicos
***4.2.5. Projetos Governamentais
***4.2.6. Grafico em Radar de XP (XP Radar Chart )
**4.3. Analise dos Resultados
***4.3.1. Nıvel Pessoal e Agilidade
***4.3.2. An´alise das Respostas do Question´ario de Aderˆencia
***4.3.3. Retrospectivas como Ferramenta de Acompanhamento
***4.3.4. M´etricas de Acompanhamento para Design e Qualidade do Codigo
***4.3.5. M´etrica de Acompanhamento para Integrac˜ao Cont´ınua
***4.3.6. M´etrica de Acompanhamento para Testes e Qualidade
**4.4. Discuss˜ao e Conclus˜oes
*5. Conclus˜ao
**5.1. Contribuic˜oes
**5.2. Trabalhos Futuros
*A. Question´ario - M´etricas de Aderˆencia (XP-am) 
**A.1. Question´ario de Ades˜ao – Programação Extrema (XP)
*B. Cat´alogo de M´etricas para o Tracker de XP 
**B.1. Programação Pareada
**B.2. Versoes Pequenas
**B.3. Integrac˜ao Cont´ınua
**B.4. Desenvolvimento Dirigido por Testes
**B.5. Jogo do Planejamento
**B.6. Cliente com os Desenvolvedores
**B.7. Refatorac˜ao e Design Simples
**B.8. Padronizac˜ao de C´odigo
**B.9. Propriedade Coletiva do Codigo
**B.10. Met´afora ou Sistema de Nomes
**B.11. Ritmo Sustent´avel
BemVindo
http://portal.acm.org/citation.cfm?id=1425786.1425803&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*publicação
**2007
***polônia
**Maria Siniaalto
**Pekka Abrahamsson
*comparative case study of five small scale software development projects
**the effect of TDD on program design was studied using both traditional and package level metrics
**an unwanted side effect can be that some parts of the code may deteriorate
***como assim?
**differences in the program code (TDDtradicional) were not as clear as expected
**question: whether the possible benefits of TDD are greater than the possible downsides
***whether the same benefits could be achieved just by emphasizing unit-level testing activities
http://portal.acm.org/citation.cfm?id=1345866.1345901&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785


*publicação
**2008
***EUA
**David Janzen
**Hossein Saiedian
*publicado tb no IEEE <http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=4455636&isnumber=4455615&punumber=52&k2dockey=4455636@ieeejrns&query=((tdd)%3Cin%3Emetadata)&pos=3&access=no>
**We weren't able to confirm claims that TDD improves cohesion while lowering coupling
**but we anticipate ways to clarify the questions these design characteristics raised.
***In particular, we're working to eliminate the confounding factor of accessor usage in the cohesion metrics.
**é igualzinho?
***o abstract é !=
*focused on internal software quality that is, design and code characteristics such as code complexity, size, coupling, and cohesion
*three quasicontrolled experiments and one case study in a Fortune 500 company
*two quasicontrolled experiments with university students in undergraduate and graduate software engineering courses
*We evaluated 24 student and professional programmers working on 21 software projects
**from a few hundred to over 30,000 lines of code
*The results indicate that
**TDD programmers tend to write software modules that are smaller, less complex, and more highly tested than modules produced by their test-last counterparts.
**However, the results didn't support claims for lower coupling and increased cohesion with TDD.
http://domaindrivendesign.org/
http://portal.acm.org/citation.cfm?id=1187623.1187715&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*publicação
**2006
***EUA
**Lisa Crispin
*arquivo baixado <artigos/inbox/2_HowTDDImpactsSWQuality.pdf>
**texto de duas páginas
***parece ser mais informal...
**imprimi
*does TDD really improve software quality?
**cita
***DavidJanzen <#Freemind_Link_688162288>
****Software architecture improvement through test-driven development <http://portal.acm.org/citation.cfm?id=1094855.1094954&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785>
*****Software architecture improvement through test-driven development <http://portal.acm.org/citation.cfm?id=1094855.1094945&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785>
*****2005
*****DavidJanzen
****TDD passa 18 a 50% mais testes externos
****cita outros estudos
*****aumenta a qualidade externa
*****aumenta a produtividade
****studies reveal that computational complexity is significantly lower in test-first projects
*****while test volume and coverage are higher.
***Boby George and Laurie Williams  <#Freemind_Link_1887164451>
****An initial investigation of test driven development in industry <http://portal.acm.org/citation.cfm?id=952532.952753&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785>
****TDD : 18% mais testes funcionais
****ultrapassa os padrões de cobertura da indústria
**reporta
***experiência dela em alguns projetos
****bem informal
***The production defect rate in the second quarter of 2005 was down 62 percent from the same quarter in 2004. 
***Between the second quarter of 2005 andthe second quarter of 2006, the defect rate went down another 39 percent.  
**outras referencias
***kenbeck
****"aim, Fire"
*****IEEE sofware
******Sept./Oct. 2001
***Brian Marick
****shared languageor project creole
*****http://www.exampler.com/book/preface.html <http://www.exampler.com/book/preface.html >
Design for Testability in Software Systems
Tese de mestrado


Software Engineering Research Group 
Department of Software Technology 
Faculty EEMCS, Delft University of Technology 
Delft, the Netherlands 
www.ewi.tudelft.nl


Julho/2007
http://portal.acm.org/citation.cfm?id=1465742.1466105&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*publicação
**2009
**EUA
**Liang Huang
***Department of Computer Science, University of Sheffield, Sheffield, United Kingdom
**Mike Holcombe
*controlled experiment
**four years' data,
**effectiveness of 
***Test First 
***Test Last (TL)
**experimental results showed that Test First teams spent a larger percentage of time on testing
**qualidade externa mínima alcançável
***of delivered software
***increases with the percentage of time spent on testing regardless of the testing strategy (TF or TL)
****although there does not exist a linear correlation between them
**strong linear correlation
***in Test First teams
***between the amount of effort spent on
****testing
****coding
***while this phenomenon was not observed in Test Last teams
http://portal.acm.org/citation.cfm?id=1156428.1157253&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*pub
**2006
**Shaochun Xu
***Algoma University College, Laurentian University,
**Vaclav Rajlich
***Wayne State University
*case study
**with 12 students
***assigned to implement a simple game application
***either as pairs or as individuals
****pairs used some XP practices
*****such as
******pair programming
******test-driven
******refactoring
****individuals applied the traditional waterfall-like approach
**results
***paired students completed their tasks faster and with higher quality than individuals
***programs written by pairs pass more test cases than those developed by individuals
***Paired programmers wrote cleaner code
****with higher cohesion
*****by creating more reasonable number of methods
***Therefore, some XP practices, such as pair programming, test-driven and refactoring could be used in game development
Falta terminar essa classificação. A maioria é estudo de caso...
http://portal.acm.org/citation.cfm?id=1159733.1159788&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*publicação
**2006
***International Symposium on Empirical Software Engineering archive
****Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering table of contents
***Rio de Janeiro, Brazil
**Gerardo Canfora
***IT
**Aniello Cimitile
***IT
**Felix Garcia
***Spain
**Mario Piattini
***Spain
**Corrado Aaron Visaggio
***IT
*which are the differences between the two practices
**between
***TDD
***testing after coding (TAC)
****which is the usual approach to run and execute unit tests after having written the code.
**from the standpoint of quality and productivity
*we carried out an experiment in a Spanish Software House
**The results suggest that TDD improves the unit testing but slows down the overall process.
http://portal.acm.org/citation.cfm?id=1159733.1159787&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*publicação
**International Symposium on Empirical Software Engineering  archive
**Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering table of contents
**Rio de Janeiro, Brazil
**2006
**EUA
**Thirumalesh Bhat
***Center for Software Excellence, Redmond, WA
**Nachiappan Nagappan
***Microsoft Research, Redmond, WA
*case studies
**TDD in two different environments at Microsoft
***divisions
****Windows
****MSN
**measure the various context, product and outcome measures to compare and evaluate the efficacy of TDD
**observed a significant increase in quality of the code (greater than two times)
**15% extra upfront time for writing the tests
**the unit tests have served as auto documentation for the code
***API
***maintenance
*cap2 principios da refatoração
**de onde vem o refactoring?
***        2 primeros
****            beck
****            ward cunningham
***        Ralph Johnson
****            GOF
****            refactoring frameworks
***        Bill Opdyke
****            doc
****                investigated the refactorings that would be useful for C++ framework development and researched the necessary semantics-preserving refactorings, how to prove they were semantics preserving, and how a tool could implement these ideas
****            +cap13
***        John Brant and Don Roberts
****            refactoring browser
****            +cap14

*cap3 - mau-cheiros no código

*cap5 - um catálogo de refactorings
Pesquisas com algum fundo pedagógico
http://portal.acm.org/citation.cfm?id=949344.949421&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*pub
**2003
**Reid Kaufmann
***Sun Microsystems, Inc., Wichita, KS
**David Janzen
*Spring 2003 experiment
**examines the claims that software quality and programmer confidence
***software quality
***programmer confidence
**indicate support for these claims and inform larger future experiments
***future!

o que mediu?
*produtividade
*A snapshot of the production code was gathered 
**on three dates
***April 10
***May 6
***May 9
**from each of the groups
**Each snapshot was analyzed with all four metrics tools 
*ferramentas
**JavaNCSS [5]
**JDepend[6]
**JMetric [7]
**CCCC [8]
Keep It Simple, Stupid

relacionado ao [[YAGNI]]
/***
|''Name:''|LoadRemoteFileThroughProxy (previous LoadRemoteFileHijack)|
|''Description:''|When the TiddlyWiki file is located on the web (view over http) the content of [[SiteProxy]] tiddler is added in front of the file url. If [[SiteProxy]] does not exist "/proxy/" is added. |
|''Version:''|1.1.0|
|''Date:''|mar 17, 2007|
|''Source:''|http://tiddlywiki.bidix.info/#LoadRemoteFileHijack|
|''Author:''|BidiX (BidiX (at) bidix (dot) info)|
|''License:''|[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D ]]|
|''~CoreVersion:''|2.2.0|
***/
//{{{
version.extensions.LoadRemoteFileThroughProxy = {
 major: 1, minor: 1, revision: 0, 
 date: new Date("mar 17, 2007"), 
 source: "http://tiddlywiki.bidix.info/#LoadRemoteFileThroughProxy"};

if (!window.bidix) window.bidix = {}; // bidix namespace
if (!bidix.core) bidix.core = {};

bidix.core.loadRemoteFile = loadRemoteFile;
loadRemoteFile = function(url,callback,params)
{
 if ((document.location.toString().substr(0,4) == "http") && (url.substr(0,4) == "http")){ 
 url = store.getTiddlerText("SiteProxy", "/proxy/") + url;
 }
 return bidix.core.loadRemoteFile(url,callback,params);
}
//}}}
BemVindo

TemaDoProjeto
1 Introduction
* 1.1 Background and Problem Statement
* 1.2 Software Testability
* 1.3 Research Question(s) 
* 1.4 Objectives, Scope and Methodology 
* 1.5 Overview of Chapters

2 Philips Medical Systems
* 2.1 Organisation overview 
* 2.2 MR Software
* 2.3 Software Testing at PMS
* 2.4 Concluding Remarks 

''3 Testability Measurement
* 3.1 Structural and Behavioural Metrics
* 3.2 Data Flow Metrics
* 3.3 Concluding Remarks

4 Testability Incorporation
* 4.1 Design Testability
* 4.2 Built-in Test
* 4.3 Test Frameworks
* 4.4 Concluding Remarks
''

5 Conclusions and Future Work
* 5.1 Conclusion / Discussion
* 5.2 Future work
http://portal.acm.org/citation.cfm?id=1070618.1070834&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*o
**2005
**USA
**Hakan Erdogmus
* On the effectiveness of the test-first approach to programming <http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=1423994&isnumber=30744&punumber=32&k2dockey=1423994@ieeejrns&query=((tdd)%3Cin%3Emetadata)&pos=8&access=no>
*controlled experiment
**undergraduate students
**grupos
***experiment group applied a test-first strategy
***the control group applied a more conventional development technique
****writing tests after the implementation
**Both groups followed an incremental process
**test-first students on average wrote more tests
**found
***test-first students on average wrote more tests
***students who wrote more tests tended to be more productive
***the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed
http://portal.acm.org/citation.cfm?id=1129031.1129494&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*pub
**2006
**University of Kansas, Lawrence, KS USA
**EUA
**David S. Janzen
**Hossein Saiedian
*experiment was conducted with undergraduate students in a software engineering course
**Students in three groups
***completed semester-long programming projects
***using either
****an iterative Test-First (TDD)
****iterative Test-Last
****linear Test-Last approach
**resultados
***indicate that TDD can be an effective software design approach
****improving both
*****code-centric aspects
******such as
*******object decomposition
*******test coverage
*******external quality
*****developer-centric aspects
******including
*******productivity
*******confidence
***automated testing demonstrated benefits manual tests
***demonstrates the viability of teaching TDD with minimal effort in the context of a relatively traditional development approach
***Potential dangers with TDD are identified regarding programmer motivation and discipline
***Pedagogical implications and instructional techniques which may foster TDD adoption will also be referenced.
/***
|''Name:''|PasswordOptionPlugin|
|''Description:''|Extends TiddlyWiki options with non encrypted password option.|
|''Version:''|1.0.2|
|''Date:''|Apr 19, 2007|
|''Source:''|http://tiddlywiki.bidix.info/#PasswordOptionPlugin|
|''Author:''|BidiX (BidiX (at) bidix (dot) info)|
|''License:''|[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D ]]|
|''~CoreVersion:''|2.2.0 (Beta 5)|
***/
//{{{
version.extensions.PasswordOptionPlugin = {
	major: 1, minor: 0, revision: 2, 
	date: new Date("Apr 19, 2007"),
	source: 'http://tiddlywiki.bidix.info/#PasswordOptionPlugin',
	author: 'BidiX (BidiX (at) bidix (dot) info',
	license: '[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D]]',
	coreVersion: '2.2.0 (Beta 5)'
};

config.macros.option.passwordCheckboxLabel = "Save this password on this computer";
config.macros.option.passwordInputType = "password"; // password | text
setStylesheet(".pasOptionInput {width: 11em;}\n","passwordInputTypeStyle");

merge(config.macros.option.types, {
	'pas': {
		elementType: "input",
		valueField: "value",
		eventName: "onkeyup",
		className: "pasOptionInput",
		typeValue: config.macros.option.passwordInputType,
		create: function(place,type,opt,className,desc) {
			// password field
			config.macros.option.genericCreate(place,'pas',opt,className,desc);
			// checkbox linked with this password "save this password on this computer"
			config.macros.option.genericCreate(place,'chk','chk'+opt,className,desc);			
			// text savePasswordCheckboxLabel
			place.appendChild(document.createTextNode(config.macros.option.passwordCheckboxLabel));
		},
		onChange: config.macros.option.genericOnChange
	}
});

merge(config.optionHandlers['chk'], {
	get: function(name) {
		// is there an option linked with this chk ?
		var opt = name.substr(3);
		if (config.options[opt]) 
			saveOptionCookie(opt);
		return config.options[name] ? "true" : "false";
	}
});

merge(config.optionHandlers, {
	'pas': {
 		get: function(name) {
			if (config.options["chk"+name]) {
				return encodeCookie(config.options[name].toString());
			} else {
				return "";
			}
		},
		set: function(name,value) {config.options[name] = decodeCookie(value);}
	}
});

// need to reload options to load passwordOptions
loadOptionsCookie();

/*
if (!config.options['pasPassword'])
	config.options['pasPassword'] = '';

merge(config.optionsDesc,{
		pasPassword: "Test password"
	});
*/
//}}}
Design for Testability * 
 
Bret Pettichord 
bret@pettichord.com 
www.pettichord.com 
Copyright © Bret Pettichord, 2002. All rights reserved. 
 
To be presented at the  
Pacific Northwest Software Quality Conference, Portland, Oregon, October 2002 
----

__introduction__

* 3 keys to test automation
** relação contrutiva entre desenvolvedores e testadores
** comprometimento da equipe toda pelo sucesso da automação
** chance dos testadores se envolverem cedo no ciclo de desenvolvimento do produto
*** então vc precisa
**** cooperação
**** entender que isso afeta a todos
**** chance de trabalhar isso cedo

* testabilidade
**            visibilidade
**            controle
* distinção
**            testabilidade
***                suporte construido no próprio produto
**            automação do teste
***                suporte externo ao produto
***                scaffolding
* facilitar a cooperação provendo um catalogo de funcionalidades de testabilidade


*    visibility basics
*    verbose outputs
*    loggin events
*    diagnostic, monitoring and fault injection
*    instalation and configuration
*    test interfaces

*    ui testability
**        ui standards and compatibility
**        recognizing ui controls
**        naming window & ui controls
**        mapping custom ui controls
**        suporting custom ui controls
**        accessing internal interfaces of custom ui controls

__conclusions__
* knowing testability options
* making testability happen

__apendix: ''what is testability?'' __

*            bach/gelperin-99
**                qualquer coisa que torne mais fácil testar
***                    mais fácil desenhar os testes
***                    mais eficiente

*           bach(mesmo texto?)
**                    Control.
***                        The better we can control it, the more the testing can be automated and optimized.
**                    Visibility. 
***                        What we see is what we test.
**                    Operability.
***                        The better it works, the more efficiently it can be tested.
**                    Simplicity.
***                        The less there is to test, the more quickly we can test it.
**                    Understandability.
***                        The more information we have, the smarter we test.
**                    Suitability.
***                        The more we know about the intended use of the software, the better we can organize our testing to find important bugs.
**                    Stability.
***                        The fewer the changes, the fewer the disruptions to testing.

*            (IEEE 1990
                “the degree to which a system or component  facilitates the establishment of test criteria and the performance of tests to determine whether  those criteria have been met.”
*            (Voas & Friedman 1995)
                observabilidade
                o inverso da probabilidade de um erro permanecer não detectado após uma bateria de testes


http://portal.acm.org/citation.cfm?id=1380662.1380664&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*pub
**2008
**Nachiappan Nagappan
***Microsoft Research, Redmond, USA
**E. Michael Maximilien
***IBM Almaden Research Center, San Jose, USA
**Thirumalesh Bhat
***Microsoft Research, Redmond, USA
**Laurie Williams
***North Carolina State University, Raleigh, USA
*in an industrial context
**little empirical evidence
*Case studies
**three development teams at Microsoft and one at IBM
**results
***pre-release defect density of the four products decreased between 40% and 90%
****relative to similar projects that did not use the TDD practice
***Subjectively, the teams experienced a 15 -35% increase in initial development time after adopting TDD
****subjetivo como?
http://portal.acm.org/citation.cfm?id=1159517.1159528&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*pub
**2006
**Suécia
**Lars-Ola Damm
***Ericsson AB, Karlskrona, Sweden and School of Engineering, Blekinge Institute of Technology, Ronneby, Sweden
**Lars Lundberg
***School of Engineering, Blekinge Institute of Technology, Ronneby, Sweden
*presents empirical results from introducing a concept for early fault detection
**an alternative approach to Test-Driven Development
***applied on a component level
****instead of on a class/method level
**method for evaluating the result of introducing the concept
***based on an existing method for fault-based process assessment
***was proven practically useful for evaluating fault reducing improvements
**evaluation was made on two industrial projects 
***on different features
****within a project that only implemented the concept partly
**results
***demonstrated improvements
****decreased fault rates
****Return On Investment (ROI)
****exemplo
*****total project cost became about 5-6% less already in the first two studied projects
http://portal.acm.org/citation.cfm?id=1094855.1094954&coll=GUIDE&dl=GUIDE&CFID=4389858&CFTOKEN=67060785

*2005
*EUA
*DavidJanzen
*Initial results and the study protocol and plans will be presented.

TDL
*test driven learning
An automated testing strategy targeted for 
efficient use in the consulting domain 

Teddie Stenvi 

Master Thesis  
Software Engineering 
Thesis no: MSE-2007:18 
June 2007 

School of Engineering 
Blekinge Institute of Technology 
Box 520 
SE – 372 25 Ronneby 
Sweden 

TestDrivenDevelopment
Vou manter aqui a minha visão atual sobre o que poderia ser o tema do mestrado.

À medida em que formos discutindo, e que forem surgindo as críticas e novas idéias, esse texto aqui vai tomando forma (espero).

----

''Pretendo investigar'' a forma com que o desenvolvimento orientado a testes ([[TDD]], [[BDD]]) e as "posturas" relacionadas ([[YAGNI]], [[KISS]]) influenciam no design final do software resultante.

Como isso se relaciona com os conceitos e características de um "bom design"?

o Vários EstudosDeCaso fazem medidas de qualidade de código ([[qualidade]], [[qualidadeInterna]], [[qualidadeExterna]])  em projetos XP a cada iteração de poucas semanas. 
* Pensei em fazer medições mais curtas - a cada commit no controle de versão - e observar minuciosamente.

Uma ideia seria investigar o efeito que algumas técnicas de [[Refactoring]] poderiam ter durante o desenvolvimento.

Qual a visão atual da ciência a respeito de um "bom design" de software? Quem investigou isso? Com que enfoque?
- DaniloSatoMetricasAgeis e AgilcoopEvolutionMetricsAgileProjects usam métricas de qualidade de código
- o MuloDesignForTestability reúne métricas de testabilidade
- Vide artigos marcados como [[qualidadeInterna]], e talvez em [[qualidade]] tb...

Em que situação poderíamos investigar as práticas?
- Projetos reais;
- Projetos de disciplinas;
- CodingDojo (pode ser parte de disciplinas como 'Programação sistemática', 'Engenharia de software', POO...)
- vide as ClassificaçõesDosArtigos

''A vantagem do CodingDojo'' é que são sessões curtas e fáceis de se organizar, de modo que seria possível fazer vários pequenos experimentos testando uma boa variedade de situações diferentes... Equipes mais ou menos experientes; utilização desta ou daquela técnica especifica; problemas simples e complexos; solução começando do zero (green field) ou sessões de manutenção e evolução de código já em desenvolvimento.

Além disso, seria viável e relativamente simples executar esses experimentos com turmas de graduação e pós graduação, extensão, iniciativa comercial ou até voluntária, comunitária.
Técnica relacionada ao ExtremeProgramming que consiste em escrever o código do programa de acordo com a orientação que os testes dão.

Na prática, todo código do software é produzido por um ciclo:
- Escreve um teste;
- Escreve o código mais simples possivel para satisfazer o teste;
- Refatora o código;

* O que seria equivalente a Teste => Programação => Projeto (exatamente o contrário do que o "bom senso" manda...
* Equivale também a uma expressão do CicloPDCA, onde começa-se definindo um objetivo (o teste), depois trabalha-se para cumprir aquele objetivo (o código), e por fim avalia-se o resultado e age-se (refactoring) para melhorar o ciclo seguinte.

O código é então escrito, pedaço por pedaço, em ciclos consecutivos.
/***
Description: Contains the stuff you need to use Tiddlyspot
Note, you also need UploadPlugin, PasswordOptionPlugin and LoadRemoteFileThroughProxy
from http://tiddlywiki.bidix.info for a complete working Tiddlyspot site.
***/
//{{{

// edit this if you are migrating sites or retrofitting an existing TW
config.tiddlyspotSiteId = 'mestradobruno';

// make it so you can by default see edit controls via http
config.options.chkHttpReadOnly = false;
window.readOnly = false; // make sure of it (for tw 2.2)
window.showBackstage = true; // show backstage too

// disable autosave in d3
if (window.location.protocol != "file:")
	config.options.chkGTDLazyAutoSave = false;

// tweak shadow tiddlers to add upload button, password entry box etc
with (config.shadowTiddlers) {
	SiteUrl = 'http://'+config.tiddlyspotSiteId+'.tiddlyspot.com';
	SideBarOptions = SideBarOptions.replace(/(<<saveChanges>>)/,"$1<<tiddler TspotSidebar>>");
	OptionsPanel = OptionsPanel.replace(/^/,"<<tiddler TspotOptions>>");
	DefaultTiddlers = DefaultTiddlers.replace(/^/,"[[WelcomeToTiddlyspot]] ");
	MainMenu = MainMenu.replace(/^/,"[[WelcomeToTiddlyspot]] ");
}

// create some shadow tiddler content
merge(config.shadowTiddlers,{

'WelcomeToTiddlyspot':[
 "This document is a ~TiddlyWiki from tiddlyspot.com.  A ~TiddlyWiki is an electronic notebook that is great for managing todo lists, personal information, and all sorts of things.",
 "",
 "@@font-weight:bold;font-size:1.3em;color:#444; //What now?// &nbsp;&nbsp;@@ Before you can save any changes, you need to enter your password in the form below.  Then configure privacy and other site settings at your [[control panel|http://" + config.tiddlyspotSiteId + ".tiddlyspot.com/controlpanel]] (your control panel username is //" + config.tiddlyspotSiteId + "//).",
 "<<tiddler TspotControls>>",
 "See also GettingStarted.",
 "",
 "@@font-weight:bold;font-size:1.3em;color:#444; //Working online// &nbsp;&nbsp;@@ You can edit this ~TiddlyWiki right now, and save your changes using the \"save to web\" button in the column on the right.",
 "",
 "@@font-weight:bold;font-size:1.3em;color:#444; //Working offline// &nbsp;&nbsp;@@ A fully functioning copy of this ~TiddlyWiki can be saved onto your hard drive or USB stick.  You can make changes and save them locally without being connected to the Internet.  When you're ready to sync up again, just click \"upload\" and your ~TiddlyWiki will be saved back to tiddlyspot.com.",
 "",
 "@@font-weight:bold;font-size:1.3em;color:#444; //Help!// &nbsp;&nbsp;@@ Find out more about ~TiddlyWiki at [[TiddlyWiki.com|http://tiddlywiki.com]].  Also visit [[TiddlyWiki.org|http://tiddlywiki.org]] for documentation on learning and using ~TiddlyWiki. New users are especially welcome on the [[TiddlyWiki mailing list|http://groups.google.com/group/TiddlyWiki]], which is an excellent place to ask questions and get help.  If you have a tiddlyspot related problem email [[tiddlyspot support|mailto:support@tiddlyspot.com]].",
 "",
 "@@font-weight:bold;font-size:1.3em;color:#444; //Enjoy :)// &nbsp;&nbsp;@@ We hope you like using your tiddlyspot.com site.  Please email [[feedback@tiddlyspot.com|mailto:feedback@tiddlyspot.com]] with any comments or suggestions."
].join("\n"),

'TspotControls':[
 "| tiddlyspot password:|<<option pasUploadPassword>>|",
 "| site management:|<<upload http://" + config.tiddlyspotSiteId + ".tiddlyspot.com/store.cgi index.html . .  " + config.tiddlyspotSiteId + ">>//(requires tiddlyspot password)//<br>[[control panel|http://" + config.tiddlyspotSiteId + ".tiddlyspot.com/controlpanel]], [[download (go offline)|http://" + config.tiddlyspotSiteId + ".tiddlyspot.com/download]]|",
 "| links:|[[tiddlyspot.com|http://tiddlyspot.com/]], [[FAQs|http://faq.tiddlyspot.com/]], [[blog|http://tiddlyspot.blogspot.com/]], email [[support|mailto:support@tiddlyspot.com]] & [[feedback|mailto:feedback@tiddlyspot.com]], [[donate|http://tiddlyspot.com/?page=donate]]|"
].join("\n"),

'TspotSidebar':[
 "<<upload http://" + config.tiddlyspotSiteId + ".tiddlyspot.com/store.cgi index.html . .  " + config.tiddlyspotSiteId + ">><html><a href='http://" + config.tiddlyspotSiteId + ".tiddlyspot.com/download' class='button'>download</a></html>"
].join("\n"),

'TspotOptions':[
 "tiddlyspot password:",
 "<<option pasUploadPassword>>",
 ""
].join("\n")

});
//}}}
| !date | !user | !location | !storeUrl | !uploadDir | !toFilename | !backupdir | !origin |
| 08/01/2009 11:10:19 | BrunoPedroso | [[mestradobruno.html|file:///Users/Bruno/GTD/referencia/pro/estudo/ciencia/mestrado/projeto/artigos/mestradobruno.html]] | [[store.cgi|http://mestradobruno.tiddlyspot.com/store.cgi]] | . | [[index.html | http://mestradobruno.tiddlyspot.com/index.html]] | . | failed |
| 08/01/2009 11:10:46 | BrunoPedroso | [[mestradobruno.html|file:///Users/Bruno/GTD/referencia/pro/estudo/ciencia/mestrado/projeto/artigos/mestradobruno.html]] | [[store.cgi|http://mestradobruno.tiddlyspot.com/store.cgi]] | . | [[index.html | http://mestradobruno.tiddlyspot.com/index.html]] | . | failed |
| 08/01/2009 11:11:09 | BrunoPedroso | [[mestradobruno.html|file:///Users/Bruno/GTD/referencia/pro/estudo/ciencia/mestrado/projeto/artigos/mestradobruno.html]] | [[store.cgi|http://mestradobruno.tiddlyspot.com/store.cgi]] | . | [[index.html | http://mestradobruno.tiddlyspot.com/index.html]] | . | ok |
| 08/01/2009 11:11:23 | BrunoPedroso | [[mestradobruno.html|file:///Users/Bruno/GTD/referencia/pro/estudo/ciencia/mestrado/projeto/artigos/mestradobruno.html]] | [[store.cgi|http://mestradobruno.tiddlyspot.com/store.cgi]] | . | [[index.html | http://mestradobruno.tiddlyspot.com/index.html]] | . | ok |
| 08/01/2009 11:12:22 | BrunoPedroso | [[mestradobruno.html|file:///Users/Bruno/GTD/referencia/pro/estudo/ciencia/mestrado/projeto/artigos/mestradobruno.html]] | [[store.cgi|http://mestradobruno.tiddlyspot.com/store.cgi]] | . | [[index.html | http://mestradobruno.tiddlyspot.com/index.html]] | . | ok |
| 08/01/2009 12:34:31 | BrunoPedroso | [[mestradobruno.html|file:///Users/Bruno/GTD/referencia/pro/estudo/ciencia/mestrado/projeto/artigos/mestradobruno.html]] | [[store.cgi|http://mestradobruno.tiddlyspot.com/store.cgi]] | . | [[index.html | http://mestradobruno.tiddlyspot.com/index.html]] | . | ok |
| 08/01/2009 12:45:47 | BrunoPedroso | [[mestradobruno.html|file:///Users/Bruno/GTD/referencia/pro/estudo/ciencia/mestrado/projeto/artigos/mestradobruno.html]] | [[store.cgi|http://mestradobruno.tiddlyspot.com/store.cgi]] | . | [[index.html | http://mestradobruno.tiddlyspot.com/index.html]] | . | ok |
| 08/01/2009 12:49:50 | BrunoPedroso | [[mestradobruno.html|file:///Users/Bruno/GTD/referencia/pro/estudo/ciencia/mestrado/projeto/artigos/mestradobruno.html]] | [[store.cgi|http://mestradobruno.tiddlyspot.com/store.cgi]] | . | [[index.html | http://mestradobruno.tiddlyspot.com/index.html]] | . | ok |
| 12/01/2009 11:07:59 | BrunoPedroso | [[mestradobruno.html|file:///Users/Bruno/GTD/referencia/pro/estudo/ciencia/mestrado/projeto/mestradobruno.html]] | [[store.cgi|http://mestradobruno.tiddlyspot.com/store.cgi]] | . | [[index.html | http://mestradobruno.tiddlyspot.com/index.html]] | . | failed |
| 25/01/2009 14:51:36 | BrunoPedroso | [[mestradobruno.html|file:///Users/Bruno/GTD/referencia/pro/estudo/ciencia/mestrado/projeto/mestradobruno.html]] | [[store.cgi|http://mestradobruno.tiddlyspot.com/store.cgi]] | . | [[index.html | http://mestradobruno.tiddlyspot.com/index.html]] | . |
/***
|''Name:''|UploadPlugin|
|''Description:''|Save to web a TiddlyWiki|
|''Version:''|4.1.3|
|''Date:''|Feb 24, 2008|
|''Source:''|http://tiddlywiki.bidix.info/#UploadPlugin|
|''Documentation:''|http://tiddlywiki.bidix.info/#UploadPluginDoc|
|''Author:''|BidiX (BidiX (at) bidix (dot) info)|
|''License:''|[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D ]]|
|''~CoreVersion:''|2.2.0|
|''Requires:''|PasswordOptionPlugin|
***/
//{{{
version.extensions.UploadPlugin = {
	major: 4, minor: 1, revision: 3,
	date: new Date("Feb 24, 2008"),
	source: 'http://tiddlywiki.bidix.info/#UploadPlugin',
	author: 'BidiX (BidiX (at) bidix (dot) info',
	coreVersion: '2.2.0'
};

//
// Environment
//

if (!window.bidix) window.bidix = {}; // bidix namespace
bidix.debugMode = false;	// true to activate both in Plugin and UploadService
	
//
// Upload Macro
//

config.macros.upload = {
// default values
	defaultBackupDir: '',	//no backup
	defaultStoreScript: "store.php",
	defaultToFilename: "index.html",
	defaultUploadDir: ".",
	authenticateUser: true	// UploadService Authenticate User
};
	
config.macros.upload.label = {
	promptOption: "Save and Upload this TiddlyWiki with UploadOptions",
	promptParamMacro: "Save and Upload this TiddlyWiki in %0",
	saveLabel: "save to web", 
	saveToDisk: "save to disk",
	uploadLabel: "upload"	
};

config.macros.upload.messages = {
	noStoreUrl: "No store URL in parmeters or options",
	usernameOrPasswordMissing: "Username or password missing"
};

config.macros.upload.handler = function(place,macroName,params) {
	if (readOnly)
		return;
	var label;
	if (document.location.toString().substr(0,4) == "http") 
		label = this.label.saveLabel;
	else
		label = this.label.uploadLabel;
	var prompt;
	if (params[0]) {
		prompt = this.label.promptParamMacro.toString().format([this.destFile(params[0], 
			(params[1] ? params[1]:bidix.basename(window.location.toString())), params[3])]);
	} else {
		prompt = this.label.promptOption;
	}
	createTiddlyButton(place, label, prompt, function() {config.macros.upload.action(params);}, null, null, this.accessKey);
};

config.macros.upload.action = function(params)
{
		// for missing macro parameter set value from options
		if (!params) params = {};
		var storeUrl = params[0] ? params[0] : config.options.txtUploadStoreUrl;
		var toFilename = params[1] ? params[1] : config.options.txtUploadFilename;
		var backupDir = params[2] ? params[2] : config.options.txtUploadBackupDir;
		var uploadDir = params[3] ? params[3] : config.options.txtUploadDir;
		var username = params[4] ? params[4] : config.options.txtUploadUserName;
		var password = config.options.pasUploadPassword; // for security reason no password as macro parameter	
		// for still missing parameter set default value
		if ((!storeUrl) && (document.location.toString().substr(0,4) == "http")) 
			storeUrl = bidix.dirname(document.location.toString())+'/'+config.macros.upload.defaultStoreScript;
		if (storeUrl.substr(0,4) != "http")
			storeUrl = bidix.dirname(document.location.toString()) +'/'+ storeUrl;
		if (!toFilename)
			toFilename = bidix.basename(window.location.toString());
		if (!toFilename)
			toFilename = config.macros.upload.defaultToFilename;
		if (!uploadDir)
			uploadDir = config.macros.upload.defaultUploadDir;
		if (!backupDir)
			backupDir = config.macros.upload.defaultBackupDir;
		// report error if still missing
		if (!storeUrl) {
			alert(config.macros.upload.messages.noStoreUrl);
			clearMessage();
			return false;
		}
		if (config.macros.upload.authenticateUser && (!username || !password)) {
			alert(config.macros.upload.messages.usernameOrPasswordMissing);
			clearMessage();
			return false;
		}
		bidix.upload.uploadChanges(false,null,storeUrl, toFilename, uploadDir, backupDir, username, password); 
		return false; 
};

config.macros.upload.destFile = function(storeUrl, toFilename, uploadDir) 
{
	if (!storeUrl)
		return null;
		var dest = bidix.dirname(storeUrl);
		if (uploadDir && uploadDir != '.')
			dest = dest + '/' + uploadDir;
		dest = dest + '/' + toFilename;
	return dest;
};

//
// uploadOptions Macro
//

config.macros.uploadOptions = {
	handler: function(place,macroName,params) {
		var wizard = new Wizard();
		wizard.createWizard(place,this.wizardTitle);
		wizard.addStep(this.step1Title,this.step1Html);
		var markList = wizard.getElement("markList");
		var listWrapper = document.createElement("div");
		markList.parentNode.insertBefore(listWrapper,markList);
		wizard.setValue("listWrapper",listWrapper);
		this.refreshOptions(listWrapper,false);
		var uploadCaption;
		if (document.location.toString().substr(0,4) == "http") 
			uploadCaption = config.macros.upload.label.saveLabel;
		else
			uploadCaption = config.macros.upload.label.uploadLabel;
		
		wizard.setButtons([
				{caption: uploadCaption, tooltip: config.macros.upload.label.promptOption, 
					onClick: config.macros.upload.action},
				{caption: this.cancelButton, tooltip: this.cancelButtonPrompt, onClick: this.onCancel}
				
			]);
	},
	options: [
		"txtUploadUserName",
		"pasUploadPassword",
		"txtUploadStoreUrl",
		"txtUploadDir",
		"txtUploadFilename",
		"txtUploadBackupDir",
		"chkUploadLog",
		"txtUploadLogMaxLine"		
	],
	refreshOptions: function(listWrapper) {
		var opts = [];
		for(i=0; i<this.options.length; i++) {
			var opt = {};
			opts.push();
			opt.option = "";
			n = this.options[i];
			opt.name = n;
			opt.lowlight = !config.optionsDesc[n];
			opt.description = opt.lowlight ? this.unknownDescription : config.optionsDesc[n];
			opts.push(opt);
		}
		var listview = ListView.create(listWrapper,opts,this.listViewTemplate);
		for(n=0; n<opts.length; n++) {
			var type = opts[n].name.substr(0,3);
			var h = config.macros.option.types[type];
			if (h && h.create) {
				h.create(opts[n].colElements['option'],type,opts[n].name,opts[n].name,"no");
			}
		}
		
	},
	onCancel: function(e)
	{
		backstage.switchTab(null);
		return false;
	},
	
	wizardTitle: "Upload with options",
	step1Title: "These options are saved in cookies in your browser",
	step1Html: "<input type='hidden' name='markList'></input><br>",
	cancelButton: "Cancel",
	cancelButtonPrompt: "Cancel prompt",
	listViewTemplate: {
		columns: [
			{name: 'Description', field: 'description', title: "Description", type: 'WikiText'},
			{name: 'Option', field: 'option', title: "Option", type: 'String'},
			{name: 'Name', field: 'name', title: "Name", type: 'String'}
			],
		rowClasses: [
			{className: 'lowlight', field: 'lowlight'} 
			]}
};

//
// upload functions
//

if (!bidix.upload) bidix.upload = {};

if (!bidix.upload.messages) bidix.upload.messages = {
	//from saving
	invalidFileError: "The original file '%0' does not appear to be a valid TiddlyWiki",
	backupSaved: "Backup saved",
	backupFailed: "Failed to upload backup file",
	rssSaved: "RSS feed uploaded",
	rssFailed: "Failed to upload RSS feed file",
	emptySaved: "Empty template uploaded",
	emptyFailed: "Failed to upload empty template file",
	mainSaved: "Main TiddlyWiki file uploaded",
	mainFailed: "Failed to upload main TiddlyWiki file. Your changes have not been saved",
	//specific upload
	loadOriginalHttpPostError: "Can't get original file",
	aboutToSaveOnHttpPost: 'About to upload on %0 ...',
	storePhpNotFound: "The store script '%0' was not found."
};

bidix.upload.uploadChanges = function(onlyIfDirty,tiddlers,storeUrl,toFilename,uploadDir,backupDir,username,password)
{
	var callback = function(status,uploadParams,original,url,xhr) {
		if (!status) {
			displayMessage(bidix.upload.messages.loadOriginalHttpPostError);
			return;
		}
		if (bidix.debugMode) 
			alert(original.substr(0,500)+"\n...");
		// Locate the storeArea div's 
		var posDiv = locateStoreArea(original);
		if((posDiv[0] == -1) || (posDiv[1] == -1)) {
			alert(config.messages.invalidFileError.format([localPath]));
			return;
		}
		bidix.upload.uploadRss(uploadParams,original,posDiv);
	};
	
	if(onlyIfDirty && !store.isDirty())
		return;
	clearMessage();
	// save on localdisk ?
	if (document.location.toString().substr(0,4) == "file") {
		var path = document.location.toString();
		var localPath = getLocalPath(path);
		saveChanges();
	}
	// get original
	var uploadParams = new Array(storeUrl,toFilename,uploadDir,backupDir,username,password);
	var originalPath = document.location.toString();
	// If url is a directory : add index.html
	if (originalPath.charAt(originalPath.length-1) == "/")
		originalPath = originalPath + "index.html";
	var dest = config.macros.upload.destFile(storeUrl,toFilename,uploadDir);
	var log = new bidix.UploadLog();
	log.startUpload(storeUrl, dest, uploadDir,  backupDir);
	displayMessage(bidix.upload.messages.aboutToSaveOnHttpPost.format([dest]));
	if (bidix.debugMode) 
		alert("about to execute Http - GET on "+originalPath);
	var r = doHttp("GET",originalPath,null,null,username,password,callback,uploadParams,null);
	if (typeof r == "string")
		displayMessage(r);
	return r;
};

bidix.upload.uploadRss = function(uploadParams,original,posDiv) 
{
	var callback = function(status,params,responseText,url,xhr) {
		if(status) {
			var destfile = responseText.substring(responseText.indexOf("destfile:")+9,responseText.indexOf("\n", responseText.indexOf("destfile:")));
			displayMessage(bidix.upload.messages.rssSaved,bidix.dirname(url)+'/'+destfile);
			bidix.upload.uploadMain(params[0],params[1],params[2]);
		} else {
			displayMessage(bidix.upload.messages.rssFailed);			
		}
	};
	// do uploadRss
	if(config.options.chkGenerateAnRssFeed) {
		var rssPath = uploadParams[1].substr(0,uploadParams[1].lastIndexOf(".")) + ".xml";
		var rssUploadParams = new Array(uploadParams[0],rssPath,uploadParams[2],'',uploadParams[4],uploadParams[5]);
		var rssString = generateRss();
		// no UnicodeToUTF8 conversion needed when location is "file" !!!
		if (document.location.toString().substr(0,4) != "file")
			rssString = convertUnicodeToUTF8(rssString);	
		bidix.upload.httpUpload(rssUploadParams,rssString,callback,Array(uploadParams,original,posDiv));
	} else {
		bidix.upload.uploadMain(uploadParams,original,posDiv);
	}
};

bidix.upload.uploadMain = function(uploadParams,original,posDiv) 
{
	var callback = function(status,params,responseText,url,xhr) {
		var log = new bidix.UploadLog();
		if(status) {
			// if backupDir specified
			if ((params[3]) && (responseText.indexOf("backupfile:") > -1))  {
				var backupfile = responseText.substring(responseText.indexOf("backupfile:")+11,responseText.indexOf("\n", responseText.indexOf("backupfile:")));
				displayMessage(bidix.upload.messages.backupSaved,bidix.dirname(url)+'/'+backupfile);
			}
			var destfile = responseText.substring(responseText.indexOf("destfile:")+9,responseText.indexOf("\n", responseText.indexOf("destfile:")));
			displayMessage(bidix.upload.messages.mainSaved,bidix.dirname(url)+'/'+destfile);
			store.setDirty(false);
			log.endUpload("ok");
		} else {
			alert(bidix.upload.messages.mainFailed);
			displayMessage(bidix.upload.messages.mainFailed);
			log.endUpload("failed");			
		}
	};
	// do uploadMain
	var revised = bidix.upload.updateOriginal(original,posDiv);
	bidix.upload.httpUpload(uploadParams,revised,callback,uploadParams);
};

bidix.upload.httpUpload = function(uploadParams,data,callback,params)
{
	var localCallback = function(status,params,responseText,url,xhr) {
		url = (url.indexOf("nocache=") < 0 ? url : url.substring(0,url.indexOf("nocache=")-1));
		if (xhr.status == 404)
			alert(bidix.upload.messages.storePhpNotFound.format([url]));
		if ((bidix.debugMode) || (responseText.indexOf("Debug mode") >= 0 )) {
			alert(responseText);
			if (responseText.indexOf("Debug mode") >= 0 )
				responseText = responseText.substring(responseText.indexOf("\n\n")+2);
		} else if (responseText.charAt(0) != '0') 
			alert(responseText);
		if (responseText.charAt(0) != '0')
			status = null;
		callback(status,params,responseText,url,xhr);
	};
	// do httpUpload
	var boundary = "---------------------------"+"AaB03x";	
	var uploadFormName = "UploadPlugin";
	// compose headers data
	var sheader = "";
	sheader += "--" + boundary + "\r\nContent-disposition: form-data; name=\"";
	sheader += uploadFormName +"\"\r\n\r\n";
	sheader += "backupDir="+uploadParams[3] +
				";user=" + uploadParams[4] +
				";password=" + uploadParams[5] +
				";uploaddir=" + uploadParams[2];
	if (bidix.debugMode)
		sheader += ";debug=1";
	sheader += ";;\r\n"; 
	sheader += "\r\n" + "--" + boundary + "\r\n";
	sheader += "Content-disposition: form-data; name=\"userfile\"; filename=\""+uploadParams[1]+"\"\r\n";
	sheader += "Content-Type: text/html;charset=UTF-8" + "\r\n";
	sheader += "Content-Length: " + data.length + "\r\n\r\n";
	// compose trailer data
	var strailer = new String();
	strailer = "\r\n--" + boundary + "--\r\n";
	data = sheader + data + strailer;
	if (bidix.debugMode) alert("about to execute Http - POST on "+uploadParams[0]+"\n with \n"+data.substr(0,500)+ " ... ");
	var r = doHttp("POST",uploadParams[0],data,"multipart/form-data; ;charset=UTF-8; boundary="+boundary,uploadParams[4],uploadParams[5],localCallback,params,null);
	if (typeof r == "string")
		displayMessage(r);
	return r;
};

// same as Saving's updateOriginal but without convertUnicodeToUTF8 calls
bidix.upload.updateOriginal = function(original, posDiv)
{
	if (!posDiv)
		posDiv = locateStoreArea(original);
	if((posDiv[0] == -1) || (posDiv[1] == -1)) {
		alert(config.messages.invalidFileError.format([localPath]));
		return;
	}
	var revised = original.substr(0,posDiv[0] + startSaveArea.length) + "\n" +
				store.allTiddlersAsHtml() + "\n" +
				original.substr(posDiv[1]);
	var newSiteTitle = getPageTitle().htmlEncode();
	revised = revised.replaceChunk("<title"+">","</title"+">"," " + newSiteTitle + " ");
	revised = updateMarkupBlock(revised,"PRE-HEAD","MarkupPreHead");
	revised = updateMarkupBlock(revised,"POST-HEAD","MarkupPostHead");
	revised = updateMarkupBlock(revised,"PRE-BODY","MarkupPreBody");
	revised = updateMarkupBlock(revised,"POST-SCRIPT","MarkupPostBody");
	return revised;
};

//
// UploadLog
// 
// config.options.chkUploadLog :
//		false : no logging
//		true : logging
// config.options.txtUploadLogMaxLine :
//		-1 : no limit
//      0 :  no Log lines but UploadLog is still in place
//		n :  the last n lines are only kept
//		NaN : no limit (-1)

bidix.UploadLog = function() {
	if (!config.options.chkUploadLog) 
		return; // this.tiddler = null
	this.tiddler = store.getTiddler("UploadLog");
	if (!this.tiddler) {
		this.tiddler = new Tiddler();
		this.tiddler.title = "UploadLog";
		this.tiddler.text = "| !date | !user | !location | !storeUrl | !uploadDir | !toFilename | !backupdir | !origin |";
		this.tiddler.created = new Date();
		this.tiddler.modifier = config.options.txtUserName;
		this.tiddler.modified = new Date();
		store.addTiddler(this.tiddler);
	}
	return this;
};

bidix.UploadLog.prototype.addText = function(text) {
	if (!this.tiddler)
		return;
	// retrieve maxLine when we need it
	var maxLine = parseInt(config.options.txtUploadLogMaxLine,10);
	if (isNaN(maxLine))
		maxLine = -1;
	// add text
	if (maxLine != 0) 
		this.tiddler.text = this.tiddler.text + text;
	// Trunck to maxLine
	if (maxLine >= 0) {
		var textArray = this.tiddler.text.split('\n');
		if (textArray.length > maxLine + 1)
			textArray.splice(1,textArray.length-1-maxLine);
			this.tiddler.text = textArray.join('\n');		
	}
	// update tiddler fields
	this.tiddler.modifier = config.options.txtUserName;
	this.tiddler.modified = new Date();
	store.addTiddler(this.tiddler);
	// refresh and notifiy for immediate update
	story.refreshTiddler(this.tiddler.title);
	store.notify(this.tiddler.title, true);
};

bidix.UploadLog.prototype.startUpload = function(storeUrl, toFilename, uploadDir,  backupDir) {
	if (!this.tiddler)
		return;
	var now = new Date();
	var text = "\n| ";
	var filename = bidix.basename(document.location.toString());
	if (!filename) filename = '/';
	text += now.formatString("0DD/0MM/YYYY 0hh:0mm:0ss") +" | ";
	text += config.options.txtUserName + " | ";
	text += "[["+filename+"|"+location + "]] |";
	text += " [[" + bidix.basename(storeUrl) + "|" + storeUrl + "]] | ";
	text += uploadDir + " | ";
	text += "[[" + bidix.basename(toFilename) + " | " +toFilename + "]] | ";
	text += backupDir + " |";
	this.addText(text);
};

bidix.UploadLog.prototype.endUpload = function(status) {
	if (!this.tiddler)
		return;
	this.addText(" "+status+" |");
};

//
// Utilities
// 

bidix.checkPlugin = function(plugin, major, minor, revision) {
	var ext = version.extensions[plugin];
	if (!
		(ext  && 
			((ext.major > major) || 
			((ext.major == major) && (ext.minor > minor))  ||
			((ext.major == major) && (ext.minor == minor) && (ext.revision >= revision))))) {
			// write error in PluginManager
			if (pluginInfo)
				pluginInfo.log.push("Requires " + plugin + " " + major + "." + minor + "." + revision);
			eval(plugin); // generate an error : "Error: ReferenceError: xxxx is not defined"
	}
};

bidix.dirname = function(filePath) {
	if (!filePath) 
		return;
	var lastpos;
	if ((lastpos = filePath.lastIndexOf("/")) != -1) {
		return filePath.substring(0, lastpos);
	} else {
		return filePath.substring(0, filePath.lastIndexOf("\\"));
	}
};

bidix.basename = function(filePath) {
	if (!filePath) 
		return;
	var lastpos;
	if ((lastpos = filePath.lastIndexOf("#")) != -1) 
		filePath = filePath.substring(0, lastpos);
	if ((lastpos = filePath.lastIndexOf("/")) != -1) {
		return filePath.substring(lastpos + 1);
	} else
		return filePath.substring(filePath.lastIndexOf("\\")+1);
};

bidix.initOption = function(name,value) {
	if (!config.options[name])
		config.options[name] = value;
};

//
// Initializations
//

// require PasswordOptionPlugin 1.0.1 or better
bidix.checkPlugin("PasswordOptionPlugin", 1, 0, 1);

// styleSheet
setStylesheet('.txtUploadStoreUrl, .txtUploadBackupDir, .txtUploadDir {width: 22em;}',"uploadPluginStyles");

//optionsDesc
merge(config.optionsDesc,{
	txtUploadStoreUrl: "Url of the UploadService script (default: store.php)",
	txtUploadFilename: "Filename of the uploaded file (default: in index.html)",
	txtUploadDir: "Relative Directory where to store the file (default: . (downloadService directory))",
	txtUploadBackupDir: "Relative Directory where to backup the file. If empty no backup. (default: ''(empty))",
	txtUploadUserName: "Upload Username",
	pasUploadPassword: "Upload Password",
	chkUploadLog: "do Logging in UploadLog (default: true)",
	txtUploadLogMaxLine: "Maximum of lines in UploadLog (default: 10)"
});

// Options Initializations
bidix.initOption('txtUploadStoreUrl','');
bidix.initOption('txtUploadFilename','');
bidix.initOption('txtUploadDir','');
bidix.initOption('txtUploadBackupDir','');
bidix.initOption('txtUploadUserName','');
bidix.initOption('pasUploadPassword','');
bidix.initOption('chkUploadLog',true);
bidix.initOption('txtUploadLogMaxLine','10');


// Backstage
merge(config.tasks,{
	uploadOptions: {text: "upload", tooltip: "Change UploadOptions and Upload", content: '<<uploadOptions>>'}
});
config.backstageTasks.push("uploadOptions");


//}}}

William Wake. XP radar chart. http://www.xp123.com/xplor/xp0012b/index. 
shtml, Jan. 2001. Last Access: Jan. 2007. 
You Ain't Gonna Need It

Princípio que advoga contra a tendência humana comum de se criar mais complexidade do que o necessário, ao se projetar antecipadamente uma peça de software.

O princípio diz que devemos adotar a solução mais simples possível, que resolva estritamente o problema que temos hoje.

(É nesse mesmo sentido que o [[TDD]] afirma que só se deve escrever, a princípio, o código mais simples possível para fazer passar o teste.)

Dessa forma, ao desenvolver um sistema baseado em bancos de dados relacionais, por exemplo, só se definiriam as entidades do sistema à medida em que o projeto fosse evoluindo.

Nesse sentido, também, ao projetar um algoritmo que interpreta números romanos, começaria-se escrevendo um teste - por exemplo: "interpreta corretamente o I (um)?" - e escreveria-se apenas o código necessário para satisfazer aquele teste - "return 1" seria a solução mais simples para esse caso. 

os que usaram o problema do score do boliche
desenvolvimento de jogos
subjetiva preenchida pelos programadores
aqueles que ainda não identifiquei se é interna ou externa