Software Carpentry
Glossary

A

absolute path:
Yuan Gan
abstract data types:
access control:
access control lists:
acquire a lock:
action:
actors:
aggregate:
alias:
anchor (in regular expression):
annotated syntax tree:
assertion:
asymmetric cipher:
atomic:
Abhishek Ranjan
attribute (in XML):
authentication:
authorization:
automatic variables (in Make):

B

basic authentication:
binary data:
binary milestone:
binary mode:
blacklist:
Jeremy Hussell
boilerplate:
boundary object:
branch:
breakpoint:
Abhishek Ranjan
breakpoint, conditional:
bug tracker:
Bugzilla:

C

call stack:
callback:
camel case:
chain:
child class:
chunk:
cipher:
ciphertext:
class:
class diagram:
Simona Mindy
client:
code browser:
code inspection:
code review:
cognitive dissonance:
collision:
comment spam:
Alireza Moayerzadeh
commit:
Common Gateway Interface:
component object model:
component testing:
concurrency:
connection:
constructor:
control object:
cookie:
Coordinated Universal Time:
core dump:
Nilesh Bansal
cross product:
Amit Chandel
cross-site scripting:
CSV:
cursor:
CVS:

D

dashboard:
data member:
data modeling:
Lei Jiang
database column:
database key:
Amit Chandel
database row:
database table:
Amit Chandel
daylight savings time:
dead code:
deadlock:
Yuan Gan
debuggee:
decryption:
default target:
defense in depth:
defensive programming:
derive:
design pattern:
Lei Jiang
development process:
Yuan Gan
dictionary:
dictionary key:
directed graph:
directory tree:
docstrings:
document:
Document Object Model:
domain model:
Lei Jiang
domain model diagram:
drive:
driver:

E

element (in XML):
embed:
encryption:
entity object:
environment variable:
Nilton Bila
epoch:
Nilton Bila
error:
escape sequence:
event-driven programming:
exception:
executable documentation:
exponent:
extend:
Extreme Programming:
Tingting Zou

F

fail:
filename extension:
filter:
finite state machine:
fixture:
flag:
foreign key:
form:

G

garbage collect:
Nilesh Bansal
getter:
group:
greedy matching:

H

heap:
Abhishek Ranjan
heisenbug:
hexadecimal:
hijack:
host address:
HTTP header:
Nilesh Bansal

I

ICONIX process:
idiom:
immutable:
in-place operator:
inheritance:
instance:
instruction pointer:
instrument:
Integrated Development Environment:
integration testing:
integrity constraint:
internet protocol:
Nilesh Bansal
invert:
issue tracker:

J

join:
Amit Chandel

K

L

leap second:
leap year:
Liskov Substitution Principle:
little-endian:
Alireza Moayerzadeh
local time:
lock:
logging:

M

macro:
mailing list:
Make:
mantissa:
match object:
memory model:
merge:
method:
Nilton Bila
milestone:
module:
multi-valued assignment:
multiplicity:
Multipurpose Internet Mail Extensions:
mutable:

N

nested query:

O

object:
Lei Jiang
object-oriented analysis and design (OOAD):
Tingting Zou
operating system:
Nikos Sarkas
operator overloading:
Nilton Bila
optimistic concurrency:
Tingting Zou
outcome, actual:
outcome, expected:
override:

P

pack:
pair programming:
parent class:
parent directory:
pass:
path:
pattern rule:
pessimistic concurrency:
Tingting Zou
phony target:
pipe:
Abhishek Ranjan
plaintext:
polymorphism:
port:
post mortem:
post mortem debugging:
post-condition:
pre-condition:
prerequisite:
pretty-printer:
private key:
process:
profiling:
program slice:
project velocity:
protocol:
public key:
public key cryptography:
publish-subscribe:

Q

R

race condition:
raise exception:
record:
Amit Chandel
refactor:
reference count:
reflection:
register:
regression:
regression testing:
regular expression:
Abhishek Ranjan
relational database:
Yuan Gan
relative path:
Yuan Gan
release a lock:
release log:
A file (often a spreadsheet) that records exactly what was shipped to whom, when.
reluctant matching:
remote procedure call:
replay attack:
repository:
repository browser:
risk assessment:
roadmap:
robustness diagram:
role:
root directory:
Nilton Bila
RSS:
Alireza Moayerzadeh
rule:

S

sample:
scaffolding:
screen scraping:
search path:
seek:
sequence:
sequence diagram:
server:
Nilesh Bansal
setter:
shared library:
shell:
short-circuit evaluation:
Simple API for XML:
Alireza Moayerzadeh
single-step:
slice:
social engineering:
socket:
SourceForge:
Nikos Sarkas
sparse:
spawn:
special method:
spiral model:
SQL:
SQL injection:
stack frame:
stack pointer:
standard error:
standard input:
standard output:
state assertion:
static space:
status code:
step into:
step over:
submodule:
Subversion:
suspended process:
SWIG:
symbolic debugger:
symmetric cipher:
system testing:

T

tag (in XML):
target:
target program:
template:
test:
test result:
test suite:
test-driven development (TDD):
Alireza Moayerzadeh
testing, bottom-up:
text:
three-tier architecture:
ticket:
ticket, closed:
ticket, open:
time structure:
time zone:
timeline:
traceability:
transaction:
Nikos Sarkas
Transmission Control Protocol (TCP):
Nikos Sarkas
triage:
tuple:
two's complement:

U

Unicode:
Nikos Sarkas (see also ).
Unified Modeling Language (UML):
Lei Jiang
unit testing:
unpack:
URL encode:
use case:
Tingting Zou
use case diagram:
Simona Mindy
user stories:
Simona Mindy

V

validate:
verifiable deliverable:
version control system:
version number:
Large projects typically use multi-part version numbers to identify software releases. In extreme cases, “6.2.3.1407” means major version 6, minor version 2, patch 3, build 1407. The major version number is only incremented when significant changes are made, where “significant” means “changes that make this version's data/configuration/whatever impossible for older versions to read”. Minor version numbers are what most people think of as releases. If you've added a few new features, changed part of the GUI, etc., you increment the minor version number and throw it to customers. Patches are things that don't have their own installers. If, for example, you need to change one HTML form, or one DLL, you will often just mail that out to customers, along with instructions about where to put it, rather than creating a new installer. You should still give it a number, though, and make an entry in your release log. Finally, the build number is incremented every time you create a new version of the product for QA to test. Build numbers are never reset, i.e. you don't go from 5.2.2.1001 to 6.0.0.0, but from 5.2.2.1001 to 6.0.0.1002, and so on. Build numbers are what developers care about: they're often only matched up with version numbers after the fact (i.e. you create build #1017, QA says, “Yeah, it looks good,” so you say, “All right, this'll be 6.1.0,” and voila, you have 6.1.0.1017.) Finally, groups will sometimes identify pre-releases as “beta 1”, “beta 2”, and so on, as in "6.2 beta 2". Again, this label is usually attached to a particular build after the fact—you wait until QA (or whoever) says that build #1017 is good enough to send out to customers, then tag it in version control.
virtual machine:
visitor:

W

watchpoint:
waterfall model:
Simona Mindy
web services:
web spider:
Simona Mindy
weblog:
Jeremy Hussell
whitelist:
Jeremy Hussell
wiki:
Jeremy Hussell
wildcard:
Jeremy Hussell
working copy:

X

Y

Z