The following full-time positions have been posted within the past week to UMBCworks. Login to your account (via the link in the Jobs & Internships topic in myUMBC) and find details and application instructions as well as hundreds of other job postings!

9256991 - Decision Support Analyst, Clinical Economics - Mercy Medical Center
9257075 - IS Analyst - GP Strategies Corporation
9256976 - Assistant to the Executive Director - Teach for America
9256965 - Asset Management Project (Manager-in-Training) - EMG Corporation
9256918 - Healthcare Auditor - TMDG, LLC

The following part-time positions have been posted within the past week to UMBCworks. Login to your account (via the link in the Jobs & Internships topic in myUMBC) and find details and application instructions as well as hundreds of other job postings!

9256863 - Design Associate - WTS International
9255543 - Donor Services Coordinator - Anatomy Gifts Registry
9256880 - Hospitality Host - Observation Baltimore
9256822 - Line Cook - The Rumor Mill Fusion Bar & Restaurant
9256973 - Rehabilitation Counselor ISS - Humanium

There are quite a few properties in CSS that take a length as a value. The box model properties are the obvious ones: width, height, margin, padding, border. But plenty of others as well: the offset and sizing of a box-shadow or the size and spacing of fonts. What are all the accepted "length" properties in CSS? There are quite a few.

The Absolute Lengths

px

.wrap {
      width: 400px; 
    }

Pixels are perhaps best thought of as "device pixels" as this length doesn't have anything to do with the literal screen pixels in the display you are looking at. It's actually an angular measurement.

It is supposed to be a value that is normalized across devices and displays, but that increasingly isn't true anymore. For instance, websites on the iPad mini render the same as on the iPad, meaning if those values were set in pixels that normalization is rather out the window.

Pixels are still a canonical measurement on the web though as they are consistently handled, many other lengths map directly to pixels, and JavaScript speaks in pixels.

in

.wrap {
      width: 4in; 
    }

Inches are a physical measurement, but in CSS land, they just map directly to pixels. Feel free to chime in with use cases in the comments and I'll add them here, but I have never seen a practical use case for this or the rest of these physical measurements.

1in == 96px

cm

.wrap {
      width: 20cm; 
    }

For most of the world, centimeters are more familiar and useful as a physical measurement. They also just map to pixels:

1cm == 37.8px

mm

.wrap {
      width: 200mm; 
    }

And an order of magnitude smaller...

1mm == 0.1cm == 3.78px

The Font-Relative Lengths

Em

.wrap {
      width: 40em; 
    }

A relative unit. Originally a typographic measurement based on the current typefaces capital letter "M". Although the length doesn't change when you change font-family, it does change when you change the font-size.

Without any CSS at all, 1em would be:

1em == 16px == 0.17in == 12pt == 1pc == 4.2mm == 0.42cm

If any CSS changes the font size (at any level in the document), 1em becomes whatever the new font-size is.

Making things a tiny bit funkier, em units multiply upon themselves when applied to font-size, so if an element with font-size 1.1em is within an element with font-size 1.1em within yet another element with font-size 1.1em, the resulting size is 1.1 ✕ 1.1 ✕ 1.1 == 1.331rem (root em). Meaning even if an element is set to, say 10em, that doesn't mean it will be a consistent width everywhere it appears. It could be wider or narrower if the font-size changes (see proof).

Rem

.wrap {
      width: 40rem; 
    }

A relative unit, like em, but it is always relative to the "root" element (i.e. :root {}) rather than using the cascade like em does. This vastly simplifies working with relative units.

Notable browser support issues: doesn't work in IE 8, Safari 4, or iOS 3.2.

Points

.wrap {
      width: 120pt; 
    }

A point is a physical measurement equal to 1/72 of an inch. Points is the most common way to size type outside of CSS (likely why it is supported in CSS). It's still common in language "Of course they set this important information in tiny eight point type!".

Points make the most sense in print stylesheets for sizing type, where physical media in involved, but there is nothing preventing you from using pt for screen media or anywhere else a length is accepted.

Notable browser support issues: There used to be big differences in on-screen rendering of pt size. Here's a comparison of IE 6 vs Firefox (probably 3.6).

Pica

.wrap {
      width: 12pc; 
    }

The same story as points, only 1pc == 12pt.

ex

.wrap {
      width: 60ex;
    }

