Tech Acronyms Made Easy

T.A.M.E in Technology

The tech world has a bunch of acronyms, shorthands, buzzwords, jargon; the list goes on and on. But do you really know what
all those words mean?

In this series, my aim is to demystify commonly used technology terms and acronyms so that you can understand them. In other words, we are going to TAME them....

Get it? 'Tamin' Technology? (I'll show myself out...)

The intended audience for this are those just starting out in their software development career, as well as those who are a few years into their career,
although you may still learn something if you've been around for a while.

I'm going to use the 'explain it like I'm five' approach, and break down things as succinctly as I can. I'm also going to use code where I can, to give a visual representation
of the topic as well. Are you ready to 'pick some low hanging fruit?'

Software Terms

We've all heard terms at one point in our career and thought 'what the heck does that mean'. I know I have. Plenty of times.
In my job as a software developer, I've heard lots of terms that I've had to quickly look up in order to know what my boss or co-worker has said
in order to understand a topic or process on the fly. I'm a quick learner, so I've got that going for me, but I've always wanted a tech dictionary of sorts
to go back and reference. Alright, enough fluff. Let's dive in!

ACID

ACID is used as an acronym to describe the properties of a transaction within a database. These properties describe the way of getting data into a database in a reliable fashion.

Think of a shopping transaction. When you go to the store, you pick out an item and bring it to a cashier. When you want to bring that item home, you put it on the counter in front of the cashier to signal a purchase, the cashier rings it up, and then gives you a total price. If the price is right, you reach into your wallet and pull out some cash or a credit card, and then you finally get a receipt which concludes the transaction.

Sometimes, that transaction doesn't happen as smoothly. Perhaps the cashier rings up the item twice and has to start over. You don't want to pay for the same item twice, so you don't hand over any money until the transaction has been reversed and you start over again. The cashier clears the register, and starts the process over again. Once the transaction is successful, you get confirmation in the form of the receipt.

When editing something on a website for example, you ultimately wind up sending data to a database. Maybe some processing happens before it gets saved (indexing, uniqueness check, formatting, etc) and then it finally gets stored in the correct table or tables. But, what happens if the network connection drops mid-way through, and not all of the data gets processed, saved, or formatted correctly? You wouldn't have any way of knowing which data got stored, or how it got stored until that connection is restored and you are able to refresh the page and see what happened. If things broke, you would have to go through the trouble of editing everything and starting over.

ACID stands for atomicity, consistency, isolation and durability, and these are all properties that ensure data is saved in a reliable, repeatable fashion within a database.

• Atomicity: Basically, this means that all the data gets saved, or none of the data gets saved. IF something was to break, the database would "roll back" the transaction, so it was as if nothing happened.
• Consistency: When data gets saved, it has to adhere to certain rules in the database. Things like primary and foreign keys may need to be created, or data must be a unique combination of values, or perhaps the data must exist (NOT NULL) in order for it to be inserted. We maintain data integrity with consistency.
• Isolation: In order for a record to get changed in ONE database transaction, it has to be locked. Databases are setup so things happen in isolation, which means that a transaction will start and finish one at a time, on a particular piece of information. In other words, only one person at a time can work on a row or table for example, and the next transaction must wait until the first is finished in order to make updates. That way, we make sure that the data is changed in an orderly fashion, and multiple changes are not happening at once.
• Durability: After something is committed to a database, durability ensures that the changed data remains within the database. It would be a terrible thing to have data wiped right after saving it, and would not make for reliable system if data was not available at all times. Durability can be seen in how we store the data (on hard drives, non-volatile memory), and it can also take the form of replication, backups, and redundancy to deal with things like system failures, etc.

API

Application Programming Interface: Think of this as a URL to someone else's code. Typically these URL's require authentication via a token, which gets appended to the end of the URL like so:
http://www.omdbapi.com/?apikey=[yourkey]&

That "your key" spot is where your "token" goes. You typically sign up, get a randomly generated token, and attach the token to the URL. Don't tell anyone what it is though! Most API's are rate limited and you pay as you use them. Giving someone your API key could result in an IP ban, outrageous charges, or both!

CORS

Cross Origin Resource Sharing: When you are browsing a website, you may not know it, but it is making 10's to 100's of requests as you scroll. It is updating site tracking services, grabbing data, requesting images, and displaying text. Some of that happens all at once when you load the page, and some of it doesn't. When you visit a page however, not all the data originates from that website. Some images and text may come from other sites, and that is where the term cross origin comes from. The website shares resources from other sites that do not share the same origin.

What does that mean for developers? Usually, servers are fine with accepting data from themselves (same origin). If you want to configure interaction, you typically need to set headers, or change a server configuration to allow it to talk to servers from other domains or IP addresses for example. In the case of setting headers, you can configure GET, PUT, POST requests with specific settings to create a security policy that protects your server from potentially dangerous data. On a corporate network for instance, you wouldn't want outside networks or servers accessing IP (intellectual property) on an internal server, so you might restrict GET requests from a certain origin.

This is a simplest explanation, but when seen in code, it may look something like this (using Axios):

axios.get('https://httpbin.org/get', {
  headers: {
    'Access-Control-Allow-Origin': 'https://internalSite.com'
  }
});

This GET request tells the server the origin is from internalSite.com, which may be necessary to make the request work.

CD

Continuous Delivery: When code is finally committed and merged into a repository, this is the process of actually building and deploying it onto a server. This process can happen many times a day, as developers are continually updating and merging code. When code is published, it may be sent through a build process which spins up a new server, or rebuilds code on an existing server. This can also work in conjunction with microservices, where individual servers serve unique purposes instead of having everything on one server. Docker and Kubernetes are most commonly used, and as servers are built, the version of code is tagged and you can track code progress through deployments.

CI

Continuous Integration: This is a process where code written by multiple developers is committed to the same central repository and merged together many times a day. This is different from continuous delivery, as this process is focused on the code itself. CI processes may include linting, testing, code formatting and code review before it is actually merged into the repo. Some of these processes happen automatically via a system like Jenkins, Bamboo, Gerrit, or Crucible to name a few. Code quality may also be checked via something like SonarQube.

One thing to note is that if code does not pass any of the automatic or manual steps, then it does not get integrated into the code base.

CRUD

Create, Read, Update, Delete: These are the four main tasks of any website you visit. Using Gmail? What actions do you typically perform? You write emails (create), read emails, edit subjects or drafts (update) and throw away old email in the trash (delete). Almost every piece of software follows this pattern.

CSS

Cascading Style Sheets: If you have ever viewed a website and wondered how they get everything to look so nice, this is where that happens. A <div> is typically styled with a .class{} with certain properties. Those properties are things like height, width, and background color.

DDL

Data Definition Language. This is used to describe the structure of database, including its schemas and tables. When you ask yourself "how many columns do you want?" or
"what type of data am I putting in those columns?" - these types of questions are answered when you create your DDL queries.

To create a table for example, we would create SQL code like this:

CREATE TABLE users (
    user_id              SERIAL       PRIMARY KEY,
    user_name       VARCHAR(50)   NOT NULL,
    user_address    VARCHAR(50)   NOT NULL,
    user_phone      VARCHAR(18)   NOT NULL,
);

We've created a user with an auto-incrementing ID, and created various fields. Notice I used user_id and user_name instead of id or name? I've been bitten
before when it comes to using reserved keywords as column names, so I'd suggest you avoid them too 😉.

DML

Data Manipulation Language. This is mostly used when referring to SQL code that updates, deletes, or inserts records in a database.

In code, it is commonly seen like this:

INSERT INTO users (user_name, user_address, user_phone) 
VALUES ('Mark', '123 Fake Street', '555-555-5555'); 

In this query, I've inserted a record into the users table, which was conveniently created above with a DDL query.

DOM

Document Object Model: Ever visit a website, right click, and view source? If you have, you probably saw some HTML, CSS, and JavaScript. All of this makes up a webpage, which in and of itself is a document. The DOM is an interface that allows programs and scripts to update the data and content within that document. In other words,the DOM allows you to change things on a webpage through the HTML elements. Things like DIV tags, paragraph tags, and header tags are all DOM identifiers, and you use JavaScript (in most cases) to change how those items act on a web page via the DOM interface.

Lets say you have an HTML snippet like this:

  <div>
    <p id="someText"> I am a paragraph </p>
  </div>

If I wanted to change the color of it, I'd need to manipulate the style some how. I'd use JavaScript to query the DOM and get that paragraph by its ID in order to change its style.

let pTag = document.getElementById("someText");

pTag.style.color = "green"

If you do this in a browser, that text will show up green. A simple way to think about it is this: the document.getElementById part is querying the DOM via the Web API.

DSL

Domain Specific Language: NO, this isn't your old phone line that you use to connect to the internet. A domain specific language is something like SQL. The actual syntax that a particular system uses is its domain specific language. You can't use SQL to create a front end for example, much like you can't use CSS to query a database. DSL's are optimized for a specific set of problems or use cases. XML, CSS, SQL, and HTML are all examples of domain specific languages.

HTML

Hypertext Markup Language: HTML is used to create websites, and this markup creates the DOM. Sorry, we can't create Vin Diesel from HTML.

IOC

Inversion of control: This is a mechanism for increasing the modularity of your code. The goal is to allow you to swap out components based on need because they share the same interface.
In other words, program to an interface not an implementation. IOC solves the problem of hard coding things in place, because when things need to change (say in a development environment vs production environment) you can swap out items without breaking anything.

JS

JavaScript: JavaScript is a programming language that allows you to create interactions on a web page. You can do this with "vanilla JS" or use a library or framework like Vue.js which has abstracted (hidden) away the complexities of dealing with these interactions and gives you a simpler way to handle them through their own syntax.

PWA

Progressive Web App: A Progressive web application is one which leverages the web API to give websites access to your mobile device. Basically, it is an "app" that is built in web technologies (HTML, CSS, JS) that runs on your phone, and even gets its own application icon to display on the home page. You can also make use of libraries for specific frameworks that abstract these things away for you (hides the complexity) and makes it easier to develop.

RDBMS

Relational Database Management System: Put simply, this is a program that allows you to store data in a relational fashion. Well, what the heck does that mean? In databases, we store data in tables, which are made up of columns and rows. Rows hold specific pieces of information, like a record containing a person's name, address, phone number etc. The column dictates what the label is for that field, marking a piece of information as a phone number or address for example. RDBMS's are programs like MySQL, Postgres, or Oracle DB (database). Think of this as a systematic way of organizing data, which is then accessed by SQL.

SQL

It can be pronounced a few ways (See-qwell, or ess-q-el) but whichever way you say it, it stands for structured query language. SQL is the de-facto standard
when it comes to getting data in and out of relational database management systems or RDBMS. MySQL, Postgres, Oracle, and Microsoft SQL Server (to name a few) all use this to
bring in data and get data out. SQL is a DSL (domain specific language) designed to manage the data held in these systems. I'll cover these terms in a bit, but they are all related in
on shape or another.

SDLC

Software Development Lifecycle: SDLC is the process used in many organizations to create software, including requirements gathering, the coding, testing and deployment of software.
This is a very vague term, with interpretations varying per organization. The main steps are planning, requirements gathering, design and prototyping, software development, testing, deployment and maintenance.

XSS

XSS: Cross Site Scripting. Cross site scripting is a security vulnerability where your application accepts and does not sanitize user input, and allows that user to run their code on your site. If your application takes untrusted user input and displays it some place on your site, it most likely will cause damage to your application. To work around this, you need to sanitize user input, and most front end frameworks have built in modules or third party plugins which can help with that.

Conclusion

These are just a few of the many tech acronyms, buzzwords, and jargon that you will find as a software developer. Don't get discouraged! These are all shorthands for things you will most likely use on a day to day basis, and after understanding what they are, you won't fret the next time you see them. I may expand on this post in the future to give specific examples on things such as the SOLID principles, or compare SQL vs NoSQL databases, but for now, this is a small glimpse of what you will see in the real world.

Don't loose heart. These buzzwords and shorthands are confusing at first, but once you see them, and understand what they are, it is more than likely you won't have to spend a lot of mental energy deciphering them again.

Cover Photo by Matthew Kerslake on Unsplash