Bullet (points) with butterfly wings

A recent challenge my teammates and I had involved a landing page with an unordered list with funky png bullet points. The page was entirely hard-coded, but the company we are working with wanted the ability to edit the text.

The team talked through possible challenges: How do we make sure the pink markers show up, what would be the easiest way to present the form to edit the page, etc.

I worked on this challenge by myself (working remotely).

Screen Shot 2016-06-15 at 4.47.04 PM

What I did first was change the CSS to automate the bullets with the following code:

p.main-points {
 background-image: image-url("svp_pin.png");
 background-size: 50px;
 background-position: left top;
 background-repeat: no-repeat;
 padding-left: 80px; /* Adjust according to image size to push text across. */
 margin-bottom:30px;
 min-height:55px;
}

In the html file, I added the main-points class to the paragraph tags. The min-height is there to ensure the entire bullet is visible, in case a particular point only has one line.

Second, I created a table in the database with a column for “main points.” That way, I could change that through a simple form, and also call the text via a rails skull_tag, ie

<%= @page.main_points %>

But how do we keep the bullet points for each point written? With the entire text in the main_points column, the section would read that as one big chunk, one big paragraph.

Enter simple_format.

<%= simple_format(@page.main_points, class:”main-points”) %>

All we had to do is make sure we keep a line break when editing the text in the textarea.

Screen Shot 2016-06-15 at 4.59.16 PM

That guaranteed having separate <p> tags, as seen in the first screenshot.

Bullet (points) with butterfly wings

Hay there! Now pass me the hash…

Hashes. Love ’em or hate ’em you, Ruby says you can’t live without ’em (sort of). Wait, did you think I meant the other kind of hash? This is a drug-free zone!

Anyway, I was having a difficult time with a rather simple (on the surface) exercise. Finding the needle in the haystack (not a literal needle in a literal haystack).

Here’s a hash:

haystack = {hay: [:hay, :hay, :hay, {hay: {hay: [:hay, {hay: [:hay, :hay, :needle]}, :hay, :hay, :hay]}}, :hay, :hay]}

Now, find the needle.

Getting to an element of an array is fairly easy. You have an array, eg:

 array = ["a","b","c","d"]

Want to get to b? Look for it by its index number.

array[1]

The first element in any array has the index number of 0.

A hash, which looks like this:

hash = {"key" => "value", "key1" => "value1"}

or this:

hash = {:key => "value", :key1 => "value1"}

if the keys are symbols, or this:

hash = {key: "value", key1: "value1"}

Anyway, if you wanted to get to “value1”, you needn’t scratch your head and try to figure out index numbers or anything, which is what I was doing. Instead, just present the key in question, and you shall receive the value.

hash[key1]

It’s that simple. Literally.

 

 

 

Hay there! Now pass me the hash…

This is not a love song

Know the song that goes “I belong to you, you belong to me, you’re my sweetheart”? Rails says you can trash that because that’s not how relationships work.

When building a site in Rails and using database tables, you’re going to have to connect these said tables in, sometimes, complicated ways.

Let’s say you have a blog, like this one. Every blog post has one title, one entry, one author…and many comments (if you’re not a loser, like myself).

Because each table cell can accommodate only ONE thing, you can’t have a database table column for comments. That would mean each blog post could only have one comment, and that would make for a depressing blog.

Instead, you’d use two tables – one for the blog posts, and one for the comments, and you’d link them by using a bit of relationship syntax.

In your blog_post model, you’d write

 has_many :comments 

In the comment model, you’d write

 belongs_to :blog_post 

Ie, you belong to me, I have many yous (the dream life).

It gets dicier when you’re dealing with, say, tags. A blog post can have many tags, but each tag can have many blog posts.

In that case, you’d use a join table – basically a third table whose sole purpose is to connect the other two. The societal lubricant of the database/coding world.

That third table would only have an id, a blog_post_id and a tag_id.

Again, syntax is super important. The join table belongs_to the others. The tag model has many tagged posts. It also has many blog_posts, through tagged_posts. And vice versa. See below for a super high-tech demonstration.

Screen Shot 2016-03-27 at 8.32.14 PM

 

 

This is not a love song