This is a measurement based on the x-height of the current font. Sometimes that comes from information embedded in the font itself, sometimes browser figure it out by measuring a lower case glyph, and worst case, it's set to 0.5em. It is named "x" height because it is supposedly based on the height of the x character. To understand x-height, think of a lowercase character that as a bit that sticks up (ascender) like a lowercase "d". The x-height doesn't include that ascender, it is the height of the lower loop part of that character.

Unlike ems, which don't change when you change the font-family, ex units do change when you change the font-family, as the value of one unit is specifically bound do that font. (proof).

ch

.wrap {
      width: 60ch;
    }

This is similar in spirit to x-height, only ch is based on the width of the zero (0) character instead of the height of the x character. It also changes as the font-family changes.

Notable browser support issues: No WebKit-based browser support at the time of this writing.

The Viewport Percentage Lengths

vw

.wrap {
      width: 10vw;
    }

This is the "viewport width" unit. 1vw is equal to 1% of the width of the viewport. It is similar to percentage, except that the value remains consistant for all elements regardless of their parent elements or parent elements width. A bit like how rem units are always relative to the root.

Sizing type is the major use case here. See Viewport Sized Typography.

Notable browser support issues: No support in any mobile browsers except the very latest iOS 6. This goes for all the viewport related length units.

vh

.wrap {
      width: 10vh;
    }

This is the same as the vw (viewport width) unit only it is based on the viewport height instead.

vmin

.wrap {
      width: 20vmin;
    }

This value will be whichever is smaller at the moment, vw or vh. In the standard use case of sizing type, this may be a more useful metric than vw or vh on their own in determining true screen size.

vmax

.wrap {
      width: 20vmax;
    }

This value will be whichever is larger at the moment, vw or vh.

Notable browser support issues: WebKit based browsers support vmin but not vmax (yet). Firefox does support vmax though.

Odd Ball Out

Percentage

.wrap {
      width: 50%; 
    }

A length set in percentage is based on the length of same property of the parent element. For example, if an element renders at 450px width, a child element with a width set to 50% will render at 225px¹.

Trivia: percentage isn't technically a length unit, but I'm including it here since it is so related.

More Information

• The spec on lengths

What is supported in your browser?

See here:

Check out this Pen!

¹ Assuming the child element isn't inline-level or a table cell with some weird table-y stuff going on, or a flex child or grid cell or any other fancy wacky stuff.

The CSS-Tricks feed is sponsored by Wufoo, the best online form builder there is. I use it on every project I've done as long as I've been a web worker. Quickly build any type of form you need, from the humble contact form to the epic multi-page, logic-riddled, mobile-friendly, custom-designed, spam-protected, payment-taking super form. Try Wufoo for free today!

The Lengths of CSS is a post from CSS-Tricks

Web apps can be split into two major components: a front-end that displays and collects information, and a back-end for storing the information. In this article, I’ll demonstrate what a relational database is, and how to properly design your database to store your app’s information.

A database stores data in an organized way so that it can be searched and retrieved later. It should contain one or more tables. A table is much like a spreadsheet, in that it’s made up of rows and columns. All rows have the same columns, and each column contains the data itself. If it helps, think of your tables in the same way that you would a table in Excel.

Fig. 1

Data can be inserted, retrieved, updated, and deleted from a table. The word, created, is generally used instead of inserted, so, collectively, these four functions are affectionately abbreviated as CRUD.

A relational database is a type of database that organizes data into tables, and links them, based on defined relationships. These relationships enable you to retrieve and combine data from one or more tables with a single query.

But that was just a bunch of words. To truly understand a relational database, you need to make one yourself. Let’s get started by getting some real data with which we can work.

Step 1: Get Some Data

In the spirit of the Nettuts+ Twitter clone articles (PHP, Ruby on Rails, Django), let’s get some Twitter data. I searched Twitter for “#databases” and took the following sample of ten tweets:

Table 1

Here’s what each column name means:

MySQL is used at just about every Internet company you have heard of.

• full_name: The user’s full name
• username: The Twitter handle
• text: The tweet itself
• created_at: The timestamp of the tweet
• following_username: A list of people this user follows, separated by commas. For briefness, I limited the list length to two

This is all real data; you can search Twitter and actually find these tweets.

This is good. The data is all in one place; so it’s easy to find, right? Not exactly. There are a couple problems with this table. First, there is repetitive data across columns. The “username” and “following_username” columns are repetitive, because both contain the same type of data — Twitter handles. There is another form of repetition within the “following_username” column. Fields should only contain one value, but each of the “following_username” fields contain two.

