Welcome to TiddlyWiki created by Jeremy Ruston; Copyright © 2004-2007 Jeremy Ruston, Copyright © 2007-2011 UnaMesa Association
<<Image "FR" "125" "250px-Mozambique_(orthographic_projection).svg.png" "http://upload.wikimedia.org/" "wikipedia/commons/thumb/8/84/Mozambique_(orthographic_projection).svg/" "" "Mozambique">>
[[Mozambique|http://en.wikipedia.org/wiki/Mozambique]] is a beautiful country with very nice people and great food.
<<Image "FL" "300" "Dao.jpg" "https://dl.dropbox.com/" "s/5ohjd1mw0c2kpa0/" "?dl=1" "Dao - Maputo">>
<<Image "FL" "300" "Fishing.jpg" "https://dl.dropbox.com/" "s/pniyd8l8emo1cm1/" "?dl=1" "Fishing - Maputo">>
[[South Africa|http://en.wikipedia.org/wiki/South_Africa]] Seems also nice but I've only had the chance to know a little of the fabulous [[Kruger Park|http://www.krugerpark.co.za/]].
<<Image "FR" "125" "250px-South_Africa_%28orthographic_projection%29.svg.png" "http://upload.wikimedia.org/" "wikipedia/commons/thumb/6/6e/South_Africa_%28orthographic_projection%29.svg/" "" "South Africa">>
This is wild life as it is meant to be. Free, happy and alive animals in all their glory.
<<Image "FL" "300" "Gazele.jpg" "https://dl.dropbox.com/" "s/8b5ntg4y5f8b3ga/" "?dl=1" "Gazele - Kruger Park">> <<Image "FR" "125" "kruger-nav-map_r10_c1_s1.gif" "http://www.krugerpark.co.za/" "images/" "" "Kruger Park">>
----
@@color:#c4d6ed; ^^
Description: Two great weeks in Mozambique and South Africa
^^@@
!One life, live it
<<Image "FR" "125" "Morocco_%28orthographic_projection%2C_WS_claimed%29.svg
" "http://upload.wikimedia.org/" "wikipedia/commons/7/78/" "" "Morroco">>
[[Morroco|http://en.wikipedia.org/wiki/Morroco]] very nice people and great place for off-road.
<<Image "FL" "480" "2018-Morroco-01.JPG" "https://dl.dropbox.com/" "s/drn0tjuoffvb7y2/" "?dl=1" "Camping">>
<<Image "FR" "480" "2018-Morroco-02.JPG" "https://dl.dropbox.com/" "s/wiu45pqmu282pa0/" "?dl=1" "">>
<<Image "FL" "480" "2018-Morroco-03.JPG" "https://dl.dropbox.com/" "s/k7n73nfz113qi20/" "?dl=1" "">>
<<Image "FR" "480" "2018-Morroco-04.JPG" "https://dl.dropbox.com/" "s/ud1lpgyxxpwoljz/" "?dl=1" "">>
<<Image "FL" "480" "2018-Morroco-05.JPG" "https://dl.dropbox.com/" "s/n1zdpypavdlxfnd/" "?dl=1" "">>
<<Image "FR" "480" "2018-Morroco-06.JPG" "https://dl.dropbox.com/" "s/ejgov6ladjdbxgc/" "?dl=1" "400000Km, enough to reach the Moon...it's a Land Rover.">>
----
/%
@@color:#c4d6ed; ^^
Description: Morroco April 2018 photos ^^@@
%/
Application Programming Interface
The interface that an application, module or sub-system exposes to be used from its outside.
----
@@color:#c4d6ed; ^^
Description: Application Programming Interface
^^@@
Performance doesn't seem to be a fashionable theme anymore. It is, however, one of the major Customer satisfaction problems we face in projects and it is, for sure, an essential step towards excelence.
Don't be naive, performance will not "just happen". You will have to design for it, experiment and take every opportunity to optimize.
__To address performance you first have to be able to measure it!__
This is a small tool to allow for quick assessement of .Net code relative performance.
* [[ASPerfBench-1.0.02.13.zip|https://www.dropbox.com/s/sgxvuv9pbejkpr9/ASPerfBench-1.0.02.13.zip?dl=1]]
<<Image "" "456" "ASPerfBench01.png" "https://dl.dropbox.com/" "s/smrackn9v91f1ff/" "?dl=1" "">>
<<Image "" "456" "ASPerfBench02.png" "https://dl.dropbox.com/" "s/k1v2tilye8i5bh0/" "?dl=1" "">>
----
//One point of confusion regarding abstraction is its use as both a process and an entity. Abstraction, as a process, denotes the extracting of the essential details about an item, or a group of items, while ignoring the inessential details. Abstraction, as an entity, denotes a model, a view, or some other focused representation for an actual item. Abstraction is most often used as a complexity mastering technique. For example, we often hear people say such things as: "just give me the highlights" or "just the facts, please." What these people are asking for are abstractions.//
Edward V. Berard - Abstraction, Encapsulation and Information Hiding [[[Berard]|BibliographyPage##Berard]]
Abstractions are an essential tool for effective communication as they can condense in a single concept a fairly complex system or sub-system. In a properly structured model they are also the entry points from where the reader can drill-down to the details.
Abstraction gears towards comprehension
[[Encapsulation]] gears towards protection from outside interference
[[Information Hiding]] gears towards containment of design changes
----
@@color:#c4d6ed; ^^
Description: Abstraction concept and references.
^^@@
|SiteIcon SiteTitle SiteSubtitle||||StyleSheet|
|MainMenu|SiteUrl||PageTemplate|StyleSheetColors|
|~|DefaultTiddlers||EditTemplate|StyleSheetLayout|
|~|~||ViewTemplate|StyleSheetPrint|
|~|~|OptionsPanel||ColorPalette|
|~|~|AdvancedOptions|||
|~|~|SideBarTabs|||
|~|~|SideBarOptions|||
|HtmlJavascript|||||
|SystemSettings|||TiddlyHost||
|~|~|~|ThostUploadPlugin||
* Save local [[backup|https://acarvalho.tiddlyhost.com/download]]
* Comment moderation : [[Disqus|https://acarvalho-tiddlyspace.disqus.com/admin/moderate/#/pending]]
<<paletteView [[ColorPalette]]>>
* GettingStarted
* [[TiddlyHost|https://tiddlyhost.com]]
* OLD : [[TiddlySpot tweeks|TiddlySpotTweeks]]
* OLD : [[TiddlySpace Documentation|http://docs.tiddlyspace.com/]]
----
!Installed plugins
* TagCloudPlugin : present a 'cloud' of tags (or links) using proportional font display
* ImageSizePlugin : adds support for resizing images
* SectionLinksPlugin : allow tiddler sections in TiddlyLinks to be used as anchor points
* FullScreenPlugin : Toggle between viewing tiddlers fullscreen and normally. Very handy for when you need more viewing space.
* HoverMenuPlugin : Provides a hovering menu on the edge of the screen for commonly used commands, that scrolls with the page. Configured at HoverMenu .
* InlineJavascriptPlugin : Insert Javascript executable code directly into your tiddler content. With more information at InlineJavascriptPluginInfo .
* GotoPlugin : view any tiddler by entering it's title - displays list of possible matches.
* GATrackerPlugin : Google Analytics tracker
* TiddlerToCPlugin : Tiddler Table of Contents generator
* BreadcrumbsPlugin : list/jump to tiddlers viewed during this session plus "back" button/macro. With more information at BreadcrumbsPluginInfo
* QuotePlugin : Create a direct link to a tiddler using a normal button and a button that expands the specified tiddler inside the current tiddler.
* TiddlersBarPluginMP : A bar to switch between tiddlers through tabs (like browser tabs bar).
** StyleSheetTiddlersBar
** DisplayOptions
* SinglePageModePlugin - Show tiddlers one at a time with automatic permalink, or always open tiddlers at top/bottom of page.
** SinglePageModePluginInfo
* [[E.A.S.E]] - this framework allows you to easily create commands that work on the current tiddler text selection in edit mode.
** [[easyFormat]] - the format command format selection according to your choice.
** [[easyInsert]] - insert text template at caret position.
* [[TiddlyTagMindMap2Plugin]] - Create mind-maps from tags
** [[jit-yc]]
** [[MapNodeTemplate]]
** [[MindMapContent]]
* [[DisqusTiddlyWikiExtension]] - from the [[disqus space|http://disqus.tiddlyspace.com/#DisqusTiddlyWikiExtension]] - Enable comments on TiddlyWiki in your TiddlySpace with htmljs and this.
** [[HtmlJavascript]] - Add {{{/bags/common/tiddlers/jquery.js
http://htmljs.tiddlyspace.com/htmljs-disqus}}}
** [[ViewTemplate]] - Add {{{<div macro="disqus"></div>}}}
!Installed Macros
* BibRefMacro - A TiddlyWiki Macro to create links to anchors in a bibliography tiddler.
* ImageMacro - A TiddlyWiki Macro to create configurable links to images.
* ContentTimelineMacro - A TiddlyWiki Macro to show timelines (modified, created) for tiddlers tagged 'Content'
* PaletteViewMacro - Displays color palettes.
* UnsavedChangesPlugin - show droplist of tiddlers that have changed since the last time the document was saved.
!Installed Tweaks
* CoreTweaks - generic tweaks
** DefaultTiddlerText - Configure default new tiddler text
* HTML serialization - produces bag, receip
** HtmlJavascript - Call external javascript code on serializing
!!~TiddlyWiki tools
* [[tiddlypocketbook|http://tiddlypocketbook.tiddlyspace.com/#]] - A guide to ~TiddlyWiki syntax
* [[TiddlyVault|http://tiddlyvault.tiddlyspot.com/]] - An index of ~TiddlyWiki extensions
* [[Tiddly Tools|http://www.tiddlytools.com]]
* [[abegoExtensions|http://tiddlywiki.abego-software.de]] - UdoBorkowski's Extensions for TiddlyWiki
* [[Martin's wiki|http://www.martinswiki.com/]] - Martin Budden's plugins and extensions for TiddlyWiki
----
@@color:#c4d6ed; ^^
Description: Administration functionality for this wiki.
^^@@
''You do not became an Agile Developer just by not doing things! You became an Agile Developer by (through study, experience and reasoning) being able to define and [[tailor|Tailoring]] processes and methods to achieve the goals with the minimum effort possible.''
Agility in software development was a good trend to clarify over engineering and too formal and rather useless practices that were being blindly imported from high maturity and criticality scenarios to other situations were they were little more than an useless overhead. Worst, as many of the practitioners did not knew how to perform those practices, they slowly degenerated in "pretend-to-be" activities that consumed resources without producing anything useful.
//''"A programmer who refuses to design is a person who refuses to think."''//
''Practices of an Agile Developer'' by Venkat Subramaniam and Andy Hunt, pag. 153 <<BibRef "Venkat 2006">>
Unfortunately, many times today, agility is used as an excuse for ignorance, immaturity and irresponsibility. Oddly, I became aware that some universities use agile methodologies to teach Software Engineering to people that does not know anything about Object Oriented Principles or software modelling or structured analysis, and that think they, alone by themselves, can "infer" all the Software Engineering knowledge ever produced just by knowing the syntax of a programming language and how to use Google. This will only produce, as we say in Portuguese, "meat for the cannons", low value programmers with very serious handicaps for evolving, but cheap and easy to replace...
Think of a would be painter that wants to start his learning by abstract art, it does not make much sense does it?
Beware of agility without solid knowledge and experience as it will be, most of the times, simplistic. Also start by considering that ''if you do not have an agile specification and an agile architecture you will, for sure, not have an agile development but just a sloppy one''.
This being said, agile methodologies are a great contribution to Software Engineering. To know more about them you may want to start with the [[Manifesto for Agile Software Development|http://agilemanifesto.org/]] and then probably head for [[Martin Fowler|http://martinfowler.com/intro.html]]'s [[Agile Software Development|http://martinfowler.com/agile.html]].
----
/%
@@color:#c4d6ed; ^^
Description: Agile Methodologies concept, discussion and references.
^^@@
%/
!Android
This page is the start point for Android OS subjects in this site.
!! Best Android software
|Area|Name|Description|Type|h
|App store|F-Droid||Free|
|Firewall|[[NetGuard|http://www.netguard.me/]]|~NetGuard provides a simple way to block access to the internet - no root required. Applications can individually be allowed or denied access to your ~WiFi and/or mobile connection.||
|~|[[AFWall+|https://github.com/ukanth/afwall]]|Android Firewall+ is an advanced iptables editor (GUI) for Android. It provides fine-grained control over which Android apps are allowed to access the network.|Free/Open-source|
|Sound|[[Neutron|http://www.neutronmp.com/]]|The best, by far, sound player for Android||
----
/%
@@color:#c4d6ed; ^^
Description: main page for Android OS matters
^^@@
%/
<<Image "FR" "350" "archetype-rca.png" "https://www.dropbox.com/s/" "syn2rlge5xb1hls/" "?dl=1" "Rich Client Application MS archetype">>
//"This section of the guide contains a series of topics that will help you to understand the capabilities, features, benefits, and liabilities of each of the common application types that you may decide to create. The first topic contains an overview of the basic application types such as Web, mobile, rich client, services, and RIA. "//
In [[Application Archetypes|http://msdn.microsoft.com/en-us/library/ee658107.aspx]]
Microsoft Application Architecture Guide 2.0 <<BibRef "AppArch 2.0">>
The application archetype is an essential step towards a proper [[Modularization]] of your system that, in turn, will be crucial for [[Encapsulation]] and [[Coupling]] and [[Cohesion]] control.
----
@@color:#c4d6ed; ^^
Description: Application Archetype concept and references.
^^@@
On the [[Knowledge Management|KnowledgeManagement]] domain we consider ''availability'' the degree to which information and knowledge in an organization are accessible and accessed when someone needs them.
----
See also [[Knowledge Management|KnowledgeManagement]]
----
/%
@@color:#c4d6ed; ^^
Description: Availability concept on Knowledge Management
^^@@
%/
/***
|Name|BibRefMacro|
|Created by|Andre' de Carvalho|
|Location|http://acarvalho.tiddlyspace.com/#BibRefMacro|
|Version|1.0.0|
|Type|Macro|
|Description|A TiddlyWiki Macro to create links to anchors in a bibliography tiddler.|
!!Example
{{{<<BibRef "Parnas 1972">>}}}
<<BibRef "Parnas 1972">>
or
{{{<<BibRef Berard>>}}}
<<BibRef Berard>>
!!Installation
Import (or copy/paste) this tiddler into your document and tag it with "systemConfig". Change the wikify path to suit your bibliography page and anchor style ( I use SectionLinksPlugin ).
!!Code
***/
//{{{
version.extensions.BibRef= {major: 1, minor: 0 , revision: 0, date: new Date(2012,6,17)};
//Created by André de Carvalho
//}}}
//{{{
config.macros.BibRef = {};
config.macros.BibRef.handler= function(place,macroName,params) {
var bref=params[0];
wikify("[[["+bref+"]|BibliographyPage##"+bref+"]]",place)
};
//}}}
|Area|Author|Title|Year|Abstract/Ref.|Archive|h
|Architecture|D.L. Parnas|<html><a name="Parnas 1972" /></html>[[On the Criteria To Be Used in Decomposing Systems Into Modules|https://web.archive.org/web/20180108050207/http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf]]|1972|This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decompositions are discussed. The unconventional decomposition, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.|
|~|~|~|~|{{{<<BibRef "Parnas 1972">>}}}|
|~|J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat|<html><a name="AppArch 2.0" /></html>[[Microsoft Application Architecture Guide 2.0 |http://apparchguide.codeplex.com/]]|2008|This guide provides design-level guidance for the architecture and design of applications built on the .NET Framework. It focuses on the most common types of applications, partitioning application functionality into layers, components, and services, and walks through their key design characteristics. This guide is a collaborative effort between patterns & practices, product teams, and industry experts.|
|~|~|~|~|{{{<<BibRef "AppArch 2.0">>}}}|
|Coding|Steven C. ~McConnell|<html><a name="McConnell 2004" /></html>[[Code Complete 2nd Ed.|http://www.cc2e.com/Default.aspx]]|2004|Widely considered one of the best practical guides to programming, Steve ~McConnell’s original CODE COMPLETE has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices—and hundreds of new code samples—illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, ~McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking—and help you build the highest quality code.|
|~|~|~|~|{{{<<BibRef "McConnell 2004">>}}}|
|~|Venkat Subramaniam and Andy Hunt|<html><a name="Venkat 2006" /></html>[[Practices of an Agile Developer|http://pragprog.com/book/pad/practices-of-an-agile-developer]]|2006|Want to be a better developer? This book collects the personal habits, ideas, and approaches of successful agile software developers and presents them in a series of short, easy-to-digest tips. You’ll learn how to improve your software development process, see what real agile practices feel like, avoid the common temptations that kill projects, and keep agile practices in balance.|
|~|~|~|~|{{{<<BibRef "Venkat 2006">>}}}|
|Concepts|Edward V. Berard|<html><a name="Berard" /></html>[[Abstraction, Encapsulation and Information Hiding|http://www.tonymarston.co.uk/php-mysql/abstraction.txt]]||The fundamental reference on these concepts|[[Archive|https://web.archive.org/web/20161121160856/http://www.tonymarston.co.uk/php-mysql/abstraction.txt]]|
|~|~|~|~|{{{<<BibRef Berard>>}}}||
|~|~|<html><a name="Berard 1996" /></html>[[Be Careful With "Use Cases"|https://www.cs.unc.edu/~stotts/COMP204/usecases/careful.html]]|1996|Use Cases and Software Engineering|[[Archive|https://web.archive.org/web/20210929110545/https://www.cs.unc.edu/~stotts/COMP204/usecases/careful.html]]|
|~|~|~|~|{{{<<BibRef "Berard 1996">>}}}|
|~|[[Frederick P. Brooks, Jr.|https://en.wikipedia.org/wiki/Fred_Brooks]]|<html><a name="Brooks 1986" /></html>[[No Silver Bullet—Essence and accident in software engineering|https://web.archive.org/web/20190712082507/http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf]]|1986|A foundational article on Software Engineering and its inherent complexity|
|~|~|~|~|{{{<<BibRef "Brooks 1986">>}}}|
|~|Mike Mannion and Barry Keepence|<html><a name="Mannion,Keepence 1995" /></html>[[SMART requirements|http://www.win.tue.nl/~wstomv/edu/2ip30/references/smart-requirements.pdf]]|1995|Systems Analysis, or as it is increasingly known as today, Requirements Engineering, is a time consuming, expensive but critical phase in software (and system) development. The "perfect" Requirements Specification should exhibit a number of qualities including correctness, completeness and consistency. Within a Requirements Specification individual requirements at the microscopic level should be justified, clear, unambiguous and verifiable. However, in many cases Systems Analysts or Requirements Engineers describe requirements which fall short of these demands. In addition, outside reviewers faced with presenting an independent qualitative assessment of a Requirements Specification have few guidelines to assist them. In this paper we present a simple technique, borrowed from objective setting in Management Psychology, to assist the construction and evaluation of individual requirements.|
|~|~|~|~|{{{<<BibRef "Mannion,Keepence 1995">>}}}|
|Processes|[[International Institute of Business Analysis (IIBA)|http://www.iiba.org]]|<html><a name="BABOK 2008" /></html>[[A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) v.2 draft|http://www.iiba.org/imis15/IIBA/Professional_Development/Business_Analysis_Body_of_Knowledge/IIBA_Website/Professional_Development/Business_Analysis_Body_of_Knowledge_pages/Business_Analysis_Body_of_Knowledge.aspx]]|2008|A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) is the collection of knowledge within the profession of business analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the business analysis professionals who apply it in their daily work role.|
|~|~|~|~|{{{<<BibRef "BABOK 2008">>}}}|
|Systems Engineering|Alexander Kossiakoff, et al.|<html><a name="Kossiakoff 2011" /></html>Systems engineering principles and practice 2ed.|2011|Learning how to be a successful systems engineer is entirely different from learning how to excel at a traditional engineering discipline. It requires developing the ability to think in a special way, to acquire the “ systems engineering viewpoint, ” and to make the central objective the system as a whole and the success of its mission. The systems engineer faces three directions: the system user ’ s needs and concerns, the project manager’ s financial and schedule constraints, and the capabilities and ambitions of the engineering specialists who have to develop and build the elements of the system.|
|~|~|~|~|{{{<<BibRef "Kossiakoff 2011">>}}}|
|~|~|~|~||
----
@@color:#c4d6ed; ^^
Description: Bibliographical references for all articles.
^^@@
"//Fundamental to any science or engineering discipline is a common vocabulary for expressing its concepts, and a language for relating them together. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions.//"
Brad Appleton on [[The Hillside Group|http://hillside.net/patterns/]]
----
/%
@@color:#c4d6ed; ^^
Description: Brad Appleton on patterns and communication
^^@@
%/
/***
|Name|BreadcrumbsPlugin|
|Author|Eric Shulman|
|Source|http://www.TiddlyTools.com/#BreadcrumbsPlugin|
|Documentation|http://www.TiddlyTools.com/#BreadcrumbsPluginInfo|
|Version|2.1.5|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|plugin|
|Description|list/jump to tiddlers viewed during this session plus "back" button/macro|
This plugin provides a list of links to all tiddlers opened during the session, creating a "trail of breadcrumbs" from one tiddler to the next, allowing you to quickly navigate to any previously viewed tiddler, or select 'home' to reset the display to the initial set of tiddlers that were open at the start of the session (i.e., when the document was loaded into the browser).
!!!!!Documentation
<<<
see [[BreadcrumbsPluginInfo]]
<<<
!!!!!Configuration
<<<
<<option chkCreateDefaultBreadcrumbs>> automatically create breadcrumbs display (if needed)
<<option chkShowBreadcrumbs>> show/hide breadcrumbs display
<<option chkReorderBreadcrumbs>> re-order breadcrumbs when visiting a previously viewed tiddler
<<option chkBreadcrumbsHideHomeLink>> omit 'Home' link from breadcrumbs display
<<option chkBreadcrumbsSave>> prompt to save breadcrumbs when 'Home' link is pressed
<<option chkShowStartupBreadcrumbs>> show breadcrumbs for 'startup' tiddlers
<<option chkBreadcrumbsReverse>> show breadcrumbs in reverse order (most recent first)
<<option chkBreadcrumbsLimit>> limit breadcrumbs display to {{twochar{<<option txtBreadcrumbsLimit>>}}} items
<<option chkBreadcrumbsLimitOpenTiddlers>> limit open tiddlers to {{twochar{<<option txtBreadcrumbsLimitOpenTiddlers>>}}} items
<<<
!!!!!Revisions
<<<
2012.06.10 2.1.5 refactored default options to eliminate global variable and use init() handling
| Please see [[BreadcrumbsPluginInfo]] for previous revision details |
2006.02.01 1.0.0 initial release
<<<
!!!!!Code
***/
//{{{
version.extensions.BreadcrumbsPlugin = { major: 2, minor: 1, revision: 5, date: new Date(2012,6,10) };
config.macros.breadcrumbs = {
crumbs: [], // the list of current breadcrumbs
askMsg: "Save current breadcrumbs before clearing?\n"
+"Press OK to save, or CANCEL to continue without saving.",
saveMsg: 'Enter the name of a tiddler in which to save the current breadcrumbs',
saveTitle: 'SavedBreadcrumbs',
options: {
chkShowBreadcrumbs: true,
chkReorderBreadcrumbs: true,
chkCreateDefaultBreadcrumbs: true,
chkShowStartupBreadcrumbs: false,
chkBreadcrumbsReverse: false,
chkBreadcrumbsLimit: false,
txtBreadcrumbsLimit: 5,
chkBreadcrumbsLimitOpenTiddlers:false,
txtBreadcrumbsLimitOpenTiddlers:5,
chkBreadcrumbsHideHomeLink: false,
chkBreadcrumbsSave: false,
txtBreadcrumbsHomeSeparator: ' | ',
txtBreadcrumbsCrumbSeparator: ' > '
},
init: function() {
merge(config.options,this.options,true);
},
handler: function(place,macroName,params,wikifier,paramString,tiddler) {
var area=createTiddlyElement(place,"span",null,"breadCrumbs",null);
area.setAttribute("homeSep",params[0]||config.options.txtBreadcrumbsHomeSeparator);
area.setAttribute("crumbSep",params[1]||config.options.txtBreadcrumbsCrumbSeparator);
this.render(area);
},
add: function (title) {
var thisCrumb = title;
var ind = this.crumbs.indexOf(thisCrumb);
if(ind === -1)
this.crumbs.push(thisCrumb);
else if (config.options.chkReorderBreadcrumbs)
this.crumbs.push(this.crumbs.splice(ind,1)[0]); // reorder crumbs
else
this.crumbs=this.crumbs.slice(0,ind+1); // trim crumbs
if (config.options.chkBreadcrumbsLimitOpenTiddlers)
this.limitOpenTiddlers();
this.refresh();
return false;
},
getAreas: function() {
var crumbAreas=[];
// find all DIVs with classname=="breadCrumbs"
var all=document.getElementsByTagName("*");
for (var i=0; i<all.length; i++)
try{ if (hasClass(all[i],"breadCrumbs")) crumbAreas.push(all[i]); } catch(e) {;}
// or, find single DIV w/fixed ID (backward compatibility)
var byID=document.getElementById("breadCrumbs")
if (byID && !hasClass(byID,"breadCrumbs")) crumbAreas.push(byID);
if (!crumbAreas.length && config.options.chkCreateDefaultBreadcrumbs) {
// no crumbs display... create one
var defaultArea = createTiddlyElement(null,"span",null,"breadCrumbs",null);
defaultArea.style.display= "none";
var targetArea= document.getElementById("tiddlerDisplay");
targetArea.parentNode.insertBefore(defaultArea,targetArea);
crumbAreas.push(defaultArea);
}
return crumbAreas;
},
refresh: function() {
var crumbAreas=this.getAreas();
for (var i=0; i<crumbAreas.length; i++) {
crumbAreas[i].style.display = config.options.chkShowBreadcrumbs?"inline":"none";
removeChildren(crumbAreas[i]);
this.render(crumbAreas[i]);
}
},
render: function(here) {
var co=config.options; var out=""
if (!co.chkBreadcrumbsHideHomeLink) {
createTiddlyButton(here,"Home",null,this.home,"tiddlyLink tiddlyLinkExisting");
out+=here.getAttribute("homeSep")||config.options.txtBreadcrumbsHomeSeparator;
}
for (c=0; c<this.crumbs.length; c++) // remove non-existing tiddlers from crumbs
if (!store.tiddlerExists(this.crumbs[c]) && !store.isShadowTiddler(this.crumbs[c]))
this.crumbs.splice(c,1);
var count=this.crumbs.length;
if (co.chkBreadcrumbsLimit && co.txtBreadcrumbsLimit<count) count=co.txtBreadcrumbsLimit;
var list=[];
for (c=this.crumbs.length-count; c<this.crumbs.length; c++) list.push('[['+this.crumbs[c]+']]');
if (co.chkBreadcrumbsReverse) list.reverse();
out+=list.join(here.getAttribute("crumbSep")||config.options.txtBreadcrumbsCrumbSeparator);
wikify(out,here);
},
home: function() {
var cmb=config.macros.breadcrumbs;
if (config.options.chkBreadcrumbsSave && confirm(cmb.askMsg)) cmb.saveCrumbs();
story.closeAllTiddlers(); restart();
cmb.crumbs = []; var crumbAreas=cmb.getAreas();
for (var i=0; i<crumbAreas.length; i++) crumbAreas[i].style.display = "none";
return false;
},
saveCrumbs: function() {
var tid=prompt(this.saveMsg,this.saveTitle); if (!tid||!tid.length) return; // cancelled by user
var t=store.getTiddler(tid);
if(t && !confirm(config.messages.overwriteWarning.format([tid]))) return;
var who=config.options.txtUserName;
var when=new Date();
var text='[['+this.crumbs.join(']]\n[[')+']]';
var tags=t?t.tags:[]; tags.pushUnique('story');
var fields=t?t.fields:{};
store.saveTiddler(tid,tid,text,who,when,tags,fields);
story.displayTiddler(null,tid);
story.refreshTiddler(tid,null,true);
displayMessage(tid+' has been '+(t?'updated':'created'));
},
limitOpenTiddlers: function() {
var limit=config.options.txtBreadcrumbsLimitOpenTiddlers; if (limit<1) limit=1;
for (c=this.crumbs.length-1; c>=0; c--) {
var tid=this.crumbs[c];
var elem=story.getTiddler(tid);
if (elem) { // tiddler is displayed
if (limit <=0) { // display limit has been reached
if (elem.getAttribute("dirty")=="true") { // tiddler is being edited
var msg= "'"+tid+"' is currently being edited.\n\n"
+"Press OK to save and close this tiddler\n"
+"or press Cancel to leave it opened";
if (confirm(msg)) {
story.saveTiddler(tid);
story.closeTiddler(tid);
}
}
else story.closeTiddler(this.crumbs[c]);
}
limit--;
}
}
}
};
//}}}
// // PreviousTiddler ('back') command and macro
//{{{
config.commands.previousTiddler = {
text: 'back',
tooltip: 'view the previous tiddler',
handler: function(event,src,title) {
var crumbs=config.macros.breadcrumbs.crumbs;
if (crumbs.length<2) config.macros.breadcrumbs.home();
else story.displayTiddler(story.findContainingTiddler(src),crumbs[crumbs.length-2]);
return false;
}
};
config.macros.previousTiddler= {
label: 'back',
prompt: 'view the previous tiddler',
handler: function(place,macroName,params,wikifier,paramString,tiddler) {
var label=params.shift(); if (!label) label=this.label;
var prompt=params.shift(); if (!prompt) prompt=this.prompt;
createTiddlyButton(place,label,prompt,function(ev){
return config.commands.previousTiddler.handler(ev,this)
});
}
}
//}}}
// // HIJACKS
//{{{
// update crumbs when a tiddler is displayed
if (Story.prototype.breadCrumbs_coreDisplayTiddler==undefined)
Story.prototype.breadCrumbs_coreDisplayTiddler=Story.prototype.displayTiddler;
Story.prototype.displayTiddler = function(srcElement,tiddler) {
var title=(tiddler instanceof Tiddler)?tiddler.title:tiddler;
this.breadCrumbs_coreDisplayTiddler.apply(this,arguments);
if (!startingUp || config.options.chkShowStartupBreadcrumbs)
config.macros.breadcrumbs.add(title);
}
// update crumbs when a tiddler is deleted
if (TiddlyWiki.prototype.breadCrumbs_coreRemoveTiddler==undefined)
TiddlyWiki.prototype.breadCrumbs_coreRemoveTiddler=TiddlyWiki.prototype.removeTiddler;
TiddlyWiki.prototype.removeTiddler= function() {
this.breadCrumbs_coreRemoveTiddler.apply(this,arguments);
config.macros.breadcrumbs.refresh();
}
//}}}
/***
|Name|BreadcrumbsPluginInfo|
|Author|Eric Shulman|
|Source|http://www.TiddlyTools.com/#BreadcrumbsPlugin|
|Documentation|http://www.TiddlyTools.com/#BreadcrumbsPluginInfo|
|Version|2.1.5|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|documentation|
|Description|Documentation for BreadcrumbsPlugin|
This plugin provides a list of links to all tiddlers opened during the session, creating a "trail of breadcrumbs" from one tiddler to the next, allowing you to quickly navigate to any previously viewed tiddler, or select 'home' to reset the display to the initial set of tiddlers that were open at the start of the session (i.e., when the document was loaded into the browser).
!!!!!Usage
<<<
{{{
<<breadcrumbs homeSeparator crumbSeparator>>
}}}
By default, the breadcrumbs are displayed as a continuous, //horizontal// word-wrapped line of text, using default character sequences for ''homeSeparator'' (" | ") and ''crumbSeparator'' (" > "). The //optional// ''homeSeparator'' and ''crumbSeparator'' macro parameters allow you to specify alternative separators. For example, to display the breadcrumbs //vertically// (in a stack, rather than a row), set the separator values to use {{{[[<br>]]}}}... and, to display a horizontal line as the home separator, use {{{[[<html><hr></html>]]}}}.
{{{
<<previousTiddler>>
}}}
This macro embeds a 'back' button in your content. Clicking the button opens/scrolls to the most recent previously viewed tiddler. You can also add the {{{previousTiddler}}} keyword to the ~ViewToolbar slice definition in ToolbarCommands. This adds a 'back' button directly to the toolbar of each tiddler that is displayed.
<<<
!!!!!Examples:
<<<
{{{
<<breadcrumbs>>
}}}
<<breadcrumbs>>
{{{
<<breadcrumbs [[<html><hr></html>]] [[<br>]]>>
}}}
<<breadcrumbs [[<html><hr></html>]] [[<br>]]>>
<<<
!!!!!Customization
<<<
Using CSS and a few of the plugin configuration options (see below), you can make the breadcrumbs display resemble browser tabs by adding the following to your [[StyleSheet]]:
{{{
.breadCrumbs { border-bottom:1px solid; }
.breadCrumbs a {
border: 1px solid; padding: 0px 1em;
-moz-border-radius-topleft:.5em; -moz-border-radius-topright:.5em;
-webkit-border-top-left-radius:.5em; -webkit-border-top-right-radius:.5em;
}
}}}
and this in [[ConfigTweaks]] (tagged with systemConfig, of course):
{{{
config.options.chkShowStartupBreadcrumbs=true;
config.options.chkBreadcrumbsLimitOpenTiddlers=true;
config.options.txtBreadcrumbsLimitOpenTiddlers=1;
config.macros.breadcrumbs.homeSeparator=" ";
config.macros.breadcrumbs.crumbSeparator=" ";
}}}
<<<
!!!!!Configuration
<<<
__''display placement:''__
<<option chkCreateDefaultBreadcrumbs>> automatically create breadcrumbs display (if needed)
{{{<<option chkCreateDefaultBreadcrumbs>>}}}
>By default, the plugin automatically creates the "breadCrumbs" display element at the top of the story column, just above the tiddlerDisplay area. To manually control the display and placement of the breadcrumbs display, you can define a DIV with class="breadCrumbs" in a custom [[PageTemplate]] or embed the {{{<<breadcrumbs>>}}} macro in specific tiddler content.
>
>For example, to add the breadcrumbs below the mainMenu, change this:
{{{
<div id='mainMenu' refresh='content' tiddler='MainMenu'></div>
}}}
>to:
{{{
<div id='mainMenu'>
<div refresh='content' tiddler='MainMenu'></div>
<div id='breadCrumbs' class='breadCrumbs'></div>
</div>
}}}
>You can also block automatic creation of the breadcrumbs display by setting
{{{
config.options.chkCreateDefaultBreadcrumbs=false;
}}}
>in a [[CookieJar]]/[[ConfigTweaks]] plugin tiddler.
__''other settings:''__
<<option chkShowBreadcrumbs>> show/hide breadcrumbs display
{{{<<option chkShowBreadcrumbs>>}}}
>This checkbox toggles the visibility of the breadcrumbs display. However, the display is not updated until the next crumb is added (or a previous crumb is clicked on). For immediate effect, you can use [[ToggleBreadcrumbs]] to synchronize the checkbox setting and the breadcrumbs display.
<<option chkReorderBreadcrumbs>> re-order breadcrumbs when visiting a previously viewed tiddler
{{{<<option chkReorderBreadcrumbs>>}}}
>When visiting a previously viewed tiddler, the title of the most-recently displayed tiddler is simply moved to the end of the list and individual breadcrumbs are not removed from the list unless the underlying tiddler is deleted. When ''re-ordering'' is disabled, the breadcrumbs list is ''trimmed'' so that all crumbs following that tiddler are removed from the list.
<<option chkBreadcrumbsHideHomeLink>> omit 'Home' link from breadcrumbs display
{{{<<option chkBreadcrumbsHideHomeLink>>}}}
>Enabling this option suppresses the automatic display of the "Home" link (and home separator). To manually add the home link elsewhere in your document, use the following HTML:
{{{
<html><a href="javascript:;" onclick="config.macros.breadcrumbs.home()">home</a></html>
}}}
<<option chkBreadcrumbsSave>> prompt to save breadcrumbs when 'Home' link is pressed
{{{<<option chkBreadcrumbsSave>>}}}
>Whenever you press the 'home' button, you can be prompted to save the current breadcrumbs in a tiddler as a space-separated list of tiddler links (default title="SavedBreadcrumbs").
<<option chkShowStartupBreadcrumbs>> show breadcrumbs for 'startup' tiddlers
{{{<<option chkShowStartupBreadcrumbs>>}}}
>Breadcrumbs are usually only added for tiddlers that are opened after the document has been loaded, and not for tiddlers displayed during initial startup (e.g., [[DefaultTiddlers]]). Enabling this option displays breadcrumbs for all viewed tiddlers, regardless of when they are opened.
<<option chkBreadcrumbsReverse>> show breadcrumbs in reverse order
{{{<<option chkBreadcrumbsReverse>>}}}
>As tiddlers are displayed, breadcrumbs are usually added to the //end// of the list. Enabling this option displays breadcrumbs in reverse order, so that the most recently visited tiddlers are listed first.
<<option chkBreadcrumbsLimit>> limit breadcrumbs display to {{twochar{<<option txtBreadcrumbsLimit>>}}} items
{{{<<option chkBreadcrumbsLimit>>}}} and {{{<<option txtBreadcrumbsLimit>>}}}
>By default, breadcrumbs are displayed for all tiddlers that have been visited (unless the list is being 'trimmed' by disabling the chkReorderBreadcrumbs option above). Enabling this option limits the display of the list to a maximum specified number of breadcrumbs.
<<option chkBreadcrumbsLimitOpenTiddlers>> limit open tiddlers to {{twochar{<<option txtBreadcrumbsLimitOpenTiddlers>>}}} items
{{{<<option chkBreadcrumbsLimitOpenTiddlers>>}}} and {{{<<option txtBreadcrumbsLimitOpenTiddlers>>}}}
>By default, tiddlers remain open (e.g., displayed in the story column) until you explicitly close them. When this option is enabled, only the most recently opened tiddlers will remain open: ''any tiddlers in excess of the specified limit are automatically closed.'' //Note: for 'data safety', if a tiddler is being edited, you will be asked for permission to "save-and-close" that tiddler or leave it open (even if that would exceed the specified limit).//
<<<
!!!!!Revisions
<<<
2012.06.10 2.1.5 refactored default options to eliminate global variable and use init() handling
2011.02.16 2.1.4 in refresh(), use 'inline' instead of 'block' style (avoids unwanted linebreak). In previousTiddler(), allow handling even if not in a tiddler so that back button can be placed in ~MainMenu or ~SidebarOptions.
2010.11.30 2.1.3 use story.getTiddler()
2009.10.19 2.1.2 code reduction
2009.03.22 2.1.0 added 'save breadcrumbs to tiddler' feature
2008.05.01 2.0.0 added 'limit open tiddlers' feature (with safety check for tiddler in edit mode)
2008.04.06 1.9.1 corrected 'limit' logic so that //last// N crumbs are shown instead of //first// N crumbs. Also, added chkBreadcrumbsHideHomeLink
2008.04.04 1.9.0 added chkBreadcrumbsReverse and chk/txtBreadcrumbsLimit
2008.03.29 1.8.4 in displayTiddler(), get title from tiddler object (if needed). Fixes errors caused when calling function passes a tiddler *object* instead of a tiddler *title*
2008.03.24 1.8.3 include shadow tiddlers in breadcrumbs list. Also changed settings so that "reordering" breadcrumbs is the default, instead of "trimming" the list
2007.12.04 [*.*.*] update for TW2.3.0: replaced deprecated core functions, regexps, and macros
2007.10.26 1.8.2 documentation cleanup
2007.10.18 1.8.1 in GetAreas(), use try/catch to avoid "Bad NPObject as private data" fatal error caused when embedded QuickTime player element is accessed by hasClass() function.
2007.10.02 1.8.0 major documentation and code cleanup. Moved config.breadCrumbs.* to config.macros.breadcrumbs.* to consolidate objects. Also, fixed homeSeparator and crumbSeparator default handling.
2007.10.02 1.7.0 added config.options.chkShowStartupBreadcrumbs option
2007.09.16 1.6.1 in getAreas(), removed errant use of 'place' (was causing fatal error when creating default breadcrumbs display element). Also, added chkCreateDefaultBreadcrumbs configuration setting to enable/disable automatic creation of a default breadcrumbs display.
2007.09.16 1.6.0 re-wrote refresh() to enable multiple display instances, by finding elements with "breadCrumbs" classname. Fallback to fixed ID (="breadCrumbs") is still used for backward-compatibility. move rendering code from refresh() to separate render() function, and added definition for {{{<<breadCrumbs>>}}} macro to support embedding breadcrumbs displays in tiddler content.
2007.09.15 [1.5.9.1] updated documentation
2007.09.15 1.5.9 defined homeSeparator (" | ") and crumbSeparator (" > ") as object properties so that they can be redefined as desired for different layouts (e.g., using 'newline' for the crumbSeparator will arrange crumbs in a column rather than a row.
2007.06.21 [1.5.8.1] in home(), return false to prevent IE from attempting to navigate away...
2007.05.26 1.5.8 added support for {{{<<option chkReorderBreadcrumbs>>}}} to toggle trim vs. re-order behavior when visiting previously viewed tiddlers
2007.05.25 1.5.7 added support for {{{<<option chkShowBreadcrumbs>>}}} to toggle //display// of breadcrumbs
2007.05.24 1.5.6 in refresh(), remove non-existing tiddler titles from crumb list. Also, hijack removeTiddler() so crumbs can be updated after tiddler is deleted.
2007.04.11 1.5.5 added optional params to previousTiddler macro handler() to allow alternative label and tooltip text (instead of default "back")
2007.03.02 1.5.4 in refresh(), for TW2.2, look for "storyDisplay" instead of "tiddlerDisplay" but keep fallback to "tiddlerDisplay" for TW2.1 or earlier
2007.02.24 1.5.3 changed from hijack of onClickTiddlerLink to hijack of displayTiddler() so that ALL displayed tiddlers are recorded in the crumbs, including programmatically displayed tiddlers opened by macros, scripts, etc., (such as [[GotoPlugin]], among many others) in addition to those opened by clicks on links.
2007.02.24 [1.5.2.0] eliminated global space clutter by moving function and data declarations so they are contained inside config.breadCrumbs object.
2007.02.06 1.5.1 added "previousTiddler" macro (for use in sidebar)
2007.02.05 1.5.0 added "previousTiddler" toolbar command (aka, "back")
2006.08.04 [1.4.0.1] change spaces to tabs
2006.08.04 1.4.0 modified from 1.4.0 distro: in refresh(), set {{{display:none/block}}} instead of {{{visibility:hidden/visible}}}. In home(), check for valid crumbArea before setting style.
2006.08.02 1.4.0 Fixed bug, the redefined onClickTiddlerLink_orig_breadCrumbs works incorrectly on IE
2006.07.20 1.3.0 Runs compatibly with TW 2.1.0 (rev #403+)
2006.02.07 1.2.0 change global array breadCrumbs to config.breadCrumbs by Eric's suggestion
2006.02.04 1.1.0 JSLint checked
2006.02.01 1.0.0 initial release
<<<
"//''Adding manpower to a late software project makes it later.''//"
[[The mythical man-month - essays on software engineering, 1975|https://is.muni.cz/www/jirqa/The.Mythical.Man.Month.F.Brooks.pdf]] ([[on WayBack Machine|https://web.archive.org/web/*/https://is.muni.cz/www/jirqa/The.Mythical.Man.Month.F.Brooks.pdf]])
[[Frederick P. Brooks|http://en.wikipedia.org/wiki/Fred_Brooks]]
page 25
----
/%
@@color:#c4d6ed; ^^
Description: Quote of Frederick P. Brooks Brook's Law
^^@@
%/
!First things first
// __''@@color(red):If you do not know or understand the problem how can you expect to give it a solution?@@''__//
From the perspective of a software development company, the initial phase of a software project is the ''Inception'' and comprises Pre-sales, Request for Proposal (or Statement of Work) Analysis and Technical Proposal Production.
<<Image "FR" "" "RUP-Inception.PNG" "https://dl.dropbox.com/" "s/diywxcpbvpp0f3d/" "?dl=1" "This is the RUP vision of the Development Process.">>
One important aspect to notice is that many high maturity software development companies do not include the Inception phase on their Software Development Processes ( [[SDP]] ) but start them at Software Requirements Specification. This might be explained by the fact that such [[SDP]]s were developed taking into consideration very formal and mature scenarios, like aero-space, where this phase is fully performed by the Customer and to an high maturity level. The problem is that, in "less critical" scenarios, this crucial phase is detached from the development process and its results may not be the best to properly feed it. In these scenarios you risk to engage in a "garbage in, garbage out" spiral if proper measures are not taken.
We are not "process and formalism fanatics", and are aware of agility needs on nowadays development, but experience has taught us that "//''you may build a bad solution over a good specification but you will never build a good solution over a bad specification''//". To engage in a legally bounding contract, like the Proposal, that is ambiguous, superficial, incomplete and poorly estimated is, at least, childish and is, for sure, to ask for trouble.
The role of business and software analyst is more and more important nowadays to the success of any software project. This as been acknowledged by top thinkers in the domain from quite some time now.
<<quote 'Frederick P. Brooks on analysis relevance' 'Frederick P. Brooks on analysis relevance'>>
<<quote 'Tom DeMarco on the Software Analyst role' 'Tom DeMarco on the Software Analyst role'>>
!!Pre-sales
''Pre-sales'' is a very important step in a project and encompasses all the initial steps of a (would be) software project. Identification of the business needs is initiated at this stage, see <<BibRef "BABOK 2008">> //Chapter 4: Enterprise Analysis//.
At this stage a lot of information is produced and vision starts to be established. This is, typically, a Customer internal phase, but, often, involves some participation of the software development partners. The important note here is that software development personnel involved preserve information and do not "close doors" by jumping to superficial restrictive solutions before more detailed information is gathered and organized. These "initial" solutions often, artificially (because they do not correspond to Customer needs nor they are solid technical choices), create technical and architectural "requirements" that may impair the pursue of the "best possible" software solution later.
The paradigmatic example is "//it must be a web browser application//" when an automated deployment, n-tier [[ClickOnce|http://msdn.microsoft.com/en-us/library/t71a733d%28v=vs.100%29.aspx]] application would do the job much better for the Customer.
!!Request for Proposal Analysis
Imagine a "not so good scenario".
Pre-sales information will be, mostly, "talk", maybe a ~PowerPoint if you are lucky. [[RFP]], if you have one, will have lots of requirements but they will not be [[SMART|SMART Requirements]] and will be spread all along a one hundred pages document.
As with any other problem analysis you should consider [[Rene Descartes' |http://www.marxists.org/reference/archive/descartes/1635/discourse-method.htm]] second principle "//''The second, to divide each of the difficulties under examination into as many parts as possible, and as might be necessary for its adequate solution.''//" and not forget the fourth "//''And the last, in every case to make enumerations so complete, and reviews so general, that I might be assured that nothing was omitted.''//"
You need tools! You need to break down, normalize, make specific, structure and [[trace|Traceability]] __ALL__ the Customer requirements. You also need to understand the business needs and the goals of the requested solution. You need to identify the data flows and the integration environment and to understand the business processes. You need tools, a check list and method, that's what will make you [[agile|Agile Methodologies]] and no, the proper tool is not MS Word nor even MS Excel.
<<Image "FR" "" "RFP-Analysis-Structure.PNG" "https://dl.dropbox.com/" "s/dwefsm068yfz2w0/" "?dl=1" "RFP Analysis Structure">>
[[RFP]]s came in a variety of formats and structures, your first consideration shall be how to make the information [[traceable|Traceability]] and not redundant. How? Using a relational database, you are talking about Software Engineering aren't you? The first task is, then, to input all the information in a software tool with a known structure that works as a completeness check list, a normalization structure and a road map for analysis. [[Sparx Enterprise Architect]] is a very good tool. But don't forget "''known structure''", that is, you will not take the full potential if you do not have a known, tested and proved structure template.
The image on the right gives an idea of what that structure can be in [[EA|Sparx Enterprise Architect]].
Details about it can be seen at [[RFP Analysis Guidelines]].
Notice that this is a fall-back approach, that is, what you can not get from RFP you must produce on Technical Proposal, what you can't produce on Technical Proposal you will have to do on Requirements Specification and so on. The later you do it the greater the risk...
!!Technical Proposal Production
<<Image "FR" "" "Technical-Proposal-Structure.PNG" "https://dl.dropbox.com/" "s/1ao4mpykaidyynt/" "?dl=1" "Technical Proposal Structure">>
If you structured and normalized the Customer request you have gain a lot of insight on his needs and goals. Also very important you have established the basis for a true [[traceability|Traceability]]. You will see this is essential to keep focus and [[scope|Scope]] and to assure [[coverage|Coverage]].
Now it is time to propose him a solution that is solid, competitive and adequate.
Again you shall use a known structure if you want to take all the tool potential.
The image on the right gives an idea of what that structure can be in [[EA|Sparx Enterprise Architect]].
Details about it can be seen at [[Technical Proposal Production Guidelines]].
----
See also [[Development Links|Development Links##BusinessAnalysis]]
Back to [[Software Development Pattern]]
----
Computer Aided Software Engineering
[[Wikipedia|http://en.wikipedia.org/wiki/Computer-aided_software_engineering]]
----
See also : [[CASE tools]]
----
@@color:#c4d6ed; ^^
Description: Computer Aided Software Engineering
^^@@
Developing professional software needs tools, [[CASE]] software tools, but beware, a tool is just as good as the usage you make of it. Software development challenges are not solved by tools but tools may be useful in implementing the solutions you define for those challenges. The bottom line here is that you must have a method and then choose tools to help implementing it not the opposite.
!!Concurrent Version Management
* [[CVS]] - This is the first area any professional software development must address. CVS and WinCVS are still my choice.
!!Modelling
*[[Sparx Enterprise Architect]] - is my primary tool and I try to make it the //[[Single Version of the Truth|https://en.wikipedia.org/wiki/Single_version_of_the_truth]]// in my specifications.
!!Prototyping
* [[Pencil]] - is an excellent [[GUI]] prototyping tool.
!!Information gathering
* Microsoft OneNote - is a tool I'm learning to like. It is quite useful for note-taking in meetings and interviews. It is also nice to be able to share it through DropBox.
----
/%
@@color:#c4d6ed; ^^
Description: A list of essential CASE software tools.
^^@@
%/
Continuous Integration
See [[Continuous Integration]]
----
/%
@@color:#c4d6ed; ^^
Description: Continuous Integration
^^@@
%/
Configuration Management
See : [[Configuration Management]]
----
/%
@@color:#c4d6ed; ^^
Description: Configuration Management
^^@@
%/
Concurrent Versioning System
See : [[Concurrent Versioning System]]
----
@@color:#c4d6ed; ^^
Description: Concurrent Versioning System.
^^@@
"//I was to learn later in life that, perhaps because we are so good at organising, we tend as a nation to meet any new situation by reorganising; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency and demoralization.//"
[[Charlton Ogburn|http://en.wikipedia.org/wiki/Charlton_Ogburn,_Jr.]] (1911-1998)
----
/%
@@color:#c4d6ed; ^^
Description: Charlton Ogburn quote on reorganising
^^@@
%/
Strong cohesion and loose [[coupling|Coupling]] are a good thing in software design.
Functional cohesion (see <<BibRef "McConnell 2004">>) be it at routine, class or module level plays an essential role in reusability, maintainability and testability. If a module does a dozen different things, chances are that, in a different scenario, one of them is not done the way you need and, in that case, you will not reuse the entire module.
Cohesion is some times relegated in favour of automatizaton, that is, you extend your module responsibilities because that way you can provide more automatism to the programmers using the module. The trade-offs shall be carefully considered and segregation measures taken. See [[Namespace Code Placement Guidelines]].
TODO: check reference
"//the functional relatedness of the elements of a module//"
Structured Analysis and System Specification, Tom DeMarco, Yourdon Press Computing Series, 1979
The Practical Guide to Structured Systems Design, 2d. ed., Meilir Page-Jones, Yourdon Press Computing Series, 1988
Modern :
"//The Single Responsibility Principle
A class should have only one reason to change.//"
Agile Principles, Patterns, and Practices in C#
By Martin C. Robert, Martin Micah
----
See also : [[Application Archetype]] [[Modularization]] [[Coupling]]
@@color:#c4d6ed; ^^
Description: Cohesion concept explanation and references.
^^@@
/*{{{*/
Background: #dce8f8
Foreground: #061222
PrimaryPale: #fafcfe
PrimaryLight: #c4d6ed
PrimaryMid: #4878b6
PrimaryDark: #014
SecondaryPale: #fefdfa
SecondaryLight: #ede3c4
SecondaryMid: #b69c48
SecondaryDark: #53514a
TertiaryPale: #fefbfa
TertiaryLight: #edd3c4
TertiaryMid: #b67048
TertiaryDark: #534d4a
Error: #f88
ColorPaletteParameters: HSL([214|12], [0.67|0.53|0.43|0.06],[0.31|0.5|0.85|0.99])
/*}}}*/
|Concepts|Acronyms|h
|<<list filter [tag[Concept]]>>|<<list filter [tag[Acronym]]>>|
----
@@color:#c4d6ed; ^^
Description: A glossary of concepts and acronyms.
^^@@
Concurrent Versioning System methods and tools play a fundamental role in [[Configuration Management]] and may be decisive in your efforts to achieve [[Systematic Reuse]]. In fact, choosing the wrong method may be one of the major [[Reuse Obstacles]].
No professional software development may be carried on without a Concurrent Versioning System (CVS) and CVS is a major part of Configuration Management.
A CVS is a centralized repository (software and hardware) that holds the digital artefacts used and produced during development (source code, documents, designs, etc.). In this perspective it may be seen as a filesystem.
The ''Versioning'' part, however, introduces a new requirement that most filesystems do not provide : version management, that is, the preservation and identification of the several versions that changes to an artefact produce along its lifecycle and also the versioning of a sub-system or the system as a whole in order to present a coherent set of its artefacts in a given moment. This introduces us to __tag__ and __revision__ concepts.
Formal and mature processes require unequivocal identification of all work products and even if that level of formality is not required you should be aware of the risks of not doing so.
The ''Concurrent'' part introduces the needs of team development in concurrent access to the artefacts and points us to __reserved editing or lock__, __branch__, __compare__ and __merge__ functionalities.
The concurrent part of [[CVS]] is very important and you have two approaches to deal with it:
* push the problem forward and deal with conflicts after they are created
* prevent conflicts as much as possible by coordinating and communicating effectively among your team
The first approach is unavoidable when you are in an open source project with a wide and probably uncontrollable team. It implies some wasted effort but is necessary as you are in a reactive model.
The second approach implies a defined team and planning and management but is much more efficient and controllable.
As seen there are several methodological approaches to use such a system. They are determined, mainly, by the exploration environment intended. An open source, widely participated and with loose governance project shall not be dealt with in the same manner as a professional team development project, also, a professional project, in a [[Systematic Reuse]] environment, presents challenges and needs that are not the same as the ones of a pure "project oriented" project.
Many people will say that you can do everything you need with any modern [[CVS]] system. Maybe that's true, but some systems are more suitable for some scenarios and, here (at professional team development), suitability means efficiency, time and money. Choosing the right methodological approach for concurrent versioning for your scenario means that you will save a lot in unnecessary effort, avoid shortcuts, hacks or "//solutions//" that impair your Company's strategic goals, like [[Systematic Reuse]], and also prevent frustration in your team. Version management shall not add effort to your projects, it shall reduce it. See also [[Reuse oriented CVS]].
In my opinion, nowadays, many people is choosing the wrong approaches and tools for [[CVS]] just because the more recent major products in the area emerged from wide open-source environments and, naturally, target those environments primarily, although they "//can also be used//" in professional, team based, environments. The older ones, team and project oriented, are so old (CVS launched in 1990, [[CVSNT|http://www.march-hare.com/cvsnt/]] in 1998) that they might even not have bugs any more… but also they are not so glamorous any more...
The first thing to take into account is that, in professional development, not all versioned artefacts are code, some projects may even not have code artefacts at all. You should also consider that, even in code files, not all environments are equal and in many mergeability is not assured or easy (think of [[IDE]] auto generated files or visual forms editors for instance). This puts aside all methodologies based on the assumed automatic mergeability of versioned artefacts. Modern project's artefacts are code, generated code, [[CASE]] tool's files, documents, binaries, images and anything else you can think of.
A professional team [[CVS]] shall :
# Be ''fully understandable'' by every team member. [[CVS]] is a major, constantly used, tool, if your team members are not proficient with it that will cause expensive, and some times irreparable, errors. Choose the simplest tool that fulfills your requirements.
# Allow ''reserved edit'' working mode. Not so much to forbid concurrent editing, but to notify us that someone else is editing the artefact __before__ we do change it. Merges are, many times, impossible and, most of the times, difficult.
# Allow ''checkout read-only'' files to prevent environments, like MS Visual Studio, from inadvertently change files without the user knowledge. This produces merge nightmares.
# Be ''file oriented''. Although project and repository oriented functionality is needed (and covered by tag/branch mechanisms), a file oriented view and management is essential in a team professional scenario. Hierarchical filesystem is, still, the best structuring and managing approach. Projects are different and with different artefacts and needs but, in digital form, their common denominator is always a filesystem.
# Use a ''sequential, predictable, revision identifier per file''. This is very important if you want, for instance, that your documents refer their [[CVS]] revision on their content (and yes, this is quite useful, and mandatory on most mature [[Configuration Management]] processes).
# Have a ''tag system'' that can work in a single branch or across branches. This is essential to promote [[Systematic Reuse]] with real code sharing and collaborative improvement. Tags must be overwrite able in order to allow to update a tag in a single file to another revision of that file. This is very important for the process agility in controlled environments. Imagine a test release with a simple, self-contained show stopper bug, do you want to repeat the entire release process? Imagine a self-contained correction or improvement ([[Refactoring|Refactor]]) in a reused module, do you want to make all dependent projects to perform merges or revalidation of your entire reuse framework? Of course in high formality environments projects shall depend on tags under their exclusive control even in shared modules.
# Have ''branching capability'' and also the ability to transform a tag into a branch. This is important for reuse in order to allow projects to start by reusing "as-is" and then, when needed and if needed, to adapt to the project's needs.
# Allow ''artefact renaming and moving'' as it is also an important feature. [[Refactoring|Refactor]], [[Continuous Improvement]] and [[Emergent Reuse]] are enough to ask for it.
# Have a ''stand-alone client'' is essential, as said, you are not working with code only, nor the project's context is the [[IDE]] context only.
# Have a clear and complete ''graphical display'' of a file's history (revisions, tags, branches and merges on the repository). You cannot manage any really reused code effectively without it.
# Provide the ability to mix ''different repository folders'' under a common development folder and to perform seamless hierarchical, recursive operations like tagging, commit, etc.
# Handle ''[[Sticky tags|http://cvsnt.org/manual2/html/Sticky-tags.html]]''. They are essential to work with reusable shared modules.
# Provide a full ''command line'' control. Essential for efficient scripting and [[Continuous Integration]]
# Provide hierarchical ''by folder permissions''. They are a must in any professional environment.
# Respect ''repository file date-time'' on checkout and update to local filesystem. It's unbelievable that some versioning systems change the files timestamp on the local filesystem (SVN or GIT for instance). It is just plain stupid and confusing : a file timestamp is the most valuable information you have in your filesystem for version management.
# Be properly ''supported in all operating systems used'' in your development environment. Have you tried to use Git on Windows? With its pity excuse of a command line? In professional development the "also works on" tools are never a good choice.
See also [[Reuse oriented CVS]] and [[Promoting Reuse by Reference]] to better understand some of these requirements. A proper, professional and mature [[CVS]] is an essential tool to support and promote reuse and to make your version management truly agile. Poor choices here are to be paid in full for many time.
----
Back to [[Configuration Management]] [[High Maturity Practices]]
----
/%
@@color:#c4d6ed; ^^
Description: Concurrent Versioning Systems discussion
^^@@
%/
Configuration Management is a broad and important topic in [[Software Development]]
"//Configuration management ([[CM]]) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional and physical attributes with its requirements, design and operational information throughout its life.//"
[[Wikipedia|https://en.wikipedia.org/wiki/Configuration_management]]
Managing a Software Project is complex. The information volume is huge and the only constant is change. Large teams, lots of actors and stakeholders, long time-frames and complex business scenarios demand strong planning and accurate and reliable information sources. One can not afford to not know exactly what was agreed and what was delivered. One can not, also, afford to loose the [[traceability|Traceability]] that shall sustain and help to understand each and every decision made.
This is the challenge of Configuration Management and it can only be conquered with method, discipline and proper tools and practice.
#[[Concurrent Versioning System]] is, probably, your first concern in regard to [[CM]].
## [[Reuse oriented CVS]] is a major factor to promote [[Systematic Reuse]]
#[[Digital Artefact Identification]] is essential for accuracy and reliability of the information. In a software project we have, at least, two kinds of identifiable artefacts:
## Filesystem artefacts - are the ones that are identified by their placement in the filesystem together with their [[CVS]] revision. This is the case, for instance, of source code files.
## Numbered artefacts - are the ones that posses and exhibit an unique identifier. They shall also have their [[CVS]] revision as explicit content (note that these artefacts may exist as physical and not only digital form). This is the case, for instance, of specification documents.
----
/%
@@color:#c4d6ed; ^^
Description: Configuration Management topics, discussions and guidelines.
^^@@
%/
/***
|Name|ContentTimelineMacro|
|Created by|Andre' de Carvalho|
|Date|12/04/2013|
|Location|http://acarvalho.tiddlyspace.com/#ContentTimelineMacro|
|Version|1.0.1|
|Type|Macro|
|Description|A TiddlyWiki Macro to show timelines (modified, created) for tiddlers tagged 'Content'|
!!Code
***/
{{{
version.extensions.ContentTimeline= {major: 1, minor: 0 , revision: 1, date: new Date(2013,4,12)};
}}}
{{{
config.macros.ContentTimeline={};
config.macros.ContentTimeline.dateFormat=config.macros.timeline.dateFormat;
config.macros.ContentTimeline.handler = function(place,macroName,params)
{
var field = params[0] ? params[0] : "modified";
var tiddlers = store.reverseLookup("tags","excludeLists",false,field);
var lastDay = "";
//var last = params[1] ? tiddlers.length-Math.min(tiddlers.length,parseInt(params[1])) : 0;
var count = params[1];
for(var t=tiddlers.length-1; t>=0; t--)
{
var tiddler = tiddlers[t];
if (!tiddler.isTagged("Content")) continue;
count=count-1;
if (count < 0)
{
break;
}
var theDay = tiddler[field].convertToLocalYYYYMMDDHHMM().substr(0,8);
if(theDay != lastDay)
{
var theDateList = document.createElement("ul");
place.appendChild(theDateList);
createTiddlyElement(theDateList,"li",null,"listTitle",tiddler[field].formatString(this.dateFormat));
lastDay = theDay;
}
var theDateListItem = createTiddlyElement(theDateList,"li",null,"listLink");
theDateListItem.appendChild(createTiddlyLink(place,tiddler.title,true));
}
};
}}}
On the [[Knowledge Management|KnowledgeManagement]] domain we consider ''continuity'' the degree to which information and knowledge in an organization are persisted and do not fade and disappear over time.
----
See also [[Knowledge Management|KnowledgeManagement]]
----
/%
@@color:#c4d6ed; ^^
Description: Continuity concept on Knowledge Management
^^@@
%/
----
@@color:#c4d6ed; ^^
Description: Continuous Improvement concept explanation and discussion.
^^@@
On the [[Knowledge Management|KnowledgeManagement]] domain we consider ''Continuous Improvement'' the degree to which knowledge and information in the system is able to be, and effectively is, continuously reviewed, refined, expanded and updated.
----
See also [[Knowledge Management|KnowledgeManagement]]
----
/%
@@color:#c4d6ed; ^^
Description: Continuous Improvement concept on Knowledge Management
^^@@
%/
“//Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.//”
[[Martin Fowler - Continuous Integration|http://martinfowler.com/articles/continuousIntegration.html]]
Continuous Integration ([[CI]]) is a major factor in team work and can prevent “snowball” integration errors and is also a major factor in preventing “broken” builds that affect everybody's work on a team. It is also used to integrate and automate other practices like [[Static Analysis]] or [[Unit Testing]].
Continuous Integration is one of the [[High Maturity Practices]] in [[Software Development]].
----
@@color:#c4d6ed; ^^
Description: Continuous Integration concept and references
^^@@
''//"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."//''
Melvin E. Conway, [[How Do Committees Invent?|http://www.melconway.com/Home/Committees_Paper.html]], 1968
//"Although sometimes construed as humorous, Conway's law was intended as a valid sociological observation. It is based on the reasoning that in order for two separate software modules to interface correctly, the designers and implementers of each module must communicate with each other. Therefore, the interface structure of a software system will reflect the social structure of the organization(s) that produced it."//
[[Wikipedia|http://en.wikipedia.org/wiki/Conway%27s_Law]]
----
/%
@@color:#c4d6ed; ^^
Description: About organization's communication.
^^@@
%/
/***
http://trac.tiddlywiki.org/ticket/637 - CLOSED: WON'T FIX
This tweak modifies the tooltip format that appears when you mouseover a link to a tiddler. It adds an option to control the date format, as well as displaying the size of the tiddler (in bytes)
Tiddler link tooltip format:
{{stretch{<<option txtTiddlerLinkTootip>>}}}
^^where: %0=title, %1=username, %2=modification date, %3=size in bytes, %4=description slice, %5=first N characters of tiddler content^^
Tiddler link tooltip date format:
{{stretch{<<option txtTiddlerLinkTooltipDate>>}}}
Tiddler excerpt limit (chars):
{{stretch{<<option txtTiddlerLinkTooltipLimit>>}}}
***/
config.messages.tiddlerLinkTooltip='%4';
config.messages.tiddlerLinkTooltipDate='DDD, MMM DDth YYYY 0hh12:0mm AM';
config.messages.tiddlerLinkTooltipLimit=50;
config.options.txtTiddlerLinkTootip=
config.options.txtTiddlerLinkTootip||config.messages.tiddlerLinkTooltip;
config.options.txtTiddlerLinkTooltipDate=
config.options.txtTiddlerLinkTooltipDate||config.messages.tiddlerLinkTooltipDate;
config.options.txtTiddlerLinkTooltipLimit=
config.options.txtTiddlerLinkTooltipLimit||config.messages.tiddlerLinkTooltipLimit;
Tiddler.prototype.getSubtitle = function() {
var modifier = this.modifier;
if(!modifier) modifier = config.messages.subtitleUnknown;
var modified = this.modified;
if(modified) modified = modified.formatString(config.options.txtTiddlerLinkTooltipDate);
else modified = config.messages.subtitleUnknown;
var descr=store.getTiddlerSlice(this.title,'Description')||'';
var txt=this.text.substr(0,config.options.txtTiddlerLinkTooltipLimit);
if (this.text.length>config.options.txtTiddlerLinkTooltipLimit) txt+="...";
return config.options.txtTiddlerLinkTootip.format([this.title,modifier,modified,this.text.length,descr,txt]);
};
/***
Set default text for new tiddlers
***/
config.views.wikified.defaultText=store.getTiddlerText("DefaultTiddlerText");
config.views.editor.defaultText=store.getTiddlerText("DefaultTiddlerText");
Strong [[cohesion|Cohesion]] and loose coupling are a good thing in software design.
Coupling (or dependency) control is one of the most important tasks in a large, complex and evolving system. It also has even more importance in an n-tier system.
See [[Namespace and Filesystem Guidelines]], [[Namespace Coupling Guidelines]] and [[Namespace Code Placement Guidelines]] as the first measure to fight //spaghetti coupling//.
See also [[OOP principles|ObjectOrientedProgramming]] for guidelines on packaging and change impact contention.
Improper coupling is a [[major obstacle to reusability|Reuse Obstacles]], maintainability and testability
----
See also : [[Application Archetype]] [[Modularization]] [[Cohesion]]
@@color:#c4d6ed; ^^
Description: Coupling concept explanation.
^^@@
When working on software specifications we are dealing with a fairly large information set and, as we have the right to refuse requests out of the agreed [[scope|Scope Management]] so the Customer has the right to expect us to fully address that same scope.
That's the concept of coverage : ''we need to assure that everything in scope is properly addressed in each step of the process and produces its necessary effects''.
Coverage is an important quality attribute for any specification and, in fact, for many other aspects like when scientifically discussing alternatives (we need to assure that the proposed alternatives cover the intended scope, if they don't, they are not alternatives for the problem under discussion).
The concept was put as requirement for the scientific method by XVII century philosopher [[Rene Descartes' |http://www.marxists.org/reference/archive/descartes/1635/discourse-method.htm]] fourth principle "//''And the last, in every case to make enumerations so complete, and reviews so general, that I might be assured that nothing was omitted.''//"
Many of the modeling techniques and tools we use are also oriented to coverage assurance and rest assured that it is very hard to achieve it without proper techniques and tools.
Proper [[CASE]] tools usually use a combination of [[status attributes|EA Usage - Attribute Status]] and [[traceability|Traceability]] information to assess and assure coverage.
----
See also [[Traceability]]
----
/%
@@color:#c4d6ed; ^^
Description: Coverage concept explanation
^^@@
%/
Data Flow Diagram
See [[Data Flow Diagram]]
----
/%
@@color:#c4d6ed; ^^
Description: Data Flow Diagram
^^@@
%/
Data Flow Diagrams ([[DFD]]) were proposed as __the essential view__ in the historical ''Structured Analysis and System Specification'' by Tom ~DeMarco, Yourdon Press, New York, 1978.
In his enlightened words "//(...) ''I conclude that it is a natural characteristic of the tool: When a Data Flow Diagram is wrong, it is glaringly, demonstrably, indefensibly wrong. This seems to me to be an enormous advantage of using Data Flow Diagrams.''//" chapter 3.2
Although he corrected his statement to "//Dataflow is one of the essential views, not the only one//" in //Structured Analysis, Tom ~DeMarco, sd&m Conference 2001, Software Pioneers//, we strongly agree that ''DFD view is essential'' for the analysis of software solutions especially as a __''[[validation|Validation]], [[scope|Scope]] definition and [[coverage|Coverage]] assurance tool''__ on the inception stages. No wonder DFD(0) are also known as ''System Context Diagram'', this name alone should give you the idea of its importance.
A DFD(0) diagram allows to answer many questions like:
*are we considering all external systems we need to interact with?
*are we considering all externally required (in and out) data items?
*is the request for integrating system X in scope of our Proposal?
these, and some other, are examples of DFD(0) usefulness as it clearly establishes an integration [[scope|Scope]], provides a [[coverage|Coverage]] check-list for external systems and, last but not least, is extremely readable by Customer personnel without the need to understand complex notations thus providing very good [[validation|Validation]] ability.
<<Image "FR" "250" "DFD%280%29.png" "https://dl.dropbox.com/" "s/9xa5jbcjemrd9j9/" "?dl=1" "DFD(0) or Context Diagram">>
//"Another useful model in system design is the context diagram, which represents all external entities that may interact with a system, either directly or indirectly. (...) Such a diagram pictures the system at the center, with no details of its interior structure, surrounded by all its interacting systems, environments, and activities. The objective of a system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of system requirements and constraints."//
<<BibRef "Kossiakoff 2011">> pg. 266
No software specification is complete without, at least, one Context Diagram describing the system data flows to and from all external entities. Not doing so is to risk to face a lot of Access databases and obscure legacy systems that nobody heard about before, popping like mushrooms after a rainy day, on the Requirements Specification phase and, of course, they must be integrated in the new system.
<<Image "FR" "350" "DFD%281%29.png" "https://dl.dropbox.com/" "s/wgm8wh10cihcn37/" "?dl=1" "DFD level 1">>
DFDs may be detailed in further levels to describe the inner flows of the system and they are very useful to help define modularization.
!!Additional references
* Just Enough Structured Analysis, Edward Yourdon - [[Wiki version|http://yourdon.com/strucanalysis/wiki/index.php/Chapter_9]] - [[On Wayback Machine|https://web.archive.org/web/20151204163430/http://www.yourdon.com:80/strucanalysis/wiki/index.php/Table_of_Contents]]
** Specially : [[Chapter 18.|http://yourdon.com/strucanalysis/wiki/index.php/Chapter_18]] The Environmental Model [[On Wayback Machine|https://web.archive.org/web/20150821014818/http://www.yourdon.com:80/strucanalysis/wiki/index.php/Chapter_18]]
TODO: add example, describe usage
----
See also : [[Use Case Diagram]]
----
@@color:#c4d6ed; ^^
Description: DFD concept, usage and references
^^@@
----
/%
@@color:#c4d6ed; ^^
Description: TODO
^^@@
%/
"//In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application.[1] Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.//"
Pasted from <http://en.wikipedia.org/wiki/Software_design_pattern>
One of the best resources for pattern related information is [[The Hillside Group|http://hillside.net/]] site.
----
/%
@@color:#c4d6ed; ^^
Description: Software Design Patterns concept and references
^^@@
%/
!! <html><a name="Architecture" /></html> Architecture
* [[Bredemeyer Consulting - Software Architecture, Architects and Architecting|http://www.bredemeyer.com/]] - This site organizes a variety of resources to help enterprise architects and software architects deepen and expand their understanding of architecture and the role of the architect.
* [[MS The Architecture Journal|http://www.architecturejournal.net]] - Microsoft's Architecture Journal.
* [[The Open Group|http://www.opengroup.org/]] - The Open Group’s member organizations work to establish open, vendor-neutral IT standards and certifications in a variety of subject areas critical to the enterprise.
* [[Martin Fowler wiki|http://martinfowler.com/]] - An excellent source of information and advice from a known guru.
!! <html><a name="OOP" /></html> OOP (Object Oriented Programming)
* [[JOT|http://www.jot.fm]] - Journal of Object Technology (JOT) is an on-line peer-reviewed publication, published six times per year by the ETH Swiss Federal Institute of Technology, aimed at intermediate to advanced practitioners, educators and researchers in the field of object technology.
* [[Object Mentor|http://www.objectmentor.com/index.html]] - Founded in 1991 by Robert C. Martin, Object Mentor is a team of highly experienced software professionals specializing in object-oriented technologies and [[Agile|Agile Methodologies]]/XP development methodologies.
!! <html><a name="Reuse" /></html> Reuse
* [[Art of Software Reuse|http://artofsoftwarereuse.com/]] - by Vijay Narayanan, a site dedicated to developers, designers, and architects aspiring to create better software.
!! <html><a name="BusinessAnalysis" /></html> Business Analysis
* [[A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)|http://www.iiba.org/imis15/IIBA/Professional_Development/Business_Analysis_Body_of_Knowledge/IIBA_Website/Professional_Development/Business_Analysis_Body_of_Knowledge_pages/Business_Analysis_Body_of_Knowledge.aspx?hkey=d0891e0a-996a-431f-a6f5-a7d644e23a5c]] - is the collection of knowledge within the profession of business analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the business analysis professionals who apply it in their daily work role.
* [[Ed Yourdon's Structured Analysis Wiki|http://yourdon.com/strucanalysis/wiki/index.php/Introduction]] - [[On Wayback machine|https://web.archive.org/web/20151221060312/http://yourdon.com/strucanalysis/wiki/index.php/Introduction]] - This project represents the ongoing evolution of Ed Yourdon's 1989 tome, Modern Structured Analysis. Until very recently, a revised and updated version was available on Ed's website under the title Just Enough Structured Analysis (...).
----
@@color:#c4d6ed; ^^
Description: Links about Software Development worth visiting.
^^@@
/***
|''Name''|DiffFormatter|
|''Description''|highlighting of text comparisons|
|''Author''|FND|
|''Version''|0.9.0|
|''Status''|beta|
|''Source''|http://svn.tiddlywiki.org/Trunk/contributors/FND/formatters/DiffFormatter.js|
|''CodeRepository''|http://svn.tiddlywiki.org/Trunk/contributors/FND/|
|''License''|[[BSD|http://www.opensource.org/licenses/bsd-license.php]]|
|''Keywords''|formatting|
!Description
Highlights changes in a unified [[diff|http://en.wikipedia.org/wiki/Diff#Unified_format]].
!Notes
Based on Martin Budden's [[DiffFormatterPlugin|http://svn.tiddlywiki.org/Trunk/contributors/MartinBudden/formatters/DiffFormatterPlugin.js]].
!Usage
The formatter is applied to blocks wrapped in <html><code>{{{diff{..}}}</code></html> within tiddlers tagged with "diff".
!Revision History
!!v0.9 (2010-04-07)
* initial release; fork of DiffFormatterPlugin
!StyleSheet
.diff { white-space: pre; font-family: monospace; }
.diff ins, .diff del { display: block; text-decoration: none; }
.diff ins { background-color: #dfd; }
.diff del { background-color: #fdd; }
.diff .highlight { background-color: [[ColorPalette::SecondaryPale]]; }
!Code
***/
//{{{
(function() {
config.shadowTiddlers.StyleSheetDiffFormatter = store.getTiddlerText(tiddler.title + "##StyleSheet");
store.addNotification("StyleSheetDiffFormatter", refreshStyles);
var formatters = [{
name: "diffWrapper",
match: "^\\{\\{diff\\{\n", // XXX: suboptimal
termRegExp: /(.*\}\}\})$/mg,
handler: function(w) {
var el = createTiddlyElement(w.output, "div", null, "diff");
w.subWikifyTerm(el, this.termRegExp);
}
}, {
name: "diffRange",
match: "^(?:@@|[+\\-]{3}) ",
lookaheadRegExp: /^(?:@@|[+\-]{3}) .*\n/mg,
handler: function(w) {
createTiddlyElement(w.output, "div", null, "highlight").
innerHTML = "…";
this.lookaheadRegExp.lastIndex = w.matchStart;
var lookaheadMatch = this.lookaheadRegExp.exec(w.source);
if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
w.nextMatch = this.lookaheadRegExp.lastIndex;
}
}
}, {
name: "diffAdded",
match: "^\\+",
termRegExp: /(\n)/mg,
handler: function(w) {
var el = createTiddlyElement(w.output, "ins", null, "added");
w.subWikifyTerm(el, this.termRegExp);
}
}, {
name: "diffRemoved",
match: "^-",
termRegExp: /(\n)/mg,
handler: function(w) {
var el = createTiddlyElement(w.output, "del", null, "removed");
w.subWikifyTerm(el, this.termRegExp);
}
}
];
config.parsers.diffFormatter = new Formatter(formatters);
config.parsers.diffFormatter.format = "diff";
config.parsers.diffFormatter.formatTag = "diff";
})();
//}}}
As said, in a software project we have, at least, two kinds of identifiable digital artefacts:
## ''Filesystem artefacts'' - are the ones that are identified by their placement in the filesystem together with their [[CVS]] revision. This is the case, for instance, of source code files or binaries or Customer provided information. Typically we do not want or can change these artefacts (content or name) to include an identifier.
## ''Numbered artefacts'' - are the ones that posses and exhibit an unique identifier (in their name and/or content). They shall also have their [[CVS]] revision as explicit content. Note that these artefacts may exist as physical and not only digital form, this is the case, for instance, of specification documents.
All digital artefacts shall be placed in a versioned ([[CVS]]) filesystem but that is not enough to make them unequivocal as they are copied, printed and transmitted among project's actors and stakeholders. To be sure that all participants can access and confirm that they are using the same variant of a given artefact is crucial for reliability.
One must define an identification schema for the artefacts that allows for unequivocal reference. Pay attention that __this identifier ''shall not'' include version information__ as this will be managed by the versioning system. Versioning systems are file based so you shall never put variable information on a file's name : ''the file's name may include an unique identifier but must be constant and never be changed.''
The ''Digital Artefact Identification'' is then composed of:
#''An unique identifier'' that shall be present in file's name and may/shall be also present in file's content
#''A revision identifier'' that is provided by [[CVS]] and __must__ be present in file's content (CVS can automatically fill this revision on checkout) and __shall not__ be present in its name. The filename and revision identifier shall be enough for the exact file's instance to be retrieved from the versioning system.
TODO:
----
Back to [[Configuration Management]] [[High Maturity Practices]]
----
/%
@@color:#c4d6ed; ^^
Description: Digital Artefact Identification discussion and guideline
^^@@
%/
! Display and Navigation Options
//Display and navigation options for this space//
<<option chkEnableTabsBar>> Tabbed navigation
<<option chkShowBreadcrumbs>> Show Breadcrumbs
<<option chkSinglePageMode>> Display one tiddler at a time
><<option chkSinglePagePermalink>> Automatically permalink current tiddler
><<option chkSinglePageKeepFoldedTiddlers>> Don't close tiddlers that are folded
><<option chkSinglePageKeepEditedTiddlers>> Don't close tiddlers that are being edited
<<option chkTopOfPageMode>> Open tiddlers at the top of the page
<<option chkBottomOfPageMode>> Open tiddlers at the bottom of the page
<<option chkSinglePageAutoScroll>> Automatically scroll tiddler into view (if needed)
----
@@color:#c4d6ed; ^^
Description: Display and navigation options for this space
^^@@
“//In preparing for battle, I have always found that plans are useless, but planning is indispensable.//”
General Dwight D. Eisenhower
----
/%
@@color:#c4d6ed; ^^
Description: A quote from General Dwight D. Eisenhower about plans
^^@@
%/
/***
|!''Name:''|!''E''asily ''A''daptable ''S''ource ''E''ditor|
|''Description:''|this framework allows you to easily create commands that work on the current tiddler text selection in edit mode|
|''Version:''|0.1.0|
|''Date:''|13/01/2007|
|''Source:''|http://yann.perrin.googlepages.com/twkd.html#E.A.S.E|
|''Author:''|[[Yann Perrin|YannPerrin]]|
|''License:''|[[BSD open source license]]|
|''~CoreVersion:''|2.x|
|''Browser:''|Firefox 1.0.4+; Firefox 1.5; InternetExplorer 6.0|
See [[easyFormat]] and [[easyInsert]] for menu building examples. You must add the menu to [[EditTemplate]] as
{{{<div macro='toolbar format insert'></div>}}}
***/
////Messages Definition
//{{{
config.messages.Ease = {
noselection:"nothing selected",
asktitle:"enter the new tiddler title",
exists:" already exists, please enter another title",
askForTagsLabel:"enter the new tiddler tags",
tiddlercreated:" tiddler created"
}
//}}}
////
//{{{
if (!window.TWkd) window.TWkd={context:{}};
if (!TWkd.Ease)
TWkd.Ease = function (text,tooltip){
this.text = text;
this.tooltip = tooltip;
this.modes = [];
this.addMode = function(modeDefinition) {this.modes.push(modeDefinition);};
this.handler = function(event,src,title) {
TWkd.context.command = this;
TWkd.context.selection=this.getSelection(title);
if (this.modes.length==1) {
this.modes[0].operation();
}
else {
var popup = Popup.create(src);
if(popup) {
for (var i=0; i<this.modes.length; i++) {
createTiddlyButton(createTiddlyElement(popup,"li"), this.modes[i].name, this.modes[i].tooltip, this.OperateFromButton, null, 'id'+i, null);
}
Popup.show(popup,false);
event.cancelBubble = true;
if (event.stopPropagation) event.stopPropagation();
return false;
}
}
};
};
TWkd.Ease.prototype.OperateFromButton = function(e){
var commandMode=this.getAttribute('Id').replace('id','');
TWkd.context.command.modes[commandMode].operation();
};
TWkd.Ease.prototype.getTiddlerEditField = function(title,field){
var tiddler = document.getElementById(story.idPrefix + title);
if(tiddler != null){
var children = tiddler.getElementsByTagName("*")
var e = null;
for (var t=0; t<children.length; t++){
var c = children[t];
if(c.tagName.toLowerCase() == "input" || c.tagName.toLowerCase() == "textarea"){
if(!e) {e = c;}
if(c.getAttribute("edit") == field){e = c;}
}
}
if(e){return e;}
}
} // closes getTiddlerEditField function definition
TWkd.Ease.prototype.getSelection = function(title,quiet) {
var tiddlerTextArea = this.getTiddlerEditField(title,"text");
var result = {};
if (document.selection != null && tiddlerTextArea.selectionStart == null) {
tiddlerTextArea.focus();
var range = document.selection.createRange();
var bookmark = range.getBookmark();
var contents = tiddlerTextArea.value;
var originalContents = contents;
var marker = "##SELECTION_MARKER_" + Math.random() + "##";
while(contents.indexOf(marker) != -1) {
marker = "##SELECTION_MARKER_" + Math.random() + "##";
}
var selection = range.text;
range.text = marker + range.text + marker;
contents = tiddlerTextArea.value;
result.start = contents.indexOf(marker);
contents = contents.replace(marker, "");
result.end = contents.indexOf(marker);
tiddlerTextArea.value = originalContents;
range.moveToBookmark(bookmark);
range.select();
}
else {
result.start=tiddlerTextArea.selectionStart;
result.end=tiddlerTextArea.selectionEnd;
}
result.content=tiddlerTextArea.value.substring(result.start,result.end);
result.source=title;
if (!result.content&&!quiet) displayMessage(config.messages.Ease.noselection);
return(result);
}//closes getSelection function definition
// replace selection or insert new content
TWkd.Ease.prototype.putInPlace=function(content,workplace) {
var tiddlerText = this.getTiddlerEditField(workplace.source,"text");
tiddlerText.value = tiddlerText.value.substring(0,workplace.start)+content+tiddlerText.value.substring(workplace.end);
}
// asking for title
TWkd.Ease.prototype.askForTitle = function(suggestion) {
if (!suggestion)
suggestion = "";
var newtitle;
while (!newtitle||store.tiddlerExists(newtitle))
{
if (store.tiddlerExists(newtitle))
displayMessage(newtitle+config.messages.Ease.exists);
newtitle = prompt(config.messages.Ease.asktitle,suggestion);
if (newtitle==null)
{
displayMessage(config.messages.Ease.titlecancel);
return(false);
}
}
return(newtitle);
}//closes askForTitle function definition
// creation of a new tiddler
TWkd.Ease.prototype.newTWkdLibTiddler = function(title,content,from,askForTags){
var tiddler = new Tiddler();
tiddler.title = title;
tiddler.modifier = config.options.txtUserName;
tiddler.text = content;
(from) ? tiddler.tags = [from] : tiddler.tags=[];
if (askForTags)
tiddler.tags = prompt(config.messages.Ease.askForTagsLabel,'[['+from+']]').readBracketedList();
store.addTiddler(tiddler);
//store.notifyAll();
displayMessage(title+config.messages.Ease.tiddlercreated);
}
if (!TWkd.Mode)
TWkd.Mode = function (name,tooltip,ask,operation) {
this.name = name;
this.tooltip = tooltip;
this.ask = ask;
this.operation = operation;
};
//}}}
This is a list of various tips and tricks that may be useful when using [[EA|Sparx Enterprise Architect]].
{{tw_ttoc{}}}
!Connectors
!! Connecting to element's internal features
You can target a connector to an element's attribute or operation instead of the element as a whole. <<Image "FR" "300" "EATT_ConnIntFeat.PNG" "https://dl.dropbox.com/" "s/xlekxxy3e6rrghj/" "?dl=1" "Connecting to internal features.">>
# In a diagram
## Create a connector between two elements
## Invoke contextual menu on the connector
## Select "Link to Element Feature"
### Choose the type of Feature
### Choose the Feature
!! Highlight Connectors from/to Element
You can highlight the connectors targeting and originating from an Element
# In a diagram
## Select an Element
## Press 'L'
### Green connectors are outgoing
### Red connectors are incoming
!Import & Export
!! Creating elements by dragging text onto a diagram
You can create an element just by dragging some text from a document onto an EA diagram. The text is parsed to split title and content of the element.
//Tip: you can open a PDF in MS Word (just use file\open) and do this from Word.//
!! Exporting to CSV through document generation
<<Image "FR" "300" "EA-CSV-export-tpl.PNG" "https://dl.dropbox.com/" "s/lsz5qgskshsbszj/" "?dl=1" "EA CSV export template">>
A good alternative and very flexible way of exporting selected elements to CSV is to create a document generation template for it.
Just pay attention to the line-breaks in the template : they are a record separator on CSV.
!! Embedding files in EA
You may drag a file to a diagram and choose {{{Artifact Internal}}} This will create an artefact with the file embedded. You can "execute" the file by double clicking the artefact element. Notice that if you edit the file EA will ask if you want to update it in its database.
!Project Browser
!!Element Hierarchy
*You may drag elements outside a Region by dragging and holding Alt.
!Search
!!Search command
<<Image "FR" "200" "EA-command-search1.PNG" "https://dl.dropbox.com/" "s/ffcv24cx3yrgekd/" "?dl=1" "EA command search">>
One of the interesting new features of EA 13 is the search command functionality. It allows you to input some words and then it presents a menu with relevant direct functionality access.
<<Image "FR" "300" "EA-command-search.PNG" "https://dl.dropbox.com/" "s/4rv1k984ckg5qvh/" "?dl=1" "EA command search configuration">>
The issue is that it will only be available if you use //Visual Style// Microsoft Office 2016.
!Shortcuts
!! Auto generate timestamp
You can generate the current date & time in the text of an Element's note
# In the notes textbox
## Press F5
!! Invoke code window
You can invoke a syntax highlighted code viewer upon reverse engineered classes
# Select the class on diagram or project browser tree
## press F12
!Errors
!! Project transfer
When transferring a project from file to DB you get an error:
{{{Microsoft OLE DB Provider for SQL Server [-2147217865]
Invalid object name 't_secpolicies'}}}
# Database is not initialized, you have to execute EA's scripts on it prior to import, see http://www.sparxsystems.com/resources/corporate/#update-dbms
----
<<TiddlerToC min-entries:1>>
/%
@@color:#c4d6ed; ^^
Description: Tips & tricks for EA usage
^^@@
%/
[[EA|Sparx Enterprise Architect]] allows for elements and other items (e.g. boundry) to have an Alternate Image. This image replaces the element standard representation in diagrams.
<<Image "FR" "250" "EA-Usage-Alternate-Image01.png" "https://dl.dropbox.com/" "s/xyt9r91l83u7dd0/" "?dl=1" "Alternate Image">>
Select an element in diagram (you may also use a boundry) and invoke contextual menu, choose //''Appearance\Select alternate image''//
<<Image "FR" "250" "EA-Usage-Alternate-Image02.png" "https://dl.dropbox.com/" "s/45p13bxt8rzo85r/" "?dl=1" "Select Alternate Image">>
The Image Manager dialogue allows to select an existing image or to add a new image to the image library. Notice that you can import and export the image library in //''Project\Model Import/Export/Reference Data''//
<<Image "FR" "250" "UserInterface04.JPG" "https://dl.dropbox.com/" "s/4za96k497jj465a/" "?dl=1" "Pencil Alternate Image">>
Select the [[Pencil]] image as the alternate image and you have an embedded mockup in your specification. It makes a very good addition to the generated documentation as you can see in [[EA Usage - User Interface diagram]].
<<Image "FR" "250" "EA-Usage-Alternate-Image03.png" "https://dl.dropbox.com/" "s/ebbxwc0j4uzjpgw/" "?dl=1" "A Deployment diagram with alternate images">>
This is a quite useful feature for overview and less technical diagrams like Deployment Overview.
----
See also : [[EA Usage - User Interface diagram]]
----
/%
@@color:#c4d6ed; ^^
Description: Enterprise Architect usage guideline - Alternate images for elements
^^@@
%/
Scope : Elements, Packages
Values : Low | Medium | High
<<Image "FR" "350" "EA-Element-Properties-Difficulty.png" "https://dl.dropbox.com/" "s/al3olln0c4xkpuh/" "?dl=1" "EA element properties dialog.">>
The difficulty attribute shall be used to identify areas (features, requirements, modules) that present major challenges to the project.
This is very important for estimation, planning, know-how gathering, testing and risk management.
We propose the use of a very simple three level scale :
|Level|Description|h
|Low|Below normal complexity. Well known domain with available experience and proved implementations. Formal reusable module available as-is. Low, stable and known business complexity.|
|Medium|Normal implementation problem where we do not expect major issues. No new technologies. Medium business complexity|
|High|Domain novelty (technical or business). Complex, not stable business definition. Severe performance, security or availability constraints. Criticality.|
The difficulty determination shall start at [[RFP analysis|RFP Analysis Guidelines]] and be a major concern at [[Technical Proposal|Technical Proposal Production Guidelines]] specially in the Major Challenges chapter. It is also very important on [[Specification|Software Specification]] to help selecting the main targets for testing and the modules that present more risk and need more attention.
On Estimation, specially if you use a [[PERT]] three point estimate, this identification will be very useful to establish, and justify, the pessimistic and optimistic offset of each task.
----
See also : [[Sparx Enterprise Architect]]
/%
@@color:#c4d6ed; ^^
Description: Enterprise Architect attribute usage guideline - Difficulty
^^@@
%/
Scope : Elements, Packages
<<Image "FR" "350" "EA%20Element%20Properties%20-%20Status%20and%20Version.jpg" "https://dl.dropbox.com/" "s/tjoknyicii3ssm9/" "?dl=1" "EA element properties dialog.">>
The following topics establish the state flow for elements of the model in their ''Status'' attribute.
The Status attribute is a main filtering factor and shall be used to clearly state the development status of each element and to identify what is already done and what needs to be done towards them.
Status is a major reporting and management item as it allows to filter the different completion state of the elements therefore providing good situational awareness and even quantitative assessments.
Unfortunately in EA the state's list is shared for all element types so you must have different states and state flows for different elements but the dropbox of each element will show them all. A clear state chart for each type is, therefore, essential to allow for a coherent and useful usage of the attribute.
Take notice that not all of the states shall be used in each concretization phase.
Status is closely related with [[Version|EA Usage - Attribute Version]] and, typically, it is a status transition that triggers version changes.
!!Requirements and Features
In Requirements and Features the status attribute is used, primarily, to convey information about what is done and what is to be done. It is also used to mark baselined elements, that is, elements that can not be changed without proper cautions.
<<Image "FR" "350" "EA%20Element%20Properties%20-%20Status%20%28FT-SR%29.jpg" "https://dl.dropbox.com/" "s/ejokdrbg24bxoa6/" "?dl=1" "Features and Requirements">>
*DRAFT
**Scope : all elements.
**The element has been sketched by Customer or team member It is in an initial state and needs further work and validation.
*REVIEWED
**Scope : all elements.
**The DRAFT element has been reviewed and approved by team leadership.
**It may be presented to Customer for Validation.
*VALIDATED
**Scope : Requirement or Feature.
**The Requirement or Feature has been informally validated by Stakeholders.
**Further changes shall change minor version and regress to DRAFT.
*APPROVED
**Scope : Requirement or Feature.
**The element is formally approved by the Customer.
**From this point on formal Change Management procedures apply.
**Major version is set to 1. On change it shall increment.
*SPECIFIED
**Scope : Requirement.
**The requirement has been assigned to a Component and Acceptance Tests defined.
*IMPLEMENTED
**Scope : Requirement or Feature.
**The element has been implemented.
*UPDATED
**Scope : Requirement or Feature.
**The element has been updated to reflect implementation changes/improvements.
**Minor version is incremented.
*TESTED
**Scope : Requirement or Feature.
**Implementation of the element has been Verified and Validated.
TODO: review state chart (Tested -> Updated, Deployed)
----
See also : [[Sparx Enterprise Architect]]
/%
@@color:#c4d6ed; ^^
Description: Enterprise Architect attribute usage guideline - Status
^^@@
%/
Scope : Requirements and Features
<<Image "FR" "350" "EA%20Element%20Properties%20-%20Status%20and%20Version.jpg" "https://dl.dropbox.com/" "s/tjoknyicii3ssm9/" "?dl=1" "EA element properties dialog.">>
The following topics establish the versioning schema for Requirements and Features (and their included additional diagrams).
Notice that Version is, in this scope, closely related to [[Status|EA Usage - Attribute Status]].
Versioning of the Requirements and Features is not intended to provide baseline identification, that's the generated documents job. These versions are working versions and their purpose is to mark changes in specification against Customer or stakeholder formal or informal interactions, that is, if you informally validate a set of requirements with one stakeholder and then you make changes to some of them you want to be able to quickly list them in the next interaction with that stakeholder. Also if you have a set of requirements formally approved and after you update them to reflect implementation findings you also want to be able to build a list of changed requirements. In this last case the baseline is established by the generated document that the Customer approves and that is placed under Change Management and Version Control not by each requirement's version but you surly understand the utility of being able to tell what changed after that, think about revision and validation effort.
We propose that a major and minor version scheme be used like 1.2. The major version shall be incremented when a change occurs after any formal interaction with the Customer, that is, over any baselined item. The minor version shall be incremented when a change happens after an informal stakeholder validation.
----
See also : [[Sparx Enterprise Architect]]
/%
@@color:#c4d6ed; ^^
Description: Enterprise Architect attribute usage guideline - Version
^^@@
%/
<<Image "FR" "350" "EA-Usage-Requirements-Diagram.png" "https://dl.dropbox.com/" "s/qltfyj1odu0elud/" "?dl=1" "EA requirements diagram.">>
The Requirements Diagram is an Extended (non UML) diagram used in Inception and Specification stages.
Its main usage is to capture statements that define scope, behaviour and requirements of the system to be developed. It is also used to relate [[Features|Feature]] and [[Requirements|Software Requirement]] with Issues, Assumptions and Ideas.
Features and Requirements (and Ideas, Issues and Assumptions) have some common characteristics :
*they are univocal elements, that is, they are numbered in a way that makes them unique in the model scope.
*their information is normalized, that is, they should not have redundant or duplicated statements
*they are atomic, that is, their statement and status (and other attributes) shall not depend on each other but be contained in a single element. This clearly excludes approaches with requirements inside other requirements or dependency relationships between requirements. Of course __Package inclusion provides a common context and an implicit relationship for contained requirements but no stronger ties shall be established between elements at the same concretisation level.__
The requirements are the most concrete expression and they must follow a strict [[SMART Requirements]] guideline, on the other hand, Proposed Features and, specially, Requested Features are allowed a more relaxed expression guideline. Never forget, however, that Proposed Features are what establishes scope and support estimation.
Requirement type elements (Requirement, Feature, Issue, etc.) shall be as atomic as possible in order to allow to control state (an element shall always have a defined, unambiguous state) and contain change impact. Atomicity is also an essential characteristic if we want to extract quantitative volume metrics of these elements in any meaningful way, and these are essential for objective management and planing.
__For requirement elements of the same kind, in the same life-cycle phase (or concretisation stage), shared context and conceptual or logical grouping shall be provided by package inclusion and not by any other kind of relationship. That is, you shall not compose Proposed Features with other Proposed Features or make them dependent from each other. Even association relationships are not advisable in this scenario.__ Of course this is not the case of relationships of different kind. A Proposed Feature may depend on an Assumption, a Requested Feature may depend on an Issue, a Proposed Feature shall Abstraction trace to a Requested Feature, etc. Also a Proposed Feature or Software Requirement may be made composite to include a State Machine or other diagram if it helps to explain it.
<<Image "FR" "350" "EA-Usage-Requirements-Diagram-elements.png" "https://dl.dropbox.com/" "s/gdgy4qju10mby8u/" "?dl=1" "EA requirements diagram, other elements.">>
Requested Features, Proposed Features and Software Requirements may ''Depend'' on ''Issues'' and ''Assumptions'' and they also may be ''Associated'' from ''Ideas''.
''Issues'' are questions or doubts or pending matters that are essential to understand, specify or implement the dependent elements.
''Assumptions'' are choices or scenarios that we assume as true and that are a condition to dependent elements.
''Ideas'' are ideas, that is, opportunities, improvements, further business that we identify along the project and that we preserve this way for future reference when and if the opportunity emerges.
----
See also : [[Sparx Enterprise Architect]] [[Writing Good Requirements]]
/%
@@color:#c4d6ed; ^^
Description: Enterprise Architect diagram usage guideline - Requirements
^^@@
%/
[[EA|Sparx Enterprise Architect]] has an extended User Interface diagram that allows to build [[GUI mockup]]s that can be extremely useful to illustrate user interaction requirements.
<<Image "FR" "350" "UserInterface01.JPG" "https://dl.dropbox.com/" "s/dideg231pdy3i8v/" "?dl=1" "EA User Interface diagram">>
These diagrams are interesting as each element of the interface is an autonomous EA element and, as such, can be related with other elements like table fields for instance.
<<Image "FR" "500" "UserInterface02.JPG" "https://dl.dropbox.com/" "s/rbg99m6r4gyjzjm/" "?dl=1" "EA User Interface diagram embedded">>
The user interface mockup may be embedded in a software requirement becoming part of its statement.
<<Image "FR" "500" "UserInterface03.JPG" "https://dl.dropbox.com/" "s/ef577rlmgpxn3et/" "?dl=1" "EA User Interface diagram in documentation">>
Notice that this kind of embedding makes it much easier to understand requirements in the generated documentation as the image provides a good interpretation context to textual requirements and these also provide context for image interpretation.
In the example you would notice that database selection at login is not referred in any requirement and thus [[validate|Validation]] if it is something not needed on the mockup or something that is needed but missing in the requirements.
If you do not need to individually link each of the UI elements these mockups are much easier to do and maintain in [[Pencil]] tool. See [[GUI mockup]] and [[EA Usage - Alternate Image]] topics for guidelines on how to use them.
Other references : [[Sparx Enterprise Architect 12: Wireframing|https://imprestige.biz/sparx-enterprise-architect-12-wireframing/]]
----
See also : [[GUI mockup]] [[EA Usage - Alternate Image]]
----
/%
@@color:#c4d6ed; ^^
Description: EA usage guideline for User Interface diagrams
^^@@
%/
“//Long books are often dull; fortunately, the subject matter of this book -- systems analysis -- is interesting. In fact, systems analysis is more interesting than anything I know, with the possible exception of sex and some rare vintages of Australian wine. Without a doubt, it is more interesting than computer programming (not that programming is dull) because it involves studying the interactions of people, and disparate groups of people, and computers and organizations.//”
[[Edward Yourdon|https://en.wikipedia.org/wiki/Edward_Yourdon]] (1944-2016)
[[Structured Analysis Wiki|https://web.archive.org/web/20150821014753/http://www.yourdon.com/strucanalysis/wiki/index.php/Chapter_1]], Chapter 1
----
/%
@@color:#c4d6ed; ^^
Description: Very good quote on how interesting Systems Analysis is
^^@@
%/
<!--{{{-->
<div class='toolbar' macro='toolbar [[ToolbarCommands::EditToolbar]]'>
<span class='toolbar' macro='gotoTiddler insert'"></span>
</div>
<div class='title' macro='view title'></div>
<div class='editor' macro='edit title'></div>
<div macro='annotations'></div>
<div macro='toolbar format insert'></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 excludeLists'></span></div>
<!--}}}-->
Emergent reuse concept is proposed by Adam Sroka, in a [[very interesting thread|http://tech.groups.yahoo.com/group/extremeprogramming/message/149980]], as a way to avoid effort waste on making reusable modules that are never reused. He says :
"//This last part isn't exactly "design for reuse." It is more like "emergent reuse" which seems to be the one sort of reuse that is rarely wasteful.//"
In the same thread a participant called timander37 added an [[interesting point|http://tech.groups.yahoo.com/group/extremeprogramming/message/150005]] :
//We tell our business people "The first time you have to pay for it to be coded, the second time you have to pay for it to be reusable, the third time it's free"//.
Vijay Narayanan also seems to point in the same direction on his interesting article [[Build for Use, then Refactor to Reuse|http://artofsoftwarereuse.com/2010/07/11/build-for-use-then-refactor-to-reuse/]].
Emergent reuse is seen as an agile alternative to "design for reuse" where you do not make an investment upfront to produce reusable assets but, instead, when the reuse opportunity emerges, and only then, you do invest towards reusability through refactoring and generalization.
This is indeed a quite good approach to reuse in a "project centric" organization. In fact, design for reuse in these kind of environments involves the risk of investing in a reusable module that, by one reason or another, will never be reused again.
We do propose that, at least part of the reuse effort, be performed in a way similar to our proposed [[Opportunistic Productization]]. The obstacles to this approach are, mainly, in the Reusable Software Asset Discovery area, that is, how do you assure that reuse opportunities are not wasted due to ignorance and lack of access to reusable assets?
On the other hand one must consider how to produce reusable assets that feed the emergent reuse and that is also not an easy task. Emergent reuse can not start from the scratch, it needs some systematic reuse planning and some infrastructural conditions and reuse methodologies to be put in place.
One important consideration is that Emergent Reuse is discussed against "Design for Reuse" it does not mean that it is not a way of performing [[Systematic Reuse]], on the contrary, it is one of the management strategies that may be used to perform it.
In [[Implementing Systematic Reuse]] we point out some guidelines that may be useful in this endeavour.
----
@@color:#c4d6ed; ^^
Description: Emergent reuse vs. design for reuse concept discussion
^^@@
//Like [[abstraction|Abstraction]], the word "encapsulation" can be used to describe either a process or an entity. As a process, encapsulation means the act of enclosing one or more items within a (physical or logical) container. Encapsulation, as an entity, refers to a package or an enclosure that holds (contains, encloses) one or more items. It is extremely important to note that nothing is said about "the walls of the enclosure." Specifically, they may be "transparent," "translucent," or even "opaque." //
* Edward V. Berard - Abstraction, Encapsulation and Information Hiding [[[Berard]|BibliographyPage##Berard]]
[[Abstraction]] gears towards comprehension
Encapsulation gears towards protection from outside interference
[[Information Hiding]] gears towards containment of design changes
----
@@color:#c4d6ed; ^^
Description: Encapsulation concept and references.
^^@@
"//''The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed. I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.''//"
[[No Silver Bullet - Essence and Accident in Software Engineering |http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf]] ([[on WayBack Machine|https://web.archive.org/web/*/http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf]])
[[Frederick P. Brooks|http://en.wikipedia.org/wiki/Fred_Brooks]]
Also on [[Wikipedia|https://en.wikipedia.org/wiki/No_Silver_Bullet]]
----
/%
@@color:#c4d6ed; ^^
Description: Quote of Frederick P. Brooks Essence of software
^^@@
%/
Features are a "relaxed" form of Requirements, namely they are not required to be, necessarily, [[SMART|SMART Requirements]]. We propose them as a preferred form to express requirements in [[RFP]] and [[Technical Proposal|Technical Proposal Production Guidelines]] at Inception phases.
<<Image "FR" "250" "Requirements-Elements.png" "https://dl.dropbox.com/" "s/o4ewv8nlr4vfb7w/" "?dl=1" "Feature element in EA.">>
Feature is an extended element in [[Sparx Enterprise Architect]] [[CASE]] tool Requirements diagram.
Features are split in ''Requested Features'', the ones that originate at Customer and describe the needs in the Customer perspective and ''Proposed Features'', the ones that constitute the software developer response at Proposal. The first ones use ''RFT'' prefix, the later ''FT''.
Quoting The Standish Group, The CHAOS Report, 1994, Scott ~McEwen in his very interesting article [[Requirements: An introduction|http://www.ibm.com/developerworks/rational/library/4166.html]] defines: "//''A feature is a service that the system provides to fulfill one or more stakeholder needs.''//"
For a distinction against [[Software Requirement]] see [[Software Requirement vs. Feature]]
----
@@color:#c4d6ed; ^^
Description: Feature concept and references.
^^@@
//''Complexity. Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into one, a subroutine, open or closed. In this respect software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.''//
[[No Silver Bullet - Essence and Accident in Software Engineering |http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf]] ([[on WayBack Machine|https://web.archive.org/web/*/http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf]])
[[Frederick P. Brooks|http://en.wikipedia.org/wiki/Fred_Brooks]]
Also on [[Wikipedia|https://en.wikipedia.org/wiki/No_Silver_Bullet]]
----
/%
@@color:#c4d6ed; ^^
Description: Frederick P. Brooks on Software Complexity
^^@@
%/
"//''The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.''//"
[[The mythical man-month - essays on software engineering, 1975|http://ultra.pr.erau.edu/~jaffem/classes/se300/Supplemental%20materials/The_Mythical_Man-Month_Essays_on_Software_Engineering_Anniversary_Edition.pdf]]
[[Frederick P. Brooks|http://en.wikipedia.org/wiki/Fred_Brooks]]
page 199
----
/%
@@color:#c4d6ed; ^^
Description: Quote of Frederick P. Brooks on requirements relevance
^^@@
%/
/***
|Name|FullScreenPlugin|
|Created by|SaqImtiaz|
|Location|http://tw.lewcid.org/#FullScreenPlugin|
|Version|1.1|
|Requires|~TW2.x|
!Description:
Toggle between viewing tiddlers fullscreen and normally. Very handy for when you need more viewing space.
!Demo:
Click the ↕ button in the toolbar for this tiddler. Click it again to turn off fullscreen.
!Installation:
Copy the contents of this tiddler to your TW, tag with systemConfig, save and reload your TW.
Edit the ViewTemplate to add the fullscreen command to the toolbar.
!History:
*25-07-06: ver 1.1
*20-07-06: ver 1.0
!Code
***/
//{{{
var lewcidFullScreen = false;
config.commands.fullscreen =
{
text:" ↕ ",
tooltip:"Fullscreen mode"
};
config.commands.fullscreen.handler = function (event,src,title)
{
if (lewcidFullScreen == false)
{
lewcidFullScreen = true;
setStylesheet('#sidebar, .header, #mainMenu{display:none;} #displayArea{margin:0em 0 0 0 !important;}',"lewcidFullScreenStyle");
}
else
{
lewcidFullScreen = false;
setStylesheet(' ',"lewcidFullScreenStyle");
}
}
config.macros.fullscreen={};
config.macros.fullscreen.handler = function(place,macroName,params,wikifier,paramString,tiddler)
{
var label = params[0]||" ↕ ";
var tooltip = params[1]||"Fullscreen mode";
createTiddlyButton(place,label,tooltip,config.commands.fullscreen.handler);
}
var lewcid_fullscreen_closeTiddler = Story.prototype.closeTiddler;
Story.prototype.closeTiddler =function(title,animate,slowly)
{
lewcid_fullscreen_closeTiddler.apply(this,arguments);
if (story.isEmpty() && lewcidFullScreen == true)
config.commands.fullscreen.handler();
}
Slider.prototype.lewcidStop = Slider.prototype.stop;
Slider.prototype.stop = function()
{
this.lewcidStop();
if (story.isEmpty() && lewcidFullScreen == true)
config.commands.fullscreen.handler();
}
//}}}
/***
|Name|GATrackerPlugin|
|Description|Google Analytics tracker|
|Author|Julien Coloos|
|Version|1.2.0|
|Date|2011-05-18|
|Status|stable|
|Source|http://julien.coloos.free.fr/TiddlyWiki-dev/#GATrackerPlugin|
|License|[img[CC BY-SA 3.0|http://i.creativecommons.org/l/by-sa/3.0/80x15.png][http://creativecommons.org/licenses/by-sa/3.0/]]|
|CoreVersion|2.6.2|
|Documentation|http://julien.coloos.free.fr/TiddlyWiki-dev/#GATrackerPlugin|
!Description
This plugin enables Google Analytics tracking inside TiddlyWiki.
The version used is the asynchronous one ({{{ga.js}}}).
The plugin comes with its own configuration, which is stored persistently inside the (hidden) [[SystemSettings]] tiddler.
The configuration has to be set before being effective: it can be done in the plugin tiddler (see below) if TiddlyWiki is not in read-only mode. Tracking works if an account ID has been set, tracking has been enabled, and TiddlyWiki access is non-local.
Tracking can be reported as either:
* page views
** pages are named {{{/#Tiddler name}}}
* events
** Category: {{{Tiddlers}}}
** Action: {{{Open}}}, {{{Refresh}}}, {{{Edit}}}, {{{Search}}}, {{{Close}}} or {{{CloseAll}}}
** Label
*** for {{{CloseAll}}} action: excluded tiddler
*** for {{{Search}}} action: searched text
*** otherwise, tiddler name on which action is performed
** Value: for the {{{CloseAll}}} action, the number of closed tiddlers
** Note: Google Analytics script limits the number of events (1 every 5 seconds, with a burst limit of 10)
Tracking can be globally disabled, or enabled per action on each tiddler:
* //Open//: when tiddler was not yet displayed
** Note: default tiddlers do not trigger this action when accessing TiddlyWiki
* //Refresh//: when tiddler was already displayed
** Note: this action is automatically triggered after editing a tiddler
* //Edit//: when editing (or viewing in read-only mode) the tiddler
* //Close//: when tiddler was displayed
** this action is never tracked in //pages views// tracking
** the //CloseAll// action is triggered by the TiddyWiki links //close all// and //close others// if at least one tiddler was closed; individual tiddlers closed are not tracked as //Close// actions
* //Search//: when searching in tiddlers
** this action is never tracked in //pages views// tracking
** {{{CloseAll}}} and {{{Open}}} actions are not taken into account while search is performed: TiddlyWiki automically closes opened tiddlers before searching and opens tiddler that match the searched text
!Configuration
<<GATrackerConfig>>
!Revision History
!!v1.2.0 (2011-05-18)
Enhancements:
* do not trigger {{{CloseAll}}} and {{{Open}}} actions when search is performed
* added the {{{Search}}} action
!!v1.1.0 (2011-05-17)
Enhancements:
* do not trigger {{{Open}}} action when displaying default tiddlers
* added the {{{CloseAll}}} action
!!v1.0.0 (2011-05-14)
Initial release.
!Code
***/
//{{{
/* Google Analytics queue object. Needs to be global. */
var _gaq = _gaq || [];
if (!config.extensions.GATracker) {(function($) {
version.extensions.GATrackerPlugin = {major: 1, minor: 2, revision: 0, date: new Date(2011, 5, 18)};
/* Prepare overridden TiddlyWiki displaying */
var trackOptions = {};
var displayDefault = 0, closingAll = 0, searching = 0;
var pl = config.extensions.GATracker = {
getOption: function(optKey) {
return (config.optionsSource && (config.optionsSource[optKey] == "setting")) ? config.options[optKey] : null;
},
setOption: function(optKey, value) {
config.options[optKey] = value;
config.optionsSource[optKey] = "setting";
saveOption(optKey);
},
loadOptions: function() {
var gaTrack = (pl.getOption("txt_GATracker_track") || "1,0,1,1,1,0,0").split(",");
trackOptions = {
id: pl.getOption("txt_GATracker_id"),
enabled: parseInt(gaTrack[0] || "1"),
type: parseInt(gaTrack[1] || "0"),
events: {
open: parseInt(gaTrack[2] || "1"),
refresh: parseInt(gaTrack[3]) || "1",
edit: parseInt(gaTrack[4] || "1"),
close: parseInt(gaTrack[5] || "0"),
search: parseInt(gaTrack[6] || "0")
}
};
if (trackOptions.id && !trackOptions.id.length) {
trackOptions.id = null;
}
},
saveOptions: function() {
var opts = trackOptions.enabled && "1" || "0";
opts += "," + trackOptions.type;
for (var ev in trackOptions.events) {
opts += "," + (trackOptions.events[ev] && "1" || "0");
}
pl.setOption("txt_GATracker_id", trackOptions.id || "");
pl.setOption("txt_GATracker_track", opts);
},
track: function() {
_gaq.push.apply(_gaq, arguments);
},
trackAndDisplayDefaultTiddlers: function() {
displayDefault = 1;
try { pl.displayDefaultTiddlers.apply(this, arguments) } catch(e){};
displayDefault = 0;
},
trackAndDisplayTiddler: function(srcElement, tiddler, template, animate, unused, customFields, toggle, animationSrc) {
if (!displayDefault) {
var trackEvent, title = (tiddler instanceof Tiddler) ? tiddler.title : tiddler;
if (story.getTiddler(title)) {
/* Tiddler is already displayed */
if (toggle === true) {
/* Closing tiddler: tracked in separate function */
}
else if (template === DEFAULT_EDIT_TEMPLATE) {
if (trackOptions.events.edit) trackEvent = "Edit";
}
else if (trackOptions.events.refresh) trackEvent = "Refresh";
}
else if (trackOptions.events.open && !searching) trackEvent = "Open";
if (trackEvent) pl.track(trackOptions.type ? ["_trackPageview", "/#" + title] : ["_trackEvent", "Tiddlers", trackEvent, title]);
}
pl.displayTiddler.apply(this, arguments);
},
trackAndCloseTiddler: function(title, animate, unused) {
if (closingAll) closingAll++;
else pl.track(["_trackEvent", "Tiddlers", "Close", title]);
pl.closeTiddler.apply(this, arguments);
},
trackAndCloseAllTiddlers: function(excluded) {
closingAll = 1;
try { pl.closeAllTiddlers.apply(this, arguments) } catch(e){};
if ((closingAll > 1) && !searching) pl.track(["_trackEvent", "Tiddlers", "CloseAll", excluded, closingAll - 1]);
closingAll = 0;
},
trackAndSearch: function(text, useCaseSensitive, useRegExp) {
if (!trackOptions.type && trackOptions.events.search) pl.track(["_trackEvent", "Tiddlers", "Search", text]);
searching = 1;
try { pl.search.apply(this, arguments) } catch(e){};
searching = 0;
}
};
pl.loadOptions();
/* Only track in non-local mode */
var local = "file:" == document.location.protocol;
if (!local && trackOptions.id && trackOptions.enabled) {
/* Insert script tag to load GA */
$("head").eq(0).prepend($("<script/>").attr({type: "text/javascript", async: "true", src: ("https:" == document.location.protocol ? "https://ssl" : "http://www") + ".google-analytics.com/ga.js"}));
/* Override TiddlyWiki display */
pl.displayTiddler = story.displayTiddler;
story.displayTiddler = pl.trackAndDisplayTiddler;
pl.displayDefaultTiddlers = story.displayDefaultTiddlers;
story.displayDefaultTiddlers = pl.trackAndDisplayDefaultTiddlers;
if (!trackOptions.type && trackOptions.events.close) {
pl.closeTiddler = story.closeTiddler;
story.closeTiddler = pl.trackAndCloseTiddler;
pl.closeAllTiddlers = story.closeAllTiddlers;
story.closeAllTiddlers = pl.trackAndCloseAllTiddlers;
}
pl.search = story.search;
story.search = pl.trackAndSearch;
/* Initialize tracking */
pl.track(["_setAccount", trackOptions.id], ["_trackPageview"]);
}
config.macros.GATrackerConfig = {
handler: function(place, macroName, params, wikifier, paramString, tiddler) {
$(createTiddlyElement(place, "div")).html("Tracking status: <span style='color:" + (trackOptions.id && trackOptions.enabled ? "green'>enabled" : "red'>disabled") + "</span> and <span style='color:" + (local ? "red'>" : "green'>non-") + "local</span>");
if (readOnly) {
$(createTiddlyElement(place, "div")).html("Configuration is not available in read-only mode");
return;
}
var formNode = $(createTiddlyElement(place, "div")).html("<div>Google Analytics plugin configuration:</div><table><tr><td>Account ID:</td><td><input id='ga_id' type='text'/></td></tr><tr><td>Tracking:</td><td><input id='ga_enabled' type='checkbox'/>Enabled<br/><br/>How: <select id='ga_track'><option value='0'>Events</option><option value='1'>Pages</option></select><br/><br/>What:<br/><input id='ga_track_open' type='checkbox'/>Open<br/><input id='ga_track_refresh' type='checkbox'/>Refresh<br/><input id='ga_track_edit' type='checkbox'/>Edit<br/><input id='ga_track_close' type='checkbox'/>Close<br/><input id='ga_track_search' type='checkbox'/>Search<br/></td></tr></table><input id='ga_action_submit' type='submit' value='Apply'/>");
$("#ga_id", formNode).val(trackOptions.id);
$("#ga_enabled", formNode)[0].checked = trackOptions.enabled;
$("#ga_track option", formNode).eq(trackOptions.type)[0].selected = true;
for (var ev in trackOptions.events) {
$("#ga_track_" + ev, formNode)[0].checked = trackOptions.events[ev];
}
$("#ga_action_submit", formNode).click(function() {
trackOptions.id = $("#ga_id", formNode).val();
if (!trackOptions.id.length) trackOptions.id = null;
trackOptions.enabled = $("#ga_enabled", formNode)[0].checked;
trackOptions.type = parseInt($("#ga_track", formNode).val());
for (var ev in trackOptions.events) {
trackOptions.events[ev] = $("#ga_track_" + ev, formNode)[0].checked;
}
pl.saveOptions();
var nodeDisplay = story.findContainingTiddler(place);
var tiddlerDisplay;
if (nodeDisplay) tiddlerDisplay = store.getTiddler(nodeDisplay.getAttribute("tiddler"));
story.refreshTiddler(tiddlerDisplay ? tiddlerDisplay.title : tiddler.title, null, true);
});
}
};
})(jQuery);}
//}}}
Graphical User Interface
----
/%
@@color:#c4d6ed; ^^
Description: Graphical User Interface
^^@@
%/
A [[GUI]] [[mockup|http://en.wikipedia.org/wiki/Mockup]] is invaluable when defining and clarifying requirements with the Customer. Remember that he is not always a software expert and, as such, he much more easily discusses and understands a representation of an interface form than a bunch of statements from which he does not know a lot of terms.
Form mockups are very useful in [[validating|Validation]] our views and expected user/system interaction. Completeness and sufficiency of entity's data (attributes) and correctness of normalization (lookups) are also much more visible in a mockup than in a lot of statements. Process adequacy is also checked when execution simulation is performed over mockups and allows to pinpoint problems early.
Using mockups is advisable as they are not expensive and largely contribute to proper [[Validation]].
Pay attention that mockups are, and shall be, a very simple form of prototyping. You do not need advanced interaction or functional prototypes to take advantage of mockups. Fidelity or "pixel perfect" designs have their place in the development cycle but they have different goals than mockups.
<<Image "FR" "" "GUIMock01.PNG" "https://dl.dropbox.com/" "s/1ftuuqnfvomkixa/" "?dl=1" "Simple GUI mockup using Pencil tool">>
A mockup shall be :
* cheap
* simple
* easily modifiable
* focused in validating/communicating
** a proposed data representation
** a proposed interaction schema
Notice that the mockup on the right is deliberately minimalist. It has no colour and uses an hand-drawn style. ''The purpose is to focus on data, process and functionality not on aesthetics.''
Mockups shall be integrated in your specification. You can easily do it in [[EA|Sparx Enterprise Architect]], see [[EA Usage - Alternate Image]]. I've found that, when, for instance, specifying [[features|Feature]] for a form, it makes it much easier and safe to validate if I include a simple mockup among the statements.
A very good, and free, tool to produce GUI mockups is [[Pencil]].
A good list of [[Gui Prototyping Tools|http://c2.com/cgi/wiki?GuiPrototypingTools]].
----
See also : [[EA Usage - Alternate Image]] [[Pencil]] [[EA Usage - User Interface diagram]]
----
/%
@@color:#c4d6ed; ^^
Description: GUI mockup concept, tools and usage
^^@@
%/
/***
|Name|GotoPlugin|
|Source|http://www.TiddlyTools.com/#GotoPlugin|
|Documentation|http://www.TiddlyTools.com/#GotoPluginInfo|
|Version|1.9.2|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|plugin|
|Description|view any tiddler by entering it's title - displays list of possible matches|
''View a tiddler by typing its title and pressing //enter//.'' As you type, a list of possible matches is displayed. You can scroll-and-click (or use arrows+enter) to select/view a tiddler, or press escape to close the listbox to resume typing. When the listbox is not displayed, pressing //escape// clears the current input.
!!!Documentation
>see [[GotoPluginInfo]]
!!!Configuration
<<<
*Match titles only after {{twochar{<<option txtIncrementalSearchMin>>}}} or more characters are entered.<br>Use down-arrow to start matching with shorter input. //Note: This option value is also set/used by [[SearchOptionsPlugin]]//.
*To set the maximum height of the listbox, you can create a tiddler tagged with <<tag systemConfig>>, containing:
//{{{
config.macros.gotoTiddler.listMaxSize=10; // change this number
//}}}
<<<
!!!Revisions
<<<
2009.05.22 [1.9.2] use reverseLookup() for IncludePlugin
|please see [[GotoPluginInfo]] for additional revision details|
2006.05.05 [0.0.0] started
<<<
!!!Code
***/
//{{{
version.extensions.GotoPlugin= {major: 1, minor: 9, revision: 2, date: new Date(2009,5,22)};
// automatically tweak shadow SideBarOptions to add <<gotoTiddler>> macro above <<search>>
config.shadowTiddlers.SideBarOptions=config.shadowTiddlers.SideBarOptions.replace(/<<search>>/,"{{button{goto}}}\n<<gotoTiddler>><<search>>");
if (config.options.txtIncrementalSearchMin===undefined) config.options.txtIncrementalSearchMin=3;
config.macros.gotoTiddler= {
listMaxSize: 10,
listHeading: 'Found %0 matching title%1...',
searchItem: "Search for '%0'...",
handler:
function(place,macroName,params,wikifier,paramString,tiddler) {
var quiet =params.contains("quiet");
var showlist =params.contains("showlist");
var search =params.contains("search");
params = paramString.parseParams("anon",null,true,false,false);
var instyle =getParam(params,"inputstyle","");
var liststyle =getParam(params,"liststyle","");
var filter =getParam(params,"filter","");
var html=this.html;
var keyevent=window.event?"onkeydown":"onkeypress"; // IE event fixup for ESC handling
html=html.replace(/%keyevent%/g,keyevent);
html=html.replace(/%search%/g,search);
html=html.replace(/%quiet%/g,quiet);
html=html.replace(/%showlist%/g,showlist);
html=html.replace(/%display%/g,showlist?'block':'none');
html=html.replace(/%position%/g,showlist?'static':'absolute');
html=html.replace(/%instyle%/g,instyle);
html=html.replace(/%liststyle%/g,liststyle);
html=html.replace(/%filter%/g,filter);
if (config.browser.isIE) html=this.IEtableFixup.format([html]);
var span=createTiddlyElement(place,'span');
span.innerHTML=html; var form=span.getElementsByTagName("form")[0];
if (showlist) this.fillList(form.list,'',filter,search,0);
},
html:
'<form onsubmit="return false" style="display:inline;margin:0;padding:0">\
<input name=gotoTiddler type=text autocomplete="off" accesskey="G" style="%instyle%"\
title="Enter title text... ENTER=goto, SHIFT-ENTER=search for text, DOWN=select from list"\
onfocus="this.select(); this.setAttribute(\'accesskey\',\'G\');"\
%keyevent%="return config.macros.gotoTiddler.inputEscKeyHandler(event,this,this.form.list,%search%,%showlist%);"\
onkeyup="return config.macros.gotoTiddler.inputKeyHandler(event,this,%quiet%,%search%,%showlist%);">\
<select name=list style="display:%display%;position:%position%;%liststyle%"\
onchange="if (!this.selectedIndex) this.selectedIndex=1;"\
onblur="this.style.display=%showlist%?\'block\':\'none\';"\
%keyevent%="return config.macros.gotoTiddler.selectKeyHandler(event,this,this.form.gotoTiddler,%showlist%);"\
onclick="return config.macros.gotoTiddler.processItem(this.value,this.form.gotoTiddler,this,%showlist%);">\
</select><input name="filter" type="hidden" value="%filter%">\
</form>',
IEtableFixup:
"<table style='width:100%;display:inline;padding:0;margin:0;border:0;'>\
<tr style='padding:0;margin:0;border:0;'><td style='padding:0;margin:0;border:0;'>\
%0</td></tr></table>",
getItems:
function(list,val,filter) {
if (!list.cache || !list.cache.length || val.length<=config.options.txtIncrementalSearchMin) {
// starting new search, fetch and cache list of tiddlers/shadows/tags
list.cache=new Array();
if (filter.length) {
var fn=store.getMatchingTiddlers||store.getTaggedTiddlers;
var tiddlers=store.sortTiddlers(fn.apply(store,[filter]),'title');
} else
var tiddlers=store.reverseLookup('tags','excludeLists');
for(var t=0; t<tiddlers.length; t++) list.cache.push(tiddlers[t].title);
if (!filter.length) {
for (var t in config.shadowTiddlers) list.cache.pushUnique(t);
var tags=store.getTags();
for(var t=0; t<tags.length; t++) list.cache.pushUnique(tags[t][0]);
}
}
var found = [];
var match=val.toLowerCase();
for(var i=0; i<list.cache.length; i++)
if (list.cache[i].toLowerCase().indexOf(match)!=-1) found.push(list.cache[i]);
return found;
},
getItemSuffix:
function(t) {
if (store.tiddlerExists(t)) return ""; // tiddler
if (store.isShadowTiddler(t)) return " (shadow)"; // shadow
return " (tag)"; // tag
},
fillList:
function(list,val,filter,search,key) {
if (list.style.display=="none") return; // not visible... do nothing!
var indent='\xa0\xa0\xa0';
var found = this.getItems(list,val,filter); // find matching items...
found.sort(); // alpha by title
while (list.length > 0) list.options[0]=null; // clear list
var hdr=this.listHeading.format([found.length,found.length==1?"":"s"]);
list.options[0]=new Option(hdr,"",false,false);
for (var t=0; t<found.length; t++) list.options[list.length]=
new Option(indent+found[t]+this.getItemSuffix(found[t]),found[t],false,false);
if (search)
list.options[list.length]=new Option(this.searchItem.format([val]),"*",false,false);
list.size=(list.length<this.listMaxSize?list.length:this.listMaxSize); // resize list...
list.selectedIndex=key==38?list.length-1:key==40?1:0;
},
keyProcessed:
function(ev) { // utility function
ev.cancelBubble=true; // IE4+
try{event.keyCode=0;}catch(e){}; // IE5
if (window.event) ev.returnValue=false; // IE6
if (ev.preventDefault) ev.preventDefault(); // moz/opera/konqueror
if (ev.stopPropagation) ev.stopPropagation(); // all
return false;
},
inputEscKeyHandler:
function(event,here,list,search,showlist) {
if (event.keyCode==27) {
if (showlist) { // clear input, reset list
here.value=here.defaultValue;
this.fillList(list,'',here.form.filter.value,search,0);
}
else if (list.style.display=="none") // clear input
here.value=here.defaultValue;
else list.style.display="none"; // hide list
return this.keyProcessed(event);
}
return true; // key bubbles up
},
inputKeyHandler:
function(event,here,quiet,search,showlist) {
var key=event.keyCode;
var list=here.form.list;
var filter=here.form.filter;
// non-printing chars bubble up, except for a few:
if (key<48) switch(key) {
// backspace=8, enter=13, space=32, up=38, down=40, delete=46
case 8: case 13: case 32: case 38: case 40: case 46: break; default: return true;
}
// blank input... if down/enter... fall through (list all)... else, and hide or reset list
if (!here.value.length && !(key==40 || key==13)) {
if (showlist) this.fillList(here.form.list,'',here.form.filter.value,search,0);
else list.style.display="none";
return this.keyProcessed(event);
}
// hide list if quiet, or below input minimum (and not showlist)
list.style.display=(!showlist&&(quiet||here.value.length<config.options.txtIncrementalSearchMin))?'none':'block';
// non-blank input... enter=show/create tiddler, SHIFT-enter=search for text
if (key==13 && here.value.length) return this.processItem(event.shiftKey?'*':here.value,here,list,showlist);
// up or down key, or enter with blank input... shows and moves to list...
if (key==38 || key==40 || key==13) { list.style.display="block"; list.focus(); }
this.fillList(list,here.value,filter.value,search,key);
return true; // key bubbles up
},
selectKeyHandler:
function(event,list,editfield,showlist) {
if (event.keyCode==27) // escape... hide list, move to edit field
{ editfield.focus(); list.style.display=showlist?'block':'none'; return this.keyProcessed(event); }
if (event.keyCode==13 && list.value.length) // enter... view selected item
{ this.processItem(list.value,editfield,list,showlist); return this.keyProcessed(event); }
return true; // key bubbles up
},
processItem:
function(title,here,list,showlist) {
if (!title.length) return;
list.style.display=showlist?'block':'none';
if (title=="*") { story.search(here.value); return false; } // do full-text search
if (!showlist) here.value=title;
story.displayTiddler(null,title); // show selected tiddler
return false;
}
}
//}}}
/***
|Name|GotoPluginInfo|
|Source|http://www.TiddlyTools.com/#GotoPlugin|
|Documentation|http://www.TiddlyTools.com/#GotoPluginInfo|
|Version|1.9.2|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|documentation|
|Description|Documentation for GotoPlugin|
''View a tiddler by typing its title and pressing //enter//.'' As you type, a list of possible matches is displayed. You can scroll-and-click (or use arrows+enter) to select/view a tiddler, or press escape to close the listbox to resume typing. When the listbox is not displayed, pressing //escape// clears the current input.
!!!!!Usage/Examples
<<<
syntax: {{{<<gotoTiddler quiet search inputstyle:... liststyle:... filter:...>>}}}
All parameters are optional.
* ''quiet'' (//keyword//)<br>list will not be automatically display as each character is typed. Use //down// or //enter// to view the list.
* ''showlist'' (//keyword//)<br>list will always be displayed, inline, directly below the input field.
* ''search'' (//keyword//)<br>adds an extra 'command item' to the list that can be used to invoke a full-text search using the entered value. This can be especially useful when no matching tiddler titles have been found.
* ''inputstyle:'' and ''liststyle:''<br>are CSS declarations that modify the default input and listbox styles, respectively. Note: the CSS styles must be surrounded by ({{{"..."}}} or {{{'...'}}}) or ({{{[[...]]}}}) (e.g., {{{liststyle:"border:1px dotted blue;color:green;..."}}}.
* ''filter:''<br>is a single tag value (or a boolean tag expression if MatchTagsPlugin is installed), and is used to limit the search to only those tiddlers matching the indicated tag or tag expression (e.g., {{{<<gotoTiddler filter:"faq or help">>}}})
{{{<<gotoTiddler>>}}}
<<gotoTiddler>>
{{{<<gotoTiddler search>>}}}
<<gotoTiddler search>>
{{{<<gotoTiddler showlist filter:"pluginInfo" liststyle:"height:10em;width:auto;">>}}}
<<gotoTiddler showlist filter:"pluginInfo" liststyle:"height:10em;width:auto;">>
<<<
!!!!!Configuration
<<<
*Match titles only after {{twochar{<<option txtIncrementalSearchMin>>}}} or more characters are entered.<br>Use down-arrow to start matching with shorter input. //Note: This option value is also set/used by [[SearchOptionsPlugin]]//.
*To set the maximum height of the listbox, you can create a tiddler tagged with <<tag systemConfig>>, containing:
//{{{
config.macros.gotoTiddler.listMaxSize=10; // change this number
//}}}
<<<
!!!!!Revisions
<<<
2009.05.22 1.9.2 use reverseLookup() for IncludePlugin
2009.04.12 1.9.1 support multiple instances with different filters by using per-element tiddler cache instead of shared static cache
2009.04.05 1.9.0 added 'showlist' parameter for inline display with listbox always visible.
2009.03.23 1.8.0 added txtIncrementalSearchMin (default=3). Avoids fetching long lists. Use down arrow to force search with short input.
2008.12.15 1.7.1 up arrow from input field now moves to end of droplist (search for input). Also, shift+enter cam now be used to quickly invoke search for text.
2008.10.16 1.7.0 in macro handler(), changed to use //named// params instead of positional params, and added optional "filter:" param for tag filtering. Removed 'insert' handling (now provided by [[QuickEditPlugin]]).
2008.10.02 1.6.1 for IE, wrap controls in a table. Corrects placement of listbox so it is below input field.
2008.10.02 1.6.0 added 'search' param for optional "Search for:" item that invokes full text search (especially useful when no title matches are found)
2008.02.17 1.5.0 ENTER key always displays tiddler based on current input regardless of whether input matches any existing tiddler
2007.10.31 1.4.3 removed extra trailing comma on last property of config.macros.gotoTiddler object. This fixes an error under InternetExplorer that was introduced 6 days ago... sure, I should have found it sooner, but... WHY DON'T PEOPLE TELL ME WHEN THINGS ARE BROKEN!!!!
2007.10.25 1.4.2 added onclick handler for input field, so that clicking in field hides the listbox.
2007.10.25 1.4.1 re-wrote getItems() to cache list of tiddlers/shadows/tags and use case-folded simple text match instead of regular expression to find matching tiddlers. This *vastly* reduces processing overhead between keystrokes, especially for documents with many (>1000) tiddlers. Also, removed local definition of replaceSelection(), now supported directly by the TW2.2+ core, as well as via backward-compatible plugin
2007.04.25 1.4.0 renamed macro from "goto" to "gotoTiddler". This was necessary to avoid a fatal syntax error in Opera (and other browsers) that require strict adherence to ECMAScript 1.5 standards which defines the identifier "goto" as "reserved for FUTURE USE"... *sigh*
2007.04.21 1.3.2 in html definition, removed DIV around droplist (see 1.2.6 below). It created more layout problems then it solved. :-(
2007.04.01 1.3.1 in processItem(), ensure that correct textarea field is found by checking for edit=="text" attribute
2007.03.30 1.3.0 tweak SideBarOptions shadow to automatically add {{{<<goto>>}}} when using default sidebar content
2007.03.30 1.2.6 in html definition, added DIV around droplist to fix IE problem where list appears next to input field instead of below it.
2007.03.28 1.2.5 in processItem(), set focus to text area before setting selection (needed for IE to get correct selection 'range')
2007.03.28 1.2.4 added prompt for 'pretty text' when inserting a link into tiddler content
2007.03.28 1.2.3 added local copy of core replaceSelection() and modified for different replace logic
2007.03.27 1.2.2 in processItem(), use story.getTiddlerField() to retrieve textarea control
2007.03.26 1.2.1 in html, use either 'onkeydown' (IE) or 'onkeypress' (Moz) event to process <esc> key sooner, to prevent <esc> from 'bubbling up' to the tiddler (which will close the current editor).
2007.03.26 1.2.0 added support for optional "insert" keyword param.
2006.05.10 1.1.2 when filling listbox, set selection to 'heading' item... auto-select first tiddler title when down/enter moves focus into listbox
2006.05.08 1.1.1 added accesskey ("G") to input field html (also set when field gets focus). Also, inputKeyHandler() skips non-printing/non-editing keys.
2006.05.08 1.1.0 added heading to listbox for better feedback (also avoids problems with 1-line droplist)
2006.05.07 1.0.0 list matches against tiddlers/shadows/tags. input field auto-completion... 1st enter=complete matching input (or show list)... 2nd enter=view tiddler. "quiet" param controls when listbox appears. handling for enter (13), escape(27), and down(40) keys. Change 'ondblclick' to 'onclick' to avoid unintended triggering of tiddler editor). Shadow titles inserted into list instead of appended to the end.
2006.05.05 0.0.0 started
<<<
/***
|''Name''|GroupByPlugin|
|''Description''|Mimics allTags macro to provide ways of creating lists grouping tiddlers by any field|
|''Version''|0.6.1|
|''Author''|Jon Robson|
|''Status''|beta|
!Usage
{{{<<groupBy tags>>}}}
mimics allTags macro
{{{<<groupBy server.bag>>}}}
groups by the server.bag field (this version contains TiddlySpace specific code for turning a bag into a space name)
{{{groupBy modified dateFormat:"YYYY"}}}
group tiddlers by year.
{{{<<groupBy tags exclude:excludeLists exclude:systemConfig>>}}}
group tiddlers by tag but exclude the tags with values excludeLists and systemConfig
Within that group you can also exclude things by filter
{{{groupBy modifier filter:[tag[film]]}}}
will group tiddlers tagged with film by modifier.
***/
//{{{
(function($) {
var taglocale = config.views.wikified.tag;
var macro = config.macros.groupBy = {
locale: {
tooltip: "all tiddlers in group %0",
noTiddlers: "no tiddlers",
openAllText: taglocale.openAllText,
openAllTooltip: taglocale.openAllTooltip,
openTiddler: "open tiddler with title %0"
},
morpher: {
// TODO: note currently the following 2 morphers are TiddlySpace specific and probably should be in separate plugin
"server.workspace": function(value, options) {
return macro.morpher["server.bag"](value.replace("bags/", "").replace("recipes/", ""));
},
"server.bag": function(value, options) {
if(typeof(value) !== "string") {
return false;
} else if(value.indexOf("_public") === -1 && value.indexOf("_private") === -1) {
value = "*%0".format(value); // add star for non-space bags.
}
return value.replace("_public", "").replace("_private", "");
},
created: function(value, options) {
return value.formatString(options.dateFormat || "DD MMM YYYY");
},
modified: function(value, options) {
return macro.morpher.created(value, options);
}
},
handler: function(place, macroName, params, wikifier, paramString) {
var field = params[0] || "server.workspace";
var dateFormat = params[1] || "DD MMM YYYY";
var container = $("<div />").attr("macroName", macroName).addClass("groupBy").
attr("refresh", "macro").attr("fieldName", field).
attr("paramString", paramString).
attr("dateFormat", dateFormat).appendTo(place)[0];
macro.refresh(container);
},
isTypeArray: function(value) {
var valueType = typeof value;
if(valueType === "object" && typeof value.length === "number" &&
!(value.propertyIsEnumerable("length")) &&
typeof value.splice === "function") { //is Array
return true;
} else {
return false;
}
},
_onClickGroup: function(ev, options) {
var i, target = ev.target, locale = macro.locale;
var tiddlers = $(target).closest(".templateContainer").data("tiddlers");
var popup = $(Popup.create(target)).addClass("taggedTiddlerList")[0];
var value = $(target).attr("value");
var openAll = createTiddlyButton($("<li />").appendTo(popup)[0],
locale.openAllText.format(value), locale.openAllTooltip);
$(openAll).click(function(ev) {
story.displayTiddlers(ev.target, tiddlers);
return false;
});
var listBreak = $("<li />").addClass("listBreak").html("<div />").appendTo(popup);
for(i = 0; i < tiddlers.length; i++) {
var item = $("<li />").appendTo(popup)[0];
var template = store.getTiddlerText(options.template) || macro.template;
wikify(template, item, null, tiddlers[i]);
}
listBreak.clone().appendTo(popup);
$(createTiddlyLink($("<li />").appendTo(popup)[0], value, false)).
text(locale.openTiddler.format(value));
Popup.show();
ev.stopPropagation();
return false;
},
_refresh: function(container, tiddlers, options) {
var totalGroups = 0, locale = macro.locale, i, j;
var excludeValues = options.exclude;
var values = {}, value_ids = [];
var field = options.field;
var morpher = macro.morpher[field] || function(value) {
return value;
};
for(i = 0; i < tiddlers.length; i++) {
var tiddler = tiddlers[i];
var value = tiddler[field] || tiddler.fields[field];
value = macro.isTypeArray(value) ? value : [ value ];
for(j = 0; j < value.length; j++) {
var v = morpher(value[j], options);
if(v && $.inArray(v, excludeValues) === -1) {
totalGroups += 1;
if(!values[v]) {
values[v] = [];
}
values[v].push(tiddler);
value_ids.pushUnique(v);
}
}
}
var ul = $("<ul />").appendTo(container)[0];
if(totalGroups === 0) {
$("<li />").addClass("listTitle").text(locale.noTiddlers);
}
value_ids = value_ids.sort();
var groupTemplate = store.getTiddlerText(options.groupTemplate);
var onClick = function(ev) {
macro._onClickGroup(ev, options);
};
for(i = 0; i < value_ids.length; i++) {
var title = value_ids[i];
var info = getTiddlyLinkInfo(title);
tiddlers = values[title];
var btn = createTiddlyButton($("<li />").appendTo(ul)[0],
"%0 (%1)".format(title, tiddlers.length), locale.tooltip.format(title), null, info.classes);
if(groupTemplate) {
$(btn).empty();
wikify(groupTemplate, btn, null, tiddlers[0]);
}
$(btn).click(onClick).attr("value", title).attr("refresh", "link").attr("tiddlyLink", title);
$(btn).addClass("templateContainer").data("tiddlers", tiddlers);
}
},
refresh: function(container) {
container = $(container).empty();
var paramString = container.attr("paramString");
var args = paramString.parseParams("name", null, true, false, true)[0];
var options = { field: container.attr("fieldName"), dateFormat: container.attr("dateFormat"), exclude: args.exclude || [],
template: args.template ? args.template[0] : false, groupTemplate: args.groupTemplate ? args.groupTemplate[0] : "" };
var tiddlers = args.filter ? store.filterTiddlers(args.filter[0]) : store.getTiddlers("title");
macro._refresh(container, tiddlers, options);
},
template: "<<view title link>>"
};
}(jQuery));
//}}}
<<TiddlyTagMindMap filter:[tag[Guideline]] vizType:rgraph id:Guideline nodeSize:5 nodeType:ellipse nodeHoverColor:'#ee00ff' nodeColor:"#ff0000" edgeColor:'#ccc' edgeWidth:2 width:750 height:480 template:NodeTemplate>>
----
/%
@@color:#c4d6ed; ^^
Description: TODO
^^@@
%/
A collection of practical development guidelines.
|Guideline|h
|<<list filter [tag[Guideline]]>>|
----
@@color:#c4d6ed; ^^
Description: A collection of practical development guidelines.
^^@@
"//''For every complex problem, there is a solution that is simple, neat, and wrong.''//"
[[Henry Louis Mencken|http://en.wikipedia.org/wiki/H._L._Mencken]] (1880 - 1956)
High Maturity Practices are one of the main factors to distinguish professional development from amateur one.
*[[Configuration Management]] ([[CM]]) is essential! No professional development may be carried out without it.
*[[Continuous Integration]] ([[CI]]) is important in any team with more than zero elements.
*[[Static Analysis]] is, probably, the simplest practice to implement and that can, immediately, have a big return on your code quality. Think about having one hundred of the best programmers inspecting your code...
*[[Unit Testing]] overemphasised but nevertheless an excellent quality tool.
*[[Peer Review]] essential if a quality standard is to be maintained.
*[[Systematic Reuse]] is a major quality and productivity factor.
*[[Issue Management]] is essential to cope with complexity.
----
@@color:#c4d6ed; ^^
Description: Reference of practices that distinguish professional development from amateur one.
^^@@
!Welcome to André de Carvalho's Wiki home page.
I'm involved with [[Software Development]] since the 80's and have worked from Turbo Pascal (3.01a), Clipper and Fox Pro (on SCO Xenix ;), through Delphi and now I mostly use C#.
I'm clearly a data-oriented ~WinForms guy that hates to "//program in XML//" and has not too much patience for browser limitations.
Maybe I'm old fashioned but I do like good conceptual data models ( [[Sybase|http://www.sybase.com/]] [[Power Designer|http://www.sybase.com/products/modelingdevelopment/powerdesigner]] is my tool), the challenge of investigating a business problem and produce an elegant object oriented architectural solution ( [[Sparx Enterprise Architect]] is essential) and then to implement a robust and performance wise application that is expandable and reusable.
Wikis, and especially [[TiddlyWiki|http://www.tiddlywiki.com/]], were the first browser application that really interested me and this site is my personal site devoted mainly to [[Software Development]] although some other topics are also present. Hope You enjoy and find it useful.
----
This is now hosted for free by [[TiddlyHost|https://tiddlyhost.com]]. If You find this useful and want to contribute to ~TiddlyHost You can make a donation at [[TiddlyHost donation|https://tiddlyhost.com/donate]], its well deserved!
If You are wandering why is this still in [[TiddlyWiki Classic|https://classic.tiddlywiki.com/]] see [[Things I really miss in TW5|https://missingintw5.tiddlyhost.com/]].
----
!Last content updates
|Last 5 tiddlers created|Last 5 tiddlers modified|h
|<<ContentTimeline created 5>>|<<ContentTimeline modified 5>>|
See more in [[Last Updates|LastUpdates]]
--__You may subscribe an RSS feed for this site in [[this link|http://acarvalho.tiddlyspot.com/index.xml]].__--
!Tagcloud
<<tagCloud excludeLists excludeSearch systemConfig systemServer PluginInfo Plugin excludeMissing excludePublisher takenotepackage app DiscoveryPackage NavigationPackage IconPackage TidIDEPackage TaskPackage ScrollbarPackage MediaPackage pluginInfo @cdent @developers @ricardoperes Administration follow tips Content System systemConfigDisable>>
''Also check TagPolicy for a resume of the more important subject tags used in this space. They can help you navigate the information.''
!~TiddliWiki
''
~TiddliWiki is a __non linear structure__, that is, there is not a fixed order to read its contents. For instance, if you are interested in my thoughts about [[Software Development]] you shall get to that tiddler then close all other opened tiddlers and start reading. You will find links to other tiddlers (concept definitions or detailed information about referred topics). If you hoover over links you will see a short description of its content, if you click it will open, you can read and then close it to go back to your main topic.
If you are new to ~TiddlyWiki my advice is that you keep only two tiddlers opened at the same time : your main topic one and the one that you followed to, when finished reading the second close it.
Be sure to explore the tiddler menu functionality and the tags also.
A note about most images in this site : if you ~Shift-Click on them they will zoom to their original (bigger) size.
If you are not comfortable with multiple tiddler navigation you may check <<option chkEnableTabsBar>> __Tabbed navigation__ or tune other DisplayOptions in this space.
--The last line of each tiddler let you comment and see commentaries on that tiddler. Comments are moderated so be patient, I'll do it ASAP.--
''
!General
You may also be interested in other [[Sites I Like]] or in [[Development Links]]
----
I may be contacted on ''Gmail'' as //andre.d.a.carvalho//.
----
!Privacy statement
This site uses Google Analytics through [[GATrackerPlugin|http://suiryc.github.io/TiddlyWiki-dev/#GATrackerPlugin]]. You may disable tracking by using [[NoScript|https://noscript.net/]] Firefox plugin and not authorizing //google-analytics.com//.
This site uses a counter from [[https://www.simple-counter.com]]
This site uses a counter from [[https://info.flagcounter.com]]
--This site uses a counter from [[www.simplehitcounter.com|http://www.simplehitcounter.com/]]--
--This site uses [[Discus|https://disqus.com]] as it commentaries engine.--
----
@@color:#c4d6ed; ^^
Description: The main entry point in this wiki.
^^@@
<<top>>
<<jump j '' top>>
<<toggleSideBar>><<renameButton '>' >>
<<fullscreen>><<renameButton ↕ 'Full Screen'>>
<<newTiddler>><<renameButton n>>
<<thostUpload>><<renameButton s 'Save TiddlyWiki'>>
/***
|Name|HoverMenuPlugin|
|Created by|SaqImtiaz|
|Location|http://tw.lewcid.org/#HoverMenuPlugin|
|Version|1.11|
|Requires|~TW2.x|
!Description:
Provides a hovering menu on the edge of the screen for commonly used commands, that scrolls with the page.
!Demo:
Observe the hovering menu on the right edge of the screen.
!Installation:
Copy the contents of this tiddler to your TW, tag with systemConfig, save and reload your TW.
To customize your HoverMenu, edit the HoverMenu shadow tiddler.
To customize whether the menu sticks to the right or left edge of the screen, and its start position, edit the HoverMenu configuration settings part of the code below. It's well documented, so don't be scared!
The menu has an id of hoverMenu, in case you want to style the buttons in it using css.
!Notes:
Since the default HoverMenu contains buttons for toggling the side bar and jumping to the top of the screen and to open tiddlers, the ToggleSideBarMacro, JumpMacro and the JumpToTopMacro are included in this tiddler, so you dont need to install them separately. Having them installed separately as well could lead to complications.
If you dont intend to use these three macros at all, feel free to remove those sections of code in this tiddler.
!To Do:
* rework code to allow multiple hovering menus in different positions, horizontal etc.
* incorporate code for keyboard shortcuts that correspond to the buttons in the hovermenu
!History:
*03-08-06, ver 1.1.2: compatibility fix with SelectThemePlugin
*03-08-06, ver 1.11: fixed error with button tooltips
*27-07-06, ver 1.1 : added JumpMacro to hoverMenu
*23-07-06
!Code
***/
/***
start HoverMenu plugin code
***/
//{{{
config.hoverMenu={};
//}}}
/***
HoverMenu configuration settings
***/
//{{{
config.hoverMenu.settings={
align: 'right', //align menu to right or left side of screen, possible values are 'right' and 'left'
x: 1, // horizontal distance of menu from side of screen, increase to your liking.
y: 158 //vertical distance of menu from top of screen at start, increase or decrease to your liking
};
//}}}
//{{{
//continue HoverMenu plugin code
config.hoverMenu.handler=function()
{
if (!document.getElementById("hoverMenu"))
{
var theMenu = createTiddlyElement(document.getElementById("contentWrapper"), "div","hoverMenu");
theMenu.setAttribute("refresh","content");
theMenu.setAttribute("tiddler","HoverMenu");
var menuContent = store.getTiddlerText("HoverMenu");
wikify(menuContent,theMenu);
}
var Xloc = this.settings.x;
Yloc =this.settings.y;
var ns = (navigator.appName.indexOf("Netscape") != -1);
function SetMenu(id)
{
var GetElements=document.getElementById?document.getElementById(id):document.all?document.all[id]:document.layers[id];
if(document.layers)GetElements.style=GetElements;
GetElements.sP=function(x,y){this.style[config.hoverMenu.settings.align]=x +"px";this.style.top=y +"px";};
GetElements.x = Xloc;
GetElements.y = findScrollY();
GetElements.y += Yloc;
return GetElements;
}
window.LoCate_XY=function()
{
var pY = findScrollY();
ftlObj.y += (pY + Yloc - ftlObj.y)/15;
ftlObj.sP(ftlObj.x, ftlObj.y);
setTimeout("LoCate_XY()", 10);
}
ftlObj = SetMenu("hoverMenu");
LoCate_XY();
};
window.old_lewcid_hovermenu_restart = restart;
restart = function()
{
window.old_lewcid_hovermenu_restart();
config.hoverMenu.handler();
};
setStylesheet(
"#hoverMenu .imgLink, #hoverMenu .imgLink:hover {border:none; padding:0px; float:right; margin-bottom:2px; margin-top:0px;}\n"+
"#hoverMenu .button, #hoverMenu .tiddlyLink {border:none; font-weight:bold; background:#18f; color:#FFF; padding:0 5px; float:right; margin-bottom:4px;}\n"+
"#hoverMenu .button:hover, #hoverMenu .tiddlyLink:hover {font-weight:bold; border:none; color:#fff; background:#000; padding:0 5px; float:right; margin-bottom:4px;}\n"+
"#hoverMenu .button {width:100%; text-align:center}"+
"#hoverMenu { position:absolute; width:7px;}\n"+
"\n","hoverMenuStyles");
config.macros.renameButton={};
config.macros.renameButton.handler = function(place,macroName,params,wikifier,paramString,tiddler)
{
if (place.lastChild.tagName!="BR")
{
place.lastChild.firstChild.data = params[0];
if (params[1]) {place.lastChild.title = params[1];}
}
};
config.shadowTiddlers["HoverMenu"]="<<top>>\n<<toggleSideBar>><<renameButton '>' >>\n<<jump j '' top>>\n<<saveChanges>><<renameButton s 'Save TiddlyWiki'>>\n<<newTiddler>><<renameButton n>>\n";
//}}}
//end HoverMenu plugin code
//Start ToggleSideBarMacro code
//{{{
config.macros.toggleSideBar={};
config.macros.toggleSideBar.settings={
styleHide : "#sidebar { display: none;}\n"+"#contentWrapper #displayArea { margin-right: 1em;}\n"+"",
styleShow : " ",
arrow1: "«",
arrow2: "»"
};
config.macros.toggleSideBar.handler=function (place,macroName,params,wikifier,paramString,tiddler)
{
var tooltip= params[1]||'toggle sidebar';
var mode = (params[2] && params[2]=="hide")? "hide":"show";
if (!params[2])
mode = "hide";
var arrow = (mode == "hide")? this.settings.arrow1:this.settings.arrow2;
var label= (params[0]&¶ms[0]!='.')?params[0]+" "+arrow:arrow;
var theBtn = createTiddlyButton(place,label,tooltip,this.onToggleSideBar,"button HideSideBarButton");
if (mode == "hide")
{
(document.getElementById("sidebar")).setAttribute("toggle","hide");
setStylesheet(this.settings.styleHide,"ToggleSideBarStyles");
}
};
config.macros.toggleSideBar.onToggleSideBar = function(){
var sidebar = document.getElementById("sidebar");
var settings = config.macros.toggleSideBar.settings;
if (sidebar.getAttribute("toggle")=='hide')
{
setStylesheet(settings.styleShow,"ToggleSideBarStyles");
sidebar.setAttribute("toggle","show");
this.firstChild.data= (this.firstChild.data).replace(settings.arrow1,settings.arrow2);
}
else
{
setStylesheet(settings.styleHide,"ToggleSideBarStyles");
sidebar.setAttribute("toggle","hide");
this.firstChild.data= (this.firstChild.data).replace(settings.arrow2,settings.arrow1);
}
return false;
}
setStylesheet(".HideSideBarButton .button {font-weight:bold; padding: 0 5px;}\n","ToggleSideBarButtonStyles");
//}}}
//end ToggleSideBarMacro code
//start JumpToTopMacro code
//{{{
config.macros.top={};
config.macros.top.handler=function(place,macroName)
{
createTiddlyButton(place,"^","jump to top",this.onclick);
}
config.macros.top.onclick=function()
{
window.scrollTo(0,0);
};
config.commands.top =
{
text:" ^ ",
tooltip:"jump to top"
};
config.commands.top.handler = function(event,src,title)
{
window.scrollTo(0,0);
}
//}}}
//end JumpToStartMacro code
//start JumpMacro code
//{{{
config.macros.jump= {};
config.macros.jump.handler = function (place,macroName,params,wikifier,paramString,tiddler)
{
var label = (params[0] && params[0]!=".")? params[0]: 'jump';
var tooltip = (params[1] && params[1]!=".")? params[1]: 'jump to an open tiddler';
var top = (params[2] && params[2]=='top') ? true: false;
var btn =createTiddlyButton(place,label,tooltip,this.onclick);
if (top==true)
btn.setAttribute("top","true")
}
config.macros.jump.onclick = function(e)
{
if (!e) var e = window.event;
var theTarget = resolveTarget(e);
var top = theTarget.getAttribute("top");
var popup = Popup.create(this);
if(popup)
{
if(top=="true")
{createTiddlyButton(createTiddlyElement(popup,"li"),'Top ↑','Top of TW',config.macros.jump.top);
createTiddlyElement(popup,"hr");}
story.forEachTiddler(function(title,element) {
createTiddlyLink(createTiddlyElement(popup,"li"),title,true);
});
}
Popup.show(popup,false);
e.cancelBubble = true;
if (e.stopPropagation) e.stopPropagation();
return false;
}
config.macros.jump.top = function()
{
window.scrollTo(0,0);
}
//}}}
//end JumpMacro code
//utility functions
//{{{
Popup.show = function(unused,slowly)
{
var curr = Popup.stack[Popup.stack.length-1];
var rootLeft = findPosX(curr.root);
var rootTop = findPosY(curr.root);
var rootHeight = curr.root.offsetHeight;
var popupLeft = rootLeft;
var popupTop = rootTop + rootHeight;
var popupWidth = curr.popup.offsetWidth;
var winWidth = findWindowWidth();
if (isChild(curr.root,'hoverMenu'))
var x = config.hoverMenu.settings.x;
else
var x = 0;
if(popupLeft + popupWidth+x > winWidth)
popupLeft = winWidth - popupWidth -x;
if (isChild(curr.root,'hoverMenu'))
{curr.popup.style.right = x + "px";}
else
curr.popup.style.left = popupLeft + "px";
curr.popup.style.top = popupTop + "px";
curr.popup.style.display = "block";
addClass(curr.root,"highlight");
if(config.options.chkAnimate)
anim.startAnimating(new Scroller(curr.popup,slowly));
else
window.scrollTo(0,ensureVisible(curr.popup));
}
window.isChild = function(e,parentId) {
while (e != null) {
var parent = document.getElementById(parentId);
if (parent == e) return true;
e = e.parentNode;
}
return false;
};
//}}}
http://htmljs.tiddlyspace.com/jquery.js
http://htmljs.tiddlyspace.com/htmljs-wikiupgrade.js
http://htmljs.tiddlyspace.com/htmljs-disqus
Integrated Development Environement
----
/%
@@color:#c4d6ed; ^^
Description: Integrated Development Environement
^^@@
%/
/***
|Name|ImageMacro|
|Created by|Andre' de Carvalho|
|Location|http://acarvalho.tiddlyspace.com/#ImageMacro|
|Version|1.1.1|
|Date|2021 06 18|
|Type|Macro|
|Description|A TiddlyWiki Macro to create configurable links to images.|
/%
Version history :
1.1.1 2021 06 18 : Corrected documentation
1.1.0 2013 05 10 : handling null parameters
%/
!!Example
<<Image "FL" "200" "Coupling-root-level.png" "https://dl.dropbox.com/" "s/vfki4dkx343k4ut/" "?dl=1" "Root level allowed dependencies.">>
{{{
<<Image "FL" "200" "Coupling-root-level.png" "https://dl.dropbox.com/" "s/vfki4dkx343k4ut/" "?dl=1" "Root level allowed dependencies.">>
}}}
or
<<Image "FR" "200" "Coupling-root-level.png" "https://dl.dropbox.com/" "s/vfki4dkx343k4ut/" "?dl=1" "Root level allowed dependencies.">>
{{{
<<Image "FR" "200" "Coupling-root-level.png" "https://dl.dropbox.com/" "s/vfki4dkx343k4ut/" "?dl=1" "Root level allowed dependencies.">>
}}}
or
<<Image "" "" "Coupling-root-level.png" "https://dl.dropbox.com/" "s/vfki4dkx343k4ut/" "?dl=1" "Root level allowed dependencies.">>
{{{
<<Image "" "" "Coupling-root-level.png" "https://dl.dropbox.com/" "s/vfki4dkx343k4ut/" "?dl=1" "Root level allowed dependencies.">>
}}}
!!Installation
Import (or copy/paste) this tiddler into your document and tag it with "systemConfig". For using size you need [[ImageSizePlugin| http://www.TiddlyTools.com/#ImageSizePlugin]].
!!Code
***/
//{{{
version.extensions.Image= {major: 1, minor: 1 , revision: 1, date: new Date(2021,06,18)};
//Created by André de Carvalho
//}}}
//{{{
config.macros.Image = {};
config.macros.Image.handler= function(place,macroName,params) {
/* Type : FL = float left, FR = float right, "" = no float */
var type=params[0];
/* Size : number = pixels (requires ImageSizePlugin), "" = no size */
var size=params[1];
/* Name : the name of the image file */
var name=params[2];
/* Path : the path of the image file (include end backslash) */
var path = params[3];
/* Prefix : optional prefix to be inserted between Path and FileName */
var prefix = params[4];
/* Postfix : optional postfix to be appended after FileName */
var postfix = params[5];
/* Caption : optional caption */
var caption = params[6];
var ini = "";
var end = "";
if (caption)
{
caption = "<br>@@padding:0.8em;@@@@color:#00f;^^"+caption+"^^@@";
}
else
{
caption = "";
}
switch(type)
{
case "FR":
ini = "{{imgfloatright{[img";
end = "]]"+caption+"}}}";
break;
case "FL":
ini = "{{imgfloatleft{[img";
end = "]]"+caption+"}}}";
break;
default:
ini="[img";
end = "]]";
}
if (size)
ini = ini + "("+size+"px+,+)";
ini = ini+"[";
if (path)
ini = ini+ path;
if (prefix)
ini = ini+ prefix;
if (name)
ini = ini+ name;
if (postfix)
ini = ini+ postfix;
wikify(ini+end, place)
};
//}}}
/***
|''Name''|ImageMacroPlugin|
|''Version''|0.9.4|
|''Description''|Allows the rendering of svg images in a TiddlyWiki|
|''Author''|Osmosoft|
|''License''|[[BSD|http://www.opensource.org/licenses/bsd-license.php]]|
|''Notes''|Currently only works in modern browsers (not IE)|
|''Requires''|BinaryTiddlersPlugin|
!Usage
{{{<<image SVG>>}}} will render the text of the tiddler with title SVG as an SVG image (but not in ie where it will fail silently)
!!Parameters
width/height: specify width/height parameters
link: make the image link to a given location
tiddlyLink: link to a tiddler
!Notes
Binary tiddlers in TiddlyWeb when passed through the wikifier will be shown as images.
eg. {{{<<view text wikified>>}}} on a binary tiddler will show the image.
{{{<<view fieldname image>>}}}
will render the value of the tiddler field 'fieldname' as an image. This field can contain a tid
{{{<<image SiteIcon>>}}}
will create an image tag where the tiddler has content type beginning image and not ending +xml
will attempt to create svg object in other scenarios
{{{<<image /photos/x.jpg>>}}}
will create an image tag with src /photos/x.jpg as long as there is not a tiddler called /photos/x.jpg in
which case it will render that tiddler as an image. Note for the case of svg files it will attempt to render as an svg if possible via the image
tag. It doesn't embed the svg in the dom for security reasons as svg code can contain javascript.
!Code
***/
//{{{
(function($) {
var macro = config.macros.image = {
shim: "/bags/common/tiddlers/shim",
ieVersion: config.browser.isIE ? parseInt(config.browser.ieVersion[1], 10) : false,
svgns: "http://www.w3.org/2000/svg",
xlinkns: "http://www.w3.org/1999/xlink",
svgAvailable: document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#BasicStructure", "1.1"),
_fixPrefix: 1,
_external_cache: {},
_image_tag_cache: {},
_image_dimensions: {},
locale: {
badImage: "This image cannot be displayed."
},
handler: function(place, macroName, params, wikifier, paramString, tiddler){
var imageSource = params[0];
// collect named arguments
var args = macro.getArguments(paramString, params);
this.renderImage(place, imageSource, args);
},
init: function() {
var startupImages = store.getTaggedTiddlers("systemImage");
var place = $("<div />").attr("id", "systemImageArea").appendTo("body").hide()[0];
for(var i = 0; i < startupImages.length; i++) {
var image = startupImages[i];
macro.renderImage(place, image.title, { idPrefix: "" });
}
var data = new Image();
data.onload = function() {
// note ie 8 only supports data uris up to 32k so cannot be relied on
macro.supportsDataUris = this.width != 1 || this.height != 1 ? false : true;
macro.supportsDataUris = macro.ieVersion && macro.ieVersion < 9 ? false : macro.supportsDataUris;
};
data.onerror = data.onload;
data.src = "data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///ywAAAAAAQABAAACAUwAOw==";
},
refreshImage: function(src) {
var elements = macro._image_tag_cache[src] ? macro._image_tag_cache[src] : [];
if(macro._image_dimensions[src]) {
macro._image_dimensions[src] = false;
}
for(var i = 0; i < elements.length; i++) {
var el = $(elements[i]);
var newSrc = "%0?nocache=%1".format(src, Math.random());
el.attr("src", newSrc); // force reload
}
},
isBinaryImageType: function(contentType) {
return (contentType && contentType.indexOf("image") === 0 &&
contentType.indexOf("+xml") != contentType.length - 4) ? true : false;
},
isImageTiddler: function(tiddler) {
return macro.isSVGTiddler(tiddler) || macro.isBinaryImageTiddler(tiddler);
},
isSVGTiddler: function(tiddler) {
var type = tiddler ? tiddler.fields['server.content-type'] : false;
return type == "image/svg+xml";
},
isBinaryImageTiddler: function(tiddler) {
return macro.isBinaryImageType(tiddler.fields['server.content-type']);
},
renderImage: function(place, imageSource, options) {
var imageTiddler = store.getTiddler(imageSource);
var container;
var classes = ["image"];
if(options.link) {
classes = classes.concat(["imageLink", "externalLink"]);
container = $("<a />").attr("href", options.link).appendTo(place)[0];
} else if(options.tiddlyLink) {
classes.push("imageLink");
container = createTiddlyLink(place, options.tiddlyLink, false);
} else {
container = $("<span />").appendTo(place)[0];
}
$(container).addClass(classes.join(" "));
options = options ? options : {};
if(imageTiddler && macro.isBinaryImageTiddler(imageTiddler)) { // handle the case where we have an image url
return macro._renderBinaryImageTiddler(container, imageTiddler, options);
} else if(imageTiddler){ // handle the case where we have a tiddler
return macro._renderSVGTiddler(container, imageTiddler, options);
} else { // we have a string representing a url
return macro._renderBinaryImageUrl(container, imageSource, options);
}
},
_renderAlternateText: function(container, options) {
var img;
var src = options.src || "";
if(options.width && options.height) {
img = $("<img />").attr("src", src).addClass("svgImageText").attr("width", options.width).
attr("height", options.height).appendTo(container);
}
var alt = options.alt;
if(img && alt) {
img.attr("alt", alt).attr("title", alt);
} else if(alt) {
$(container).addClass("svgImageText").text(alt);
}
macro._image_tag_cache[src] = img;
},
_renderSVGTiddler: function(place, tiddler, options) {
if(!options) {
options = {};
}
merge(options, { tiddler: tiddler, fix: true});
if(macro.svgAvailable) {
this._importSVG(place, options); // display the svg
} else if(options.altImage) {
var image = options.altImage;
delete options.altImage;
this._renderBinaryImageUrl(place, image, options);
} else {
this._renderAlternateText(place, options); // instead of showing the image show the alternate text.
}
},
_renderBinaryImageTiddler: function(place, tiddler, options) {
var resourceURI;
var fields = tiddler.fields;
if(fields["server.type"] == "tiddlyweb") { // construct an accurate url for the resource
resourceURI = "%0/%1/tiddlers/%2".format(config.defaultCustomFields["server.host"],
fields["server.workspace"], encodeURI(fields["server.title"]));
} else { // guess the url for the resource
resourceURI = tiddler.title;
}
var ctype = fields["server.content-type"] || tiddler.type;
var text = tiddler.text;
if(macro.supportsDataUris && ctype && text.indexOf("<html") == -1) {
var uri = "data:%0;base64,%1".format(ctype, text);
options.src = resourceURI;
return macro._renderBinaryImageUrl(place, uri, options);
} else if(options.src) {
return macro._renderBinaryImageUrl(place, options.src, options);
} else {
return macro._renderBinaryImageUrl(place, resourceURI, options);
}
},
_renderImageTag: function(container, src, width, height, options) {
var img;
img = $("<img />").appendTo(container);
if(height) {
img.attr("height", height);
}
if(width) {
img.attr("width", width);
}
if(macro.ieVersion && macro.ieVersion < 7 && macro.shim && options.ie6png) {
$(img).css({width: userW, height: userH,
filter: "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='%0', sizingMethod='scale')".format(src)
}).attr("src", macro.shim);
} else {
img.attr("src", src);
}
if(!macro._image_tag_cache[options.srcUrl]) {
macro._image_tag_cache[options.srcUrl] = [];
}
img = $(img).addClass(options.imageClass)[0];
macro._image_tag_cache[options.srcUrl].push(img);
return img;
},
_getDimensions: function(realDimensions, reqDimensions, preserve) {
var w = realDimensions.width;
var h = realDimensions.height;
var reqh = reqDimensions.height;
var reqw = reqDimensions.width;
var finalw = w, finalh = h;
var ratiow = reqw / w, ratioh = reqh / h;
var scaledw = ratioh * w;
var scaledh = ratiow * h;
if(!reqw && reqh) {
finalw = scaledw;
finalh = reqh;
} else if(reqw && !reqh) {
finalw = reqw;
finalh = scaledh;
} else if(reqh && reqw) {
var preserveWidth = w > h ? true : false;
if(preserve) {
if(preserveWidth && scaledh < reqh) {
finalh = scaledh;
finalw = reqw;
} else {
finalh = reqh;
finalw = scaledw;
}
} else {
finalw = reqw;
finalh = reqh;
}
}
return { width: parseInt(finalw, 10), height: parseInt(finalh, 10) };
},
_renderBinaryImageUrl: function(container, src, options) {
var srcUrl = options.src ? options.src : src;
srcUrl = srcUrl.indexOf("/") === -1 ? "/%0".format(srcUrl) : srcUrl; // for IE.
var image_dimensions = macro._image_dimensions[srcUrl];
var image = new Image(); // due to weird scaling issues where you use just a width or just a height
var createImageTag = function(dimensions, error) {
if(error) {
var altImage = options.altImage;
if(altImage) {
delete options.altImage;
macro._renderBinaryImageUrl(container, altImage, options);
} else {
options.src = src;
macro._renderAlternateText(container, options);
}
} else {
var dim = macro._getDimensions(dimensions, {
width: options.width, height: options.height }, options.preserveAspectRatio);
options.srcUrl = srcUrl;
macro._renderImageTag(container, src, dim.width, dim.height, options);
}
};
if(!image_dimensions) {
image.onload = function() {
var dimensions = { width: image.width, height: image.height};
macro._image_dimensions[srcUrl] = dimensions;
createImageTag(dimensions);
};
image.onerror = function() {
createImageTag(null, true);
};
image.src = src;
} else {
createImageTag(image_dimensions);
}
},
_generateIdPrefix: function(){
return "twsvgfix_" + (this._fixPrefix++).toString() + "_";
},
_fixSVG: function(childNodes, idPrefix) {
var urlPattern = /url\(\#([^\)]*)\)*/ig;
var fixes = [
{ attr: "id", pattern: /^(.*)$/ig },
{ attr: "href", namespace: macro.xlinkns, pattern: /^#(.*)$/ig }
];
var url_fixes = ["filter", "fill", "mask", "stroke", "style"];
for(var i = 0; i < url_fixes.length; i++) {
fixes.push({ attr: url_fixes[i], pattern: urlPattern });
}
for(var t = 0; t < childNodes.length; t++) {
var node = childNodes[t];
for(var a = 0; a < fixes.length; a++) {
var fix = fixes[a];
var attr = fix.attr;
var ns = fix.namespace || "";
if(node.hasAttributeNS && node.hasAttributeNS(ns, attr)) {
var v = node.getAttributeNS(ns, attr);
fix.pattern.lastIndex = 0;
var match = fix.pattern.exec(v);
if(match) {
// Make sure replacement string doesn't contain any single dollar signs
var toReplace = match[1];
if(toReplace.indexOf(idPrefix) !== 0 && toReplace.indexOf("twglobal_") !== 0) {
var replacement = (idPrefix + toReplace).replace("$", "$$$$");
v = v.replace(match[1], replacement);
}
node.setAttributeNS(ns, attr,v);
}
}
}
var children = node.childNodes;
if(children.length > 0) {
this._fixSVG(children, idPrefix);
}
}
},
_importSVG: function(place, options){
options = options ? options : {};
var svgDoc, tiddlerText = options.tiddler.text;
if (window.DOMParser) {
svgDoc = new DOMParser().parseFromString(tiddlerText, "application/xml").documentElement;
var idPrefix = options.idPrefix || this._generateIdPrefix();
this._fixSVG([svgDoc], idPrefix);
var el = document.importNode(svgDoc, true);
var svgHolder = document.createElementNS(macro.svgns,"svg");
var width = options.width;
var height = options.height;
if(width || height) {
if(width && height) { // set view box of containing svg element based on the svg viewbox and width and height.
var viewBox = el.getAttribute("viewBox");
var topLeft = "0 0";
if(viewBox) {
topLeft = viewBox.replace(/([0-9]*) +([0-9]*) +([0-9]*) +([0-9]*) */gi,"$1 $2");
}
svgHolder.setAttributeNS(macro.svgns, "viewBox", "0 0 %0 %1".format(width, height));
} else {
if(!width) {
width = el.getAttribute("width");
}
if(!height) {
height = el.getAttribute("height");
}
}
svgHolder.setAttribute("width", width);
svgHolder.setAttribute("height", height);
el.setAttribute("width", "100%");
el.setAttribute("height", "100%");
svgHolder.setAttribute("class", "svgImage svgIcon %0".format(options.imageClass || ""));
svgHolder.appendChild(el);
place.appendChild(svgHolder);
}
else {
var existing = el.className ? el.className.baseVal : "";
el.setAttribute("class","svgImage %0".format(existing));
place.appendChild(el);
}
// if a tiddler attribute is set this is read as a link
$("[tiddler], [tiddlyLink]", place).attr("refresh", "link").click(function(ev) {
var tiddler = $(ev.target).attr("tiddlyLink");
if(tiddler) {
story.displayTiddler(ev.target, tiddler);
}
});
}
},
getArguments: function(paramString, params) {
var args = paramString.parseParams("name", null, true, false, true)[0];
var options = {};
for(var id in args) {
if(true) {
var p = args[id];
if(id == "def") {
options[id] = p;
} else {
options[id] = p[0];
}
}
}
var width = isNaN(params[1]) ? false : parseInt(params[1], 10);
var height = isNaN(params[2]) ? false : parseInt(params[2], 10);
options.width = macro.lookupArgument(options, "width", width);
options.height = macro.lookupArgument(options, "height", height);
options.preserveAspectRatio = args.preserveAspectRatio &&
args.preserveAspectRatio[0] == "yes" ? true : false;
options.tiddlyLink = macro.lookupArgument(options, "tiddlyLink", false);
options.link = macro.lookupArgument(options, "link", false);
return options;
},
lookupArgument: function(args, id, ifEmpty) {
return args[id] ? args[id] : ifEmpty;
}
};
// update views
var _oldwikifiedview = config.macros.view.views.wikified;
// update wikifier to check tiddler type before rendering
merge(config.macros.view.views, {
wikified: function(value, place, params, wikifier, paramString, tiddler) {
if(macro.isImageTiddler(tiddler) && params[0] == "text") {
var newplace = $("<div />").addClass("wikifiedImage").appendTo(place)[0];
macro.renderImage(newplace, tiddler.title, { alt: macro.locale.badImage });
} else {
_oldwikifiedview.apply(this, arguments);
}
},
image: function(value, place, params, wikifier, paramString, tiddler) {
// a field can point to another tiddler whereas text is the current tiddler.
var title = params[0] == "text" ? tiddler.title : value;
var args = macro.getArguments(paramString, params);
macro.renderImage(place, title, args);
}
});
config.shadowTiddlers.StyleSheetImageMacro = [".wikifiedImage svg, .wikifiedImage .image { width: 80%; }",
".svgImageText { background-color:[[ColorPalette::Error]]; color:#ddd; display: inline-block; }",
"span.svgImageText { display: inline-block; overflow: hidden; }"
].join("");
store.addNotification("StyleSheetImageMacro", refreshStyles);
})(jQuery);
//}}}
/***
|Name|ImageSizePlugin|
|Source|http://www.TiddlyTools.com/#ImageSizePlugin|
|Version|1.2.3|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|plugin|
|Description|adds support for resizing images|
This plugin adds optional syntax to scale an image to a specified width and height and/or interactively resize the image with the mouse.
!!!!!Usage
<<<
The extended image syntax is:
{{{
[img(w+,h+)[...][...]]
}}}
where ''(w,h)'' indicates the desired width and height (in CSS units, e.g., px, em, cm, in, or %). Use ''auto'' (or a blank value) for either dimension to scale that dimension proportionally (i.e., maintain the aspect ratio). You can also calculate a CSS value 'on-the-fly' by using a //javascript expression// enclosed between """{{""" and """}}""". Appending a plus sign (+) to a dimension enables interactive resizing in that dimension (by dragging the mouse inside the image). Use ~SHIFT-click to show the full-sized (un-scaled) image. Use ~CTRL-click to restore the starting size (either scaled or full-sized).
<<<
!!!!!Examples
<<<
{{{
[img(100px+,75px+)[images/meow2.jpg]]
}}}
[img(100px+,75px+)[images/meow2.jpg]]
{{{
[<img(34%+,+)[images/meow.gif]]
[<img(21% ,+)[images/meow.gif]]
[<img(13%+, )[images/meow.gif]]
[<img( 8%+, )[images/meow.gif]]
[<img( 5% , )[images/meow.gif]]
[<img( 3% , )[images/meow.gif]]
[<img( 2% , )[images/meow.gif]]
[img( 1%+,+)[images/meow.gif]]
}}}
[<img(34%+,+)[images/meow.gif]]
[<img(21% ,+)[images/meow.gif]]
[<img(13%+, )[images/meow.gif]]
[<img( 8%+, )[images/meow.gif]]
[<img( 5% , )[images/meow.gif]]
[<img( 3% , )[images/meow.gif]]
[<img( 2% , )[images/meow.gif]]
[img( 1%+,+)[images/meow.gif]]
{{tagClear{
}}}
<<<
!!!!!Revisions
<<<
2011.09.03 [1.2.3] bypass addStretchHandlers() if no '+' suffix is used (i.e., not resizable)
2010.07.24 [1.2.2] moved tip/dragtip text to config.formatterHelpers.imageSize object to enable customization
2009.02.24 [1.2.1] cleanup width/height regexp, use '+' suffix for resizing
2009.02.22 [1.2.0] added stretchable images
2008.01.19 [1.1.0] added evaluated width/height values
2008.01.18 [1.0.1] regexp for "(width,height)" now passes all CSS values to browser for validation
2008.01.17 [1.0.0] initial release
<<<
!!!!!Code
***/
//{{{
version.extensions.ImageSizePlugin= {major: 1, minor: 2, revision: 3, date: new Date(2011,9,3)};
//}}}
//{{{
var f=config.formatters[config.formatters.findByField("name","image")];
f.match="\\[[<>]?[Ii][Mm][Gg](?:\\([^,]*,[^\\)]*\\))?\\[";
f.lookaheadRegExp=/\[([<]?)(>?)[Ii][Mm][Gg](?:\(([^,]*),([^\)]*)\))?\[(?:([^\|\]]+)\|)?([^\[\]\|]+)\](?:\[([^\]]*)\])?\]/mg;
f.handler=function(w) {
this.lookaheadRegExp.lastIndex = w.matchStart;
var lookaheadMatch = this.lookaheadRegExp.exec(w.source)
if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
var floatLeft=lookaheadMatch[1];
var floatRight=lookaheadMatch[2];
var width=lookaheadMatch[3];
var height=lookaheadMatch[4];
var tooltip=lookaheadMatch[5];
var src=lookaheadMatch[6];
var link=lookaheadMatch[7];
// Simple bracketted link
var e = w.output;
if(link) { // LINKED IMAGE
if (config.formatterHelpers.isExternalLink(link)) {
if (config.macros.attach && config.macros.attach.isAttachment(link)) {
// see [[AttachFilePluginFormatters]]
e = createExternalLink(w.output,link);
e.href=config.macros.attach.getAttachment(link);
e.title = config.macros.attach.linkTooltip + link;
} else
e = createExternalLink(w.output,link);
} else
e = createTiddlyLink(w.output,link,false,null,w.isStatic);
addClass(e,"imageLink");
}
var img = createTiddlyElement(e,"img");
if(floatLeft) img.align="left"; else if(floatRight) img.align="right";
if(width||height) {
var x=width.trim(); var y=height.trim();
var stretchW=(x.substr(x.length-1,1)=='+'); if (stretchW) x=x.substr(0,x.length-1);
var stretchH=(y.substr(y.length-1,1)=='+'); if (stretchH) y=y.substr(0,y.length-1);
if (x.substr(0,2)=="{{")
{ try{x=eval(x.substr(2,x.length-4))} catch(e){displayMessage(e.description||e.toString())} }
if (y.substr(0,2)=="{{")
{ try{y=eval(y.substr(2,y.length-4))} catch(e){displayMessage(e.description||e.toString())} }
img.style.width=x.trim(); img.style.height=y.trim();
if (stretchW||stretchH) config.formatterHelpers.addStretchHandlers(img,stretchW,stretchH);
}
if(tooltip) img.title = tooltip;
// GET IMAGE SOURCE
if (config.macros.attach && config.macros.attach.isAttachment(src))
src=config.macros.attach.getAttachment(src); // see [[AttachFilePluginFormatters]]
else if (config.formatterHelpers.resolvePath) { // see [[ImagePathPlugin]]
if (config.browser.isIE || config.browser.isSafari) {
img.onerror=(function(){
this.src=config.formatterHelpers.resolvePath(this.src,false);
return false;
});
} else
src=config.formatterHelpers.resolvePath(src,true);
}
img.src=src;
w.nextMatch = this.lookaheadRegExp.lastIndex;
}
}
config.formatterHelpers.imageSize={
tip: 'SHIFT-CLICK=show full size, CTRL-CLICK=restore initial size',
dragtip: 'DRAG=stretch/shrink, '
}
config.formatterHelpers.addStretchHandlers=function(e,stretchW,stretchH) {
e.title=((stretchW||stretchH)?this.imageSize.dragtip:'')+this.imageSize.tip;
e.statusMsg='width=%0, height=%1';
e.style.cursor='move';
e.originalW=e.style.width;
e.originalH=e.style.height;
e.minW=Math.max(e.offsetWidth/20,10);
e.minH=Math.max(e.offsetHeight/20,10);
e.stretchW=stretchW;
e.stretchH=stretchH;
e.onmousedown=function(ev) { var ev=ev||window.event;
this.sizing=true;
this.startX=!config.browser.isIE?ev.pageX:(ev.clientX+findScrollX());
this.startY=!config.browser.isIE?ev.pageY:(ev.clientY+findScrollY());
this.startW=this.offsetWidth;
this.startH=this.offsetHeight;
return false;
};
e.onmousemove=function(ev) { var ev=ev||window.event;
if (this.sizing) {
var s=this.style;
var currX=!config.browser.isIE?ev.pageX:(ev.clientX+findScrollX());
var currY=!config.browser.isIE?ev.pageY:(ev.clientY+findScrollY());
var newW=(currX-this.offsetLeft)/(this.startX-this.offsetLeft)*this.startW;
var newH=(currY-this.offsetTop )/(this.startY-this.offsetTop )*this.startH;
if (this.stretchW) s.width =Math.floor(Math.max(newW,this.minW))+'px';
if (this.stretchH) s.height=Math.floor(Math.max(newH,this.minH))+'px';
clearMessage(); displayMessage(this.statusMsg.format([s.width,s.height]));
}
return false;
};
e.onmouseup=function(ev) { var ev=ev||window.event;
if (ev.shiftKey) { this.style.width=this.style.height=''; }
if (ev.ctrlKey) { this.style.width=this.originalW; this.style.height=this.originalH; }
this.sizing=false;
clearMessage();
return false;
};
e.onmouseout=function(ev) { var ev=ev||window.event;
this.sizing=false;
clearMessage();
return false;
};
}
//}}}
[[Static Analysis]] implementation in an enterprise wide fashion is not too expensive but presents several risks. You will have a machine telling people they made mistakes... the machine shall better be right or it will quickly be labelled as non functioning and ignored. Also one thousand warnings are no warning at all... You shall carefully select your Static Analysis rules and Severity levels in order to assure important things are noticed and unimportant ones don't clutter analysis. Credibility of the tool analysis shall be your first concern. Start by classifying all occurrences at Info or Minor level then analyse some projects and start promoting the level of the more important and trustworthy ones.
Coverage of the static analysis tool shall be progressive, that is, first it shall warn only on indisputable occurrences that constitute a clear defect or violation. This is a way to establish the tool and motivate adherence and recognition of its importance.
Consider some goals for Static Analysis:
*It shall be a tool for programmers to evolve in their code quality
*It shall be considered an useful "automated reviewer" by every programmer
*it shall promote an healthy competitive quality referential among teams and projects
*It shall be a trusted and respected warning system
!!Analysis Targets
|Type|Description|Sub-type|Description|h
|Defects||||
|Conformance||Documentation||
|~|~|Naming||
|Anti-pattern||Metrics||
|~|~|Security||
|~|~|Performance||
|~|~|Guideline||
!!Occurrence severity
|Level|Meaning|Action|Override|h
|''Blocker''|Refers to occurrences that, almost always, represent a very severe problem.|Immediate action required. Show stopper.|Non overrideable.|
|''Critical''|Refers to occurrences that, almost always, represent a severe problem.|Immediate action required.|Non overrideable.|
|''Major''|Refers to occurrences that, almost always, represent a problem.|Action advisable.|Overrideable only with a case-by-case analysis and justification.|
|''Minor''|Refers to occurrences that, normally, represent a deviation from the desirable pattern.|No immediate action required.|Globally overrideable with a justification.|
|''Info''|Refers to occurrences that may or may not be a problem depending on the specific context.|No immediate action required.|Project decision on the relevance of the pattern may be taken at a global level.|
----
@@color:#c4d6ed; ^^
Description: practical guidelines in implementing Static Analysis
^^@@
!An incremental approach
Implementing [[Systematic Reuse]] is an engineering improvement process, much like the ones performed to achieve maturity levels (CMMI for instance). This means that there are areas where you should invest first and that are pre-conditions to the more evolved ones. An incremental approach, where you progress in phases in your ability to perform and on the return of your performance, is, thus, recommended.
Before you start you should access if your organization is ready for such an initiative.
"//It is believed that until CMM Level 3 ("Defined Process") is achieved, when the entire organization is able to follow an explicitly defined process, it is hard to systematically make sweeping process and technology changes. In particular, effective pervasive software reuse requires many, if not most, projects in the organization to follow compatible managed processes to create, support or reuse assets. CMM Level 3 is a significant indicator that the organization has achieved a process maturity and readiness for change to this level of formal multi-project coordination.//"
(…)
"//First and foremost, introducing systematic software reuse is a significant process improvement, driven by critical business need. The CMM is a process improvement framework that summarizes key guidelines about mature software process, which can be directly applied to improved reuse practice. The change to a set of concurrent, managed and supported multi-project creator/reuser process demands significant organization changes and standardized process throughout the organization.//"
Reuse Strategies [[CMM as a Framework for Adopting Systematic Reuse|http://martin.griss.com/pubs/obm10.htm]], Martin L. Griss, Object Magazine, March, 1998, pp. 60-62,69.
Also make sure that the effort, time and expected return of the investment is well understood by your top and middle management as medium-term support will be essential to achieve any significant goals. Accountancy, that is, the ability to objectively demonstrate profitability of the initiative, is essential to keep it running, and funded, on the medium-term.
Below we will propose a Reuse Maturity Model (RMM) that you may use to plan and evaluate your reuse improvement programme but first you shall determine your goals, targets and actors in this endeavour.
!Improvement targets, goals and actors
Reuse targets are not only, nor even mainly, software code assets. Reuse is easier towards abstraction and, as such, specifications, techniques, architectures, know-how and many other tangible and intangible assets shall be considered when planning [[Systematic Reuse]] implementation. Probably it is much more rewarding to start by reusing an [[archetype|Application Archetype]] catalogue or a [[filesystem and namespace guideline|Namespace and Filesystem Guidelines]] than a specific code library. Consider this when planning your move towards systematic reuse and consider that you shall start by removing [[reuse obstacles|Reuse Obstacles]].
The goals of the improvement programme are to remove obstacles and to promote reuse and to achieve better and better reuse levels across all your software development activities thus achieving the known [[reuse advantages|Reuse Advantages]].
Actors of this improvement process are each and every person involved in the development process from management and sales, through development teams to designers and quality assurance among many others. This must be seen as a company wide pervasive endeavour. Of course that management sponsorship is essential but also direct project management is a condition for reuse to succeed. The first is quite easy to get but the last one is harder. [[PM]]s are usually much more concerned with the short-term than with medium or long-term benefits they will not willingly accept to divert a few resources from the immediate project goals to a medium-term target unless that is planned and paid for in advance and they are also rewarded for future earnings. [[PM]]s like to reuse they do not like to produce for reuse.
!A Reuse Maturity Model (RMM)
|Stage|Description|h
|Individual|Individual reuse is the first stage. This is the personal reuse every programmer or analyst does.|
|Processual|Processual stage is the one where a mature software company has established development processes and provides structural templates for most of its work products. Mandatory guidelines for [[Namespace and Filesystem Guidelines]], for instance, start to be established|
|Methodological|At this stage a software company provides a full lifecycle [[meta-model|http://en.wikipedia.org/wiki/Metamodeling]] and promotes a "[[Single Version of the Truth|http://en.wikipedia.org/wiki/Single_Version_of_the_Truth]]", content templates and methodological orientation and examples that actively fight [[reuse obstacles|Reuse Obstacles]]. Coherent metrics on reuse start to be established and dedicated effort is allocated to promote reuse.|
|Systematic|[[Reuse by copy|Reuse by Reference]] is reduced and [[Continuous Improvement]] is promoted. Reuse profitability is established. Dissemination practices and infrastructures are put in place (see <<quote 'Conway´s law' 'Conway´s law'>>). Reuse is considered and performed across all phases. Dedicated and formal roles are established for reuse. Permanent and stable funding. Medium / long term planning.|
----
@@color:#c4d6ed; ^^
Description: Guidelines on implementing a Systematic Reuse improvement process.
^^@@
On the [[Knowledge Management|KnowledgeManagement]] domain we consider ''independence'' the degree to which information and knowledge in an organization do not depend exclusively from individual persons and expertises.
----
See also [[Knowledge Management|KnowledgeManagement]]
----
/%
@@color:#c4d6ed; ^^
Description: Independence concept on Knowledge Management
^^@@
%/
//The second (and better) scenario is modularized based on "design decisions." Parnas observes, "We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others." //
[[Abstraction]] gears towards comprehension
[[Encapsulation]] gears towards protection from outside interference
Information Hiding gears towards containment of design changes
* Edward V. Berard - Abstraction, Encapsulation and Information Hiding [[[Berard]|BibliographyPage##Berard]]
* D.L. Parnas - On the Criteria To Be Used in Decomposing Systems Into Modules, 1972 [[[Parnas 1972]|BibliographyPage##Parnas 1972]]
----
@@color:#c4d6ed; ^^
Description: Information hiding concept and references.
^^@@
/***
|Name|InlineJavascriptPlugin|
|Source|http://www.TiddlyTools.com/#InlineJavascriptPlugin|
|Documentation|http://www.TiddlyTools.com/#InlineJavascriptPluginInfo|
|Version|1.9.6|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|plugin|
|Description|Insert Javascript executable code directly into your tiddler content.|
''Call directly into TW core utility routines, define new functions, calculate values, add dynamically-generated TiddlyWiki-formatted output'' into tiddler content, or perform any other programmatic actions each time the tiddler is rendered.
!!!!!Documentation
>see [[InlineJavascriptPluginInfo]]
!!!!!Revisions
<<<
2010.12.15 1.9.6 allow (but ignore) type="..." syntax
|please see [[InlineJavascriptPluginInfo]] for additional revision details|
2005.11.08 1.0.0 initial release
<<<
!!!!!Code
***/
//{{{
version.extensions.InlineJavascriptPlugin= {major: 1, minor: 9, revision: 6, date: new Date(2010,12,15)};
config.formatters.push( {
name: "inlineJavascript",
match: "\\<script",
lookahead: "\\<script(?: type=\\\"[^\\\"]*\\\")?(?: src=\\\"([^\\\"]*)\\\")?(?: label=\\\"([^\\\"]*)\\\")?(?: title=\\\"([^\\\"]*)\\\")?(?: key=\\\"([^\\\"]*)\\\")?( show)?\\>((?:.|\\n)*?)\\</script\\>",
handler: function(w) {
var lookaheadRegExp = new RegExp(this.lookahead,"mg");
lookaheadRegExp.lastIndex = w.matchStart;
var lookaheadMatch = lookaheadRegExp.exec(w.source)
if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
var src=lookaheadMatch[1];
var label=lookaheadMatch[2];
var tip=lookaheadMatch[3];
var key=lookaheadMatch[4];
var show=lookaheadMatch[5];
var code=lookaheadMatch[6];
if (src) { // external script library
var script = document.createElement("script"); script.src = src;
document.body.appendChild(script); document.body.removeChild(script);
}
if (code) { // inline code
if (show) // display source in tiddler
wikify("{{{\n"+lookaheadMatch[0]+"\n}}}\n",w.output);
if (label) { // create 'onclick' command link
var link=createTiddlyElement(w.output,"a",null,"tiddlyLinkExisting",wikifyPlainText(label));
var fixup=code.replace(/document.write\s*\(/gi,'place.bufferedHTML+=(');
link.code="function _out(place,tiddler){"+fixup+"\n};_out(this,this.tiddler);"
link.tiddler=w.tiddler;
link.onclick=function(){
this.bufferedHTML="";
try{ var r=eval(this.code);
if(this.bufferedHTML.length || (typeof(r)==="string")&&r.length)
var s=this.parentNode.insertBefore(document.createElement("span"),this.nextSibling);
if(this.bufferedHTML.length)
s.innerHTML=this.bufferedHTML;
if((typeof(r)==="string")&&r.length) {
wikify(r,s,null,this.tiddler);
return false;
} else return r!==undefined?r:false;
} catch(e){alert(e.description||e.toString());return false;}
};
link.setAttribute("title",tip||"");
var URIcode='javascript:void(eval(decodeURIComponent(%22(function(){try{';
URIcode+=encodeURIComponent(encodeURIComponent(code.replace(/\n/g,' ')));
URIcode+='}catch(e){alert(e.description||e.toString())}})()%22)))';
link.setAttribute("href",URIcode);
link.style.cursor="pointer";
if (key) link.accessKey=key.substr(0,1); // single character only
}
else { // run script immediately
var fixup=code.replace(/document.write\s*\(/gi,'place.innerHTML+=(');
var c="function _out(place,tiddler){"+fixup+"\n};_out(w.output,w.tiddler);";
try { var out=eval(c); }
catch(e) { out=e.description?e.description:e.toString(); }
if (out && out.length) wikify(out,w.output,w.highlightRegExp,w.tiddler);
}
}
w.nextMatch = lookaheadMatch.index + lookaheadMatch[0].length;
}
}
} )
//}}}
// // Backward-compatibility for TW2.1.x and earlier
//{{{
if (typeof(wikifyPlainText)=="undefined") window.wikifyPlainText=function(text,limit,tiddler) {
if(limit > 0) text = text.substr(0,limit);
var wikifier = new Wikifier(text,formatter,null,tiddler);
return wikifier.wikifyPlain();
}
//}}}
// // GLOBAL FUNCTION: $(...) -- 'shorthand' convenience syntax for document.getElementById()
//{{{
if (typeof($)=='undefined') { function $(id) { return document.getElementById(id.replace(/^#/,'')); } }
//}}}
/***
|Name|InlineJavascriptPluginInfo|
|Source|http://www.TiddlyTools.com/#InlineJavascriptPlugin|
|Documentation|http://www.TiddlyTools.com/#InlineJavascriptPluginInfo|
|Version|1.9.6|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|documentation|
|Description|Documentation for InlineJavascriptPlugin|
''Call directly into TW core utility routines, define new functions, calculate values, add dynamically-generated TiddlyWiki-formatted output'' into tiddler content, or perform any other programmatic actions each time the tiddler is rendered.
!!!!!Usage
<<<
This plugin adds wiki syntax for surrounding tiddler content with {{{<script>}}} and {{{</script>}}} markers, so that it can be recognized as embedded javascript code. When a tiddler is rendered, the plugin automatically invokes any embedded scripts, which can be used to construct and return dynamically-generated output that is inserted into the tiddler content.
{{{
<script type="..." src="..." label="..." title="..." key="..." show>
/* javascript code goes here... */
</script>
}}}
All parameters are //optional//. When the ''show'' keyword is used, the plugin will also include the script source code in the output that it displays in the tiddler. This is helpful when creating examples for documentation purposes (such as used in this tiddler!)
__''Deferred execution from an 'onClick' link''__
<script label="click here" title="mouseover tooltip text" key="X" show>
/* javascript code goes here... */
alert('you clicked on the link!');
</script>
By including a {{{label="..."}}} parameter in the initial {{{<script>}}} marker, the plugin will create a link to an 'onclick' script that will only be executed when that specific link is clicked, rather than running the script each time the tiddler is rendered. You may also include a {{{title="..."}}} parameter to specify the 'tooltip' text that will appear whenever the mouse is moved over the onClick link text, and a {{{key="X"}}} parameter to specify an //access key// (which must be a //single// letter or numeric digit only).
__''Loading scripts from external source files''__
<script src="URL" show>
/* optional javascript code goes here... */
</script>You can also load javascript directly from an external source URL, by including a src="..." parameter in the initial {{{<script>}}} marker (e.g., {{{<script src="demo.js"></script>}}}). This is particularly useful when incorporating third-party javascript libraries for use in custom extensions and plugins. The 'foreign' javascript code remains isolated in a separate file that can be easily replaced whenever an updated library file becomes available.
In addition to loading the javascript from the external file, you can also use this feature to invoke javascript code contained within the {{{<script>...</script>}}} markers. This code is invoked //after// the external script file has been processed, and can make immediate use of the functions and/or global variables defined by the external script file.
>Note: To ensure that your javascript functions are always available when needed, you should load the libraries from a tiddler that is rendered as soon as your TiddlyWiki document is opened, such as MainMenu. For example: put your {{{<script src="..."></script>}}} syntax into a separate 'library' tiddler (e.g., LoadScripts), and then add {{{<<tiddler LoadScripts>>}}} to MainMenu so that the library is loaded before any other tiddlers that rely upon the functions it defines.
>
>Normally, loading external javascript in this way does not produce any direct output, and should not have any impact on the appearance of your MainMenu. However, if your LoadScripts tiddler contains notes or other visible content, you can suppress this output by using 'inline CSS' in the MainMenu, like this: {{{@@display:none;<<tiddler LoadScripts>>@@}}}
<<<
!!!!!Creating dynamic tiddler content and accessing the ~TiddlyWiki DOM
<<<
An important difference between TiddlyWiki inline scripting and conventional embedded javascript techniques for web pages is the method used to produce output that is dynamically inserted into the document: in a typical web document, you use the {{{document.write()}}} (or {{{document.writeln()}}}) function to output text sequences (often containing HTML tags) that are then rendered when the entire document is first loaded into the browser window.
However, in a ~TiddlyWiki document, tiddlers (and other DOM elements) are created, deleted, and rendered "on-the-fly", so writing directly to the global 'document' object does not produce the results you want (i.e., replacing the embedded script within the tiddler content), and instead will //completely replace the entire ~TiddlyWiki document in your browser window (which is clearly not a good thing!)//. In order to allow scripts to use {{{document.write()}}}, the plugin automatically converts and buffers all HTML output so it can be safely inserted into your tiddler content, immediately following the script.
''Note that {{{document.write()}}} can only be used to output "pure HTML" syntax. To produce //wiki-formatted// output, your script should instead return a text value containing the desired wiki-syntax content'', which will then be automatically rendered immediately following the script. If returning a text value is not sufficient for your needs, the plugin also provides an automatically-defined variable, 'place', that gives the script code ''direct access to the //containing DOM element//'' into which the tiddler output is being rendered. You can use this variable to ''perform direct DOM manipulations'' that can, for example:
* generate wiki-formatted output using {{{wikify("...content...",place)}}}
* vary the script's actions based upon the DOM element in which it is embedded
* access 'tiddler-relative' DOM information using {{{story.findContainingTiddler(place)}}}
Note:
''When using an 'onclick' script, the 'place' element actually refers to the onclick //link text// itself, instead of the containing DOM element.'' This permits you to directly reference or modify the link text to reflect any 'stateful' conditions that might set by the script. To refer to the containing DOM element from within an 'onclick' script, you can use "place.parentNode" instead.
<<<
!!!!!Instant "bookmarklets"
<<<
You can also use an 'onclick' link to define a "bookmarklet": a small piece of javascript that can be ''invoked directly from the browser without having to be defined within the current document.'' This allows you to create 'stand-alone' commands that can be applied to virtually ANY TiddlyWiki document... even remotely-hosted documents that have been written by others!! To create a bookmarklet, simply define an 'onclick' script and then grab the resulting link text and drag-and-drop it onto your browser's toolbar (or right-click and use the 'bookmark this link' command to add it to the browser's menu).
Notes:
*When writing scripts intended for use as bookmarklets, due to the ~URI-encoding required by the browser, ''you cannot not use ANY double-quotes (") within the bookmarklet script code.''
*All comments embedded in the bookmarklet script must ''use the fully-delimited {{{/* ... */}}} comment syntax,'' rather than the shorter {{{//}}} comment syntax.
*Most importantly, because bookmarklets are invoked directly from the browser interface and are not embedded within the TiddlyWiki document, there is NO containing 'place' DOM element surrounding the script. As a result, ''you cannot use a bookmarklet to generate dynamic output in your document,'' and using {{{document.write()}}} or returning wiki-syntax text or making reference to the 'place' DOM element will halt the script and report a "Reference Error" when that bookmarklet is invoked.
Please see [[InstantBookmarklets]] for many examples of 'onclick' scripts that can also be used as bookmarklets.
<<<
!!!!!Special reserved function name
<<<
The plugin 'wraps' all inline javascript code inside a function, {{{_out()}}}, so that any return value you provide can be correctly handled by the plugin and inserted into the tiddler. To avoid unpredictable results (and possibly fatal execution errors), this function should never be redefined or called from ''within'' your script code.
<<<
!!!!!$(...) 'shorthand' function
<<<
As described by Dustin Diaz [[here|http://www.dustindiaz.com/top-ten-javascript/]], the plugin defines a 'shorthand' function that allows you to write:
{{{
$(id)
}}}
in place of the normal standard javascript syntax:
{{{
document.getElementById(id)
}}}
This function is provided merely as a convenience for javascript coders that may be familiar with this abbreviation, in order to allow them to save a few bytes when writing their own inline script code.
<<<
!!!!!Examples
<<<
simple dynamic output:
><script show>
document.write("The current date/time is: "+(new Date())+"<br>");
return "link to current user: [["+config.options.txtUserName+"]]\n";
</script>
dynamic output using 'place' to get size information for current tiddler:
><script show>
if (!window.story) window.story=window;
var title=story.findContainingTiddler(place).getAttribute("tiddler");
var size=store.getTiddlerText(title).length;
return title+" is using "+size+" bytes";
</script>
dynamic output from an 'onclick' script, using {{{document.write()}}} and/or {{{return "..."}}}
><script label="click here" show>
document.write("<br>The current date/time is: "+(new Date())+"<br>");
return "link to current user: [["+config.options.txtUserName+"]]\n";
</script>
creating an 'onclick' button/link that accesses the link text AND the containing tiddler:
><script label="click here" title="clicking this link will show an 'alert' box" key="H" show>
if (!window.story) window.story=window;
var txt=place.firstChild.data;
var tid=story.findContainingTiddler(place).getAttribute('tiddler');
alert('Hello World!\nlinktext='+txt+'\ntiddler='+tid);
</script>
dynamically setting onclick link text based on stateful information:
>{{block{
{{{
<script label="click here">
/* toggle "txtSomething" value */
var on=(config.txtSomething=="ON");
place.innerHTML=on?"enable":"disable";
config.txtSomething=on?"OFF":"ON";
return "\nThe current value is: "+config.txtSomething;
</script><script>
/* initialize onclick link text based on current "txtSomething" value */
var on=(config.txtSomething=="ON");
place.lastChild.previousSibling.innerHTML=on?"disable":"enable";
</script>
}}}
<script label="click here">
/* toggle "txtSomething" value */
var on=(config.txtSomething=="ON");
place.innerHTML=on?"enable":"disable";
config.txtSomething=on?"OFF":"ON";
return "\nThe current value is: "+config.txtSomething;
</script><script>
/* initialize onclick link text based on current "txtSomething" value */
var on=(config.txtSomething=="ON");
place.lastChild.innerHTML=on?"enable":"disable";
</script>
}}}
loading a script from a source url:
>http://www.TiddlyTools.com/demo.js contains:
>>{{{function inlineJavascriptDemo() { alert('Hello from demo.js!!') } }}}
>>{{{displayMessage('InlineJavascriptPlugin: demo.js has been loaded');}}}
>note: When using this example on your local system, you will need to download the external script file from the above URL and install it into the same directory as your document.
>
><script src="demo.js" show>
return "inlineJavascriptDemo() function has been defined"
</script>
><script label="click to invoke inlineJavascriptDemo()" key="D" show>
inlineJavascriptDemo();
</script>
<<<
!!!!!Revisions
<<<
2010.12.15 1.9.6 allow (but ignore) type="..." syntax
2009.04.11 1.9.5 pass current tiddler object into wrapper code so it can be referenced from within 'onclick' scripts
2009.02.26 1.9.4 in $(), handle leading '#' on ID for compatibility with JQuery syntax
2008.06.11 1.9.3 added $(...) function as 'shorthand' for document.getElementById()
2008.03.03 1.9.2 corrected fallback declaration of wikifyPlainText() (fixes Safari "parse error")
2008.02.23 1.9.1 in onclick function, use string instead of array for 'bufferedHTML' (fixes IE errors)
2008.02.21 1.9.0 output from 'onclick' scripts (return value or document.write() calls) are now buffered and rendered into into a span following the script. Also, added default 'return false' handling if no return value provided (prevents HREF from being triggered -- return TRUE to allow HREF to be processed). Thanks to Xavier Verges for suggestion and preliminary code.
2008.02.14 1.8.1 added backward-compatibility for use of wikifyPlainText() in TW2.1.3 and earlier
2008.01.08 [*.*.*] plugin size reduction: documentation moved to ...Info tiddler
2007.12.28 1.8.0 added support for key="X" syntax to specify custom access key definitions
2007.12.15 1.7.0 autogenerate URI encoded HREF on links for onclick scripts. Drag links to browser toolbar to create bookmarklets. IMPORTANT NOTE: place is NOT defined when scripts are used as bookmarklets. In addition, double-quotes will cause syntax errors. Thanks to PaulReiber for debugging and brainstorming.
2007.11.26 1.6.2 when converting "document.write()" function calls in inline code, allow whitespace between "write" and "(" so that "document.write ( foobar )" is properly converted.
2007.11.16 1.6.1 when rendering "onclick scripts", pass label text through wikifyPlainText() to parse any embedded wiki-syntax to enable use of HTML entities or even TW macros to generate dynamic label text.
2007.02.19 1.6.0 added support for title="..." to specify mouseover tooltip when using an onclick (label="...") script
2006.10.16 1.5.2 add newline before closing '}' in 'function out_' wrapper. Fixes error caused when last line of script is a comment.
2006.06.01 1.5.1 when calling wikify() on script return value, pass hightlightRegExp and tiddler params so macros that rely on these values can render properly
2006.04.19 1.5.0 added 'show' parameter to force display of javascript source code in tiddler output
2006.01.05 1.4.0 added support 'onclick' scripts. When label="..." param is present, a button/link is created using the indicated label text, and the script is only executed when the button/link is clicked. 'place' value is set to match the clicked button/link element.
2005.12.13 1.3.1 when catching eval error in IE, e.description contains the error text, instead of e.toString(). Fixed error reporting so IE shows the correct response text. Based on a suggestion by UdoBorkowski
2005.11.09 1.3.0 for 'inline' scripts (i.e., not scripts loaded with src="..."), automatically replace calls to 'document.write()' with 'place.innerHTML+=' so script output is directed into tiddler content. Based on a suggestion by BradleyMeck
2005.11.08 1.2.0 handle loading of javascript from an external URL via src="..." syntax
2005.11.08 1.1.0 pass 'place' param into scripts to provide direct DOM access
2005.11.08 1.0.0 initial release
<<<
The Internet is not what it used to be. It was taken by scams, advertisement, sales and stupid pseudo-social applications that completely obfuscate everything else.
There is, however, some noble resistance.
{{tw_ttoc{}}}
!General
General purpose links
* [[Wikipedia|https://www.wikipedia.org]] - The Free Encyclopedia
* [[Medium|https://medium.com/]] - Read, write and share stories that matter
* [[Increment|https://increment.com/]] - A print and digital magazine about how teams build and operate software systems at scale.
!Social
* [[Crítica|https://criticanarede.com/]] - A Crítica é uma publicação dedicada à filosofia, fundada em 1997 por Desidério Murcho. Recebe cerca de 100 mil leitores por mês.
!Archives
Archive web sites where we can find old (sometimes invaluable and unsurpassed) things
* [[Wayback Machine|https://web.archive.org/]] - The Internet Archive - Explore more than 624 billion web pages saved over time...
* [[bitsavers|http://bitsavers.org/]] - A personal archive worth a visit...
* [[www.oldapps.com|https://web.archive.org/web/20210515053706/https://www.oldapps.com/]] - Essential to fight nowadays "programmed obsolescence" obscenity.
!Search engines
Web search engines non advertising and sell oriented
* [[swisscows|https://swisscows.com/]] - Privacy safe search engine. A search engine that looks for what you seek instead of trying to sell you things.
* [[Ecosia|https://www.ecosia.org/]] - The search engine that plants trees.
!Indexers
Index engines for publications
* [[Cornell University's arXiv|https://arxiv.org/multi?group=grp_cs&%2Fform=Form+Interface]] - Computer Science search form
* [[The Index of Information Systems Journals|http://lamp.infosys.deakin.edu.au/journals/]] - Published by Deakin University
!Finance
* [[GoParity|https://goparity.com]] - ~GoParity is an online investment platform connecting private and institutional investors with projects that are in line with the [[United Nations' Sustainable Development Goals (SDGs)|https://sdgs.un.org/goals]]. We operate based on a crowd-lending business model – in which our community of investors pool their funds together in order to lend collectively to specific projects.
----
~~See also: [[Privacy page|PrivacyPage]]~~
----
<<TiddlerToC min-entries:1>>
/%
@@color:#c4d6ed; ^^
Description: Thoughts about the Internet and selected interesting resources that may be found there
^^@@
%/
Knowledge Management
"//Knowledge management (KM) is the process of creating, sharing, using and managing the knowledge and information of an organisation. It refers to a multidisciplinary approach to achieving organisational objectives by making the best use of knowledge.//"
From [[Wikipedia|https://en.wikipedia.org/wiki/Knowledge_management]]
----
See: KnowledgeManagement
----
/%
@@color:#c4d6ed; ^^
Description: Knowledge Management
^^@@
%/
<<quote 'Standing on the shoulders of giants' 'Standing on the shoulders of giants'>>
In the development dimension we want to take every opportunity to improve and expand the available knowledge. For this agile tools are essential as those opportunities almost always emerge during other tasks and, if the effort required to utilize them is too much, people will stick to the task at hands and miss the opportunity. A system that promotes small but <<quote 'continuous incremental improvements' 'Continuous Improvement (KM)'>> to information and knowledge is the one that will prosper.
TODO:
----
Back to [[KnowledgeManagement]]
See also : [[KM Production]] [[KM Retrieval]] [[KM Storage]]
----
/%
@@color:#c4d6ed; ^^
Description: TODO
^^@@
%/
The knowledge production is a multi-faceted continuous task that must be performed in very different ways and systems. The "central repository" idea is wrong and will not cope with mutating needs that Knowledge Management area always faces.
The desired centralization shall be achieved through our proposed [[technical stack|KM Technical Stack]] and, especially, with the Search & Index and Relationship pillars as their role is to provide a centralized and searchable access point to knowledge. This is the way to make <<quote 'available' 'Availability (KM)'>> the disperse and in multiple format and storages knowledge.
Make no mistake, in an organization, data will always be produced in a variety of formats and supports, trying to reduce that to a single format and repository is futile and doomed to failure.
The right approach to deal with that unavoidable dispersion is to implement the [[three technical stack pillars|KM Technical Stack]] in a way that allows them to cover the full data landscape and work as a central entry point to locate and access the available knowledge. That is, in a way that promotes our goals of <<quote 'availability' 'Availability (KM)'>>, <<quote 'continuity' 'Continuity (KM)'>>, <<quote 'independence' 'Independence (KM)'>> and <<quote 'Continuous Improvement' 'Continuous Improvement (KM)'>>.
This dispersion is also required by the agility needed in knowledge production. There shall be no obstacles to knowledge production, that is, any knowledge is good, no matter its format, as long as it is able to be integrated in in our stack and, as such, made <<quote 'available' 'Availability (KM)'>>.
''In this context the first and foremost requirement for knowledge production is that it is made in an externally (no silos) indexable, searchable and retrievable way.'' No other requirements shall be put as they will turn into obstacles to knowledge production. Of course that guidelines to ease classification and improve retrievability and content quality and maintainability are not only allowed but desirable.
So, as most of system designs should, we will start by identifying our data sources and model.
!!Books, Articles, Papers, Manuals, Standards and other written references
A ''Library'' is, still, the best knowledge base available. If you properly index its contents, making it <<quote 'available' 'Availability (KM)'>>, you will have a very powerful tool to promote better, informed, choices and generally increase the quality of your results and your team's potential.
TODO: Faceted search, semantic clustering, structures, tags, metadata
!! Organizational operational data
!! Technical Case Studies
!! White papers
!! Wikies and sites
!! Internal documents
Internal documents like guidelines, process definitions and even project documentation shall be great sources of information if properly indexed. The main obstacle here may be confidentiality issues and internal disclosure policies.
----
Back to [[KnowledgeManagement]]
See also : [[KM Storage]] [[KM Retrieval]] [[KM Development]]
----
/%
@@color:#c4d6ed; ^^
Description: Knowledge Production requirements and considerations
^^@@
%/
The retrieval ability is the best chance to achieve a continuous improvement of produced, stored and retrieved knowledge. It is also the retrieval ability that makes knowledge useful. Knowledge must be <<quote 'available' 'Availability (KM)'>> when needed if not it is just a waste of resources.
TODO:
----
Back to [[KnowledgeManagement]]
See also : [[KM Production]] [[KM Storage]] [[KM Development]]----
/%
@@color:#c4d6ed; ^^
Description: TODO
^^@@
%/
From the venerable [[Apache Lucene|https://lucene.apache.org/]] index engines have evolved a lot, even if its orientation today seems to focus more on web storefronts than information repositories there are plenty choices.
Two of the more important are [[ElasticSearch|https://www.elastic.co/products/elasticsearch]] and [[Solr|https://lucene.apache.org/solr/]]. Notice from the beginning that there are several integrated systems that perform all the functions of a search & index system but, such integration carries constraints, namely on the authorization area, that may difficult a proper knowledge management approach.
{{tw_ttoc{}}}
!Main concern topics
!!Authentication and authorization
At this topic a difficult choice must be made, you are in the knowledge management context so your primary goal is to provide the existent information when it is needed to whoever needs it. This conflicts with the traditional confidentiality policies that hide everything until it be explicitly granted to a specific user.
Take notice that we are talking about an indexing and search system, actual access to the indexed data shall still be governed by its individual systems.
We propose a modified [[KM multi-level security]] model that is able to preserve some level of confidentiality without impairing knowledge share and <<quote 'availability' 'Availability (KM)'>>. One important aspect of this model is that it supposes that ''high sensitiveness information shall not be indexed in the system''.
!!Scalability and volume
Face it! If you do not intend to index the whole Internet you probably do not need an engine able to do so. For a normal organization the knowledge management data hardly classifies as "big data". The organization may produce "big data" but that is not the target of its knowledge management system, that "big data" shall be handled by dedicated systems with very different requirements and goals.
And remember that the more general your system is, less <<quote 'relevant' 'Relevance (KM)'>> will be its results.
!!Relevance
<<quote 'Recall' 'Recall (KM)'>> and <<quote 'Precision' 'Precision (KM)'>> are the two main measures for search engine results.
The first is important if you need an exhaustive search, for instance in a legal data search system where you can not afford to miss a law on the subject you are working on. In these scenarios you will want to assure you return each and every possible result.
The second is more important when you have a large potential result set and must rank that set in order to present the most relevant results first. Results on the 99th page of a result set are not, usually, very useful because the user will not get there.
In the knowledge management field the index & search system's major challenge is relevance. In crawling and parsing you must gather as much relevance signals as you can and these can range from placement and origin system's metadata to the typographical structure of indexed data. For this you may start with a generic parser but you will need to specialize it to specifically handle your repositories (data sources) if you want to maximize relevance.
!Anatomy of a search & index block
A search&index block has two autonomous processes: building the index and searching and retrieving results from the index.
In the first process (building the ''index'') you, typically, have three main steps:
*''Crawling'': at this step you traverse your target information sources and get the data to be indexed. This will be files, web pages, database records or anything else you want to be able to search.
*''Parsing'': here you want to deal with all the formats in which data can be found and extract its content and meta-data to a common representation that is proper for indexing.
*''Indexing'': finally you give the common representation of each data item to the indexer engine to be incorporated in the index.
In the second process, ''Retrieval'', a user will define a search criteria that will be executed against the index and retrieve a result set that, hopefully, will be <<quote 'relevant' 'Relevance (KM)'>> and as <<quote 'complete' 'Recall (KM)'>> as possible.
!!Details on building the index
!!!Crawling
Crawling has, today, many challenges as we no more deal only with static web pages, files and data records. Crawling a Sharepoint site is not easy as we are facing dynamic content, ambiguous linking, multi-tenancy and many other difficulties that a classic http-crawler can't deal with. Crawling a [[CVS]] system like Git is a nightmare as you have to retrieve the entire repository before crawling.
Scalability is also an issue here as you are, potentially, talking about terabytes of data and, ideally, you should be able to handle it incrementally, by detecting change, and not with brute-force, by redoing it all every time.
!!!Parsing
The [[Apache Tika™|https://tika.apache.org/]] toolkit detects and extracts metadata and text from over a thousand different file types (such as PPT, XLS, and PDF).
!!!Indexing
Indexing is, typically, not problematic as modern engines, like Solr, already take care of it in a proper manner. The challenge here is to configure the index to increase <<quote 'precision' 'Precision (KM)'>> on the retrieval which is achieved by having as much <<quote 'relevance' 'Relevance (KM)'>> signals as possible and by structuring the data in order to rank matches by their relevance (for instance a match in a title is, typically, more relevant than the same match in the text body). Remember that the quality of the results is determined at index time not at retrieval time: the retrieval system can not use data that is not indexed.
!!Details on searching the index
The retrieval system is what the users will see of the system... TODO:complete
----
Back to: [[KM Technical Stack]]
<<TiddlerToC>>
----
/%
@@color:#c4d6ed; ^^
Description: Guideline for implementing a KM Search & Index stack
^^@@
%/
As we saw, in any real organization you will have multiple production and storage means for the information.
TODO:
----
Back to [[KnowledgeManagement]]
See also : [[KM Production]] [[KM Retrieval]] [[KM Development]]
----
/%
@@color:#c4d6ed; ^^
Description: KM Storage requirements and considerations
^^@@
%/
!The context
In any organization information is dispersed among several different repositories. Think of CRM systems, shared filesystems, web sites, databases, and a lot of other possibilities.
The challenge here is, given the existence of information, how to access it, how to know that it exists and where to retrieve it when needed. And more, how to correlate that information in order to turn it into actionable knowledge (something that gives you more than what you already know).
!Three pillars
<<Image "FR" "320" "KM-ArchStack.jpg" "https://dl.dropbox.com/" "s/00rd1n42e9wo8ze/" "?dl=1" "KM architectural stack">>
There are three systems that are essential for managing the information in order to transform it into knowledge. These work together and are complementary to each other.
!!Search and index
This is the most common. To have an indexing engine that access all or most of the repositories and indexes their content and an exploration system that is able to query those indexes is an unavoidable need for any organization with a reasonable volume of information. In [[KM Search and Index]] you may find a detailed proposal and guideline for implementing such a system.
But a mere word index that returns thousands of results for any search is not efficient.
!!Graph relationship
<<Image "FR" "320" "KM_ASK_tool.png" "https://dl.dropbox.com/" "s/g8brrykpw7cbujc/" "?dl=1" "ASKnowledge tool">>
Relationship is what turns information into knowledge, actionable knowledge.
A proper relationship management tool is needed as it is the only way to cope with progressive ontology discovery and development. In my experience all other approaches fall short and fail in getting up with evolution and continuous improvement in an enterprise knowledge management endeavour.
<<Image "FL" "320" "km_tech.png" "https://dl.dropbox.com/" "s/6t8bx9u7x1wz3n0/" "?dl=1" "Tech area ontology">>
<<Image "FR" "320" "km_tech_db.png" "https://dl.dropbox.com/" "s/ufhw6dpzl6jwn5n/" "?dl=1" "Tech area DB example">>
Graph relationship and hyperlinking of information are also the proper ways to cope with progressive and cooperative building of knowledge. These techniques are ideal to foster collaboration and a continuous improvement and refining of knowledge. ''They are also the only ones that offer an open enough model to cope with ever evolving knowledge and its needs.'' They also provide the ideal medium to merge automatically gathered information and human produced one.
Their main strength is that, if properly designed, they provide an open and ever evolving [[ontology|https://en.wikipedia.org/wiki/Ontology_(information_science)]] keeping a strict normalization. The model expressiveness is not constrained //ab initio// but evolves and adapts to the emerging needs.
!!Wiki repository
A napkin note is better than no note at all.
We need a system that is able to handle quick notes, unstructured information and direct unobtrusive input and that is fit for progressive, incremental and collaborative information improvement. Wiki approach is the best for these goals. You can also use blogs and forums but consider that these tend to impair progressive improvement, as they are more cumulative than progressive information tools, and often produce a lot of noise around a subject. A topic may start in a forum but, as soon as it reaches some maturity, it shall be moved to a more structured and clean wiki page. Wikies are excellent tools for distilling, refining and cross-relating information and knowledge as they are intended, precisely, for collaborative and progressive iterative knowledge building.
----
Back to: KnowledgeManagement
----
/%
@@color:#c4d6ed; ^^
Description: Knowledge Management technical stack presentation
^^@@
%/
The [[KM]] system shall implement multi-level per area security.
The main goal of a knowledge management system is to provide access to information to those that need it. As such the system's focus shall not be to hide information but, otherwise, to expose it as much as possible. __High sensibility information shall not be indexed or handled by this system.__ Notice that the KM system does not provide access to the data itself this access is provided, and controlled, by the source systems.
The system shall implement a security mechanism that allows for lower Clearance Level users to know that information exists on upper Security Classification levels but not to know what that information is. This is devised so that a low clearance user can know that the information exists and ask for it to a higher cleared user when needed. These are known as ''Security Levels''.
The security system is built around security levels attributed to users and documents (or entire repositories) that when crossed determine one of four access levels that define what is returned to the user, from nothing to the full document title, link and context. Notice again that this system only returns, at most, the document's title, link and matching context, access to the document itself is governed by the source repository.
Security levels are called ''Security Clearance'' for users and ''Security Classification'' for documents/repositories. Notice that KM repositories may be a sub-set of physical repositories, that is, a [[CVS]] structured physical repository may be divided into two KM repositories one for source code (with lower classification) and the other for management information (with higher classification) for instance.
The system shall also consider that in organizations the users' clearance may depend and vary according to the user's and document's Business or Functional Area and, as such, documents belong to an area and users may have specific clearances per area.
Following is a draft list of security features that may help understand the proposed approach.
''~FT-10.010 - Security levels''
The system's security is based on a multi-level approach where access is granted to users with a clearance (security level) equal or above the security level classification of a document.
''~FT-10.020 - Access levels''
The system implements 4 access levels that determine what is returned for each matching document:
1. Nothing
2. Count : a count of matched documents
3. Title : the title and link of matched documents
4. Full : the title, link and context of matched documents
The access level is determined in fall-back, that is, a user with Confidential clearance will have a nº3 (Title) access level over a Secret classified document and a nº2 (Count) access level over a Top Secret classified document.
''~FT-10.030 - Security areas''
The users have a, potentially different, security clearance level per area. The documents belong to an area.
Areas are business areas for instance Technical, Commercial, etc. They may also be organizational departments if needed.
''~FT-10.040 - Security defaults''
If a specific level is not attributed to a user in an area or to a document they default to the lowest level (Public).
The principle is that everything the system handles is Public until otherwise stated.
A document with no area is considered to belong to a General area.
''~FT-10.050 - User security clearance''
Each user shall have a security clearance level defined for each available security area.
If not defined defaults will be used as per ~FT-10.030 - Security defaults .
''~FT-10.060 - User security levels - persistence''
The system supports user security levels per area definition on LDAP.
Other methods shall be possible through adapter mechanisms.
''~FT-10.070 - Document security classification levels''
Each indexed document has a security classification.
If not defined defaults will be used as per ~FT-10.030 - Security defaults .
The security classification is determined at crawling (may be revised at Parsing) and indexed along the document.
The security classification may be determined by repository configuration or by rules over the document's properties (path, type, etc.).
''~FT-10.080 - Document area''
Each indexed document has an area.
If not defined defaults will be used as per ~FT-10.030 - Security defaults .
The area is determined at crawling (may be revised at Parsing) and indexed along the document.
The area may be determined by repository configuration or by rules over the document's properties (path, type, etc.).
''~FT-10.090 - Search service''
The search service is responsible for applying access levels to each returned match set on each search.
The access level nº2 counts shall be performed by page and state:
//"There was x additional matches found but not available for your clearance."//
----
Back to: [[KM Search and Index]]
----
/%
@@color:#c4d6ed; ^^
Description: Security guideline for a knowledge management system
^^@@
%/
!Knowledge management is a broad and important organisational area.
"//Knowledge management (KM) is the process of creating, sharing, using and managing the knowledge and information of an organisation. It refers to a multidisciplinary approach to achieving organisational objectives by making the best use of knowledge.//"
From [[Wikipedia|https://en.wikipedia.org/wiki/Knowledge_management]]
{{tw_ttoc{}}}
In most areas nobody doubts that knowledge is the most valuable asset of an organization. In most organizations knowledge is, also, stored on individual and unique people. This puts several challenges in areas like <<quote 'availability' 'Availability (KM)'>>, <<quote 'continuity' 'Continuity (KM)'>>, <<quote 'independence' 'Independence (KM)'>>, <<quote 'Continuous Improvement' 'Continuous Improvement (KM)'>> and others.
But also KM is, still today, regarded with some suspicion by management deciders. This may be due to some unrealistic expectations that, naturally, were not met in past endeavours. This is prompting the appearance of several new buzz words like //knowledge sharing//, or the more selective usage of KM's sub-domains like //expertise locator systems (ELS)//.
As in many other areas of organizational evolution the first caution is to consider that the real challenge is in devising and maintaining a system, not on selecting some technologies. Throwing technology on a problem is not, usually, a solution, especially in a ''people-centric problem'' like knowledge management. This being said, technology plays an important role in a KM system but it __shall be selected to potentiate and promote the system not to derive the system from it__. Also, a proper and full KM system for a specific organization can hardly be supported by any single of-the-shelf solution.
We will propose a knowledge management system, with some focus on software organizations, and, in each proper place suggest, available or bespoke, technological solutions to support and promote that system.
!Organisational knowledge dimensions
Knowledge may be seen through four fundamental dimensions:
- production
- storage
- retrieval
- development
These are interconnected and interdependent:
*You may produce and store lots of knowledge but, if nobody is able to retrieve it when needed, it is useless.
*You may produce lots of knowledge but if you do not store it it will fade away and eventually be lost.
*You may put in place excellent storage and retrieval mechanisms but if nobody produces knowledge they are useless.
*You may even be able to produce, store and retrieve knowledge but, if you are not able to maintain and update it, it will soon become obsolete and unmanageable.
These dimensions must be considered along __each and every step__ of the knowledge management process.
Lets look with more detail at each of the proposed dimensions.
!!Production
The first thing to consider is that knowledge is produced in an incremental fashion. It can not be seen only as a single task with a defined and final output. It is an iterative process whose results are much better in a collaborative, continuous improvement, environment.
Knowledge production must be encouraged and supported by collaboration tools and practices that remove obstacles and reward producers.
Knowledge must also be produced in an agile (or spiral) approach and have tools that support that approach, that is, tools that support a progressive and shared building, improvement and expansion of each and every knowledge item.
Today's mindset is much more oriented to produce basic elementary statements (think of Twitter) than to engage in true collaborative, incremental knowledge production, also the "blog" perspective is very limited as it encourages the expression of immature views that are seldom revisited, polished and improved. That's not knowledge but only data or information. If we want to produce knowledge we must acknowledge that it will take time and effort as well as collaboration and iterative improvement. ''The major challenge here (as in most other places) is people'' and their inhibitions and lack of argumentative training and practice. Most people is much more comfortable with consensual, useless, statements than with provocative thinking and laborious, time-consuming, iterative truth discovery through study, dialogue and even passionate discussion. But face it, the last is the only way to produce really useful and lasting knowledge.
The ''"definition of Done"'' for Knowledge is ''never''. A "done" knowledge piece is an obsolete and of little usefulness one. This presents a major challenge to knowledge support systems and to knowledge initiatives management. It takes courage, long-term vision, wisdom and experience to be able to embrace these challenges.
See [[KM Production]] for more details and requirements in this topic.
!!Storage
People's memory and experience are very good, but unreliable, storage mediums.
Personal knowledge, when you get to it, is excellent in compactness and relevance because it can understand your context and needs and provide experience. You will never want to dismiss expert knowledge. But as an organization you can not depend, exclusively, on specific people you must also have <<quote 'independent' 'Independence (KM)'>> knowledge.
See [[KM Storage]] for more details and requirements in this topic.
!!Retrieval
The retrieval ability is the best chance to achieve a continuous improvement of produced, stored and retrieved knowledge. It is also the retrieval ability that makes knowledge useful. Knowledge must be <<quote 'available' 'Availability (KM)'>> when needed if not it is just a waste of resources.
See [[KM Retrieval]] for more details and requirements in this topic.
!!Development
<<quote 'Standing on the shoulders of giants' 'Standing on the shoulders of giants'>>
In the development dimension we want to take every opportunity to improve and expand the available knowledge. For this agile tools are essential as those opportunities almost always emerge during other tasks and, if the effort required to utilize them is too much, people will stick to the task at hands and miss the opportunity. A system that promotes small but continuous incremental improvements to information and knowledge is the one that will prosper.
See [[KM Development]] for more details and requirements in this topic.
!Guidelines and resources
To manage anything you better know what it is first, so a good place to start is to define a proper [[ontology|http://en.wikipedia.org/wiki/Ontology_%28information_science%29]] for the domain. In our case a [[Software Development Ontology|SoftwareDevelopmentOntology]].
In an organization knowledge management needs a technological stack that supports its needs, operation and development. Our proposal is at [[KM Technical Stack]].
TODO: complete
TODO: graphs
----
<<TiddlerToC min-entries:1>>
/%
@@color:#c4d6ed; ^^
Description: Knowledge management main page
^^@@
%/
|Last 30 tiddlers created|Last 30 tiddlers modified|h
|<<ContentTimeline created 30>>|<<ContentTimeline modified 30>>|
----
@@color:#c4d6ed; ^^
Description: Shows the last updates in this wiki.
^^@@
/***
|''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);
}
//}}}
[[Home|HomePage]]
[[Software Development]]
[[Guidelines]]
[[Pearls]]
[[Software Tools|SoftwareToolsPage]]
[[Modelling References]]
[[Programming Topics]]
[[Knowledge Management|KnowledgeManagement]]
[[Privacy|PrivacyPage]]
[[Quotes|QuotesPage]]
[[Concepts|ConceptsPage]]
[[Bibliography|BibliographyPage]]
[[Selected References]]
TagPolicy
----
[[Android|AndroidPage]]
[[Travel|TravelPage]]
[[Internet|InternetPage]]
----
__''[[Last Updates|LastUpdates]]''__
----
[[Administration|AdministrationPage]]
<<option chkEnableTabsBar>> Tabbed navigation
DisplayOptions
^^TiddlyWiki
<<version>>
^^
<<unsavedChanges list "<br>">>
----
<html>
<!-- Start of SimpleHitCounter Code
<div align="center"><a href="http://www.simplehitcounter.com" target="_blank"><img src="http://simplehitcounter.com/hit.php?uid=2038168&f=16777215&b=0" border="0" height="18" width="83" alt="web counter"></a><br><a href="http://www.simplehitcounter.com" target="_blank" style="text-decoration:none;"></a></div>
End of SimpleHitCounter Code -->
</html>
Stats from
2021 03 11
<html>
<!-- ADAC From 20200703 COUNT 0 -->
<!-- hitwebcounter Code START -->
<div align="center"><a href="https://www.hitwebcounter.com" target="_blank">
<img src="https://hitwebcounter.com/counter/counter.php?page=7763272&style=0006&nbdigits=5&type=page&initCount=0" title="Free Counter" Alt="web counter" border="0" /></a></div>
<!-- http://s05.flagcounter.com/index.html START -->
<div align="center"><a href="https://info.flagcounter.com/E3cW"><img src="https://s01.flagcounter.com/count/E3cW/bg_BABABA/txt_000000/border_CCCCCC/columns_3/maxflags_30/viewers_0/labels_0/pageviews_0/flags_0/percent_0/" alt="Flag Counter" border="0"></a></div>
</html>
----
"//''Systems Analysis, or as it is increasingly known as today, Requirements Engineering, is a time consuming, expensive but critical phase in software (and system) development.''//"
[[SMART Requirements]] by <<BibRef "Mannion,Keepence 1995">>
----
/%
@@color:#c4d6ed; ^^
Description: Mannion and Keepence on requirements effort
^^@@
%/
//"The [[meta-architecture|http://www.bredemeyer.com/ArchitectingProcess/MetaArchitecture.htm]] collects together decisions relating to your architecture strategy. It sets direction for your architecture effort, with high-level decisions that will shape the architecture and guide the architects. These include architecture principles, statements of philosophy, metaphors and organizing concepts that will guide system decomposition and design of architectural mechanisms."//
Meta-architecture is a concept of [[VAP - Visual Architecting Process|http://www.bredemeyer.com/ArchitectingProcess/VisualArchitectingProcess.htm]] by Ruth Malan and Dana Bredemeyer.
Meta architecture harmonization and sharing is a key aspect of [[Implementing Systematic Reuse]] and it is also a main target and indicator of the Methodological stage in the Reuse Maturity Model. Meta-architectural matching is a primary indicator of reusability when accessing a potential reusable asset.
----
See also: [[Namespace and Filesystem Guidelines]] [[Namespace Coupling Guidelines]]
----
/%
@@color:#c4d6ed; ^^
Description: Meta-architecture concept explanation and references.
^^@@
%/
* [[Ongoing References]] - list of ongoing study references
!!General UML diagrams
* [[The Unified Modeling Language|http://www.uml-diagrams.org/]]
!!Data Flow Diagrams
* [[Data Flow Diagram]] - Data Flow Diagrams (DFD) were proposed as the essential view in the historical Structured Analysis and System Specification by Tom ~DeMarco, Yourdon Press, New York, 1978.
!!Use Case Diagrams
* [[Use Case Diagram]] - Use Case Diagrams (UC) are a very useful communication mean to use with users and stakeholders.
!!Application Archetype
* [[Application Archetype]] - illustrates the fundamental tier and layer organization of a software architecture.
!!Component Diagrams
* [[UML basics: The component diagram|http://www.ibm.com/developerworks/rational/library/dec04/bell/index.html]] - From The Rational Edge: This article introduces the component diagram, a structure diagram within the new Unified Modeling Language 2.0 specification. - Donald Bell (bellds@us.ibm.com), IT Architect, IBM Corporation
!!Sequence diagrams
* [[UML Tutorial: Sequence Diagrams - Robert C. Martin - 1998|https://web.archive.org/web/20070820035259/http://www.objectmentor.com/resources/articles/UMLSequenceDiagrams.pdf]] - In this column we will be discussing UML Sequence diagrams. Sequence diagrams contain the same information as Collaboration diagrams, but emphasize the sequence of the messages instead of the relationships between the objects.
* [[UML basics: The sequence diagram|http://www.ibm.com/developerworks/rational/library/3101.html]] - From The Rational Edge series of articles, .UML basics, on the essential diagrams in the Unified Modeling Language, this article offers a detailed introduction to the sequence diagram. It also introduces several new notation elements in the recent UML 2.0 specification. - Donald Bell (bellds@us.ibm.com), IT Architect, IBM Corporation
!!CASE Tools
* [[Sparx Enterprise Architect]] - a comprehensive tool that can handle almost all modelling elements and scenarios. This tiddler also lists all my articles on <<tag EA>> usage.
* [[Sybase|http://www.sybase.com/]] [[Power Designer|http://www.sybase.com/products/modelingdevelopment/powerdesigner]] - the best tool for data modelling. Conceptual and physical models and full round-trip engineering.
----
@@color:#c4d6ed; ^^
Description: Unified Modelling Language (and others) references
^^@@
Modularization is, probably, the most important choice you will make on structuring, specifying and implementing a solution. Its impacts, good or bad, will affect [[validation|Validation]] and [[verification|Verification]] ability, [[reuse|Reuse]], maintainability, robustness, [[refactorability|Refactor]] and all the other important aspects that define the overall quality of your solution.
If I had to choose just one quality for a software project I would not doubt : good modularization. Everything else is meaningless without it. The sheer size of any software project is not humanely manageable without proper modularization.
!What is modularization
"The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules." <<BibRef "Parnas 1972">>
Modularization is a division of complexity, based on criteria, that produces an [[abstract|Abstraction]] structure.
But modularization is also the containment of change impact through [[information hiding|Information Hiding]] and [[coupling|Coupling]] minimization through [[encapsulation|Encapsulation]]. See <<BibRef Berard>>.
Criteria (plural) are the essential condition to have modularization and not a random split of topics that no one is able to navigate. But notice that you will have several levels of modularization each one with one different criterion (singular), for instance you are likely to have a first level modularization based on tier physical separation and then progress to further levels based, for instance on business or functional domains (see [[Namespace and Filesystem Guidelines]]).
!The many contexts of modularization
!!Modularization at Analysis
The first thing to do when facing a 'big problem' is to split it in several 'smaller problems'. This is common sense from many centuries now, consider [[Rene Descartes' |http://www.marxists.org/reference/archive/descartes/1635/discourse-method.htm]] second principle "//''The second, to divide each of the difficulties under examination into as many parts as possible, and as might be necessary for its adequate solution.''//"
At analysis you will want to start build a conceptual framework for the domain at hands and so you will start identifying conceptual topics for each subject you may address in relative isolation, this is an essential step to avoid being overwhelmed by the problem's magnitude. This will also be your table of contents for navigating information and your [[coverage|Coverage]] (completeness) checklist.
!!Modularization at Specification
Conceptualization of a solution is the first step to be able to cope with complexity and to work in a team with the communication needs it involves. A good concept is worth a thousand words...
At specification you have many goals to achieve besides being able to communicate efficiently. The [[Object Oriented Design|OOP]] principles give you some.
!!Modularization at Construction
Filesystem and namespace rules play an essential role in preventing obstacles to and promoting many of the most important software qualities. A well structured filesystem and namespace is essential for maintainability, coupling control, cohesion, refactorability, testability and many other qualities. Be sure to establish a set of comprehensive and well reasoned [[Namespace and Filesystem Guidelines]]
TODO: packaging principles
----
See also : [[Application Archetype]] [[Coupling]] [[Cohesion]]
@@color:#c4d6ed; ^^
Description: Modularization concept explanation.
^^@@
On developing we produce different types of code in what generalization (and, as such, re-usability) is concerned :
* ''Sub-systems'' : These are highly <<quote 'cohesive' 'Cohesion>> modules with no <<quote 'coupling' 'Coupling>>. They do one thing and do it well without any external dependencies. This code is highly reusable and shall also be well <<quote 'encapsulated' 'Encapsulation>> and exposed through an as simple as possible <<quote 'API' 'API'>>. Sub-systems shall have a single responsibility with clear input and output. Think of a Logging sub-system, for instance, although it may perform several functions like information gathering, formatting and persisting it shall not extend its responsibilities to alarm triggering or corrective control, that shall be other module's responsibility.
* ''Generic code'' : is, mostly, the old functional library concept and Interfaces (pure abstract classes). It shall have simple and objective responsibilities. Coupling shall be kept to a minimum. Think of a mathematical functions library, a recursive filesystem traverse function, etc.
* ''Base code'' : shall have strong functional [[cohesion|Cohesion]] but is intended to be the generic base for specialization at platform.
* ''Platform code'' : introduces advanced automation, that is, it assumes a specific architecture, data structures and functionality and provides most of the technical requirements for its intended domain. It also integrates and orchestrates all the more generic code to provide a base ready to be specialized.
* ''Specialized code'' : specializes and overrides Platform and produces a specific solution for a specific project's business needs (with more or less customization ability).
----
See also [[Namespace and Filesystem Guidelines]], [[Namespace Coupling Guidelines]] and [[Promoting Reuse by Reference]]
----
@@color:#c4d6ed; ^^
Description: Guidelines for namespace code placement
^^@@
Strong [[cohesion|Cohesion]] and loose [[coupling|Coupling]] are a good thing in software design. On defining a good structure for your namespaces you will also be preventing "spaghetti coupling" and, to some extent, weak cohesion.
Coupling is not easy to [[refactor|Refactor]] as it involves moving code (and files) around. This usually messes up [[CVS]] and has large impact specially on reused code. This shall encourage you to clearly think ahead and establish your namespace coupling rules.
<<Image "FR" "250" "Coupling-root-level.png" "https://dl.dropbox.com/" "s/vfki4dkx343k4ut/" "?dl=1" "Root level allowed dependencies.">>
Your [[Meta-architecture]] shall address the Coupling control strategy by establishing clear rules about allowed dependencies between your namespaces.
Start at ''root level'' and define the allowed dependencies. Remember that you want your project's code to depend from your reusable code and both of them to depend from third-parties. Of course the inverse is not allowed as you want to keep reusable elements decoupled from specializations.
<<Image "FR" "250" "Coupling-reusable-code.png" "https://dl.dropbox.com/" "s/ayuutnc6sl4bha3/" "?dl=1" "Reusable code allowed dependencies.">>
Inside ''reusable code'' you shall promote a dependency hierarchy where the more specialized can depend from the more generic. Remember that your goal is to reduce reuse obstacles to the minimum possible.
See [[Namespace and Filesystem Guidelines]] for a rationale of the FRW, CMP and SYS division and [[Namespace Code Placement Guidelines]]. Of course you may use other if that makes more sense in your scenario.
Notice also that the same conceptual module (for instance ~ErrorHandling) may, and probably shall, have instances at different generalization layers (one generic instance in CMP to deal with basic catching and display and one more specialized instance at FRW that introduces context analysis for instance).
<<Image "FR" "250" "Coupling-tier-level.png" "https://dl.dropbox.com/" "s/hu07f3mq7229uce/" "?dl=1" "Tier level allowed dependencies.">>
Finally you shall consider to keep a strict ''tier level'' separation. Remember that tier level exists everywhere except on ~ThirdParties (and even here we could consider to implement it as second level). Again it is essential to promote a [[modularization|Modularization]] that favours reuse.
A conceptual module (for instance ~ErrorHandling at the component CMP layer) may have physical modules at ''Common'', ''Server'' and ''Client'' tiers (the catching code at Common and the dialogue for user display at Client and eventual server-only code at Server ).
----
See also : [[Namespace and Filesystem Guidelines]], [[Namespace Code Placement Guidelines]] and [[Promoting Reuse by Reference]]
----
@@color:#c4d6ed; ^^
Description: Guidelines for namespace coupling control.
^^@@
!! Why do you need Filesystem and Namespace Guidelines
Filesystem and Namespace Guidelines shall be a mandatory (and reusable) part of your [[Meta-architecture]]. These are strategic decisions that will affect all of your project in very important qualities like reusability, maintainability, modularization and team work efficiency. You can survive without them in a single man small project, but will need them as a roadmap for design and implementation and as an enforcing mechanism for your [[Application Archetype]] among your team.
!! Filesystem, namespaces and packaging
First of all, filesystem, namespaces and packaging shall be equivalent. This is important for search ability on the code and avoids incoherence and naming clashes when reusing.
{{{
Filesystem :
C:\source\AdacSoft\ProjectX\Server\DAO
shall contain namespace :
AdacSoft.ProjectX.Server.DAO
that is packaged in DLL :
AdacSoft.ProjectX.Server.DAO.dll
}}}
This simple rule will save you a lot of trouble when developing and maintaining your code on a team. With this you define packaging, placement and conceptual [[modularization|Modularization]] at the same time. The binary naming also plays an important role when you need to dynamically discover and load ~DLLs based on a namespace. DLL name may be shorter than namespace, that is, {{{AdacSoft.ProjectX.Server.DAO.SQLite}}} may be contained in {{{AdacSoft.ProjectX.Server.DAO.dll}}}.
!! Filesystem definition
You shall have a standard base filesystem structure that you reuse and follow in every one of your projects. And you shall, definitely, use a [[CVS]] system. See [[Promoting Reuse by Reference]] guideline for a detailed filesystem and reuse structure proposal.
!! Namespace definition
For defining namespace you shall also follow defined and well understood rules.
First you want it to be different to avoid conflicts and to promote your brand so you should use your company name as root. You shall also consider using third-party components and also to segregate your own reusable components, so you may have two other root level items :
*''[~YourCompanyName]'' : for your project's root.
*''[~YourCompanyAcronym]'' : for your own reusable modules.
*''[~ThirdParties]'' : for external, off-the-shelf components. The second level shall be producer name and the third product name for instance {{{ThirdParties.Apache.Log4Net}}}
These guidelines have an huge impact in management and maintenance of your [[CVS]] repository and also help in preventing [[reuse by copy|Reuse by Reference]].
Then you want to distinguish your different projects so the second level shall be project name.
At the third level you shall be concerned with coupling control and tier segregation to handle strict n-tier scenarios.
You shall stick to this organization even if your code is single tier. Think about it being reused in a n-tier scenario or if you want to reuse n-tier code. Also this encourages good [[modularization|Modularization]] and thus [[coupling control|Namespace Coupling Guidelines]].
The fourth level shall represent your conceptual modules (Components or archetype parts). This shall be a technical (Architectural) criterion.
From the fourth level onwards common sense applies, don't go too deep, divide if you have to, you may use technical, business or any other criteria but be coherent and explicit.
Your namespaces shall then be built according to :
{{{
{Root level}.{Project/Product level}.{Tier level}.{Module level}
}}}
* ''Root level''
** Root level shall reflect ownership.
*** ''[~YourCompanyName]'' for specific project/product resources
*** ''[~YourCompanyAcronym]'' for reusable, shared among projects, resources
*** ''[~ThirdParties]'' for third-party resources. You may choose to use third party company name at this level but it will clutter root.
* ''Project/Product level''
** This second level is dependant on the previous one and shall reflect domain or coupling layer separation.
** For ''[~YourCompanyName]'' root :
*** [Project Code] - for "normal" projects
*** [Product Name] - for products
** For ''[~YourCompanyAcronym]'' root :
*** ''CMP'' is intended to hold reusable modules that are independent from particular architectures but that may be strongly coupled to other CMP modules.
*** ''FRW'' is intended to hold reusable modules that are strongly coupled and that require a specific architecture. This layer encourages strong automation.
*** ''SYS'' is intended to hold reusable modules that are loosely coupled and that shall be seen as autonomous subsystems.
** For ''[~ThirdParties]'' root :
*** This shall be manufacturer name followed by the item namespace
*** The ~ThirdParties root level has no further guidelines after 2nd level and shall conform to producer specifications. Example {{{Apache.log4net}}}
* ''Tier level''
** ''Client'' : client side code, may depend on Common, interacts with user.
** ''Common'' : common code, may not depend on any of the others, may not interact with user.
** ''Server'' : server side code, may depend on Common, may not interact with user.
* ''Module level''
** From module level onwards common sense rules apply.
** You may use Business Domain or sub-Domain criteria or Technical Domain or both.
----
See also : [[Namespace Coupling Guidelines]], [[Namespace Code Placement Guidelines]] and [[Promoting Reuse by Reference]]
----
@@color:#c4d6ed; ^^
Description: An example Filesystem and Namespace Guideline for .Net projects.
^^@@
"//''There is no single development, in either technology or management
technique, which by itself promises even one order-of-magnitude
improvement within a decade in productivity, in reliability, in simplicity. ''//"
[[No Silver Bullet - Essence and Accident in Software Engineering |http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf]] ([[on WayBack Machine|https://web.archive.org/web/*/http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf]])
[[Frederick P. Brooks|http://en.wikipedia.org/wiki/Fred_Brooks]]
Also on [[Wikipedia|https://en.wikipedia.org/wiki/No_Silver_Bullet]]
----
/%
@@color:#c4d6ed; ^^
Description: Quote of Frederick P. Brooks No Silver Bullet
^^@@
%/
!Tag page for OOP (Object Oriented Programming)
[[From Wikipedia, the free encyclopedia|http://en.wikipedia.org/wiki/Object-oriented_programming]] - Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as [[data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance|ObjectOrientedProgramming]]. Many modern programming languages now support OOP, at least as an option.
The main entry point for the subject on this wiki is [[Object Oriented Programming|ObjectOrientedProgramming]] page.
[[Modularization]] is, probably, the most important choice you will make on structuring, specifying and implementing a solution. Its impacts, good or bad, will affect [[validation|Validation]] ability, reuse, maintainability, robustness, refactorability and all the other important aspects that define the overall quality of your solution.
It will also play a key role in the management ability of your project, planning, testing, delivery and other tasks are dependent on the quality of your modularization, progress reporting and evaluation, task assignment and know-how selection and almost any other development aspect will favourably or adversely be affected by it.
The first, easiest and with more immediate return investment in modularization is to define, and closely enforce, a clear set of guidelines to be followed by the development team. These guidelines must encompass [[Namespace and Filesystem Guidelines]], [[Namespace Coupling Guidelines]] and [[Namespace Code Placement Guidelines]].
!!Fundamental concepts
* ''[[Abstraction]], [[Encapsulation]] and [[Information Hiding]]'' - The fundamental reference is [[Abstraction, Encapsulation, and Information Hiding|http://www.tonymarston.co.uk/php-mysql/abstraction.txt]] By Edward V. Berard, The Object Agency <<BibRef Berard>>
!!Principles
* Packaging (or modularization)
** [[Stable Dependencies Principle]]
----
See also [[Programming Links|ProgrammingLinksPage]]
----
@@color:#c4d6ed; ^^
Description: Object Oriented Programming topics.
^^@@
|Area|Title|Year|Description|Notes|DOI|Rating|h
|Model Centric|[[A Quantitative SWOT-TOWS Analysis for the Adoption of Model-Based Software Engineering|https://www.jot.fm/issues/issue_2022_04/article9.pdf]]|2022|Enterprises’ trend to low-code development revives model-based software engineering (MBSE) since several low-code platforms are based on the principles of model-based design, automatic code generation, and visual programming.|Interesting factors for model based adoption.|[[10.5381/jot|http://dx.doi.org/10.5381/jot.2022.21.4.a9]]||
----
/%
@@color:#c4d6ed; ^^
Description: Ongoing study references list
^^@@
%/
''Opportunistic Productization is a disciplined management and engineering activity oriented to achieve scale savings and continuous improvement on the opportunity to produce similar solutions for different customers.''
Opportunistic Productization may be seen as an higher level [[Systematic Reuse]].
The concept is useful for project-oriented software houses. It cames into play when you have a Customer request that is similar to something you already developed for another Customer.
In these scenarios you have an opportunity and several dangers.
The opportunity is to evolve your solution to near an off-the-shelf, high quality, product you will be able to resell more times with almost no cost and very good Customer satisfaction levels.
The dangers are that you will ''dump price'' (and Customer's perceived value for the solution) and engage in a series of adaptation hacks that, ultimately, will became more expensive than a complete reimplementation. The second risk is that, if you are lucky in the first hack, you will try a second based on the same estimation. This is a severe mistake as [[software rot|Software Rot]] happened for sure in the first adaptation and is more than likely to increase at the second.
Opportunistic Productization may lead to a full Product Development process but not necessarily. Product Development is a different, and with different methods and techniques, activity.
<<Image "FR" "250" "Gartner-magic-quadrant-animated.gif" "https://dl.dropbox.com/" "s/pl96dh24fvq83r6/" "?dl=1" "Gartner magic quadrants">>
If, in a second, similar, sell you do not have resources for more, at least encourage your team to establish a clear [[Application Archetype]] and [[refactor|Refactor]] what they can towards better [[encapsulation|Encapsulation]] and [[modularization|Modularization]].
In the image on the right you can see an animation using [[Gartner Magic Quadrants|http://www.gartner.com/technology/research/methodologies/research_mq.jsp]] that illustrates your product position along several opportunistic productization cycles. If you took the opportunity your vision and your realisation ability increased so you can now aim to the top right corner. At this point, unless you exhausted the market, productization ability is no longer just an hypotheses, it is a proved fact, now you should consider a proper Product Development Process.
The number of cycles may vary depending on your investment and on the characteristics of the project and the market it targets.
One good rule of thumb to access the quality of a second productization effort is that the results shall be seen as an upgrade opportunity for the prior Customers, that is, the results are more customizable and increased in overall quality. To achieve this you should assure that, at least, technical management stays the same across projects. You must also assure that some, if not all, of the reuse savings are invested in improving the (to be) product.
----
@@color:#c4d6ed; ^^
Description: Opportunistic Productization concept explanation,
^^@@
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]]
PERT - Program (or Project) Evaluation and Review Technique
//PERT is a method to analyze the involved tasks in completing a given project, especially the time needed to complete each task, and to identify the minimum time needed to complete the total project.
PERT was developed primarily to simplify the planning and scheduling of large and complex projects. It was developed for the U.S. Navy Special Projects Office in 1957 to support the U.S. Navy's Polaris nuclear submarine project. It was able to incorporate uncertainty by making it possible to schedule a project while not knowing precisely the details and durations of all the activities.
(...)
Through an electronic computer, the PERT technique processes data representing the major, finite accomplishments (events) essential to achieve end-objectives; the inter-dependence of those events; and estimates of time and range of time necessary to complete each activity between two successive events. Such time expectations include estimates of ''"most likely time"'', ''"optimistic time"'', and ''"pessimistic time"'' for each activity.
//
From [[Wikipedia|http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique]]
----
/%
@@color:#c4d6ed; ^^
Description: Program (or Project) Evaluation and Review Technique
^^@@
%/
Project Manager
----
/%
@@color:#c4d6ed; ^^
Description: Project Manager
^^@@
%/
/***
|''Name''|PaletteViewMacro|
|''Version''|0.2|
|''Author''|FND|
|''Source''|[[FND's DevPad|http://devpad.tiddlyspot.com/#PaletteViewMacro]]|
|''License''|[[Creative Commons Attribution-ShareAlike 3.0 License|http://creativecommons.org/licenses/by-sa/3.0/]]|
|''~CoreVersion''|2.1|
|''Type''|macro|
|''Requires''|N/A|
|''Overrides''|N/A|
|''Description''|Displays color palettes.|
!Notes
There is also [[ViewPalettePlugin|http://simon.tiddlyspot.com/#ViewPalettePlugin]], which currently does not work with TiddlyWiki v2.2 though.
!Usage
{{{
<<paletteView [tiddler name]>>
}}}
!!Example
<<paletteView [[ColorPalette]]>>
!Revision History
!!v0.1 (2007-11-18)
* initial release
!!v0.2 (2007-11-20)
* limited processing to slices containing [[actual color values|http://www.w3.org/TR/CSS21/syndata.html#color-units]]
* changed fallback value to the tiddler the macro is called from (instead of using [[ColorPalette]])
!To Do
* selection list for all available palettes (tag-based)
* parameter for custom table class
* customizable column order
* documentation (e.g. using from within [[ViewTemplate]])
!Code
***/
//{{{
config.macros.paletteView = {};
config.macros.paletteView.handler = function(place, macroName, params, wikifier, paramString, tiddler) {
var title = params[0] || tiddler.title;
//var palettes = store.getTaggedTiddlers(params[0]); // DEBUG: yet to be implemented
var colors = store.calcAllSlices(title);
var labels = [];
for(var c in colors) {
if(this.isColor(colors[c])) {
labels.push(c);
}
}
if(labels.length > 0) {
var output = "|!Sample|!Value|!Name|h\n";
for(var i = 0; i < labels.length; i++) {
output += "|padding:0 4em;background-color:" + colors[labels[i]] + "; |"
+ "{{{" + colors[labels[i]] + "}}}|"
+ "[[" + labels[i] + "|" + title + "]]|\n";
}
wikify(output, place);
}
};
config.macros.paletteView.isColor = function(s) {
var colors = ["Black", "Green", "Silver", "Lime", "Gray", "Olive", "White", "Yellow",
"Maroon", "Navy", "Red", "Blue", "Purple", "Teal", "Fuchsia", "Aqua", "Orange"];
var match = s.match(/^#[0-9A-F]{3}$|^#[0-9A-F]{6}$|^RGB\([\d,\s]{5,}\)$/i);
if(match) return true;
if(colors.contains(s)) return true;
return false;
};
//}}}
/***
|''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"
});
*/
//}}}
These are assorted wisdom pearls that I collect from many places.
!!Software Engineering
*[[sd&m Conference 2001, Software Pioneers|https://www.software-pioneers.com/en/conference]] - One of the best software engineering conferences ever.
!!Systems and Quality
*[[Russell L. Ackoff|https://en.wikipedia.org/wiki/Russell_L._Ackoff]] : [[If Russ Ackoff had given a TED Talk...|https://www.youtube.com/watch?v=OqEeIG8aPPk]] - Simply amazing! Enlightening! The absolute fundamentals of Systems Thinking and Continuous Improvement in under 15 minutes.
----
/%
@@color:#c4d6ed; ^^
Description: A collection of wisdom pearls. Things like this make life worth living.
^^@@
%/
<<Image "FL" "" "logo-shadow.png" "http://pencil.evolus.vn/" "styling/images/" "" "">> <<Image "FR" "" "home-ss.jpg" "http://pencil.evolus.vn/" "images/" "" "">>
[[Pencil Project|http://pencil.evolus.vn/]] - //An open-source [[GUI]] prototyping tool that's available for ALL platforms. Pencil is built for the purpose of providing a free and open-source GUI prototyping tool that people can easily install and use to create mockups in popular desktop platforms.//
* [[Google Code stencil download page for Pencil|http://code.google.com/p/evoluspencil/downloads/list?q=label:Stencil]].
* [[Google Code template download page for Pencil|http://code.google.com/p/evoluspencil/downloads/list?q=label:Template]].
Pencil is a very useful tool for sketching GUI elements. These are a very important way of validating intended and expected user interaction.
----
See also : [[EA Usage - Alternate Image]] [[GUI mockup]]
----
/%
@@color:#c4d6ed; ^^
Description: Pencil - GUI modelling free and open-source tool
^^@@
%/
//"Precision is the percentage of documents in the returned results that are relevant."//
[[Apache Solr Reference Guide 6.0|https://lucene.apache.org/solr/guide/]]
----
See also: [[Recall (KM)]] [[Relevance (KM)]]
----
/%
@@color:#c4d6ed; ^^
Description: Precision concept on knowledge management
^^@@
%/
<<Image "FL" "182" "universal-declaration-human-rights.jpg" "http://www.un.org/sites/www.un.org/files/2015/10/07/" "" "">>
''[[The Universal Declaration of Human Rights|http://www.un.org/en/universal-declaration-human-rights/index.html]]''
''Article 12.''
''// No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.//''
Always connected actual reality is frightening. People you do not know from anywhere is constantly monitoring where you are, what you do, to whom you talk, what you read and so many other aspects of your life that we can not even imagine.
Cloud, mobile ~OSs, like Google Android and IOS, completely remove your control over to whom you, or your devices and software, interact with. They say that you can control but, in fact, the choice is an "all or nothing", if you want to use an application you must grant it all privileges even if you do not want or need to use some of them.
There are lots of examples. MS ~OneNote mobile only works with cloud storage and not with local files. Why? Android devices treat you not as the device owner but as a very limited user with very limited control and knowledge of what's really happening with your data. Any mobile application now requests network access, to display advertising they say, and what else?
The question here is not if ''I do have something to hide'' the question here is that ''I consider my right to have something to hide'', and that is being taken away from me.
I'm starting a systematic approach to protect my privacy in the devices and software I use and I'll try to share those techniques and tools here.
|Type|Name|Description|h
|Browsing|[[Tor Browser|https://www.torproject.org/projects/torbrowser.html.en]]|The Tor Browser lets you use Tor on Windows, Mac OS X, or Linux without needing to install any software. It can run off a USB flash drive, comes with a pre-configured web browser to protect your anonymity, and is self-contained (portable).|
|E-mail service|[[Tutanota|https://tutanota.de]]|Secure every message with automatic encryption. Tutanota protects your data by encrypting subject, content and attachments of emails. Tutanota automatically encrypts all your data on your device. Your emails as well as your contacts stay private. You can easily communicate with any of your friends end-to-end encrypted. Even subject and attachments as well as all your contacts are encrypted.|
|Messaging|[[Jami|https://jami.net/]]|Share, freely and privately.<br> Available on Linux, Android, ~AndroidTV, Windows, macOS and iOS. <br>No personal information needs to be provided when creating an account. <br>All communications are peer-to-peer and end-to-end encrypted.|
|Track control|[[NoScript|https://noscript.net/]]|~NoScript Firefox extension provides extra protection for Firefox, Seamonkey and other mozilla-based browsers: this free, open source add-on allows ~JavaScript, Java, Flash and other plugins to be executed only by trusted web sites of your choice (e.g. your online bank).|
|~|[[Privacy Badger|https://www.eff.org/privacybadger]]|Privacy Badger is a browser add-on that stops advertisers and other third-party trackers from secretly tracking where you go and what pages you look at on the web. Privacy Badger learns about trackers as you browse. For Firefox, Opera and Chrome.|
|Track detection|[[Lightbeam|https://www.mozilla.org/en-US/lightbeam/]]|Lightbeam is a Firefox add-on that uses interactive visualizations to show you the first and third party sites you interact with on the Web. As you browse, Lightbeam reveals the full depth of the Web today, including parts that are not transparent to the average user. <br> [[Lightbeam extension for Firefox is no longer supported|https://support.mozilla.org/en-US/kb/lightbeam-extension-firefox-no-longer-supported]]|
|~|[[Lightbeam 3.0|https://addons.mozilla.org/en-US/firefox/addon/lightbeam-3-0/]]|by Princiya <br> I have been involved with Lightbeam since 2017 through Outreachy and ~PrototypeFund.de programs. I now take responsibility to maintain this web extension! <br> [[On GitHub|https://github.com/mozilla/lightbeam-we]]|
|~|[[BrowserLeaks|https://browserleaks.com/]]|~BrowserLeaks.com — It's all about Web Browser Fingerprinting. Here you will find the gallery of web browser security testing tools, that tell you what exactly personal identity data may be leaked without any permissions when you surf the Internet.|
|~|[[TcpLogView|http://www.nirsoft.net/utils/tcp_log_view.html]]|TcpLogView is a simple utility that monitors the opened TCP connections on your system, and adds a new log line every time that a TCP connection is opened or closed. For every log line, the following information is displayed: Even Time, Event Type (Open, Close, Listen), Local Address, Remote Address, Remote Host Name, Local Port, Remote Port, Process ID, Process Name <br> Run this and get scared at the level Windows exposes You.|
|~|[[IPNetInfo|http://www.nirsoft.net/utils/ipnetinfo.html]]|IPNetInfo is a small utility that allows you to easily find all available information about an IP address: The owner of the IP address, the country/state name, IP addresses range, contact information (address, phone, fax, and email), and more.|
|Android Firewall|[[NetGuard|http://www.netguard.me/]]|~NetGuard provides a simple way to block access to the internet - no root required. Applications can individually be allowed or denied access to your ~WiFi and/or mobile connection.|
|~|[[AFWall+|https://github.com/ukanth/afwall]]|Android Firewall+ is an advanced iptables editor (GUI) for Android. It provides fine-grained control over which Android apps are allowed to access the network.|
|Internet Search|[[SwissCows|https://swisscows.ch/]]|Privacy safe ~WEB-search. A good alternative to advertisement oriented search engines like Google.|
|~|[[search.privacytools.io|https://search.privacytools.io/]]|Powered by searx - Searx is a free internet metasearch engine which aggregates results from more than 70 search services. Users are neither tracked nor profiled. Additionally, searx can be used over Tor for online anonymity.|
|OS Privacy|[[W10Privacy|https://www.winprivacy.de/english-home/]]|The by default highly questionable set options concerning privacy and data protection in Windows 10 make this program a __MUST__ for every user. The program is a help, to display the available settings relatively clearly and to set the desired options if necessary.|
!Sites on privacy
* [[privacytools.io|https://www.privacytools.io/]] - You are being watched. Private and state-sponsored organizations are monitoring and recording your online activities. privacytools.io provides services, tools and knowledge to protect your privacy against global mass surveillance.
* [[EFF|https://www.eff.org/]] - Electronic Frontier Foundation. The leading nonprofit defending digital privacy, free speech, and innovation.
* [[Humane Tech Community|https://github.com/humanetech-community]] - promoting solutions that improve wellbeing, freedom and society.
----
/%
@@color:#c4d6ed; ^^
Description: Privacy related matters page
^^@@
%/
!Database programming
!!Paradigms and approaches
There are a lot of approaches for data persistence. Depending on the exploration scenario some are better than others.
Following are some worth reading articles on the subject :
|Author|Date|Title|Resume|h
|Martin Kleppmann|2015|[[Stream processing, Event sourcing, Reactive, CEP… and making sense of it all|https://www.confluent.io/blog/making-sense-of-stream-processing/]]|An excellent and complete article about available persistence approaches. A must read!|
!!Keys
Record identification and ID generation and strategy is a major choice when designing a database.
!!!GUID
Global Unique Identifiers (aka UUID on Java world) present some very attractive advantages to database keys but they have some drawbacks also.
The main advantages of using ~GUIDs are related to integration and distributed and briefcase model applications. Using ~GUIDs allows for concurrent creation of items without key clash. But using ~GUIDs (really using, that is, they are single primary keys and any relationship uses them and not some business alternate key) also follows some good programming principles.
* <<quote 'Stable Dependencies Principle' 'Stable Dependencies Principle'>> : as they are not business driven or dependent they can be much more stable than any business key that can change out of our control.
* <<quote 'Encapsulation' 'Encapsulation'>> : being business independent they present "a protection layer" that shields our systems from changes in business rules or errors and variance in human input.
Following are some worth reading articles on the subject :
|Author|Date|Title|Resume|h
|Jeremy Todd|2013|[[GUIDs as fast primary keys under multiple databases|http://www.codeproject.com/Articles/388157/GUIDs-as-fast-primary-keys-under-multiple-database]]|This article outlines an approach for using GUID values as primary keys/clustered indexes that avoids most of the normal disadvantages, adapting the COMB model for sequential GUIDs developed by Jimmy Nilsson in his article The Cost of GUIDs as Primary Keys. While that basic model has been used by a variety of libraries and frameworks (including NHibernate), most implementations seem to be specific to Microsoft SQL Server. This article attempts to adapt the approach into a flexible system that's can be used with other common database systems such as Oracle, PostgreSQL, and MySQL, and also addresses some of the eccentricities of the .NET Framework in particular.|
|Jimmy Nilsson|2002|[[The Cost of GUIDs as Primary Keys|http://www.informit.com/articles/article.aspx?p=25862]]|In this article, Jimmy Nilsson presents the pros and cons of using globally unique identifiers (GUIDs) as the datatype for primary keys in SQL Server 2000. In doing so, he shows you test results that hint of performance characteristics and introduces you to a special type of GUID that he invented, called COMBs, that solves what otherwise might give you a big throughput problem.|
|||||
----
@@color:#c4d6ed; ^^
Description: Database programming main page.
^^@@
This page lists my selection of the finest programming tools I've used.
!! CASE
* [[Sparx Enterprise Architect]] - The best, full process, modelling tool by far.
* [[Sybase Power Designer]] - Essential for database moddeling.
!! Static Analysis
* [[Source Monitor]] - The freeware program Source Monitor lets you see inside your software source code to find out how much code you have and to identify the relative complexity of your modules. Web site : [[Campwood Software|http://www.campwoodsw.com/sourcemonitor.html]]
!! Diff & merge
* [[Araxis Merge]] - Advanced 2 and 3-way file comparison (diff), merging and folder synchronization. [[Web site|https://www.araxis.com/merge/index.en]]
----
/%
@@color:#c4d6ed; ^^
Description: This page lists my selection of the finest programming tools I've used.
^^@@
%/
*[[Database Programming|Programming Database]]
----
* [[Object Oriented Programming (OOP)|ObjectOrientedProgramming]] - concepts and thoughts about this essential paradigm.
* [[Development Links]] - a collection of worth visiting links.
Some tools I made that you may find interesting
* [[ASPerfBench]] - small tool to allow for quick assessment of .Net code relative performance.
----
@@color:#c4d6ed; ^^
Description: Programming main page
^^@@
I do program software for living and even get paid for it ;) .
* [[Business Analysis|Business Analysis]] - first the problem then the solution.
* [[Software Specification|SoftwareSpecification]] - ask for things in the right way if you want them to be done well.
* [[Object Oriented Programming (OOP)|ObjectOrientedProgramming]] - concepts and thoughts about this essential paradigm.
* [[References|ReferencesPage]] - a collection of worth visiting links.
Some tools I made that you may find interesting
* [[ASPerfBench]] - small tool to allow for quick assessment of .Net code relative performance.
----
[[Reuse by Reference]] has to face several obstacles and, if not properly planned and supported, will produce a nightmare in maintenance and development. But, on the other hand, [[Reuse by Reference]] is the only way to achieve [[Continuous Improvement]] on reusable assets and to capitalize inter-project and inter-team synergies. That's the difference between a solo freelancer developer and a team in a solid and mature company.
This approach assumes you are using a proper [[CVS]] system that holds all your project's data and reusable assets. See [[Concurrent Versioning System]].
!!Filesystem
The first concern shall be to put in place a proper filesystem structure and reuse strategy that is used, known, and enforced, among all your projects. Your filesystem structure and reuse strategy shall be part of your shared infrastructure specification.
The filesystem shall have folders for, among others, specification items, quality management, project plans and, of course, code. Inside the code folder you must use relative paths for your dependencies and, if you want to share reusable code, you may use the CVS system to produce something like symbolic links, that is, you may checkout reusable modules to the project's filesystem keeping relative dependencies stable and the base code in a shared common place.
The option of checking out common code to the project's folder and not to a shared location intends to allow for each project to depend on specific versions of the reused modules and also to only have to deal with the modules you indeed reuse in each project and not with all of your reusable assets.
On the next image you can see an example of a filesystem structure that promotes [[Reuse by Reference]] and allows for reusable modules to be stored at a central shared location on [[CVS]] while being used (and edited) at each project's filesystem.
<<Image "FR" "" "Reuse%20Filesystem%20Structure.jpg" "https://dl.dropbox.com/" "s/ddp713d8htzcihs/" "?dl=1" "Filesystem structure for reuse.">>
On the left is the [[CVS]] filesystem structure organized according to our proposed [[Namespace and Filesystem Guidelines]], on the right is the development filesystem structure, that is, the checked out filesystem on the developer's machine.
Suppose now that you have a reusable module that is a façade for third-party logging systems like Log4Net and that you want to reuse it in your Project1 project. You have several choices :
# Get a copy of the module and third-party and put it on the project's Implementation folder
# Checkout the module and third-party to your CVSROOT and establish dependencies to it
# Checkout the module and third-party to your project's Implementation folder reproducing it's relative path
The first approach works but you are hiding the module from all other projects, if you improve or correct it the changes will not be visible for others.
The second approach also works but, aside for the difficulty of maintaining relative paths, it prevents the scenario where you have several projects reusing different versions of the reusable module and makes building, deployment and archiving more difficult. It may also bring unnecessary modules to your filesystem and project's environment.
In the third approach you check out only the needed modules from //Internal// folder to a reproduction of the [[standard filesystem structure|Namespace and Filesystem Guidelines]], this way they keep their relative paths and, although they point to the same location on the [[CVS]] you can check out specific tags (versions) for each project. If you change the reusable module you may promote the tag to a branch and commit your changes to the shared module. The reusable module owner can later decide to merge your changes in a new release.
To make thing easier for your users (the developers), and to prevent future maintenance needs, you shall produce a small batch file for each of your reusable modules that will perform the checkout to the folder where it is placed. This way re-users just have to place these batch files where they are needed and run them, this is essential if you do automated [[Continuous Integration]].
{{{
cvs -z9 -r checkout -P -r LOGGING-REL-01_00_002 -d Logging -- Internal/[YourCompanyAcronym]/SYS/Common/Logging
cvs -z9 -r checkout -P -r LOGGING-REL-01_00_002 -d Log4Net -- Internal/Third-Parties/Apache/Log4Net
}}}
The above command will check out the Logging module from [[CVS]] on tag ~LOGGING-REL-01_00_002 and place it in a Logging folder beneath the current directory. The second command will check out the Apache's Log4Net from your repository.
To specify, disseminate and enforce a proper and shared filesystem structure and reuse methodology is the first step for succeeding in [[Systematic Reuse]] efforts and is also a condition for performing [[Emergent Reuse]] effectively.
----
See also : [[Namespace Coupling Guidelines]], [[Namespace Code Placement Guidelines]] and [[Namespace and Filesystem Guidelines]] [[Reuse oriented CVS]]
----
@@color:#c4d6ed; ^^
Description: Promoting Reuse by Reference through a proper filesystem structure guideline
^^@@
/***
|Name|~QuotePlugin|
|Source|http://web.ist.utl.pt/tiago.dionizio/twiki/twiki.cgi/TWPlugins.html#%5B%5BQuote%20Plugin%5D%5D|
|Documentation||
|Version|1.0.0|
|Date|15/7/2005|
|Author|Tiago Dionízio|
|License||
|~CoreVersion||
|Type|plugin|
|Description|Create a direct link to a tiddler using a normal button and a button that expands the specified tiddler inside the current tiddler.|
!!!Syntax:
{{{<<quote 'Text to display' 'Tiddler name' [open]>>}}}
!!!Description:
Create a direct link to a tiddler using a normal button and a button that expands the specified tiddler inside the current tiddler.
To display the included tiddler initially visible just pass ''open'' in the third parameter (not actually the only possible value but you can interpret it like that).
The expand button can also collapse the included tiddler, this will actually remove the included contents. If the included tiddler is changed you can simply expand it again.
!!!Code
***/
{{{
version.extensions.quote = { major: 1, minor: 0, revision: 0, date: new Date(2005, 07, 15)};
config.macros.quote = {};
config.macros.quote.onClick = function(e) {
if (!e) var e = window.event;
var container = this.nextSibling;
var isOpen = container.style.display == "block";
var tick;
this.removeChild(this.firstChild);
if (isOpen) {
container.style.display = "none";
tick = "+";
removeChildren(container);
}
else {
tick = "-";
var title = container.getAttribute("tiddlyLink");
var text = store.getTiddlerText(title);
removeChildren(container);
if(text)
wikify(text,container,null,null);
container.style.display = "block";
}
this.appendChild(document.createTextNode(tick));
}
config.macros.quote.handler = function(place,macroName,params) {
// param 0: text button
// param 1: tiddler name to display
// param 2: initial display by default
var label = params[0];
var title = params[1];
var isOpen = params[2] != null;
var link = createTiddlyLink(place,title,false);
link.appendChild(document.createTextNode(label));
var btn = createTiddlyButton(place, isOpen ? "-" : "+", "expand tiddler " + title, this.onClick);
var container = createTiddlyElement(place, "blockquote");
container.setAttribute("tiddlyLink", title);
container.style.display = isOpen ? "block" : "none";
if (isOpen) {
var text = store.getTiddlerText(title);
if(text)
wikify(text,container,null,null);
}
}
}}}
|Quotes|h
|<<list filter [tag[Quote]]>>|
----
/%
@@color:#c4d6ed; ^^
Description: A collection of important quotes from important people
^^@@
%/
Request for Proposal
----
See also : [[RFP Analysis Guidelines]]
----
/%
@@color:#c4d6ed; ^^
Description: Request for Proposal
^^@@
%/
//''"In preparing for battle, I have always found that plans are useless but planning is indispensable."''//
[[Dwight David Eisenhower (14 October 1890 – 28 March 1969)|http://en.wikiquote.org/wiki/Dwight_D._Eisenhower]]
!Introduction
The Request for Proposal Analysis occurs when you have to respond to a Customer's request for providing a Proposal (technical, financial and schedule) for a, possible, project he is willing to perform. This is the first stage you must perform : study and analysis of the problem and its scope.
{{tw_ttoc{}}}
!RFP Analysis Structure
The Request for Proposal Analysis is intended to provide a study infrastructure and step that will allow you to fully understand the Customer's request and needs. If done with method and proper tools, it will also produce a known, coherent and normalized [[traceability|Traceability]] basis for further work.
At the same time you study the [[RFP]] you shall <<quote 'copy' 'EA Tips & Tricks##Creating elements by dragging text onto a diagram'>> its information to the referred structure, changing as little as you can. The structure will act as a roadmap for analysis and as a completeness check list.
Do not think it is a waste of time, restructuring and normalizing the information is one of the best known ways of converting it into knowledge, and more, ''shareable persistent knowledge''.
!!Problem Statement
This is an introductory section that shall give an overview of the problem and give a broad overview of the Customer envisioned solution.
This shall also provide a context for the following sections.
EA usage : Packages as typographical elements of a document. Illustrative diagrams may be used if necessary. This shall, when possible, be an import of the Customer provided information.
<<Image "FR" "" "RFP-Analysis-Structure.PNG" "https://dl.dropbox.com/" "s/dwefsm068yfz2w0/" "?dl=1" "RFP Analysis Structure">>
//This is the Business Requirements Level. The business requirement is written from the Sponsor's point-of-view. It defines the objective of the project (goal) and the measurable business benefits for doing the project. The following sentence format is used to represent the business requirement and helps to increase consistency across project definitions:
"The purpose of the [project name] is to [project goal -- that is, what is the team expected to implement or deliver] so that [measurable business benefit(s) -- the sponsor's goal]." //
<<BibRef "BABOK 2008">> Chapter 4 : Enterprise Analysis
!!Goals
The Goals section shall describe the Customer goals for the project.
It shall also provide a list of success criteria in Customer's perspective.
This section shall present the business goals the project is supposed to support. This information shall be used to take decisions and to evaluate project's success.
You may, and probably shall, partition the project goals in sub-packages as specific as possible. Remember the goals are the factors to consider in trade-offs and are also success criteria so, the more specific they are the better.
Goals list is a main alignment tool between you and your Customer. Goals identification and description are also a main validation item that provides a very readable and understandable topic for your stakeholders.
"//According to our experience, the goal-agent-scenario triangle proved to be really effective. In particular, we repeatedly observed that a well-structured goal model provides an ideal communication interface between business managers and software engineers. Decision makers looked at goal models carefully, paying special attention to alternative goal refinements, operationalizations and responsibility assignments; they did not care too much about UML object models; annotated goal diagrams were found to be more helpful for focussed brainstorming, validation, negotiation, and decision making than fairly vague use case diagrams.//"
A. van Lamsweerde
[[Goal-Oriented Requirements Engineering: A Roundtrip from Research to Practice |http://www.info.ucl.ac.be/Research/Publication/2004/avl-RE04-Keynote.pdf]]
Proceedings of RE’04, 12th IEEE Joint International Requirements Engineering Conference, Kyoto, Sept. 2004, 4-8 (Invited Keynote Paper)
!!Stakeholders
Stakeholders are the persons affected by the project results and that can sponsor, contribute or take decisions over its definition.
<<Image "FR" "250" "RFP-Stakeholders.png" "https://dl.dropbox.com/" "s/25108r91fth99ra/" "?dl=1" "RFP Stakeholders">>
Define Stakeholders list.
Stakeholder attributes :
*Identification
*Contact details
*Affected interests
*Project's impact : real / perceived
*Decision ability
EA usage : ''Use Case'' diagram. ''Actor'' element (for groups detail contact person(s)). Fill details (Stakeholder attributes) in each element.
[[Traceability]] : Stakeholders may/shall be traced from Requested Features as authors or decision makers.
Stakeholders are not Roles. Not all Stakeholders will correspond to a role in the solution but all roles in the Proposed Solution must have a correspondent Stakeholder.
<<BibRef "BABOK 2008">> Chapter 2 : Business Analysis Planning and Monitoring : 2.3 and 2.9
!!Business Processes
<<Image "FR" "250" "RFP-Business-Process.png" "https://dl.dropbox.com/" "s/go4tkspievr9bqc/" "?dl=1" "RFP Business Processes">>
This section shall describe all business processes, as the Customer see or perform them, that the solution will interact with.
This information may came from Customer's documented business processes or be constructed by a joint effort between Tendering and Technical Proposal Team. If necessary and possible it shall also involve Customer.
EA usage : The Business Processes diagram is ''Activity'' and the most relevant elements are ''Partition'', ''Activities'' and ''Decision''.
Primary Relationship is ''Control Flow'' to convey sequence.
The partitions shall reflect the relevant actors be them Customer organizational units or existing or to be developed systems. For each activity the expected role of the solution shall be stated.
Business Processes shall be structured in packages and the package shall contain a contextual introduction to the diagram. The diagram itself shall contain a textual description of the process.
!!System Context
The following sections are intended to provide a full description of the surrounding environment for the solution.
This is a major scope control information and shall prevent most of the integration problems. It is also very useful in defining our system's responsibilities versus Customer's systems responsibilities and, as such, very important for Proposal.
!!!Data Flow Diagram
<<Image "FR" "250" "DFD%280%29.png" "https://dl.dropbox.com/" "s/9xa5jbcjemrd9j9/" "?dl=1" "DFD(0) or Context Diagram">>
Next to specification errors, integration "surprises" are a major cause of project problems or even failure. Determining a clear exploration context with very specific integration needs is, therefore, a major concern in Software Development. Also an underspecified context is a major scope risk. You know the scenario when tenths of MS Access databases start popping in requirements phase, don't you?
On analysing the [[RFP]] you shall identify each and every reference to external systems and record it in your [[DFD|Data Flow Diagram]].
A [[Data Flow Diagram]] is your first and best ally in this matter.
!!!Integration Environment
The Integration Environment shall describe the intended hardware, network and software platform were the system is supposed to be deployed.
It is the deployment or infrastructure view of the Context Diagram.
<<Image "FR" "250" "Integration%20Environment%20-%20Overview.png" "https://dl.dropbox.com/" "s/zbvwh0uix7o3i8y/" "?dl=1" "Integration Environment - Overview">>
There are two views for this information:
*informal - targeted to non technical audiences is simpler and only focuses in nodes and connections,
*formal - for more technical audiences addresses execution environments.
The integration environment is an important piece to align customer infrastructure needs and also to assure good and specified integration of the solution. This may save you a lot of trouble and waiting time when deploying for acceptance.
*Description:
**This shall describe Customer's infrastructure and the integration environment for the requested solution.
**It shall present the existent deployment hardware environment and the software components with which the solution interacts.
**This must clearly state all integration requirements such as Authentication Schema, mandatory frameworks/technologies, etc.
<<Image "FR" "250" "Integration%20Environment.png" "https://dl.dropbox.com/" "s/6c58fgjn7omzmfi/" "?dl=1" "Integration Environment">>
*EA usage:
**The Integration Environment diagrams are Deployment diagram. The elements are Nodes for machines, Execution Environments for operating systems and platforms, Components for programs, existent or to be developed. The components to be developed shall be represented at the deployment package or system level and they may be placed here or at Technical Proposal.Technical Solution.Preliminary Component Model being this the preferred placement.
**Relationships are Association and they may be named for protocol and have source and target roles specified.
**Two diagrams shall be produced : the Overview with only the Nodes and their relationships and using friendly icons and the Detailed diagram using all referred elements.
*Traceability
**Traceability shall be maintained upwards by Association with correspondent Data Flow Externals.
*Scope:
**This is a PUBLIC section that is not directly present in deliverables.
*Internal section goals:
**This section shall present a technological introduction to the problem and its context. It shall also present a broad technological scope definition for the proposal. This shall be a Customer view.
**This is the (Customer) declared integration environment, it will be the basis for the corresponding section on Proposal.
**All systems (hardware, devices, software, interfaces) that are relevant to the problem/solution shall be listed and described with as much detail as possible. Relationships between them shall be described and protocols identified.
*External section goals:
**None.
*When in doubt:
**This is a mandatory input. You may state "NO INTEGRATION" if you, as an architect, are lucky enough to have such a project, in this case this is a very probable candidate to productization and reuse.
*Notes:
**This section is reused (probably with modifications/enhancements) on [[Proposal|Technical Proposal Production Guidelines]].
**This is a clear candidate for reuse and continuous improvement when we have more than one project with the Customer. It shall be continuously refined along all the project.
*References:
!!!External Interfaces
*Description:
**This shall list and describe Customer's systems interfaces that our system will depend upon.
**The interfaces shall be described (operations and parameters) to the possible extent. This may/shall be refined on Specification phase.
**This must clearly state all interfaces that our system will depend upon.
*EA usage:
**The External Interfaces diagram is Class Diagram and the elements are Interface.
*Traceability
**External Interfaces shall be exposed on Integration Environment Components.
*Scope:
**This is a PUBLIC section that is not directly present in deliverables.
*Internal section goals:
**This section shall, up to the possible extent, present a full list of interfaces that our system will use on Customer's existing systems.
*External section goals:
**Validate completeness.
*When in doubt:
**This is a mandatory input. You may state "NO INTEGRATION" if you, as an architect, are lucky enough to have such a project, in this case this is a very probable candidate to productization and reuse.
*Notes:
**This section is reused (probably with modifications/enhancements) on [[Proposal|Technical Proposal Production Guidelines]].
**This is a clear candidate for reuse and continuous improvement when we have more than one project with the Customer. It shall be continuously refined along all the project.
*References:
!!Organization Standards
Every organization has some standards it follows. They may be more or less formal, written or just practised, but they are always, at least, guidelines and expectation referentials.
When this information is transmitted to you, in any form, you can not afford to ignore or lose it under the penalty of disregarding something that is obviously important for your Customer.
In our context this section shall list, reference and, at least, summary describe all Customer pertinent information. Imagine a reference architecture, a naming convention, a glossary, an external standard the Customer is certified under, etc.
This information is essential and is an important business continuity mark when you have more than one project with the same Customer. It shall be reused and enhanced in each new project with the same Customer.
!!Requested Features
The first consideration is how to express the problem and the business needs. ''User Requirements'' concept is the first thing to came to mind. We propose, however, that a different concept be used in the Inception phase, that concept is ''Feature'' in the form of ''Requested Feature'' and ''Proposed Feature''. The detailed discussion on this approach is in [[Software Requirement vs. Feature]].
The Requested Features shall have a content as close to the Customer's original expression as possible. You want to capture all of the RFP information in the model in order to not have to go back to [[RFP]] after analysis is concluded. For this you shall respect Customer's statements and make clear what was said by him and what you add yourself. Remember that Requested Features are your primary [[traceability|Traceability]] origins and scope items.
Decompose Customer statements into as many features as they contain and create one feature for each. You want requested Features to be as specific as possible.
Customer : "//The system shall optimize data entry effort and enrich it with more information than we have today.//"
''~RFT-10.010 - Optimize data entry effort''
The system shall optimize data entry effort (...).
''~RFT-10.020 - Enrich data with more information''
The system shall (...) enrich [data entry] with more information than we have today.
!!Issues
If you are analysing you'll have doubts and identify omissions, record them or lose them, is that simple.
----
Back to [[Business Analysis]]
----
<<TiddlerToC min-entries:1>>
/%
@@color:#c4d6ed; ^^
Description: Guidelines for RFP analysis
^^@@
%/
//"Recall is the percentage of relevant results returned out of all relevant results in the system. Obtaining perfect recall is trivial: simply return every document in the collection for every query."//
[[Apache Solr Reference Guide 6.0|https://lucene.apache.org/solr/guide/]]
----
See also: [[Precision (KM)]] [[Relevance (KM)]]
----
/%
@@color:#c4d6ed; ^^
Description: Recall concept on knowledge management
^^@@
%/
''//"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior."//''
Martin Fowler [[Refactoring Home Page|http://martinfowler.com/refactoring/]]
<<Image "FR" "125" "P/0201485672.01.MZZZZZZZ.jpg" "http://images.amazon.com/" "images/P/" "" "">>
"//Refactoring is about improving the design of existing code. It is the process of changing a software system in such a way that it does not alter the external behaviour of the code, yet improves its internal structure. With refactoring you can even take a bad design and rework it into a good one.//"
[[Refactoring: Improving the Design of Existing Code|http://c2.com/cgi/wiki?RefactoringImprovingTheDesignOfExistingCode]], 1999
Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Refactoring is a primary weapon against [[Software Rotting|Software Rot]] and an essential tool for [[Continuous Improvement]], [[Systematic Reuse]] and [[Opportunistic Productization]].
An interesting blog post by Vijay Narayanan states [[Refactor Code Often, Continuously, Every Iteration|http://artofsoftwarereuse.com/2013/03/24/refactor-code-often-continuously-every-iteration/]] and, in fact, you should. Refactoring is never a waste of time even if you don't reuse the refactored code and just have to maintain it.
----
@@color:#c4d6ed; ^^
Description: Refactor concept explanation and references.
^^@@
!! <html><a name="Architecture" /></html> Architecture
* [[Bredemeyer Consulting - Software Architecture, Architects and Architecting|http://www.bredemeyer.com/]] - This site organizes a variety of resources to help enterprise architects and software architects deepen and expand their understanding of architecture and the role of the architect.
* [[MS The Architecture Journal|http://www.architecturejournal.net]] - Microsoft's Architecture Journal.
!! <html><a name="BusinessAnalysis" /></html> Business Analysis
* [[A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)|http://www.iiba.org/imis15/IIBA/Professional_Development/Business_Analysis_Body_of_Knowledge/IIBA_Website/Professional_Development/Business_Analysis_Body_of_Knowledge_pages/Business_Analysis_Body_of_Knowledge.aspx?hkey=d0891e0a-996a-431f-a6f5-a7d644e23a5c]] - is the collection of knowledge within the profession of business analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the business analysis professionals who apply it in their daily work role.
!! <html><a name="OOP" /></html> OOP (Object Oriented Programming)
* [[JOT|http://www.jot.fm]] - Journal of Object Technology (JOT) is an on-line peer-reviewed publication, published six times per year by the ETH Swiss Federal Institute of Technology, aimed at intermediate to advanced practitioners, educators and researchers in the field of object technology.
----
//"In information retrieval, relevance is defined as the practice of returning search results that most satisfy the user’s information needs."//
Relevant Search - With applications for Solr and Elasticsearch
Doug Turnbull and John Berryman
As a measure :
//"Relevance is the degree to which a query response satisfies a user who is searching for information."//
[[Apache Solr Reference Guide 6.0|https://lucene.apache.org/solr/guide/]]
----
See also: [[Precision (KM)]] [[Recall (KM)]]
----
/%
@@color:#c4d6ed; ^^
Description: Relevance concept in Knowledge Management
^^@@
%/
The concept of using boilerplates for writing statements of requirement is quite simple: choose an appropriate predefined template, and fill in the gaps. Each statement of requirement then becomes a generic boilerplate plus the specific values of selected attributes.
''Example boilerplate:''
> The <user> shall be able to <capability> at a maximum rate of at least <quantity> times per <time unit>.
''Example instantiation: ''
> <user> = order entry clerk
> <capability> = raise an invoice
> <quantity> = 10
> <time unit> = hour
''Giving :''
> "The order entry clerk shall be able to raise an invoice at a maximum rate of at least 10 times per hour."
Using this approach, an organisation can gradually refine a repertoire of ways of expressing all the kinds of requirement it needs. By encouraging engineers always to choose from the repertoire, a uniformity of style can be achieved in the organisation.
From : http://eatwalksleep.com/gbjedi/books/re/boilerplates/index.htm
----
/%
@@color:#c4d6ed; ^^
Description: Requirement Boilerplate concept and references.
^^@@
%/
Reuse, [[Systematic Reuse]], is, probably, the closest thing to a "//silver bullet//" that one can get in Software Engineering.
But the fact is that most of reuse endeavors fail miserably.
In my opinion this is due, mostly, to a focus on "code reuse" instead of in promoting the conditions that favor the production of reusable code.
----
/%
@@color:#c4d6ed; ^^
Description: Tag for reuse matters
^^@@
%/
''Solution quality''
A reused solution is more mature than an absolutely new one. Maturity is a good thing as it incorporates continuous improvement and assures more knowledge and control over the context and results. Also a reused solution is, typically, better verified and validated than a new one.
''Reduced costs''
A reused solution shall reduce cost when compared to a brand new solution.
This shall improve competitiveness and release resources to the really specific challenges of each concrete project.
''Estimation accuracy''
Estimating over a reuse framework is more accurate as the uncertain parts are less and framed by known meta-architectures and solution patterns.
Also estimation history and problem comparability increases figures safety and the ability to decrease risk margin thus contributing to potential competitiveness.
''Homogeneity promotion''
Reuse promotes homogeneity of work products thus also promoting their reusability and continuous improvement making a virtuous cycle.
----
/%
@@color:#c4d6ed; ^^
Description: An enumeration of reuse benefits
^^@@
%/
There are many obstacles to implementing [[Systematic Reuse]]. Some are practical and technical considerations, some are management attitudes and myths, some are strategic choices, some are just reflex of lack of experience and immaturity.
!Reusable Asset Discovery
The first obstacle is the difficulty on locating potential reusable assets. How do you know that they exist? How do you assess them in a time/cost-effective manner? To progress from the Individual Reuse level (See [[RMM|Implementing Systematic Reuse]]) to more advanced ones you must tackle this problem.
See also : [[Software Development Ontology|SoftwareDevelopmentOntology]]
!Project Centric fanatic views
A common minimalistic management view is to think that projects shall consider only the shortest possible view to accomplish their immediate targets and never consider any medium-term goals, these are top management tasks, project members are just task oriented code doers incapable of taking reasonable medium-term economical decisions.
This has a known effect of stalling technical progress and effectively prevent and even discourage any kind of reuse.
!Lack of established guidelines for namespace and coupling control
Chaotic namespaces ([[filesystem, namespace and packaging|Namespace and Filesystem Guidelines]]) and uncontrolled spaghetti [[coupling|Coupling]] are one of the major technical obstacles to reuse. They undermine confidence in the profitability of reuse and bring nasty surprises to those who dare to risk reusing. They are, however, quite simple to avoid with proper planning and clear guidelines enforced. I do recommend these two aspects to be addressed at the beginning of any reuse improvement programme. [[Namespace and Filesystem Guidelines]] and [[Namespace Coupling Guidelines]] provide some very simple approaches to deal with the subject.
!Reuse by Copy
[[Reuse by Copy|Reuse by Reference]] is induced by the technical myth that you must completely isolate each project's code from all other projects. This completely impairs continuous improvement of reusable artefacts and creates a nightmare of hacked versions that for sure discourage reusable artefact authors of maintaining and improving them. At the very minimum any reusable artefact shall have an owner and the owner shall be informed of each and every reuse instance and be given the opportunity to know and comment any changes made to the artefact.
!Lack of established archetypes
Chaotic [[modularizations|Modularization]] often prevent reuse even inside the same project. An established [[archetype|Application Archetype]] catalogue will help in orienting [[modularizations|Modularization]] of your systems in order to reduce [[Coupling]] and increase [[Cohesion]] and these are major factors on reuseability.
!The tool myth
Before choosing tools to manage reuse assets or processes you must be able to produce reusable assets and have those assets. To produce reusable assets you must invest in promoting homogeneity (compatibility) and collaboration (continuous, collaborative improvement). A tool without a method is an obstacle...
See [[Implementing Systematic Reuse]] for, I think, a better approach.
!Concurrent Versioning System methods
Choosing the wrong [[Concurrent Versioning System]] may be one of the worst obstacles to [[Systematic Reuse]]. Certain methods encourage divergence (branching) and do not promote convergence and, thus, [[Continuous Improvement]], collaboration and sharing.
See [[Reuse oriented CVS]].
----
/%
@@color:#c4d6ed; ^^
Description: Reuse Obstacles identification and discussion
^^@@
%/
Reuse by copy opposes to __reuse by reference__ and is one of the main obstacles to [[Systematic Reuse]] and [[Continuous Improvement]]. Reuse by reference applies to code reuse primarily but keep in mind that [[Systematic Reuse]] is not only, nor even primarily, code reuse.
Reuse by copy happens when, on reusing a module, you just copy it from its original repository and put the copy on the filesystem of the project that reuses it. On __reuse by reference__ you check out the reusable module to the filesystem of the reusing project but, on the [[CVS]] repository, the module is the same. Of course you shall relay your dependency on a [[CVS Tag]]. The benefit of doing so is evident : ''all enhancements and improvements may be easily shared among all projects that reuse the module'' along time. When you copy you hide from all other projects and [[Systematic Reuse]] is impaired.
In a very interesting post about [[5 Tips to Co-Create Reusable Components|http://artofsoftwarereuse.com/2013/02/17/5-tips-to-co-create-reusable-components/]] Vijay Narayanan states :
"//Share the source code of all your reusable components so every developer in the team can see under the hood how the component works and how it can be improved//"
----
See also : [[Promoting Reuse by Reference]]
----
@@color:#c4d6ed; ^^
Description: Reuse by Reference vs. Reuse by Copy concept explanation.
^^@@
The first thing to consider when designing a [[CVS]] policy is file system structure. You must establish rules and standard file system structures to cope with complexity and allow for information location and retrieval. Also, if [[reuse|Systematic Reuse]] is, and it should be, a concern, a proper, standardized and followed, [[code file system|Namespace and Filesystem Guidelines]] is a major asset you can not afford to underestimate.
As said, [[Configuration Management]] encompasses much more than code and, as such, your file system structure shall reflect that.
For the code part you may look at [[Promoting Reuse by Reference]] and [[Namespace and Filesystem Guidelines]]. A good [[CVS]] tool and policy are essential on promoting [[Systematic Reuse]].
TODO: source-control vs. concurrent versioning system
----
Back to [[Concurrent Versioning System]] [[High Maturity Practices]]
See also [[Namespace and Filesystem Guidelines]] [[Promoting Reuse by Reference]]
----
/%
@@color:#c4d6ed; ^^
Description: Some guidelines for Concurrent Versioning Systems implementation and management.
^^@@
%/
Software Architecture Specification
----
@@color:#c4d6ed; ^^
Description: Software Architecture Specification
^^@@
!Self-balanced Parallel Asynchronous Processor (SBPAP)
Provide a reusable platform and architectural guidance for self-balanced parallel asynchronous processing of variable data objects in order to increase applications performance and leverage actual multiprocessor environments full potential.
Self-balancing means that the system is able to adjust itself to load and available resources during its operation.
Parallel means that the system is able to process each data object in different parallel threads taking full advantage of multi-processor environments.
Asynchronous means that the system is intended for asynchronous usage, that is, it is not intended for scenarios where an immediate response is needed from processing (although it can also be used that way, probably with some performance and architectural advantages).
You may download the full article [[here|https://www.dropbox.com/s/luehyrcvmpeq8yd/Self-balanced%20Parallel%20Asynchronous%20Processor%20%28SBPAP%29.docx?dl=1]]
----
/%
@@color:#c4d6ed; ^^
Description: Self-balanced Parallel Asynchronous Processor (SBPAP)
^^@@
%/
[[Software Development Process]]
----
/%
@@color:#c4d6ed; ^^
Description: Software Development Process
^^@@
%/
SMART stands for :
* ''Specific'' : A requirement must say exactly what is required.
* ''Measurable'' : In the context of Requirements Engineering, by measurable we mean is it possible, once the system has been constructed, to verify that this requirement has been met.
* ''Attainable'' : By an attainable requirement we mean it is possible physically for the system to exhibit that requirement under the given conditions.
* ''Realizable'' : in the context of software requirements, by realisable we mean is it possible to achieve this requirement given what is known about the constraints under which the system and the project must be developed.
* ''Traceable'' : Requirements [[Traceability]] is the ability to trace (forwards and backwards) a requirement from its conception through its specification to its subsequent design, implementation and test.
These are characteristics a Software Requirement shall present to be considered as such. The concept was proposed by <<BibRef "Mannion,Keepence 1995">>.
----
See also : [[Software Requirement]] [[Writing Good Requirements]]
----
@@color:#c4d6ed; ^^
Description: SMART Requirements concept explanation and reference.
^^@@
Software Requirements Specification
----
@@color:#c4d6ed; ^^
Description: Software Requirements Specification
^^@@
Next to Inception and Specification errors, lack of Scope Control is one of the major failure causes in Software Development.
Scope is (re)defined along the entire project, however, Scope Definition should be centered in some specific phases as changes to it in later phases usually bring a lot of cost and risk associated.
Scope Management is related to several other disciplines namely Change Management and, of course Inception and Specification. In fact, Inception and Specification quality and maturity greatly determine the scope risks a project will incur.
[[Traceability]] is the first weapon against loosing scope control, proper structure, methods and maturity of the specification team are the other factors to consider. A proper and traceable structure gives you a check list and a known context where you can detect omissions and ambiguity warnings as well as clear indicators of scope growing. Evolved methods allow for objective expression, coherence and validation of the considered scope. Maturity is essential to anticipate, detail, integrate and define a scope that is feasible and adequate to Customer's needs.
<<Image "FR" "358" "Phasing-Scope.png" "https://dl.dropbox.com/" "s/tpr7waf8t2l60wo/" "?dl=1" "Phasing and Scope.">>
We propose that scope be, primarily, defined in the Inception phase (Pre-sales, RFP and Proposal). The image illustrates the relative scope range in the different phases from a broad open scope in pre-sales to a more focused one in [[Request For Proposal|RFP Analysis Guidelines]] to a closed, defined and sufficient scope on [[Proposal|Technical Proposal Production Guidelines]]. The [[Requirements|Software Specification]] phase shall not change the proposed scope unless with a formal Change Procedure. Remember estimation and, thus, price, schedule and resources, were defined at Proposal. But also remember that the Customer is entitled to expect that your proposed scope is ''sufficient'' to address his needs unless you clearly stated otherwise in your Proposal.
There is a permanent and difficult balance to be done between "selling arguments" in the Proposal and realistic and adequate scope definition.
To manage (protect) scope at Requirements Specification phase is one of the most challenging tasks a Software Development team faces.
The first task with a Change Request is to identify it as an ''omission'', that is, a Feature of the system that is essential for it to fulfil its declared goals and, as such, its a shared mistake between your Proposal team and the Customer's Proposal validation team, or as an ''addition'', that is, an opportunistic identification of a need, that the Customer wants to see covered by a Feature of the current system and that is, in fact, an extension to the proposed scope.
----
See also [[Coverage]]
----
/%
@@color:#c4d6ed; ^^
Description: Scope Management guidelines
^^@@
%/
/***
|Name|SectionLinksPlugin|
|Source|http://www.TiddlyTools.com/#SectionLinksPlugin|
|Documentation|http://www.TiddlyTools.com/#SectionLinksPlugin|
|Version|1.4.2|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|plugin|
|Description|allow tiddler sections in TiddlyLinks to be used as anchor points|
This plugin enhances tiddler links so that they can include section references that ''auto-scroll to the indicated section heading'' within a tiddler (i.e., similar to the 'anchor' behavior provided in HTML by {{{<a name="foo">}}} and {{{<a href="#foo">...</a>}}}). The {{{<<tiddler>>}}} macro syntax has also be extended to allow section references without a tiddler name, so that transclusion of //hidden sections from the same tiddler// can be easily accomplished. The plugin also adds a new macro, <<sectionTOC>> which can auto-generate and embed a 'Table of Contents' outline view into a tiddler to enable quick navigation to sections within that tiddler.
!!!Usage
<<<
!!!!~TiddlyLink syntax
You can link to a section of a tiddler by adding the "##sectionname" syntax to the tiddlername:
{{{
[[SomeTiddler##SomeSection]]
}}}
When clicked, the tiddler is displayed and the specified section heading is automatically scrolled into view. If the tiddler title is omitted or the 'here' keyword is used, e.g.,
{{{
[[##SomeSection]] or [[here##SomeSection]]>>
}}}
then the current containing tiddler is implied by default.
!!!!HTML anchor syntax
You can use HTML syntax to create a scrollable 'anchor' location within a tiddler without use of the standard TW section heading syntax:
{{{
<html><a name="sectionname" /></html>
}}}
You can then link to that section using the enhanced TiddlyLink syntax as above.
!!!!{{{<<tiddler>>}}} macro
The {{{<<tiddler>>}}} syntax has been extended so that when the tiddler title is omitted or the 'here' keyword is used, e.g.,
{{{
<<tiddler ##SomeSection>> or <<tiddler here##SomeSection>>
}}}
then the current containing tiddler is implied by default.
!!!!"""<<sectionTOC>>""" macro
This macro generates a 'Table of Contents' outline-style bullet list with links to all sections within the current tiddler. Simply place the following macro at the //end of the tiddler content// (i.e., following all section headings). Important note: //''The {{{<<sectionTOC>>}}} macro must occur at the end of the tiddler in order to locate the rendered section headings that precede it.''//
{{{
<<sectionTOC>> or <<sectionTOC className>>
}}}
To position the macro's //output// within the tiddler, you must create a special 'target element' that uses a specific classname (default='sectionTOC'), like this:
{{{
{{sectionTOC{}}}
}}}
When the {{{<<sectionTOC>>}}} macro is rendered, it will find the matching 'sectionTOC'-classed element and writes it's output there. You can also add the macro and/or target elements directly to the [[ViewTemplate]] definition, so that every tiddler can automatically display the table of contents:
{{{
<span class='sectionTOC'></span> <!-- target element -->
...
<span macro='sectionTOC'></span> <!-- must be at end of tiddler -->
}}}
<<<
!!!Configuration
<<<
You can change the {{{<<SectionTOC>>}}} output link format by adding the following statement to a tiddler tagged with <<tag systemConfig>>
{{{
config.macros.sectionTOC.linkFormat='[[%0|##%0]]';
}}}
The default value (shown above) produces a link to each section within the tiddler, using "%0" to insert the section name into the link. You can add extra formatting to generate additional output to suit your purposes. For example, if you have EditSectionPlugin installed, you could include a link that invokes that plugin's popup editor directly from each item in the TOC display, like this:
{{{
config.macros.sectionTOC.linkFormat='[[%0|##%0]] <<editSection [[##%0]] [[(edit)]]>>';
}}}
<<<
!!!Examples
<<<
links to sections defined by ''TW heading syntax'' (e.g, {{{!!!sectionname}}}):{{indent{
[[SectionLinksPlugin##onClickTiddlerLink]]
[[##onClickTiddlerLink]] //(current tiddler implied)//}}}
links to anchors defined by ''HTML syntax'' (e.g., {{{<html><a href="anchorname"></html>}}}):{{indent{
[[SectionLinksPlugin##sampleanchorlink]]
[[##sampleanchorlink]] //(current tiddler implied)//}}}
<<<
!!!Revisions
<<<
2011.12.21 1.4.2 refactor sectionTOCformat to permit customization
2011.02.08 1.4.1 in isExternalLink() hijack, strip section references before testing for external link
2010.08.09 1.4.0 in scrollToSection(), added support for using HTML <a name="..."> anchor elements
2009.08.21 1.3.4 added handling to ignore leading/trailing whitespace in section references
2009.08.21 1.3.3 in createTiddlyLink(), add tiddlyLinkNonExistingSection class if matching section is not found
2009.08.14 1.3.2 in createTiddlyLink(), don't override core value for ~TiddlyLink attribute
2009.08.02 1.3.1 in sectionTOC.handler(), trim leading/trailing whitespace from generated section links
2009.08.01 1.3.0 in scrollToSection(), apply 3-tier section matching (exact, startsWith, contains)
2009.07.06 1.2.2 fixed displayTiddler() hijack
2009.07.03 1.2.1 in {{{<<sectionTOC>>}}}, suppress output if target is not found
2009.06.02 1.2.0 added support for 'here' keyword in {{{[[here##section]]}}} links and {{{<<tiddler here##section>>}}} macro
2009.04.09 1.1.1 in sectionTOC macro, make target visible when TOC is rendered.
2009.01.18 1.1.0 added {{{<<sectionTOC>>}}} macro to generate numbered-bullet links to sections of current tiddler
2009.01.06 1.0.0 converted to stand-alone plugin
2008.10.14 0.0.0 initial release (as [[CoreTweaks]] #784 - http://trac.tiddlywiki.org/ticket/784)
<<<
!!!Code
***/
//{{{
version.extensions.SectionLinksPlugin= {major: 1, minor: 4, revision: 2, date: new Date(2011,12,21)};
Story.prototype.scrollToSection = function(title,section) {
if (!title||!section) return; var t=this.getTiddler(title); if (!t) return null;
var elems=t.getElementsByTagName('*');
var heads=[]; var anchors=[];
for (var i=0; i<elems.length; i++)
if (['H1','H2','H3','H4','H5'].contains(elems[i].nodeName)) heads.push(elems[i]);
for (var i=0; i<elems.length; i++)
if (elems[i].nodeName=='A' && (elems[i].getAttribute('name')||'').length) anchors.push(elems[i]);
var found=null;
for (var i=0; i<heads.length; i++)
if (getPlainText(heads[i]).trim()==section) { found=heads[i]; break; }
if (!found) for (var i=0; i<heads.length; i++)
if (getPlainText(heads[i]).trim().startsWith(section)) { found=heads[i]; break; }
if (!found) for (var i=0; i<heads.length; i++)
if (getPlainText(heads[i]).trim().indexOf(section)!=-1) { found=heads[i]; break; }
if (!found) for (var i=0; i<anchors.length; i++)
if (anchors[i].getAttribute('name')==section) { found=anchors[i]; break; }
if (!found) for (var i=0; i<anchors.length; i++)
if (anchors[i].getAttribute('name').startsWith(section)) { found=anchors[i]; break; }
if (!found) for (var i=0; i<anchors.length; i++)
if (anchors[i].getAttribute('name').indexOf(section)!=-1) { found=anchors[i]; break; }
if (found) {
// if section heading is collapsed, click to expand it - see [[FoldHeadingsPlugin]]
if (hasClass(found,'foldable') && found.nextSibling.style.display=='none') found.onclick();
// scroll *after* tiddler animation
var delay=config.options.chkAnimate?config.animDuration+100:0;
setTimeout('window.scrollTo('+findPosX(found)+','+findPosY(found)+')',delay);
return found;
}
}
//}}}
/***
!!!!core hijacks
***/
/***
!!!!!createTiddlyLink
***/
//{{{
// [[tiddlername##section]] and [[##section]]
if (!window.createTiddlyLink_section)
window.createTiddlyLink_section=window.createTiddlyLink;
window.createTiddlyLink=function(place,title) {
var t=story.findContainingTiddler(place); var tid=t?t.getAttribute('tiddler'):'';
var parts=title.split(config.textPrimitives.sectionSeparator);
var title=parts[0]; var section=parts[1]; if (section) section=section.trim();
if (!title.length || title.toLowerCase()=='here') title=tid; // default=current tiddler
arguments[1]=title;
var btn=createTiddlyLink_section.apply(this,arguments);
if (section) {
btn.setAttribute('section',section);
if (store.getTiddlerText(title+config.textPrimitives.sectionSeparator+section)===null)
addClass(btn,'tiddlyLinkNonExistingSection');
}
return btn;
}
//}}}
/***
!!!!!onClickTiddlerLink
***/
//{{{
if (!window.onClickTiddlerLink_section)
window.onClickTiddlerLink_section=window.onClickTiddlerLink;
window.onClickTiddlerLink=function(ev) {
var e=ev||window.event; var target=resolveTarget(e); var title=null;
while (target!=null && title==null) {
title=target.getAttribute('tiddlyLink');
section=target.getAttribute('section');
target=target.parentNode;
}
var t=story.findContainingTiddler(target); var tid=t?t.getAttribute('tiddler'):'';
if (title!=tid||!section) // avoid excess scrolling for intra-tiddler links
onClickTiddlerLink_section.apply(this,arguments);
story.scrollToSection(title,section);
return false;
}
//}}}
/***
!!!!! displayTiddler
***/
//{{{
if (!Story.prototype.displayTiddler_section)
Story.prototype.displayTiddler_section=Story.prototype.displayTiddler;
Story.prototype.displayTiddler = function(srcElement,tiddler)
{
var title=(tiddler instanceof Tiddler)?tiddler.title:tiddler;
var parts=title.split(config.textPrimitives.sectionSeparator);
var title=parts[0]; var section=parts[1]; if (section) section=section.trim();
if (!title.length || title.toLowerCase()=='here') {
var t=story.findContainingTiddler(place);
title=t?t.getAttribute('tiddler'):'';
}
arguments[1]=title; // default=current tiddler
this.displayTiddler_section.apply(this,arguments);
story.scrollToSection(title,section);
}
//}}}
/***
<html><a name="sampleanchorlink" /></html>This is a sample ''anchor link'': {{{<html><a name="sampleanchorlink" /></html>}}}
!!!!!isExternalLink
***/
//{{{
if (!config.formatterHelpers.isExternalLink_section)
config.formatterHelpers.isExternalLink_section=config.formatterHelpers.isExternalLink;
config.formatterHelpers.isExternalLink=function(link) { // remove section references before testing
var l=link.split(config.textPrimitives.sectionSeparator)[0];
return config.formatterHelpers.isExternalLink_section(l);
}
//}}}
/***
!!!!!tiddler.handler
***/
//{{{
if (!config.macros.tiddler.handler_section)
config.macros.tiddler.handler_section=config.macros.tiddler.handler;
config.macros.tiddler.handler=function(place,macroName,params,wikifier,paramString,tiddler)
{
if (!params[0]) return;
var sep=config.textPrimitives.sectionSeparator;
var parts=params[0].split(sep); var tid=parts[0]; var sec=parts[1]; if (sec) sec=sec.trim();
if ((tid.toLowerCase()=='here'||!tid.length) && sec) { // fixup for 'here##section' and '##section'
var here=story.findContainingTiddler(place)
var tid=here?here.getAttribute('tiddler'):tiddler?tiddler.title:'';
arguments[2][0]=tid+sep+sec;
arguments[4]=paramString.replace(new RegExp('(here)?'+sep+sec),tid+sep+sec);
}
config.macros.tiddler.handler_section.apply(this,arguments);
}
//}}}
/***
!!!!sectionTOC macro
***/
//{{{
config.macros.sectionTOC = {
targetClass: 'sectionTOC',
linkFormat: '[[%0|##%0]]',
handler: function(place,macroName,params,wikifier,paramString,tiddler) {
var out=[];
var targetClass=params[0]||this.targetClass;
var t=story.findContainingTiddler(place); if (!t) return;
var elems=t.getElementsByTagName('*');
var level=5; // topmost heading level
for (var i=0; i<elems.length; i++) {
var txt=getPlainText(elems[i]).trim();
var link=this.linkFormat.format([txt]);
switch(elems[i].nodeName) {
case 'H1': out.push('#'+link); level=1; break;
case 'H2': out.push('##'+link); level=level<2?level:2; break;
case 'H3': out.push('###'+link); level=level<3?level:3; break;
case 'H4': out.push('####'+link); level=level<4?level:4; break;
case 'H5': out.push('#####'+link); level=level<5?level:5; break;
default: if (hasClass(elems[i],targetClass)) var target=elems[i];
}
}
// trim excess bullet levels
if (level>1) for (var i=0; i<out.length; i++) out[i]=out[i].substr(level-1);
// show numbered list
if (out.length && target) {
if (target.style.display=='none') target.style.display='block';
wikify(out.join('\n'),target);
}
}
}
//}}}
/***
!!!Invoke macro
{{{
<<sectionTOC>>
}}}
***/
// //<<sectionTOC>>
!Architecture
[[Level Up Coding|https://blog.levelupcoding.co/]] - Complex programming concepts explained with simple terms and stunning visuals. Join the growing community of engineers experiencing accelerated learning through straight-to-the-point, bite-sized explanations.
[[Stream processing, Event sourcing, Reactive, CEP… and making sense of it all|https://confluentinc.wordpress.com/2015/01/29/making-sense-of-stream-processing/]] - by Martin Kleppmann - In this talk, we will go in search of the wisdom behind the buzzwords. We will discuss how event streams can help make your application more scalable, more reliable and more maintainable.
----
/%
@@color:#c4d6ed; ^^
Description: Selected references and pointers
^^@@
%/
{{button{goto}}}
<<gotoTiddler>><<search>><<closeAll>><<permaview>><<newTiddler>><<newJournal "DD MMM YYYY" "journal">><<thostUpload>>[[download|https://acarvalho.tiddlyhost.com/download]]<<slider chkSliderOptionsPanel OptionsPanel "options »" "Change TiddlyWiki advanced options">>
/***
|Name|SinglePageModePlugin|
|Source|http://www.TiddlyTools.com/#SinglePageModePlugin|
|Documentation|http://www.TiddlyTools.com/#SinglePageModePluginInfo|
|Version|2.9.7|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|plugin|
|Description|Show tiddlers one at a time with automatic permalink, or always open tiddlers at top/bottom of page.|
This plugin allows you to configure TiddlyWiki to navigate more like a traditional multipage web site with only one tiddler displayed at a time.
!!!!!Documentation
>see [[SinglePageModePluginInfo]]
!!!!!Configuration
<<<
<<option chkSinglePageMode>> Display one tiddler at a time
><<option chkSinglePagePermalink>> Automatically permalink current tiddler
><<option chkSinglePageKeepFoldedTiddlers>> Don't close tiddlers that are folded
><<option chkSinglePageKeepEditedTiddlers>> Don't close tiddlers that are being edited
<<option chkTopOfPageMode>> Open tiddlers at the top of the page
<<option chkBottomOfPageMode>> Open tiddlers at the bottom of the page
<<option chkSinglePageAutoScroll>> Automatically scroll tiddler into view (if needed)
Notes:
* The "display one tiddler at a time" option can also be //temporarily// set/reset by including a 'paramifier' in the document URL: {{{#SPM:true}}} or {{{#SPM:false}}}.
* If more than one display mode is selected, 'one at a time' display takes precedence over both 'top' and 'bottom' settings, and if 'one at a time' setting is not used, 'top of page' takes precedence over 'bottom of page'.
* When using Apple's Safari browser, automatically setting the permalink causes an error and is disabled.
<<<
!!!!!Revisions
<<<
2010.11.30 2.9.7 use story.getTiddler()
2008.10.17 2.9.6 changed chkSinglePageAutoScroll default to false
| Please see [[SinglePageModePluginInfo]] for previous revision details |
2005.08.15 1.0.0 Initial Release. Support for BACK/FORWARD buttons adapted from code developed by Clint Checketts.
<<<
!!!!!Code
***/
//{{{
version.extensions.SinglePageModePlugin= {major: 2, minor: 9, revision: 7, date: new Date(2010,11,30)};
//}}}
//{{{
config.paramifiers.SPM = { onstart: function(v) {
config.options.chkSinglePageMode=eval(v);
if (config.options.chkSinglePageMode && config.options.chkSinglePagePermalink && !config.browser.isSafari) {
config.lastURL = window.location.hash;
if (!config.SPMTimer) config.SPMTimer=window.setInterval(function() {checkLastURL();},1000);
}
} };
//}}}
//{{{
if (config.options.chkSinglePageMode==undefined)
config.options.chkSinglePageMode=false;
if (config.options.chkSinglePagePermalink==undefined)
config.options.chkSinglePagePermalink=true;
if (config.options.chkSinglePageKeepFoldedTiddlers==undefined)
config.options.chkSinglePageKeepFoldedTiddlers=false;
if (config.options.chkSinglePageKeepEditedTiddlers==undefined)
config.options.chkSinglePageKeepEditedTiddlers=false;
if (config.options.chkTopOfPageMode==undefined)
config.options.chkTopOfPageMode=false;
if (config.options.chkBottomOfPageMode==undefined)
config.options.chkBottomOfPageMode=false;
if (config.options.chkSinglePageAutoScroll==undefined)
config.options.chkSinglePageAutoScroll=false;
//}}}
//{{{
config.SPMTimer = 0;
config.lastURL = window.location.hash;
function checkLastURL()
{
if (!config.options.chkSinglePageMode)
{ window.clearInterval(config.SPMTimer); config.SPMTimer=0; return; }
if (config.lastURL == window.location.hash) return; // no change in hash
var tids=decodeURIComponent(window.location.hash.substr(1)).readBracketedList();
if (tids.length==1) // permalink (single tiddler in URL)
story.displayTiddler(null,tids[0]);
else { // restore permaview or default view
config.lastURL = window.location.hash;
if (!tids.length) tids=store.getTiddlerText("DefaultTiddlers").readBracketedList();
story.closeAllTiddlers();
story.displayTiddlers(null,tids);
}
}
if (Story.prototype.SPM_coreDisplayTiddler==undefined)
Story.prototype.SPM_coreDisplayTiddler=Story.prototype.displayTiddler;
Story.prototype.displayTiddler = function(srcElement,tiddler,template,animate,slowly)
{
var title=(tiddler instanceof Tiddler)?tiddler.title:tiddler;
var tiddlerElem=story.getTiddler(title); // ==null unless tiddler is already displayed
var opt=config.options;
var single=opt.chkSinglePageMode && !startingUp;
var top=opt.chkTopOfPageMode && !startingUp;
var bottom=opt.chkBottomOfPageMode && !startingUp;
if (single) {
story.forEachTiddler(function(tid,elem) {
// skip current tiddler and, optionally, tiddlers that are folded.
if ( tid==title
|| (opt.chkSinglePageKeepFoldedTiddlers && elem.getAttribute("folded")=="true"))
return;
// if a tiddler is being edited, ask before closing
if (elem.getAttribute("dirty")=="true") {
if (opt.chkSinglePageKeepEditedTiddlers) return;
// if tiddler to be displayed is already shown, then leave active tiddler editor as is
// (occurs when switching between view and edit modes)
if (tiddlerElem) return;
// otherwise, ask for permission
var msg="'"+tid+"' is currently being edited.\n\n";
msg+="Press OK to save and close this tiddler\nor press Cancel to leave it opened";
if (!confirm(msg)) return; else story.saveTiddler(tid);
}
story.closeTiddler(tid);
});
}
else if (top)
arguments[0]=null;
else if (bottom)
arguments[0]="bottom";
if (single && opt.chkSinglePagePermalink && !config.browser.isSafari) {
window.location.hash = encodeURIComponent(String.encodeTiddlyLink(title));
config.lastURL = window.location.hash;
document.title = wikifyPlain("SiteTitle") + " - " + title;
if (!config.SPMTimer) config.SPMTimer=window.setInterval(function() {checkLastURL();},1000);
}
if (tiddlerElem && tiddlerElem.getAttribute("dirty")=="true") { // editing... move tiddler without re-rendering
var isTopTiddler=(tiddlerElem.previousSibling==null);
if (!isTopTiddler && (single || top))
tiddlerElem.parentNode.insertBefore(tiddlerElem,tiddlerElem.parentNode.firstChild);
else if (bottom)
tiddlerElem.parentNode.insertBefore(tiddlerElem,null);
else this.SPM_coreDisplayTiddler.apply(this,arguments); // let CORE render tiddler
} else
this.SPM_coreDisplayTiddler.apply(this,arguments); // let CORE render tiddler
var tiddlerElem=story.getTiddler(title);
if (tiddlerElem&&opt.chkSinglePageAutoScroll) {
// scroll to top of page or top of tiddler
var isTopTiddler=(tiddlerElem.previousSibling==null);
var yPos=isTopTiddler?0:ensureVisible(tiddlerElem);
// if animating, defer scroll until after animation completes
var delay=opt.chkAnimate?config.animDuration+10:0;
setTimeout("window.scrollTo(0,"+yPos+")",delay);
}
}
if (Story.prototype.SPM_coreDisplayTiddlers==undefined)
Story.prototype.SPM_coreDisplayTiddlers=Story.prototype.displayTiddlers;
Story.prototype.displayTiddlers = function() {
// suspend single/top/bottom modes when showing multiple tiddlers
var opt=config.options;
var saveSPM=opt.chkSinglePageMode; opt.chkSinglePageMode=false;
var saveTPM=opt.chkTopOfPageMode; opt.chkTopOfPageMode=false;
var saveBPM=opt.chkBottomOfPageMode; opt.chkBottomOfPageMode=false;
this.SPM_coreDisplayTiddlers.apply(this,arguments);
opt.chkBottomOfPageMode=saveBPM;
opt.chkTopOfPageMode=saveTPM;
opt.chkSinglePageMode=saveSPM;
}
//}}}
/***
|Name|SinglePageModePluginInfo|
|Source|http://www.TiddlyTools.com/#SinglePageModePlugin|
|Documentation|http://www.TiddlyTools.com/#SinglePageModePluginInfo|
|Version|2.9.6|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|documentation|
|Description|Documentation for SinglePageModePlugin|
Normally, as you click on the links in TiddlyWiki, more and more tiddlers are displayed on the page. The order of this tiddler display depends upon when and where you have clicked. Some people like this non-linear method of reading the document, while others have reported that when many tiddlers have been opened, it can get somewhat confusing. SinglePageModePlugin allows you to configure TiddlyWiki to navigate more like a traditional multipage web site with only one item displayed at a time.
!!!!!Usage
<<<
When the plugin is enabled, only one tiddler will be displayed at a time and the browser window's titlebar is updated to include the current tiddler title. The browser's location URL is also updated with a 'permalink' for the current tiddler so that it is easier to create a browser 'bookmark' for the current tiddler. Alternatively, even when displaying multiple tiddlers //is// permitted, you can still reduce the potential for confusion by forcing tiddlers to always open at the top (or bottom) of the page instead of being displayed following the tiddler containing the link that was clicked.
<<<
!!!!!Configuration
<<<
<<option chkSinglePageMode>> Display one tiddler at a time
><<option chkSinglePagePermalink>> Automatically permalink current tiddler
><<option chkSinglePageKeepFoldedTiddlers>> Don't close tiddlers that are folded
><<option chkSinglePageKeepEditedTiddlers>> Don't close tiddlers that are being edited
<<option chkTopOfPageMode>> Open tiddlers at the top of the page
<<option chkBottomOfPageMode>> Open tiddlers at the bottom of the page
<<option chkSinglePageAutoScroll>> Automatically scroll tiddler into view (if needed)
Notes:
* {{block{
The "display one tiddler at a time" option can also be //temporarily// set/reset by including a 'paramifier' in the document URL: {{{#SPM:true}}} or {{{#SPM:false}}}. You can also use {{{SPM:expression}}}, where 'expression' is any javascript statement that evaluates to true or false. This allows you to create hard-coded links in other documents that can selectively enable/disable the use of this option based on various programmatic conditions, such as the current username. For example, using
{{{#SPM:config.options.txtUserName!="SomeName"}}}
enables 'one tiddler at a time' display for all users //other than// "~SomeName")}}}
* If more than one display mode is selected, 'one at a time' display takes precedence over both 'top' and 'bottom' settings, and if 'one at a time' setting is not used, 'top of page' takes precedence over 'bottom of page'.
* When using Apple's Safari browser, automatically setting the permalink causes an error and is disabled.
<<<
!!!!!Revisions
<<<
2008.10.17 2.9.6 changed chkSinglePageAutoScroll default to false
2008.06.12 2.9.5 corrected 'scroll to top of page' logic in auto-scroll handling
2008.06.11 2.9.4 added chkSinglePageKeepEditedTiddlers option
2008.06.05 2.9.3 in displayTiddler(), bypass single/top/bottom mode handling if startingUp. Allows multiple tiddlers to be displayed during startup processing (e.g., #story:DefaultTiddlers), even if single/top/bottom mode is enabled.
2008.04.18 2.9.2 in displayTiddler() and checkLastURL(), handling for Unicode in tiddler titles (remove explicit conversion between Unicode and UTF, as this is apparently done automatically by encode/decodeURIComponent, resulting in double-encoding!
2008.04.08 2.9.1 don't automatically add options to AdvancedOptions shadow tiddler
2008.04.02 2.9.0 in displayTiddler(), when single-page mode is in use and a tiddler is being edited, ask for permission to save-and-close that tiddler, instead of just leaving it open.
2008.03.29 2.8.3 in displayTiddler(), get title from tiddler object (if needed). Fixes errors caused when calling function passes a tiddler *object* instead of a tiddler *title*
2008.03.14 2.8.2 in displayTiddler(), if editing specified tiddler, just move it to top/bottom of story *without* re-rendering (prevents discard of partial edits).
2008.03.06 2.8.1 in paramifier handler, start 'checkURL' timer if chkSinglePageMode is enabled
2008.03.06 2.8.0 added option, {{{config.options.chkSinglePageKeepFoldedTiddlers}}}, so folded tiddlers won't be closed when using single-page mode. Also, in checkURL(), if hash is a ''permaview'' (e.g., "#foo bar baz"), then display multiple tiddlers rather than attempting to display "foo bar baz" as a single tiddler
2008.03.05 2.7.0 added support for "SPM:" URL paramifier
2008.03.01 2.6.0 in hijack of displayTiddler(), added 'title' argument to closeAllTiddlers() so that target tiddler isn't closed-and-reopened if it was already displayed. Also, added config.options.chkSinglePageAutoScrolloption to bypass automatic 'scroll into view' logic (note: core still does it's own ensureVisible() handling)
2007.12.22 2.5.3 in checkLastURL(), use decodeURIComponent() instead of decodeURI so that tiddler titles with commas (and/or other punctuation) are correctly handled.
2007.10.26 2.5.2 documentation cleanup
2007.10.08 2.5.1 in displayTiddler(), when using single-page or top-of-page mode, scrollTo(0,0) to ensure that page header is in view.
2007.09.13 2.5.0 for TPM/BPM modes, don't force tiddler to redisplay if already shown. Allows transition between view/edit or collapsed/view templates, without repositioning displayed tiddler.
2007.09.12 2.4.0 added option to disable automatic permalink feature. Also, Safari is now excluded from permalinking action to avoid bug where tiddlers don't display after hash is updated.
2007.03.03 2.3.1 fix typo when adding BPM option to AdvancedOptions (prevented checkbox from appearing)
2007.03.03 2.3.0 added support for BottomOfPageMode (BPM) based on request from DaveGarbutt
2007.02.06 2.2.3 in Story.prototype.displayTiddler(), use convertUnicodeToUTF8() for correct I18N string handling when creating URL hash string from tiddler title (based on bug report from BidiX)
2007.01.08 2.2.2 use apply() to invoke hijacked core functions
2006.07.04 2.2.1 in hijack for displayTiddlers(), suspend TPM as well as SPM so that DefaultTiddlers displays in the correct order.
2006.06.01 2.2.0 added chkTopOfPageMode (TPM) handling
2006.02.04 2.1.1 moved global variable declarations to config.* to avoid FireFox 1.5.0.1 crash bug when assigning to globals
2005.12.27 2.1.0 hijack displayTiddlers() so that SPM can be suspended during startup while displaying the DefaultTiddlers (or #hash list). Also, corrected initialization for undefined SPM flag to "false", so default behavior is to display multiple tiddlers
2005.12.27 2.0.0 Update for TW2.0
2005.11.24 1.1.2 When the back and forward buttons are used, the page now changes to match the URL. Based on code added by Clint Checketts
2005.10.14 1.1.1 permalink creation now calls encodeTiddlyLink() to handle tiddler titles with spaces in them
2005.10.14 1.1.0 added automatic setting of window title and location bar ('auto-permalink'). feature suggestion by David Dickens.
2005.10.09 1.0.1 combined documentation and code in a single tiddler
2005.08.15 1.0.0 Initial Release
<<<
R0lGODlhWwAkAPf7AAAAAAgICBAQEBgQEBgQGCEYMSEpISEpMSkYISkpITEhMTEpKTEpMTEpOTEpSjExQjFSUjkhITkpMTkxOTkxSjk5Yzlac0IpIUIxMUI5KUJCUkJKa0JSY0JaY0JahEoxIUo5MUo5OUpCIUpjhEpjjEprc0pznFJCMVJCQlJSWlJSa1JaY1Jaa1JjWloxKVo5MVo5QlpCQlpCUlpCY1qEpVqMrWNKQmNKY2NSa2Naa2Nae2Nrc2NrhGN7jGsxOWs5OWtSKWtSOWtSQmtaSmtjOWuMe2uMhGuMnGuUrXM5UnNCWnNKa3NSc3NaWnNae3NjKXNrSnNze3N7jHtKUntjhHtrY3t7lHuEnHulvYRCOYRaWoRac4RjWoRje4Rra4RrjIR7Y4R7jIR7lISMa4SMjISMnISUpYxjQox7Qox7e4yMOYyMUoyMe4ylrZRzc5R7Y5R7lJSEe5SMnJSUa5xzc5yEe5yElJyMe5yUjJycnJycpaVKY6V7UqWEjKWUY6WcjKWle61zc62Ee62MSq2lY7WcnLWtrbW1pb21rb3GtcalSsalnMa1a861StaEjNbGWtbGa9bOe97Wa97We/fnSvfve////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////wAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD//////wAAAAAAAAAAAAAAACH5BAEAAPsALAAAAABbACQABwj8APcJHEiwoMGDCAtSyLFjB5MqKxJKnEixosWEKnhQoSJGTh49cEKKgSNGTI4UOyhcXMmyZUEYcOyIlMJDhw4VOHI6ofLlCxw9UVwKHYrwQh89Yr5IkULFiRObOnKqUDEhQAACN76kkUC0q1AQX+yEUUrFJg4GAhDI0EElRYEBVgP8I0DhCwaveC1e2IJ0Y1MdTgQEUBAiAFwCBEJMEEDgn1wMXyLknYzwAN+SX5wCTsETBQG5cR2DfswkTALKqAWK8GGopBgqTDYa+KdEwD/RcXPHRRBgwhYlqSfPGYCojBQxUtjmYPAPBQrcuqMbjuAERfC8AeyYsVKSbeHb+xNS/BMsPfo/BAQwaLnelYgPpHJKOpHhGEEX+qGlk4+ehD3RAH3kUQZJTBXmQgBTzAZdedENgMA+CGiAQhVB+VcRGC8YIoccYSTlBA4hxADaggsySMA+ESBhAgkjVDCCCkOAYSFCJ9ixYYcyfKaWEgiUyGAAackl2gUaINHDkUjUQMOSFgRAhx5kkBGGhYBEYAgccsARx4iO7fdjbgOY0QMLEBhAAAIxHNkDD2ouaUYAFCBBwwgkeBCAI0MBckccaAQBAghAiJDAAB+4oEceGzYxnlW3fSndAFYgIamkR/AAAQJX9GDCESSQsOk/GtSgZg13sjTGGlCsQUQQ+y9A8UIQacQRRxqGEAGDhnLo8RyQV3nJqH65HUHDkVccgaQBD5iQggom0IDEEaAu2cMRNfyDJ0WHgEGEtn6AEUIdEmVggyGI6iEeYv80oeBo5d0mAGM7GGtsmyUMsAACDTSgAQtFgMoDCz1YcYQAU7CRRkJzELGGH1CgcYdFCSiBqxx9BHBCFYY5KpcADWSUKWILpMCDCWvSsMMAGZnAwwgpJPBPCB0YIMAAcFFBwgwqOBAFuAIBIsIZkjxhA0tDwKDHhrlGEYABCPTIoG0DaMCDFZk6QPOgAURoxZItBBDFChQswLSQjQr2zwwmmJGkCRwYEAgRQEAiiSQL+3CBx0pjfHB00gsEEIHMP/7TgBRX8ECCDp8RsEDUnnIgAQ9IdDDebY0G8METaAzSiCRqnH1EQxqYiUAgIWQxt9yPEIIqBkGAUUUcEkWwtx453JaYj6BtMO/KbPKAQQRsjkDnCAjo0EOjmKuhyCOUNO985+TdFoIdA0UxBB9yz619JHOsgQYaKITwAhFNEGRAH4boYQgeA4TQWFy+BiBFGz2MwEIKHDSQQg868LCyDlZYGfFC8I8BKMJ5COTcE0TAqAIqYREHScMOhgAFRpwue5PQHiQIQQQiNGwNQcCAF3ZAoQLIIA05UJBjKHebHVghCiwgwchMMAAdCM9w+53qlAlKcJsBPEISlGiEGp6QgHdRziowgB1FolAFG6ABEpHIoCQgQUXtSWISlZBEFiPBCEYQwg9rCCMFg3CCBLQOCmCAggHg4pgQpAAFA4jCmlgwFRVo4I5VsQrNzMbC0OyhJVFoQgbQ4AdGPOIRkDjkISWxSCtW4pGQjKQkKzEJRowBCosbANQI8K7QdKmBLOwSGwUwmT+wgQ1gWMAU0pCGN0CBdd/73hqeAIWGNQwNYawl3ICQAQOs0WwywAISzHCEYh7hCm2YDaMYA4Mo9EEgLhvAH2aEhwkg5QsheMAWQsnNUFrFbAQIWLGOMKl+xeWZBsEDBGckkDEsrKAMesCDBIBkg07Gj0GiQQAD9CW1BVDOB+ysSBUQoAL1heEffbuno/6xTjx4AQwICIEX0BlQiiTCOWJY3wQiAD+NMYqiFSXKBBAgBj0UQg8USMz7FgqDkOYFDxEKQ65QgK8HyAx3txGCSydziCEsQANR0MNsIuAGDYSAj2RDgCB2mpo8yIACMkDADagQOgRQwKgDIMAP7sZU9uAhDEaIggwWgIIl4KEP66xoQAAAO/7vVGhpcyBHSUYgZmlsZSB3YXMgYXNzZW1ibGVkIHdpdGggR0lGIENvbnN0cnVjdGlvbiBTZXQgZnJvbToNCg0KQWxjaGVteSBNaW5kd29ya3MgSW5jLg0KUC5PLiBCb3ggNTAwDQpCZWV0b24sIE9udGFyaW8NCkwwRyAxQTANCkNBTkFEQS4NCg0KVGhpcyBjb21tZW50IGJsb2NrIHdpbGwgbm90IGFwcGVhciBpbiBmaWxlcyBjcmVhdGVkIHdpdGggYSByZWdpc3RlcmVkIHZlcnNpb24gb2YgR0lGIENvbnN0cnVjdGlvbiBTZXQAOw==
<<image SiteIcon>>
!!Personal site for Andre' de Carvalho's Software Development thoughts and more...
Most of the content will be Software Engineering related but other topics will emerge as well.
Hope you find it useful.
Software development thoughts and more...
[img[https://www.dropbox.com/s/yexreus6je9j3o7/shiplogo.gif?dl=1]] André de Carvalho
https://acarvalho.tiddlyhost.com
!!Friends
* [[Development with a Dot|http://weblogs.asp.net/ricardoperes/default.aspx]] - Ricardo Peres .Net technical blog with lots of enlightened information.
----
!!Friends
* [[Development with a Dot|http://weblogs.asp.net/ricardoperes/default.aspx]] - Ricardo Peres .Net technical blog with lots of enlighted information.
----
I do develop software for living and even get paid for it ;) .
<<quote 'Charlton Ogburn on reorganising' 'Charlton Ogburn on reorganising' 'open'>>
<<quote 'Ed Yourdon on Systems Analysis' 'Ed Yourdon on Systems Analysis' 'open'>>
I do not intend to present any new software development methodology. There are already many deserving that title and each one has its own strengths depending on the scenario you want to use it in. But I do want to present a comprehensive view of Software Development that focus on practical performance aspects of the domain.
# [[Software Development Process]] (SDP) - concepts and thoughts about software development as a process.
# [[Software Development Pattern]] - concepts and thoughts about Software Development practices, techniques, tools, methods, etc.
## [[Business Analysis]] - first the problem then the solution.
### [[RFP Analysis Guidelines]]
#### [[Traceability]]
#### [[Data Flow Diagram]]
### [[Technical Proposal Production Guidelines]]
#### [[Software Requirement vs. Feature]]
#### [[Validation]]
#### [[Application Archetype]]
## [[Software Specification]] - ask for things in the right way if you want them to be done well.
### [[Software Requirements Specification Guidelines]]
#### [[Writing Good Requirements]]
#### [[SMART Requirements]]
#### [[Requirement Boilerplate]]
### [[Software Architecture Specification Guidelines]]
#### [[Meta-architecture]]
## [[Software Construction]]
### [[Software System Documentation]]
## [[Software Maintenance]]
# [[High Maturity Practices]] - software development high maturity practices.
## [[Configuration Management]]
###[[Concurrent Versioning System]]
###[[Reuse oriented CVS]]
###[[Digital Artefact Identification]]
## [[Continuous Integration]]
## [[Static Analysis]]
###[[Implementing Static Analysis]]
## [[Unit Testing]]
## [[Peer Review]]
## [[Systematic Reuse]]
## [[Issue Management]]
# [[The Agile Problem]]
# [[The Methodological Problem]]
----
@@color:#c4d6ed; ^^
Description: The main page for software development matters.
^^@@
The term Software Development Model (SDM) is used to address [[Software Development Process]] (SDP) realization sequence.
SDM concept is used as Software Development Process Model to identify different sequence approaches to the development process like [[Waterfall|http://en.wikipedia.org/wiki/Waterfall_model]], [[Spiral|http://en.wikipedia.org/wiki/Spiral_model]], etc.
Although there are many development models one must acknowledge that we can not ''do'' before we know ''how'' to do and we can not choose how to do before knowing ''what'' to do and also that knowing ''why'' to do is very useful to know what to do. This implies that, ultimately, all models are little more than sequences of waterfalls.
----
See also : [[Software Development Pattern]]
----
@@color:#c4d6ed; ^^
Description: Software Development Model (SDM) concept as used here
^^@@
The term Software Development Pattern is used here to mean a set of resources, practices and techniques that shall frame [[SDP]]'s concrete performance. You may think of it in a similar manner as [[Design or Architectural Patterns|Design Patterns]] but applied to Software Development Process performance. In fact we are trying here to provide a set of very good, tested and proved solutions to common, recurrent challenges you will find in any Software Development endeavour.
!!Why do we need a Development Pattern?
The [[SDP]] establishes a formal software development process that is the basis for certification and performance at an high maturity level. On doing so it, however, usually assumes that all actors, Customer included, will perform at that level, which, many times, is not the case. On the other hand the [[SDP]] "starts" at Specification phase and assumes a proper Inception phase was performed and produced proper results to serve as its input, again, that, many times, is not the case.
The fact is that the Customer, in many projects, does not want or does not have the resources to produce a proper Inception phase with also proper results and so expects the software development company to help him to deal with the problem. When this fact is not properly acknowledged the risk exists that you will enter a "garbage in - garbage out" process in which everybody will loose.
It must be clear that an [[SDP]] that "starts" at Software Requirements Specification is assuming the Inception phase was properly performed and produced adequate results. The scenario where those results are not available or are not adequate is frequent, specially when dealing with customers whose primary concern is not software development, in these cases the assumption that "//the Customer does not know what he wants//" is a very dangerous one and a severe mistake. Of course the Customer knows what he want, we, the software development team, are the ones that do not know what the Customer want.
On the other hand, technical communication, effective technical communication, is a difficult task where mistakes are paid high. A development pattern may help in providing a common vocabulary and in making outcomes more predictable and homogeneous. See, for instance, <<quote 'Brad Appleton on patterns and communication' 'Brad Appleton on patterns and communication'>>
!!A Software Development Pattern
<<quote 'Henry L. Mencken on simplicity' 'Henry L. Mencken on simplicity' 'open'>>
A Software Development Pattern presents, for a domain (technical, business or other) and a known context, a set of proved and coherent choices on ''__how__'' to do it in order to produce excellent quality and predictable and reusable results.
Software Development Pattern is an integrated view of and comprises the process performance guidelines, techniques and infrastructure. __It also includes the definition of a full [[meta-model|http://en.wikipedia.org/wiki/Metamodeling]] for the project's information structure and content__.
It is a low-level technical asset not a management tool although it does have radical impacts in management concerns.
The Software Development Process is a rule, the Software Development Pattern is a guideline. You may override it in particular cases if you have a solid reason to do it.
The following topics address some of my findings, study and conclusions about success factors on software development projects for different Customers of an high maturity ([[CMMI|http://www.sei.cmu.edu/cmmi/]] level 5) company. Although the Company works with Customers like [[ESA|http://www.esa.int]], the scenarios I'm addressing here are the ones involving customers from industry, services, government or finance on medium size and criticality projects.
These projects often present enormous challenges, specially at Inception level, due to time and specification detail constraints. If you ever worked in one of these you know the feeling of being asked to produce a Technical Proposal, in a week, to compete with several other proponents. Of course you must be [[agile|Agile Methodologies]] ... but you also must get it right at the first attempt, you will not have another.
[[Systematic Reuse]], [[Opportunistic Productization]] and [[Continuous Improvement]] are the goals to pursue here. First objectives should be establishing a [[meta-model|http://en.wikipedia.org/wiki/Metamodeling]] for project full lifecycle (from Inception to Maintenance, Productization and Reuse) documentation (probably on [[EA|Sparx Enterprise Architect]]) and to establish a "[[Single Version of the Truth|http://en.wikipedia.org/wiki/Single_Version_of_the_Truth]]" (again probably on [[EA|Sparx Enterprise Architect]]).
An important foreword on this subject is that the execution pattern we are proposing works in a ''fall-back mode'', that is, although there are ideal moments and even sequences identified to perform these activities it is not always possible to perform them on those recommended moments. This does not mean that we just give up of doing them, we shall perform them as soon as possible! If I can't produce a good [[DFD|Data Flow Diagram]] at [[RFP]] Analysis I still shall do it at a later time, even if I did produce a DFD at Proposal I shall maintain and update it along all the project.
This also means that the project's model (the full model in the [[CASE]] tool used) is a living model constantly improved and updated, although its organization may lead You to think that it is a sequence ( of [[SDP]] phases ) it is not! In fact the proposed organization is oriented, mainly, to make standard [[SDP]] formal documents generation easier and promote structure recognition. Differently from what many Agile authors (wrongly) think, even a waterfall project, in real world, is always a spiral endeavor that progresses in refinement and breadth at each iteration. This has an important consequence that the model shall never be seen as a baseline artifact. The baseline artifacts are the specific documents generated from the model at milestone moments, the model is (shall be) an as updated as possible view of the present reality. For instance the [[DFD]] diagram started at [[RFP]] Analysis shall be continuously improved along the entire project (1).
----
(1) Of course that the scope contention role that it shall perform shall be done through its different incarnations on the baseline documents. On the model the [[DFD]] shall always represent everything we know up to the moment.
----
Back to [[Software Development]]
----
@@color:#c4d6ed; ^^
Description: a set of resources, practices and techniques that shall frame SDP's concrete performance
^^@@
A Software Development Process (SDP) intends to establish ''__when__'' and ''__what__'' has to be done in order to produce minimum quality assured and repeatable results.
This is not the main focus of this site as there are plenty process definitions available, our focus is more on the [[Software Development Pattern]] used when instantiating a defined [[SDP]].
----
/%
@@color:#c4d6ed; ^^
Description: Software Development Process (SDP)
^^@@
%/
"//(...) a software requirement is a property which must be exhibited by software developed or adapted to solve a particular problem.//"
[[Guide to the Software Engineering Body of Knowledge (SWEBOK)|http://www.computer.org/portal/web/swebok/html/ch2#ch2-1.1]]
For a distinction against [[Feature]] see [[Software Requirement vs. Feature]]
----
See also : [[SMART Requirements]] [[Writing Good Requirements]]
----
@@color:#c4d6ed; ^^
Description: Software Requirement concept explanation and reference.
^^@@
Business analysis literature commonly refers to ''Requirements'' (User, System and Software). See, for instance, <<BibRef "BABOK 2008">>. But, in the software world, ''Requirements'' have a very specific meaning and several conditions to be considered as such. The best characterization is in ''[[SMART Requirements]]'' <<BibRef "Mannion,Keepence 1995">>.
"//A great deal of formal and anecdotal evidence exists that the typical quality of actual requirement specifications today is embarrassingly poor. In practice, far too many requirements are ambiguous, incomplete, infeasible, unverifiable, inadequately prioritized, and mutually inconsistent [Firesmith 2003a]. In fact, this poor quality of individual requirements and the requirements specifications that document them is a primary reason why so many projects continue to fail [Standish 1994].//"
Donald G. Firesmith: “Quality Requirements Checklist”, in [[Journal of Object Technology, vol. 4|http://www.jot.fm/issues/issue_2005_11/column4]], no. 9 November - December 2005, pp. 31 - 38
Experience tells us that it is not so often that we find SMART requirements in ''Requests for Proposal'' or even in ''Technical Proposals'', they usually only appear, if they do at all, on the ''Specification Phase'' in ''Requirements Gathering''. Using the ''Requirements'' concept in a superficial and stressed phase, as the ''Inception'' usually is, is dangerous as it implies a concreteness degree that is seldom or never achieved. This leads to misunderstandings and miscalculations that may be very hard to solve. It also increases the risk of expressing artificial requirements that do not correspond to an effective need but will condition architecture sometimes preventing the best choices.
<<Image "FR" "250" "Requirements-Elements.png" "https://dl.dropbox.com/" "s/o4ewv8nlr4vfb7w/" "?dl=1" "Feature element in EA.">>
''[[Feature]]s'' are an higher abstraction level towards ''[[Software Requirement]]s'' in the sense that they allow a more relaxed expression of a need or of a commitment. Features can be as [[SMART|SMART Requirements]] as Requirements but they need not to be. The required characteristics of a feature are :
* ''Need oriented'' : A [[feature|Feature]] is a service that the system provides to fulfil one or more stakeholder needs.
* ''Specific enough'' : they are atomic to the granular level possible at the circumstances.
* ''Reasonable scope'' : they provide a reasonable scope delimitation for the request or proposal.
* ''Support estimation'' : they provide support for estimation within the accepted risk levels.
* ''Support Validation'' : they support Customer [[validation|Validation]] of Proposal understanding, adequacy, completeness and contractual commitment.
* ''[[Traceable|Traceability]]'' : uniquely identified and relatable to stakeholders, between request and proposal and between proposal and requirements.
Features concreteness level may range from very specific user requirement ("The system shall support IE 6.0.") to very diffuse problem statements ("The system shall optimize data entry effort.") to which the software company is expected to give the best possible answer. Of course Proposed Features shall narrow Requested Feature's scope in order to provide a validateable direction to proposed solution and a [[controlled scope|Scope Management]] for the Proposal.
----
Back to [[Business Analysis]]
See also [[Feature]]
----
@@color:#c4d6ed; ^^
Description: definition and discussion of the two concepts and their usage.
^^@@
Also known as bit rot, code rot, software entropy, software erosion or software decay.
<<Image "FR" "" "BoehmsCurve.JPG" "https://dl.dropbox.com/" "s/cq6e3p0wiwpl4pq/" "?dl=1" "Boehm's Curve">>
In //Software Engineering Economics//, 1981, [[Barry Boehm|http://csse.usc.edu/csse/about/people/faculties/BarryBoehm.html]] showed that change's cost exponentially increases along software life-cycle.
In my opinion this is the most important aspect of software rot and not the performance issues that are commonly referred to the concept today.
It shall be noted that not only bugs and design flaws matter here but also, and, probably mostly, the normal evolutive maintenance changes that any really used professional software must undergo.
Casuistic quick adaptation hacks and features are the most common cause of decay. And they add to each other up to an unmanageable, uncorrectable and impossible to improve system. The main problem here is to not perform [[refactoring|Refactor]], or even redesign, when they are needed. But refactoring and redesign are expensive so we should focus on ways to make them easier, platform based software and [[Systematic Reuse]] principles and methodologies are good steps for these goals.
A software system that is not based on a platform maintained with [[Systematic Reuse]] and [[Continuous Improvement]] will decay over time and became legacy or obsolete software. If it is really used in a professional environment it will, rapidly, become unmaintainable and impossible to improve to respond to its user's needs.
[[Refactoring|Refactor]] is a way of dealing with the problem of software rot. [[Systematic Reuse]] also contributes to prevent it.
----
@@color:#c4d6ed; ^^
Description: Software Rot concept explanation and discussion.
^^@@
<<Image "FR" "350" "RUP-Elaboration.png" "https://dl.dropbox.com/" "s/wswkdlgwx5gdqpm/" "?dl=1" "This is the RUP vision of the Development Process.">>
Software Specification occurs mainly in the ''Elaboration Phase'' and encompasses :
* Software Requirements Specification (SRS)
* Software Architecture Specification (SAS)
At this point you are working in a won software project. The first thing to consider is that You are not starting from scratch but continuing a project that started before and produced already some information, mainly, a Proposal that shall frame all your work. This is the next stage on model construction, in this iteration we shall refine and detail Requirements and Architecture in order to achieve a clear and suficient specification for system implementation.
The next consideration is that, not like many people on the Agile field think, Requirements and Architecture are not pure sequential activities. They interact and feed each other. Its true that Architecture shall respond to Requirements but Requirements gathering must also be oriented by envisioned Architecture in order to gather the needed information to build the system.
The first part of Requirements and Architecture was done at what we called [[Business Analysis]] section ( Inception phase in RUP ) in the [[Request for Proposal Analysis|RFP Analysis Guidelines]] and [[Technical Proposal production|Technical Proposal Production Guidelines]] activities. Those activities had defined goals, mainly:
* allow for ''estimation'' of the proposed work within the accepted risk level
* reassure the Customer on our ''understanding of the problem'' and ''ability to overcome it''
* and, of course, to establish a ''contractual baseline on scope''.
Here we are in a new phase (Elaboration in RUP) that has a different set of goals. This phase is much more //pure software engineering// and it really does not matter that much what management approach you will work in, be it Waterfall, Spiral (with or without staged delivery), Agile or whatever, ''you need to technically specify to develop software'' (at least when working in a team). And make no mistake, this is as technical as coding and requires as much (if not more) knowledge, experience and vocation.
----
Back to : [[Software Development]] [[Software Development Pattern]]
See also : [[Development Links]]
----
This [[ontology|https://en.wikipedia.org/wiki/Ontology_(information_science)]] is intended to represent software development knowledge oriented to reuse asset discovery and human resource management as well as strategic technical analysis and planing.
The proposed classes are not closed and are oriented by the meaningful relationships you may establish among them. They are focused on the questions you may want to put to the system in a drill-down approach.
The main idea is that information is added continuously to the system and, along time, by establishing relationships, knowledge is built. This is essential to manage know-how in your company, access knowledge gaps, strengths and weakness, detect trends.
!!Classes
<<Image "" "" "SoftwareDevelopmentOntology.PNG" "https://dl.dropbox.com/" "s/5tdv4n38z9imrop/" "?dl=1" "Software Development Ontology classes.">>
''People''
People class holds people be it Customer personnel, collaborators, external experts, etc.
''Customer''
Customer organizations we interact with.
They may establish relationships among themselves when necessary.
''Location''
Locations may be geographical locations or organizational locations.
It is intended to provide the ability to access proximity (of people, teams, Customers, etc.).
''Project''
Projects are aggregators and correspond to the Project Management concept.
''Proposal''
A formal proposal for a project.
''Vertical''
Vertical is a broad business area that requires specific treatment.
''Domain''
Business domain corresponds to a coherent and common set of business needs that appear across relevant sets of projects and Customers and, possibly, Verticals.
''Standard''
Standards are established standards that are required by Customers or Verticals or even by internal Quality or Architectural policies.
''Certification''
Certifications are formal acknowledgements that a Customer or People have.
Certifications may be linked to standards and, when from a Customer, may impose requirements to the projects.
''Area''
A technical area is a broad division that, typically, means technical comfort or high productivity zones for people.
It may also imply technical compatibility.
.Net, Java, ASP .Net, BI, DB, Mobile, Business Analysis, Requirements, Architecture, Continuous Integration, Unit Testing, Static Analysis, Configuration Management, etc.
''Pattern''
A pattern is an application architectural solution type. An architectural pattern like ORM, CRM, CEP, Pipes&Filters.
''Tool''
A tool is a tool, that is, something we use as an aid to produce our results. A tool may require Techniques, has expert People and be used in Projects.
''Technique''
A technique is something that a person may have expertise in and that is required to use a tool or that is used by projects to produce some results.
C#, UML, English are examples of techniques one may possess and use.
''Framework''
A framework is a development platform that may have experts and be used in projects.
''Resource''
A resource may be anything useful, a book, a web site, etc.
''Tag''
A tag is just a tag, that is, something that qualifies other classes through Association.
!!Relationships
<<Image "" "" "SoftwareDevelopmentOntology2.JPG" "https://dl.dropbox.com/" "s/v8rs37f2rm5ulep/" "?dl=1" "Software Development Ontology relationships.">>
TODO: update classes and relationships
----
/%
@@color:#c4d6ed; ^^
Description: A Software Development domain ontology proposal
^^@@
%/
!Software Selection
|Area|Name|Description|OS|Type|h
|Notes|[[Markor|https://gsantner.net/project/markor.html]]|Offline and private <br>Markor is a TextEditor for Android. This project aims to make an editor that is versatile, flexible, and lightweight. Markor utilizes simple markup formats like Markdown and todo.txt for note-taking and list management. Markor is versatile at working with text, it can also be used for keeping bookmarks, copying to clipboard, fast opening a link from text and lots of more. Created files are interoptable with any other plaintext software on any platform.Markor is using open formats and is free software, openly developed and accepts community contributions.|Android|Free/OS|
|~|[[Todo.txt|http://todotxt.org/]]|Offline and private <br>Todo.txt apps are minimal, todo.txt-focused editors which help you manage your tasks with as few keystrokes and taps possible.|All|Free/OS|
----
~~Back to [[SoftwareToolsPage]]~~
----
/%
@@color:#c4d6ed; ^^
Description: Organized by topic software selection page
^^@@
%/
----
See also [[References|ReferencesPage##Architecture]]
----
This page is a personal collection of software tools I find particularly interesting or useful.
See also the topic organized [[Software Selection|SoftwareSelection]] page
See also the dedicated [[Programming Tools]] page.
See also the dedicated [[Privacy|PrivacyPage]] page.
!!Outstanding sites
* [img(150px+,+)[http://www.nirsoft.net/nirsoft2.gif]] [[NirSoft web site|http://www.nirsoft.net/]] provides a unique collection of small and useful freeware utilities, all of them developed by Nir Sofer.
* [img(150px+,+)[https://web.archive.org/web/20210515043246im_/https://cache.oahermes.com/images/logo.png]] [[www.oldapps.com|https://web.archive.org/web/20210515053706/https://www.oldapps.com/]] - Essential to fight nowadays "programmed obsolescence" obscenity.
!! Information management
* [img[https://dl.dropbox.com/s/x5pa51wewk8ymr8/TiddlyWiki.png?dl=1]] [[TiddlyWiki|http://www.tiddlywiki.com/]] - a reusable non-linear personal web notebook. ~TiddlyWiki is written in HTML, CSS and ~JavaScript to run on any reasonably modern browser without needing any ~ServerSide logic. It allows anyone to create personal ~SelfContained hypertext documents that can be published to a ~WebServer, sent by email, stored in a ~DropBox or kept on a USB thumb drive to make a ~WikiOnAStick. Because it doesn't need to be installed and configured it makes a great ~GuerillaWiki.
* --[img[http://tiddlyspot.com/_ts/images/banner-logo.png]] [[TiddlySpot|http://tiddlyspot.com/]] - ~TiddlySpot builds on the tried and tested tiddler model introduced by ~TiddlyWiki by moving tiddlers to the web.--
* [img[https://tiddlyhost.com/assets/logo-d172f33f619f67863d9e0c60088fc1f396e6e85a7938f0b9c11049ef10c045fd.svg]] [[TiddlyHost|https://tiddlyhost.com]] - The successor to ~TiddlySpot (that succeded ~TiddlySpace) and is, today, the golden standard for hosting ~TiddlyWiki.
* [img(150px+,+)[http://freemind.sourceforge.net/wiki/images/thumb/c/c8/FreeMind-computer-knowledge-080.png/800px-FreeMind-computer-knowledge-080.png]] [[Freemind|http://freemind.sourceforge.net/wiki/index.php/Main_Page]] - ~FreeMind is a premier free mind-mapping software written in Java.
!! <html><a name="Online" /></html> Online Services
* [img(38px+,+)[https://dl.dropbox.com/s/e8oenx53kn8z392/dropbox_48x48.ico?dl=1]] [[Dropbox|https://www.dropbox.com]] - Dropbox is a free service that lets you bring all your photos, docs, and videos anywhere.
!! <html><a name="Security" /></html> Security
* [img(150px+,+)[https://www.safer-networking.org/wp-content/themes/spybot3-pepi/img/spybot-blue.svg]] [[Spybot-S&D|http://www.safer-networking.org/en/index.html]] - the free, fully functioning privacy and anti-malware software brought to you for over 10 years by ~Safer-Networking!
* [[TrueCrypt|http://www.truecrypt.org/]] - Free open-source disk encryption software for Windows 7/Vista/XP, Mac OS X, and Linux.
** [img[https://truecrypt.ch/wp-content/uploads/2014/06/TCN-logo1.png]] [[TrueCrypt.ch|https://truecrypt.ch/]] - TrueCrypt must not die. TrueCrypt.ch is the gathering place for all up-to-date information. Unfortunately TrueCrypt.org really is dead. But, we organize a future.
** [img(38px+,+)[https://avatars.githubusercontent.com/u/5839944?v=4]] [[Open Crypto Audit Project|https://opencryptoaudit.org/]] - The Open Crypto Audit Project (OCAP) is a community-driven global initiative which grew out of the first comprehensive public audit and cryptanalysis of the widely used encryption software TrueCrypt®.
*** [[Verified Windows, OSX, Linux TrueCrypt v. 7.1a binaries and source files|https://github.com/AuditProject]] on ~GitHub
* [img(38px+,+)[http://keepass.info/images/plockb75.gif]] [[KeePass Password Safe|http://keepass.info/]] - the free, open source, light-weight and easy-to-use password manager.
!! <html><a name="SystemUtilities" /></html> System utilities
* [img[http://www.steffengerlach.de/freeware/_scnthumb.gif]] [[Scanner|http://www.steffengerlach.de/freeware/]] - This tool uses a sunburst chart to display the usage of your hard disk or other media. The chart shows all major files and folders from all directory levels at once.
* [[ClickFix|https://github.com/CemraJC/clickfix]] - Tame your mouse - stop annoying repeat clicks. It works!
----
{{imgfloatleft{[img(150px+,+)[http://www.sparxsystems.com/images/products/logos/EA.png]]}}}{{imgfloatright{[img(250px+,+)[http://www.sparxsystems.com/images/products/ea/recording_thumb.jpg]]}}}
Enterprise Architect is my primary tool in software development specification and documentation activities. For me it is a full life-cycle tool that I use from Inception, through code documenting and reuse management up to the end of life of each solution.
|EA specific articles in this site|h
|<<list filter [tag[EA]]>>|
[[Sparx Enterprise Architect|http://www.sparxsystems.com/]] [[CASE]] tool.
----
!!Additional resources
* [[Sparx Systems Enterprise Architect Community Site|http://community.sparxsystems.com/]]
* [[Exploring EA|http://exploringea.com/]] - Learning, experimenting and extending Sparx Systems Enterprise Architect
* [[Enterprise Architect (Sparx Systems) User Group|http://www.linkedin.com/groups?home=&gid=1356]] - Linkdin group on EA
* [[eaWorkplace|http://www.eaworkplace.com./]] - your one-stop shop for all Sparx Enterprise Architect tools, services and talent.
* [[Geert Bellekens|http://bellekens.com/]] - Freelance UML and Enterprise Architect consultant
----
@@color:#c4d6ed; ^^
Description: Sparx Enterprise Architect CASE tool.
^^@@
!The Stable Dependencies Principle (SDP)
"//THE DEPENDENCIES BETWEEN PACKAGES IN A DESIGN SHOULD BE IN THE DIRECTION OF THE STABILITY OF THE PACKAGES. A PACKAGE SHOULD ONLY DEPEND UPON PACKAGES THAT ARE MORE STABLE --THAT-- THAN IT IS.//"
Robert C. Martin
https://web.archive.org/web/20151203170924/http://www.objectmentor.com/resources/articles/stability.pdf
----
/%
@@color:#c4d6ed; ^^
Description: OOP Robert C. Martin packaging principle
^^@@
%/
The metaphor of dwarfs standing on the shoulders of giants (Latin: //nanos gigantum humeris insidentes//) expresses the meaning of "discovering truth by building on previous discoveries". This concept has been traced to the 12th century, attributed to Bernard of Chartres. Its most familiar expression in English is by Isaac Newton in 1675: "If I have seen further, it is by standing on the shoulders of giants."
[[Wikipedia|https://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants]]
----
/%
@@color:#c4d6ed; ^^
Description: Isaac Newton : If I have seen further, it is by standing on the shoulders of giants.
^^@@
%/
In our scope Static Analysis refers to ''Static Code Analysis''. It is static because it is a code quality analysis done without running the code. In this sense a code inspection may be considered a form of static analysis. Modern tools for automated static analysis that detect known problematic patterns or rule violations are common nowadays and provide a very good quality return with little effort and investment. At static analysis' high-end we also include formal Code Inspections, or Code Reviews, performed by a group of programmers, but these are expensive and shall be reserved for targets that automated tools can not achieve.
Static Analysis targets are ''defects'', that is, code patterns that are known to cause problems or ''violations'', that is, occurrences that violate an existent coding rule or guideline (naming conventions for instance). Targets also encompass ''errors'' that can be discovered in Code Inspections as unconsidered risks, limitations or scenarios or even logical mismatches against requirements.
Static Analysis is one of the [[High Maturity Practices]] in [[Software Development]].
For a guideline on enterprise wide implementation of static analysis see : [[Implementing Static Analysis]]
!!Static Analysis References
* Tools
** [[List of tools for static code analysis|http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis]] From Wikipedia, the free encyclopedia.
* Implementing
** [[Deploying Static Analysis|http://www.drdobbs.com/testing/deploying-static-analysis/240003801?pgno=1]] by Flash Sheridan, 2012 - Static analysis is a cheap and easy way to find bugs, but it offers important challenges that tend to be more political than technical.
** [[How to Spring Clean Your Static Analysis: 10 Tips|http://www.codeproject.com/Articles/589448/How-to-Spring-Clean-Your-Static-Analysis-10-Tips]] by c_a_dunlop, 2013 - A [[Code Project|http://www.codeproject.com]] article with some interesting tips.
----
@@color:#c4d6ed; ^^
Description: Static Analysis concept, discussion and references.
^^@@
/* -------------------------- */
/* Mind Map */
/* -------------------------- */
.mindMap {
height: 300px;
margin: 16px 448px 0px 72px;
}
/* -------------------------- */
/* Image padding */
/* -------------------------- */
.viewer img { padding:0em 0.5em 0em 0.5em; }
/* -------------------------- */
/* -------------------------- */
/* Image formatting for float */
/* -------------------------- */
.imgfloatleft{float:left;}
.imgfloatright{float:right;padding:5px}
.imgfloatcenter{float:center;}
/* -------------------------- */
/* -------------------------- */
/* Site titles */
/* -------------------------- */
.siteTitle {
font-family: script;
font-size: 3.0em;
font-weight: bold;
}
.siteSubtitle {
font-family: script;
font-size: 1.5em;
font-weight: bold;
padding-left: 1.0em;
}
/* -------------------------- */
/* -------------------------- */
/* Tiddler options*/
/* -------------------------- */
.tiddler .subtitle { display:none; }
/* -------------------------- */
/* -------------------------- */
/* Font selection */
/* -------------------------- */
body {
font-family: "Lucida Sans Unicode", freesans, clean, sans-serif;
font-size: 1.0em;
}
/* -------------------------- */
/*{{{*/
/* This was the original border around the tab section at top */
/*
#tiddlersBar {
margin: 0.5em;
border: 1px [[ColorPalette::TertiaryLight]] solid;
background-color:[[ColorPalette::Background]];
}
*/
/* Undo the xxx to have an underline / border underneath TopMenu or the tab section
#tiddlersBar {
margin: 0.5em;
border-bottom: 1px [[ColorPalette::TertiaryLight]] solid;
border-top: 1px [[ColorPalette::TertiaryLight]] solid;
background-color:[[ColorPalette::Background]];
}
*/
/* line-height controls the second row of tabs at top. Not noticeable until after 21px; */
#tiddlersBar .tab {
white-space: nowrap;
padding: .2em;
border: 1px [[ColorPalette::PrimaryDark]] solid;
line-height: 30px;
}
#tiddlersBar {padding : .5em}
.tabUnselected .tabButton, .tabSelected .tabButton {padding : 0 2px 0 2px; margin: 0 0 0 0px;}
.tiddler, .tabContents {border:0px [[ColorPalette::TertiaryLight]] solid;}
.tabUnselected { background-color:[[ColorPalette::TertiaryLight]];}
.tabSelected { background-color:[[ColorPalette::PrimaryLight]];}
#tiddlersBar .button
{
border:0;
padding-right: 5px;
padding-left: 5px;
}
/*}}}*/
chkPrivateMode: false
txtUploadStoreUrl: store.cgi
txtUploadUserName: acarvalho
txt_GATracker_id: UA-32849239-1
txt_GATracker_track: 1%2C1%2C1%2C1%2C1%2C1%2C1
Systematic reuse opposes to //ad hoc// (or opportunistic) reuse as it involves defined practices, processes, management and infrastructure that allow [[Continuous Improvement]].
//Ad hoc// reuse, or opportunistic reuse, is just a scavenging practice unable to scale and doomed to fall way back of systematic reuse potential. It is usually performed as [[Reuse by Copy|Reuse by Reference]] and, as such, it does not promote [[Continuous Improvement]] and is destined to [[rot|Software Rot]].
''Systematic reuse starts, and has its major potential, at processes, analysis and specification, not on code.''
This is an often overlooked aspect as, most people, think in __reuse code__ as the first reuse topic. ''The fact is that reuse is easier towards abstraction.'' Its easier to reuse a set of [[Feature]]s (business needs) than the specific [[Software Requirement]]s they originate, its easier to reuse a set of requirements than the specific code that was produced in response to them, its easier to reuse an interface than a concrete class. Of course that, if systematic reuse is in the mindset of your analysis and specification, chances are that you will also produce more reusable code.
''Systematic reuse improves overall quality of development artefacts as it provides [[Continuous Improvement]] opportunities.'' Each reuse instance is an opportunity to [[refactor|Refactor]], optimize, correct and enhance and, if [[Reuse by Copy|Reuse by Reference]] is avoided, these improvements propagate to all the other, past, present and future reuse instances.
''Systematic reuse is a major competitiveness factor.'' On tendering it allows us to focus on the specific Customer request challenges and not on technical common problems, this makes us more [[agile|Agile Methodologies]] and improves the quality of our response. Reuse (of proper reusable artefacts) also has an huge impact on cost contributing to a more competitive proposal. By using common, known and tested approaches we also reduce risk and improve estimation accuracy.
In [[Implementing Systematic Reuse]] we point out some guidelines that may be useful in this endeavour.
----
!!Other references on the topic
* Aravamudhan Narayanan (Vijay), on [[Art of Software Reuse|http://artofsoftwarereuse.com/]] - Enabling Organizational Agility using Systematic Software Reuse
----
See also : [[Emergent Reuse]], [[Reuse oriented CVS]], [[Reuse Obstacles]]
----
@@color:#c4d6ed; ^^
Description: Systematic Reuse concept explanation and discussion.
^^@@
/***
|Name|TagCloudPlugin|
|Source|http://www.TiddlyTools.com/#TagCloudPlugin|
|Version|1.7.0|
|Author|Eric Shulman|
|Original Author|Clint Checketts|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|plugin|
|Description|present a 'cloud' of tags (or links) using proportional font display|
!Usage
<<<
{{{
<<cloud type action:... limit:... tag tag tag ...>>
<<cloud type action:... limit:... +TiddlerName>>
<<cloud type action:... limit:... -TiddlerName>>
<<cloud type action:... limit:... =tagvalue>>
}}}
where:
* //type// is a keyword, one of:
** ''tags'' (default) - displays a cloud of tags, based on frequency of use
** ''links'' - displays a cloud of tiddlers, based on number of links //from// each tiddler
** ''references'' - displays a cloud of tiddlers, based on number of links //to// each tiddler
* ''action:popup'' (default) - clicking a cloud item shows a popup with links to related tiddlers<br>//or//<br> ''action:goto'' - clicking a cloud item immediately opens the tiddler corresponding to that item
* ''limit:N'' (optional) - restricts the cloud display to only show the N most popular tags/links
* ''tag tag tag...'' (or ''title title title'' if ''links''/''references'' is used)<br>shows all tags/links in the document //except// for those listed as macro parameters
* ''+TiddlerName''<br>show only tags/links read from a space-separated, bracketed list stored in a separate tiddler.
* ''-TiddlerName''<br>show all tags/links //except// those read from a space-separated, bracketed list stored in a separate tiddler.
* ''=tagvalue'' (//only if type=''tags''//)<br>shows only tags that are themselves tagged with the indicated tag value (i.e., ~TagglyTagging usage)
//note: for backward-compatibility, you can also use the macro {{{<<tagCloud ...>>}}} in place of {{{<<cloud ...>>}}}//
<<<
!Examples
<<<
//all tags excluding<<tag systemConfig>>, <<tag excludeMissing>> and <<tag script>>//
{{{<<cloud systemConfig excludeMissing script>>}}}
{{groupbox{<<cloud systemConfig excludeMissing script>>}}}
//top 10 tags excluding<<tag systemConfig>>, <<tag excludeMissing>> and <<tag script>>//
{{{<<cloud limit:10 systemConfig excludeMissing script>>}}}
{{groupbox{<<cloud limit:10 systemConfig excludeMissing script>>}}}
//tags listed in// [[FavoriteTags]]
{{{<<cloud +FavoriteTags>>}}}
{{groupbox{<<cloud +FavoriteTags>>}}}
//tags NOT listed in// [[FavoriteTags]]
{{{<<cloud -FavoriteTags>>}}}
{{groupbox{<<cloud -FavoriteTags>>}}}
//links to tiddlers tagged with 'package'//
{{{<<cloud action:goto =package>>}}}
{{groupbox{<<cloud action:goto =package>>}}}
//top 20 most referenced tiddlers//
{{{<<cloud references limit:20>>}}}
{{groupbox{<<cloud references limit:20>>}}}
//top 20 tiddlers that contain the most links//
{{{<<cloud links limit:20>>}}}
{{groupbox{<<cloud links limit:20>>}}}
<<<
!Revisions
<<<
2009.07.17 [1.7.0] added {{{-TiddlerName}}} parameter to exclude tags that are listed in the indicated tiddler
2009.02.26 [1.6.0] added {{{action:...}}} parameter to apply popup vs. goto action when clicking cloud items
2009.02.05 [1.5.0] added ability to show links or back-links (references) instead of tags and renamed macro to {{{<<cloud>>}}} to reflect more generalized usage.
2008.12.16 [1.4.2] corrected group calculation to prevent 'group=0' error
2008.12.16 [1.4.1] revised tag filtering so excluded tags don't affect calculations
2008.12.15 [1.4.0] added {{{limit:...}}} parameter to restrict the number of tags displayed to the top N most popular
2008.11.15 [1.3.0] added {{{+TiddlerName}}} parameter to include only tags that are listed in the indicated tiddler
2008.09.05 [1.2.0] added '=tagname' parameter to include only tags that are themselves tagged with the specified value (i.e., ~TagglyTagging usage)
2008.07.03 [1.1.0] added 'segments' property to macro object. Extensive code cleanup
<<<
!Code
***/
//{{{
version.extensions.TagCloudPlugin= {major: 1, minor: 7 , revision: 0, date: new Date(2009,7,17)};
//Originally created by Clint Checketts, contributions by Jonny Leroy and Eric Shulman
//Currently maintained and enhanced by Eric Shulman
//}}}
//{{{
config.macros.cloud = {
tagstip: "%1 tiddlers tagged with '%0'",
refslabel: " (%0 references)",
refstip: "%1 tiddlers have links to '%0'",
linkslabel: " (%0 links)",
linkstip: "'%0' has links to %1 other tiddlers",
groups: 9,
init: function() {
config.macros.tagCloud=config.macros.cloud; // for backward-compatibility
config.shadowTiddlers.TagCloud='<<cloud>>';
config.shadowTiddlers.StyleSheetTagCloud=
'/*{{{*/\n'
+'.tagCloud span {line-height: 3.5em; margin:3px;}\n'
+'.tagCloud1{font-size: 80%;}\n'
+'.tagCloud2{font-size: 100%;}\n'
+'.tagCloud3{font-size: 120%;}\n'
+'.tagCloud4{font-size: 140%;}\n'
+'.tagCloud5{font-size: 160%;}\n'
+'.tagCloud6{font-size: 180%;}\n'
+'.tagCloud7{font-size: 200%;}\n'
+'.tagCloud8{font-size: 220%;}\n'
+'.tagCloud9{font-size: 240%;}\n'
+'/*}}}*/\n';
setStylesheet(store.getTiddlerText('StyleSheetTagCloud'),'tagCloudsStyles');
},
getLinks: function(tiddler) { // get list of links to existing tiddlers and shadows
if (!tiddler.linksUpdated) tiddler.changed();
var list=[]; for (var i=0; i<tiddler.links.length; i++) {
var title=tiddler.links[i];
if (store.isShadowTiddler(title)||store.tiddlerExists(title))
list.push(title);
}
return list;
},
handler: function(place,macroName,params) {
// unpack params
var inc=[]; var ex=[]; var limit=0; var action='popup';
var links=(params[0]&¶ms[0].toLowerCase()=='links'); if (links) params.shift();
var refs=(params[0]&¶ms[0].toLowerCase()=='references'); if (refs) params.shift();
if (params[0]&¶ms[0].substr(0,7).toLowerCase()=='action:')
action=params.shift().substr(7).toLowerCase();
if (params[0]&¶ms[0].substr(0,6).toLowerCase()=='limit:')
limit=parseInt(params.shift().substr(6));
while (params.length) {
if (params[0].substr(0,1)=='+') { // read taglist from tiddler
inc=inc.concat(store.getTiddlerText(params[0].substr(1),'').readBracketedList());
} else if (params[0].substr(0,1)=='-') { // exclude taglist from tiddler
ex=ex.concat(store.getTiddlerText(params[0].substr(1),'').readBracketedList());
} else if (params[0].substr(0,1)=='=') { // get tag list using tagged tags
var tagged=store.getTaggedTiddlers(params[0].substr(1));
for (var t=0; t<tagged.length; t++) inc.push(tagged[t].title);
} else ex.push(params[0]); // exclude params
params.shift();
}
// get all items, include/exclude specific items
var items=[];
var list=(links||refs)?store.getTiddlers('title','excludeLists'):store.getTags();
for (var t=0; t<list.length; t++) {
var title=(links||refs)?list[t].title:list[t][0];
if (links) var count=this.getLinks(list[t]).length;
else if (refs) var count=store.getReferringTiddlers(title).length;
else var count=list[t][1];
if ((!inc.length||inc.contains(title))&&(!ex.length||!ex.contains(title)))
items.push({ title:title, count:count });
}
if(!items.length) return;
// sort by decending count, limit results (optional)
items=items.sort(function(a,b){return(a.count==b.count)?0:(a.count>b.count?-1:1);});
while (limit && items.length>limit) items.pop();
// find min/max and group size
var most=items[0].count;
var least=items[items.length-1].count;
var groupSize=(most-least+1)/this.groups;
// sort by title and draw the cloud of items
items=items.sort(function(a,b){return(a.title==b.title)?0:(a.title>b.title?1:-1);});
var cloudWrapper = createTiddlyElement(place,'div',null,'tagCloud',null);
for (var t=0; t<items.length; t++) {
cloudWrapper.appendChild(document.createTextNode(' '));
var group=Math.ceil((items[t].count-least)/groupSize)||1;
var className='tagCloudtag tagCloud'+group;
var tip=refs?this.refstip:links?this.linkstip:this.tagstip;
tip=tip.format([items[t].title,items[t].count]);
if (action=='goto') { // TAG/LINK/REFERENCES GOTO
var btn=createTiddlyLink(cloudWrapper,items[t].title,true,className);
btn.title=tip;
btn.style.fontWeight='normal';
} else if (!links&&!refs) { // TAG POPUP
var btn=createTiddlyButton(cloudWrapper,items[t].title,tip,onClickTag,className);
btn.setAttribute('tag',items[t].title);
} else { // LINK/REFERENCES POPUP
var btn=createTiddlyButton(cloudWrapper,items[t].title,tip,
function(ev) { var e=ev||window.event; var cmt=config.macros.cloud;
var popup = Popup.create(this);
var title = this.getAttribute('tiddler');
var count = this.getAttribute('count');
var refs = this.getAttribute('refs')=='T';
var links = this.getAttribute('links')=='T';
var label = (refs?cmt.refslabel:cmt.linkslabel).format([count]);
createTiddlyLink(popup,title,true);
createTiddlyText(popup,label);
createTiddlyElement(popup,'hr');
if (refs) {
popup.setAttribute('tiddler',title);
config.commands.references.handlePopup(popup,title);
}
if (links) {
var tiddler = store.fetchTiddler(title);
var links=config.macros.cloud.getLinks(tiddler);
for(var i=0;i<links.length;i++)
createTiddlyLink(createTiddlyElement(popup,'li'),
links[i],true);
}
Popup.show();
e.cancelBubble=true; if(e.stopPropagation) e.stopPropagation();
return false;
}, className);
btn.setAttribute('tiddler',items[t].title);
btn.setAttribute('count',items[t].count);
btn.setAttribute('refs',refs?'T':'F');
btn.setAttribute('links',links?'T':'F');
btn.title=tip;
}
}
}
};
//}}}
Tags are a very useful navigation and search mechanism in TiddlyWiki.
This space has several tags that group and categorize subjects.
When you open a tiddler its list of tags is in the upper right corner. You may click each tag to see a list of tiddlers tagged with it.
|Type|Tag|Description|h
|Generic|<<tag System>>|Support, configuration and functionality tiddlers for this space. You will only be interested in them if you want to know more about how TiddlyWiki and TiddlySpace work and how some functionality is made in this space.|
|~|<<tag Content>>|Main content of this site intended for visitors. All user content is tagged as such. Each subject in these tiddlers may, and most do, have other tags that further categorize its content|
|Subject|<<tag Acronym>>|Acronyms mainly from Software Engineering area|
|~|<<tag Concept>>|Software Engineering concepts with short descriptions and references.|
|~|<<tag Development>>|Software Development thoughts and tools.|
|~|<<tag EA>>|Sparx Enterprise Architect CASE tool usage guidelines and references.|
|~|<<tag Guideline>>|Software Engineering practical performance guidelines and detailed practical performance examples.|
|~|<<tag KM>>|Knowledge Management|
|~|<<tag OOP>>|Software Engineering Object Oriented Programming or Principles|
|~|<<tag Quote>>|Software Engineering important citations from important people.|
|~|<<tag Reuse>>|Software Reuse concepts, guidelines and information|
|~|<<tag Requirements>>|Software Requirements concepts, guidelines and information|
|~|<<tag Tool>>|Software selected tools|
|System|<<tag systemConfig>>|Tags tiddlers that are treated as code providing additional functionality to TiddlyWiki|
|~|<<tag excludeLists>>|Tags tiddlers that shall not appear in any list|
|~|<<tag excludeSearch>>|Tags tiddlers that shall not appear in search results|
!Tagcloud
<<tagCloud>>
----
/%
@@color:#c4d6ed; ^^
Description: Tag policy used in this space
^^@@
%/
Software Development Process tailoring "//is an activity that adjusts an abstract set of processes and activities to the needs of a concrete project by selecting processes and activities and/or reducing (or enlarging) their complexity, frequency, etc.//"
[[Software Development Plan Tailoring : A Goal Oriented Strategy Proposal|https://www.dropbox.com/s/p308qz0iwtnhvy8/Software%20Development%20Plan%20Tailoring.pdf?dl=1]] by André de Carvalho, 2002 (draft 1)
“//Tailoring is a key element in the organization’s ability to develop reasonable and efficient software development plans for use in managing and controlling projects within the organization.//”
Process Tailoring and the Software Capability Maturity Model – CMU/~SEI-94-TR-024 – Mark P. Ginsberg, Lauren H. Quinn – 1995
----
@@color:#c4d6ed; ^^
Description: Software Development Process tailoring concept and references
^^@@
!Introduction
After you performed [[RFP Analysis|RFP Analysis Guidelines]] you are ready to start building your Technical Proposal to use it as the basis for estimations and, as such, the basis for the Financial Proposal but also as a clear demonstration of capability able to persuade the Customer that you are the best technical choice to carry on his project.
{{tw_ttoc{}}}
!Technical Proposal Structure
The Technical Proposal is your contractual proposal to the Customer. It shall clearly close the scope of work and present your view of it to be validated by the Customer.
It is this view that determines effort estimation and cost proposed to the Customer and, as such, every effort shall be put on achieving a clear and closed scope to be used as a contractual reference.
The Technical Proposal may, and shall, refer the [[RFP]] if it is a formal one or may produce information that is supposed to came from [[RFP]] if it is an informal one.
Take notice that Proposal shall establish the structure and scope for Requirements gathering and, as such, it shall be as complete and detailed as possible.
At the Proposal closure the information items referred in [[RFP]] and Proposal shall be acquired no matter if from [[RFP]] or built in the Proposal. This is a very important aspect of safe and realistic proposals.
!!Glossary
<<Image "FR" "" "Technical-Proposal-Structure.PNG" "https://dl.dropbox.com/" "s/1ao4mpykaidyynt/" "?dl=1" "Technical Proposal Structure">> Never underestimate the importance of communication. Remember that each knowledge area has its own vocabulary, your Customer's included, and that a common vocabulary is essential to communicate any ideas. To establish a Glossary that you keep, validate and enhance shall be one of your priorities. [[EA|Sparx Enterprise Architect]] provides a good mechanism to produce a glossary and, of course, you shall reuse it in other projects with the Customer or even on the domain. Start it on the first day.
!!Problem and Solution Statement
This is an introductory section that shall give an overview of the problem and provide a context for the following sections. It shall reuse (structuring, extending and enhancing) the correspondent section on the RFP.
*EA usage:
**Packages as typographical elements of a document. Illustrative diagrams may be used if necessary.
*Internal section goals:
**This section shall present an introduction to the problem and its context. It shall also present a broad scope definition for the proposal. This shall be Customer view as we understand it.
*External section goals:
**This section shall be able to provide the Customer with the means to validate our conceptual understanding of his problem.
!!Solution Processes
This is the Proposal counterpart to RFP Business Processes section.
At this level we shall describe all business processes that the solution will support or contribute to. This is the system view of the business processes.
*EA usage:
**The Solution Processes diagram is Activity and the most relevant elements are Partition, Activities and Decision.
**Primary Relationship is Control Flow to convey sequence. The partitions shall reflect the relevant actors be them Customer organizational units or existing or to be developed systems. For each activity the role of the solution shall be stated. Solution Processes shall be structured in packages and the package shall contain a contextual introduction to the diagram. The diagram itself shall contain a textual description of the process.
* [[Traceability]] :
**Partitions shall trace to Roles.
*Internal section goals:
**This section shall present an overview of the system/solution processes and a description of the activities proposed. This is a major scope definition item as any externally observable solution feature must be present here.
*External section goals:
**Validate business view and understanding and solution [[coverage|Coverage]] of business needs.
!!Roles
This section shall describe all Roles that are relevant for the solution.
This information may came from the RFP or be constructed by a joint effort between Tendering and Technical Proposal Team. If necessary and possible it shall also involve Customer.
*EA usage:
**Diagram is Use Case. Role element is Actor. Actors may be related by Generalization/Specialization relationships. Actor description shall include a description of the role and solution interaction.
* [[Traceability]] :
**Roles shall be traced to RFP Stakeholders.
*Internal section goals:
**The Roles section provides a definitive list of Human interaction with the system. It may also represent other automated systems that play a role in the solution. This is an important information for instance to determine the different, Authorization based, interfaces the system must allow.
**This is also an important scope item as it provides a definitive list of foreseen interactions with the system.
!!Use Cases
This section shall describe all the Use Cases derived from Roles and Solution Processes interaction.
*EA usage:
**The Use Cases diagram is Use Case and the elements are Actor (from Roles) and Use Case. Use Cases shall be structured in packages the top package shall state the structuring criteria. Each package shall state its scope with a short description. Each Use Case may be detailed by filling its Scenarios in Basic or Alternate paths. Actors relate with Use Cases through Use relationship. Use Cases relate with each other through Include and Extends relationships. The Use Case elements may be hierarchically numbered with, at least, two levels (xx.xxx). It is advisable to use factor 10 increments.
* [[Traceability]] :
**Actors must be those in Roles. Use Cases may/shall be linked with Solution Processes' Activities as a way to detail them from an user interaction perspective.
*Internal section goals:
**When possible register User interaction foreseen by the Customer or envisioned by the proposal team. Validate completeness and adequacy.
**Help in defining proposal scope. The scope contribution is not definitive as Use Cases are used to detail User Interaction with the system when needed so its catalogue is not exhaustive, however if an Use Case exists it is a positive scope item that must be honoured.
*External section goals:
**Allow Customer to validate adequacy of the perceived GUI needs.
See also : [[Use Case Diagram]]
!!Solution Integration and Deployment
*Description:
**This section shall describe the integration environment of the solution, namely, describing and specifying external interfaces and protocols used for our system integration with existing or foreseen external systems.
*EA usage:
**The Solution Integration diagram is Deployment and the elements are mainly Node, Execution Environment, Component and Interface.
**Components shall be reused from Technical Solution.
* [[Traceability]] :
*Scope:
**The intended audience scope for the section is PUBLISHED.
*Internal section goals:
**This section is intended to define the integration needs of the solution by identifying all external systems and correspondent Interfaces and Protocols. This section shall also present a preliminary deployment environment specification for our system.
*External section goals:
**Validation of completeness of external systems list and identification of interfaces and protocols.
*When in doubt:
** Build assumptions.
*Notes:
*References:
!!Proposed Features
Proposed [[Feature]]s are your response to customer's Requested Features. They will be the main content of your Technical Proposal and the main content of your customer analysis on the suitability and advantages of your proposed solution.
*Description:
**This section shall present the complete list of Proposed Features for the solution. These are our response to the Requested Features from Customer and constitute our proposed agreement terms and solution scope.
*EA usage:
**The Proposed Features diagram is Requirements and the element is Feature.
**The Proposed Feature elements have FT- prefix.
**The Proposed Feature elements are hierarchically numbered with, at least, two levels (xx.xxx). It is advisable to use factor 10 increments.
* [[Traceability]] :
**Proposed Features shall trace (Abstraction) to Requested Features on RFP. Proposed Features shall be traced (Abstraction) from Software Requirements. Proposed Features may dependency trace to Issues and Assumptions and be associated to Ideas and Changes.
*Scope:
**The intended audience scope for the section is PUBLISHED.
*Internal section goals:
**This section shall contain the complete list of proposed Features and Assumptions in response to the RFP and, thus, be seen as the complete and primary scope definition for the Proposal.
*External section goals:
**This section shall allow Customer validation of completeness and adequacy of our proposal and serve as the complete agreement on project's scope.
*When in doubt:
**Any pending Issue at this stage shall be solved by an Assumption.
*Notes:
*References:
!!Technical Solution
On a Proposal the technical solution is, of course, preliminary. Nevertheless your Customer expects that you are able to convince him that you do have a solid technical solution and are able to execute it. He also wants, for sure, to access the compatibility and fitness of your proposed solution in his environment and evolution roadmap. Finally your Customer wants to be reassured that you understood the full scope and complexity of the problem and are taking that into account on your financial proposal and not just "tossing up a nice round number" over a simplistic view.
!!!Major Challenges
Identifying major technical challenges of the project is essential for estimation, know-how gathering and team assembling. Clearly stating them will also assure your Customer that you are a mature software developer that understood the problem and its solution and that your Proposal is solid, serious and proper for the task at hands. It is also a major asset when you have to "discuss the cost".
*Description:
**This section shall describe the major technical challenges rose by the project and propose approaches for each one.
*EA usage:
**This is a textual section.
**Correspondent Features, Components, etc. shall have their <<quote 'Difficulty attribute' 'EA Usage - Attribute Difficulty' >> set to High.
*Scope:
**The intended audience scope for the section is PUBLIC or PUBLISHED depending on the confidence of the analysis.
*Internal section goals:
**Internally this section must convey the assurance that all major technical challenges were considered. If a challenge has no immediate solution approach then Risks shall be created and Assumptions made.
**Technical challenges may also be rise from business challenges.
**This is an important factor in estimation accuracy. This is also important in defining know-how required and V&V potential main targets.
*External section goals:
**This section shall increase Customer confidence in a proper understanding and prioritisation of the solution challenges.
*When in doubt:
**Seek for Expert advise. Rise Risks and build Assumptions.
!!!Architectural Archetype
The <<quote 'Architectural Archetype' 'Application Archetype'>> is the spine of your solution's architecture. It is the first vision of it and will greatly determine all your other architectural choices, and, by the way, possibilities.
A known and well thought archetype will inspire confidence and provide a very good fitness [[validation|Validation]] element.
*Description:
**This section intends to convey the architectural, or, better, the meta-architectural archetype, in which the proposed technical solution will fit.
*EA usage:
**The Archetype diagram is CompositeStructure and the stack element is Part. You may use Boundary to separate tiers.
**The relationship is Connector from consumer to provider.
**This is a common Stacked Diagram as it is generally used in protocol illustration. Layers shall be vertically stacked inside tiers. Communication between tiers is important and also transversal concerns.
*Scope:
**The intended audience scope for the section is PUBLISHED.
*Internal section goals:
**The most important goal here is to establish an architectural basis, an archetype, from which solutions may be inferred in terms of commonly used patterns in the approach.
**Non-conventional parts of the proposed solution must be explicitly detailed as such. **Example : the solution uses a proprietary Authentication schema. The "standard" solution parts need not to be much detailed and may be just referred.
**This diagram is invaluable in accessing reuse candidates.
*External section goals:
**It must allow the Customer to identify as known the architectural basis of our architecture. The Customer shall also validate that the proposed meta-architecture fits in his existent/envisioned environment.
**This top folder shall contain a brief justification of the choice as well as a demonstration that it fits in Customer's existing systems/architecture. If it is a new/isolated system then the justification shall be more elaborated in order to be perceived as proper for future development and expansion (maturity, long term support forecast, adopters importance, etc. are important factors to consider and to show to the Customer that they were considered).
*When in doubt:
**Produce clear assumptions regarding suitability of the archetype and its used patterns.
*References:
>Microsoft Application Architecture Guide (2nd Edition)
>[[Application Archetypes|http://msdn.microsoft.com/en-us/library/ee658107%28v=PandP.10%29.aspx]]
!!!Development Environment
*Description:
**This section shall state the technologies to be used in the proposed project.
**In most of the cases this section shall be a direct reuse of the standard list of environments. A standard environment comprises IDE, language, Database, Third-parties, Frameworks, Tools, etc.
*EA usage:
**For now this shall be a textual description of the environment.
*Scope:
**The intended audience scope for the section is PUBLISHED.
*Internal section goals:
**The most important goal here is to establish an architectural environment that directs know-how gathering, team selection and costs forecast.
*External section goals:
**It must allow the Customer to identify as known the technological basis of proposed architecture.
**This top folder shall contain a brief justification of the choice as well as a demonstration that it fits in Customer's existing technologies. If it is a new/isolated system then the justification shall be more elaborated in order to be perceived as proper for future development and expansion (maturity, long term support forecast, adopters importance, etc. are important factors to consider and to show to the Customer that they were considered).
*When in doubt:
**Produce clear assumptions regarding suitability of the Development Environment.
*References:
!!!Preliminary Component Model
*Description:
**This section shall provide a preliminary component model decomposition of the system that is primary oriented to support estimation and reuse analysis.
**Attention shall be centred on Major Challenges and the strategies envisioned to deal with them. Also the modularization shall reflect the architectural archetype chosen.
*EA usage:
**The Preliminary Component Model (PCM) diagram is Component and the PCM main elements are Component and Interface.
**Decomposition shall progress from overview model to more detailed ones. Detail shall be the one that is enough to produce an effort estimation within the risk level accepted for the Proposal and without taking unnecessary compromise with specific solution designs.
* [[Traceability]] :
** Components shall Realize Software Requirements that, in this way, become their responsibilities. Components also Realize Interfaces and Aggregate Classes.
** Notice that this is a ''preliminary'' component model here at Proposal. It may be fully replaced by a Software Architecture Specification later.
*Scope:
**The intended audience scope for the section is PUBLISHED. Not all detail levels, however, may appear in final Proposal document as we must consider the level of Architectural compromise we want or are able to support at this phase.
*Internal section goals:
**Perform a first modular view of the system able to support estimation of effort, reuse analysis including third-parties, necessary know-how definition and challenge consideration demonstration and overcame strategy existence.
*External section goals:
**Perform a first modular view of the system that Customer's technical personal may validate.
**Generate confidence in our ability to deal with changes and achieve a good solution.
*When in doubt:
**Produce Assumptions. Identify Risks.
*Notes:
*References:
!!Assumptions
*Description:
**This section shall present the complete list of Assumption established for pending Issues, doubts or disambiguation.
*EA usage:
**The Assumption diagram is Custom and the element is Issue.
**The Assumption elements have AS- prefix.
**The Assumption elements are hierarchically numbered with, at least, two levels (xx.xxx). It is advisable to use factor 10 increments.
* [[Traceability]] :
**Assumptions shall dependency trace from any element they are related to.
*Scope:
**The intended audience scope for the section is PUBLISHED.
*Internal section goals:
**This section shall establish a closed scope for proposal even when issues and doubts are still present.
*External section goals:
**This section shall allow Customer validation of our assumptions and serve as a complete closure on project's scope.
*When in doubt:
**This is mandatory.
*Notes:
*References:
----
Back to [[Business Analysis]]
----
<<TiddlerToC min-entries:1>>
/%
@@color:#c4d6ed; ^^
Description: Guidelines for Technical Proposal Production
^^@@
%/
Test content
one change
----
/%
@@color:#c4d6ed; ^^
Description: TODO
^^@@
%/
{{tw_ttoc{}}}
!Introduction
Agile brought a needed reality check and optimization to some practices and methodologies used in software development. Unfortunately the quality and knowledge of its proponents was not met by a large part of its current followers and evangelists. The unfortunate result is that you see a considerable retrogress in many software development practices and methods with profound consequences in the result's quality.
On the following text I'm taking Agile with a broad sense to encompass everything that is commonly done under its name. I do know that the origins of many of these things are not Agile (not even SCRUM) like the backlog that comes from Kanban and that many things done and said today, under the Agile buzzword, would never cross Agile proponent's minds but, for practical purposes, I'm referring as Agile all the practices and ideas that are, nowadays, fashionable as opposed to structured methodologies. May the respectable authors of the [[Agile Manifesto|https://agilemanifesto.org/]] forgive me.
Agile proposes a method for user functional needs capture based on User Stories and, indeed, they are a good approach to iteratively capture the gap between the current user status and his desired one. In rapidly changing environments like e-commerce or "social" applications or even in product first stages development, experimentalism and "fail-fast" are necessary and specification detail may be a waste of effort and imply an unsatisfactory time-to-market. Also on evolutive maintenance, over a known and solid platform, this gap oriented specification is, in many cases, the most effective and efficient approach.
Agile also proposes a team management methodology that advocates team autonomy and sufficiency and this is a much welcome change in that it empowers team's people and potentiates much more realistic, and committed, plans and deadlines. It also optimizes change reaction effort with its self-contained sprints and dynamic backlog (if compared with the worst case, and hypothetical, full project re-planning on other scenarios).
Agile also proposes an estimation approach based on story points and evolving team's average velocity that provides much more objective results than many other methods. The planning approach based on small, self-contained sprints and the maintenance of a backlog presents clear advantages on the proper scenarios.
But, as any other methodologies, Agile has an exploration scenario, the ''Agile Problem'' is that, nowadays, most of its evangelists have a <<quote 'silver bullet' 'No Silver Bullet'>> view of it and force it into any scenario and software development task, many times with "out of thin air", inefficient, immature and obsolete approaches that produce "pretend to be" solutions that greatly affect the software solution's quality and the team's continuous growing and comfort.
The problem (using Agile where it is not supposed to be used) is exacerbated by the fact that, in many projects and teams, it is overcome with technical leadership performing all the tasks that Agile do not cover in an "off-the-record" fashion without any guidance, planned effort, method and peer support.
This scenario, with all the lone responsibility it produces, tends to rapid burn-out of technical leadership that soon resorts to self-preservation mode just doing and using what "everybody does and uses", being this, typically, purely determined by volatile commercial strategies of the big players on the domain, and fall-back to the tired (and false) excuse of "the Customer does not know what he wants".
The sum-up is that, in many agile projects, the agile management methodology (with its myths and misconceptions around a handful of very basic principles) just obfuscates Software Engineering practices and techniques without providing any other real alternative.
Another aspect of the Agile vs. the other methodologies discussion, nowadays, is that Agile advocates are, typically, demagogic by presenting a best-case scenario for Agile vs. a worst-case, purely hypothetical and ultimately stupid, scenario for other methodologies. This line of discussion is effective for non technical deciders and inexperienced practitioners but is totally damaging for any serious and informed discussion.
As a starting point for this discussion it is necessary to (re)explore the concept of <<quote 'essential complexity' 'Essence of software'>> characteristic of software systems or, at least, of interesting and relevant software systems. It is also necessary to establish that ''usability'' has very different meanings for a web site to sell shoes than what it has for a professional software tool. It must also be noticed that "minimum viable product" is a concept (equivalent to prototype or proof-of-concept) that has its exploration context but that no professional wants his daily tools to be "minimum" or just an experiment. And, of course, it is necessary to expose the Agile's fallacious arguments around [[BDUF (Big Design Up Front)|https://en.wikipedia.org/wiki/Big_Design_Up_Front]].
!!Complexity
Software systems are <<quote 'inherently complex' 'Frederick P. Brooks on Complexity'>>.
Since [[Rene Descartes |http://www.marxists.org/reference/archive/descartes/1635/discourse-method.htm]] that we know that complex problems shall be attacked with method and all military know that <<quote 'plans are useless but planning is essential' 'Dwight D. Eisenhower on plans'>>.
Complex software systems need to be specified in a structured way to be developed with the bare minimum of quality. Most agile instantiations completely hide this truth and inexperienced practitioners are convinced that they can tackle a complex professional software system the same way they do some "more of the same" selling websites. That's simply not true.
!!Usability and users
<<quote 'No, the user is no longer the king.' 'Tom DeMarco on the Software Analyst role'>> Most professional users have no clue on what are the possibilities that a software system can bring to their work, very few of them will have a "system view" and even fewer will consider the system and its data potential in the medium term. Almost none of them will understand the technical trade-offs implied in their software choices. I'm not insulting the users: its not their job to design and build software. Its ours.
Any professional software tool has a learning curve. That is the counterpart of its power and potential. To demand that a software tool for complex tasks be "intuitive" is just plain stupid and, most of the times, originates a solution that is "funny" in the first couple of days and a limiting pain for the next five or six years of its usage.
!!MVP approaches
Minimum Viable Product approaches are essential in many contexts and an aberration on other. If You are trying to build a new product or service, of course that You want to prototype, explore and "fail fast". Nobody wants to invest an year just to discover that his public is interested in something else. In these contexts You want to quickly produce "something" that can be used to confirm or infirm Your expectations on what are the needs Your product will fulfill and what is the strength of those needs (Your potential market). You want to do it as fast as possible and as cheap as possible. And You are prepared to throw it all away and start from scratch as soon as You have proved Your theories and have real data to work from.
On the other hand, in professional software systems, that is, systems intended to be intensively used by professionals performing their profession You may use this approach in very small and self-contained domains, to test a new idea to a specific challenge, to evaluate adhesion from the users and other experimental endeavors. But, if You are addressing a full system, don't be naive, You will not, nowadays, be building a first generation system, You will be building a sixth or seventh generation system upon which there should be decades of knowledge, lessons learnt and evolution, in one word, experience. You will be, much more, integrating proved solutions than inventing radically new ones, Your best contribution will be in discovering and incrementally improve the existent not on devising a completely new solution out of thin air. In this context, analysis, structured analysis, is essential.
!!BDUF (Big Design Up Front) fallacy
Of course that nobody (minimally intelligent) ever thought of specifying a software system to the ultimate detail (except in critical scenarios where failure is not acceptable). The analogy is to produce a map at 1:1 scale ([[Jorge Luís Borges tale|https://en.wikipedia.org/wiki/On_Exactitude_in_Science]] comes to mind).
Of course, also, that nobody wants to produce tons of documents with information scattered among them and painfully (and ineffectively) tied together with document hierarchies and manually constructed Excel traceability matrices. Also it is clear to everybody (with minimum experience) that specification is not a "one-shot" endeavor but a continuous task along entire project (and even after it) as [[Rational Unified Process (RUP)|https://en.wikipedia.org/wiki/Rational_Unified_Process]] taught us many years ago.
To advocate that line of business systems do not need a structured specification is just foolish, to say that structured specification can not be done without spending prohibitive effort and time is ignorant and reveals a very obsolete view of it.
On the first point it is nowadays clear that many "Agile built" information systems of the last half dozen years reached their unmaintainable state and can no longer be evolved, but, worst, the knowledge that built them was not persisted and maintained and fade away (and no, reverse engineering of the code is not an answer as it will only, in the best case, give You knowledge of one of the possible solutions and tell You nothing about the problem to solve).
Their owners face the "start from scratch" dilemma and, usually, incur in a fatal mistake : they start defining a full line of business system with "User Stories" (and, worst, Jira tickets). These "User Stories" are unstructured, out of context, incomplete, redundant, unmanageable, untraceable and ambiguous, they are also, and thus, not fully validateable by its stakeholders. And, as unmanageable, they also tend to be a "never ending story"...
On the second point, the effort and time required for structured analysis, the fact is that it has already been done in projects that previously failed, miserably, using the Agile approach, and done, roughly, in half the time they previously took to produce mainly garbage and confusion (and it is my belief that the Agile "products" produced, in fact, doubled the Structured Analysis necessary effort...).
Of course that, if You want to do anything on Software Engineering, You need to study to know how to do it and You need to take advantage of every tool (CASE tools for instance) and method (model centric specification for instance) at Your disposal to be successful (effective and efficient). Of course, also, that naive "we see as we go" and "I'll figure that out alone" approaches are doomed to failure, Software Engineering deals with lots of Essential Complexity <<BibRef "Brooks 1986">> after all.
!After Agile
It is my belief that we are entering an "after Agile" era. Not only its most respected authors start condemning the abuses made to it, but reality is starting to show the medium-term (and, sometimes, short-term) costs it implies. And is showing it in an undeniable and powerful way!
Notice that I'm not saying that Agile principles are wrong, they are not!
I'm just acknowledging that, as an Engineering Methodology, Agile does not fulfill the main goals as it does nothing to prevent, and even creates conditions to promote, practitioners to produce inferior, simplistic results, instead of framing their behavior in a continuous improvement path. On another perspective, and against Agile principles, Agile, as it is practiced nowadays, blindly impedes the practitioners from using proved, seasoned and proper techniques and tools to successfully (effectively and efficiently) tackle the challenges of a software project.
Many will say that Agile well done has not these problems. And they will be right!
But the fact is that methodologies are not made, nor they are that useful, for exceptional practitioners, they are for common, average practitioners and are intended to improve our performance and help us achieve better results.
A methodology that is (ab)used as justification for a "//burn the books//" and "//everything before us is wrong//" kind of attitude is damaging and should be abandoned as soon as possible (we will revisit it in a decade or two, don't worry...).
----
<<TiddlerToC min-entries:1>>
/%
@@color:#c4d6ed; ^^
Description: A discussion on Agile methodologies
^^@@
%/
Aside from well know challenges in Software Development, Software Engineering faces, nowadays, a very important challenge from the attitude many young, and not so young, practitioners have towards knowledge and methodologies.
Nobody doubts that Software Engineering needs methods to address the <<quote 'complex problems' 'Frederick P. Brooks on Complexity'>> it faces. During much of its history this was understood as a laborious and permanent effort of knowing and acquiring experience with as much methodologies as possible and then carefully distil the most effective and efficient practices of each one to assemble into a personal method where one could be as effective and efficient as possible. The notion that there were <<quote '"no silver bullets"' 'No Silver Bullet'>> was common and the patience to slowly and laboriously progress up to excellence was understood and accepted. Those who had done that path were regarded as having "experience".
Nowadays it seems that many practitioners expect to find a simple and complete recipe to develop software. There is no such thing! If you are not willing to traverse the hard path to acquire "experience" You will never be much more than a coder and, in the worst case, a code typist. There is nothing wrong with that but just don't expect to be able to handle any real professional software development project, You will do as told in small, self-contained, tasks defined by someone else. Recent methodologies are presented, or at least largely perceived, as "one size fits all" <<quote '"silver bullets"' 'No Silver Bullet'>> that "can also" be used in anything and any context. Ahh! And they are simple too... if they are not any aspiring practitioner, and even some seasoned ones, just drop them as <<quote '"too complex"' 'Henry L. Mencken on simplicity'>>. And, to my astonishment, this is regarded as "normal". Proficiency without effort, excellence without study, total ignorance of the scientific knowledge of the area.
!!Art and Engineering
[[The Art of Computer Programming|https://en.wikipedia.org/wiki/The_Art_of_Computer_Programming]] - Donald Knuth, 1968
[[The Art, Science, and Engineering of Software Development|https://stevemcconnell.com/articles/the-art-science-and-engineering-of-software-development/]] - Steve ~McConnell, 1998
... TODO: ...
----
/%
@@color:#c4d6ed; ^^
Description: A broad discussion on some methodological trends nowadays.
^^@@
%/
/***
|''Name:'' |ThostUploadPlugin |
|''Description:'' |Support saving to Tiddlyhost.com |
|''Version:'' |1.0.0 |
|''Date:'' |March 06, 2021 |
|''Source:'' |https://github.com/simonbaird/tiddlyhost/tree/main/rails/tw_content/plugins |
|''Author:'' |BidiX, Simon Baird |
|''License:'' |BSD open source license |
|''~CoreVersion:'' |2.9.2 |
***/
//{{{
version.extensions.ThostUploadPlugin = {
major: 1, minor: 0, revision: 0,
date: new Date("Mar 06, 2021"),
source: 'https://github.com/simonbaird/tiddlyhost/rails/tw_content/plugins',
author: 'BidiX, Simon Baird',
coreVersion: '2.9.2'
};
//
// Environment
//
if (!window.bidix) window.bidix = {};
bidix.debugMode = false;
//
// Upload Macro
//
config.macros.thostUpload = {
handler: function(place,macroName,params) {
createTiddlyButton(place, "save to tiddlyhost",
"save this TiddlyWiki to a site on Tiddlyhost.com",
this.action, null, null, this.accessKey);
},
action: function(params) {
var siteName = config.options.txtThostSiteName.trim();
if (!siteName) {
alert("Tiddlyhost site name is missing!");
clearMessage();
}
else {
bidix.thostUpload.uploadChanges('https://' + siteName + '.tiddlyhost.com');
}
return false;
}
};
//
// Upload functions
//
if (!bidix.thostUpload) bidix.thostUpload = {};
if (!bidix.thostUpload.messages) bidix.thostUpload.messages = {
invalidFileError: "The original file '%0' does not appear to be a valid TiddlyWiki",
mainSaved: "Main TiddlyWiki file uploaded",
mainFailed: "Failed to upload main TiddlyWiki file. Your changes have not been saved",
loadOriginalHttpPostError: "Can't get original file",
aboutToSaveOnHttpPost: 'About to upload on %0 ...',
storePhpNotFound: "The store script '%0' was not found."
};
bidix.thostUpload.uploadChanges = function(storeUrl) {
var callback = function(status, uploadParams, original, url, xhr) {
if (!status) {
displayMessage(bidix.thostUpload.messages.loadOriginalHttpPostError);
return;
}
if (bidix.debugMode) {
alert(original.substr(0,500)+"\n...");
}
var posDiv = locateStoreArea(original);
if ((posDiv[0] == -1) || (posDiv[1] == -1)) {
alert(config.messages.invalidFileError.format([localPath]));
return;
}
bidix.thostUpload.uploadMain(uploadParams, original, posDiv);
};
clearMessage();
// get original
var uploadParams = [storeUrl];
var originalPath = document.location.toString();
var dest = 'index.html';
displayMessage(bidix.thostUpload.messages.aboutToSaveOnHttpPost.format([dest]));
if (bidix.debugMode) {
alert("about to execute Http - GET on "+originalPath);
}
var r = doHttp("GET", originalPath, null, null, null, null, callback, uploadParams, null);
if (typeof r == "string") {
displayMessage(r);
}
return r;
};
bidix.thostUpload.uploadMain = function(uploadParams, original, posDiv) {
var callback = function(status, params, responseText, url, xhr) {
if (status) {
displayMessage(bidix.thostUpload.messages.mainSaved);
store.setDirty(false);
}
else {
alert(bidix.thostUpload.messages.mainFailed);
displayMessage(bidix.thostUpload.messages.mainFailed);
}
};
var revised = bidix.thostUpload.updateOriginal(original, posDiv);
bidix.thostUpload.httpUpload(uploadParams, revised, callback, uploadParams);
};
bidix.thostUpload.httpUpload = function(uploadParams, data, callback, params) {
var localCallback = function(status, params, responseText, url, xhr) {
if (xhr.status == 404) {
alert(bidix.thostUpload.messages.storePhpNotFound.format([url]));
}
var saveNotOk = responseText.charAt(0) != '0';
if (bidix.debugMode || saveNotOk) {
alert(responseText);
}
if (saveNotOk) {
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=x" +
";user=x" +
";password=x" +
";uploaddir=x";
if (bidix.debugMode) {
sheader += ";debug=1";
}
sheader += ";;\r\n";
sheader += "\r\n" + "--" + boundary + "\r\n";
sheader += "Content-disposition: form-data; name=\"userfile\"; filename=\"index.html\"\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 = "";
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, 'x','x', localCallback, params, null);
if (typeof r == "string") {
displayMessage(r);
}
return r;
};
// same as Saving's updateOriginal but without convertUnicodeToUTF8 calls
bidix.thostUpload.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;
};
//
// Site config
//
bidix.initOption = function(name,value) {
if (!config.options[name]) {
config.options[name] = value;
}
};
merge(config.optionsDesc, {
txtThostSiteName: "Site name for uploads to Tiddlyhost.com",
});
bidix.initOption('txtThostSiteName','acarvalho');
//
// Tiddlyhost stuff
//
// So you can see edit controls via http
config.options.chkHttpReadOnly = false;
window.readOnly = false;
window.showBackstage = true;
// Add 'upload to tiddlyhost' button
with (config.shadowTiddlers) {
SideBarOptions = SideBarOptions.replace(/(<<saveChanges>>)/,"$1<<thostUpload>>");
}
//}}}
/***
|Name|TiddlerToCPlugin|
|Description|Tiddler Table of Contents generator|
|Author|Julien Coloos|
|Version|1.1.0|
|Date|2011-06-12|
|Status|stable|
|Source|http://julien.coloos.free.fr/TiddlyWiki-dev/#TiddlerToCPlugin|
|License|[img[CC BY-SA 3.0|http://i.creativecommons.org/l/by-sa/3.0/80x15.png][http://creativecommons.org/licenses/by-sa/3.0/]]|
|CoreVersion|2.6|
|Documentation|http://julien.coloos.free.fr/TiddlyWiki-dev/#TiddlerToCPlugin|
{{tw_ttoc{}}}
!Description
This plugin adds the {{{TiddlerToC}}} macro to generate a ~ToC inside a tiddler.
The generated ~ToC entries list the visible headings found in the tidder, each entry being preceded by a number representing its level and index (e.g.: //1.2.1//). Those numbers link to the corresponding heading.
Found headings are also altered to display a link back to the ~ToC.
The ~ToC does not reference tiddlers embedded using the {{{tiddler}}}, {{{slider}}} or {{{tabs}}} macro.
The ~ToC is either generated at a given target, or at the beginning of the place it was dropped in. If there are less headings than a given minimum (default being 2), the ~ToC is not displayed.
The ~ToC title can be clicked to hide/display the ~ToC content.
!Notes
The {{{TiddlerToC}}} macro searches for the HTML headings ({{{h1}}} to {{{h6}}} tags) in the place where it is inserted. Each heading is then converted to a ~ToC entry, preserving inner text format.
The macro thus has to be inserted at the end of the tiddler: content has been generated and the ~ToC can be populated.
!Usage
The {{{TiddlerToC}}} macro is intended to be inserted at the end of a tiddler.
By default the ~ToC is generated at the beginning of the place the macro was inserted in.
However a target can be used: if the place contains an element which class is {{{tw_ttoc}}}, this element will be replaced by the ~ToC.
Such an element can be generated by dropping one of the following inside the tiddler:
* using a ~TiddlyWiki macro
{{{
{{tw_ttoc{}}}
}}}
* inserting an explicit HTML tag; the advantage here is that attributes can be specified
{{{
<html><div class="tw_ttoc" min-entries="3"/></html>
}}}
The macro and/or target element can also be used in [[ViewTemplate]] to be applied to all tiddlers:
{{{
...
<!-- Wikified tiddler content -->
<div class='viewer' macro='view text wikified'>
<!-- Insert ToC right before tiddler content -->
<div class='tw_ttoc'></div>
</div>
<!-- ToC generator, to use at the end of the tiddler -->
<div macro='TiddlerToC min-entries:3'></div>
}}}
!!Parameters
The following parameters are available:
* {{{min-entries}}} (optional)
** minimum number of entries needed to display the ~ToC
** can be specified as macro parameter, and can be overridden in the target tag (needs explicit HTML tag; see before)
** default value is {{{2}}}
!!Examples
Without target:
{{{
Tiddler content.
...
<<TiddlerToC min-entries:3>>
}}}
With a target:
{{{
Beginning of the tiddler.
...
Where to generate the ToC:
{{tw_ttoc{}}}
Or, with a minimum number of entries specified:
<html><div class="tw_ttoc" min-entries="3"/></html>
Tiddler continues ...
<<TiddlerToC min-entries:3>>
}}}
!Styling
~ToC content uses some classes which style can be overriden using CSS. Those classes are:
* {{{tw_ttoc}}}: ~ToC
* {{{tw_ttoc_title}}}: title ({{{Table of Contents}}})
* {{{tw_ttoc_level}}}: sub-level entry indentation
* {{{tw_ttoc_entry}}}: entry
* {{{tw_ttoc_id}}}: entry number
* {{{tw_ttoc_top}}}: heading link back to the ~ToC
Default style can be found in the code below, and can be overridden in the [[StyleSheet]] tiddler.
!Revision History
!!v1.1.0 (2011-06-12)
Changes:
* by default, ~ToC is now displayed only if it contains more than one entry
Enhancements:
* added a macro parameter to give the minimum number of entries needed to display the ~ToC
** the parameter can be overridden in the ~ToC target
Fixes:
* do not list headings that are not //displayed//
!!v1.0.1 (2011-05-29)
Changes:
* if there is none, adds a {{{br}}} tag after the ~ToC
!!v1.0.0 (2011-05-28)
Initial release.
!Code
***/
//{{{
if (!config.macros.TiddlerToC) {(function($) {
version.extensions.TiddlerToCPlugin = {major: 1, minor: 1, revision: 0, date: new Date(2011, 6, 12)};
var hTag = /^h([1-6])$/i;
setStylesheet(".tw_ttoc {background-color: #F8F8F8; padding: 10px; border: 1px #CCCCCC solid;} .tw_ttoc_title {text-align:center; font-weight: bold; margin: 5px 0px 20px 0px;} .tw_ttoc_level {padding-left: 20px;} .tw_ttoc_id {margin-right: 6px;} .tw_ttoc_top {float: right; font-size: 0.5em;}", "TiddlerToCPlugin");
function cloneNodeWithEvents(node) {
var clone = node.cloneNode(true);
var n1 = [node].concat(Array.prototype.slice.call(node.getElementsByTagName('*')));
var n2 = [clone].concat(Array.prototype.slice.call(clone.getElementsByTagName('*')));
for (var i=0 ; i<n1.length ; i++) {
for (var j in n1[i]) {
if (j.substr(0,2) != "on") continue;
n2[i][j] = n1[i][j];
}
}
return clone;
}
var pl = config.macros.TiddlerToC = {
handler: function(place, macroName, params, wikifier, paramString, tiddler) {
var namedParams = paramString.parseParams(null, null, true), paramMinEntries = getParam(namedParams, "min-entries"), minEntries = paramMinEntries ? parseInt(paramMinEntries) : 2;
if ($(place).hasClass("viewer") || $(place).parents(".viewer").size()) pl.generate(place, minEntries);
else {
/* the macro is not used inside a tiddler content but probably in a template */
var t = story.findContainingTiddler(place);
if (!t) return;
pl.generate(t, minEntries);
}
},
getElements: function(place) {
var els = $();
$(place).children().each(function(i, n) {
/* exclude embedded tiddlers */
if ($(n).attr("tiddler") || $(n).hasClass("sliderPanel") || $(n).hasClass("tabsetWrapper")) return;
/* include headings and ToC target */
if (hTag.test(n.tagName) || $(n).is(".tw_ttoc")) els = els.add(n);
/* recurse */
els = els.add(pl.getElements(n));
});
return els;
},
generate: function(place, minEntries) {
var els = pl.getElements(place);
/* get ToC target, or insert it as first element */
var toc = els.filter(".tw_ttoc");
if (toc.size()) {
if (toc.size() > 1) {
/* More than one target; happens when using ViewTemplate while
* tiddler already contains a ToC target. In any case, it is best
* to keep the last one and remove others.
*/
toc.not(toc.last()).remove();
toc = toc.last();
}
/* check the ToC was not already generated */
if (toc[0].toc && toc[0].toc.generated) return;
/* check if the minimum number of entries is overridden */
if (toc.attr("min-entries")) minEntries = parseInt(toc.attr("min-entries"));
/* rebuild target tag */
toc = toc.empty().wrapInner("<div class='tw_ttoc'/>").children("div").unwrap();
}
else toc = $("<div class='tw_ttoc'/>").prependTo(place);
var hLevelCurrent = 0, hLevel;
var tocInner = $("<div/>"), listCurrent = tocInner[0], listId = "1";
toc.hide().append($("<div class='tw_ttoc_title'><a href='javascript:;'>Table of Contents</a></div>"), tocInner);
$(".tw_ttoc_title a", toc).click(function() {
if (tocInner.is(":visible")) tocInner.hide("fast");
else tocInner.show("fast");
});
var headings = $();
els.each(function(i, c) {
/* check we got a visible heading */
var match = hTag.exec(c.tagName);
if (!match || !$(c).is(":visible")) return;
hLevel = parseInt(match[1]);
/* check the heading level */
if (!hLevelCurrent) hLevelCurrent = hLevel;
if (hLevel < hLevelCurrent) {
/* have to go up */
while ((hLevel <= --hLevelCurrent) && listCurrent.parentNode) {
listCurrent = listCurrent.parentNode.parentNode;
ids = listId.split(".");
ids.pop();
listId = ids.join(".");
}
}
else if (hLevel > hLevelCurrent) {
/* have to go down */
while (hLevel >= ++hLevelCurrent) {
$(listCurrent.lastChild).append(listCurrent = $("<div class='tw_ttoc_level'/>")[0]);
ids = listId.split(".");
ids.push(1);
listId = ids.join(".");
}
}
/* determine this heading index */
ids = listId.split(".");
ids[ids.length-1] = $(listCurrent).children("div.tw_ttoc_entry").size() + 1;
listId = ids.join(".");
/* clone the heading content to insert it in the ToC */
$(cloneNodeWithEvents(c)).wrapInner("<div class='tw_ttoc_entry'/>").children("div").unwrap().prepend($("<a class='tw_ttoc_id' href='javascript:;'/>").html(listId).click({target: c}, function(ev){window.scrollTo(0,findPosY(ev.data.target))})).appendTo(listCurrent);
headings = headings.add(c);
hLevelCurrent = hLevel;
});
toc[0].toc = {generated: true};
if (headings.size() >= minEntries) {
/* display ToC */
/* Note: jQuery 'next' does not take into account text nodes */
var sibling = toc.show()[0].nextSibling;
if (sibling && (sibling.nodeName != "BR")) toc.after("<br/>");
/* insert a 'ToC' link in the headings */
headings.append($("<span class='tw_ttoc_top'><a href='javascript:;' title='Go to Table of Contents'>[ToC]</a></span>")).find(".tw_ttoc_top a").click(function() {window.scrollTo(0,findPosY(toc[0]))});
}
}
};
})(jQuery);}
//}}}
/***
<<TiddlerToC>>
***/
/***
|''Name:''|TiddlersBarPluginMP|
|''Description:''|A bar to switch between tiddlers through tabs (like browser tabs bar).|
|''Version:''|1.2.5|
|''Date:''|Jan 18,2008|
|''Source:''|http://visualtw.ouvaton.org/VisualTW.html|
|''Author:''|Pascal Collin|
|''License:''|[[BSD open source license|License]]|
|''~CoreVersion:''|2.1.0|
|''Browser:''|Firefox 2.0; InternetExplorer 6.0, others|
!Attention
This plugin contains some changings, at the end of the plugin marked with !!MP!!
!Demos
On [[homepage|http://visualtw.ouvaton.org/VisualTW.html]], open several tiddlers to use the tabs bar.
!Installation
#import this tiddler from [[homepage|http://visualtw.ouvaton.org/VisualTW.html]] (tagged as systemConfig)
#save and reload
#''if you're using a custom [[PageTemplate]]'', add {{{<div id='tiddlersBar' refresh='none' ondblclick='config.macros.tiddlersBar.onTiddlersBarAction(event)'></div>}}} before {{{<div id='tiddlerDisplay'></div>}}}
#optionally, adjust StyleSheetTiddlersBar
!Tips
*Doubleclick on the tiddlers bar (where there is no tab) create a new tiddler.
*Tabs include a button to close {{{x}}} or save {{{!}}} their tiddler.
*By default, click on the current tab close all others tiddlers.
!Configuration options
<<option chkDisableTabsBar>> Disable the tabs bar (to print, by example).
<<option chkHideTabsBarWhenSingleTab >> Automatically hide the tabs bar when only one tiddler is displayed.
<<option txtSelectedTiddlerTabButton>> ''selected'' tab command button.
<<option txtPreviousTabKey>> previous tab access key.
<<option txtNextTabKey>> next tab access key.
!Code
***/
//{{{
config.options.chkEnableTabsBar = config.options.chkEnableTabsBar ? config.options.chkEnableTabsBar : true;
config.options.chkHideTabsBarWhenSingleTab = config.options.chkHideTabsBarWhenSingleTab ? config.options.chkHideTabsBarWhenSingleTab : true;
config.options.txtSelectedTiddlerTabButton = config.options.txtSelectedTiddlerTabButton ? config.options.txtSelectedTiddlerTabButton : "closeOthers";
config.options.txtPreviousTabKey = config.options.txtPreviousTabKey ? config.options.txtPreviousTabKey : "";
config.options.txtNextTabKey = config.options.txtNextTabKey ? config.options.txtNextTabKey : "";
config.macros.tiddlersBar = {
tooltip : "see ",
tooltipClose : "click here to close this tab",
tooltipSave : "click here to save this tab",
promptRename : "Enter tiddler new name",
currentTiddler : "",
previousState : false,
previousKey : config.options.txtPreviousTabKey,
nextKey : config.options.txtNextTabKey,
tabsAnimationSource : null, //use document.getElementById("tiddlerDisplay") if you need animation on tab switching.
handler: function(place,macroName,params) {
var previous = null;
if (config.macros.tiddlersBar.isShown())
story.forEachTiddler(function(title,e){
if (title==config.macros.tiddlersBar.currentTiddler){
var d = createTiddlyElement(null,"span",null,"tab tabSelected");
config.macros.tiddlersBar.createActiveTabButton(d,title);
if (previous && config.macros.tiddlersBar.previousKey) previous.setAttribute("accessKey",config.macros.tiddlersBar.nextKey);
previous = "active";
}
else {
var d = createTiddlyElement(place,"span",null,"tab tabUnselected");
var btn = createTiddlyButton(d,title,config.macros.tiddlersBar.tooltip + title,config.macros.tiddlersBar.onSelectTab);
btn.setAttribute("tiddler", title);
if (previous=="active" && config.macros.tiddlersBar.nextKey) btn.setAttribute("accessKey",config.macros.tiddlersBar.previousKey);
previous=btn;
}
var isDirty =story.isDirty(title);
var c = createTiddlyButton(d,isDirty ?"!":"x",isDirty?config.macros.tiddlersBar.tooltipSave:config.macros.tiddlersBar.tooltipClose, isDirty ? config.macros.tiddlersBar.onTabSave : config.macros.tiddlersBar.onTabClose,"tabButton");
c.setAttribute("tiddler", title);
if (place.childNodes) {
place.insertBefore(document.createTextNode(" "),place.firstChild); // to allow break line here when many tiddlers are open
place.insertBefore(d,place.firstChild);
}
else place.appendChild(d);
})
},
refresh: function(place,params){
removeChildren(place);
config.macros.tiddlersBar.handler(place,"tiddlersBar",params);
if (config.macros.tiddlersBar.previousState!=config.macros.tiddlersBar.isShown()) {
story.refreshAllTiddlers();
if (config.macros.tiddlersBar.previousState) story.forEachTiddler(function(t,e){e.style.display="";});
config.macros.tiddlersBar.previousState = !config.macros.tiddlersBar.previousState;
}
},
isShown : function(){
if (! config.options.chkEnableTabsBar) return false;
if (!config.options.chkHideTabsBarWhenSingleTab) return true;
var cpt=0;
story.forEachTiddler(function(){cpt++});
return (cpt>1);
},
selectNextTab : function(){ //used when the current tab is closed (to select another tab)
var previous="";
story.forEachTiddler(function(title){
if (!config.macros.tiddlersBar.currentTiddler) {
story.displayTiddler(null,title);
return;
}
if (title==config.macros.tiddlersBar.currentTiddler) {
if (previous) {
story.displayTiddler(null,previous);
return;
}
else config.macros.tiddlersBar.currentTiddler=""; // so next tab will be selected
}
else previous=title;
});
},
onSelectTab : function(e){
var t = this.getAttribute("tiddler");
if (t) story.displayTiddler(null,t);
return false;
},
onTabClose : function(e){
var t = this.getAttribute("tiddler");
if (t) {
if(story.hasChanges(t) && !readOnly) {
if(!confirm(config.commands.cancelTiddler.warning.format([t])))
return false;
}
story.closeTiddler(t);
}
return false;
},
onTabSave : function(e) {
var t = this.getAttribute("tiddler");
if (!e) e=window.event;
if (t) config.commands.saveTiddler.handler(e,null,t);
return false;
},
onSelectedTabButtonClick : function(event,src,title) {
var t = this.getAttribute("tiddler");
if (!event) event=window.event;
if (t && config.options.txtSelectedTiddlerTabButton && config.commands[config.options.txtSelectedTiddlerTabButton])
config.commands[config.options.txtSelectedTiddlerTabButton].handler(event, src, t);
return false;
},
onTiddlersBarAction: function(event) {
var source = event.target ? event.target.id : event.srcElement.id; // FF uses target and IE uses srcElement;
if (source=="tiddlersBar") story.displayTiddler(null,'New Tiddler',DEFAULT_EDIT_TEMPLATE,false,null,null);
},
createActiveTabButton : function(place,title) {
if (config.options.txtSelectedTiddlerTabButton && config.commands[config.options.txtSelectedTiddlerTabButton]) {
var btn = createTiddlyButton(place, title, config.commands[config.options.txtSelectedTiddlerTabButton].tooltip ,config.macros.tiddlersBar.onSelectedTabButtonClick);
btn.setAttribute("tiddler", title);
}
else
createTiddlyText(place,title);
}
}
story.coreCloseTiddler = story.coreCloseTiddler? story.coreCloseTiddler : story.closeTiddler;
story.coreDisplayTiddler = story.coreDisplayTiddler ? story.coreDisplayTiddler : story.displayTiddler;
story.closeTiddler = function(title,animate,unused) {
if (title==config.macros.tiddlersBar.currentTiddler)
config.macros.tiddlersBar.selectNextTab();
story.coreCloseTiddler(title,false,unused); //disable animation to get it closed before calling tiddlersBar.refresh
var e=document.getElementById("tiddlersBar");
if (e) config.macros.tiddlersBar.refresh(e,null);
}
story.displayTiddler = function(srcElement,tiddler,template,animate,unused,customFields,toggle){
story.coreDisplayTiddler(config.macros.tiddlersBar.tabsAnimationSource,tiddler,template,animate,unused,customFields,toggle);
var title = (tiddler instanceof Tiddler)? tiddler.title : tiddler;
if (config.macros.tiddlersBar.isShown()) {
story.forEachTiddler(function(t,e){
if (t!=title) e.style.display="none";
else e.style.display="";
})
config.macros.tiddlersBar.currentTiddler=title;
}
var e=document.getElementById("tiddlersBar");
if (e) config.macros.tiddlersBar.refresh(e,null);
}
var coreRefreshPageTemplate = coreRefreshPageTemplate ? coreRefreshPageTemplate : refreshPageTemplate;
refreshPageTemplate = function(title) {
coreRefreshPageTemplate(title);
/*-- new --*/
var e = document.getElementById("tiddlersBar");
if (config.macros.tiddlersBar && e) config.macros.tiddlersBar.refresh(e);
// !!MP!! old prevents a theme, which has no div id=tiddlersBar from loading.
//old if (config.macros.tiddlersBar && e) config.macros.tiddlersBar.refresh(document.getElementById("tiddlersBar"));
}
// !!MP!! removed this line because it causes a scroll to top if a popup opens.
// ensureVisible=function (e) {return 0}
config.shadowTiddlers.StyleSheetTiddlersBar = "/*{{{*/\n";
config.shadowTiddlers.StyleSheetTiddlersBar += "#tiddlersBar .button {border:0}\n";
config.shadowTiddlers.StyleSheetTiddlersBar += "#tiddlersBar .tab {white-space:nowrap}\n";
config.shadowTiddlers.StyleSheetTiddlersBar += "#tiddlersBar {padding : 1em 0.5em 2px 0.5em}\n";
config.shadowTiddlers.StyleSheetTiddlersBar += ".tabUnselected .tabButton, .tabSelected .tabButton {padding : 0 2px 0 2px; margin: 0 0 0 4px;}\n";
config.shadowTiddlers.StyleSheetTiddlersBar += ".tiddler, .tabContents {border:1px [[ColorPalette::TertiaryPale]] solid;}\n";
config.shadowTiddlers.StyleSheetTiddlersBar +="/*}}}*/";
store.addNotification("StyleSheetTiddlersBar", refreshStyles);
config.refreshers.none = function(){return true;}
config.shadowTiddlers.PageTemplate=config.shadowTiddlers.PageTemplate.replace(/<div id='tiddlerDisplay'><\/div>/m,"<div id='tiddlersBar' refresh='none' ondblclick='config.macros.tiddlersBar.onTiddlersBarAction(event)'></div>\n<div id='tiddlerDisplay'></div>");
//}}}
This tiddler list modifications made on migrating from TiddlySpot to TiddlyHost
!Macros:
<<thostUpload>> for saving to TiddlyHost
!Plugins
*UnsavedChangesPlugin not working, does not detect save to tiddlyhost
*TspotSetupPlugin disabled as no longer used
!Shadows
-----
SideBarOptions
Removed :
<<saveChanges>><<tiddler TspotSidebar>>
----
HoverMenu
Replaced:
<<saveChanges>> with <<thostUpload>>
----
OptionsPanel
Removed:
<<tiddler TspotOptions>>These [[InterfaceOptions]] for customising [[TiddlyWiki]] are saved in your browser
----
UploadLog
is pointing to tiddlyspot
----
/%
@@color:#c4d6ed; ^^
Description: TiddlyHost customizations
^^@@
%/
* Saving to web
** AdvancedOptions txtUploadStoreUrl shall not be the default (Url of the UploadService script (default: store.php)) but instead ''store.cgi''
** Upload password : copy/paste does not work, you must at least delete and enter by keyboard the last letter
TODO: convert from TiddlySpace to TiddlySpot
----
/%
@@color:#c4d6ed; ^^
Description: TODO
^^@@
%/
!!Sites
* [[Projectify|https://projectify.wiki/]] - Projectify brings project management to TiddlyWiki, interlinking task and knowledge management in one place.
!!Guides
* [[TiddlyWiki Guides|http://tiddlywikiguides.org/index.php?title=TiddlyWiki_Guides]] - This is one of two collaborative documentation projects for TiddlyWiki.
!!How To
!!! Formating images
* [[TWHelp|http://twhelp.tiddlyspot.com/#FormattingImages]]
!!Macros
|Type|Name|Code|Description|h
|Information|Version|{{{<<version>>}}}|Displays ~TiddlyWiki version|
|Information|Timeline|{{{<<timeline (created|modified) 5>>}}}|Displays last X tiddlers created or modified|
!!Creating macros
* BibRefMacro
!!Plugins
|Version|Name|Description|h
|Classic|||
|~|[[SlideShowPlugin|http://www.math.ist.utl.pt/~psoares/addons.html#SlideShowPlugin]]|Creates a slide show from any number of tiddlers.|
|~|[[LinkifyPlugin|http://linkify.tiddlyspot.com/#LinkifyPlugin]]|Automatically turns text into links, optionally using aliases.|
|TW 5|[[Projectify|https://projectify.wiki]]|Projectify is a project management app for TiddlyWiki, inspired by products like Todoist and Basecamp.|
|~|[[Relink|https://github.com/flibbles/tw5-relink]]|It expands on TW5's bulk updating to allow for any customizable fields to be updated, whether they're lists, filters, macros, or single-tiddler fields. In addition, relink parses through the text of all relevant tiddlers and updates prettyLinks, transclusions, widgets, and other syntax patterns to properly reflect the title change.|
----
See also [[TiddlyWiki Wish List|TiddlyWiki WishList]]
----
/%
@@color:#c4d6ed; ^^
Description: TiddlyWiki related issues.
^^@@
%/
"//''My final point (my loss of faith that “the customer is king”) is not just a change in my own thinking, but a sign of the maturing of IT in specific and of the business climate in general. In 1975, the typical commercial system we built was a first time automation of what had before been done manually. The customer, of course, was the only one who knew what this was all about and his/her sense of what the automated version would have to do was prime.
Today we are building third and fourth generation automated systems, and IT personnel are often as well or better informed about how the existing system works as their business partners. More important, the meaningful successes of IT today are no longer to be achieved by simple automation or re-automation of existing process. We have moved on to a new era: Our challenge today is to combine improved information technology and market opportunity in order to create product that is radically different from what could have been achieved in a less connected world. This tells us that the new king is neither client nor technologist, but their partnership: the tightly merged amalgam of business and technological expertise. Companies that achieve and maintain such a partnership are the ones who will prosper.''//"
[[Structured Analysis: Beginnings of a New Discipline|http://cs.txstate.edu/~rp31/papersSP/TDMSpringer2002.pdf]]
[[Tom DeMarco|http://en.wikipedia.org/wiki/Tom_DeMarco]]
sd&m Conference 2001, Software Pioneers
Eds.: M. Broy, E. Denert, Springer 2002
----
/%
@@color:#c4d6ed; ^^
Description: Quote of Tom DeMarco opinion on modern Software Analyst role
^^@@
%/
|~ViewToolbar|+editTiddler cloneTiddler closeOthers closeTiddler > fields refreshTiddler changeToPublic changeToPrivate syncing permalink references jump previousTiddler < |
|~EditToolbar|+saveTiddler saveDraft -cancelTiddler deleteTiddler|
|~RevisionToolbar|> fields revert|
Traceability is the ability to trace (forwards and backwards) a modelling element from its conception through its specification to its subsequent design, implementation and test.
<<Image "FR" "413" "Traceability-Concretisation.png" "https://dl.dropbox.com/" "s/5dmf76e8aankguz/" "?dl=1" "Traceability and Concretisation">>
As a process, software development progresses through phases and, in each phase, a different level of information concretisation (and range) is achieved.
The diagram illustrates the main elements of each phase, their relationships and the concretisation traceability from Inception to Construction, this is, basically, a [[meta-model|http://en.wikipedia.org/wiki/Metamodeling]].
Pay attention that several other diagrams and elements may and shall be used, to detail and improve specification, like business models, use cases, state diagrams, etc. These auxiliary diagrams and elements, however, are not considered in our main traceability proposal.
For now we shall understand that traceability refers to the ability of locating related elements up in abstraction direction or down in concretisation direction or even horizontally as happens with test cases and tables.
As such a ''Requested [[Feature]]'' shall be traced (Abstraction) from one or more dependant ''Proposed Features''. A ''Requested Feature'' shall also be dependant from one or more ''Stakeholders'' (Customer person affected or/and with decision power over the feature).
''[[Requirements|Software Requirement]]'' shall trace (Abstraction) to features and shall also be associated with their correspondent ''Test Cases''. The architectural ''Components'' shall ''realize'' the requirements that, in that way, correspond to their responsibilities.
Composition of the ''Components'' shall be established by aggregation of the correspondent ''Classes'' that, in turn, shall trace their dependency from database ''Tables'' and establish their realizations of ''Interfaces''.
Notice that, although ''Interfaces'' and ''Tables'' appear at Construction level they may, and shall, be specified as soon as possible.
Traceability also implies unequivocal and ''unambiguous identification'' of each item. As Classes are naturally identified by namespace and name and Components and Tables are, usually, only identified by name, this means that you should number your Features, Requirements, Issues, Assumptions, Test Cases, and anything whose name is not unique in the system, in an unequivocal way. We strongly suggest to use hierarchical numbering with gaps and type prefixes. See [[Writing Good Requirements]] for more information on this.
<<Image "FL" "630" "ModelNavigability.png" "https://dl.dropbox.com/" "s/ycu8jb2frb5f3oz/" "?dl=1" "Model Navigability">>
When using a [[CASE]] tool like [[EA|Sparx Enterprise Architect]], traceability relationships are also a condition for ''model navigability''. This is essential if you want a minimum of productivity and efficiency in tool usage.
Proper relationships give us model navigability with simple follow link action.
As you surely understand, ''the ability to locate information in a set as large as Software Specifications tend to be is crucial and can not be underestimated''.
''Model Navigability'' is essential to :
* cope with information volume
* assess change impact and context
* assure [[coverage|Coverage]]
* protect scope
!!Traceability and Agile
Pay attention that most Agile approaches do not properly consider traceability and, when confronted with the need, propose (out of thin air) outdated solutions, very close to "//Excel traceability//", that will make you return to the stone age of software development. These immature and ill thought pseudo-solutions will require a lot of effort and produce near useless and unmaintainable results. This scenario is made worst when task management tools that "can also be used for anything else...", like Jira, are brought to the matter destroying the "single source of truth" characteristic of the model (you are not thinking in modelling in Jira are you?) and, in fact, rendering it almost useless and unmaintainable. You do not code in Notepad, although it would be possible to do so. So why (ab)use tools and use outdated inefficient methods when there are plenty professional [[CASE]] tools and solid methods that can do the job efficiently and effectively?
See, for instance, [[Lightning Cast: Non-Functional Requirements in Agile|https://masteringbusinessanalysis.com/lightning-cast-non-functional-requirements-in-agile/]] :
* the first approach (Backlog Item) destroys state management, and in fact all sprint concept, when a non-functional requirement applies to all or a big part of the system. Or you will need to create a different Backlog Item with the same content for each US in each sprint.
* the second and third approaches translate into non discrete attributes of other elements and, thus, are not traceable in a properly bidirectional and normalized fashion and you will be back into "//Excel traceability//" nightmare.
----
''See also :''
* Additional recommended relationships in Requirements Diagrams : [[EA Usage - Requirements Diagram]]
----
!!Other references on the topic
* Rémy Fannader, on [[Traceability|http://caminao.wordpress.com/system-engineering/project-management/traceability/]]
* Serge Thorn, on [[Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0|http://sergethorn.blogspot.fr/2013/05/redefining-traceability-in-enterprise.html]]
* Geert Bellekens, on [[Instant impact analyses in Enterprise Architect with SQL searches|http://bellekens.com/2015/02/15/instant-impact-analyses-in-enterprise-architect-with-sql-searches/]]
----
@@color:#c4d6ed; ^^
Description: traceability concept explanation and usage guideline.
^^@@
*2012
** [[Mozambique and South Africa|2012 Mozambique and South Africa]]
*2014
** [[Mozambique|2014 Mozambique]]
** [[Brazil|2014 Brazil]]
*2015
** [[Brazil|2015 Brazil]]
*2018
** [[UK|2018 UK]]
** [[Morroco|2018 Morroco]]
*2019
** [[Morroco|2019 Morroco]]
----
@@color:#c4d6ed; ^^
Description: Travels page, photos and other things
^^@@
/***
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 = 'acarvalho';
// 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,{
'TspotOptions':[
"tiddlyspot password:",
"<<option pasUploadPassword>>",
""
].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"),
'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?// @@ 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// @@ 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// @@ 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!// @@ 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 :)// @@ 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"),
'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")
});
//}}}
/***
|Name|UnsavedChangesPlugin|
|Source|http://www.TiddlyTools.com/#UnsavedChangesPlugin|
|Version|3.3.6|
|Author|Eric Shulman|
|License|http://www.TiddlyTools.com/#LegalStatements|
|~CoreVersion|2.1|
|Type|plugin|
|Description|show droplist of tiddlers that have changed since the last time the document was saved|
Display a list of tiddlers that have been changed since the last time the document was saved. The list includes all new/modified tiddlers as well as those changed with "minor edits" enabled and any tiddlers that you import during the session, regardless of their modification date.
!!!!!Usage
<<<
{{{
<<unsavedChanges panel>> or <<unsavedChanges>>
}}}
{{indent{
the ''panel'' keyword displays a 'control panel' interface containing a droplist of unsaved tiddlers and a 'goto' button, along with a command link to 'save changes'. Depending upon what other plugins are installed, several additional elements will also be displayed: When [[NestedSlidersPlugin]] is installed, the entire control panel is contained within a ''SLIDER''. When [[LoadTiddlersPlugin]] is installed, a ''REVERT'' button is added. When [[SaveAsPlugin]] is installed, a ''SAVE AS'' link is added. When [[UploadPlugin]] is installed, an ''UPLOAD'' (or ''save to web'') link is added. When [[TrashPlugin]] is installed and there are tiddlers tagged with<<tag Trash>>, an ''EMPTY TRASH'' link is added.
}}}
{{{
<<unsavedChanges list separator>>
}}}
{{indent{
the ''list'' keyword displays a simple space-separated list of unsaved tiddlers without any other command links. You can specify an optional ''separator'' value that can be used in place of the default space character. For example, you can specify {{{"<br>"}}} as the separator in order to display each link, one per line.
}}}
{{{
<<unsavedChanges command label tip>>
}}}
{{indent{
the ''command'' keyword displays a single 'command link' that, when clicked, displays a ~TiddlyWiki popup containing the list of unsaved tiddlers, the 'save changes' command and, depending upon what other plugins are installed, additional commands for 'save as', 'upload', and 'empty trash' (similar to the panel display described above).
You can specify optional ''label'' and ''tip'' parameters in the macro to customize the command link text and tooltip. The default label for the command link is: "There %1 %0 unsaved tiddler%2...", where:
* %0 is automatically replaced with the number of unsaved changes
* %1 is either "is" (if changes=1) or "are" (if changes>1)
* %2 is either blank (if changes=1) or "s" (if changes>1)
resulting in the text: //"There is 1 unsaved tiddler...", "There are 2 unsaved tiddlers...", etc.//
}}}
<<<
!!!!!Examples
<<<
^^//note: the following examples will not display any output unless you have already created/modified tiddlers in the current document.//^^
{{{<<unsavedChanges>>}}}
<<unsavedChanges>>
----
{{{<<unsavedChanges command>>}}}
<<unsavedChanges command>>
----
{{{<<unsavedChanges list>>}}}
<<unsavedChanges list>>
----
{{{<<unsavedChanges list "<br>">>}}}
<<unsavedChanges list "<br>">>
<<<
!!!!!Revisions
<<<
2011.11.27 3.3.6 in panel(), command(), and list(), check for null 'place' (maybe caused if tiddlers are modified by a plugin during startup 'init' handling)
2011.04.29 3.3.5 in panel(), use custom label (if provided). Also, removed "small" style from panel commands so surrounding CSS font size will be used.
2010.12.05 3.3.4 display 'save as...' command even if readOnly
2009.03.02 3.3.3 fix handling for titles that contain HTML special chars (lt,gt,quot,amp)
2008.09.02 3.3.2 cleanup popup list output generation and added timestamps/sizes to popup display
2008.08.23 3.3.1 added optional custom 'label' and 'tip' params to 'command' mode and defined default values for mode, label, tip, and separator as object properties for I18N/L10N-readiness.
2008.08.21 3.3.0 complete re-write of rendering and refresh processing to support multiple instances and automatic self-refresh (no longer depends upon core refresh notifications)
2008.08.21 3.2.0 added 'command' option for link+popup as alternative to 'control panel' interface
2008.04.22 3.1.2 use SaveAsPlugin instead of obsolete NewDocumentPlugin to add "save as" link
2007.12.22 3.1.1 hijack removeTiddler() instead of low-level deleteTiddler() to correct tracking and refresh handling issues. in saveTiddler(), check for 'tiddler rename' (title!=newtitle) and adjust list accordingly.
2007.12.21 3.1.0 added support for {{{<<unsavedChanges list separator>>}}} usage to unsaved tiddlers as a simple list of links, embedded in tiddler content (e.g., [[MainMenu]])
2007.12.20 3.0.0 rewrite to track ALL changed tiddlers, including imports and minor edits, regardless of saved modification dates. Also, rewrote display logic to directly refresh macro output instead of triggering a page refresh. The entire process is MUCH more efficient now.
2007.08.02 2.0.0 converted from inline script
2007.01.01 1.0.0 initial release
<<<
!!!!!Code
***/
//{{{
version.extensions.UnsavedChangesPlugin= {major: 3, minor: 3, revision: 6, date: new Date(2011,12,27)};
config.macros.unsavedChanges = {
changed: [], // list of currently unsaved tiddler titles
defMode: "panel",
defSep: " ",
defLabel: "There %1 %0 unsaved tiddler%2",
defTip: "view a list of unsaved tiddler changes",
handler: function(place,macroName,params,wikifier,paramString,tiddler) {
var wrapper=createTiddlyElement(place,"span",null,"unsavedChanges");
wrapper.setAttribute("mode",params[0]||this.defMode);
wrapper.setAttribute("sep",params[1]||this.defSep); // for 'list' mode
wrapper.setAttribute("label",params[1]||this.defLabel); // for 'command' mode
wrapper.setAttribute("tip",params[2]||this.defTip); // for 'command' mode
this.render(wrapper);
},
render: function(wrapper) {
removeChildren(wrapper); // make sure its empty
if (!this.changed.length) return; // no changes = no output
switch (wrapper.getAttribute("mode")) {
case "command": this.command(wrapper); break;
case "list": this.list(wrapper); break;
case "panel": default: this.panel(wrapper); break;
}
},
refresh: function() {
var wrappers=document.getElementsByTagName("span");
for (var w=0; w<wrappers.length; w++)
if (hasClass(wrappers[w],"unsavedChanges"))
this.render(wrappers[w]);
},
list: function(place) { // show simple list of unsaved tiddlers
if (!place) return;
wikify("[["+this.changed.join("]]"+place.getAttribute("sep")+"[[")+"]]",place);
},
command: function(place) { // show command link with popup list
if (!place) return;
var c=this.changed.length;
var txt=place.getAttribute("label").format([c,c==1?'is':'are',c==1?'':'s']);
var tip=place.getAttribute("tip");
var action=function(ev) { if (!ev) var ev=window.event;
var p=Popup.create(this); if (!p) return false;
var d=createTiddlyElement(p,"div");
d.style.whiteSpace="normal"; d.style.width="auto"; d.style.padding="2px";
// gather pretty links for changed tiddlers
var list=[]; var item=" [[%1 - %0 (%2 bytes)|%0]] ";
for (var i=config.macros.unsavedChanges.changed.length-1; i>=0; i--) {
var tid=store.getTiddler(config.macros.unsavedChanges.changed[i]);
if (!tid) continue;
var when=tid.modified.formatString('YYYY.0MM.0DD 0hh:0mm:0ss');
list.push(item.format([tid.title,when,tid.text.length]));
}
wikify("@@white-space:nowrap;"+list.join("<br>")+"@@",d);
var t="\n----\n";
t+="@@white-space:nowrap;display:block;text-align:center; ";
if (!readOnly) {
t+="<<saveChanges>>";
t+=config.macros.saveAs?" | <<saveAs>>":"";
t+=config.macros.upload?" | <<upload>>":"";
t+=(config.macros.emptyTrash&&store.getTaggedTiddlers("Trash").length)?" | <<emptyTrash>>":"";
} else {
t+=config.macros.saveAs?"<<saveAs>>":"";
}
t+=" @@";
wikify(t,d);
Popup.show();
ev.cancelBubble=true; if(ev.stopPropagation)ev.stopPropagation();
return(false);
}
createTiddlyButton(place,txt,tip,action,"button");
},
panel: function(place) { // show composite droplist+buttons+commands
if (!place) return;
// gather changed tiddlers (in reverse order by date - most recent first)
var tids=[]; for (var i=this.changed.length-1; i>=0; i--)
{ var t=store.getTiddler(this.changed[i]); if (t) tids.push(t); }
tids.sort(function(a,b){return a.modified<b.modified?-1:(a.modified==b.modified?0:1);});
// generate droplist items
var list=[]; var item='<option value="%0">%1 - %0 (%2 bytes)</option>';
for (var i=tids.length-1; i>=0; i--) {
var when=tids[i].modified.formatString('YYYY.0MM.0DD 0hh:0mm:0ss');
list.push(item.format([tids[i].title.htmlEncode(),when,tids[i].text.length]));
}
// display droplist, buttons, and command links
var out=''; var c=this.changed.length;
var NSP=config.formatters.findByField("name","nestedSliders");
var summary=place.getAttribute("label").format([c,c==1?'is':'are',c==1?'':'s']);
out+=NSP?'+++(unsaved)['+summary+'|'+this.defTip+']...':(summary+"\n");
out+='<html><form style="display:inline"><!--\
--><select size="1" name="list" \
title="select a tiddler to view" \
onchange="var v=this.value; if (v.length) story.displayTiddler(null,v);"><!--\
-->'+list.join('')+'<!--\
--></select><!--\
--><input type="button" value="goto" onclick="this.form.list.onchange();">';
if (config.macros.loadTiddlers) {
out+='<input type="button" value="revert" \
title="import the last saved version of this tiddler" \
onclick="var v=this.form.list.value; if (!v.length) return; \
var t=\'<\'+\'<loadTiddlers [[tiddler:\'+v+\']] \'; \
t+=document.location.href; \
t+=\' confirm force noreport>\'+\'>\'; \
var e=document.getElementById(\'executeRevert\'); \
if (e) e.parentNode.removeChild(e); \
e=document.createElement(\'span\'); \
e.id=\'executeRevert\'; \
wikify(t,e);">';
}
out+='</form></html>';
out+='\n{{nowrap{';
if (!readOnly) {
out+="<<saveChanges>>";
out+=config.macros.saveAs?" | <<saveAs>>":"";
out+=config.macros.upload?" | <<upload>>":"";
out+=(config.macros.emptyTrash&&store.getTaggedTiddlers("Trash").length)?" | <<emptyTrash>>":"";
} else {
out+=config.macros.saveAs?"<<saveAs>>":"";
}
out+='}}}';
out+=NSP?'===':'';
wikify(out,place);
}
};
// hijack store.saveTiddler() to track changes to tiddlers
if (store.showUnsaved_saveTiddler==undefined) {
store.showUnsaved_saveTiddler=store.saveTiddler;
store.saveTiddler=function(title,newtitle) {
if (title!=newtitle) {
var i=config.macros.unsavedChanges.changed.indexOf(title);
if (i!=-1) config.macros.unsavedChanges.changed.splice(i,1); // remove old from list
}
var i=config.macros.unsavedChanges.changed.indexOf(newtitle);
if (i!=-1) config.macros.unsavedChanges.changed.splice(i,1); // remove new title from list
config.macros.unsavedChanges.changed.push(newtitle); // add new title to END of list
var t=this.showUnsaved_saveTiddler.apply(this,arguments);
if (!this.notificationLevel) config.macros.unsavedChanges.refresh();
return t;
}
}
// hijack store.removeTiddler() to track changes to tiddlers
if (store.showUnsaved_removeTiddler==undefined) {
store.showUnsaved_removeTiddler=store.removeTiddler;
store.removeTiddler=function(title) {
var i=config.macros.unsavedChanges.changed.indexOf(title);
if (i!=-1) config.macros.unsavedChanges.changed.splice(i,1); // remove from list
this.showUnsaved_removeTiddler.apply(this,arguments);
if (!this.notificationLevel) config.macros.unsavedChanges.refresh();
}
}
// hijack store.setDirty() function to reset change list after file save
// note: do NOT hijack the prototype function. This hijack should only be applied to
// the main 'store' instance only (i.e., don't refresh when loading temporary store
// as part of ImportTiddlers processing)
if (store.showUnsaved_setDirty==undefined) {
store.showUnsaved_setDirty=store.setDirty;
store.setDirty = function(flag) {
var refresh=this.isDirty() && !flag; // 'dirty' to 'clean', force a refresh...
this.showUnsaved_setDirty.apply(this,arguments); // but change the flag first.
if (refresh) {
config.macros.unsavedChanges.changed=[]; // clear changed list
config.macros.unsavedChanges.refresh();
}
}
}
//}}}
| !date | !user | !location | !storeUrl | !uploadDir | !toFilename | !backupdir | !origin |
| 17/09/2020 13:26:26 | YourName | [[/|http://acarvalho.tiddlyspot.com/]] | [[store.cgi|http://acarvalho.tiddlyspot.com/store.cgi]] | . | [[index.html | http://acarvalho.tiddlyspot.com/index.html]] | | ok |
| 17/09/2020 13:56:46 | YourName | [[/|http://acarvalho.tiddlyspot.com/]] | [[store.cgi|http://acarvalho.tiddlyspot.com/store.cgi]] | . | [[index.html | http://acarvalho.tiddlyspot.com/index.html]] | |
| 17/09/2020 14:07:58 | YourName | [[/|http://acarvalho.tiddlyspot.com/]] | [[store.cgi|http://acarvalho.tiddlyspot.com/store.cgi]] | . | [[index.html | http://acarvalho.tiddlyspot.com/index.html]] | | ok |
| 17/09/2020 14:11:45 | YourName | [[/|http://acarvalho.tiddlyspot.com/]] | [[store.cgi|http://acarvalho.tiddlyspot.com/store.cgi]] | . | [[index.html | http://acarvalho.tiddlyspot.com/index.html]] | |
| 17/09/2020 14:12:35 | YourName | [[/|http://acarvalho.tiddlyspot.com/]] | [[store.cgi|http://acarvalho.tiddlyspot.com/store.cgi]] | . | [[index.html | http://acarvalho.tiddlyspot.com/index.html]] | |
| 17/09/2020 14:13:20 | YourName | [[/|http://acarvalho.tiddlyspot.com/]] | [[store.cgi|http://acarvalho.tiddlyspot.com/store.cgi]] | . | [[index.html | http://acarvalho.tiddlyspot.com/index.html]] | | ok |
| 17/09/2020 15:35:08 | YourName | [[/|http://acarvalho.tiddlyspot.com/]] | [[store.cgi|http://acarvalho.tiddlyspot.com/store.cgi]] | . | [[index.html | http://acarvalho.tiddlyspot.com/index.html]] | | ok |
| 17/09/2020 15:45:41 | YourName | [[/|http://acarvalho.tiddlyspot.com/]] | [[store.cgi|http://acarvalho.tiddlyspot.com/store.cgi]] | . | [[index.html | http://acarvalho.tiddlyspot.com/index.html]] | | ok |
| 17/09/2020 16:05:39 | YourName | [[/|http://acarvalho.tiddlyspot.com/]] | [[store.cgi|http://acarvalho.tiddlyspot.com/store.cgi]] | . | [[index.html | http://acarvalho.tiddlyspot.com/index.html]] | | ok |
| 17/09/2020 16:33:17 | YourName | [[/|http://acarvalho.tiddlyspot.com/]] | [[store.cgi|http://acarvalho.tiddlyspot.com/store.cgi]] | . | [[index.html | http://acarvalho.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");
//}}}
Use Case diagrams may be done in a structured or unstructured way. We will focus here in the unstructured way as it is simpler and more adequate to the Inception phases of the projects.
Use Case diagrams shall be considered alongside with [[Data Flow Diagram]]s but from the perspective of identifying the user interactions with the system, that is, the functionalities that the system offers to its users. While we are focusing on data flows to and from our system in [[DFD]]s, on Use Cases we focus on functionality blocks the user expects to use. Its an exploring and validation tool that is easily understood by non technical stakeholders, hence its usefulness on inception stages. They are also an aid in determining the screens we need to prototype and the roles the application will need.
TODO: add example, describe usage
!!References
* Ryan Languay, Nika Prairie, Jörg Kienzle, “[[Concern-Oriented Use Cases|https://www.jot.fm/contents/issue_2023_02/article13.html]]”, Journal of Object Technology, Volume 22, no. 2 (July 2023), pp. 2:1-14, doi:10.5381/jot.2023.22.2.a13. - Interesting proposal with reuse considerations
----
See also : [[Data Flow Diagram]]
----
@@color:#c4d6ed; ^^
Description: Use Case concept, usage and references
^^@@
Validation & [[Verification]] (V&V) in software are the quality processes to assure that as system fulfils its intended purpose and performs as specified.
Validation is oriented to assure that "''we are building the right thing''". Verification gears towards assuring that "''we built it right''".
A very important quality attribute of any specification is its validation ability, that is, the degree to which it allows validation from your Customer and peers. This is achieved, mainly, through structure, context and clearness. See [[Writing Good Requirements]] for more information.
Validation ability is an essential quality attribute of a [[Technical Proposal|Technical Proposal Production Guidelines]]. The ability you provide to your (prospective) Customer of judging the fitness of your understanding of his problem and the solution you propose to it is what will set you proposal apart from the rest.
Validation is also an essential step on other specification stages to prevent expensive mistakes and misunderstandings, that's why you want all of your specifications reviewed and approved by your Customer before you start developing.
//[[GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE REQUIREMENTS AND DESIGN SPECIFICATIONS|https://web.archive.org/web/20180721205319/http://csse.usc.edu/TECHRPTS/1979/usccse79-501/usccse79-501.pdf]]//
[[Barry W. Boehm|https://en.m.wikipedia.org/wiki/Barry_W._Boehm]]
----
@@color:#c4d6ed; ^^
Description: Software Validation concept
^^@@
<div class='toolbar' role='navigation' macro='toolbar [[ToolbarCommands::ViewToolbar]]'></div>
<div class='title' macro='view title'></div>
<div macro="view title replyLink"></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>
{{tw_ttoc{}}}
!Why writing good requirements is important
A good, validated, requirements catalogue is what assures your solution will meet Customer's expectations and Project Management's deadlines.
<<quote 'Frederick P. Brooks on analysis relevance' 'Frederick P. Brooks on analysis relevance' 'open'>>
<<quote 'Mannion and Keepence on requirements effort' 'Mannion and Keepence on requirements effort' 'open'>>
I learned that ''you may build a bad solution over a good specification but you will never build a good solution over a bad specification''. [[Validation]] by the stakeholders plays a fundamental role in assuring you have a good specification this, however, requires that the stakeholders indeed read the proposed specification and, more, that they understand it, in order to provide valuable feed-back that you can use to improve it. "Garbage in - garbage out" processes are just a way to postpone problems to development or, worst, to acceptance.
Specification is a Software Engineering process just like coding, it can, and many times will, be late. Acknowledge it and act accordingly. Project Management will press you to "deliver something" to meet the deadline. They don't believe anyone will really read the specification anyway. This is the worst mistake, even if nobody else reads the specification, you did, and that is a very important success factor. ''Projects shall be late at their beginning, while you still can do something about it, not at their end.''
I also learned that ''stress at the beginning is motivation, at the end is despair''.
One very important aspect is that [[Requirements Specification|Software Requirements Specification Guidelines]] is a step in a process and is, definitely, not the first one. To be able to produce a good requirements specification you must have previous work done at [[RFP Analysis|RFP Analysis Guidelines]] and [[Technical Proposal|Technical Proposal Production Guidelines]]. Without this previous work, or if you disregard it, you will, most of the times, be engulfed in a scope and out of context detail nightmare and will, probably, build a very poor system.
!Anatomy of a requirement
A <<quote 'Software Requirement' 'Software Requirement'>> is composed of several parts, each one fulfilling specific goals. It is important to consider all these parts on each and every requirement you write.
!!Context
A requirement shall be as simple and short as possible therefore establishing a proper context for its statement is essential.
<<Image "FR" "640" "Requirements_00.JPG" "https://dl.dropbox.com/" "s/xaxxtkwzahyfimk/" "?dl=1" "Package notes as context for requirements.">>
In [[EA|Sparx Enterprise Architect]] the first natural context provider is the Package element. Packages structure and group Requirements but they also provide a textual note where you shall describe the intent and the vision where the enclosed requirements fit. The purpose is to avoid having to repeat context information on each and every requirement. Here you can explain and guide your reader to allow him to perform a true [[Validation]] of the requirements. A good context provides a way to assure your reader understands the requirements and, more, understands them the same way you do : __this is crucial to avoid ambiguity__.
Other context providers are the [[traceability|Traceability]] relationships to <<quote 'Proposed Features' 'Feature'>>. You shall establish the scope of each topic in specification by identifying the related features it responds to. The Customer shall be able to clearly identify which features (requested and proposed) the requirements respond to in order to understand their impact, trade-offs and practical significance.
!!Title
Title is a very important part of a requirement. First it is the only visible part when you look at a requirements diagram, second it acts as a table of content and as a secondary structure by grouping and sorting the requirements, third, but not less important, it provides context and focus for the requirement statement. This last characteristic is the most important in what concerns validability of the requirement. The title is intended to define a clear scope and determine an unambiguous point of view for the statement, effectively leading the reader towards a common comprehension of the requirement statement.
<<Image "FR" "640" "Requirements_01.JPG" "https://dl.dropbox.com/" "s/qv9xohgby8anog7/" "?dl=1" "Structure, traceability and title as context providers for requirements.">>
A requirement's title is also very useful in assuring the requirement is <<quote 'specific' 'SMART Requirements'>> as it shall be short and direct and establish precisely what the statement is about. A short title for a specific statement is easier than for a complex, multi-targeted statement. As a rule of thumb, if you can not find a proper short title for your requirement then its statement is too complex and not specific.
A very good way of preparing and conducting a requirements specification meeting with the stakeholders is to produce a package structure and a set of requirements with just titles and use them as a topic roadmap and check list during the meeting. Better yet, you shall also identify the [[Proposed Features|Feature]] each requirement is addressing.
A requirement title shall be divided in two parts : Numbering and Name.
An example of a requirement title is : ''~SR-10.10.010 - Authentication''
!!!Numbering
Numbering is essential to make the requirement's reference unequivocal. We suggest that you use hierarchical numbering as it eases referencing and locating requirements in [[EA|Sparx Enterprise Architect]] in a great extent.
Numbering shall follow the format :
''{Prefix}-{Hierarchy Numbers}.{Requirement Number}'' - {Requirement Name}
*''Prefix'' shall be ''SR'' for Software Requirements
*''Hierarchy Numbers'' shall reflect package hierarchical placement of the requirement.
*''Requirement Number'' shall be a sequential, unique (in the hierarchy), gaped and zero padded number that, apart from uniquely identifying the requirement also assures its sort order in [[EA|Sparx Enterprise Architect]]'s Project Browser and generated documentation.
Numbering shall use gap numbering (10 steps) in order to ease renumbering and "in between" insertion.
Take notice that, after the first release of the specification for the stakeholders you shall not modify any requirement's number.
!!!Name
<<Image "FR" "" "Requirements_02.JPG" "https://dl.dropbox.com/" "s/alwsr88cd6cjbkg/" "?dl=1" "Document generated from the above structure">>
The name of the requirement is the first thing your reader reads. It will condition and orient his understanding of the statement and focus its scope. Name is the subject of the statement and you shall use it to check if the statement is, or not, [[specific|SMART Requirements]]. If your statement says much more than the name's subject covers then you shall split your statement in several requirements.
The name may also be used to produce sub-grouping in the requirements, for instance you may use :
''~SR-10.10.020 - Login'' and ''~SR-10.10.030 - Login - Intrusion detection'' to group several related requirements without having to create too many sub-packages. Be sure to not abuse this technique, if you have several closely related requirements it is probably better to group them in a dedicated package.
Sub-grouping also leads us to another important topic : ''structure'' and ''order''. Do not forget that the validatable item for stakeholders will be a document. As in any other document, structure and sequence play a decisive role in readability. A clean, well structured and with proper sequence document promotes understanding and validation.
Think of names as topics in a table of content, this will help in preparing and conducting requirements specification meetings with the stakeholders. With time and experience you will also build a kind of standard template or check list of topics, in each common subject, that can be improved from project to project and that will greatly improve completeness of your specifications. You will be surprised with how much you can reuse from one project to another.
!!Statement
The fundamental reference for requirement's statement writing is <<quote 'SMART Requirements' 'SMART Requirements'>> by <<BibRef "Mannion,Keepence 1995">>. Be sure to read it before anything else, it is a short, very well written paper that any practitioner should know.
A good starting guide for requirement statement expression may be found at <<quote 'Requirements Boilerplates' 'Requirement Boilerplate'>>.
There are many guidelines for quality requirements. Experience will give you the main ones, the next topics, however, shall always be considered when writing requirements.
* keep it short and direct
** the reader must be able to remember the beginning of the statement when reading its end
** the statement's content must be contained in the title's subject
** use imperative mood
** remember context shall be established on package not on requirement's statement
* respect atomicity
** don't say two things that can change autonomously in the same requirement
** check that you can always answer in a Boolean manner to the question about if the system respects the requirement
** do not cross-relate requirements, this will lead to a status and dependency nightmare. Use Packages for aggregation of interdependent requirements and always evaluate a requirement in the context of its Package and sibling requirements.
* use proper vocabulary and be consistent
** use, and, when needed, establish, business concepts
** beware of synonymy traps (you are in a specific business context)
** build a complete glossary (business and technical)
* don't repeat yourself
** do not repeat statements in different requirements (that's the context's job)
* trace your requirements
** trace each and every requirement to your contractual proposal
** the ones you can not trace are inception mistakes or change requests
As with any other guideline take these with intelligence and consideration. For instance the example requirement ~SR-10.10.030 above could have been split in three different requirements but would that be more readable or maintainable?
The statement of a requirement does not have to be text only. You can use auxiliary diagrams enclosed in the statement if they help to understand it. A [[State Chart Diagram]] or a [[GUI mockup]] may be extremely useful to increase requirement understandability and [[validability|Validation]]. See [[EA Usage - User Interface diagram]] guideline for more details.
!!Other attributes
[[EA|Sparx Enterprise Architect]] provides many other attributes for requirement element and you shall take advantage of some of them :
* [[Status|EA Usage - Attribute Status]] : is a list of states that can be used to classify a requirement as Draft, Proposed, Validated, Implemented, Tested, etc.
* [[Dificulty|EA Usage - Attribute Difficulty]] : The difficulty attribute shall be used to identify areas (features, requirements, modules) that present major challenges to the project.
* [[Priority|EA Usage - Attribute Priority]] : shall be used to distinguish essential, required and nice-to-have elements (must, shall and nice-to-have).
* [[Type|EA Usage - Attribute Type]] : shall be used to denote an appropriate typology for each element.
* [[Version|EA Usage - Attribute Version]] : shall be used to denote changes to requirement after it is validated by stakeholders.
* [[Phase|EA Usage - Attribute Phase]] : can be used to define a staged delivery of the project
!Requirements Specification
Requirements Specification is an engineering process like any other. This means that, professionally, it shall be performed by a team where there are defined roles and that follows a defined process with the proper techniques and tools.
!!The Requirements Team
The team part of the above statement is very important. Requirements gathering is a very stressful task with huge amounts of information, not always coherent, that is obtained in a disperse and, many times, unstructured way. A single person can never grasp that volume of information alone. Requirements gathering shall always be performed by, at least, a two persons team. And I mean two analysts, not a PM and an analyst. This is an essential factor for correctness, completeness and readability of a Requirements Specification. It is also the best way to promote maturity in your company as these teams shall be composed by a more senior analyst and a more junior one.
Also one of the more common problems in requirements is ambiguity and there is no better weapon against it than a discussed, shared and agreed expression and this means that the requirement expression shall be produced, not only reviewed, by more than one person.
!!The Requirements Gathering Process
!!!Preparation
The Requirements Process involves Customer interaction and access to scarce resources (the Customer's experts) and, as such, it shall be planed and prepared with all the care possible to not waste opportunities and to optimize each and every interaction.
Remember that, during Requirements Specification you must also protect the proposed scope in order to keep focus and not risk project's success. To do this you must prepare the list of subjects to address in each meeting and with each stakeholder. A good way of doing this is by creating a specification structure (Packages in EA) to address each subject of the Proposed Features. The [[Technical Proposal|Technical Proposal Production Guidelines]] shall be your initial roadmap, although you'll need to add more detail and refinement to its structure and, probably, add some more technical subjects not explicitly on the Proposal, you must remember that scope was established on Proposal and shall not be modified on Requirements without a formal Change Procedure.
Start by creating your package structure (an evolution of the one in your Proposal, don't worry, you will refactor it more than a couple of times during this phase), then drag your Proposed Features to it and start asking yourself : "What information will I need to develop this Feature?". Create a Software Requirement with only a title for each one of your questions or answers and [[trace|Traceability]] it to the correspondent Proposed Feature.
On a second iteration try to add some content to the proposed requirements you have. This content is your preliminary view and shall be confirmed or refuted by the stakeholders but will serve as a starting point and checklist. This is also a very good time to access reusable requirements sets, or even solutions, that you may have.
Depending on the size of the project this phase shall take from some days to some weeks. Be careful to not take too much time without validating your view with the Customer, you may be completely wrong. But also consider that jumping directly to stakeholder interview at the beginning of a project without proper preparation is foolish and involves the risk of loosing control of the specification process and project's scope as well as Customer's respect.
Again, remember this shall be a team effort and that this is extremely difficult to perform alone as most of the information shall be obtained, clarified and detailed in a dialog process inside the team.
After some iterations and lots of brainstorming you shall have a fairly decent structure of topics to be addressed and also some insight on which stakeholders you need to interview for each subject. Build an interview plan, with detailed schedule, and propose it to the Customer remember to include Interview and Consolidation time. After obtaining agreement on the schedule prepare meeting invites with detailed explanation of the subjects to be addressed, also include all information requests (Customer's documents, other systems specifications, etc.) you can anticipate you will need. This will allow the stakeholders to prepare themselves (possibly aligning their own team views and gathering needed information) prior to the meeting and make this one much more effective. Be prepared to face some stakeholders that will not prepare the meeting. That's life and they are the Customer...
!!!Interview
Interview time shall not go on for more than 4 hours a day. In my experience, more than this is a waste of time and jeopardizes consolidation efforts.
When you have to travel to Customer's premises, your management will pressure to do all the interviews in the shortest time possible and then return home and consolidate. This is a severe mistake, you will loose half of the information gathered and will be sure of none.
Start the interview by explaining your methodology and its goals then ask the stakeholders to briefly address their view of the subject to handle. Be ready to adjust, on the fly, the structure and information you prepared. Then start, on a topic by topic approach, to detail, validate and complete your prepared information. When you reach a statement on a subject be sure to clearly state it for all the attendees to understand and validate.
Be sure to update and correct your Glossary in every opportunity. Every time a new concept emerges don't be afraid to ask what it means and record its meaning.
I prefer to record most of the information in my [[CASE]] tool directly (it offers a lot of functionality like relationship, state, atomic elements, etc. that help the recording process) but you may use other methods if you want. The point here is to effectively and completely record the information. Don't waste time in giving it a final form, you will have Consolidation for that, but also do not postpone important issues and make sure you understand the stakeholders point. Your questions are not dumb nor are the Customer's representatives, they are experts in their fields and they understand that you are not, and most people likes to teach things they are good at. Show that you are good at learning and that you preserve the information they give you and you will earn their respect. That's the first step for project's success.
!!!Consolidation
Consolidation means to structure, persist, normalize, disambiguate, discuss, understand and establish the requirements.
After stakeholder interview a consolidation meeting within the analysis team is essential. These meetings shall take place as soon as possible after the interview and shall persist the information gathered in the requirements tool. The consolidation meeting shall take, at least, as many time as the interview, most of the times it will take more. You shall review the statements expression and complement them with auxiliary diagrams (a business process, an improved [[DFD|Data Flow Diagram]] or a [[GUI mockup]] for instance). You shall also take the time to make the requirements [[SMART|SMART Requirements]] and to assure they are coherent in the full system.
As soon as possible after the consolidation meeting, its results, in a draft form, shall be informally [[validated|Validation]] with the stakeholders from the interview. The subject will be fresh in their minds and they can immediately correct any errors or omissions on your interpretation. Also the information volume will be more manageable in small chunks of 10 pages than when you only present a final 200 pages document that nobody has the time, or will, to fully and deeply validate. This will assure an informal preliminary acceptance of the analysis team view and also assure you are preventing rolling errors. It is also very important in aligning expectations when you have to compatibilize different views of the system from different stakeholders.
!!!Review
A peer review is essential in any professionally produced product. It is even more important in Requirements Specification. But not less important is Customer validation of the proposed specification. For this to happen your specification must be readable. If it is not, you'll get a "postponed agreement" that, you may be sure, will get on you as soon as anything goes wrong and, as soon as it starts, rest assured it will not stop and you'll be in "scope hell" and will spend most of your time discussing, justifying and arguing about scope.
!The analyst role
Finally you should always take good notice on what says <<quote 'Tom DeMarco on the Software Analyst role' 'Tom DeMarco on the Software Analyst role' 'open'>>
----
See also : [[Software Requirement]] [[SMART Requirements]] [[EA Usage - Requirements Diagram]]
----
<<TiddlerToC min-entries:1>>
@@color:#c4d6ed; ^^
Description: Writing Good Requirements guideline
^^@@
/***
|!''Name:''|!easyFormat|
|''Description:''|the format command format selection according to your choice|
|''Version:''|0.1.0|
|''Date:''|13/01/2007|
|''Source:''|[[TWkd|http://yann.perrin.googlepages.com/twkd.html#easyFormat]]|
|''Author:''|[[Yann Perrin|YannPerrin]]|
|''License:''|[[BSD open source license]]|
|''~CoreVersion:''|2.x|
|''Browser:''|Firefox 1.0.4+; Firefox 1.5; InternetExplorer 6.0|
|''Requires:''|@@color:red;''[[E.A.S.E]]''@@|
***/
//{{{
config.commands.format = new TWkd.Ease('Format','format selection accordingly to chosen mode');
config.commands.format.addMode({
name:'Bold',
tooltip:'turns selection into bold text',
operation:function(){
config.commands.format.putInPlace("''"+TWkd.context.selection.content+"''",TWkd.context.selection);
}
});
config.commands.format.addMode({
name:'Italic',
tooltip:'turns selection into italic text',
operation:function(){
config.commands.format.putInPlace("//"+TWkd.context.selection.content+"//",TWkd.context.selection);
}
});
config.commands.format.addMode({
name:'Underlined',
tooltip:'turns selection into underlined text',
operation:function(){
config.commands.format.putInPlace("__"+TWkd.context.selection.content+"__",TWkd.context.selection);
}
});
config.commands.format.addMode({
name:'Strikethrough',
tooltip:'turns selection into striked text',
operation:function(){
config.commands.format.putInPlace("--"+TWkd.context.selection.content+"--",TWkd.context.selection);
}
});
config.commands.format.addMode({
name:'Superscript',
tooltip:'turns selection into superscript',
operation:function(){
config.commands.format.putInPlace("^^"+TWkd.context.selection.content+"^^",TWkd.context.selection);
}
});
config.commands.format.addMode({
name:'Subscript',
tooltip:'turns selection into subscript',
operation:function(){
config.commands.format.putInPlace("~~"+TWkd.context.selection.content+"~~",TWkd.context.selection);
}
});
config.commands.format.addMode({
name:'Highlight',
tooltip:'highlight selection',
operation:function(){
config.commands.format.putInPlace("@@"+TWkd.context.selection.content+"@@",TWkd.context.selection);
}
});
//}}}
/***
|!''Name:''|!easyInsert|
|''Description:''|insert text template at caret position|
|''Version:''|0.0.4|
|''Date:''|10/02/2017|
|''Source:''|[[easyInsert|http://acarvalho.tiddlyspot.com/#easyInsert]]|
|''Author:''|André de Carvalho|
|''License:''|[[BSD open source license]]|
|''~CoreVersion:''|2.x|
|''Browser:''|Firefox 1.0.4+; Firefox 1.5; InternetExplorer 6.0|
|''Requires:''|@@color:red;''[[E.A.S.E]]''@@|
!!History
''0.0.4 10/02/2017 : Added insert file reference''
''0.0.3 02/02/2017 : corrected image parameters''
''0.0.2 19/05/2013''
***/
//{{{
config.commands.insert = new TWkd.Ease('Insert','insert template text at caret position');
config.commands.insert.addMode({
name:'Image',
tooltip:'image template',
operation:function(){
config.commands.format.putInPlace(""+TWkd.context.selection.content+"<<Image \"FR\" \"320\" \"filename\" \".\" \"\\filepath\\\">>",TWkd.context.selection);
}
});
config.commands.insert.addMode({
name:'Image with caption',
tooltip:'image with caption template',
operation:function(){
config.commands.format.putInPlace(""+TWkd.context.selection.content+"<<Image \"FR\" \"320\" \"filename\" \".\" \"\\filepath\\\" \"\" \"caption\">>",TWkd.context.selection);
}
});
config.commands.insert.addMode({
name:'Bib reference',
tooltip:'bibliographical reference template',
operation:function(){
config.commands.format.putInPlace(""+TWkd.context.selection.content+"<<BibRef \"reference\">>",TWkd.context.selection);
}
});
config.commands.insert.addMode({
name:'Popnote',
tooltip:'selection to inline popnote',
operation:function(){
config.commands.format.putInPlace("<<quote \'"+TWkd.context.selection.content+"\' \'targettiddler\'>>",TWkd.context.selection);
}
});
config.commands.insert.addMode({
name:'File reference',
tooltip:'Local relative file reference',
operation:function(){
config.commands.format.putInPlace("[["+TWkd.context.selection.content+"|file:.\\]]",TWkd.context.selection);
}
});
//}}}
R0lGODlhUABQAPcAAAAAAIx7LWRbOczMZiEcMdPR00xmjJGImxcYGI5vhcTExkZkfjFJR1mCoaCaP0RbZJiosT4/NhEIB/foTWWRpXN1jUpMZuDVz4ptcTMfIaGFi/Pw6WtefnVfaoJsOoyanwEIB1hCNVuQtLuiRFxIQO/idkIrMp2yy//5hJeHX66loaCYiHSElEJbWVZnijozGHNsfh8bImJdaGFOZ+DVTD0+W5GCeubf3VVzg7+2aEJOWniMoRcPH419Tr27n1dFaZ2hbHpoVjMzM4Okwfj09GRQW4NrjK6mgX1tZldDV5SDi0lIUaCUpf/2Ul9kelBwlMO7v4t8dNPGx6einz47TIBohLCFi1tLUxAOD2uDk21dQEY3LHJqVP32dSgfIqqerb6xVufceLWgjDYfKZV3fiQYC21Xc4FibVNOQsrIbVJASJmFO2xWcnBffk4pN7W1mV2JrbOnSFNdbIJ2SpChsNzV1wkBCJaHspiLU21dVn1wjebi5mR7in+DWLy2tjc5Qx0oPreuvoaJlzApOszMzIp5k5uOaFVRZaGOYPDlbW6euCIaGNqQl+bcanNxh0tQPkU/U4OEkPj28U1slLFwcoR8k4Z8cjoeG3pRYmRPM46FlqmhcGZmZgcQCxoQD29nQXFvbXVgOyktJntrR1tCQv///2R3hHt8X9vMWFxrfPjxdsimtVN4n8qzRZFbQbSmo0lBTXpigXB7mZ+bkf//ZnBLUWeDnZmDTc6KkK2nXh4gIs/MvzovK/Drw09nhce6ZiknPBQQCWNbU5CQnTkoK359gauNm7awrufaZX52VwkCAO3k6d3Oz1SErIOxxUYtQU9QKmpjciIRGm6MnVAtQJmZmVBOWDUzP6CKkFx0jX+Uq6+usggICNnLap5Waox6jWdza9/d38q9Wkk6OmWbuoloeVlaTJ6crMG3saCRf3uGnFdQbmmDi7euYiQlF1tXb1VNUraYUmFGTKWjrkhohjAqHmN9kkA9Qcqysu/u7ykpMmyZr6yilVVsjJKUrP///yH5BAUUAP8ALAAAAABQAFAAAAj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuXMGPKPAmBHaRo4Nqc4RTuw8yHRNT5YyKo6IFvSL99ERSJKZSfChPoQVqoaKVYWKtUKWTESKVI+aAahCKlgzFNmgo5csSBw6G3ZszMmPFtGBQ/YgfmI6XhnB497GC0MbPuHQcz7yzos2PHixklVwrk/WfJDDZNf9uyGYTFBBsj0YBhAQECAJZrsa7kfUVtmKZYemKxaeMFgDRiXgYN4mFCHxY7AACoYRMFajg15ZhcjWWGQ6x799TUDo4lgxcs3LgBWJTgCt6ZoK58/6lUqYqZNm3uxarCCziA7MGDa89QBAaaZTKhbOlLHmuhJQCQEoMy72Vn4IHSYAHLGcbEJAkXpPjBQiUVcGCEDFgsQop8B3ZooAmxKBHTMhFEQkcFlcCQGgIAeCEDN9h56OEYzyBxA0z8mBDIhJVwwEYwAMTwzD0wytghAJ5wQ8oqMGVyhj9oVdKGCQBIgMkZBxZ4YIwGAjDGKvmEc8MyRKiUTwavfIAWC7HU40kZpGyopZEdSuMHNtbkYcM8Kq0wjh+uoWVEElvUI4EnHNLZIRYK2CCHL77IUYE2NohhEhcYzKNJJXrMQEUSmFCTqKLcECgfKB3YAsckvhjwhBPFQP9QzQUFECKZR5KQ8MUBaF0BnDRJUKMdqQYKoctoVZpgyzR8ZLEPHNAugAAZH7BQARQK4CcREURIIkk++WwA7hHjHFPIAdjUEx+MXJKqTAVZyMEAAgiYkIo99piSBR8NNLMDFhYo8oQvk+iDi0Q3+PDKJpbkEcQc5twTQgjzVDMMGZ6AoN2o7joyxD4U4JuKDteok00D9hgwyTTcWCBCNjjAocvBDkHxhg9AJJPHKCGQEEQQwnASgjzzDHMOEhKAgN2cdMYIQCpwTDPNEIpkgcMiTjSQCiuswGELNw+IYA875MTAyEKlhLMLIX30wcUoyWCQThQr+IHOMXVwIc8xB8z/A4p2SpuABdMyxpeKIvZkwQIffOzDgD4PmFADPct2YoHXOwyhCyU3bIDQHrus8EkyoxyBRBSeH4RGHscYXQw3niyyiDCdvEc4fKbpoos1jE+DrykN4OBJBvpcQ8Uh4GBxSCpyOMKCLrXYgE0d4aQuUD6GzLHJHHOks0E4eyQUASZ8H2CMF1vkwc0ipL43yDoV7KCPNEJE8wQrwKeyyCH99C+HENyAhw7oFQMscMAXM1gHDPhRpn/4QBiIcEAodnEBbSkkD7U4xwEO8AUYeCEC0pDA7QYHAH0cYlKygAQWPHGoa2RjGg2QQwwi4QILMOAaIsRdcNYxCRZwzRSceIUP//rggUasYQyEcEgySKDBYQyjGFhAgBcQZSQAXAMGslCHE3gAAAIC4g9qsAc5WoCFJcTAPcEJxiK2oAVoKOMHiqDDPugBiBhQIhMeUIUq5qCFdNShAAqoww3CdxB+hOAcmjhHJEQBgAyIgk4AAAYLtJGNSSQBC9XxghxYMYlr3GMHC4iPMmDnjlCsYQSo6AIqggGJVFjjD4vwghqsQApXJKIb3UBGO1LAhRAkwxI2GNMelhGWgYxjHn2LxOAQQIzbcQMYtrAFH1KxAFPYAxaXcELKVKaPJPAhOO4IwClRMYEmmLMJrQiGgZThBSWQSQGgmAMYVNEFZAzgF+3YxCnmkP+CDswgCDa41T+E8IptGNQLXmCMHYrUJX1oQxv9kIMcqACLaXDgHXzwBQcq0I8FjEENAKhHKyZQTnPSIhEOCMALSoOkM6DDggrARhRSgIdudEEVJehGDsAABkTg4RajyMMs+PEGXhQhEsWoBjCecQV9sHRjwbnGCT6QChc4gR7XgIUL+kcPF2TDAM14AKKg0QVaNIEGIwiAB6BRBhECgBhomMINSlGQUihSGIbIhTjCUAKcluCvYcjFHHqAiFzcQgtROIUlYAELG8gAAb8BgB0giwBd1IAKg6iBE+DwB2U9wRT9M4DKcECaeuQiDmuAxgugGpwxaOACC9lGMfLQg1//pAGXuG1EIxKRiC70tgRh6MYvcpCLXCAiGT0IBTQ+YYgUAOET7khSMMYBjwzcgw9y0AEkIIHZa+jDQJhkbYEA4I2GEGEPdYBBHgSAiBzgFhWoQEYikIEK3iaiEapAAQr0qN/99le/YcjBKbSQAU94ApOQxYIyTGUaHRaIXjlkBkQKEIhjULAXvTgCEJ7LXEMgYg6mjANPeZqDX9g2DShux07jkYxHeEECg5NGKpj3gBpbIxWM3Bg3xgCPDsg2OMKgq0UU4Ac/COIbgQjEK64wiCgEYWJBKEMM6kHlF1gZoWXIcicS3KIhnOAEzgizM07ASADoIg/FMIYCbhQOYeRh/xdC7gie/HGHIhBAVPHJs57lQ0IdcMAJpjgZHNjBUnk0cCCgO7RHlsGFJdBhCuPYzjg0Riz4ZMe6VICEE+6hDCxIwworQYcJqDAPFVgDALxQWqVxlw4FHAMJSCAGMfJABuulRAXwKEKF76HgYVUaAFeQxD9KwYxdTOEYzLB1SkqBjgwkwQ8qKEIz6eXMLnkCH5MpxhjacA58RIIHuCENpY0kj8n8Ix9KGMMhmLANTmRANwgAjpG2IGFzS8IS47jiNiLAjVkLYRF7DhC2zS2QG/ADFDKAAYDckIAl1AMLPBicBHgBD3zEmeD/IMIrzNABNZznGu54xjvyMI48iKGYGC03yDG+EZhnGFUJ2HhFymdO85rb/OY4z7nOd87znvv850APutCHTvSiG90gAQEAOw==