TDD stands for Test Driven Development it is a development methodology where you write unit tests before you write your actual code.  Wikipedia defines it as:

Test-Driven Development (TDD) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes. The availability of tests before actual development ensures rapid feedback after any change. Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing.

In its simplest form it is a way to develop software that allows your code to be completely tested and testable to limit bugs later on.

I have made several posts on TDD please check them out below. 

General Posts on TDD

TDD (Test Driven Development) for beginners
More on TDD "so much code"

Series on TDD

Part 1: TDD Test Driven Development for Beginners pt1
Part 2: TDD for Beginners pt2 - Pig Latin
Part 3: TDD for Beginners pt3 - The Application
Part 4: TDD for Beginners pt4 - Unit Tests

CI stands for Continuous Integration it is a way of constantly and consistenly testing your application end-to-end while in the development stage to limit bugs. Wikipedia defines Continuous Integration as:

For small projects, developers run all their unit tests, and integrate. Large projects often require a longer build and test cycle, so these projects use Automated Continuous Integration. A server process or daemon monitors the version control system for changes, then automatically runs the build process (e.g. a make script or Ant-style build script) and then runs test scripts (e.g. JUnit or NUnit). In many cases the build script not only compiles binaries but also generates documentation, website pages, statistics and distribution media (such as Windows MSI files or RPM files).

I read this and kind of go WTF? A while back I was able to persuade Scott Reynolds to post "Why Use Continuous Integration - Beginner's Overview".  Here is a quick blurb of his post.

At root, CI is a tool to automate build and build-related tasks.  A typical scenario is some CI "server" that checks the source repository for changes, gets latest, makes a build, and reports success/failure.  If you are running automated tests, CI would run them for you with the build, and would include the output in its report.  If you are running code metrics or static analysis like NDepend, FxCop, and so forth, CI would run those for you post-build and include the output in the report.  Finally, you could configure your CI process to deploy newly-built code to some location, possibly for QA purposes.

So basically from these two sources it is a methodology of testing your application end-to-end to help make your application a more solid product by the end. With CI it allows you to see where what breaks on the application as a whole instead of your small subset of unit tests that you are hopefully writing using TDD.  As I progress through programming CI looks more and more appealing for me to use from a fun-setup-a-server-to-play-with-something-new way and to help me write better software. I suggest checking it out if you don't currently use it. 

For another resource on getting started with Continuous Integration check out this altnetpedia page:

Continuous Integration 

SOA stands for Service Oriented Architecture with SOA pretty much you do things with services.  Wikipedia defines SOA as:

an architectural style that guides all aspects of creating and using business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes loosely coupled from the operating systems and programming languages underlying those applications. SOA represents a model in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. The concepts of Service Oriented Architecture are often seen as built upon, and the evolution of, the older concepts of distributed computing and modular programming.

A simplistic way I like to "think" of SOA is your main application doesn't actually manually touch any of your data.  Instead you go through say web services to get and do all of your data-centric stuff.  One major reason being I can then build my application or my services in any language I want and just access them through a specific protocol.  To find out more about SOA please read the wikipedia article.  I just wanted to give you a basic concept of SOA. 

C.R.U.D.

CRUD stands for "Create","Read","Update", and "Delete". They are the 4 basic things people typically do with data in a some type of data store. Wikipedia defines CRUD as:

Create, read, update and delete (CRUD) are the four basic functions of persistent storage, a major part of nearly all computer software. Sometimes CRUD is expanded with the words retrieve instead of read or destroy instead of delete. It is also sometimes used to describe user interface conventions that facilitate viewing, searching, and changing information; often using computer-based forms and reports.

Often when working with data these are the 4 basic steps that are required to work with the data. So when you are creating your backend make sure you have at least these 4 things and you are set to start working with data.

This post is the first in a series of posts one what acronyms are in the programming world as there are a lot and we all need to know them so we don't get lost.