Second, there is repetitive data across rows.

@AndyRyder5 and @Brett_Englebert each tweeted twice, so the rest of their information has been duplicated.

Duplicates are problematic because it makes the CRUD operations more challenging. For example, it would take longer to retrieve data because time would be wasted going through duplicate rows. Also, updating data would be an issue; if a user changes their Twitter handle, we would need to find every duplicate and update it.

Repetitive data is a problem. We can fix this problem by splitting Table 1 into separate tables. Let’s proceed with first resolving the repetition across columns issue.

Step 2: Remove Repetitive Data Across Columns

As noted above, the “username” and “following_username” columns in Table 1 are repetitive. This repetition occurred because I was trying to express the follow relationship between users. Let’s improve on Table 1‘s design by splitting it up into two tables: one just for the following relationships and one for the rest of the information.

Fig. 2

Because @Brett_Englebert follows @RealSkipBayless, the following table will express that relationship by storing @Brett_Englebert as the “from_user” and @RealSkipBayless as the “to_user.” Let’s go ahead and split Table 1 into these two tables:

Table 2: The following table

Table 3: The users table

This is looking better. Now in the users table (Table 3), there is only one column with Twitter handles. In the following table (Table 2), the is only one Twitter handle per field in the “to_user” column.

Edgar F. Codd, the computer scientist who layed down the theoretical basis of relational databases, called this step of removing repetitive data across columns the first normal form (1NF).

Step 3: Remove Repetitive Data Across Rows

Now that we’ve fixed repetions across columns, we need to fix repetitions across rows. Since the users @AndyRyder5 and @Brett_Englebert each tweeted twice, their information is duplicated in the users table (Table 3). This indicates that we need to pull out the tweets and place them in their own table.

Fig. 3

As before, “text” stores the tweet itself. Since the “created_at” column stores the timestamp of the tweet, it makes sense to pull it into this table as well. I also include a reference to the “username” column so we know who published the tweet. Here is the result of placing the tweets in their own table:

Table 4: The tweets table

Table 5: The users table

After the split, the users table (Table 5) has unique rows for users and their Twitter handles.

Edgar F. Codd called this step of removing repetitive data across rows the second normal form (1NF).

Step 4: Linking Tables with Keys

Data can be inserted, retrieved, updated, and deleted from a table.

So far, Table 1 has been split into three new tables: following (Table 2), tweets (Table 4), and users (Table 5). But how is this useful? Repetitive data has been removed, but now the data is spread out across three independent tables. In order to retrieve the data, we need to draw meaningful links between the tables. This way we can express queries like, “what a user has tweeted and who a user is following”.

The way to draw links between tables is to first give each row in a table a unique identifier, termed a primary key, and then reference that primary key in the other table to which you want to link.

We’ve actually already done this in users (Table 5) and tweets (Table 4). In users, the primary key is the “username” column because no two users will have the same Twitter handle. In tweets, we reference this key in the “username” column so we know who tweeted what. Since it is a reference, the “username” column in tweets is called a foreign key. In this way, the “username” key links the users and tweets tables together.

Is the “username” column the best idea for a primary key for the users table?

On one hand, it’s a natural key — it makes sense to search using a Twitter handle instead of assigning each user some numerical ID and searching on that. On the other hand, what if a user wants to change his Twitter handle? That could cause errors if the primary key and all referencing foreign keys aren’t updated accurately, errors that could be avoided if a constant numerical ID was used. Ultimately the choice depends on your system. If you want to give your users the ability to change their username, it’s better to add a numerical auto-incrementing “id” column to users and use that as the primary key. Otherwise, “username” should do just fine. I’ll continue to use “username” as the primary key for users

Let’s move on to tweets (Table 4). A primary key should uniquely identify each row, so what should the primary key be here? The “created_at” field won’t work because if two users tweet at the exact same time, their tweets would have an identical timestamp. The “text” has the same problem in that if two users both tweet “Hello world,” we couldn’t distinguish between the rows. The “username” column is the foreign key that defines the link with the users so let’s not mess with that. Since the other columns are not good candidates, it makes sense here to add a numerical auto-incrementing “id” column and use that as the primary key.

Table 6: The tweets table with an “id” column

Finally, let’s add a primary key to the following table. In this table, neither the “from_user” column nor the “to_user” column uniquely identifies each row on its own. However “from_user” and “to_user” together do, since they represent a single relationship. A primary key can be defined on more than one column, so we’ll use both these columns as the primary key for the following table.

As for the foreign key, “from_user” and “to_user” are each foreign keys since they can be used to define a link with the users table. If we query for a Twitter handle on the “from_user” column, we’ll get all the users he follows. Correspondingly, if we query for a Twitter handle on the “to_user” column, we’ll get all the users following him.

We’ve accomplished a lot so far. We removed repetitions across columns and rows by separating data into three different tables, and then we chose meaningful primary keys to link the tables together. This entire process is called normalization and its output is data that is cleanly organized according to the relational model. The consequence of this organization is that rows will appear in the database only once moving forward, which in turn make the CRUD operations easier.

Fig. 4 diagrams the finalized database schema. The three tables are linked together and the the primary keys are highlighted.

Fig. 4

Relational Database Management Systems

There are small variations in SQL between each RDBMS vendor, termed SQL dialects.

Now that we know how to design a relational database, how do we actually implement one? Relational database management systems (RDBMS) are software that let you create and use relational databases. There are several commercial and open source vendors to choose from. On the commercial side, Oracle Database, IBM DB2, and Microsoft SQL Server are three well known solutions. On the free and open source side, MySQL, SQLite, and PostgreSQL are three widely used solutions.

MySQL is used at just about every Internet company you have heard of. In context of this article, Twitter uses MySQL to store their users’ tweets.

SQLite is common in embedded systems. iOS and Android let developers use SQLite to manage their app’s private database. Google Chrome uses SQLite to store your browsing history, cookies, and your thumbnails on the “Most visited” page.

PostgreSQL is also a widely used RDBMS. Its PostGIS extension supplements PostgreSQL with geospatial functions that make it useful for mapping applications. A notable user of PostgreSQL is OpenStreetMap.

Structured Query Language (SQL)

Once you’ve downloaded and set up an RDBMS on your system, the next step is to create a database and tables inside of it in order to insert and manage your relational data. The way you do this is with Structured Query Language (SQL), which is the standard language for working with RDBMSs.

Here’s a brief overview of common SQL statements that are relevant to the example Twitter data above. I recommend you check out the SQL Cookbook for a more complete application-driven list of SQL queries.

• Create a database, named “development”

    CREATE DATABASE development;
        

• Create a table named “users”

    CREATE TABLE users (
          full_name VARCHAR(100),
          username VARCHAR(100)
        );
        

  RDBMSs require that each column in a table is given a data type. Here I’ve assigned the “full_name” and “username” columns the data type VARCHAR which is a string that can vary in width. I’ve arbitrarily set a max length of 100. A full list of data types can be found here.

• Insert a record (the Create operation in CRUD)

    INSERT INTO users (full_name, username)
        VALUES ("Boris Hadjur", "_DreamLead");
        

• Retrieve all tweets belonging to @_DreamLead (the Retrieve operation in CRUD)

    SELECT text, created_at FROM tweets WHERE username="_DreamLead";
        

• Update a user’s name (the Update operation in CRUD)

    UPDATE users
        SET full_name="Boris H"
        WHERE username="_DreamLead";
        

• Delete a user (the Delete operation in CRUD)

  DELETE FROM users
      WHERE username="_DreamLead";
      

SQL is pretty similar to regular English sentences. There are small variations in SQL between each RDBMS vendor, termed SQL dialects, but the differences are not dramatic enough that you can’t easily transfer your SQL knowledge from one to the other.

Conclusion

In this article, we learned how to design a relational database. We took a collection of data and organizing it into related tables. We also briefly looked at RDBMS solutions and SQL. So get started by downloading an RDBMS and normalizing some of your data into a relational database today.

Preview Image Source: FindIcons.com/Barry Mieny

On Tuesday, March 12, Robert Provine, professor of psychology, talked to WYPR’s “Midday with Dan Rodricks” about his new book, “Curious Behavior: Yawning, Laughing, Hiccuping, and Beyond.”

Rodricks asked Provine why he chose to research mundane – and even occasionally embarrassing – behaviors such as yawning, belching and farting.

“It’s fun to do, and it’s something that can get junior science students involved right away. It also has a lot of rewards for the serious scientist, which is what got me interested in it in the first place,” he said. “By looking at elemental behaviors, such as the instincts of yawning, laughing, coughing, sneezing, belching, and so on, this provides us with a molecular approach to human behavior. The opportunity to look at these exciting and important acts is only available because we’ve overlooked them. I believe that they will lead to important insights.”

The full interview can be heard here.